What Kind of Manager are You?

August 25, 2013

Over the years people have identified some styles of management with cute names. Most of the cute names are for obviously bad styles, but not all. Anyway, since I’ve learned a new one recently I thought it miht be fun to review. So I did, and by golly! I found a bunch of different styles to talk about.

The Seagull

My favorite, not because it’s the best style but because the definition is so amusing, is the Seagull. Seagull managers do to employees what real seagulls do to diners in open air seaside restaurants. They fly in from nowhere, screaming loudly, crap all over everything and everybody in sight, and then fly away.

There are two things that are interesting to me about the Seagull. One is that sometimes they actually do unblock a jam or cause action. Not a great way to do it, obviously, but it occasionally works. The other interesting thing is that seagull managers invariably give themselves credit when whatever project they crapped on finally gets done. The never notice that it was well on its way all by itself, or that the mess they made was simply added to the work needed to finish the project and not a help at all.

The Wishful Thinker

The Wishful Thinker bases decisions on unrealistic hopes for success (i.e., luck). Unlike the cautious “Hope for the best and plan for the worst,” the motto of the Wishful Thinker is “Assume the best, the more unlikely the better.” I once had a boss named Roger Gourd, who used to mimic the Wishful Thinker’s whine as a way to remind people that they were guilty of wishful thinking: “If we only had some ham, we could have some ham and eggs, if we only had some eggs!” In other words, stop making it sound like you have something going in a case where you really have nothing.

The Ostrich

This one is pretty simple. The Ostrich does what real ostriches are said to do in times of difficulty, which is to stick their head into the sand and refuse to see the danger in an effort to prove that it doesn’t exist. It is a refusal to see the objective situation. “No, we don’t have that problem!” Something to keep in mind if you are an Ostrich is that when your head is in the sand, it makes a different part of your anatomy much more visible.

The Oracle

Sometimes we have to ask difficult questions of the boss, and we depend no the information or the decision in order to continue to make progress. Sometimes the question or the answer is uncomfortable, which of course is why they get the big bucks. The Great Oracle handles this situation by ignoring the question and refusing to answer. This is the manager to whom you have to send the same email request three times or more in order to get a Yes or a No. Since you are forced into being an annoying pest in order to try to get answers or approvals or direction, you will tend to avoid trying. And so you will often take no action.

The Sightseer

Management by Walking Around has been…well…around for quite a few years. It originated at HP in the 1970s and was popularized by Tom Peters and others in the 80s. It used to be held up as a great thing because it meant you were out with the folk and not locked up incommunicado in your office. You were then supposed to be in better touch with the actual situation. It is similar to the Lean idea of gemba, which means“the real place.”

I have recently seen some discussion that characterizes this style as “active micromanagement.” I’m honestly not sure what to do with that because I always thought of this style as positive. I guess it’s possible to be too active and intrusive while you are walking around and I think that’s what the micromanagement caution is about. So be careful and follow the Star Trek rule – don’t interfere with the local civilization while you are observing it.

The Collaborator

Here’s a thought. What if you treated your employees as knowledgeable peers? What if you shared problems, ideas, and solutions with them? What if you brainstormed along with them and brought your experience, knowledge, and business perspective into the discussion without directing it or squelching the ideas of others? That’s tough to pull off, but I bet you can see which of all of these styles would be the most powerful. Um, can you?

The Caretaker

Also referred to as the Servant Leader, this one is about being there to help the employees achieve their best they possibly can. The Caretaker is a mentor and helper and partner and peer who is not so much into being in charge, but more into helping others succeed. This is the Agile model and it is a high bar that is difficult to attain.

Metrics for Your Scrum Team

March 18, 2013

I have spent the past couple of years as the owner of some scrum teams and when I integrate that experience with years of doing, teaching, and coaching scrum I find that I have finally found some good ways to use metrics. This article is for all of you managers and scrum masters out there who might be looking for some suggestions.

Here are some things metrics won’t do for you:

• Metrics won’t tell you if you people are “working as hard as they should”
• Metrics won’t tell you which individuals are “good” or “better than others”

What I’m saying is that just because you have metrics doesn’t mean you should use them any way you feel like. Used incorrectly, they will sap the will of your teams and employees and eliminate the gains you might otherwise get by using scrum. The funny part is that there isn’t any metric out there that will tell you if your teams have become uncaring, unmotivated, disengaged, unproductive drones due to your misuse of metrics!

So let me first dispense some warnings. Here’s what not to do with metrics:

