Thursday, April 07, 2011

Scrum Taboos

It is said ‘success has many fathers but failure is orphan’. Agile community is no exception but goes beyond unreasonably at project failures unfortunately. Agile ‘as a process’ often gets glory of a successfully delivered projects today and that is well deserved in my opinion. Unfortunate side of the story is that it’s always the team that is blamed in case of failures. Often in these cases the team get blamed for not practicing agile right’.

As we stand today, it is really important that we open up the discussions the failure case studies of agile and ensure those are not repeated again. There are enough discussions and trainings on how to practice ‘scrum right’, but there is little discussion on how ‘not to practice’ the same.

In this post I would like to open up discussing some of these taboo topics of Scrum. Just that we need to be aware of the pitfalls and see if the team is heading to any of those.
  • As stated many times, Scrum is clearly a management process and does not define engineering practices. It is important to understand that the successful projects were successful not only because they had a good management process but because of the equivalently good engineering practices. But this is something often underrated in-front of the glorified Scrum process. Remember that Scrum alone will not take you anywhere. For example Scrum without test automation is a recipe for failure.
  • Most of the times in my experience, successful Scrum projects had a undeclared project leader who ensured nothing unexpected is taken place in the project. In some cultures, this model works better than just expecting to the team to self-organize specially when all members are not highly experienced. Though many of the Scrum literature discourage organizing around a leader, that looks a much natural model for me at least until team is mature enough to handle itself. Just be aware that hiring and assembling 5 a team with good developers without leadership qualities will have a limited success.
  • Another issue is that the agile methodologies are not really agile when it comes to implementation in different project contexts. Tweaking the practices to avoid any non negotiable constraints is often discouraged by agile practitioners. Scrum practitioners recommends it to be practiced as defined in books most of the time. This sometimes cause the teams to choose suboptimal flows just for the sake of satisfying process needs (just the same was seen too often in CMMi and ISO days). For example I have worked with a project team who hasn't done any Sprint planning in detail had a 45 mins daily scrum. They have clarified all daily issues from the PO as it was the best time of the day for PO and it worked out quite well.
  • Agile processes suggests late architectures as it tend to incorporate accumulated knowledge over time. It looks appealing in theory but may be a better approach is needed in practice. what I have always noticed is, regardless of documented or not, senior developers envision the product architecture in good detail upfront. Since BDUF is taboo in agile, these architectures are not documented but held in heads. Better approach may be that we accept the need for architecture upfront and document/share the same with others in/out the team. Only thing is that we need to ensure everyone understand the architecture is not final, but should be changed as team get to know things better. 
  • Collaborative design and architecture is another a cool concept in theory. If you have ever involved in designing complex system think for a minute, how practical is for whole team to gather in a meeting room and derive a design for that really complex problem? There are too many parameters to consider and too many brains analyzing the parameters in different angles makes things complex further. More practical model may be that couple of senior developers doing the initial architecture sketches/alternatives and then discuss it with the team so the team have a base for analysis. 
  • For Scrum teams, the prominent outcome of a sprint is the working feature demonstration at the review. It is widely seen that Scrum teams are driven by the desire of having a cool feature demo at the end of the each sprint. This is because most of the POs do not understand (or do not care) technical activities such as refactoring, unit tests, etc. As demo pressure increase, teams often omit these critical technical activities but keep collecting features at the expense of technical debts.
  • There are many stakeholders to a project, not just PO, SM. It is important that team accommodates other stakeholders to be a part of the delivery. Unfortunately many teams end up in Scrum elitism by listening only to the PO but calling all others chickens. On a similar note, Scrum teams are bound to be ‘protected’ from any external interferences. But this sometimes can make the team to be away from the ground realities as well. Software engineering is not simple and predictable job always. Some years ago software developers had courage and willingness to handle pressure when business critically demands it. It is questionable how far the new generation can hold a massive pressure when business really need that to survive.
  • Offshore Scrum teams are subjected to the direct exposure of customer. This can certainly be noisy and disturbing in some scenarios. Once there was a member who did quite a team administration (logistics, non technical documentation, process clearance, etc) was seen by the customer as non productive. But in fact those were necessary functions to the project given the context. The fact that he wasn't a great communicator added more concerns on the matter. Though it was possible to explain things to the customer at each point, they slowly grew negativeness around the member and eventually we decided to take him out of the project. 

Above are some ground realities I have experienced in working with agile teams. I’m sure any process (not just Scrum) can theoretically provide solutions for all above. But just be aware that things are still challenging on the battle field, miles away from the command center.
[tag: 99xp ]


Unknown said...

Excellent read as always. Quick question. If you are trying to convert a traditionally run software services programme (Not a project) to a Scrum approach what would be the best method in your experience? 1. Going all out in to full Scrum mode and trying to practice as many Scrum practices as possible OR 2. Taking one step at a time and gradually transforming the project to Scrum.

Hasith Yaggahavita said...

i have tried both approaches and I'm convinced if you are starting a new project it's the first method - full scrum mode that works.

'Scrum BUT' as a mindset is very disruptive. When you practice, yes it takes time to master and you will miss out few things here and there. But never 'plan' to miss things. :D