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

DoD : does it really help continuous delivery?

Short Answer: Yes if done right :).

Long Answer:
We are trying to come with DoD (Definition of Done) for my teams. We came up with our DoD, which is pretty much taking care of entire 9 yard, from code to validation.  It has checks for 

• meeting acceptance criteria
• making sure we are doing code review
• release check list 
• making sure automated test in written for code
• architectural review
• .....

This set looks almost identical with my previous teams (may be with 10-20% variance).  After the entire exercise, I am honestly challenging myself on how much DoD would help my team in delivery? Does anybody really cares for DoD in real day-to-day work? 

I thought of gathering some understanding on the true purpose and scope of DoD. For Teams who are doing continuous deployment and development, how is this artifact relevant? 

• Is it a reminder for us to do our engineering job i,e commit your code, write acceptance criteria or automated test cases
• we need DoD to have one understanding of Done
• Use to DoD to get Story Points in the same iteration vs. next
• Is it a big checklist for us to remember our mistakes
• It helps teams to be more disciplined
• Improves teams credibility amongst stakeholders
• it helps team find weakness in the system
• It reduces the risk of misunderstanding as well as the communication gaps between the teams and stakeholders.
• it is something else. 

Relevancy is dependent upon the context you are in... Here are some tips which worked very nice for our team in past: 

• Automate as many check as possible 
• Don't let it collect dust. it is not static document.
• Break checks across all columns vs. doing it at the end.
• Try making your DoR big, so only right stuff can entire the work pipeline. And try to keep DoD short and concise.  

Again, until DoD is part of daily ritual, I doubt, it would bring the desired result. For DoD to allow us to focus on delivery, it has to be part of our daily routine/discipline. 

Hope it helps

Manisha

What is an Impediment?

One of my team always says "Wish we did not have this meeting today" or "We are still waiting for our server rule to be created" or "Thoughts on how to get feedback sooner from architectural group" or "We are still figuring out whom to ask for getting rights for TFS server". Their comments made me think, how can I help them and what to do to raise their concern.

During this thinking process, I asked myself, are these impediments?

At present, we have mechanism to flag stories or tasks in Jira as blocker or impediments. We, agile coaches, get alert whenever somebody marks an issue as impediment. We all work our best to remove it as quickly and as efficiently as possible. Impediment for us is anything, which stops team from doing its work. 

What if we change the definition to, "Impediment is anything which is preventing our teams from achieving continuous flow as fast as possible." it can be anything like delay in getting new server for testing, getting feedback from other group, too many meetings complain etc... Most of the times team members do not specify them as impediment but these things effect our flow. Hence keeping an eye on them is very useful and can help teams a lot. 

Alongside, we facilitated a retrospective called Angel retrospective. We asked team members to wish for one thing which will help them in achieving their goal in most effective and efficient way. We collected their wishes and it was starting point for our impediment list.  

I am still working on finding techniques and methods to collect impediments and work on removing them.

Let me know your experience

Manisha

Estimate Size and derive duration

Planning should enable us to do right and reliable decision making. - John Maynard

I am big proponent of doing estimation. I think it has advantages if done right. For doing it right, I personally found Mike Cohn's "Estimate Size and Derive Duration technique" very useful.

In this technique we separate the step of Estimation from the step of Deriving the Duration.

In Estimation step, we figure out the size of the work to be performed. It can be done in any unit your team prefer i.e. story points, ideal time or any other unit. Once we have the rough number for size then we estimate our pace i.e velocity or cycle time.  After having both the numbers, finally we derive the duration.

Example:

Lets say we are building a new analytics dashboard. I request my team to estimate the backlog in ideal time (Time Spend doing the work) by making three assumption.

1. It's all you work on
2. no one interrupts you
3. and everything you need is available

I request them to do a rough estimation, it does not need to be precise. Then I convert the Ideal Time into Elapse Time (Time is from start to finish of the work) by taking into account their daily meetings, their other distractions etc.

After doing my above math I try to find their pace. If the team is new to agile methodology, I prefer to wait for couple of sprints/stories to finish before guessing their pace. Otherwise I like to average the velocity or cycle time by removing the out liars.

Once I have above two units, I simply divide to derive duration.

Estimation / Pace = Duration

Hope it helps
Manisha

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