I have seen this “developer owns a feature” a lot. What does it lead to? If “dev owns…” then they typically work alone on the feature. So then end up coding and then handing off to QA. In other words, they’re back to where we started with serial phased waterfall development. You will also see, miraculously, the same number of stories as developers. Each developer will take one, and none of the stories will complete until the end of the sprint, when some of them will complete and some won’t. So you lose the benefit of swarming and you also lose the benefit of moving testing forward in the development process.

(My current company uses Pivotal Tracker, which is one of the online tools that actually have a field called “Owner” for each story. Rally has one, too, as do other Scrum tools. I have no idea why that field is there or called that, but it is one of those cases where a tool encourages bad behavior. )

Let’s think about this. If a developer owned a feature, or a set of stories, and other developers and testers worked on those stories, too, then would there be a problem? Not so much, IMHO. In fact, there are some nice side effects of such a model. Being the owner of the story or theme or feature or set of stories becomes a kind of scrum-oriented technical leadership position. The position lasts as long as the story or the feature is being developed. This person can be the domain expert and can “lead” the design of the feature, and they can also mentor the others working on it. Using this approach I have found to be helpful when trying to map scrum into existing performance review and promotion models. I mention this because the thing that is so poisonous is not “developer owns a feature” but “developer owns a feature and works alone on it until coding is done.”
So how do we get from “developer owns a feature” to “team owns a feature”? As a coach, I think it’s important to find a way to evolve there rather than try to just legislate it. Just saying “no more dev owns a feature” sounds like you’re taking something away from people. People will resist. Can we find a stepwise way to evolve this? I think this is the coaching challenge here.

One thing I tried that was not perfect but it helped, was to emphasize the risk management approach. Obviously, it’s nice to have an expert who can work within a domain faster than anybody else, but if you only have one guy per domain, you run the risk of not being able to do any work in that domain if your guy goes sick or leaves. Then you are way behind the eightball. (I used to try to convince people that it wasn’t necessarily true that the most experienced guy in the domain goes the fastest and writes the best code, but that one is a tough sell. There’s even that cute story about the teams that chose to work only on things they didn’t know about and it actually increased their velocity, but people don’t believe it.)

So, back to risk management. Even the most feature-hungry, speed-freak executive should fear having zero people who can work on a problem. Having just one is the same as having a single-source supply chain. It’s a disaster waiting to happen. It is Management 101 to work to mitigate risks like this, and the way you mitigate risks like this in Scrum is you spread knowledge. In scrum you spread knowledge by allowing or encouraging people to work on new tasks. People working on a new task use the experts on the team to help them learn enough to complete the task. I would argue that the manager of a scrum team that doesn’t do this is guilty of bad management, from the company’s point of view. That manager is not doing risk management. So you work to get the idea of knowledge distribution to be a part of what the team is expected to do and it starts to break the “developer owns a feature alone” pattern.

Here’s another evolutionary approach: mentoring. In most large companies, experienced engineers are called upon to help younger engineers learn. In many companies, it is considered a part of the senior job descriptions and they are often graded on their mentoring activities at review time. In the old, “wasterfall” days the way people would learn new things was their manager would say “Sure. Go ahead but don’t spend more than 10% of your time on it.” That was because we had no other way back then to cleanly allocate a small amount of somebody’s time and energy to a specific thing like learning a new domain. In scrum we can do better. Why not let an experienced person mentor an inexperienced person in the scrum way…by helping the inexperienced one work on a task with which she is unfamiliar?
What happens when we let somebody take a task on an unfamiliar story and plan to ask the ‘lead’ any questions? Well, you then have two engineers working on that story! One is the experienced one and one is the newbie who is learning. Two engineers on the same story? Why, it almost sounds like scrum!

The point of the preceding two ideas is that they are a way to start to get more than one person involved on a project without having to win an argument.

Once you can get tasks to move around, the rest will follow without having to coerce people. That is my experience, anyway. The thing I like about this evolutionary approach is you don’t have to have a big fight or debate with anybody up front. You don’t have to make people do large change. All you have to do is find one person who is willing to take on one task for the pure joy of learning. And it’s usually easy to find some engineers who want to learn new things. If you can’t find one of those in your organization, you have other issues.

