It’s well known that developer quality is critical to successful implementation of Agile software development. Unfortunately, the Scrum Alliance has paid little attention to this concern, not because they think it isn’t important, but because Scrum is designed to be a sort of container for the development process. As I’ve mentioned here before, Jeff Sutherland, Scrum’s co-creator, says explicitly that high performance Scrum teams need XP-style technical practices. Bottom line, no one is arguing against technical practice, and the Scrum movement has by choice not made a lot of noise about it.

That’s going to change. I’ll be writing here from my informed belief that the Scrum Alliance is sincerely interested in people’s success, and that they are doing their best to help people succeed. I say “informed” because I know members of the Alliance leadership and many members of the Scrum training community, and I assess them as good people who are doing their best to help.

As I say, the Scrum Alliance focus on developer quality is going to change. In fact, it has been changing for quite a while. You’ll recall that Chet, Uncle Bob, Brian Marick, Jim Shore and I had a meeting in Chicago to talk about developer certification. That meeting was funded by the Scrum Alliance, with no strings attached. The Scrum Alliance also paid for the followup meeting in Ann Arbor, reported here under Developer Certification and here under Agile Skills Workshop. The result of that was the Agile Skills Project. As I’ve described before, this project is building an inventory of the many skills that developers need in order to be effective in an Agile situation. There are mailing lists on this subject, and a wiki, and things are proceeding well. Here’s a link to the wiki.

One outcome of the Agile Skills Project will be that any piece of courseware, any book, any information offering, can be compared with the Skills Inventory. This will give a quick view of what that course addresses, how deeply it does so, and what it misses. We believe that this will help people better assess what courses to consider.

Now, again, all this has been supported by the Scrum Alliance (and no other organization so far), with no strings attached.

There’s more to come. What I’ll report next is early information, and is subject to change in details, but I expect not in focus.

Scrum Alliance Recognizes Need

The Scrum Alliance continues to recognize the need for developer quality, just as Uncle Bob does, as you do, and as I do here in the corporate towers of XProgramming.com. The Alliance also knows that the notion of “Certified” as they presently use it is weak with respect to any guarantee of quality (there is none) and that it is strong as a marketing approach.

Let me speak to that for a moment. You’re probably aware that Chet and I teach a Certified Scrum Developer course. We have even taught a couple under the Object Mentor flag, by the way, and it was at Object Mentor’s suggestion and support that I became a CST a year ago. Yes, Uncle Bob’s company.

We have had a clear indication that our course that offers the CSM is easier to sell, and easier to fill seats, than a course we would teach without that little certificate. We are clear, always, about what the certificate means and what it doesn’t, and our customers are quite aware of that truth already.

And still, it sells better. We do our best to sell and teach without deceit, and as an insider I am certain that the Scrum Alliance and the Scrum Trainers that I know do the same. There’s certainly a conflict of interest that I feel: on the one hand, I’m the same delightful guy with or without the certificate. On the other, I get more students, and thus more income, when I offer the CSM. On the gripping hand, I also get to influence more people.

What I mostly care about is influence. But I do care about money and I recognize that it’s acting as a force on me. I do my best to be fair about it. This is the problem that any honest marketer faces.

The Scrum Alliance knows that the CSM is an entry-level rating, as is the CSPO. They want to adjust people’s understanding to focus on the CSP (now Certified Scrum Practitioner, possibly to be renamed Certified Scrum Professional.) The CSP is much harder to get: you have to actually work in a Scrum environment, and you have to write an acceptable report convincing people that you have a clue. It’s still not Rocket Surgery but it is definitely a higher bar.

From my connections with the Alliance, I’m sure they are sincere about doing this. As time goes on, we’ll all see what they do. But what about developers and their skills?

The SA Plan for Developers

There is a plan under way to have a new rating, which will probably be called Certified Scrum Developer . (Yes, I’d rather it was called Rank Apprentice Agile Developer but that name isn’t likely. Let’s focus on what it will be, not just on the name.)