• Don’t use team metrics to compare the “performance” of Scrum teams
• Don’t use team metrics to either reward or punish individuals regarding pay or promotions
• Don’t use team metrics to make customer commitments
• Don’t use individual metrics, period.
• Don’t try to measure “software product development productivity.”

“Sheesh.” I hear you cry. “It seems like there’s nothing I can do with metrics, then.” Fear not.

• Do use metrics as part of an inspect and adapt process to improve team performance
• Do use metrics to gauge whether a team has a healthy or unhealthy agile development process in place
• Do encourage, allow, and help your teams to use metrics to improve.
• Do rotate your use of metrics. Don’t use the same one for more than six months.
So what metrics can I use to tell if my teams are doing well? Here are a few:

• Total Defects
• Total Defects in Agile Code (reported after story completion, aka “escapees”)
• New Defects in Agile Code
• Defects in Legacy Code

Total Defects tells you something about the condition of your entire product. Total Defects in Agile Code and New Defects in Agile Code tell you how well you are doing in achieving the Agile potential of zero defect code. You should be looking for total defects to level off over time, and then to turn south and head towards zero. What you do to make that happen is a subject for another day, but you can’t attack defects it until you can see your defect picture on a nice, simple graph.

Does it go without saying that if you are doing Scrum and you can’t get these under control then you have some significant problems in either your scrum process or your engineering practices? I hope so. If it doesn’t, please hire me as your coach.

• Do/Say Ratio in Points
• Do/Say Ratio in Stories
• Number of stories not completed per sprint

The Do/Say ratio is a way to capture the team’s ability to commit (or predict, depending on which school you are from) and then deliver predictably. Nobody can do this perfectly but a good scrum team can do it very very well. If these metrics aren’t near 100%, then you should look for inconsistent estimation, inappropriate story size, organizational abuse, or persistent waterfall engineering practices.

The ratio is expressed as (what you actually did, or “Do”)/(what you thought you’d do, or “Say”). 100% means you did exactly what you said you would do. 80% means you did less than you expected, and 120% means your team outdid itself. Not being able to predict means that the team doesn’t have a good handle on either the work it is doing or how it is being done.
I find that I want to track both the percentage in points and also I want to know how often a story is missed. Again, this is a general health indicator and not some kind of punishment/reward thing. For instance, if I see that a story was missed twice in the last three or four sprints, then I can ask the Scrum Master if the team has retrospected on this troubling occurrence.

Danger: If this metric is misused, the team will find a way to make these go up by predicting that it will do much less, thereby making it easier to hit 100%.

Relative Productivity
• Average cost per Story Point (in $)
• Average cost per Story (in $)

These take a bit more thinking, but they can be nice to have around. Cost per story point is exactly what it sounds like. It is the total cost of the team per sprint (fully loaded salaries times the length of the sprint probably) divided by the number of points of work accepted. It’s awfully fun to be able to give a quick answer to the traditional “We have a customer who wants such-and-such. How much will it cost to build?”
Multiply the cost per story point times the average size of a story in your Product Backlog and you get Average Cost per Story. Are these interesting? Heck yes. Sometimes the ACPSP goes down (meaning the same team is doing a lot more points per sprint) but the ACPS stays the same (meaning the team is inflating estimates?).

And finally, here’s one that is very uninteresting:


Velocity is only good for one thing, which is to predict progress down an estimated Product Backlog. It’s highly volatile and it doesn’t travel well. Not only is it specific to a single team, it tends to change over time.

OK. There are a few metrics you can use with a scrum team. There are more out there just waiting to be invented and used. Make sure you use them for good and not evil.

It’s Agile’s Fault

February 28, 2013

Last night I launched FourSquare for the first time in several weeks so I could check in from Dubai International Airport, which is another story entirely. No big surprise, FourSquare has been upgraded since I last used the app. Guess what, though? The new version sucks. I hate it. I intend to uninstall it and never use it again.

What did they do that is so awful? Not much, really. They took away the two things I really enjoyed about doing checkins is all. They stopped showing me how many points the checkin is worth, and they stopped showing me where I rank among my FourSquare friends. Can I find those things elsewhere in the app? I don’t know and don’t care. It’s not worth the effort to find out. All I know is it used to be fun and now it’s not.

“All I know is Facebook used to be fun and now it’s not.” Have you heard that recently, or in the past year? It used to be that Facebook was fantastically simple and fun. Everybody loved it. Now, it’s complicated and annoying and even scary. People blog about how bad it is. It seems like if there were an alternative to Facebook, people would go there in a minute.