Dealing with documentation is often confusing for new Scrum teams. Many teams overdo the rejection of project documentation when they start to become Agile. Tribal knowledge can appear to be all you need on a tightly knit team, especially one that is also embracing emergent architecture and design.
Another reason teams stay away from documentation is that they think that “there is a rule” against documentation in scrum. I’m reminded of the developer who, in response to a very pointed accusation of technical negligence during a post-mortem at a famous internet company said, “Well, we wanted to do a better design, but we were doing scrum so we weren’t allowed to.” Yes, it is as lame as it sounds, and it’s not true. The scrum framework doesn’t prevent or prohibit anything, it merely challenges you to do the right amount of the right things for the right reasons while you are developing.

Tribal knowledge has its limitations. While it is healthy and productive to Just Say No to the kind of rote documentation requirements that burden many teams, it’s also true that there can be a lot to remember about how a system works and it’s not a sin to use documentation to improve the ability of a team to work to the best of its abilities.

The key to deciding when and how much is the nearly banal idea that Scrum gives you many options in almost everything you do, documentation being no exception. Scrum does not forbid documentation. It simply says “create the right amount, at the right time.” The cool part is you can do that in Scrum, which leads to the best documentation possible. But beware. You need to think through your needs. Check out the following cautionary tale:

My first Scrum team decided that they wanted to do the best job ever on their technical documentation. The team wrote quite a few designs during the first few sprints of our 18 month project, but soon they settled into a comfortable routine where the need for a design or other document was recognized by all when a new story was activated. We started to accumulate dozens of small, story-sized design documents on a wiki page designed for easy browsability. So far so good.
Then, the inevitable happened and a new guy joined the team. As the team’s manager and Scrum Master (yeah, yeah, I know, but that’s not what this post is about) I was bursting with pride as I familiarized him with our documentation wiki and its over 100 design documents.

“Just go have a read and let us know when you’re ready to dive in,” I said, expecting to see him in a week or so. Next day, new guy shows up with a glazed look and says, “Could I just get a bug to fix, please?”
Moral of the story: Even really great, up to date, accurate, and correct documentation is not a silver bullet.

Remembering this story makes me smile whenever people bring up this topic in CSM classes, because the “new person joining the team” scenario is the favorite example that people use to demonstrate the crushing need to have extensive technical documentation.

Scrum allows you to write documentation contemporaneously (I hate to brag, but I spelled that correctly on the first try!) with design and coding, and it is easy to make your documentation correct. The Definition of Done gives you a mechanism that can nearly guarantee that technical documentation can be kept up to date as the system changes over time.

Think about your documentation requirements by thinking of the problem you are trying to solve. Do you only need design documentation? Are you required to provide documentation for compliance with standards or laws like SOX? Will the documentation be for communication with other teams within your company? Will it be input to a separate department that produces extensive user manuals? Each of these needs drives different approaches to documentation. Agile teams are expected to make conscious decisions about what they do and why they do it, and documentation is no exception.

Oh…so what happened with my Scrum Master and his team and their documentation debt? I don’t really know. Not my job. It’s up to them, isn’t it? If you really want, I’ll send him an email and ask him.

They’ve only been doing Scrum for five months now and they’re doing well. They’ve been producing potentially shippable software each sprint from the very beginning. They inspect and adapt, although there’s still a lot of help required from their managers in that. They do stories and grooming and planning. And they’re now writing automated tests. Wowie.
And an unexpected thing happened that is interesting enough for me to write about it. Here’s what it is: our quality went down.

Yup. We’re doing more software. We’re releasing more often. We’re writing automated tests, both unit and functional. What could possibly go wrong?

In the old days (before last June), they used to release maybe three or four times a year max. And for each release, they would spend a week or two or more testing. Everybody testing. And the software was pretty good and the testing was pretty good and so it went out and the production software was pretty good.

Then we became Agile and started releasing more. We started writing automated tests (over 225 done on the back end system, and the handset application team has begun to write their own automated tests). We prepared to release each sprint. And we stopped doing huge manual testing marathons the way we had done in the past. Everything seemed OK until maybe Sprint 6, then we started to notice small problems in production after the release. Bad SQL. Broken javascript. Small stuff, but noticeable.

So what happened? We stopped testing, is what. But Agile says don’t do manual testing, do automated testing and we’re doing that. Aha, but writing automated tests isn’t quite ‘doing automated testing’ until you have enough automated tests in place to really make a difference. That’s what we seem to have missed. We stopped our manual testing (those three week marathons) because we figured that because we had started writing automated tests, everything would be OK.

