Some teams don’t do demos at the end of their iterations. Many of the teams who don’t do demos also have trouble finishing all the stories they committed to at the beginning of the iteration. They continue, iteration to iteration, not always finishing, not getting to releaseable at the end of the iteration. And, sometimes, these teams don’t do retrospectives because they are not done.
There’s significant value in a demo at the end of the iteration.
- The demo shows the team what they have done and not done in the iteration.
- The demo shows the product owner/customer what they have done and not done.
- The demo acts a a milestone–the team has to stop what they are doing to show the demo. They can’t keep going without doing a demo.
If you’re not demoing at the end of an iteration, reconsider. Use the demo to get feedback, record your velocity, and see if you are done enough with this project for now, or if you really need to continue working off this backlog.
Tweet This Post
August 31, 2010 02:34 PM
One of the most powerful things you can do to help someone solve a problem is to ask great questions. My new article “Questions to Explore Problems” (PDF) gives dozens of questions that I’ve found essential in my work as a coach, including questions to explore:
- The problem in general.
- The desired state, the perceived state, and the difference between the two.
- The way the problem is stated.
- The problem’s past, present, and future.
- The way the problem is being solved.
- The way you are exploring the problem.
August 30, 2010 07:37 PM
I co-presented three sessions at Agile 2010. The materials for these sessions are now available:
I hope you enjoyed the session or get some useful ideas from the session materials. Let us know how you’ve applied these tools.
August 29, 2010 07:53 PM
I have been delinquent for those of you who subscribe to my email newsletter. I have not published one since April. On the other hand, I just posted Park Projects You Can’t Staff, For Now. The next newsletter is scheduled for Thursday morning. In case you’re wondering, I post the most immediate past newsletter when I queue one up for sending. If you decide to subscribe, you can rest assured I will not bombard you with email!
Tweet This Post
August 25, 2010 10:02 PM
Last week at Agile 2010, Joshua Kerievsky and I facilitated an Open Jam session (open space) about what done means. We discussed a variety of points. I believe we eventually agreed that context matters.
- It’s important to know what your product success criteria are. If you don’t use a project charter where you define success criteria, consider doing so. (Yes, in Manage It!, I have a discussion on what success means. I have downloadable templates too.)
- You also need to know what your release criteria are–when is the product good enough to release?
- Do you have a product that can be continuously deployed, or does it need to be deployed discretely?
Success criteria are not the same as release criteria. You may decide to release something now, to get some feedback from some customers, even if it doesn’t meet the product success criteria. Your success criteria might be about the process, not the product.
For products that can be continuously deployed, you can obtain customer feedback, so you can consider an approach that says done isn’t done until customers accept it. I didn’t ask then, but I will ask now: what happens if some of your customers really like the feature and some don’t? What do you do? (The benefits of sleep :-) Which customers do you listen to?
For products that don’t lend themselves to continuous deployment, you have some options:
- Make sure you have iteration goals. For each feature on the backlog, before you start it, ask “How does this feature move us closer to our project release criteria and product success criteria?”
- If you don’t have iteration goals (you may be using kanban) ask, “How does this feature move us closer to our project release criteria and product success criteria?”
- At the end of an iteration, or periodically if you’re using kanban, ask “How are we progressing towards our release and success criteria?”
If you have someone grooming the backlog, I would assume that person is asking those questions. However, we all know about assumptions. Maybe making the assumptions explicit is the right thing to do.
A holistic approach to a product is a good thing. If you can work with your customers, that’s great. And, many of us work on products where we either don’t have customers yet (we’re creating a market or we want to be quiet for a while to manage the competition risks), or where we cannot do continuous deployment. Thinking about done for the feature makes sense then.
I still want someone guiding the product, who is not a technical person. That person would ask the question about moving the product forward to our criteria. That person knows when there is more business value to create and when we have enough for now.
For me, done is still feature-based. Maybe some of you think I draw the circle too narrowly around the project. Maybe I do. But I still meet agile (!) teams who say, “We finish a feature and hand it to QA.” Sorry, to me that’s not done. Until I see more teams taking a holistic approach within the technical work to finish a feature, I want team members to know when they are done and when they are not.
Tweet This Post
August 18, 2010 02:35 PM
