The team returned to the meeting room in better spirits. Kate had drawn a new picture on her tablet.

“Welcome back,” Kate said. “Jim? Susan? Do you have some stories for us?”

Jim took the lead. “We brought five stories, not because we expect five but because we’re not sure whether they are too small or too large. Normally we’d have time to talk with some of the team members to get a sense of size. This time we had to guess. OK”?

Jim and Gil had been leaning forward, ready to leap, but sat back. “OK,” Jim said. “Let’s see what you’ve got.”

“Should we put them all up at once,? Susan said.

Gil said, “Let’s go one at a time and talk a bit about what each one involves.”

The team all nodded.

One story at a time, Susan and Jim described what they needed. After each one, the team discussed how they might test that story, and talked a bit about how the story could be implemented.

When they got finished with the third story, Kate noticed that the team was looking tense. “How is it looking, gang? You look a bit edgy.”

Chuck spoke up. “In the earlier meeting, I was pretty optimistic about getting last week’s five all done. We talked about it during the break, and I’m still optimistic but I think there might be more work than I thought. I feel like this is enough, or maybe even too much.”

Kate said, “Are your stories in priority order, Jim and Susan?” They nodded. “Shall we look at the other two while we’re here, or stop now?”

Jim Anderson said, “I’d like to hear the other two. It won’t take long and it’ll give us a look at the future.” The team seemed to agree.

After all five stories had been discussed, Kate said: “OK. We’re looking at finishing last iteration’s stories and some of these. What do you think?”

Carlos said, “It would help me if we could put the old stories up on the board and task them out.”

Gil said, “We already know what we have to do for those. We don’t need to review.”

Carlos sat back, but Kate said, “I don’t want to be here all day, but let me ask a question, Gil. If we had everyone in the room write down on a sheet of paper what the five other stories are, and what work needs to be done, would all the sheets agree?

“I’m the disappointed story lady, and I really don’t want to be disappointed again, and I don’t want your children and kitties to starve. Should we take some time, or take a chance?”

Gil said, “OK, good point. Obviously Carlos isn’t sure, so let’s review. I’m sure we could figure it out but let’s be a bit more explicit, since we screwed up last time.”

It didn’t take long to put the other stories up on the board and to brainstorm the work that needed to be done.

Kate said, “OK. I noticed that there was a bit of discovery there. We saw a task that wasn’t mentioned this morning, and we found a task that could be done another way. I’m thinking that was worth doing.

“Now let’s take a short break and see what I can look forward to when I come in to the story store next week.”

Commitment time …

“OK, crew,” Kate said. “Looking at these ten stories on the board, what do you think?

No one spoke. After a while, Chuck said, “I still think we are good for the original five stories in two days. I’m sure the one I was working on is only a day, then I can pitch in on something else.”

Jim looked around the room. “Two days, guaranteed?”

Again no one spoke. Then Carlos said, “Let’s play it safe and say three, then shoot for two.”

That seemed to be a good idea.

“OK,” said Kate. “What else can be accomplished?”

The team huddled a bit. Then Jim said, “I know we said three before, but these are a bit larger than we had in mind or something. We’re sure we can do the first two. Maybe the third, but maybe not.”

“Probably not,” said Alice. “All three of these need GUI work that I’ll need to do. I really don’t think it happens.”

Susan wrote on a card, and handed it to Kate with a grin.

Kate grinned. “Good Susan,” she said. “Biscuit later. Gang, Susan’s card says ‘Stretch Goal?’. What do you think?”

“I say go for it,” said Jim. Some of the team nodded, some just sat there.

“Objections?” asked Kate. Again silence.

Finally Jim spoke up. “Kate, Susan and I have been pushing the team to ’stretch goals’ right along. We think they respond well to a little challenge.”

Kate looked around. “I don’t see smiling faces, Jim. And when you’ve pushed the team to stretch goals, what has happened? Do they meet them?”