Somebody smart must have already said that “A poor test that is executed is way better than a great test that isn’t executed.” (In case nobody said it, I say it all the time so I’ll take credit.) We forgot that. We didn’t have enough tests to execute, so in effect we weren’t testing, and we didn’t recognize it and supplement with old, manual tests. So now we’re figuring that out, and it’s tricky because we don’t have three weeks each sprint to spend doing manual testing. Unfortunately, we’re probably a couple thousand test cases from being up to speed on our automated testing. We’ll have to inspect and adapt a few times on this.

And yes, you’re right, the title doesn’t really match the article, does it? Still, I like it.

I used to make money as a coach/consultant but now I’m back in product development. I have found that in some ways being an Agile coach or consultant is relatively easy compared to the jobs that most people have. Most people can actually fail at their job, but it is hard to demonstrably fail as a coach. Most people have to live with the consequences of their recommendations, but coaches often make their recommendations and move on. Most people must deliver some kind of results in their job, but coaches mostly deliver knowledge.

Recently, I went back into product development as a CTO, so I have to deliver on my own behalf and also on behalf of my organization and my company. It’s hard and scary and exciting and fun. I missed the pressure to deliver when I was a coach, but now I have a different problem. Now I have to try to do Scrum well while the real world conspires against me! I know that doing Scrum well is the way to get the best from development, but it is pretty difficult to make it look like the book. Er…books. Um…any of the books. So I think now I am experiencing Industrial Scrum.

I came to my current company to make development more responsive to the business. Sound familiar? What I found is that all the things I coached people not to do keep wanting to happen. It’s basically impossible to Disneyland Scrum out here, even for a CST ex-coach. Here is how things have turned out so far doing Industrial Scrum:

a) Engineering is now definitely more responsive. We are doing recognizable, scrum and showing potentially shippable software each sprint. (Editor’s Note: Good)

b) There is a client team and a server team instead of an integrated team. We tried having one team doing both client and server stuff, but it did not work well at all. (Editor’s Note: This will get me dumped upon if I say this in some of the Scrum discussion groups online.)

c) The Scrum Masters are also managers. I had no choice in that. You can’t just add people and there aren’t extra people hanging around. (Editor’s Note: At least it is not an official party foul to have managers be scrum masters even though it is second best.)

d) The teams are distributed across the US and China. Guess what? Daily scrum is a real pain because of time zone and language issues. Huge credit to the teams…they have dealt with the time zone problem. Language is harder to deal with, and they now run their daily scrums in Campfire as a text chat. It works much better than audio. (Editor’s Note: Coaches tend to insist that you are supposed to do audio or video in the daily scrum.)

e) We have one Product Owner for two Product Backlogs for two teams. He does not attend either of the two daily scrums. He is untrained and he is also VP of Marketing. Yet he does reasonably well at being PO. (Ed. Note: Not very good, but it’s what we could do.)

f) The training we have done has been spotty. We haven’t taken a day to do Agile team training. (Ed. Note: You mean to tell me that you have a CST/CSC as the CTO and people are not well-trained??????)

g) Everybody does not love Scrum, but they are getting stuff done and it is improving over time. The most bitching is about the number and length of meetings, and about my harping about automated test. (Editor’s Note: Sigh)

h) Much of the company attends the sprint demo every two weeks. (Good)

i) The execs are in Stage I of Agile Transformation: they still talk about projects and dates, but they also have started to use Agile words (usually incorrectly) in their conversations. (Ed. Note: The execs are usually the toughest to change anyway.)

j) After four months of Scrum, the teams are starting to break stories into tasks. (Ed. Note: Good, but what took so long?)

So, I guess I’m OK. Scrum is robust. Industrial Scrum is ugly but it delivers, and it is not ScrumBut. My goal when I came here was to build a successful Agile organization, and I think I’m on my way. There is a lot of training and transforming and adapting to do, still, but yup, we are on our way.

I have one word for you: China.

I’m returning from the Shanghai Scrum Gathering held this past weekend. The theme was “Let Agile Fly”. It was a great gathering. In terms of sheer joy, exuberance, wonder, and excitement it equaled or bettered any conference or gathering I’ve ever attended. In China, things are in a very early stage and people are excited in the way people were excited about Scrum ten years ago in the US.

