TL;DR: Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service’s thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people’s hand.

The Scrum Guide™ describes DoD as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality. The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

They recommend that having a clear DoD helps Scrum Teams to:

• Work together more collaboratively, increases transparency, and ultimately results in the development of consistently higher quality software.
  • Clarifies the responsibilities of story authors and implementors.
• Enables the Development Team to know how much work to select for a given Sprint.
  • Encourages people to be clear about the scope of work.
• Enable transparency within the Scrum Team and helps to baseline progress on work items
  • Helps visualize done on posters and/or electronic tools.
  • Aids in tracking how many stories are done or unfinished.
• Expose work items that need attention
• Determine when an Increment is ready for release

Also according to them, DoD is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.

According to the LeSS  website– DoD is an agreed list of criteria that the software will meet for each Product Backlog Item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse DoD with acceptance criteria, which are specific conditions an individual item has to fulfil to be accepted. DoD applies uniformly to all Product Backlog items.

Examples

If you search online, you’ll find sample DoD for user stories more or less like this:

1. Short Spec created
2. Implemented/Unit Tests created
3. Acceptance Tests created
4. Code completed
5. Unit tests run
6. Code peer-reviewed or paired
7. Code checked in
8. Documentation updated
9. 100% Acceptance tests passed
10. Product Owner demo passed
11. Known bugs fixed

Another example:

1. Upgrade verified while keeping all user data intact.
2. Potentially releasable build available for download
3. Summary of changes updated to include newly implemented features
4. Inactive/unimplemented features hidden or greyed out (not executable)
5. Unit tests written and green
6. Source code committed on server
7. Jenkins built version and all tests green
8. Code review completed (or pair-programmed)
9. How to Demo verified before presentation to Product Owner
10. Ok from Product Owner

Do you see the problem with DoD? If not, read on:

Problems:

• Checklist Driven: It feels like a hangover from checklist driven project management practices. It treats team members as dumb, checklist bots. Rather than treating them as smart individuals, who can work collaboratively to achieve a common goal.
• Compliance OVER Ownership: It drives compliance rather than ownership and entrepreneurship (making smart, informed, contextual decisions.)
• Wrong Focus: If you keep it simple, it sounds too basic or even lame to be written down. If you really focus on it, it feels very heavy handed and soaked in progress-talk. It seems like the problem DoD is trying to solve is lack of maturity and/or trust within a team. And if that’s your problem, then DoD is the wrong focus. For example, certain teams are not able to take end-to-end ownership of a feature. So instead of putting check-points (in the name of DoD) at each team’s level and being happy about some work being accomplished by each team, we should break down the barriers and enable the team to take end-to-end responsibility.
• Contract Negotiation OVER Collaboration: We believe in collaboration over contract negotiation. However DoD feels more like a contract. Teams waste a lot of time arguing on what is a good DoD. You’ll often find teams gold plating crap and then debating with the PO about why the story should be accepted. (Thanks to Alistar Cockburn for highlighting this point.)
• Output Centric: DoD is very output centric thought process, instead of focusing on the end-to-end value delivery (outcome/impact of what the team is working on.) It creates an illusion of “good progress”, while you could be driving off a cliff. It mismanages risks by delaying real validation from end users. We seem to focus more on Software creators (product owners, developers, etc.) rather than software users. Emphasis is more on improving the process (e.g. increasing story throughput) rather than improving the product. Ex: It helps with tracking done work rather than discovering and validating user’s needs. DoD is more concerned about “doing” rather than “learning”. (Thanks to Joshua Kerievsky for highlighting this point.)
• Lacks Product Engineering Mindset: Encourages more of a downstream Service’s thinking  rather than a product engineering mindset. Unlike in the services business, in product engineering you are never done and the cycle does not stop at promoting code to high environment (staging environment). Studying whether the feature you just deployed has a real impact on the user community is more important than checking off a task from your sprint backlog.

What should we do instead?

Just get rid of DoD. Get the teams to collaborate with the Product Management team (and user community, if possible) to really understand the real needs and what is the least the team needs to do to solve the problem. I’ve coached several teams this way and we’ve really seen the team come up with creative ways to meet user’s need and take the ownership of end-to-end value delivery instead of gold-plating crap.

The need for an Agile coach and a right channel for coaching has become imperative for many Agile organisations. This forces us to nurture a community of coaches who understand the role requirements and goes beyond the usual to tackle the implementation challenges. Lyssa Adkins and Michael Spayd are pioneers in coaching the Agile coaches to handle large enterprise problems. Their experience in life coaching and expertise in the industry gives them an edge. They have more than 15 years of experience in leading projects and organisations.

Lyssa is also trained as a Co-active coach and leader. She authored ‘Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition’ in 2010.