Susan raised her hand and got the nod. “I happen to know that. About three-fourths of the time, they fail to deliver one or two stories. When they do deliver, every single time at least one of the stories turned out to be seriously incomplete or broken.”

Jim said, “Yes. Think how bad things would have been if we didn’t keep the pressure on!”

It seemed like the entire dev team snarled. Gil jumped up. “Damn it, you just set us up to fail! We tell you what we can accomplish and then you push us to do more. If we do the job right, we fail. If we do the job wrong, we ship crap. Stretch goals, my ass!”

Everyone kind of fell back. Gil looked around, then said, “Well, sorry. But it’s crap. We can’t win. We can’t even tie.”

Kate said, “Let’s see if I understand. Someone said–I don’t remember who–that under pressure, programmers have secret quality dials that they are tempted to turn in order to make a deadline that should never have been set. The result is code that never comes together, or that seems to work but isn’t really robust. Is that what you mean, Gil? Leaving your seat out of it?”

Gil said, “Yes, that’s it. And it’s crap. It asks us to produce crap and I don’t want to live that way. I’m here to do good work. Damn it.”

Kate laughed. “Well at least you’re consistent about this. What about the rest of you? Do you agree with Gil’s point, if not his format?”

Right around the table, the developers agreed. Chuck said, “Yes. I’m here to do good work. I know what good work is. I really value the clarity we’re getting with these smaller stories. But it doesn’t help me to have work piled on to work.”

Alice said, “Yes. And it’s worse than that. Remember you asked if others could do the GUI work that I do. They nearly could, with a little coaching. But if I have too many stories to do, I don’t have the time to sit with people and help them work through things. That takes a little longer the first few times. Under pressure I feel I don’t have the time and I’m too stressed to do it.”

Kate said, “Jim? Susan? It sounds to me like your ’stretch goal’ strategy has never really worked. You usually don’t get what you want and what you do get isn’t as good. What do you think?”

Susan went to speak, but Jim held up his hand. “Let me say it. We’re afraid if we don’t keep the pressure on, the team won’t go as fast as they could. They may lay back and take it easy.”

Again the team erupted. This time Kate held up her hand. “Let me take this one.

“How would you feel, Jim, or you, Susan, if Dan told you that he thought you weren’t working as hard as you could, and started pushing more work on you?

“Take a moment, then be truthful. Feel it, and tell us how it feels.”

Jim and Susan paused. Then Jim said, “I’d hate it. Dan knows we’re the best. He gave us these jobs. He should trust us to do the right things and to do them right. Dan’s not like that anyway. Dan would coach us and help us, not treat us like …”

Kate said, “Like what?”

Jim said, “I get it. We’re making the team feel untrusted, and by pushing more work on them, we overload them.”

Kate said, “And why does that overload them? Why don’t they just go along at the slacker pace you’re worried about and deliver what they can? What could possibly explain what they do?”

Susan chipped in. “They’re not good enough …”

Kate stopped her. “No one is ever good enough. Everyone is as good as they are. If they’re getting in trouble trying to reach stretch goals, not being good enough can’t be the real cause.”

Jim said, again, “I get it. They do poorly because they’re trying to do what we ask, and it is too much for them.”

Kate said, “Exactly. And what does that tell us about trust?”

A long silence ensued. Finally, Jim nodded. “They’re failing because they’re trying to do to much. The fact that they’re trying tells us that they’re willing to work hard and that we don’t need to push them. We can trust them to work hard.”

Kate gathered everyone’s eyes. “Is that right, team? Can we trust that you’re doing your best?”

Gil laughed. “Let’s see, we could say no, or we could say yes …

“Yes, you can trust us. We’re professionals. We do this work because we want to do it well.”

Kate said, “One more thing, and we’ll close. Jim, Susan? When the team has fallen short of the stretch goals, how do you feel?”

Susan said, “I feel let down. I feel like they broke a promise.”