Don’t forget Swype, the Android keyboard input software that is so amazing. Except that they have now enlarged their dictionary so much that they match all kinds of ridiculous words. They match so many wrong words that it is now harder to text using Swype than not. I mean, who uses words like “euphemism” in text messages?

Who thinks LinkedIn is pleasant to use any more? Not me. Who is tired of having new features pushed at them all the time? Me!

If you think about the software that you use regularly, you may notice that the trajectory of software usability has reversed. We used to stay away from 1.0 versions because we knew that they were broken. It was only with 2.0 that it was usable. After 2.0, features were slowly added that filled out the early offering. There were lots of problems, but usually they were about all of the features we wanted but couldn’t get.

In other words, software used to be born fragile, broken, and feature-poor, then improve slowly over time. Now, it’s the opposite. We use the app the day it’s released, and within a year the developer has added so much cruft and crap that the app has lost its original appeal and we go elsewhere!

On the other hand, there is CraigsList. Still going strong. Still the same features as ever (that is, hardly any). It solves my problem. I’m happy with it. I don’t want anything more. I don’t want to post ads to Facebook or Like them or join a community or make friends among people who sell antique typewriters or have gratuitous graphics leaking all over the page. I just want to post an ad and then go drinking. With CraigsList I can do just that. Bravo!

What is going on? I have a theory.

It’s Agile’s fault.

In olden times, it was hard to build an application. It took a long time and when you were done it was buggy. After release, you spent a year just getting the thing to work as well as you originally expected. After that, you added features at an agonizingly slow pace, causing more bugs as you went. So people were always clamoring for more and as a developer, you thought you could never keep up.

That’s the waterfall world, isn’t it?

Now, you can put reasonable quality software together very quickly. And you can add features very quickly without breaking it. In fact, that’s how we think you’re supposed to build a big thing. You are supposed to do it by building a little thing and then adding to it a little at a time.

That’s the agile world, isn’t it? Iterative and incremental? Keep adding.

But no methodology, framework, or process can decide for you what you should build, or how much of it. More importantly, nobody has ever put any thought into deciding when to stop. Stopping has never been an option. Wise Agile coaches will point out to you that if you have a team that specializes in a component, they will continue to work on that component forever, regardless of actual need. I can now extend that wisdom. As long as you have developers (and marketers), they will continue to add to your application regardless of need.

That’s what’s happening. We are so good at building software now that we build past where users want us to go. Our teams stay in place and they keep adding and changing features because that’s what product teams do. We take something that has just achieved success and change it, a process that the development and marketing people call “improving” it. Nobody ever has a meeting entitled “Should we do anything more with this application?” Instead they have a meeting entitled “What new features should we put into this application?”

Let me challenge the Product Owners out there. Stop improving your app before we hate it. Learn how to say “No” to worthless features!

A Fresh Look at Compensation – Pt. I

July 23, 2012
Principles of a Compensation System

I feel like it’s time to tag up again on the subject of compensation for developers. Compensation comes up as a topic when people are transitioning to scrum, and for a good reason. People are compensated as individuals, but in scrum we begin to understand the role of the team and we find that like in so many areas, scrum makes the problems inherent in many compensation systems much more visible. Because of the risk of pitting individuals against the team under the guise of assigning goals or distributing rewards we have to be more careful than ever with compensation and its handmaiden, performance appraisal, in a scrum environment.

At the same time, we have to take commercial reality into account. Soon after I joined my current company as CTO, we lost a very promising young engineer. He was poached by a company who offered him a 60% raise. 60%. Did this loss hurt us? Yes. Is it likely that free lunches, the chance to learn and grow and control his professional life, flex time, and perhaps the opportunity to work on a team of respected colleagues doing scrum would have made him immune to the poaching? Nope. Possibly resistant, but not immune. I learned a couple of things from that experience. One is that compensation does matter on an individual basis. Very few companies have gotten to that place that Daniel Pink mentions, where “compensation is taken off the table as an issue.” Another was…oh…hmmm…I guess I only learned one thing from that incident. Compensation, individual compensation, matters.

