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

Continuous review and delivery - can they go hand in hand ??

Background: 

We use to be Scrum shop and then moved to Kanban a year ago. ( For good reasons :D). Our stakeholders were use to Scrum Review where they could give feedback before things move to production. We had defined cadence for review. 

Important points, I am not talking about Product Owners review or feedback. They are very closely involved in our DNA. I am talking about upstream and downstream communication to real stakeholders. In Scrum world they had chance to give their feedback during Scrum Review which become impossible for us to sustain when we switched to Kanban. Why:

1) We do deployment for each tiny chunk.  2) We could not predict when each story would be done. Getting stakeholders to review a story on-demand is close to impossible. 

For above reasons, we swapped the Review with Demo where they could get update on live stories once in month. After almost a year and lots of chances in our board, our stakeholders complained about not getting involved early and continuously enough to provide their feedback. They are missing something like scrum review process is our assumption.

We definitely had below constraints before proposing a solution:

• We don't want a solution, which will create bottleneck in our continuous delivery flow. 
• We don't want to increase the operational cost of our stories
• We do want the system to be self maintainable 

We started studying our Jira produced data to understand what is the average life of stories in our system in PO Review column. For first round of experience we proposed two changes.

Experiment 1: We will run this for two weeks before introducing second experiment. This will give us sometime to collect data and fill our power grid.

• We would modify the JIRA ticket to add stakeholder list for each MMF 
• Once the story related to MMF would move to "Ready for PO Review " status, JIRA would generate an automatic email notifying the above list of stakeholders. Or LDAs would get notify and they will send the email. 
• The email will have link to staging environment for feature.
• Stakeholder would get notification and can provide their feedback to responsible PO/s, but we will not wait for their feedback. PO/s still have full authority to approve the story as before.

Advantage: 

• This will be seamless to current process and would generate passive information for people to react and consume. 
• Will also tell us about our most interested stakeholders in grid. 
• POs can also send update based on that reminder.
• All stakeholders would be notified only interested one would get email.

Disadvantage

• People might not notice the information and it might just reside in their emails

Experiment 2:

• Creating a fixed rhythm of meetings may be bi-weekly (or something else) review meetings to ensure the stakeholders are up-to date
• We can review all the stories, which we have been moved to done.
• Each team can nominate one person and they can present the stories to stakeholders. 
• We would need to create a calendar for team
• Based on stakeholders comment, POs can align their stories better in future. (Inspect and Adapt)

Advantage:

• Stakeholders are involved directly 
• Team members and POs are getting their feedback directly and doing a direct collaboration 

Disadvantage:

• Stakeholder not coming to meeting bi-weekly (We can always adjust the frequency)
• Might be little too overwhelming for stakeholders to see so many stories at once.

Experiment 3: We need to change lots of code to incorporate it.

• Deploy every story with a switch in pre-production environment. (Propagate to other environments vs. Notify Developer with changes) 

Advantage:

• Stakeholders can test feature with production data and can rollback || propagate changes.
• Stakeholders have fun control over the feature. 

Disadvantage:

• Stakeholders need to be really proactive.

I will share results of our experiment on my blog for others to learn. 

Thanks

Manisha

What is exactly being productive means?

How can we improve our productivity? / What can we do to improve our productivity? / How can we effectively measure productivity? and many more questions related to same topic arises everyday. So what is productivity?

Is productivity means keeping entire organization busy all the time on most important thing?

As an organizations, our focus is always on Net Profit, ROI and Cash Flow.  To make money we need to increase net profit while simultaneously increase return on investment and cash flow. If the goal is to make money, then, an action that moves us towards making money is productivity. And an action that takes us away from making money is non-productive. So, "Productivity is the act of bringing a company closer to the goal (of MAKING MONEY). "

Making money is definitely the end result of a goal but might not be the direct goal of your company. Your company might have target like 10m new customers in next quarter or being #1 company in advertisement field etc to achieve making money goal.

Knowing those tiny goals and keeping focus on those goals are very important. To make an organization productive everyone part of it should have clear picture of their goals and should understand all the tiny steps required to achieve those goals.

I believe in agile environment, we expect too much out of our POs (Product Owners). I feel, as if we expect them to behave like superheros. They are responsible for entire engineering team's productivity. We don't expect engineering team to have much power when it comes to deliver business value.

It is hard being a Product Owner. POs are responsible to align their day to day work with mission/vision statement of the company. If PO fails to prioritize properly, it effects the bottom line.
They are also required to keep up changing market demand, creating proper specification for all engineers, being responsible for business flow and value etc. They are human after all and can make mistakes.

I strongly believe it is not only PO who need to understand organization goal, its everyone's. That's what being productive means. It is responsibility of every member to make sure they are on same page and speak same language. And it starts with selecting right items to work on.

I would recommend management to do first round of prioritization by selecting high value items (HVI I call them H6 list) (Lean Enterprise has awesome formula #WSFJ).  Then broadcast or share (via OKRs) H6 list with everybody. This could be the first step towards creating a common platform. POs would still be responsible for articulating and bringing the ship to island. But engineers can raise a flag incase they notice something which is not part of the H6 list.

Until everybody is aware of organizational goal and necessary steps to achieve it, being productive does not hold much meaning.

Lets build something which matters the most to the customer :)
Manisha