This was my third scrummish trip to China. I had a great time renewing connections with the two Daniels (Gu and Teng), the Li brothers (Mike and Bill, who aren’t actually brothers), Shining Hsiong (the rock upon which the Chinese Scrum Gatherings seem to rest), Julien Mazloum and Brenda Bao from OutSofting, Ethan Soo of CGC, the extremely cool folks from NetCircle, the Odd-e Outlaws Kiro-san, Stanley, Terry, and Steven, my fellow working CST Vernon Stinebaker (we both have engineering management jobs in addition to being CSTs), and my new Scrum brother Alan whose last name I either don’t know or can’t pronounce. I got to meet Mike Beedle, co-author of the first scrum book with Ken, who is an imposing intellect with a lot to say. He also eats like me, which means anything that won’t bite back is fair game.

I learned last week that “Chinese people are very practical.” They grasp the lofty thinking but they crave the nuts and bolts advice that they can put to direct and immediate use. Gerard Meszaros was smart smart smart and I and they loved his emphasis on actual code and engineering practices. Gerard’s bumper sticker from the lofty ideas part of the Gathering: Agile is an operating system, not an application.” Hmmmm. Maybe you had to be there. The practical details continued with Lance Kind on the TDD side and Erik Petersen on the testing side. These guys were adept and experienced, and a whole bag of monkeys fun, too. And to think I’d never even heard of them!

400 excited folks gathered at the Huating Hotel in Shanghai for the two day gathering, which sported four complete tracks with English, Chinese, and mixed language presentations. The venue was great. The attendees were a mix of consultants and experienced Agile folks along with lots of real people practicing real Agile in the real world at work in China and there was a good smattering of tire kickers new to Scrum, too.

I really had a great time during the 90 minute Open Space. It was wild. In ten minutes the hotel staff converted the orderly rows of chairs in the main room to a giant circle, and several Chinese facilitators got people to propose topics. We put the titles on big sheets of flip chart paper and all marched around the circle holding up the titles so everybody could see what was available. (This is the closest I will ever get to being a ring girl for professional wrestling.) I think there were about fifteen topics. Each topic owner then found some wall space, taped up their title page, and people gathered for the session. All of them in the same giant room. The hubbub was fantastic. I did a session called Practical Basics of Scrum, and I think it was the only one in English. We covered the entire Scrum machine and probably two dozen random Scrum questions in the time we had, and it was difficult to end it. I haven’t had that much fun since playing the ballpoint game at Amazon outside a board meeting and having Jeff Bezos come out and stare at us before he continued on to the bathroom.

I stopped in to a lot of the presentations over the two days, and I am happy to report that China is clearly growing its own generation of Agile practitioners and thinkers who can teach others. The level of expertise was high and the questions were very probing. It’s odd to sit in a presentation and not understand what the presenter is saying and at the same time to grasp the thrust of the material by just watching the slides. The general level of interaction was very impressive.

The retrospective was interesting. We all divided into teams of 9 using a very weird method that I did not understand at all since it was all explained in Chinese. I just depended on people pushing me one way or another at the right times. Then each group got a large drawing of nested ovals. In the outer ring we all put four things we liked about the conference. Then we each put down three feelings we had during the conference. Into the third ring we put the two most valuable things we had learned. And into the center we collected the outstanding items from the previous rings to summarize. Then each team reported out to the others, to much hilarity and applause.

No description of the conference can be complete without mentioning Ripley (Believe It Or Not), the graphic recorder. She just sat in the main room and drew what was happening during each session. The pictures that were captured were so interesting and wonderful I hope somebody can post them somewhere somehow. Hers is a real talent and she totally enriched the whole Gathering with her work.

Two more things I have to say.

One: the conference was put on by ALL VOLUNTEERS! Amazing job by all. Flawless.
Two: the very best thing was at the end of the wrapup and retrospective, when a giant rugbylike scrum formed with people yelling and grunting and pushing and shoving for no apparent reason other than that they were just so full of joy. I have never seen anything like it, but I hope to see something like it when I go back next year, because that’s what I intend to do!

alan

I know we’re supposed to have daily scrums, so I’ll schedule them in everybody’s calendar. Gotta find a place to meet, where we can meet every day. Same-time-same-place is a good idea. Do we have to decide as a team or am I allowed to actually make a decision? Hmmmm. I remember “Ask the team” from my training or some blog or somewhere. Can’t possibly go wrong with that, can I? How about the hallway outside of my cube? I can hang all of the flip chart sheets with story cards on them there.