The team rustled. Susan went on, “Oh. They didn’t promise. They always said ‘We’ll try.’ Anyway, I do feel disappointed.”

Exactly, said Kate. “I would as well. So when Binary Girl the Feature-buying Lady leaves today, what shall we tell her? Seven, or eight?”

Carl said, “We can do seven. Tell her seven. Right gang?”

Everyone on the team nodded or said yes.

Kate looked around. “OK. We’re all tired. Tough meeting today but I think it has been worth it. The team says they can do seven. Next week BG the SL will be expecting seven. Let’s close for now, but tomorrow I’d like a brief session with interested folks to talk about what we should do to make sure we get seven, and what to do if it turns out we can’t. Would 9 AM work for that? Attendance is optional.”

Everyone agreed.

“OK, seven stories it is. Thanks. See you tomorrow.”

The team filed out. Kate gestured Susan to stay. “Susan? I’d still like to have a session with you. Today? Or is tomorrow better after all this?”

“Do we have to?” said Susan. “I’ll be good.”

“Yes, please,” Kate said. “I just want to help you understand what I’m up to.”

“OK, tomorrow then. After the 9 AM thing?”

“Great,” said Kate. “Don’t worry. I promise not to blow my whistle.”

“Yikes, I hadn’t even thought to worry about that. OK. I’ll just stay after then 9 o’clock, OK?”

Kate said, “That’ll work fine. Thanks. Bye for now.”

Shop Class as Soulcraft: An Inquiry into the Value of Work
– Matthew B. Crawford

Crawford speaks eloquently about the value people feel in work that is tangible. He is primarily extolling the joy we feel in applying the manual arts well, and suggests that we should value those skills more highly.

He points out that a craft like plumbing is not subject to off-shoring, because it must be done on site. The Agile software community, of course, understands that working on site is far more effective for us, though it is not logically necessary in quite the way that plumbing is.

But there’s more for us in this book besides a good read. People do get joy and work harder, when their work is tangible. This has implications for how a developer can work toward greater joy, by focusing on delivering real features that people want.

There are implications for management as well. Because people are motivated to see their work come to fruition, we’re likely to get better results with feature-focused teams rather than teams divided along other lines, such as infrastructure levels.

This book is a quick and enjoyable read and it will give you valuable ideas.Give it a look!

Another Perfect Start to Another Perfect Day

“Let me see if I understand, Carl,” Kate said. “In our last planning meeting, the team said that they would take on five stories? And now, at the end of the iteration, none of them are done?”

“That’s right!” said Susan. “They promised us five critical features and now they let us down again! These so-called engineers just aren’t very good!”

Gil jumped up. Carl, normally Mr Calm, jumped up. “Susan …” they said, as if in chorus.

“Stop!” Kate said. “Stop now!”

Everyone kept shouting.

“Stop! Everyone who wants to be a part of this meeting, calm down now. We have work to do!” Kate said, louder this time.

The hubbub continued. Gil and Carl and Susan were raving and the rest of the room looked shocked. Kate grasped a chain around her neck and pulled out her emergency whistle. She blew it, loudly. Sudden silence.

Kate smiled. “Thank you. Carl and Gil, please sit down. I want to explore this situation and to hear what you have to say. Susan, you may leave.”

“I want to stay. My concerns need to be heard,” said Susan.

“Susan, we are here to find out what happened in this iteration, and to do something about it. You seem to have some other agenda. You and I will discuss our concerns after the meeting. For now, you may leave.”

“Please. I want to stay,” Susan said.

Kate relaxed her shoulders, almost visibly collecting calmness from the air around her. “OK. You may stay, but not another word. If you have a question or comment, write it on a card and give it to me. And find an hour on my calendar today: we need to talk.”

Susan frowned, nodded, and sat down. Kate sat perfectly still for a moment. Then it was as if she reanimated.

