Some product owners don't want to address technical debt. They only want to add features to a product or system. And that's a huge problem.

The product owner has the responsibility for value of the entire system. That means that the product owner has to address features, technical debt, defects, whatever needs to be ranked so that the team knows what to do when. If the product owner does not rank the technical debt and the existing defects in addition to the features, the team will have trouble sooner or later delivering features.

So what's a team to do?

1. It's time for a heart-to-heart talk with the product owner. The product owner first needs to know that it is his/her job to rank everything for the iteration. It's possible he or she does not know.
2. If you are not tracking velocity, start. Remember, velocity is a trend, and will help your product owner see what is going on. Because your velocity will go down as your technical debt goes up, and your product owner needs to know that now.
3. If you are not tracking the number of defects found and fixed in an iteration, start now. Make this a trend, not a number. Trends are what's important. 
4. Consider tracking Fault Feedback Ratio, the number of bad fixes to total fixes as a trend on an iteration basis. This tells you if the developers and testers are making progress or spinning their wheels.
5. Make fixing technical debt a part of each feature. I don't understand how anyone can prevent you from doing this. I do understand how insufficient estimation can prevent initial test automation. But a team has the ability to say, "Wait a minute, we are not really done." 

Remember, the team has a the "done" card. If a team wants to play the done card and define what done means, and swarm around a story, making sure that they have prevented technical debt from accumulating, they can. I'm not talking about gold-plating, adding more features. I am talking about code review, architectural review, test development at all levels, whatever you need to know that the code works.

Not fixing technical debt is behavior you want to prevent, or stop early. But, if you can't stop it early, make sure the product owner sees the reality of his or her decisions. This is why short iterations are such a good idea. Your product owner might even have a good reason for his or her feature-itis. But if they acknowledge the reason for the feature-itis and explain when it will end, the team has a shot of retaining its sanity.

The more features a team adds without address technical debt or defects, the more technical debt a team adds. And, that's not acceptable, regardless of your lifecycle.

Project Charters are a way to initiate projects. Sometimes charters are text documents. Sometimes charters are boxes or brochures that "sell" the product's benefits and features to others.

I like text documents as a first draft because they are easy, and are a fast way to bring a team together that has not worked together before. Once a team has worked together, try a box or a brochure. But if you're new, consider a text document.

Especially if you're new to project charters, take a minimalist approach. I like to think, "What's the minimum I can put into this project charter and still make it be enough for this project?" I offer a project charter from Manage It! Your Guide to Modern, Pragmatic Project Management. That charter has these parts:

1. Vision: Concise and compelling idea behind the project
2. Drivers, Constraints, and Floats: What's driving the project, what's constraining the project, and where you have freedom to organize the project as you need.
3. Goals: What you might want to accomplish with the project, but not required that you do so
4. Success Criteria: Capabilities your product will have at the end of the project
5. ROI Estimate: Potential return from your project (only if your organization requires it)

Write your vision with the project team. That way, you can make the project vision compelling to the entire team. If everyone starts yawning as they start writing, you know nothing about the vision is compelling! Ask them, "What do we have to do to make this vision compelling?" Maybe they need to start with objectives, not the vision. That's fine.

When you think about drivers, constraints, and floats, do not think of the iron triangle. There are more than three sides to the iron triangle. You need to consider the organizational constraints: cost, people and their capabilities, technical debt, and the environment of the project. And, you need to consider the specifics of this project: the desired release date, the desired feature set, and the desired defect levels. Only by balancing what's honestly driving the project, what's really constraining the project, and what's really in your degrees of freedom can you make decisions about the project. You might need a project driver matrix to make those decisions.

The team may want some goals for this project, that are separate from the organization's requirements. I often see this when teams want to start paying down some technical debt. "We want to automate 10% of our regression tests."

Success criteria are the capabilities the product will have once the system is done. Knowing what success looks like is a tricky definition. You'll probably use context free questions to define success.

ROI, return on investment is something few of us have to calculate, but if you do, the project charter is the place to put it. Of course, you'll be wrong, but that's ok. (You'll be wrong because it's a prediction based on what the project will cost and how many people will use your results. You cannot know the future! If you do, please go gamble in Vegas.)

