Before we start, let me set the stage right for all of you :)
Old Scenario (Dancing Stories, Story keeps dancing between phases/states till it gets ultimate nirvana of doneness.) :
Sven a handsome developer picked a story from "Ready to Be Developed" column :D.
- He moves it to "Analysis/Planning" column to have a clear understanding of story. He collaborates with PO and Team subsequently. After his analysis he either moves his story to " back for PO to update" or "In Progress to start the work".
- After finishing the story, he moves the story to "Ready to Be Reviewed". Like before this can also result in backward or forward movement.
- Then comes the Ready to Be Product Owner Review phase. Similar pattern follows in this phase too. The story moved in "In Progress" if PO finds some anomaly (:D) otherwise Ready to Be Deployed.
Problem:
- Board is not representing the real state of story vs. just helps in understanding who is working on it.
- It encourages silos of responsibilities within team vs. enforcing swarming culture
- Helps very little in identifying the true weakness of system. Using this approach it will longer to identify bottleneck.
Refactored Scenario, with only one COOL rule, FORWARD Please :):
Sven, same old, handsome developer picked a story from "Ready to Be Developed" column :D.
- He moves it to "Analysis/Planning" column to have a clear understanding of story. He collaborates with PO and Team subsequently. Since he can't move the story backward, he pairs with PO to ensure readiness. If PO needs time, then he assigns the story to PO but story DOES NOT CHANGE state/phase. After finishing his Analysis he moves it to "In Progress to start the work".
- After finishing the story, he moves the story to "Ready to Be Reviewed". Like before story has to live in same state until it has fulfilled the current state. The responsible person can change but not the state. i.e. Sven assigned it to "Michael" for code review or to "Mike" for QA verification. During this time, he is either pairing with appropriate person working on story or uses this time to prepare about next state of story or helping other team members in finishing their task. In any case he is not starting any new until current work is done.
- .... Similar pattern would follow across the board.
As always, after introducing this new rule, Sven was super upset and came running to his favourite LDA ( Lean Delivery Agent):
Sven: This change is ridiculous and will slow us down. Why we have to do it?
Manisha: We introduced this change hoping it will help us in identifying bottlenecks in our system. For example:
- If "Analysis" is taking longer than we might have to involve Architect during technical feasibility more
- If "In Progress" is taking longer than might be story was not sized properly or scope creep is happening.
- If PO Review is taking longer than we might request POs for in time feedback or would involve them early may be during development.
Sven: It will definitely slowing us down since I am not being able to start something new after I am done working with my story?
Manisha: You mean, when the story is deployed on live and usable. I thought for us DONE means story is deployed and usable in production. (YES!!!!!!)
Sven: No, I mean when I finish coding of it.
Manisha: Aha! Simply because finished coding does not mean you are done dear :). You still need to make sure you keep your focus on the story and involve people effectively and efficiently.
Sven: Why can't we move the story backward, AGAIN? I am working on it since it failed verification, it should be In Progress.
Manisha: You are working the story continuously till it is deployed, aren't you, may be with different people. Hence "In Progress" is not the only column, which shows that you are working on it. The status/phases represents the state of the story not who is working on it. On the other hand whomever the story is assigned to, is the Person working on the story. Let me be little more explicit on collaboration piece:
- During analysis, you are collaborating with Team or Architects or PO to understand the story
- In Progress, you are writing code based on your understanding
- In PO Review, you are collaborating/supporting PO to get your story approved.
- In Deployment, you are collaborating/supporting devops/live deployment/doing it yourself to get your story deployed
Sven: Yeah, Yeah we always do that. Who would be benefitted most with this change, since we sit close by and are aware of things happening around it.
Manisha: As said earlier, The status represent the story's life cycle state, which would help stakeholders/distributed team knowing the current status of the work. i.e First time In Progress would take longer and hopefully addressing PO comments would be quick. So it will help in expectation management.
Sven: Okay! lets give it a try :D.
Yeeeehhhhh!!! That's the spirit.. Lets give it a try
Manisha
No comments:
Post a Comment