Michael is trained as a Team and Organisational coach, in co-active leadership and in executive coaching.Currently he is writing a book called Coaching in the Agile Enterprise.

Lyssa and Michael are running a workshop at Agile India 2014 for Agilists who wants to increase their overall Agile coaching skills, including in the areas of Teaching, Mentoring, Facilitation, and Professional Coaching.

We had a short chat with them to understand their views about Agile Coaching

1. What is the role of an Agile Coach in the Agile transformation journey?

Lyssa Adkins: You know Agile coach is a word that we just use generically because almost every corporation has their own version of these words. They’ll say “XP coach” or “Scrum Master” or “Agile Project Manager” or something like that. And we’re not really religious about which form or the word we use. What we care is about how the coaches help teams move beyond just getting the practices up and running and, into helping teams on their joyful and deliberate pursuit of high performance. It’s really going beyond what we would consider as a basic Scrum Master or XP coach for example.

Michael Spayd: It is, as Lyssa is saying, a pretty broad range of definitions. The word “coach” is interesting too because it’s such an overloaded term. You know, it means sports coach to some people, it means professional coach – like a life coach or an executive coach to some people, and it means kind of you having coaching by your manager which really means telling you what you need to do or you are going to get fired.And that’s created some confusion around what Agile coaches do and a really wide range of activities they do.

We’ve done some writing about that and talked about all the competencies that Agile coaches need to have. But basically they stand in a position or work in a position that’s kind of like a team leader in a certain way and kind of outside the team, helping the team, serving the team, and helping the team become a better team. Not like doing things for the team, not getting and making all the decisions for the team – anything like that, but really trying to help the team become a better team.

2. What does it take to be an effective Agile Coach?

Michael Spayd: Well this is where the term Agile coach is both overloaded and really big actually, there’s a lot of things to do as an Agile coach. So we look to impart facilitation, like professional facilitation and having skill at being a neutral facilitator of meetings and events (you know games whatever it is in the Agile environment). And help leading teams through that without getting involved in the content without voting on “Oh you should do this way” but actually helping the team get better themselves.

The thing that most people think about when they think about an Agile coach is what we call an Agile-Lean practitioner, so knowing about the Agile processes, knowing how the values relate to the principles, relate to and generate the practices, how you innovate, how you modify them in a consistent way – that sort of thing – so all the world of knowing all about Agile and Lean. That’s one big, big piece but it’s definitely not the whole shooting match.

Lyssa Adkins: The predominant role we’re playing now is to help coaches create awareness in themselves of which of those disciplines (we didn’t even go through all of them but we’ve gone through a good number of them) they have solidly and which they don’t. And how at any given moment they will choose which one serves the purposes of the transformation best.

Michael Spayd: So making for an Agile coach in terms of transforming or working with a team they have to draw on this pallet, if you think about this, because coaching, facilitation, teaching, mentoring, Agile Lean practitioner. It’s like a pallet of colours that you are painting with so to speak, and the art of it, in a lot of ways, is which one do you choose at which time to help an organization make this transition.

Lyssa Adkins: We recognize that transformation is about “transformation”. Which means you can’t consult your way into it, you can’t cajole someone into it, you can’t make them do it. It’s a lot about each individual person and how that radiates out to a whole organization. So, in the center of all of those disciplines is this thing we call the coaching stance. Which is very much just like a home base that an Agile coach comes back to as a way to help activate in other people their next positive steps towards the transformation they see needs to take place. And that’s how the results stick. That’s how an organization continues to transform once the Agile consultants have left the building. And that’s an important thing for us. I guess the higher calling of why we’re together is that Agile is this incredible positive transformation virus. It is unleashing a wave of positive change everywhere that it goes. And we believe that Agile coaches when they are well equipped are powerful transformation agents to help that virus spread in a positive and useful way. Not only for people but also for products.

 3. What are the key take-aways from your workshop?

Lyssa Adkins: Well instead of us telling you about the take-aways from our workshops, you can find the testimonials from our participants on ‘Our Impact’ page in our website.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2014#workshops

How different is Counseling from Coaching?

Definition: the provision of assistance and guidance in resolving personal, social, or psychological problems and difficulties, esp. by a professional.

While the approach might look very similar, there are 2 key differences:

• Generally people go for Counseling when something is bothering them. So counseling typically focused on trying to find the root-cause of something that occurred in the past. While coaching is mostly focused on achieving a goal/skill in future.
• Counseling can also be used when the person is not really in a mental state to accept coaching.

What about Consulting?

Definition: A senior person in a professional or technical field, engaged in the business of giving advice to others working in the same field.

In my experience, consulting is at a whole different level. Typically as a consultant, I use coaching skills to gain deeper understanding of the situation/context and thus discover the real problem/s, which would help us co-create an agenda/plan to resolve the problem/s. This agenda/plan might consist of more coaching, training and/or mentoring. Its also important to note that sometimes, since the consultant is a subject matter expert, a consultant might be called in to just give their advice or do actually do the work for the client. In the second case, the consultant might not using coaching, training or mentoring at all.

