Understanding Scrum

Even though Scrum has touched souls of most of the software developers across the globe, it still seems to be understood as set of practices.  There are many yet to catch up with the principles behind the Scrum.   In the recent blog, Ken Schwaber  reviews the typical mistakes done by most of the Agilists and specifically large organizations. 

Here is the summary of  key points from his blog post with my 2 cents added in between.  Ken’s comments are in Italics.

1. Our tendency and tooling from waterfall and predictive processes is to view people as assignable, parsed, optimized resources. This works great if you are running a factory line and people are doing simple work. It really sucks if you are trying to do creative, complex work where there are many competing ideas and solutions emerge from interactions.

Even  now I have seen many people using the word “resources”  to mean mostly the “developers and testers”.  Even worst, they are also called many times as “heads” or “bodies”.   This is not only demeaning and disrespecting the people around us, but also shows the lack of seriousness about the knowledge workers.

2. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed

This is a radical thought process isn’t it ?   All of us work from 9 to 7 PM shift, and we have to think and complete our work in this duration. It is easy for every one around us to be predictive and work in the same time zone. In reality,  this is not possible.  However, the stress, which reduces creativity can be minimized by removing many of the enforcement on the employees at work.

3.

Last, but I’m sure I’ve missed others, is the idea of “assigned” work. This is a common smell of a development team that is not self-managing. Who “assigns” work if a development team is self-organizing? Development teams select work, figure out how to do it, and go do it. Assignments are a dysfunction.

Most of the issues like “assigning the tasks”,  “Architects doing the estimation on behalf of every one”,  “Project Manager approving leaves”  are the vestiges from the Waterfall era.  It is always better to coach and train the people in the top before it affects the bottom.  As the phrase goes “Fish always rots from the head down”.

You can read the entire article here.



Image courtesy: http://www.dreamstime.com/the-right-way-or-wrong-way-thumb2307359.jpg

Increase in Iteration Duration for benefit

Deciding the iteration duration is not easy. It depends on various parameters like  Duration of the project, Agile Maturity of the team, risk mitigation factors, Project domain etc.   Most of the Agile proponents suggest 2 weeks iterations. 

Typically  2 Weeks iteration looks like :

In a matured Agile team with good domain knowledge, the Iteration Planning duration over a period of time becomes stagnant. In the sense,  that the team need not spend too much time understanding  set of user stories or requirements  during iteration planning. 

For example, The team who has spent 2 years working on a particular domain can easily understand the enhancement requests.

While working with experienced teams, I have observed that whether it is 2 weeks or 3 weeks iteration, the iteration planning duration stayed almost 2 days. In such projects, it is beneficial to extend the Iteration duration to 3 weeks to gain additional 1 or 2 days saved from reduction in effort spent on Iteration Planning meeting.  

User Stories - How detailed it should be ?

During the initial days of requirement gathering session, the product owners end up writing the epics. These epics needs to be broken further down into the user stories .   One common question repeatedly asked by the novice product owners is when is the right time to stop splitting the user stories ?   

If you Google around there are many articles written about this topic. 

Some of the options proposed by various authors include:

1.  Stop detailing when you feel the user story is big enough to be implemented in 3 – 4 days

2. Stop detailing when you feel the user story can be implemented in one iteration

3. Quite commonly referred acronym is the “INVEST” model.  More details about this model can be found here,   
    
I really like the INVEST model however,  if the Product Owners(PO) and developers are new to Agile, the above model will not help them much. I still feel that it looks pretty abstract to them.  

In one of the real world case studies, a group of “new to Agile”  product owners and developers  applying the INVEST model on user stories got into a debate for couple of days. They were not willing to budge with their own understanding of  “What testable” means, as each of them had their own explanation.  

So, just telling some one to follow the INVEST model may not be sufficient.

I have my own opinion about this,  while I am coaching the Agile teams, I recommend an iterative approach to detail out the user stories. Each time the user story is created, I ask the product owners to apply the INVEST principle to begin with and then share it with the development team to check their confidence level . If they are able to understand it easily and say that they can code this story, then probably it is the right size.   If not,  then the user stories needs to be split or detailed out further.  The developers take the important seat here. The developers need to review it because, they are the people on the ground implementing the same.

If the team is working in distributed model with POs  and developers distributed across the globe, then the POs could write the user story on Wiki or JIRA kind of tool . The developers on the other end can write their comments/questions as part of the feedback loop.