Ack! What about the burndown? Guess I better draw up one of those, huh? One piece of flipchart paper. I guess it’s…what the heck was that…oh yeah, total estimated effort from the Sprint Backlog tasks. No Product Backlog item estimates included…just the estimates of tasks.

We only had time to really pay attention to the first part of the Product Backlog during our Sprint Planning. That part is now in this sprint. What do I do about the rest? I know if I ignore it, it’ll be a pain to dredge it all up at the next planning meeting. Oh yeah! They said something about this. I’ll schedule an hour of team time at the beginning of the second week of the iteration. We’ll get together and talk about the rest of the Product Backlog. We can estimate and re-prioritize it then. No doubt we’ll add a few PBIs (heh heh…I was the one who asked what PBI meant during the coaching session. Product Backlog Item. I like to call ‘em all stories anyway.) and maybe dump a few, too. Product Owner needs to be there. Hah! Better be there or we’ll start making decisions without him. I better go talk to him. It’ll be good to have the PB ready to go for the next iteration planning. Maybe we can get out of there in a couple of hours instead of all day like last time.

What else? Better reserve conference rooms for the Sprint Review, Retrospective, and Sprint Planning meetings coming up. In fact, while I’m at it, I think I’ll reserve rooms for the rest of the year! I already know when I’m going to need them, right? And I can stick invites onto our manager’s calendar, and her boss, and his boss (my grand-boss), and…why not? The VP (my great-grand-boss)! And how about UEX folks, and their boss, and maybe a QA manager or two? I really want them involved so we can talk about getting them more closely involved in the sprints anyway.

So what if nobody comes? At least they’ll know something new is going on. And all I need is one or two people to show up once and see something unusual or interesting, and they’ll mention it to other people, and who knows what’ll happen then?
It can’t be this easy, can it? Heck, I still have enough energy to start my Impediment Log, where I’ll keep track of all of our blockers. That ought to be interesting to look at in a couple of months.

And I might as well start looking at http://groups.yahoo.com/scrumdevelopment. There’s all kinds of stuff to learn still, I can see that. Hmmmm. I wonder what this Kanban thing is all about?

I have a degree in behavioral psychology. It’s not the only degree I have, but I do have it. To the best of my knowledge, the only time I actually used it was to cover up a really bad stain on the wall of a rental apartment I once had in Louisville, KY. But you do learn a bunch of really interesting stuff when you study psychology, and in behavioral psychology you do some really neat experiments.

Here’s one of them. You put a pigeon in a special controlled environment called a Skinner box, and you arrange it so the pigeon gets some food every couple of minutes on a completely random basis. Then you go out to lunch or to Comparative Religion class, which you have to take in order to satisfy something called a “distribution requirement” in order to graduate. Apparently, taking classes like this guarantees that you will appear to be really smart and other people will then want to go to your college.

Anyway, when you come back to your experiment, you will find the pigeon behaving in really strange and unpredictable ways. She (?) might be whirling in circles, or plumping her feathers up and down, or bobbing her head, first up and down and then side to side, or maybe just hopping up and down on one leg. What the heck is going on? You have just demonstrated superstitious behavior, which is defined as behavior that is directed at getting certain results (in this case food) but which in fact has no effect whatsoever. In other words, the pigeon thinks that whirling in a circle is causing the food to appear because a few times early in the experiment she happened to be turning in a circle when the food appeared. She incorrectly put 2 and 2 together and decided that whirling in a circle brought the food. (When I explained this to the pigeon later, she took it very graciously. She went on to become the only pigeon in the history of the Brown University behavioral psychology laboratory to successfully steal the cheese out of a rat maze during a running experiment. So you don’t need to worry about the pigeon.)

Is there any possible way that I can relate this to Agile software development? Of course there is!

What happened at your company the last time a big project laid a gigantic Egg of Failure? Very possibly, a post mortem meeting generated a number of suggestions to prevent it from happening again.

Here’s the connection I promised you: most of those suggestions were based on superstition. They were based on events that were co-located in time but not which did not have an actual causal relationship. Check it out:

• “Next time, we won’t start until the Requirements doc is done and everybody has signed it.”
• “Next time we’ll require management sign-off before pushing to production.”
• “Next time, we will get all of the Principal Engineers in the company to review the design.”
• “We had a document that listed the dependencies, so that couldn’t have been a contributing factor.”
• “Lots of people took too much time off at critical junctures. We should restrict that.”
• “We need to supervise people more closely next time to make sure they do what they say.”

