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 ]

Saturday, March 26, 2011

Exceeding expectations don’t just happen!

One of the interesting debates in business forums is whether one should try to ‘exceed’ customer expectations, or should just keep on ‘meeting’ expectations. It’s tempted to participate the debate, but rather adding more confusion I will present some experience on the matter.

If you just google for the topic of ‘exceeding expectations’ you will see hundreds of tips coming up. Despite the topic, almost all of those actually talk about ‘meeting’ expectations. I would say that’s very positive, because ‘meeting’ expectations is the baseline of customer satisfaction. One who’s not meeting expectations, but trying to ‘exceed’ expectations will be seen simply stupid by the customer. This is why a Harvard Business Review article once said ‘Stop Trying to Delight Your Customers’ as it may not really bring much loyalty.

Where does that leave us? does that mean there is nothing called ‘exceeding expectations’? I don’t believe so. In my view, if you are already ‘meeting’ expectations, anything beyond can take you a long way ahead competition.

But there are three extremely important facts one should know before stepping in.
  • Fact 1: The level bar of expectations is on the move and is relative to the circumstances. 
  • Fact 2: Unless consciously does it, it is unlikely you will continuously exceed expectations. 
  • Fact 3: There is always a chain of expectations and you are in the middle of the chain. 
It's because of the fact number one above, one can never continuously exceed expectations by ‘overwork’. If your team overwork this month, you raise the bar of expectations. Next month you will have to work even harder to exceed expectations, and that model is simply not sustainable.

‘Hard work’ isn’t the strategy, but it is ‘smart work’ that helps exceeding expectations. Means that one need to be on the ball all the time, picking smart things that can make a notable impact.Therefore as said in the fact 2, that doesn’t just happen but one should consciously stay well tuned to pick things.

The final fact above tells us where to be focused. You need to empower/help the one above in the chain (commonly the immediate customer) to exceed expectations of his/her customer. One of the most common means of exceeding expectations is to do something that results in total effort reduction in the chain.

I’m tempted to provide some examples, but I won’t since it will hinder the thinking process of the readers. If is not black magic. Sensibly apply above facts in your project context, I’m sure you will find cool things to do time-to-time that will help you to ‘exceed’ expectations.
[tag: 99xl]