“OK. That wasn’t fun. Let’s not do that again. Any of us. I’m all for passion in our work and I insist that we keep the passion directed in a positive way. There are to be no personal attacks on this project, in my presence or outside it. Take a few minutes in silence and decide whether you can work that way.”

Susan moved as if to speak. Kate gave her a little head-shake. Susan subsided.

Gil raised his hand. Kate grinned, gestured a heart attack, then nodded and gave Gil a calming gesture at the same time. After a little time for thought, Kate started looking around the room, making eye contact with people in turn. She tilted her head as if with a question.

Jim Anderson looked her in the eyes and nodded. One by one, the developers, who had been silent anyway, nodded. Kate looked at Carl, who nodded. She looked at Gil, who clearly wanted to speak.

Kate took a chance. “Go ahead, Gil.”

“Kate, I’m sorry. I’ll do as you ask.”

Glances were shared all over the room. No one had ever heard Gil say he was sorry before. Kate just said, “Thanks, Gil.”

Kate then looked at Susan for the first time. She held up her hand. “One word, Susan. Yes or no?” She dropped her hand.

“Yes. And I’m sorry too.”

Kate smiled. “You were supposed to write that on a card. But OK. Now please everyone take a short bio and calming break and we’ll start over. Back in ten minutes?”

Everyone nodded and got up to break. Carl said, “Can I bring you a Diet Coke, Kate?”

Gil said, “Let me.”

Kate said, “Thanks, you two. Gil, yes please.” Gil turned to go, and Kate gave Carl a friendly nod. After a moment he smiled and returned it, and left the room.

If At First …

While she waited for the team to come back, Kate amused herself doodling on her Tablet. The picture on the wall screen took form:

Kate had just finished this masterpiece when people started filing back in. Everyone was subdued, but there was a sense of energy. Gil put a Diet Coke in front of Kate.

“Thanks, Gil, I owe you a quarter.”

“It’s on me.”

“OK. I never turn down a free soda.”

Kate gathered up the eyes of the people in the room. “OK, as I was saying before the storm, we thought we were going to get five things, and nothing came out. We’re here to explore productively what happened, and to decide what we should do about it. Do any of you know of Diana Larsen?”

Carlos raised his hand. “She’s a coach. She specializes in retrospectives, and people-focused things.”

“Yes,” said Kate. “I once heard Diana say ‘A person is never the root cause of a problem,’ and I try to live by that idea. We need to look at what happened, and to figure out how our approach let all of us people down, then improve our approach. This isn’t a formal retrospective, but we’ll live by Diana’s guideline.

“So, as I understand it, we set out to do five features, and we got none of them done. Carl, what happened?”

Carl didn’t need any time to think. “We got lots done, Kate. Those five features are ninety percent done, maybe more.” All the developers nodded or murmured agreement.

“OK, Carl. But call me Binary Girl. Done, or Not Done?”

Carl smiled ruefully. “Well, BG — can I call you BG? — if those are the rules, I guess I have to say Not Done. But darn it, we’re nearly there!”

“‘Kate’ will be just fine. Binary Girl is my job title, and we’re pretty informal around here. Let’s pretend for a moment that I was paying for this project.”

“But you are paying for the project,” said Susan, and then made a lip-zipping motion.

Kate laughed. “We’d better let you speak, Susan, or you’ll explode. But let’s keep it positive. You’re right, I guess I am paying for the project. So we shouldn’t have any trouble pretending.

“But my point is a larger one. We should all, always, pretend that we are paying for the project. Every week we have another iteration, and every week we have to shell out enough money to keep the team fed.

“Let’s talk about what it takes. You all know that I think of our product as made up of features. Oh, sure, we all know there are functions and objects and tests and databases and such in there, but to me, and to Jim and Susan, the product is a collection of features that we think will make us successful.

“Features are what we’re trying to buy and features are how we measure our progress. If I came into your feature store today, planning to buy five features, there just wouldn’t be any on the shelf to buy. I’d have to go home without features, and your feature store would have to run for another week with no revenue …”