The CSD program will focus originally on actual software developers, that is, programmers. (Other specialties will probably follow.) It will require that a developer complete training including Scrum basics (or a CSM), plus an approved course about development. The course must be taught by a “SA-REP”, Scrum Alliance Registered Education Provider. And the course itself must be examined and approved by a representative of the Scrum Alliance who has a clue about what such courses will be. I happen to know who’s doing that for them now, and I’m happy to say that I trust him.

The approval will be based on the course introducing a core of essential ideas and practices, and on offering actual experience doing the practices. It will need to be a programming course, not a sit down and listen course.

At the end of the course, the student will have heard the words we say, will have had experience doing the practices in a lab environment, and will have been told in no uncertain terms that this is their next step on a road to learning that will never end.

Chet and I will be producing a CSD course. I hope that you know us well enough to be confident that it will be darn good. It’ll still be just a few days, but it will be packed with everything we can pack into it.

The SA plans to invite others to produce and offer courses under the SA-REP program. I’d expect that Uncle Bob and his organization would be a very valuable resource for such programs, as would many of our other colleagues in the XP community.

Bottom Line: Perfect, no. Better, yes.

I am confident that the Scrum Alliance sees the need for developer improvement, and that they are working toward making their members aware of the need. I am confident that they are working to provide resources that Scrum teams can use to begin to build the skills that they need. And I’m dedicated to influencing them in the right direction, and to bringing as many people into the situation to help accomplish that.

In the end, what I care about is software development, as narrow and geeky as that might be. I care about other people finding the joy in the craft that I’ve found, and that means they have to discover the joy of life-long learning. I think this Scrum Alliance effort can help with that, and I think that “certification” has little or nothing to do with it. What counts will be what we tell the people who show up.

I welcome your thoughts on this and will leave the comments open at least for now.

And yet, it is risk, not knowing the outcome, working against the odds, putting forth effort, and accomplishing things that express mindfulness, effort and skill, that make life and the things we make most meaningful. And so, what this boils down to is that at least some good measure of what we do should be done the hard way. Choose your tools wisely, that they allow for the development of your skill.

In “skill and toolery”, he says:

These simple charts may help to explain why so many wood workers like to work with hand tools. Skill and attention are matters that create feelings of self-worth and accomplishment. They are the soft side of harsh reality, and the human component that compels engagement in physical and cultural reality.

These things speak to my heart. If I’m good at a few things, it is because of the joy that the craft of making them has brought to me. This applies to all the things I may do moderately well.

If I express software development ideas nicely once in a while, it is as a result of having expressed them hundreds of times in different ways. Some of those ways have worked well, some incredibly poorly. (I apologize to those of you who have had to read so many of them, and offer thanks for your help in the occasional success.)

If I have the ability to look at most any design, most any code, and see how to make it better, it is because I’ve looked at so many bad designs, so much poor code, that needed improvement, and have worked with them to try to make them better. I hasten to add that most of these unsavory collations were my own.

A small lesson for me …

Last week, Chet and I taught a TDD/Refactoring class. We also taught two Agile Introductions, a CSM, a Story Workshop, and a Partridge in a Pear Tree, but the TDD/Refactoring one is on my mind just now. In that class, we demonstrated how we do TDD/Refactoring.

Naturally, duplication was one of the first smells we encountered, and removing it was one of the first refactorings we applied. We did that with Extract Method, and we used the built-in tool. As I think about it now, we’d probably do well to do the first few refactorings by hand. There are at least these reasons:

1. First, the tools work instantaneously and as if by magic, and the audience almost certainly cannot follow what happens as code disappears from one place, replaced by something different, and then appears somewhere else. I know that when I watch coding examples, those quick transforms escape me, and I generally know what to look for.
2. Second, what’s important about this refactoring, and any refactoring, is what’s going on in our mind … and that is best learned by looking at what we do with our hands.  We perceive the code transformation better if we move the code around ourselves. We learn it better.
3. Third, real-world refactorings can be aided by tools but the tools won’t do them, they’ll just do the steps. We learn to proceed in steps, not by pushing the magic button, but by proceeding in steps.

Henceforth, when we do these demonstrations, I’ll make a point of doing things by hand for a while. The magic tools, as Doug Stowe suggests, may decrease risk, but they also decrease our skill.

… and a question for us all