The value of the charter is not so much in the text, but in the discussions to create it. Your discussions as a project manager with the team, the team's discussions among itself, the team's discussions with senior management, anyone's discussions about the project driver matrix. The discussions create an atmosphere of teamwork, and create the agreements so people can start.

You may decide that you need a cross between a project charter and a project plan. That's fine. Maybe all you need is a project vision and release criteria. For me, that's the absolute minimum that any project needs. You know where you are going and you know what done means.

The project charter gives you one small way to build a team. Try it.

At Agile 2011 last week, we were treated to three wonderful keynotes, aside from over 260 sessions.

The first, on Tuesday morning was about positive emotions by Barbara Frederickson. I was afraid it was going to be one of those "be happy" nonsense things, but it wasn't. She discussed how to stay happy, and it was about challenging yourself, and learning how to have emotional resilience, something I'm quite interested in, and will be discussing in more detail on my createadaptablelife blog sometime in the next few weeks. I bought her book and will be reading it because I really liked her presentation. Her presentation is mostly pictures.

The second was entitled "Code" and delivered by Kevlin Henney. I hadn't heard of him, because I'm a management geek. Well, if you have not heard of him, go seek him out, find his presentation. He showed pictures of code. Yes, pictures! Aside from cute things you can do with code, one of the best analysis tools I saw was using wordle as a static analysis tool, to see what kinds of domain knowledge you have built into your code. Is that cool or what? Way cool.

But the best and last, was Linda Rising's keynote called, "The Power of an Agile Mindset." I should tell you, Linda and I are friends, as well as colleagues. I've known Linda for years, and volunteered as a shepherd on the Insights stage that she co-chaired for the conference.

 Linda discussed the fixed mindset where we go for perfection and get stuck if we don't achieve it versus the agile mindset where we adapt if discover a challenge and we try harder.

And, then came the zinger. As a society, we encourage smart little girls towards perfection in elementary school. We encourage little boys towards challenge. So, by the time we all get towards middle school/junior high, little girls do not want to fail. They don't want the challenge. They want perfection. All their lives they have been praised for perfection. How can they stop now? And boys? Why should they want perfection? All their lives they have been praised for rising to the challenge. Why should get all As? Why should they want the grades when they can find a bigger challenge?

This explains so much about why girls gravitate towards classes they can do well in, and why boys take classes they find a challenge--as a generalization. There will always be girls like me who rebel (rebelled) against society and boys who had such family pressure for perfection that they avoided the challenge.

If you are a parent now, you can help your children chart their way by encouraging them to challenge themselves by praising their effort, not their results. "Wow, look at those colors!" or "Wow, you must have worked really hard on that." or "I saw how hard you concentrated on that. Good for you!" Kids need to have their effort acknowledged, not rewarded. There's a big difference.

If you are a manager, same thing. Acknowledge the work, even if the result is not always what you expected. Some of you might be asking, "But why can't we take partial credit for partially complete stories at the end of the iteration, if we want to acknowledge effort?" Because we while we want to acknowledge effort, we do not want to reward it. That's the challenge.

I was one of the people who gave Linda a standing ovation. I will be urging her to share this presentation.

I'm at a conference this week with my husband, where I am "just" the spouse. That means I get to go to sessions and attempt to keep my mouth shut. Hah! Lots of luck with that! On the other hand, I also get to learn about what this group thinks is important to sustain itself.

"Mentoring" is a big deal at this conference. What they call mentoring, I would call coaching. Coaching is a big deal in our community, too. I've written about this before, in How 2 Buddy. Arlo Belshee has a great experience report from an early Agile conference, Promiscuous Pairing and Beginner's Mind. Yes, it looks like the paper is about pairing, but it's also about coaching, where each person coaches the other.

What makes a great coaching program? Well, both people, the coach and the coachee have to get something out of it. Here are my steps for creating a coaching program.