Jim chimed in. “Before you can say it, Kate …”

Everyone chorused: “That would be bad!”

Kate blushed and grinned. “I guess I do say that a lot. But it would be no pizza all around. That would definitely be bad.”

Somehow, at that moment, the pizza guy walked in.

“How does she do that?” Carlos asked.

“Ask me the secret of humor,” Jim said.

Carlos took the bait. “What’s the sec…?”

“Timing!” said Jim.

Kate smiled and nodded. “Timing. And the timing is always right for pizza. Let no one say I’m not a reasonable woman. Grab a slice and a soda, and let’s dig into the pizza and the problem.”

Fully unified against the pizza challenge, they did.

… You Don’t Succeed …

“OK,” said Kate, “the feature-buying lady has just left your feature store. She was a bit sad because she couldn’t buy any features. And you’re a bit sad because your children and kitties are going to go hungry for a week. What are you going to do? And remember, no recriminations.”

Jim raised his hand. “I’ve got a business idea. Let’s call the feature lady back and ask her which one of those features is most valuable to her. Then let’s finish that one first and maybe we can have it for her by Tuesday. She might give us the money for that one and we could keep going.”

Kate said, “Interesting idea, and I think we should explore later what if I said yes. But suppose I say that I only shop for features on Friday?”

Susan raised her hand, and Kate gave her a nod. “Jim, Gil? You said those stories are all ninety percent done? How accurate is that?”

Jim said, “I think it’s pretty solid. I really think we can get them all done in one more day.”

“Just one more?” Kate said.

Jim looked at his developers. Those who weren’t looking at their shoes were shaking their heads. “OK, guys. How many? Show of fingers.”

The developers all showed two or three fingers, except Chuck, who was shielding his one-finger signal from Kate with his other hand.

Kate said, “Chuck? Your estimate seems out of line with the others.”

Chuck blushed. “How do you do that?”

Kate smiled. “I counted. You know, one, two, three. Was one your estimate, or your opinion of the proceedings?”

Chuck said, “My estimate, with a little spank for my conservative brothers and sisters here. I can finish my stuff in a morning, and probably help someone else finish up in an afternoon.”

“OK,” Jim said. “So we can finish these up in a couple of days. But Kate won’t buy stories on Tuesday, Susan. So what?”

Susan actually smiled. “So I was wondering why you … why we didn’t focus all our effort last week on just three or four of the features. Wouldn’t we have had enough time to get those done? Then Kate, um, the feature lady would have given us the money for at least three.”

“I would definitely pay for three or four,” said Kate. “Would that have been possible?”

The techies conferred, then Gil answered. “We could probably have finished three of those features. We might have finished the fourth, but probably not. But there’s a problem. Four of the stories had significant GUI work to do, and Alice is our only GUI person.”

Kate said, “Let’s ask Alice. I think she’ll know. Alice, are you really the only person who can do the GUI work?”

Alice said, “I’m most experienced with the GUI code, and I’m pretty good at the design side. I’m our most effective person at it, I think. But almost everyone can actually do it. So if someone else could have picked up the GUI work on the fourth story, they would probably be done by now, or maybe they’d have needed me to pitch in a little help for the hard parts. As it was, I only got three of the GUIs done.”

Kate said, “Let’s review, please. We undertook five stories. Three of them have their GUIs done. All of them have a lot done on them, only another day or two of work for one person, but none of them got completed.  There’s a general feeling that if we had focused on fewer stories, we’d have had three of them done, maybe even four. Right?”

There was agreement all around.

“OK, then, what shall we do?”

Gil said, “Do you want to buy some stories on Tuesday?”

Kate thought a moment. “No, I would like to stick to the rhythm. Let’s plan to do a full week’s iteration. I propose that the team sign up for the same five stories as last iteration, and get them done this time.”

Gil said, “Team, I think we can get those five done, and more. What do you think?”