What: Unconference for Agile Coaches, Scrum Masters, Agile Trainers, Leaders, Change Agents and Mentors.
When: 7th-8th June 2013
Where: Hotel Ramada, Bangalore
Theme: True Essence of Coaching

Planning Poker is certainly a fun and engaging way to do one of the most boring things on earth (STORY POINT ESTIMATION.)

If I’m not wrong, James Grenning originally came up with this idea. And my understanding is that Planning poker can best be explained by using fundamental premise of Wisdom of Crowd (Why the Many Are Smarter Than the Few). Jack Treynor’s Jelly Bean Jar Experiment is a classic example. The average guess of the group is better than the best guess of any individual.

Can we apply this concept to software estimation? May be. But there are a few small difference. In the case of the jelly bean experiment

• Everyone in the group is taking their best guess.There isn’t much prior experience or historical data to look at.
• There is zero consequences if they go wrong. They will not be held liable to this number.
• Also, everyone, more are less, are equally good at the task at hand (counting.)

Now when we talk about applying the same to highly specialized software development where each skill is quite diverse and the involvement of each person is quite varied. What do we get? A complete mess IMHO!

One way to address this issue is to embrace the generalizing specialist approach. If nothing else, in the long run, these folks would become great assets to the company.

But if you don’t want to go down the generalizing specialist route, and you have people in silos with deep pockets of knowledge/skill, can planning poker work? After trying it for 3-4 years, I did not seen it working. But you should certainly give it an honest try. After all, <sarcasm>its the industry best practice.</sarcasm>

The other argument I often hear in favor of planning poker is that when the teams are doing this, they learn so much from each other. I agree 100% to this observation. Certainly getting a group of people together and asking them to estimate (commit) to something, gets them to talk to each other, share their view points and it leads to knowledge sharing. IMHO knowledge sharing is extremely important. Why not have focused meeting for just knowledge sharing? Brown-bag sessions, show-n-tell sessions, code-walk-thrus, idea-fest, scratch your personal itch days, refactoring-fest and many more. Why morph something so important under the estimation/planning meeting banner, where the priorities are different? People don’t go into a planning session saying “Wow, today all of us are going to learn something new.”

Also I would suggest reading my blog on: Story Points and Velocity: Recipe for Disaster.

Agile Coach Camp is an Unconference for Agile Coaches, Scrum Masters, Agile Trainers, Leaders, Change Agents and Mentors.

We are pleased to invite you

The art of coaching teams toward excellence and productivity is tricky business. We often don’t have direct control over groups but have responsibilities to motivate team members who don’t report to us. Too often, as coaches, we work in isolation from other expert coaches in the field. This is our opportunity to share stories and practices and to wrestle with the direction in which this discipline is going, or should go.

Growing a Community of Practice

Agile Coach Camp is about creating a network of practitioners who are striving to push the limits in guiding software development teams, while staying true to the values and principles at the core of the Agile movement. We’ve invited practitioners who, like you, are passionate about their work, active in the field and willing to share what they’ve learned. It’s a great chance to form relationships that can last a lifetime (and act as a lifeline).

Do you have a technique or practice worth sharing with your peers? Or an idea you’d like to test out with some leaders in the community? Are you facing challenges and want to get some perspective from other practitioners, or hear how they do things? If you feel you would benefit from connecting with 80-100 like-minded peers to talk, draw, argue and explore ideas, then this unconference is for you.

Spread the Word

Twitter Hashtag: #accin
LinkedIn Event: http://linkd.in/My2BJ1

Identifying the right pilot project is an extremely important first step towards your Agile transformation journey.

While selecting a pilot project, I generally look for the following characteristics:

• Importance: We don’t want to start with a project, which could shut down your business if things went wild. Nor do we want to pick a small pet project. Even if we proved Agile works well, it won’t appeal to the organization as it won’t be representative nor credible. A critical project with high-enough stakes is ideal.
• Dependencies: Fairly self-contained projects with minimum external dependencies are relatively easier for introducing change. If the team does not have the necessary skill or authority to take decision or if most of the project’s attributes are outside the organization’s control, it would be a very difficult pilot project.
• Stakeholder Engagement: Access to all the stakeholders is critical. Their involvement and buy-in is extremely important to make any sustainable change.
• Top-Management Support: During the transition, the team will run into many roadblocks and challenges. Having a good management support and backing will motivate the team to creatively solve those problems.
• Duration: To effectively capitalize on the learning and excitement, it’s important for the pilot project to be between 4-9 months.
• Size: A single collocated team with less than 10 members is an ideal size to coach. Gradually we can grow this team to large multi-site geographically distributed team/s.
• Stage: If the project was already in a fire-fighting mode, the team members would be under too much pressure to try anything different. If it’s a laid-back large maintenance project, team members might not have the motivation to change large legacy system. Project in its early stages with most of its team members on-board, seems to be a good stage to introduce Agile and Lean thinking.
• Team Composition: Most successful organizations have strong (vocal) leaders or connectors at the grass-root level. If we can influence these folks early on, they can be our internal change-agents. Hence while picking a pilot project, we consider their density in the pilot team.

