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

Journey from no automated test to some

In the world where code is legacy, the minute you deploy it to a production system. Every developer is touching some piece of code which is legacy and does not have sufficient test coverage. Team might be running manual test for their releases. But as we know running manual test might take significant amount of time. It would make continuous development/deployment impossible for any agile team. I would think any agile practice would fail without proper automated test coverage.  Forget about teams who does not have manual testcases.

Imagine above project where we had 10 features to start with and team slowly developed more functionality. Our manual testing time also gradually grew from 1 hour to 4 hours.  The amount of manual testing would go up with every feature unless team takes measures to stop this from happening. 

In my old project we started with identifying easy to automate, we started automating steps which were repeated in most of the testcases. i.e. login, mouse clicks and loading of menu bars etc. Our application was very difficult to automate because it was not written to keep automation in mind. 

During step identification process, we decided to develop automated tests for our new features. We were being able to stop our situation from deteriorating. Our goal was to add automated test for all new functionality we were developing. This was the most difficult step. We modified our DoD ( Definition of Done) too. 

Honestly this was big step for us and we gained lots of confidence by doing it. We slowly used our Kaizen time to convert existing manual testcases over the period of time. 

Trying doing the same thing for your codebase, I am sure you would see success too. Try reading http://www.thoughtworks.com/insights/blog/test-automation-who-should-be-involved article.

Cheers!

Manisha

Estimation meeting getting dragged for hours?

In our organization all Product Owners (PO) fear or simply run away from estimation meeting. We started following Kanban and one major consideration amongst others were relief from those hour long estimation meetings.

Basically we made estimation meetings so painful that POs stopped asking for it. We started arguing about value of those estimation meeting.  I am sure this scenario is not common to us. I felt, as if these developers have been burnt by giving estimate before. I am confident, management hold them accountable for the numbers they spoke. 

I would try to resolve these issues by encouraging team to give honest estimation. I would also assured them that the number will not be taken against anybody if it turns out to bigger than what they feel. Also never use their estimates against them i.e. in reports or some charts. Remember estimates are not commitments. We estimate and then if necessary we commit. One of the most important factor in converting an estimation into commitments, are cost of being wrong. A team facing high cost for being wrong would give a different commitment from being a team which pays no cost at all. 

I would recommend explaining them the benefit of estimation meeting from team's perspective. We all know why estimation is important for client/customer/PO but why it is important to team. (Mike Cohn gave an awesome tip, which I love to follow.). Team develops credibility by giving an estimate and sticking to it. If team has track record of providing estimate and meeting them. Business will listen when team says certain deadline is impossible. I am sure every team likes to be heard. 

Cheers

Manisha

Estimating Product Backlog Items - why to do it?

In our team we have stopped estimating product backlog items.

In our context I believe it's fine not to spend our valuable time estimating product backlog item. Because, there is no need to tell, where the team would be in two or three months. Also since team is working on small small features PO wants all of them. For us having estimate will not change any behavior, so I would say it's okay. 

In my past projects we always estimated PB. An estimate represent the cost of an item and helped PO successfully prioritize the items. Also estimation helped us doing the rough long term projection on when team would be done with the product backlog items. We estimated product backlog items during our PbG ( Product backlog Grooming) meeting. We use to have PbG meetings 2 to 3 days before sprint planning meeting. This gave enough time to PO to get the backlog prioritized and ready for sprint planning meeting. At times we did adhoc Product backlog estimation based on PO's need. 

It is nice to experience both side of spectrum. 

Thanks

Manisha

How To Groom Product Backlog

Product Backlog Grooming (PbG) means keeping the product backlog well maintained. This concept has become very popular amongst teams over the past few years. Teams realize that Sprint work gets lot easier if the product backlog is in good shape. i.e. Well Groomed.

PbG is where top priority backlog items are assessed against Definition of Ready(DoR) or Conditions of Satisfaction or Acceptance Criteria. Whatever you would like to call them in your system, is basically high level test to verify the backlog item. By doing this in advance of Sprint Planning meeting, Product Owner (PO) gets a chance to add any missing details to the item before Sprint Planning meeting.  Grooming a product backlog usually involves handful of separate activities.

1) New items can be added into backlog with rough estimate from team.
2) Reprioritization of backlog items based on customer feedback, usage pattern etc.
3) Discussing top big items and breaking them into smaller items to fit them into next Sprint.
4) Adding details to the items as per DoR
5) Throwing away the items which are not needed

I would not suggest entire team to participate in PbG. However PO, Scrum Master and one or two team member should be sufficient. Lots depend upon the team semantics. Scrum Master may ask the team during standup, about their availability for PbG meeting, anybody who is not too busy during the Sprint can participate. Everybody should get a chance to participate once in couple of Sprints.

In my perspective it is lot advantageous to designate a specific time in the Sprint and do it on regular basis vs. thinking of doing it real time. i.e. whenever needed. It should be good to do it before 2 or 3 days before Sprint Planning (SP) meeting.

Thoughts

Manisha

Task finish late more often than they finish early, why?

"Failure to plan is planning to fail"     -  Winston Churchill. 
"It is better to be roughly right than precisely wrong." - John Meynard Keynes 

Planning should enable us to take right and reliable decision. Don't get me wrong, I am not asking for precise estimation.

I strongly believe in quick and rough estimation which evolves as time pass through.

In this post, I am leaning more towards what impact, human behavior and type of work we do, make on our rough estimated number.

Student Syndrome or waiting till last responsible moment ;)

Student Syndrome, refers to waiting to start a task until the last possible moment that does not preclude on time finish. (This is human nature and very difficult to change.) Lets take same feature A example. As a developer, I thought task X should not take more than 3 days but I kept one day buffer and said 4 days.

When we think we always think like below: Work (3 days) + local Buffer (1 day)

But while executing we feel very optimistic to finish the task in 3 days and we start with cleaning technical debt, preparing some flow for project or documents etc.

We behave reverse i.e. Local Buffer (1 day) + Work ( 3 days)

Finally I started my work and my work took 4 days. I ended up delaying the schedule vs. finishing on time. I had local buffer but it did not help. Therefore having shorter iteration in development cycle might help in keeping the focus vs. big iteration.

Lateness passed down (Central Limit theorem does not apply for software)

Software tasks are mostly dependent upon each other, hence the impact of delay of one task may cause delay in other another too. Let me elaborate what I mean by this. Lets estimate a feature A, which has 3 tasks X, Y, Z.  Task X would take 4 days to finish. Y and Z subsequently would take 2 days each. So initial estimate for feature A is 8 days.

For some technical reason task A took 5 days. Now obvious question would be to think what impact would it have on tasks Y and Z? Developers would mostly say other tasks would finish in 2 days each, since I learnt a lot while finishing task X.

You might think that our new estimate for feature A is 10 days vs. 8 days.  If the tasks in feature A are independent to each other, than this new estimate might be good but in most cases if task X took 1 days longer there are possibilities that task Y and Z might take longer too.  Therefore for any revision, look for inter-dependency within tasks for more accurate estimates.  

my experience
Manisha