Carl said, “Those five and about three more of the same size?”

Everyone agreed.

Kate said, “Works for me.  Jim, Susan? Does that make sense to you?”

Susan said, “Yes. We’d like more but that’s good.”

Jim said, “Yes.”

Kate looked around. “Good. You need three more stories of about the same size. Let me suggest a short break, and that we then reconvene to get three stories from Jim and Susan.”

To be continued … after the break!

First, two things are fundamental:

1. Ship running, tested software every two weeks, or, if you are a wuss, every month. (DONE == DONE)
2. Reflect frequently on how it’s going, and revise your practices in accord with what you observe. (Inspect and Adapt)

Now then. When you set out to do these things, certain chains of events are inevitable and I do mean inevitable. Here’s one example:

1. To ship done software, it must be tested.
2. To ship done software every two weeks, it must be tested every two weeks.
3. Changes to the software can, in principle and in practice, break essentially any feature anywhere in the software.
4. To ship done software every two weeks, essentially every feature needs to be tested every two weeks.
5. This testing burden increases linearly or worse than linearly with the number of features.
6. Manual testing cannot sustain the two week delivery cycle.
7. Therefore, for a truly successful iterative software project, automated testing is absolutely necessary.

There are quite a few things like this that are just inevitable. There are others that are almost always needed, others that are commonly needed, still others that are sometimes needed.

To call a process “Scrum”, we demand certain things. All of those things are pretty good ideas. Some of them may be necessary to a successful project, even if they are necessary in order to call the process Scrum. I’m more interested in successful projects than I am in the name of the process.

Historically, software projects have had no API. You gave a software team an unchangeable list of requirements and an immutable date. The project was done in phases such that nothing was useful until all phases were finished for everything: analyze, design, code, test. Along the way, the project produced no measurable output and could not be controlled in any useful way.

As the manager became more and more concerned that things weren’t going well, their only available approaches were to add people, which is usually not possible and doesn’t work anyway, or to add pressure, which doesn’t work either.

Incremental projects using approaches such as Scrum offers of course do have an API. They produce completed features which can be counted, and you can control very nicely what gets done by the date just by selecting the features to do next. (You still can’t improve things by using pressure, mind you.)

However, well-crafted incremental projects don’t let the manager control scope: they put that in the hands of business-side people, product planners and the like, who used to be passive –and unhappy– recipients of whatever the software project actually did.

So software managers now have a very odd job to do, if they have a job at all. They are not really able to manage much of anything about the project. The date and scope are set by the business side, the team’s practice is guided by a coach or ScrumMaster, the team makes all the technical decisions, adding people still won’t work, and pressure still doesn’t work.

No wonder they are confused.

If your organization is like many others, you have adopted Scrum or another “Agile” method. You have received some benefit and are glad you have gone Agile. Yet very likely you feel there should be more — and you’re right!

The creators of Scrum agree: Ken Schwaber has said that perhaps only twenty-five percent of Scrum teams get the full benefit of doing Scrum. Jeff Sutherland has said that every high-performance Scrum team he has seen was using practices that go beyond Scrum.

To move beyond what Scrum and “Agile” have given us, we need to do some new things, and likely we need to do some old things better. Let’s explore together how to recognize those things, and how to begin to address them.

We’ll be looking in these articles at the things that need to be done inside your projects, and outside your projects. We’ll point out what the manager or executive should ask teams to do, and we’ll talk about why. We’ll also be look at what managers and executives themselves need to do to help projects to become successful. Some of these ideas may not be new to you, and others probably will be. Some of the ideas will be challenging, even a bit difficult. Make no mistake: to attain the higher levels of performance, we all need to work a bit differently.

The fundamental benefit that the Agile methods try to provide is the continuous delivery of “Running Tested Features”. Here’s why:

For most projects, we have a deadline in mind, and we have some understanding of the capability we want to have by that date. There are two key questions we need to address:

