Establishing an upfront, common understanding of “done” that suits the unique dynamics of each development project can be one of the most critical activities for Agile teams. With a consistent meaning of done, agreed to by the whole team, velocity or throughput becomes more stable – allowing your team to make and meet commitments, establish priorities and plan iterations.
We recently hosted a webinar entitled “Defining Done: Creating Velocity without Debt,” to discuss how a common definition of done lays the foundation for focusing on business value while avoiding technical debt. Although we enlisted Rally’s expert coaches to answer the hundreds of questions that pored in from over 2,200 people around the world who joined in, we wanted to spend some more time providing in-depth answers to a few of the questions we received. Below is a video with answers to some of the tough questions about the definition of done:
I also put together a presentation that goes into more depth about what your team can learn from burndown charts.
We hope these resources help you come up with a definition of done that suits your unique team and project. Have more questions? Feel free to post them in the comments section below – we’re always thrilled to continue these discussions with the Agile community.
Zach Nies is a CTO at Rally Software and a proud member of the Boulder/Denver Agile community for the last ten years.
This is a story of how I went from being the poster child for bad posting etiquette on pm.stackexchange.com to becoming their poster child for fast learner! A poignant tale of hubris, struggle, fear, benevolent mentorship, and redemption.
Prequel: The Lure
Some colleagues of mine at Rally Software (Karl Scotland, Ken Clyne, Eric Willeke, Ben Carey, and Ryan Martens) have been telling me about how much they were enjoying their experiences in StackExchange. My CTO colleagues Zach Nies and Mark Gammon have also been enthusiastic about the value of being engaged in the StackExchange community. But I was intimidated. I feared I wouldn’t know how to appropriately engage in either asking a question or answering a question. It turns out my fears were well-founded.
Scene 1: The Leap
I finally decided to jump in. I set-up an account, fairly easy to do. I perused some of the questions already posted by others. I saw the tags and the replies. I saw the voting. Somewhat intimidating. But, I had a topic I was really excited about. I thought it would make a great question. And so I made the leap; I took the plunge. And this is what was wrought:
Scene 2: The Faux Pas
Not a bad question. The problem was that in the text area below the question title, I gave further detail on the question. A lot of detail. I pulled a major faux pas: I waxed poetic on what I thought the answer was. (I’m not going to go into the topic here. Trust me. It was lengthy and unyielding. :-(
Fortunately for me, however, very timely and gentle advice appeared from Mark Phillips and jmort253:
Could they have been any nicer? What a great community!
Scene 3: Meeting with the masters
The good news is that help was on its way. Back in March, we’d spoken with Joel Spolsky (co-founder and CEO of StackExchange.) Ryan’s goal in talking with Joel was to look at how we at Rally could incorporate StackExchange into our upcoming RallyOn conference in May. How could we work together to create community in StackExchange as we were creating community in the conference?
The result? We brought in the great StackExchange masters Anna Lear and Mark Phillips to the RallyOn conference. In his opening remarks at the conference, Ryan introduced our two Zen StackExchange masters and Ryan’s hope for how we could all engage with them to kick start a powerful presence of the Agile community within StackExchange.
Yea! I was going to actually be able to work with Mark and Anna to become more comfortable and more productive in StackExchange!
Scene 4 : Lessons Learned
After Mark held a small session on getting started in StackExchange, I saw him in the hallway. I’d missed the session, but he quickly filled me in. It turned out, he’d used MY question/answer fumble as an example of how NOT to engage in StackExchange. I had become the poster child for bad StackExchange etiquette :-(
But both Anna and Mark quickly took my under their wing. We edited my original question. We commented on one of the answers. We created a new question. And we answered another question. The result was a new exchange of comments:
I continue to stay engaged asking and answering questions. I’ve learned to keep my questions short, my comments short, and my answers short. And, I’m gaining reputation points and earning badges, still with gentle guidance from Anna, Mark and “jmort253″.
My Rally colleagues continue to post as well. It is exciting to see the Agile community begin to expand in pm.stackexchange.com. Provocative questions with great answers. And through the tags, we can watch the expansion into other topic areas.
For the happiest ending of all, I’m saving the best for last: my email yesterday from StackExchange!
“Congratulations — you are one of the top new Project Management – Stack Exchange users for the month of May 2011! http://stackexchange.com/leagues/month/pm/2011-05-01 ” There was also the caveat that my name would not appear in the list of users because I still need to earn more reputation points. Okay, June, you are going down!
Help keep the story alive!
To wrap things up: I not only survived jumping into StackExchange; I love it. I’m hooked. So, my story is not over.
Now, I’d love your reply to this post to tell me how you are getting involved in StackExchange.
Jean Tabaka is an intrepid intercontinental traveller, a 6-badge holder in pm.stackexchange.com, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka
Several weeks ago, in an interview with Dave West of Forrester Research, Dave posed a provocative question to me.
“Do you have to be smart to do Agile?”
In retrospect, Dave’s question reminded me of an old joke: “Have you stopped beating your wife?“ In this “deeply philosophical” question, there is really no good answer. “Yes” looks bad; “No” looks worse. Answering the question about Agile and smartness could be the same. For me to answer “Yes” could be interpreted as, “Gee of course; look how brilliant I am!” To answer “No” could be interpreted as, “Gee of course not! Look at me! I’m as dumb as a doorknob!“
All jokes aside, I answered “No,” to Dave’s question and here is why.
The real question is not about individuals. The real question is, “Do Agile TEAMS have to be smart?” And to that question, I would answer “Yes.“
Agile relies on the collective wisdom of the team, not on the brilliance of one individual. I learned a lot about this, not just in my research of Katzenbach and Smith’s The Wisdom of Teams. I also have experienced it in the variety of teams in which I have worked and with the teams I have mentored. High team E.Q. (emotional quotient) is what makes Agile really hum. In fact, high team collaboration, their ability to invite and manage conflict, and their ability to create consensus, actually is the fiber that weaves the cloth of a high-performance team. High-performance teams have a collective high goal for which they hold themselves mutually accountable. It is about the team and its commitment to one another and their goal.
So, back to our title math question.
7 + 2 = 5 if your team mistakes collaboration as working in a “dumb down” or “group think” mode. That is not the intent of Agile collaboration or consensus. We’re an Agile team because we intend to increase our collective wisdom.
7 +2 = 9if you are not gathering all the insights of all the team members to inform your decisions in your work. You are not quite yet truly Agile.
7 + 2 = 11 is where the collective wisdom of the Agile team raises its team I.Q. That is, the Agile whole team is indeed greater than the sum of its parts. And besides, as Spinal Tap says, it’s great to, “Go to 11!”
RallyDev.com