Which of our tools are increasing our skill, and which ones are standing in the way? Which of our tools are bringing joy to our lives, and which ones are standing in our way?

Jim Shore has written a short item on the above subject. I’ll begin by paraphrasing him, following his outline closely.

In a nutshell, he’s saying that customer acceptance testing using Fit (and FitNesse I imagine) isn’t paying off for him. His objection seems primarily to be that the “natural language” tools don’t pay off.

Two things drive this. First, the people in the customer role don’t want to take the time to write the examples. However, they don’t trust examples written by others. The result is that the responsibility gets handed off to testers, which defeats the purpose.

Second, the tests that Jim’s teams get with Fit seem to be end-to-end, and therefore slow, and brittle.

Therefore, Jim is no longer recommending this kind of testing. Instead, he relies on close communication with the on-site customers (product owners), only sometimes creating the examples that correspond to conventional Fit tests, and then turning those examples into TDD tests.

In a couple of tweets, Jim also tells me that his teams do create regression tests, and of course they do exploratory testing as any wise team would. When exploration finds things, or when defects are reported, then the team realizes they are too confident, improves their practice a bit, bears down a bit, and gets back on track.

On the one hand, I find Fit and FitNesse to be an intense pain to use, and in my gut I suspect that if I were made to use it, I’d refuse. Or, I hope, come up with a better idea.

On the other hand, I believe that examples are the best way to communicate about any complex requirement, and I’m concerned that Jim’s teams may not be working on the complex end of the requirements scale. (This could be good for a number of reasons, but it might imply that his advice is only good at that end of the scale.) Still, his teams are using examples where they think it counts. In many applications that are basically CRUD, examples may well be a waste of time.

On the gripping hand, I’m concerned about the potential loss of understanding and agreement between on-site customer / product owner and the team. Examples are the best way to do that and while it is more work for the customer, the examples are more likely to be understood, and to be correct.

Bottom line, I’m concerned about this issue because I like the clarity that results from having concrete tests that are agreed to be “the definition of done”. At the same time, Jim is a smart and experienced person, and we need to pay attention to what he’s finding out there.

This related post just in from Gojko Adzic.

This related post just in from George Dinwiddie.

Jim Explains …

For all our benefit, Jim Shore goes on to describe the things his teams do that help make it safe to operate without Acceptance Tests per se. Good stuff. Read it. I’ll wait.

OK, well, yes. Jim lists essentially the entire contents of the XP lexicon. And all those practices are good and done in concert, you’ll be pretty safe. Let’s look at a few of these for comment.

Jim points out that his teams use unit tests, focused integration tests, and end to end integration tests, written in TDD style. The latter two are exactly the kind of tests you’d get if you could get what I call “Customer Tests”, except that they might not be in a form that the Customer herself could write or read. These should ensure reliability, though they might fall short a bit in communication value compared to Customer-written tests. With good communication around them, this can surely work.

(Mind you, I’m sure it does work. Jim is doing it. I’m just saying that we can see how the laws of software physics support this approach working. It’s readily credible.)

Jim then lists a few million standard XP practices which do support quality. Excellent. Then, he says:

And finally, when my teams find a bug, we fix it right away — or decide that it isn’t ever worth fixing. … After writing a test to reproduce the bug and fixing it, we refactor the code so similar bugs are less likely in the future.

Well. This is interesting. The point is that if we fix things right away, and reflect, and improve our code (and our process I imagine), we’ll improve so as to reduce defect injection. Again, it is easy to see that this will certainly work.

We still have open a small concern about customer-team communication, since all this is mostly on the technical side.

Now Jim goes on to talk about collaboration. He has fully cross-functional, collocated teams, including customers and testers on site. Forgive me for suggesting that if you’re not doing these things, you are not on safe ground for full communication and that the need for Acceptance Tests, however painful, may be increased.

But wait, don’t answer yet! There’s more! Jim’s teams use “Customer Examples” for anything that is difficult to explain. And the developers use these examples for tests … which may not be able to be reviewed by the customers.

This is quite OK. If customers provided Acceptance Tests, the developers would be fools not to run them until they work. It really wouldn’t matter, other than for confidence building, if the customers never saw them run. That has always been true: on C3, our test running person would report the results of the tests every day, and the customer almost never ran any of them. She was satisfied that they were being run and looked at.