Planning: How can we decide how much time and how many people we need, in order to get the capability we need by the time we need it?

Managing: Given this overall plan, how can we manage the project to get what we need by the time we need it?

Even with a great plan, we can’t succeed without good project management. We can even produce great results from poor plans. Our teams need to execute every day, and we plan only seldom. So first we’ll look at ongoing management of our projects, and then at how we should plan them.

Conventional software project plans used to look like the picture above. Mysterious and magical things go on in development, and then toward the end of the project, we expect to see features rapidly coming on line, with a successful delivery right at the deadline.

Yes, and on Christmas, Santa will bring you a pony. When we plan this way, the reality usually looks more like this:

The mysterious and magical stuff happens all right, but when things start coming on line, they start late, and arrive more slowly than expected. The project turns from “ALL OK” to “IN TROUBLE” very late on. As managers, we have little or no time to respond to the trouble, yet our sunk costs are so large that we have no real choice but to go ahead.

Incremental development, as Scrum and Agile taught us, gives us the ability to manage the project. The capabilities of the modern project come on line incrementally, a few every month. We can project the growth of features to see how we’re doing. Even if we don’t go any faster, we’re in a better position to make decisions about what to do. We can look at feature growth and the deadline and decide to what extent we should cut scope, and to what extent we should extend the deadline. The incremental project looks like this in comparison with the conventional:

Because of the value of this information, the modern software manager asks for an incremental process, with smooth growth of features. We demand that actual progress be faithfully presented to us regularly, like the blue line above. Our first job is to recognize that a faithful blue line is the truth, and that our job is to manage to that truth. We build our organization’s plans around the truth of what is happening.

Secondarily, we do want to help that line to climb more rapidly. We do things to help it climb – and we do things to make sure that the line remains true. As we succeed in improving feature growth, we update our plans. Always, we focus our plans on what’s true, not on what we wish were true.

In the articles that follow, we’ll discuss what it takes to keep that line growing smoothly and steadily. We’ll talk about how to manage them, and about what the people on the projects need to do. Our focus will always be on this blue line of progress, keeping it smooth and steady, so that we can guide our projects to the best possible success.

Teams using incremental and iterative processes have daily stand up meetings that provide an opportunity to observe how things are going, and they can set up a quick meeting to remove obstacles and improve things. At the end of every iteration, there is an opportunity to review the whole iteration and decide how to make things better.

Most experts, and most named iterative methods, explicitly call for a retrospective, at the end of each iteration if not more frequently.

Some people — and at least one named method — argue that if we iterate, reflect, inspect, and adapt, we can and will become a high-performance team. This is true, to an extent: if we observe the right things and make the right choices, then of course we can improve as much as we want. Unfortunately, we were not born knowing the right things to observe, much less the right things to do about what we see. If we get it wrong, good things will be missed.

Alpha Team has been building features for quite some time now. When they hand things off to QA, they rarely come back, and when they do come back, Alpha looks at what they’ve done, and devises ways to avoid that kind of return from QA. Alpha has beefed up its testing ability substantially, and they use pair programming and code reviews to great benefit. Still, things seem sluggish. Even with no bugs coming back from QA at all, it still takes a week or two to be sure that features are done. This seems wrong, but they don’t see what to do.

Alpha Team, for some reason, has not thought of some valuable ways of restructuring the team, and their work, to help them get things done more quickly. The most effective teams move the QA function before development to the greatest extent possible. The testers are part of the team, not in some separate group. They provide tests before the iteration even starts, and the team considers anything “done” that passes all those tests. When something passes all the tests but does not seem “done”, the whole team considers, not who screwed up, but what tests were not thought of, and how to improve their thinking for next time. The result is much more certainty of where the team stands, and much less stress all around.

Where is a team supposed to get ideas like this? If we wait for each team to think of things, some of them may never do so. If we set up a standard way of doing things, we’ll be cheating ourselves of learning, and we’ll wind up making process followers of our people rather than intelligent creative workers.

