There’s significant value in a demo at the end of the iteration.

1. The demo shows the team what they have done and not done in the iteration.
2. The demo shows the product owner/customer what they have done and not done.
3. 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

Tweet This Post

1. 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.)
2. You also need to know what your release criteria are–when is the product good enough to release?
3. 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

A story isn’t done until it is being used by real users in production and has been validated to be a useful part of a product.

I have trouble with this definition:

• The development team is dependent on other people getting the product out to the users, especially in the case of shrink-wrap, or a hard product. The development team cannot deploy the product alone. (Rarely can a development team deploy a product alone, but it’s possible with SaaS. It’s not probable! For other products, you need a program team or some other mechanism to make sure the marketing is done, the bill of materials is created, etc. Deployment is almost always separate from development. I’ll blog later about whether it should be.) Just as release criteria need to be under the team’s control, the definition of done needs to be something the team can accomplish.
• The development team is dependent on the users actually using the product. To me, this violates the separation of what to build (from the product owner or customer) and the how to build it (from the development team). There is one person, a product owner or customer talking to the team. Yes, that person needs to know what real users will use. And, I don’t see how a team could talk to a gaggle of users and know what to build. The organization’s strategy is part of what to build.
• It’s possible that you would have an entire release of product waiting for “done.” Features would be some sort of done, but not all the way done, because the users had not used the product and validated it. This violates–for me–the notion of being done for now, but having demonstrable, releaseable product at the end of an iteration or when a card is marked done.

I see that the feedback from real users is helpful, maybe even necessary. I’ve been on projects where I certainly would have liked the feedback earlier than at release. Maybe the real value of this definition is to jiggle us into thinking about how to get feedback from users earlier, in the same way as in How Short Can Your Iterations Be? Thinking and rethinking about what done means (or how long your iterations are) to reduce waste in the project and deliver a useful product is a good thing.

I still have trouble with done not being under control of the development team. If a user or user surrogate has explained what he/she wants, and the development team has implemented it, and that person has seen a demo or used it, I have to believe the feature is done.

I’m not convinced that expanding the definition of done helps a project team. It does help us think of the obstacles that prevent us from obtaining feedback as early as a feature is complete. I’m still going with the idea that done needs to be under the control of the development team.

Tweet This Post

Tweet This Post

We’re working through the issues of large programs and architecture, and, of course, we have encountered the develop by component vs. develop by feature debate. I’m closer to the develop by feature side of the house than Rebecca. She’s a little closer to the develop by component side. We’re not too far apart–we’re not polar–we’re not precisely at the same place. And, we may never be at the same place, because our experiences are different. We each have good reasons.

You get tremendous benefits when you develop by component: high cohesion in the component and low coupling between components. Don’t underestimate the value of these. If you don’t pay attention to cohesion and coupling, eventually you can’t develop anything.

When you develop by feature, you get features. It’s hard to underestimate the value of working product.

But especially in a large system effort, with multiple teams, how do you do this right? Of course, it depends. You might have a combination of teams, in my preference after you have a little experience with some features. Maybe you develop some prototypes. Maybe you do something else.

We’re developing a simulation for the workshop. If you have encountered this problem in your system, please post a comment and let me know if you would like a simulation to explore this. (I am not under the impression this means you would commit to our workshop!) If you’d like to send me private email, that’s great too. We’re trying to develop a simulation that will mimic what happens at work.

Tweet This Post

Tweet This Post

A program is a collection of projects, where the value is in the overall deliverable. Yes, each project may have a deliverable that’s valuable, but the value to the organization is when all the sub-projects get together and deliver their product. Here’s an example. Think of a cell phone. One sub-project might be the team(s) who create the features that allow the phone to make a call. There may be another sub-project for the features to answer calls. Another sub-project could be the features to manage/interface with voicemail. Another sub-project is the minute counting for administration/billing purposes. The texting features would be another  sub-project.

Each of these sub-projects have teams that are as large as they need to be. So, to answer Veretax and André’s questions: yes, working in smaller teams so each team can be agile does work. Yes, each sub-project works in parallel. The teams for sub-projects work in parallel. When I think of these sub-projects for a program, eacah sub-project has its own rhythm and staff and backlog. That’s why the program needs an overall backlog, because the sub-projects may have interdependencies and may uncover program risks as the program proceeds. In the example of a cell phone, you might not want to start the voicemail until after you know the phone can receive calls. Maybe you can, because maybe there’s a platform that supplies the services your project needs. What happens if you realize you need to change the minute-counting after the call-placing features are done, but before the billing features are complete? You work it out.