Many coaches are against differential rewards to individuals within the context of an Agile team, but after a year of running a development organization I have come to recognize the desirability and the need to reward peoples’ varying levels of contribution. All of these new perspectives have changed my overall thoughts on compensation systems. I recently saw a list of “Criteria for a Good Compensation System” (from 2008) by a guy named David Maister. I didn’t agree with most of it, but I liked the idea of having a list of principles for designing a compensation system. Thank you, David, for the idea of having the list. Here’s my list:

  • Overall, we want to reward team results and individual contribution so we must find a way that those two things don’t conflict.
  • Rewarding people for their contributions is healthy and fair as long as the determination of relative contribution levels is transparent and reasonable.
  • A compensation system shouldn’t get in the way of the actual work. (It is dumb to arrange the work or the organization in order to make evaluating people easy.)
  • Paying people enough so that money is removed as a concern is a lovely concept that is rarely achievable in practice. Assume that money matters to people a lot.
  • Compensation is a retention tool. In a world of limited resources (money) you must use what you have to safeguard the people who are hardest to replace.
  • Some people just plain do more or better or quicker or smarter than others and they deserve better compensation, even within the structure of a team.
  • It takes a team to build something non-trivial. A compensation system should support and reward the team, or at least not conflict with it.
  • In a self-organizing team, it is the team that knows best the truth about who contributes what. Managers, stakeholders, and other outsiders can also contribute toward the complete picture.
  • We will not forget about intrinsic motivation. We will allow people Autonomy, Mastery, and Purpose. (But we won’t pretend that the money doesn’t matter.)
  • A compensation system is about compensation, which is about rewarding relative job performance, contribution to the company, and the creation of value. It’s not about motivation or self-development or communication between managers and employees or anything else.

Using those principles, we ought to be able to design a compensation system that will work for us in our  commercial Agile environment. We will also try to use these principles to try to generate strategies for Scrum Masters and managers who are trying to carve out an Agile enclave in a non-Agile environment. More to come…

New Information

February 20, 2012

I mentioned in my last post about the Indian shower design thing where they tend to leak all over the bathroom floor. Well, on my way to Shanghai yesterday I was sitting next to a Swiss guy who happens to be living in France but is moving back to St. Louis next week. Yuh…huh. Anyway, he had read an article in one of the Indian Sunday papers that mentioned just this exact phenomenon, but from the Indian point of view. Apparently, the Indian writer could not understand the European mania for keeping the shower water from running all over the bathroom floor. He thought it was a great thing to be able to have water run all over the place. He viewed it as some kind of exhilarating and freeing thing. I think it might have had to do with the fact that they didn’t have as much of it in India, but I’m not too sure because of my seatmate’s heavy St. Louis accent.

Anyway, don’t you love that? The thing I think is weird and crazy and maybe even a little backward and dumb turns out to be the thing they think is wonderful, and vice versa!

I have one other important discovery to share. You know how annoying it is to be near somebody on a cellphone who is having a conversation? How you can’t keep from listening to it even though you hate both yourself and the cellphone person because you are helpless against the pull? People are forever complaining about public cellphone users like, “I don’t want to hear about your underwear shopping experience or your lifelong struggle with flatulence!”

Well, I have new information. It is not because of what they are saying. That’s not the reason we listen against our will. I know this because I realized, while I slowly rotted from the inside out in various airports over the past couple of weeks, that I was incapable of ignoring people having cellphone conversations even when it was in a foreign language that I couldn’t understand.

That’s right, people. It’s not the soap opera drama of what it was like for her to break up with her lesbian girlfriend or the shockingly obtuse behavior of that store clerk (go ahead, take a side). It’s something about the noise. I don’t know what. But it’s something. Something in tone of voice that transcends the tonal patterns of different languages. Or maybe it just has to do with the fact that we know that they are on a cellphone (I don’t think it’s this one because lots of times I notice that I’m listening to the one-sided conversation before I notice the person or that they are on a cellphone).

I’m thinking maybe it’s the fact that the conversation is one-sided, but can I tell that when somebody is having it in Tamil or Tagalog or Urdu? And I wonder if I figure it out, will it liberate me from the tyranny of cellphone eavesdropping, or will it make things worse?

I think I’ll go spray shower water all over the bathroom floor.

February 13, 2012

Spending two weeks doing CSM courses in India. Here are a few mostly non-agile non-scrum non-professional notes:

Two 9 hour flights in a row is still long.

On the way into Delhi, they announced that they had to fumigate the airplane before landing! A moment later you could smell the perfumed insecticide. Turns out it smells a lot better than Delhi, which seems to be downwind of a giant forest fire somewhere. Everything in the airport smells vaguely of smoke.

On the upper deck business class seats in a KLM 747, they had built-in massage seats. Wowee. Too bad I was too addled to actually use them. They did vibrate because I checked before we took off. After that I just forgot about it until now.

Arriving in Delhi I had to get to the Eaton Smart transit hotel in the airport because I fly to Kolkata tomorrow. So they met me at the gate, and the guy, Narendra, I think, except I’m pretty sure there was a ‘g’ in there somewhere, made me wait until I was in no danger of zipping quickly through the immigration line, and then he escorted me to the immigration line. The immigration guy, when I finally got to him, spent at least five minutes figuring out that I had made a mistake and put my arrival date where it had either visa expiry or passport expiry. Dude, it’s a braino, which is a typo that comes from your brain.