1. Make sure you have enough coaches for the people who want coaching. Insufficient coaches means you spread people too thin, which does not work, or you leave people without a coach, which is disappointing. Better to leave people without, than to spread coaches too thin. I've seen a number of organizations attempt to move to agile who don't have enough coaches. The people and teams struggle to implement what they were taught. They do not understand what to do. That's insufficient coaching.
   
2. Set expectations about what a coach does. A coach is not a teacher, although if a coach so chooses, a coach can teach a coachee.
   
3. Coaches help to isolate the problem. Often, when people describe the problem, the problem they see is not the real problem, but a result of the real problem.
4. Coaches help the coachee evaluate potential options and the results of those potential options. A coach offers options with support. Sometimes those options come directly from the coachee. Sometimes those options come from the coach because the coachee cannot think of any options without help.
5. Coaches help the coachee generate action items and SMART (specific, measurable, actionable, realistic, timebound) goals.
   
6. Coaching is a time-bound experience. When I coach my clients, I limit our time for a specific kind of coaching. After that coaching is over, it's okay to change the relationship to a new coaching relationship about some new issue.
   
7. Coaches encourage. They do not evaluate anyone's efforts.
   
8. Coaches provide feedback. They may help a coachee by catching that person doing something right. Or, by catching them before they go too far down the wrong path. Maybe they experiment together.
   

There are a number of coaching tools that a coach can use for feedback. The key is that the coach use them.

I often find that when I coach teams I also need to coach the individuals on the team.

Coaching does not have to be an external activity; it can be internal. And, a coach is a full-time job. You cannot coach in you free time.

So, think about the coaching you need at work. And think about the people who can provide it. Decide if you can staff coaching internally at a sufficient level. If you can, wonderful. And if not, know that now. Do not shortchange such a critical function. If it's worth doing, it's worth doing right.

I've been meeting teams who complain to me the iteration is too long. "But, JR," they say, "we can't get anything done in four weeks. We have to move to six week iterations. We can't possibly commit to anything in four weeks. We need at least six weeks to finish anything."

They sit there, with their sincere faces. They look at me, expecting me to go along with them. I take a deep breath, and say, in my most sympathetic and sincere voice, "Oh boy. This is really hard. Ok, you've convinced me. The iteration is now two weeks long."

At first, they turn to each other congratulating each other that they've pulled something over on me. Then they turn back to me, and look at me like I've grown at least one more head. Or maybe that my head is turned around backwards. Inevitably, the tallest man stands up and tried to intimidate me physically. He doesn't realize that my stature is the smallest part of me, that I've been shorter than everyone else for so long that his attempt at intimidation is pitiful to me.

"Johanna, what do you mean, two weeks. Did you not hear us?"

"I heard you just fine. Do you really want to wait six weeks to discover why you can't release anything in six weeks either?'

That usually stops them in their tracks. "What do you mean?"

"If you don't think you can finish anything in four weeks, the chances are quite good you can't finish anything in six weeks either. If we make your iterations two weeks, you have to reduce the size of the work you take into your iterations. You will be more able to estimate the work. You will have less to test. You will have less opportunity to create technical debt. You have a shot at releasing what you created.

"But if you expand the timebox to six weeks, you won't get the feedback you need. You will never understand why you can't do anything in four weeks. You will never learn why you can't finish anything in four weeks. You will have a self-fullfilling prophecy: your four-week iteration will be too long."

At this point, they generally want to go back to a four-week iteration, because it looks better than a two-week iteration. But no, a four-week iteration is an excuse to do a waterfall iteration: one week of design, one to two weeks of development, one week of testing (which will get crunched into less than a week because the development will expand) and then quick, end the iteration. Some smart person will want a Gantt chart of the iteration, and another smart person will want a test plan. Their self-inflicted overhead will kill their agile efforts.

Now, maybe your agile pilot did succeed with four-week iterations. Good for you! But I'm meeting more and more teams whose pilots are not succeeding. They don't change what they are doing--they fit their silo'd teams into a four-week timebox and call it agile. They certainly get some value from the timebox. But they are not living the agile values and they are not transitioning to agile.

When you make the iterations shorter than you can imagine, you force yourself to change your practices. You force the team to consider continuous integration. You force the team to integrate the testers with the developers. You force the team to limit the number of stories in progress at one time. You force the team to reduce the number of stories under consideration for a timebox, so the team has a better idea of what they can commit to for an iteration.

