Assuming Agile

If I would be granted a wish, I would choose to be freed from making assumptions and easy judgments (and maybe sometimes to shut up and listen).
The general assumption when starting with Agile is that it will solve the problems of speed, quality, eficciency… and it will boost performance by itself. It continues further by thinking that agile practices will make a perfect code, or that people will accept Agile as a natural way of thinking and doing business. Even further, we can say that the usual assumption is that daily meetings, visual (task) boards, backlog and small iterations make us agile. It will help, but it goes fairly beyond that. This assumptions lead towards many disappointments and stopping agile transformations. You may take a look at the transformation curve in the section about culture.
Once, I had lunch with colleagues from other company. Discussing the agile SW development, one of them said: “I have very low opinion about people doing Agile. I don’t know you, so I cannot tell.” He actually never tried agile practices and learned about the principles behind them. His (strong) statement was probably based on some previous observations, creating the assumption that the ‘agile gang’ actually escapes from doing the ‘real work’. It imprinted in his mind, so in general he was against Agile. Such an attitude prevented him to see the value that could possibly derive from it and it fairly blocked his need to learn about it.

Not making conclusions based on unconfirmed assumptions is a skill. It requires practice and an open approach with a fair dose of humbleness. Assuming agility will happen without learning and hard work is like swimming towards a distant shore without moving hands and legs.

You may take a look about 10 common fails with agile from TaskWorld:

Top 10 Agile Fails #infographic

Agile – Long Trip in a Short Strip


Tribes – The Way to Compete

circle_of_feetSocializing is an important aspect of being human. It goes a long way back throughout the human evolution, having people organized in tribes for the common purpose to survive. Nowadays, collaboration has similar dimensions. Knowledge sharing is fast, including a whole range of tools and means, from web collaboration frameworks, like wiki; social networking to live video sessions. Actually, there is no excuse for not doing it.

Nowadays, my impression is that people have a tendency to group smaller tribes. Agile teams are good example. More and more they become cross-functional, gradually extending their ability to work end-to-end. They meet daily to collaborate, brainstorm, do pair-programming, share the ideas and artifacts, i.e. they learn together, and they are getting more and more efficient in all this. However, as we get pressured with different deadlines with a constant change of business dynamic, it seems that communication, collaboration and engagement with others (other teams) have been set as a lower priority. Sharing and learning is focused (and limited) within a team borders.

Since we learn as individuals and acquire knowledge, and we just said that we more and more learn within teams, we need to learn as a whole organization/company as well. We have different programs or domains that span over a number of teams. Sometimes they work together on a feature and the work is scaled. Efficient delivery of such features is dependent on scaling, i.e. learning, collaboration and sharing information and knowledge. One of the examples I witnessed was about the setup of Scrum of Scrums. If each of the teams nominates its representative (trying to avoid Scrum Masters and Product Owners) in one-level-up Scrum, it needs to make sure that the person ‘feels’  the same level of confidence and safety to share, learn and contribute as in her/his own team. Daniel Mezick, in his book “The culture game”, calls it tribal learning. In the Lean world, this is called Yokoten – the process (obligation) to horizontally share when something new is learned. Dave Logan, John King and Halee Fischer-Wright in their book Tribal Leadership – Leveraging Natural Groups to Build a Thriving Organizationdescribe the thinking model and possibilities to build tribes. They commonly describe tribes as a relatively moderate number of members – up to 150 where they can unite for a common purpose. Competitiveness of your organizations depend on possibility to scale, build contemporary tribes. Of course, culture is the part of it, so you may want to check the previous post about it.