After immigration, I go through customs where I don’t declare anything, as usual. How do they catch smugglers, anyway? Then Narendra-with-a-g-somewhere took me to a separate baggage screening place where he explained that I could not take my checked baggage into the hotel. I freaked, since I’ve been traveling 24 hours and I’m just a bit wilted in spite of my fumigation. So he finagled and got me through. Almost another calamity as the person doing the paperwork at this weird inspection stop couldn’t figure out from my travel itinerary what my flight number was for tomorrow. After the required five minutes staring at it, she finally asked and I pointed to it. Sigh.

So my bags get screened there and little security stickers get put over the zipper openings and we then walk somewhere else, where some military guys need to see my itinerary for tomorrow. Made it through there, and then another checkpoint, and then up the elevator to the hotel. Arriving there, the military guy who is clocking in guests and baggage (at 1am) officially rips off the security tags and I’m in. Whoa. No way I could beat this security because you need to be able to analyze it in a rational way first.

Another day, another Indian hotel bathroom where the water from the shower runs over the whole bathroom floor. The solution seems to be to put a drain in the main bathroom floor rather than just separate the shower from everything else. I mean, really, after 9000 years this is the best they got?

One of the best parts of India is the newspaper.

  • “Woman Throws Sandal at MP”. In the first sentence of the article is the important note “…and fell short of its target.”
  • Three elected guys in the congress of Karnataka are watching porn on cellphones during congressional session. Behind and above them, in the gallery, is a TV film crew which films it over their shoulders. They kind of resign the next day.
  • Some guy was fired from his job 25 years ago for committing adultery. This week, the court decided that his firing should stand. Way to go, swift justice. I wonder what would have happened if they had decided he was wrongly fired? 25 years of back pay?
  • Check it out: India is bracing for a drop to a mere 7% yearly growth rate in the economy.
  • Woman in a remote village travels home to husband’s home, then storms out two days later, refusing to come back until he or his parents install a toilet. The village takes up a collection and he puts in the toilet. Then about 80 other village girls leave their houses due to lack of toilets. Then the original girl gets a huge award for “raising awareness of hygiene in the remote rural areas.” And how will she use the reward money? To build a bathroom.

OK, enough for now. On to Bangalore this afternoon after a great course in Kolkata (46 people!) and a really fun one in Pune.

Bye for now!

Developer Owns a Story – Good Idea or Bad?

January 26, 2012

One aspect of the transition to Agile is the switch to truly team-based work. Like all aspects of significant change, it can be difficult to get it to take hold. One of the anti-patterns that coaches see from time to time is when a single developer takes over the development of a user story and works on it alone. This is a pattern that shows up in more traditional environments and it is a shadow of the more extreme “cowboy coder” phenomenon. No matter the details, it is the opposite of the kind of swarming, tightly knit team approach that we depend on in scrum to give us some extra oomph.

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.

Documentation Debt in Scrum

December 11, 2011

Recently one of my Scrum Masters came to me with a question. He said, “We have been going crazy building things since we switched to Scrum a few months ago. We have made some major changes to our system architecture and design, but we haven’t documented them. That is starting to scare me. What should we do?”
It was a great question and I was pleased to hear it because it showed me a thinking Scrum Master.

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.

Be Careful What You Test For

October 28, 2011

My teams are great. I’m not on them…I own them. At least as far as an executive ‘owns’ his teams. In an Agile world, when we say ‘own’ we kind of mean ‘is responsible for the success of ‘ or some such thing. What I’m trying to say is, don’t take umbrage at the words I used. I’m responsible for a bunch of people in a company, and those people are mostly organized into Scrum teams. So, my teams are great.

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.

Disneyland Scrum vs. Industrial Scrum

September 29, 2011

When I teach Scrum, I start with the idealized version of it. For all of Scrum’s famous (at least to me) simplicity, it can be quite difficult and time-consuming to explore all of the nuances and possibilities and corner cases. Over the past couple of years, I’ve begun to refer to this idealized version of Scrum as ‘Disneyland Scrum.’ In Disneyland Scrum, everything goes well. Teams self-organize. Self-organized teams have good ideas. People are excited to sit through planning and review meetings. Everything on the Product Backlog is an identifiable feature expressed as a user story. Management “gets it” and makes no unfair demands on the team. Disneyland Scrum works great!

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.


Get every new post delivered to your Inbox.