Maybe each of these changes is not so big as a single change, but taken all together, they are a huge change for a given team. For the team who thought they could pull one over on me, each change was a big change, and all the changes together was a monumental shift in the way they worked. And, when I suggest we start the iteration on a Wednesday, I thought they were going to revolt, especially since it was Tuesday afternoon.

"Can't we start on Monday?" one of the developers plaintively asked.

"What do we gain by waiting?" I asked.

"We get accustomed to the ideas," he replied.

"You get to research and discover more ways you can push back and tell me why things won't work here," I answered."

Everyone laughed, nervously. I said, "Look, I'm asking you for two weeks. Starting tomorrow morning. The worst thing that happens is that you get through tomorrow morning and you hate me. Right? That's about me, not you. What do you have to lose? All you do is take it one step at a time. And I'm with you each step of the way. Ok?"

They agreed. I was concerned they would all be sick the next morning, but they all came into work on time. We did plan the next morning. And they did get through the next afternoon. They almost finished a small feature, which blew them away. By Friday afternoon, they had finished two stories off the backlog. And, they discovered what prevented them from making their integration continuous. And, they learned what the testers needed for an automated test system, and created a just-enough test automation system.

By the end of the iteration, they had finished eight of the ten stories on the backlog, discovered they had mis-estimated two of the stories, and had discovered five new stories. They had never worked like that before. When they provided a demo to the product owner, the PO was thrilled.

Not all teams have such great results. As with all changes, your mileage will vary. But when your team says, "the iteration is too long," consider shortening the duration, not lengthening it. The more opportunities the team has for feedback, the faster the team can learn.

I recently spoke with a Scrum Master of a team of 10 people. He is struggling, as is the team. They are having trouble connecting as a team. They are ok when they work as smaller sub-teams, but not as a team of 10. Well, that's not entirely surprising. There's research backed up by data to explain why.

I've observed over the years that teams of larger than 9 people didn't have what I call the "intimacy" of teams 9 people or smaller. Teams of 3 people or smaller didn't always have the ideas needed, but teams larger than 9 people lost something that was common to smaller teams--an ability to easily communicate with each other. There is a reason for that: the number of  communication paths in the team.

The number of communication paths in the team do not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. That means you have these communication paths for these team sizes:

4 people, (16-4)/2=6
5 people, (25-5)/2=10
6 people, (36-6)/2=15
7 people, (49-7)/2=21
8 people, (56-8)/2=24
9 people, (81-9)/2=36
10 people (100-10)/2=45

That means the number of paths for up to 8 people is still manageable (24), but once you get to 9 people, it becomes 36 paths, which is high. For 10 people, the number of paths is 45, which is unmanageable for most of us. Can some people manage this number of communication paths? Sure. But not many of us, which is the problem. That's why "teams" of 10 people don't work.

If you have a group of 10 people, they will naturally divide into smaller sub-teams of people who can work together. They will not divide themselves evenly, as 5 and 5. Oh no, that would make life too easy. If you are very lucky, they will divide by features. If you are not lucky, they will divide by architecture or by function, or even worse, by clique.

So what does that mean you should do if you have a large team? Here are some ideas:

1. Organize by feature. If you have a feature team that's relatively small, as in fewer than 10 people, great. Keep the team that size and stop worrying. You're done.
   
2. If you have already organized by feature and the team is still larger than 9, first see if you have enough people on the team. Do you have enough testers, BAs, product owners, writers, whatever you need? If not, determine what you need. I often see that teams on the verge of becoming programs (collections of projects) do not realize they have to scale, and are trying to "make do" with who they have, which doesn't work at all.
3. Once you have enough people, and you've organized by feature, now, ask the people to organize the way that makes sense so that they can get the work done. Do not tell them, "Every team deserves 1.35 testers," because that's how you can divide the testers up. That doesn't make sense. Ask the teams to discuss it and let you know what they need and what does and does not make sense. They will let you know.

