It appears that the whole software development industry is washed agog with this holy mantra of Agile, and everyone is jumping onto this massive bandwagon trying to proclaim themselves as purveyors of whatever is cool in software development. However, what started out with the best of intentions, has been productized and monetized to the point where it has lost its essence.

Having been involved in various forms of Agile software development, there are some lessons that I’ve distilled from my experience with various forms of practices that call themselves “Agile” practices and how they could evolve to unproductive habits. I’d like to add a disclaimer that I am in no way denigrating these practices but how it could turn out very differently from what it was intended for.

Standups

Standups are a way the team could sync up information amongst each other. The intention was to get everyone updated on what everyone else is doing and also to relay blockers or issues that someone had encountered the day before. It is usually done quickly and a team should aim to finish their standups within 15 minutes. It is NOT meant to be a status update or a time report to a superior on what you have done.

Ideally, standups are good information relaying mechanism where a team could see where they stand based on work from the day before. However, the presence of a direct report or line manager usually becomes a powerful influence as the team will gravitate their information towards the superior, turning it into a reporting mechanism. There are times where standups start to morph into technical discussions or debates between individuals but this could be avoided by using some mechanism to postpone that discussion to AFTER the standup so that everyone gets their turn to say what needed to be said. This could come in the form of a quick note at the side of a whiteboard or a post-it note as a marker on the discussion topic.

A good standup is one where everyone is able to relay what they did yesterday, what problems they encountered yesterday and what they are going to do today. Once these information is radiated out to the team, any further discussion or questions could be left between the people who are interested or stakeholders.

Pair Programming

This practice comes from XP and it is meant to be a technical practice that encourages knowledge redundancy and propagation. It is perfect when you have new hires in a team and you can pair him off with an experienced developer. Since it is all hands-on experience, knowledge tend to get disseminated faster than purely instructional mentoring. In my team, we used to break pairs every iteration so that we can experience the diversity of knowledge within the team and given enough time, that knowledge spreads itself across. A solid 2 hours of pair programming can be rather exhausting as the pair is in a constant mode of interaction and bouncing ideas off each other. Usually you will have a navigator who is thinkin a step ahead and constantly reviewing what has been written and a driver who is the one who is writing the code and reasoning with the navigator on the rationale behind the code.

If you also do TDD (Test Driven Development), another good practice that calls itself Agile, you can incorporate it into the pair programming flow by doing tests and implementation alternatively, introducing a natural cadence to the development process. This approach not only encourages interaction between individuals, it also results in programs that are well tested.

However, doing Pair Programming right requires a fair bit of discipline for both programmers in the pairing. In reality there are times where some distractions come into the picture and more time was spent engaging in banter than work. Also, like any social activity, Pair Programming involves multiple personalities and incompatible personalities may clash and impede progress instead. Egos may be bruised in the process of pairing so practitioners need to open to constructive debate and positive criticisms.

Retrospective

Of all the various practices in Agile, retrospective is probably one of the most polarising practice amongst software developers. On one hand, a properly conducted retrospective has the advantage of providing useful insights to the team and allow them to improve on their practices and effectiveness. On the other hand, it can often degenerate into a blaming session or a pointless introspection (especially when identifying factors outside the team’s sphere of influence). This has been one of the biggest reasons why it is important for a team to have at least one specialised scrum master or skilled facilitator to conduct a retrospective. Otherwise, in my humble opinion, we might as well use the time for more productive purposes.

References

• http://blog.toolshed.com/2015/05/the-failure-of-agile.html
• https://www.thoughtworks.com/talks/the-death-of-agile