Identifying a project with all these characteristics would be ideal, but is rarely the case. A good coach knows how to make reasonable trade-offs.

How do you measure or know the effectiveness of a Scrum Master?

IMHO on a given team, in less than 6 months, an effective Scrum Master will:

• make themselves redundant
• make process second-nature for the team

That would be the true test for their effectiveness.

In the mean time, I would look for:

• Has the SM been able to win the team’s trust and build credibility with the team? Does the team see the SM as an integral part of the team?
• Apart from effectively facilitating (not enforcing) the Scrum ceremonies, is the SM helping the team understand the rationale behind those ceremonies?
• Is the SM creating a culture of safe-fail experimentation where the team can experiment, learn and grow beyond the standard Scrum ceremonies? If the team is not evolving their practices and work culture, is the SM really doing their job?
• Does the SM encourage System’s Thinking and uses techniques like Value Stream Maps, Five Whys, A3, etc. to identify & highlighting bottlenecks in the team?
• Has the SM been successful at creating Self-Organized Empowered Team? Or is the team waiting for directions from the SM?
• Is the SM able to emerge as a leaders and be the voice of the team, shielding the team from external interferences, yet creating a healthy collaborative culture?
• Is the SM able to motivate the team and steer them towards excellence?
• Is the SM abel to put a framework in place for the team to record and surface important and relevant data about the team’s performance? Using techniques like information radiators to build informative workspaces. Basically enabling the team to get food for improvement.
• Is the SM proactive (instead of reactive) about resolving issues?
• Is the SM approachable? Believes in servant-leadership?
• Does your SM have first-hand experience working in Scrum teams? Extremely knowledgeable about processes?
• Is the SM up-to-date with the latest trends in the industry? Keen learner and open-minded?

Often companies undervalue the part-time coaching model.

What do I mean by part-time coaching model?
A coach is onsite, working hands-on with the team for a week and then offsite (accessible via email & phone, but off the project) for a week. Basically, the coach is available on-off either alternative weeks or a some other timeframe.

Personally I’ve experience the following advantages of a part-time coaching model:

From the company & its employees’ point of view:

• When I’m not there full time, teams realize they cannot fully depend on me. I’m not the bottleneck for making decisions. The teams start to take ownership and make more decisions on their own (usually by consulting me, but not waiting on me.)
• When I steps out for sometime and come back to the team, I bring a slightly fresh perspective and can pay attention to weak signals. Many times we get so engrossed in what we are doing, that we might miss out paying attention to something else.
• Coaching can be intense. Having a little time off from coaching helps the teams get a breather. Which makes the overall coaching more sustainable.
• As coaches we expect things to change much faster rate than usually they do. If we are there full-time, it might start to bother us. But with the on-off model, the slower rate of change seems more acceptable. Similarly the team does not feel pressurized to accept change at a rate that might not be sustainable or acceptable to them.
• The management seems to get more confidence in the whole engagement, because they can see things are not blowing up when the coach is not around.
• Last but not the least, it does have a good financial incentive for the company.

From the coach’s point of view:

• Having some downtime is good for the coach to build/upgrade their skills.
• Can help achieve a better work-life balance.
• From a risk management point of view, it allows a coach to take on multiple part-time client.

Hopefully, all of this leads to a more effective coaching engagement.

At the SDTConf, we had an interesting discussion on how to deal with technical debt. The group agreed on the following suggestions:

• C3: Coverage, Complexity & Churn – Instead of looking at each of these parameters in isolation, we generate C3 graph using a TreeMap and use the cumulative graph to see red spots in the product. Esp. helpful to quickly raise awareness.
   
• Slack: Every team members gets a 10-20% time every iteration to invest on things that hurt them.
• Scratch your Personal Itch day: Every iteration each team members gets 1 day to fix unplanned issues on the project
• Visitor from Hell: Every month have one person from other team visit you and give you feedback on various aspect of the team. Its up to the team to address these issues or not. But certainly can be used to pitch to the management for additional time to work on these issue.
• Code Walk Throughs: Every time a team member (or pair) implements something important, they give a code walk through or a demo to the rest of the team. This usually ensures team members don’t have crappy things when they give a demo.

Check out the project rescue report, if you would like to see some examples of how we’ve used C3.