If you have a small team, a team of 3 or fewer people, watch out for insufficient ideas to solve the problems. That doesn't always happen, but it sometimes does. Too few people can be just as bad--although differently bad--than too many people. Team size matters.

I'm in Australia right now. I've been keynoting, paneling, and talking at Software Education's SDC conference. One of the participants asked the panel of speakers, "My management thinks I should be able to do the BA work and the Scrum Master work on my project. What do you think?" The other speakers were reasonable, explaining that because BAs are collaborative, they are a natural for the Scrum Master role.

I just about exploded out of my chair. "What is your management thinking? Do they want to do Scrum or do they want the project to fail? Or, maybe they want you to fail?" I ranted and raved a little more, but I'll save you from that. Here are the ideas behind my ranting and raving.

If you are new to agile and you want to do Scrum, then follow Scrum. There is a reason for the role of Scrum Master. That reason is that when you are new to agile, you need someone who advocate for the team to remove impediments at all levels of the organization, someone who can facilitate the process for the team. This person serves the team. This person, if serving the team, will spend all of their time serving their team. They will nudge the product owner into grooming the backlog. They will help people understand the acceptance criteria. They will facilitate the standup meetings and make sure those meetings occur, that the team collects the data and does not last longer than 15 minutes. That person ensures that the other problem-solving meetings occur. That person will solve problems on behalf of the team. In my experience, a new Scrum Master, for a new team spends a ton of time away from the team doing things like fighting the furniture police, fighting the network police, fighting the management police, so that the team can work. If this person also has deliverables to the team guess what? No one resolves the impediments. The team's velocity never settles into a rhythm. The team and the organization never sees the benefits of agile.

Someone says "Agile (or Scrum) doesn't work." Nope, that's not the problem. You're not doing agile or Scrum if you don't follow the directions. Don't adapt it if you don't first adopt it, lock, stock, and barrel.

When you try to play more than one role on an agile project, you are not adopting agile. You are adapting agile without understanding how to adopt it.

Multitasking on an agile project is just as bad as multitasking on any other project. You have to make it transparent. If you are asked to multitask, make it an obstacle. Show your lack of progress on the board. Consider using a kanban board inside a timebox if a number of people on the project are supposed to be multitasking. Ask your managers to start managing the project portfolio.

Because remember, it's not about the projects you start; it's about the projects you complete. It's not about the roles you take on; it's about the projects you complete. If you can successfully complete projects with multiple roles, great. That's a rare capability for rare projects. 

Keep your eye on the goal: finishing projects. Then you'll know what to do about this business of multiple roles.

When I work with people who want to clean up their meetings, they tell me what their problems are: presentations in meetings and serial status meetings.

Ban presentations from meetings. If you have to have a presentation, send the presentation in advance. Ask people to read it in advance. At the meeting discuss the issue. That's why you have the meeting. You don't need the meeting for someone to read you slides.

But the more serious problem is serial status meetings. That's where you go around the room and ask for status. This is built into our work culture all over the world. It's a huge time-waster. If you do this now, stop. Ask yourself why you do this. You may have good reasons: you want to know what people are working on and you want other people to know what everyone else is working on.

But, that's precisely the presentation problem. If you want everyone in the group to know what each other is working on, you either have everyone email each other their status in advance of the meeting if the group is not agile, or, if you are agile, you have standup meeting every day, so you don't need a serial status meeting. That takes care of everyone else in the group.

Now, how will you know what's going on if you are the manager? You have one-on-ones with everyone in the group. You have a 15-20 minute one-on-one with each person every week or every other week, where you have a private discussion about their general progress on their work: are they happy on their projects, do they want other work, what kind of career development do they want, or what progress have they made, what issues do they have for you, what issues do you have for them? This is your opportunity as a manager to build a trusting relationship with your employee, for you and the employee to investigate communities of practice, to give and receive feedback and coaching, if necessary. One-on-ones are a valuable and underutilized management tool.

If someone else, such as your manager, conducts serial status meetings, ask for a one-on-one and give your manager feedback. "Mary Manager, you may not realize this, but when you go around the room asking for status, it's not interesting to us, it's only interesting to you. Instead of doing this at our group meetings, how about we email our status to you, and we use our group meetings to solve our problems or discuss our group mission, or only meet as a group to solve problems every other week? We can have short one-on-ones with you every week or every other week with you instead. What do you think?"