I mean, how different are those than

• “Next time, we’ll all throw salt over our left shoulders before each status meeting.”

Why do I say that superstition is involved? Because these suggestions are based on circumstantial evidence of the form “We did or observed this thing on the project, and the project went bad.” It’s hard to make decisions with the kind of delayed and non-specific feedback you have in that kind of post-mortem situation. When nothing gets finished until the very end, it’s hard to pinpoint where things went wrong. Conversely (inversely?, obversely?), when you can’t experiment to see results immediately you can’t determine the true underlying causal relationships. You can’t find root causes.

This is a big strength of Scrum and other Agile methods. We don’t have to depend on superstition. We don’t have to make things up and we don’t have to guess. We can take small things to completion and get feedback immediately. We can apply a lesson learned overnight, and in a few days or a week or two, we can see if it has the desired effect.

This is why you don’t see Agile developers whirling in circles, tearing their hair out, hoping to get food from the box and wondering why they don’t. They are in a pretty good position to either know what matters, or to find out what matters. In case you were wondering.

You may or may not know that Scrum comes complete with a set of values by which we are supposed to guide our daily professional lives, or at least our life within the team. Of the five values, Commitment might just be the most famous. It’s supposed to be really important. It’s supposed to be a Bad Thing if a team can’t commit to delivering a certain amount of value each sprint and then deliver it.

So here I am, going “Well, uh…if the team just gets on with it and develops stories in value order then who cares about commitment?  They’re gonna go whatever speed they go and committing ain’t gonna change that.” Fair question, right?

I look at the Agile estimation process and I like it, especially when it’s done correctly. Then I think, “No way does this lead to any kind of exact or accurate estimate. In fact, it’s not supposed to!” How could anybody possibly think that this is exact enough to hold a team to a standard of completion or a commitment to deliver? And what a standard! Some coaches will tell you that teams should be able to complete 90%+ of what they commit to. Others will say the team should hit its commitment 100% on four out of every five sprints. Those are some really high expectations.

My problem is that I just don’t get it. I can’t make it logical. First of all, it can’t be a do-or-die commitment because that’s not sustainable and hence, not Agile. It can only be a “we promise to try really hard” commitment, which has always seemed a little wishy-washy to me. So if I’m not committing to getting a bunch of stories completed do-or-die, then what is my team committing to, really?

And back to my original question, what happens if you don’t commit but you still do work anyway?

I keep thinking, “If the team builds the most software possible in the timebox, then what does commitment have to do with it?” “If we measure the team’s ability to produce valuable software using velocity, then doesn’t that make things predictable and thereby solve our need to support business decision-making?” Does the team do more or better work when it commits?” “What does commitment mean if it doesn’t mean ‘at all costs, even if we have to work around the clock’”?

So, after a couple of years agonizing, unable to confide my doctrinal sins to my wife or my boss or colleagues, I think Ifinally got it. Michele Sliger gave me the lightbulb,  but I don’t remember exactly what she said. But I know it was her, because when I woke up that morning I still didn’t get it and then I drank beer with her and when I went to sleep that night I had my new version of it. So I will paraphrase what I don’t remember that she said.

The thing a team commits to when they commit at the end of the sprint is not the list of user stories per se. What they commit to, at least in terms of what makes sense to me, is a unified, focused (another scrum value), relentless, best-effort sprint oriented around those user stories.

In other words, and this seemed strange to me when I first thought it but I can’t analyze it away, THE SPRINT COMMITMENT IS THE WAY A SELF-ORGANIZING SCRUM TEAM PROVIDES ITSELF WITH DIRECTION AND INSPIRATION.

That is too weird for words, isn’t it? The sprint commitment is a surrogate for a manager? I guess so.

Now I understand when people admonish against labeling a sprint that completes all of its committed user stories as a “success” and labeling a sprint that misses a story as a “failure”. A failed sprint is one in which the team does not maintain a relentless, focused, unified, professional effort based on the committed Product Backlog items.  A success is one in which the team does that, regardless of the number of stories that are completed. Sure, we worry when they don’t display predictability and we retrospect and fix it, but the team doesn’t fail if they are working well and the technology bites back or random Acts of God get in their way. They fail if they don’t work well. They fail if they don’t pay attention. They fail if they don’t build quality software, or if they don’t bother meeting the Definition of Done. They fail if they don’t build the most valuable software that could have been built in the sprint. Otherwise, they succeed.

And Commitment gets them there.

