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