Why stories should only flow continuously forward?

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

System: What it is?

I came across awesome definition of System in "Thinking in Systems" book.  Thought of sharing :).

Definition from Thinking in Systems book:

"A system is an interconnected set of elements that is coherently organised in a way that achieves something. System must consists of three kinds of things:"

• Elements 
• Interconnections
• A function or purpose

Few examples: 

• Digestive System:
  • The elements of your digestive system include teeth, enzymes, stomach and intestines. 
  • They are interrelated through the physical flow of food 
  • The function of this system is to break down food into it's basic nutrients and to transfer those nutrients into blood stream ( Another System)
    
• Football Team:
  • The elements such as players, coach, field and ball
  • Its interconnections are the rules of the game, the coach's strategy, the players communication and laws of physics that govern the motions of ball and players.
  • The purpose of the team is to win games or have fun or get exercise or make million of dollars or all of above

How to identify a System (How to know whether you are looking at a system or just a bunch of stuff)

• Can you identify parts? ... and
• Do the parts affect each other? ... and 
• Do the parts together produce an effect that is different from the effect of each part on it's own? and perhaps 
• Does the effect, the behaviour over time, persist in a variety of circumstances?

Most difficult Part:

• It is easier to learn about a system's element than about it's interconnections:
  • Many of the interconnections in system operate through the flow of information. 
  • Information holds systems together and play a great role in determining how they operate?
• The least obvious part of the system, it's function or purpose, is often the most crucial determinant of the system's behaviour.
  • It dependants upon complexity of the system

"You think that because you understand "one" that you must therefore understand "two" because one and one make two. But you forgot that you must also understand"and" " - Sufi teaching story

Cheers!

Manisha

Definition of Ready (DoR) - "Aha! we get it feeling"

I am trying to make my teams root strong and in the process, I am questioning them about the purpose of each and every agile ritual or document they have. I strongly believe the need of understanding the purpose before starting to do it.

Today was the turn for DoR and Board Work Flow. During my preparation I compiled few points from various blogs and thoughts of sharing with you all.

Purpose of DoR:

• It helps to keep the backlog items actionable
• It gives the opportunity to team understand the value of backlog items vs. working on junk stories
• Avoids wastage of time of both when a story is started and after a few days' work (if more information is needed to complete the story, the work on it stops).
• Reduces requirements churn in development.
• it makes sure team builds what is required
• It expose inherent weaknesses of the system.
• The Product Owner and Delivery Team work at different cadences. They focus on different things at different times. This checklist initiates the necessary discussion between Product Owner and the rest of the team.
  

What DoR should contain : 

• What:  Is the goal or end-result of the story clearly defined?  i.e., is the expected behaviour or coverage goal as clear an unambiguous as possible at this stage of development?
• How: Have you considered how to build the feature?  It doesn’t have to be much, but some thought about how to build and integrate the product story into the existing working product.
• Who / Resources:  Are all the necessary resources (i.e., people, tools, IT infrastructure) available and committed to the product story to have a reasonable chance of completing within a reasonable amount of time?
•  The DoR checklist is a living document and should be kept up-to date with the learning. 

I know my team gets very furious at times when they don't see a fully prepared story but I always insist them to work with POs to complete it.  In my opinion stories does not need to be 100% defined with all acceptance criteria. But it should be READY ENOUGH so that team can work on it without waiting in between. It should always be made 100% ready together with during grooming or similar kind sessions.

Board flow discussion was super exciting and would share the outcome in next blog.

until then!

Manisha