Teams that work on systems with a Client-Server architecture traditionally divide up into a Front End team and a Back End team. It seems pretty logical, doesn’t it? The developers that consider themselves front-end people, or GUI people, all get to concentrate on the user experience, while the back-end people aren’t burdened by those concerns. They are just the hardcore folks who wrangle the data. Often, they’re the ones ‘close to the iron’.

What happens when these teams adopt Scrum? In the best of all possible worlds, somebody on one of the teams notices that the Product Backlog of one or both teams doesn’t really contain items that deliver customer value. The Back-end team has items like “implement database connection pooling” or “archive audit logs”. The Front-End team has Product Backlog Items (PBIs) like “As a user, I can see my account balances” and “As a user, I can cancel my account if it has zero balance.” The teams are assigned to components and it is impossible for either team to work on a single Product Backlog item that cuts through both levels of the architecture (client and server) in order to deliver a complete feature. In that best of worlds, somebody notices it and sees a better way.

At Sprint Planning time, the teams realize that they must carefully choose PBIs that go together in order to deliver a sensible product increment. It takes a “front-end” PBI and a “back-end” PBI to deliver one customer-visible feature. During the sprint, the two teams find themselves slowed because they have to coordinate with each other. Often, they start to point fingers at one another as problems arise that transcend the ability of either team to address independently. Neither team can succeed (i.e., deliver a feature) without the other. Freedom of action, independence, ownership, and commitment start to fade as driving factors and we find ourselves back in the morass of complex, interconnected waterfall-style plans.

Dependencies! Integration! Oy, is there a better way? There is. This is a case where the back-end system is not delivering customer value.

Try this: reorganize the teams. If possible, make them into one single cross-functional scrum team. If there are too many people for a single scrum team, and if that many people are really needed,  then create two cross-functional scrum teams. In this case, what I mean by “cross-functional team” is that each team will be able to develop front-end, back-end, and test software in order to deliver fully-formed, fully-tested customer features. They will not need to go outside of themselves in order to complete the PBIs.

With this organization, your single Product Backlog will consist of well-formed items that describe customer-visible value. Cross-team dependencies will go away, since the dependencies between the client and the server components are resolved within each team. No more finger-pointing. No more need for careful coordination. You can even move to separate sprint planning once the two teams have chosen items from the single, unified Product Backlog.

This is a great way to handle client-server architectures in Scrum. All development activity is focused on delivering completed features to the end user, and everything conforms to the best ideals of Agile software development.

You might also be at a company that is early in its Agile transformation, and your team might be working on a component of a large system because your organization hasn’t yet implemented Feature Teams. Hopefully it’s a shared component with multiple customers from different systems or applications, but no matter.

The problem is, what will you do when it comes time to demo your product increment at your sprint reviews? How will you show that your software is doing something that is by definition invisible to end users? How will you make your demo dramatic and compelling for your invited guests (you *are* inviting outsiders to your Sprint demo, aren’t you)? How will you keep your audience from falling asleep without doing extensive, wasted work to produce a spiffy demo?

Here are a few suggestions:

Your audience might not be able to picture the system context of what they are about to see. There’s a great post about this in the Agile Project Manager blog (http://agile-pm.blogspot.com/). The idea is to create some visuals (I think this is a euphemism for slides) that show the audience what is about to be demonstrated. I recently saw this being done at a client of mine and it worked really well. In fact, I had the impression that the business folks who attended this particular sprint review might not have been there at all without the introductory slides to explain to them what they were about to see. At least when they saw the very unexciting demo of hidden software doing invisible things correctly, they could begin to appreciate everything that they just didn’t see.

The next place to look is to your automated acceptance tests (you have them, right?). How long do they take to run, and how do you monitor them? There’s nothing wrong with running your acceptance tests during the demo and let the real-time test results provide the show. Many teams have web pages or other reporting mechanisms that show the success or failure of individual tests and test suites. Coupled with some graphics, this can demonstrate your software in a reasonably effective and interesting way.

Does your software run in a production environment? If so, then you must have any number of system monitors that tell you not only the basic health of the system, but I bet you also have things that show real-time system behavioral parameters and usage data. These are another good way to demo your software feature, and if you don’t have these things, you will become addicted to them if you begin to create them. Use them for demos and later for monitoring your apps in production. You might even get a Christmas card from the folks in ops.

The ides is that there is always a way to show someone what your software is doing. Be creative.