Jim goes on to say that he’s OK if the tests are not automated and if they are not customer-understandable. I’m OK that they are not customer-understandable — though I would prefer that they were if it were close to free. I am less comfortable with the notion that they are not automated. My concern would be that if they are not automated, doors are opened to regressions.

It would be interesting to know when these tests are automated, and when they are not, and what other tests are commonly put in place when they are not. Certainly it is not necessary to run every example to be sure that the code works. Probably it is necessary to run some.

Jim then digresses to point out that the real way to trust is to ship stuff that works. Yes. Our question here is about the extent to which Customer Acceptance Tests contribute to things working. I agree that with a sufficiently weird customer they wouldn’t generate trust just by printing “Yay, we work!”

Jim goes on to list every other known XP and related practice as things that his teams do. If your team is doing all those things, then you, too, may not need to automate acceptance tests.

And remember: I hate automating acceptance tests with Fit and suspect that I couldn’t sustain doing them. I also hope and vow that I would do everything else I knew about, to make up for it.

In sum, take a hard look at all the things Jim’s teams do, including every known good practice, especially including root cause analysis on every defect. Notice that his teams do not treat defects as business as usual.

My bottom line on all this is that if I were that good, I could skip acceptance tests as well. On my best days, I’m that good. On my normal days, not so much.

I suggest that the right notion might be this one:

Acceptance Tests are at shu level and the bottom half part of ha level. When your team is at or near the ri level, you’ll have enough other rigor in place to safely drop them. Even then, keep a weather eye peeled for increases in defects. We’re not as good as we think we are.

Summary Remarks

Jim and I, and a few others, exchanged some Q&A on Twitter. My main concern is this one:

Acceptance Tests are what Joshua Kerievsky calls “Story Tests”. They test whether stories work. It appears that Jim’s teams do these sometimes, but not always. They always do lots of low-level TDD, and they do what he calls “integration” and “end-to-end” tests. However, Jim says that they do not always save the end to end tests, sometimes just doing them manually during development.

It seems to me that if any given patch of code is not covered by an automated test, in principle we do not know whether it still works or not. It could be broken by a change to the code itself …  or by a change to any object on which the code relies. Yes, the TDD tests for the objects involved will help prevent defects in the users but they are not as solid a guarantee as we’d have with automated story tests for all stories.

Jim’s observations seem to me to touch on these related but separate topics.

First, customer-owned examples are hard to drag out of the customer. Jim’s teams work to get the examples in the cases where the stories are complex enough to warrant them.

Second, building visible story tests for customers is costly, given today’s tools, and often the team and its customers do not get enough value to make it worth doing customer-visible story tests.

Third, Jim’s teams have found that intensive TDD, including unit tests, integration and some story tests, gives them enough confidence (and enough real quality).

To the first, I’ve seen plenty of teams where the customer (Product Owner) was too busy to create examples. I’ve also seen it lead to slow-downs, and to mistakes, especially when things were complex. Examples are a good way to go in those cases.

To the second, I, too, find the existing tools to be way too much trouble to use. On the C3 project, we built our own tool, which made tests practical. We had examples, mostly from the Customer’s helpers, and it turns out that we reported the results to the Customer: she rarely looked directly at the tests. In addition the C3 project had a very complex domain, which made the tests more valuable.

To the third, I remain a bit uncomfortable. Certainly, if the team is producing very few defects, then what they are doing is working. I would be interested to know some statistics, notably: How often, when a defect arises, could the defect have been prevented by a story test that was not written?

My bet would be that missing story tests will be associated with the majority of story defects that are discovered.

Does that make Customer-owned Acceptance Tests written with Fit or equivalent worth while? No, not if resistance is high enough and value low enough.

Does that make story tests automatically worth while? No, not if errors are infrequent enough.

My conclusion is that certainly what Jim’s teams are doing is working, and they are doing all the XP practices quite well. If other teams do the practices that well, they’ll probably have similar results.

And I think that automated story tests are the simplest and most certain way to prevent defects cropping up in stories later on.

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.