Sunday, February 16, 2014

Finish First To Start Next - Applying This Rule To Agile?

Do we do multi-tasking in our daily work? Or are we just good at that? Many do including me. We always do juggling over many things. This is because we are surrounded by several tasks to perform in a day. This may be true for all, developers, project managers, engineering managers. The next question is are we productive doing this? The research says that we'll not be productive at the end of the day. Juggling over too many things leads no where. I liked the post by Tony Schwartz on Magic Of Doing One Thing At a Time which is worth reading.

In the context of agile development methodology, I thought of applying this rule. This is because, I saw frustrations of developers who execute user stories planned for a sprint, that they were not able concentrate on the planned stories. Because they were pulled by several other 'unplanned' tasks such as a critical customer issues. Well, while agile encourages to take the critical (high business value) tasks first, this is not a good practice from developers' perspective once the Sprint has started. Context switching has its own role to play. And people may not like too much context switching in a day. This is exactly the problem we faced. This typically happens in a product development team where in the product is already into customer site and product enhancements/features are being developed.

Field Issues pop up once the Sprint has started

Lets say, you are working on an important user story which requires your complete attention and concentration and you have started working on it already. And when your scrum master comes to you and says, "Hey, there is a customer issue reported from the field, would you take up that on high priority?" The answer from most of the developers will be "Yes", because nothing gets important than a customer issue. However, your mind has to switch between your current user story to the customer issue. And when you come back for the 'paused' user story, you require some time to put yourself into that task. You end up not achieving the sprint goals. So, is there anything that we can do to avoid context switching? Definitely yes.

Then we made a change in the process of how we execute the sprint stories. Knowing the fact that we are expecting customer issues, have dedicated resources to solely look into those. It does not matter whether there are customers issues reported or not. Sometimes yes and sometimes no. But planning this during Sprint planning makes life a lot better. And the dedicated resources will mentally be prepared to take up the field issues.

No User Story Getting Moved to 'Verified'

Finish the user stories that under development or under verification first before pulling the next user story from to-do list. During certain sprints, many stories can be under development and no stories moved to 'verified' state. This happens due to several reasons such as there is an impediment doing a particular story. Or the resource assigned does not have sufficient competency to complete the story. And the resource stops that story and moves on to the next. It is agreed that this kind of issues must be thought through upfront during sprint planning, however in case not enough grooming of the stories has happened, these issues may be uncovered during execution. In this kind of issues are brought up during daily scrum meetings and the entire team can come into rescue to finish.  A quick change (upon everybody's agreement) will solve this problem. A different person who understands the technical depth involved in the story takes the task and complete it. This is ensured by scrum masters since scrum masters are expected to know the scrum teams better or a team's collective decision for quick change in the day's plan.

These examples can be specific certain teams only and may not apply for all agile teams, but in case teams are facing the same problems, I think I've tried to propose resolutions.

No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...