But the idea is that you have a program: deliver a cell phone. Each of the sub-projects has its own list of features and each of the sub-projects delivers a valuable result. But, you don’t have a cell phone unless you can make and receive calls and get voice mail. You may need more than that, but you don’t have a product that can succeed in the market without those minimum requirements.

Now, for the why we need program management. I’ve seen (and I bet you have too) programs where the software was all done except for one small piece. Or the software was done but the marketing was not. Or the hardware was done, the marketing was done, and the software was going nowhere. If you have agile approaches to programs, you get to see visible progress (or lack thereof) at the end of each iteration. You don’t have to wait until the predicted or desired end of the program to see the risk.

That’s one of the ways agile reduces technical and schedule risk. The iterations help you get to done across the entire program each iteration and help you see how things fit together. The demo at the end of an iteration shows you where you have technical risk, which reduces schedule risk. In general, incremental approaches reduce schedule risk and iterative approaches reduce technical risk. Because agile combines both, you reduce both kinds of risk. (For more detail on lifecycles, see Manage It!)

Stephan also asked how agile program management differs from “plain” program management. In non-agile program management, managers of sub-projects speak for their functional area, commit people, manage risks, and commit other resources. Notice that there is no program-specific view of the product or transparent coordination across the functional teams. There is not necessarily a ranked product backlog. You could have those things in a “plain” program. I haven’t seen them, but maybe that’s how your program management works.

In agile program management, you have coordination across the cross-functional teams. That’s a huge difference. You don’t have functional managers, you need cross-functional project managers (of some stripe) for each sub-project, and one for the program. Managers don’t commit; teams commit. The program team is all about managing the backlog and risks, the business value of the architecture, and the obstacles for the program.

In case you’re not sure, I’m starting to write the agile program management book, so you nice folks are hearing about this as I try to articulate it. Thank you for your comments.

Tweet This Post

Now, you might say that we should not even try to do programs of 300 people. That 300 people are too many and it’s too difficult to manage their interactions. And, besides, they can’t know each other. Well, they don’t all work together. And, if you have a large product and you want to finish it in a year or less, you may need that many people. Several of my clients do want to complete large product releases in a short time and use agile, because agile reduces many of the technical and schedule risks. And I want to help them be successful.

Here’s what I know about agile program management:

1. You must pay attention to architecture, not just from the beginning, but all the way through the program.
2. If you try to define the architecture up front, you will be wrong. And, you will discover you are wrong after the predicted middle of the program. If you are really unlucky, you will discover this when things start to break near the end.
3. If you have more than one product backlog, everyone will be confused.
4. If you try to mix up the teams, you can no longer predict any velocity. Remember, velocity is personal to a team. Teams will be consistent in themselves, but once you’ve changed the team, the velocity may well change.

These ideas lead me to say that in programs, you need to address architecture throughout the program, that you need one product backlog for the entire program, and that teams need to be relatively static. None of this is easy. I’ll be sharing the guidelines I develop as I see them.

Tweet This Post

With a simulation, you create a safe environment in which people can experiment with learning a new skill or seeing how they operate. There are two critical pieces to the simulation:

1. Creating a safe environment in which people can work. No one can learn if they feel unsafe.
2. Debriefing the simulation. If you don’t debrief, you can’t tell what you learned.

There are more pieces, but the setup for safety and the debrief are critical.

What I love about simulation-based training is that people are never wrong. Whatever happens in the simulation reflects their reality. Because people recreate their behaviors in the simulation, they (and the instructor!) get immediate feedback on what happens in their work lives.

If you want to consider experiential learning, that’s what I do at conferences, when I lead tutorials. The AYE conference is all experiential learning. (The current discounted registration of $1500 expires July 1.) My workshops are all experiential learning.

If you are trying to learn something without practicing, stop it. Fire the instructor. Do that kind of work in practice, preferably in a simulation, so you can learn from it.

Tweet This Post