What’s most important is that team members need to improve their skills. The organization can help with this by providing training, by subsidizing books, or by other means. We believe that the best approach is for the organization to encourage retrospectives, draw proposals from the team, try them, and watch what happens. When ideas come in from outside, make a point of noting what book or web site was read or what course was taken. In short, show respect for people’s efforts to improve themselves.

Sources of Good Ideas

For internal technical practices, we suggest looking at the practices of Extreme Programming. In particular, automated testing, both Test-Driven Development and Acceptance Test-Driven Development are very valuable, as we discuss elsewhere.

For in-team workflow practices, look to Kanban and other approaches to limiting “Work in Progress”. These ideas highlight bottlenecks and delays inside the development team.

It’s important to look at the larger flow as well. Nothing good will happen if we get development time down to zero in an organization that takes six months to get an idea off the ground and another six months to deploy it. Here we would recommend ideas from Lean, such as Value Stream Analysis.

Is Our Process Framework Complete? Is It Sufficient?

If your process framework includes taking in features at the beginning of an iteration, delivering them complete at the end, and reflecting on and improving what you do, it is probably complete. In principle, that’s enough to make a good framework.

It’s far from sufficient as a process, however. There are many practices, many ideas, many things that we have to do in order to improve. Those things are necessary and they should come from the team and its explorations. No process framework can list everything we need to do. No framework should try.

Some good people[1], plus Chet and I, met in Ann Arbor the week of October 12 2009, to discuss Agile Team Member qualification. The outcome: The Agile Skills Project.

The Agile Skills Project is a non-commercial resource that will establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices. The Project intends to:

• establish an evolving picture of the skills needed on Agile teams;
• encourage life-long continuous learning;
• establish a network of trust to help members find like-minded folk, and to identify new mentors in the community.

Among the projects we have an interest in supporting are:

• defining an Agile Skills Inventory (e.g. Active Listening, Story Splitting, Test-Driven Development, Exploratory Testing):
• providing a repository for reference courses, interest groups, and other material;
• defining self and peer assessments;
• characterizingof external courses in terms of their coverage of the Agile Skills Inventory;
• defining a “learning ecosystem” including paths of learning, or “quests”;
• offering means for publishing team or individual experience reports;
• supporting community rating of courses or trainers;
• supporting ratings for trainers and courses

The Agile Skills Project is not for profit. It aims to be independent of any specific form or style of Agile, and explicitly welcomes all such forms and related disciplines such as Lean or Kanban. The idea here is to build an inventory of all the skills that can aid an Agile team member, across the board.

Looking at certification specifically, The Agile Skills Project stands in full support of the Agile Alliance position that certification should be skills-based, and hard to attain. At the same time, the Project also exists in support of any and all such efforts, in that it will provide a stable and independent Skills Inventory, against which any proposed certification can be assessed.

I just thought I’d make a page with links that may be worth exploring. If you have some, let me know. I have not explored all of these, nor, probably, have you. That’s why I’m listing them.

Iteration Burndown Google Spreadsheet

Visual Management Blog. Articles and pictures about managing projects with big visible charts and information radiators.

Why Project Managers Can’t Manage Projects. Interesting David Schmaltz article suggesting that project management is literally impossible.

Technical Debt on Your Balance Sheet. Is it possible to monetize technical debt?

Perfect Example of Certification. Who says certification has no value?

Comparing open-source Agile project management tools.

Here are a few links relating to collocation, thanks to Adrian Howard and others. If you know of more, let me know, please.

CSCW 2008 Workshop: Supporting Distributed Team Work

RE challenges in multi-site software development organisations

An empirical study of global software development: distance and speed

Team Knowledge and Coordination in
Geographically Distributed Software Development

How Does Radical Collocation Help a Team Succeed?

Working together in “war rooms” doubles teams’ productivity

George Dinwiddie Collocation Page