What wastes your time in your organisation? It's probably a tie between the multitasking and the meetings. Maybe the multitasking wins, but the meetings are a close second. The first way to stop wasting time in meetings is to keep your meetings clean.

If your meetings don't have agendas, minutes, and action items, why do you have them? Sometimes meetings are merely information dissemination events, which are either infrequent, or you can timebox. Don't have weekly serial status meetings. If you have them, I'll suggest alternatives in my next blog post. If you are subject to them, I'll suggest alternatives in my next blog post. Serial status meetings are deadly. Donuts don't help. Nothings helps. Don't have them. Don't participate. Say no to serial status meetings.

1. If you regularly attend meetings which do not have agendas, minutes, and do not have action items, you can ask for them, or start creating them. Yes, that's leading from the back of the room, but what's wrong with that?
   
2. If you do not need to be at a meeting, you can leave. You can decline the meeting at the invitation. You can decline the meeting when you discuss the agenda, and realize you don't need to be there. You can say, "Oh, if that's what's up for discussion, I don't need to be here. Let me know what you decide."
3. End the meeting 5 minutes before the hour. That allows people time for a quick bio break and time to get to their next meeting.
   
4. Be on time for meetings you accept. It's rude to be late.
   
5. Start your meetings on time and do not start the meeting over for people who arrive late. I once worked with people who agreed themselves to put a dollar in the kitty for every minute they were late to a meeting. Once a quarter they had a party with the money in the kitty. After one quarter, they were unable to have a party, because there was insufficient money in the kitty. And what happens when a senior person arrives late? Ignore that person. Remember, they put their pants on one leg at a time, too. Do not treat them as special, just because they arrive late.
   
6. Email agendas and any supporting material 24 hours in advance of the meeting so people have time to read them.
7. Email minutes within 24 hours of the meeting, so people don't forget their action items.

The first step towards not wasting time in meetings is to keep your meetings clean, so follow these steps to keeping your meetings clean. I'll rant and rave and suggest alternatives to serial status meetings in my next blog post.

I live in the Boston area, and we have had more snow in the last few weeks than we normally have. And, we have not had our normal thaws, so the snow hasn't gone anywhere. Our snowbanks at corners are high--so high that when you drive, you have to edge out into the already-narrowed streets to look around the snowbanks to see if it's safe to go. Of course, by that time, you're already halfway out into the street. You'd better commit to go!

I was thinking about that problem on my way home from the gym this morning. The streets are already narrowed from the snow, the snowbanks are high. There are times when I do not want to commit to going--such as when a bus is already too close for me to make a turn and get to a reasonable speed.

We see problems like this on our projects all the time. We need to stick our noses out to see if it's safe to try a direction before we fully commit to it. We may want to try one direction and then turn around if it's not working (not an easy thing to do on snow-narrowed streets).

We have options for managing our project risks that we do not have for our driving risks:

1. Try a Hudson Bay Start. For a Hudson Bay Start, you try to push through one very small piece of functionality, and see what it took to do that. The reasons you start with a small piece of functionality is that you want to try driving across the street, not the country. You want the equivalent of "Hello World" and no more, just to see where the risks are, and what you will need to do about them.
2. You can try a short iteration, say a week, maybe two, and see how far you can get. Now you have data that you can apply to the rest of the project or program.
3. For a design/architecture problem, apply a design spike. Take 2 or 3 people for no more than 6 hours, and discuss and code, and see where you are at the end of that time.
   

In software projects, we don't have to commit the way we do when driving--which is a good thing! We can do a little more exploring and see what data we can gather. Now, based on data, we can make a reasoned decision. We don't have to make a split-second decision on snowy streets the way I do right now when driving.

Wish me luck--we're expecting another foot of snow by the time you read this. The streets will be even narrower and the snowbanks even higher. One of my options will be to take a deep breath and go for it. We don't have to do that on our projects. Which is a Very Good Thing.