The Regenerate Web

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.

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

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

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.

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

Josh Kerievsky has an intriguing post about Redefining Done. The idea is that a story is not done until:

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

I learned this week that I made the Top Women in Business Blogging list. They tell me my readers nominated me. Dear readers, thank you!
Online MBA Rankings

Tweet This Post

I’ve been working with Rebecca Wirfs-Brock on an agile architecture workshop. I’m working with Rebecca because she has such a depth of experience in architecture, as well as design. She’s working with me because of my project and program management experience. We’re pretty psyched.

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

I’m proud and pleased to be on the list of LiquidPlanner’s Top Project Management Thinkers. I’m thrilled, too!

Tweet This Post

It’s a good thing I said my post about musings was just that–musings! I didn’t bring all of you along. Sorry about that. Let me be more clear.

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

I’ve been working with organizations who want to move their programs to agile. They’ve been successful with small projects. But now, they want to make agile work with large programs, programs that involve hardware or firmware, programs with many pieces of interdependent software features, programs of 50 to 300 (or more!) people.

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

In June, I taught PSL with Esther and Jerry. We had a blast. So did the participants. Part of why PSL is so much fun is that we use simulations.

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

My column at Gantthead, The Agile Project Manager: To Facilitate, Serve and Protect is posted. Enjoy!

Tweet This Post

A twitter follower asked if I could provide a link to a “discussion of tactical vs strategic planning/projects?” Here you go:

Strategic work is a management role. It involves setting the direction for the organization (or group), deciding what to do and what not to do, who to hire and when. If it involves committing the organization to money in some way, that’s strategic work. Here are some examples (not an exhaustive list): managing the project portfolio, deciding on a product line, deciding when to hire which kinds of people, deciding on a software process initiative.

Project management is mostly tactical, the operational approach to the day-to-day decisions. The one exception is at the beginning of the project, when you decide on release criteria and a life cycle. When you decide on release criteria, you have defined the boundaries of this release, a strategic decision. When you decide on a life cycle, that’s a strategic approach to how you use the people. The rest of a project or a program is tactical. Looking for and managing risks? Tactical. Understanding how people are working together–or not? Tactical. Conducting a meeting? Tactical. Problem-solving? In the context of a project, tactical.

There’s also work that requires tactical time, and is strategic management work. For example: one-on-ones, feedback, coaching, career development/discussion, working across the organization to smooth the way for a project, solve other problems, or accomplish something that managers needs to do, such as collaborating on the project portfolio. This is the day-to-day work of a manager, which makes it tactical. It’s strategic in nature, because it builds culture, retains people, builds a trusting relationship with people across the organization, and implements the mission. I can never tell if this is strategic or tactical.

Strategic work is difficult. It requires thought and discussion. Tactical work is difficult in a different way. Tactical work often demands answers quickly. Strategic work, assuming you don’t postpone it and create management debt should take longer because reflection is a good thing for strategic work.

So when I said in Functional Managers Acting as Scrum Masters: Not a Good Idea that Scrum Masters will do the tactical work postpone the strategic work, I meant that the Scrum Master will conduct the stand-ups, will facilitate the demo, review, and retrospective (maybe not personally), and remove obstacles for the team. That mean no one is thinking about or performing the management work, such as managing the project portfolio or conducting one-on-ones, or solving problems in advance of the team, if the Scrum Master is also the manager.

Let me know if this is not helpful.

Tweet This Post

I often meet people who are transitioning to agile, and they decided to pick Scrum, because it’s a helpful project management framework. Ok, that makes sense. But then they decide that they no longer need project managers, and that the development manager can act as the Scrum Master.

The Scrum Master is not a management position. The Scrum Master protects the team’s process and removes the team’s obstacles. For me, the Scrum Master is analogous to the project manager. (I’ve never believed in command-and-control PMs.)

There is still a need for managers, but a little differently.  I don’t see the need for functional managers. The agile team needs a manager who champions that whole team. That means that the champion managers need to understand all the functional parts in the team, so they can help each team member.

But the real issue is that it’s a bad idea to have a manager be a Scrum Master. Here’s why:

1. The Scrum Master is a part of the team, and the manager, because of his/her titular authority can never be a part of the team.
2. People are reluctant to take a risk in front of their managers. (Bob Sutton in Weird Ideas That Work: How to Build a Creative Company cites data about this.)
3. Managers set direction, which is more strategic work. They do this with managing the project portfolio, looking at the makeup of the teams, seeing if they need more people. Scrum Master work is tactical, about the day-to-day work of the project team. If you have to choose between strategic work and tactical work, which one will win? (Tactical, all the time.)

So what does happen to the managers when an organization transitions to agile? They help teams self-organize. They manage the project portfolio. They provide feedback and coaching. They champion the team. They take the lead on hiring.

Managers, do your management job. Project teams, including the Scrum Master, do your project work. The two types of work intersect above the project, not in it.

Tweet This Post

The people who are organizing Your Team Needs Women have a good idea–diversity in teams. I have a problem with how they are doing it.

I have tried to contribute to the agile community, chairing the Agile 2009 conference, speaking at user groups, writing for a number of outlets, working with my clients. I do those things because I love my work. I don’t do them because I’m female. I provide a type of diversity, more because of my age and experience than my gender.

How many people in this field have been developers and testers? That’s a type of diversity I offer. As well as managing projects and programs. I’ve developed hardware/software projects and programs. Too few people have that type of work diversity.

Gender diversity is an obvious diversity. It’s not the most useful diversity. Personality diversity is even more important. (I described why in Hiring the Best…) The nomination even calls it out a little, in the sections about “support, promote and encourage” and empathy.

And, with what I read of the nomination, I am concerned that the nominations are looking for nurturing women. I hope not. I nurture my family, not my colleagues. I’m only my daughters’ mother. I’m not anyone else’s mother.

For me, this would be a fabulous award for *anyone*, not just women. In fact, showcasing men as empathic beings might bring more women into the field, but I doubt it.

The problem is that we need to talk to women when they are teenagers, not when they are in their 20′s, 30′s, 40′s. When we help teenagers think about technology careers, that’s when we can get more women in the field.

Don’t get me wrong. I love recognition of people’s achievements. I was thrilled when Manage It! won a Jolt productivity award, and I still am thrilled. That award was for a book, not a woman-authored book.The playing field was open.

I would love to see this award open to every gender, not just women. When you take most of the constituency out of the equation, the award means less.

Do I think we need more women in software? Yes. Do I think this award will help? No. I’m not offended; I’m disappointed.

If we really want more women in software, some of us women must put on nice clothes and talk to the middle-schoolers, high schoolers, and maybe freshman and sophomores in university. That’s how we influence women to join the field. I volunteer for that.

Don’t just look for women. Don’t award or recognize just women. Look for people with a variety of work experience, life experience, and most importantly, personality diversity. That’s how you get a great agile team.

Tweet This Post

I have a new Stickyminds.com column up: Transitioning to Agile Testing. Enjoy!

Tweet This Post