PrOpER coaching cycle

I leant a technique from Agile Coaching book, which I find very useful in my day to day life and thought of sharing.

Lets look into each term closely:

Problem: Pick a problem to work on. Watch how the team works. What needs to be improved? 

Options: Consider your options. What could you try that might influence the situation for the better? List at least three options. You can choose to brainstorm with team by persuading them via thinking questions. i.e. How often do you think about this issue? or Can you spot any gap in your thinking etc. 

Experiment: Pick one option to try and run that experiment for 2 weeks or more, depending upon your situation. Making change an experiment helps focus the team on the benefit because you’ll need to discuss how to evaluate whether the experiment is a success. If they can measure an improvement, this gives the team a reason to continue. So, start the team off making some small changes, such as redesigning the work- space or introducing a regular team lunch, to get them ready for bigger changes.

Review: Review the outcome after experiment is over. Did you improve things? Even if things haven’t improved, have you learned something? 

I use above technique almost on every problem, which is thrown at me. I also like to start with WHY question at time. Use "why" questions technique carefully, sometimes it is better to ask, "What you have in your mind" or "Are you satisfies with the results" question vs. starting with why. We will end up with less offended  team member.  More coaching cycles for you: 

GROW (Whitmore)	PrOpER	PDSA (Sheward)	PDCA (Deming)	PDSA
Goal
Reality	Problem
Options	Options	Plan	Plan	Plan
Will	Experiment	Do	Do	Do
	Review	Study	Check	Study
		Act	Act	Adjust

I like PrOpER because of it's Experimental nature. 

Thanks

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