What is agile, part 2

(for the first part, see https://www.coveros.com/what-is-agile-part-1/ )

Strategies for greater effectiveness had been discussed and applied since the earliest days of software development.  What set agile apart was the shared understanding on these techniques by some of the most mindful and collaborative developers of their generation.  They convened to decide on the intersection of their respective views at Snowbird ski resort, Utah in 2001.

Some of the programmers involved in these discussions, like Kent Beck, had spent time experimenting with novel techniques to increase productivity and morale.  Kent’s book, Extreme Programming Explained (a short read, and well worth your time, by the way), went a long way towards promoting creativity and innovation in the field.

After lengthy consideration and vetting, the discussions resulted in a shared understanding of a set of values and principles which make up the Agile Manifesto (see http://agilemanifesto.org).  

The benefits paid by adherence to agile techniques was a repudiation of the cumbersome and numbing approaches that business had traditionally applied to the software development process.  To a great degree, agile allowed teams to achieve their business and personal goals, opening the door to compounding innovation and continuous improvement.

Purely by good luck, I started my career in an organization that primarily followed the strategies described by Beck.  All the promised results were seen:

• Morale was high.  
• A team of seven developers was successfully competing with companies employing ten times that number.  
• We had a sense of community and valued each other highly.  
• There was little sense of the isolation and disaffection that I have often encountered in several subsequent positions.

Since then, I have seen many companies that claimed to be agile but were not really.  Rather, they carried out actions that reinforced misunderstandings and hurt the teams.

For instance, many companies decided that to become agile meant solely renaming roles – the team lead became the “scrum master”, the product manager become “product owner”.  

In those companies, the ceremonies were often misunderstood and pointless.  For example, retrospectives as pressure release valves, to complain about things the team could not change, and to give kudos to one another for good work carried out in the otherwise difficult circumstances.  Standups that were thirty minutes long.

Does that seem familiar?