Guest Post by Jurgen Appelo:

I once read that “managing is harder than programming, because making people do what is needed is far more difficult than making computers do what is needed”. (Don’t flame me if you don’t agree. I’m quoting from an unknown source here.)

This quote kept running through my mind when I recently encountered a number of, well… let’s call them disciplinary challenges, like…

• Not being at a meeting, without notice, despite having accepted the request,
• Not keeping systems or task boards up-to-date with latest task/story statuses,
• Not linking code or time registration to issues or user story numbers,
• Not actively checking if there’s overrun on a budget,
• Not responding to a show stopper problem within promised response time,
• Not storing project documents in the shared repository,
• Etc…

Is this a case of hanging out the dirty laundry? Not really. We’re all people, employees and managers alike. We’re not computers, we all make mistakes. If you don’t have similar problems in your organization then I will assume you’re working with robots, not with human beings.

Still, they are problems nonetheless. If my computers were this unreliable I would throw them out the window. No, actually I would carry them all the way up to the tea room in our office building, and then throw them out the window. But we don’t do that with employees anymore these days. That’s because managers have discovered how to be humans themselves, and they can understand the reasons for people’s non-disciplined behavior, with excuses like: I-Didn’t-Know-This-Was-A-Rule, Sorry-I-Forgot, There-Was-Too-Much-On-My-Mind, I-Was-Kept-Busy-With-Some-Major-Problem, I-Was-Sick, My-Dog-Was-Sick, My-Dog-Ate-My-Agenda, My-Dog-Ran-Away, and of course My-Dog-Died.

So, we all understand being human. But what to do about the problems?

One solution that people often come up with is that some supervisor should be made responsible to inspect everything. This is of course step 1 on The Road To Bureaucracy, and it is a direction that agile and lean people fervently argue against. However, other people argue that some of those steps are nevertheless very useful.

For example: Mary and Tom Poppendieck, famous for their books on Lean Software Development, argue that inspection to find defects is waste, and they call for zero-inspection. They claim that resources should be spent on preventing problems instead of fixing them, because it’s cheaper.

On the other hand: Tom and Kai Gilb, famous for their work on Software Inspection (among other things), teach people how to inspect documents to find and measure defects. They even have certificates for inspection, like Inspection Leaders and Inspection Process Owners!

What’s going on here?

Can these different viewpoints be aligned? Can I earn myself a certificate for doing zero inspections? Or do we have a chance of witnessing a clash between the two most celebrated family duos in software development? An epic battle between father and son Gilb against husband and wife Poppendieck?

Well, I admit that would be a sight to see, but my guess is that their viewpoints are simply two sides of one and the same coin. Yes, preventing problems is cheaper than fixing problems, but only for 95% of the problems. In fact, it has been noted before that zero defects is the wrong approach, because preventing those last few problems is far too expensive. Which means that we have to allow some problems to flow to the next phase in the process, where detecting and fixing them can be cheaper. I discussed the staged approach to discipline in one of my earlier articles:

1. People have to show a high level of self-discipline;
2. They have a coach to help them in becoming more disciplined;
3. Their discipline must be subjected to peer pressure;
4. There should be tools to assist in mistake-proofing the process;
5. Last of all, there might be some supervisor doing regular inspections;
6. And if everything fails, the dirt will land on the manager’s desk.

It is almost always cheaper to solve problems higher up in this stack. Supervising and inspecting is the final gate where problems can be detected and prevented from ending up at the manager’s desk, or worse… the customer’s desk. Fewer inspections are better. But zero-inspection is like full code coverage. It is a lofty goal that, in practice, is unattainable because of its exponential costs. There will always be some work left for some supervisor to inspect, certified or not.

So, in solving the problems I mentioned earlier, before giving work to a supervisor, I will try and make sure that I have done all I can to prevent needing him in the first place!

And of course, the principles of discipline apply to my own work as a blog writer as well… juicy title: check… teasing opening paragraph: check… re-reading ten times: check… silly jokes: check… spell-checking: check… hyperlinks and mark-up: check… great pictures: check… making fun of celebrities: check… conclusion: check… OK, ready for the next phase… Chris, will you inspect this post please?

About Jurgen Appelo

Jurgen is the Chief Information Officer at ISM eCompany, rated (a while ago) as the #1 fastest growing technology company in The Netherlands. As a manager, he leads a horde of 100 software developers, development managers, project managers, business consultants, quality managers, service managers and kangaroos, some of which he hired accidentally.  He also write a blog called NOOP.NL: A Guide to Development, Management, Things & Stuff.

The catch was that all of the participants except one were confederates of Dr. Asch. The confederates gave the correct answer for the first few trials, but then all began to give the incorrect answer in subsequent trials. Amazingly, the test subject began giving the same incorrect answers as the confederates. In fact, overall, after 18 trials, 36.8% of the answers given by the ‘real’ participants were incorrect, effectively conforming to the wrong answers given by the unanimous confederates. Only 25% never gave a false answer, therefore showing that 75% conformed at least once. The results show a surprisingly strong tendency to conform under group pressure, even in cases when the answer is clear.

How does this inform us? When we’re working on teams, we need to be cognizant of this study. We need to be vigilant against conformity and group steering. It can be extremely detrimental to continuous improvement. If one person on a team has an opinion that is different from every other team member, this tendency towards conformity may have a chilling effect on their ability to communicate a problem with the team. This applies to estimating as well. If teams estimate in an open manner, differing opinions can potentially be quashed. That’s why I believe planning poker is such an effective method for estimating with teams.

But, there is hope. Asch was very disturbed by the results of his experiment. He said, “That we have found the tendency to conformity in our society so strong… is a matter of concern. It raises questions about our ways of education and about the values that guide our conduct.” Some time later, Asch conducted his experiments again. This time, when every one of the confederates voted for the wrong answer, one stood up and said “That’s wrong!”. The test subject then easily identified the correct answer. Adding one supporting partner greatly diminished the power of the majority. Hope!

One voice of dissent enabled another to be heard. Is that all it takes on our teams, in our society to make a difference? One voice to say “That’s wrong”? I believe so. But I also believe that on a deeper level, we need to create environments on our teams, in our organizations, and in our society where people do not have to feel pressured to conform. People should be able to think freely and express their views without being hindered by the majority rule. This freedom to disagree is where all progress, creativity, and innovation comes from. I love the fact that the results show that the 25% of subjects who never gave wrong answers were not susceptible to conformity. That makes me very happy. There is hope that not everyone around us is likely to conform to the majority opinion.

I would suggest that you start your iterations on Tuesdays or Wednesdays and end them on Wednesdays or Thursdays. The logic behind this is simple. Think about it: Monday morning, folks roll in from the weekend and are kind of groggy. They’re not 100% focused. Is this really the best time to be thinking about planning your next iteration? The planning meeting is the place for robust, intelligent conversations to happen when nailing down the details and tasking a user story. If your team is half asleep, or still getting over the weekend, this is probably not the optimal day for planning. By Tuesday or Wednesday, the team is awake and engaged, ready to think. This is probably closer to optimal for planning sessions.

On the flip side, the end of an iteration doesn’t fare very well on Fridays. First, if you have team members getting an early start on the weekend, you’re missing people for your reviews, demos and retrospectives. Not ideal. And, if you’re missing your product owner or stakeholders for your demo, definitely not ideal. But beyond that, Fridays usually present us with another case of lack-of-focus. You and your team could probably muddle through your review and demo even if you’re distracted by the impending weekend plans or tired from a long week of work. But for your retrospective, you not only want your team present physically, but mentally as well. The retrospective is possibly one of the key practices for success in agile development. A team needs to be sharp to really consider what went right during an iteration, what went wrong, and most importantly, what they need to do to improve their practices in the future. If there is a lack of focus during the retrospective, your team could be missing out on some of the best benefits agile has to offer. So, to keep things focused, I would recommend ending your iterations on either Wednesdays or Thursdays. And try to schedule the review/demo/retrospective early in the day as opposed to later in the afternoon. Not only will this help keep folks focused, it’ll also cut down on last minute coding/fixing before the demo.

So, let’s take a walk through the schedule. On the first two days of the iteration, the developers get busy coding the stories in their backlog while the QA’s start writing test cases/acceptance tests. The QA’s should also be running these tests against the existing code base. This validates that the test harness is working correctly and that the new tests do not mistakenly pass without requiring any new code. Obviously, the new tests should also fail for the expected reason. This tests the tests themselves, in the negative: it rules out the possibility that the new tests will always pass, and therefore be worthless. OK, so that’s day one and two.

Over the next five days, the QA’s begin testing any testable code that has been completed. At the same time, the developers continue coding and also start working on fixing any defects picked up in the testing. Pretty standard days. Code-test-fix.

OK, we’re deep into the iteration now. Days eight and nine see QA continuing to test all of the remaining code written during the iteration. Yes, ALL of the remaining code. At this point, the developers effectively stop writing “new” code and focus their energy on fixing all defects identified in testing. If the dev team has no defect work or find themselves with down-time while waiting for testing results, they can and should be helping the product owner develop and refine the user stories that are likely to be played in the next iteration. Additionally, developers can start considering the design aspects of the immediate upcoming stories and coordinating design decisions with the project architect.

Last day! Don’t start scrambling now, you’ve got a demo and review later today. So, on Friday, the developers focus on bashing any remaining defects and making the code bombproof. We’re shooting for zero defects here folks. The QA’s are spending most of their time doing some final acceptance testing (as is the product owner). That’s it. It’s noon and it’s time for your review and demo. You’ve tested and fixed everything so you and your team can demo with total confidence. No surprises for your team, you’ve built serious quality into your software!

So, there’s my idea for a basic schedule that completely integrates QA and testing into your iteration. Now, this is only one way I think QA can be integrated into an iteration. There are probably dozens of other ways to do this and I think ultimately, the way teams work QA into their iterations really needs to be assessed on a case-by-case basis. So, I’d like to pose the question to agile teams out there: How do you currently fit QA/testing into your iterations?

Or, maybe you think it’s a little more organized and looks like this garage:

Either way, all of your stuff, your requirements, your backlog items are stuffed away and it’s probably hard to figure out what you’ve actually got. You and your team probably spent a good amount of time in a planning session writing as many user stories as you could think of. And, that’s not a bad thing to do during the initial brainstorming sessions when you’re stocking your high level backlog. But, at this point, you haven’t pared it down to stories that fit the overall vision and roadmap for your product yet. The backlog at this point is cluttered. Because it’s so cluttered (or put into neat little boxes or files or binders), it’s really difficult to make connections between the stories. It’s hard to see the big picture. So, what do you do now?

Well, Dan Roam, author of The Back of the Napkin has a good solution. Have a garage sale. Well, sort of. Dan talks about the Garage-Sale Principle. He says:

“Regardless of how well organized all the stuff in the garage may be, laying everything out on the tables in the light of day yields a completely new perspective on it all.”

So, how can we do this with our backlog and our user stories? First, get all of your stories written on cards or really big sticky notes (preferably during your initial planning session). Now, get a conference room and stick all of those stories on the walls. Plaster the place with them . Next, let everyone on the delivery team, all of the stakeholders, the product owner…everyone…take a walk through the conference room. Leave the stories up for a day or two. Let people really get a good look at every story. Give the team a place to air their comments about the stories. And then, start performing story triage.

Start by grouping the stories based on two or more of the 6 W’s: Who, What, Where, When, Why, and (W)How. And I mean literally group them on the walls. Move the stories around. Let everyone move the stories to the groups they think they belong in. Got them grouped? Good. Now, go through the groups and the stories and start moving any stories (or entire groups) that don’t adhere to the product vision or roadmap into a parking lot area somewhere in the room (but don’t throw them away!). Be tough and cut any stories that don’t advance the product vision. By now, you should have user stories that are grouped by common themes and that are completely focused on achieving the product vision. You’ve cleaned your cluttered garage and now you can clearly see the value of all of the items that were in there. Now you’re ready to start moving stories into your backlog and get to work building focused, valuable software. And, because your team and product owner spent a little time living with their user stories, prioritizing and sizing the stories in the uncluttered backlog should be easier too.

“As a <user type>, I want to <function> so that I can <business value>.”

An example of a real user story looks like this:

“As a frequent traveler, I want to rebook a past trip so that I can save time booking trips.”

Good. Now we have a simple story to put into our backlog. But what I’m curious about is, just who are these user types…these frequent travelers? We often give them generic names like product owner, frequent traveler, end user, customer, or just the user. There’s no meat on the bones of these generic user types. They have no personality. I firmly believe that as developers we need to focus intensely on our users and what they want if we want to create remarkable software and products. So if we focus so intently on our users in our marketing efforts and in our sales cycles, why do we make them an amorphous lump in our user stories? Why don’t we know more about them? Ultimately, we’re developing software for them. Shouldn’t we know them a little better?

Well, here’s a suggestion: Stop using generic user types and use personas instead. Give your users some life. Real lives. Consider creating an actor table to define the personas of each user type. It will connect you more with your end users and really help your delivery team focus on developing software that doesn’t speak to the generic masses. Here’s an example of an actor table for one user persona:

If you create a persona for each one of your user types and start using their names in your user stories, you’ll start feeling more connected to your users. They won’t be a generic mass out there anymore. You’ll be developing software for somebody. You’ll start caring about what you develop and in the end this will improve your software and ultimately improve the satisfaction of your frequent traveler user type…or let’s just call him Jeff.

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Thinking back to the Get Smart stories, I think they are independent and valuable, but they fall short of being negotiable, estimable, sized appropriately, and especially testable. Now, I know that these stories generally are used to define research spikes and therefore are used to give better estimates for other user stories in the backlog. So, I can even let go of estimable, negotiable and small. What I want to focus on is the “T”: Testable. If all your story says is “Get smart on the dojo toolkit“, how does your team test if you “Got smart“? There are no specifics in the story about why your team needs to get smart. What is the reason for the research? As my colleague Ben Carey has described it, the testable attribute ensures that our acceptance criteria are not ambiguous. To make something testable – we need to make it measurable and specific. And I believe this has to apply to the Get Smart stories as well.

So, instead of “Get smart on the dojo toolkit“, try to rewrite the story to maybe say something like “In order to send complex data between the client and server as json, as a delivery team we want to research the dojo toolkit and the ASP.NET MVC.” And, if you want to go with the traditional user story format, you could write it as “As a delivery team, we want to research the dojo toolkit and the ASP.NET MVC so that we could figure out a way to send complex data between the client and server as json“. These stories are much more testable because they’re specific and measurable. When the team completes one of these stories, they should be able to describe how to send complex data between the client and server as json using either or both the dojo toolkit and the ASP.NET MVC. In fact, they would probably be able to demo a prototype of the functionality based on the stories. And, because these stories are specific, they prevent the team from wandering through documentation, tutorials, and code samples without any aim or goal. The research in this story is confined only to understanding how to send data as json. Nothing else. So, be specific and avoid storyotypes….do that and you and your team will get smart!

Building software is complex. Every time you think have something nailed down, the requirements change. In fact, it reminds me of a quote from Al Gore’s “An Inconvenient Truth“:

“It’s like beach combing. Every time the tide comes in and out, you find some more shells.”

In software development, every time you show your progress to your end users or talk with your stakeholders, you get feedback…more shells. How can you respond to that feedback, that change? It’s a question I hear often and in my opinion, agile practices are the answer. But how do you describe agile and it’s ability to embrace change and complexity to someone who has never heard of agile? I spent many years in the geographic information systems industry so my thoughts logically went back to mapping systems for an example of how agile embraces change. Let’s use the simple example of trying to drive to a meeting destination that you’ve never been to before. You need some directions.

Let’s start with MapQuest. In MapQuest, you start by entering a starting point and a destination. MapQuest assumes you know where you are starting from and where you are going. MapQuest returns a complete set of step-by-step directions from your origin to your destination. So, you print out your directions, get in your car and start driving, following the stepwise directions. Then, you encounter a problem. The highway is closed due to an unexpected accident. You exit the highway, look at your step-by-step directions from MapQuest and sigh. Now what? You don’t know where to go because you only have the original step-by-step directions. You’re in an unfamiliar place. There are no detour signs to guide you. You’re stuck. You try going one way, but that doesn’t work. You try another way and that doesn’t work either. Before you know it, you’re lost. You’re late. Your printed directions are no longer useful. You might never get to your destination now. MapQuest is waterfall. MapQuest is how we traditionally developed software. Have an origin, an end point and a set of step-by-step directions to guide us from origin to destination. It doesn’t allow feedback into the system. It doesn’t allow for deviation from the plan.

Next, we try out Google Maps. In Google Maps, you do the same thing you did in MapQuest. Enter a starting point and a destination. But Google Maps is a little different. If we know ahead of time that there is a construction project or an accident on the highway, you can dynamically drag the route Google Maps provided and “draw” a route that avoids these problem areas. Google Maps reroutes you on the fly and provides you with a revised set of directions. So we print out our “smarter” directions, get in our car and start driving. But if we hit any unexpected obstacle, we’re in the same situation as we were in with our MapQuest directions. Google Maps is a little more agile, but it requires prior knowledge of the problems you might face to avoid getting slowed down or lost on your way to your destination.

Finally, we get a GPS unit in our car. We get into our car without any printed directions. We turn on the GPS and all it asks is “Where to?“. It already knows where we are; it just needs to know where we’re going. The GPS unit maps out the shortest path from our current location to our destination. It presents us with a general overview map of the route, but provides us with detailed directions only as we need them. It only gives us enough information to make the next turn. It doesn’t present us with complete step-by-step directions. And, the GPS constantly inspects our current position in relation to our destination. If we encounter obstacles on our way and need to deviate from the route, it adapts the route on the fly and provides us with new directions to reach our destination. And maybe while we’re on the highway, our client calls and tells us they changed the location of our meeting entirely. Our destination has changed. So, in mid-course, we can tell the GPS unit our new destination. Without hesitation, it provides a new set of directions to our new destination. GPS allows feedback into the system and it adjusts course based on this feedback. GPS is dynamic. GPS doesn’t mind if you find some new shells. GPS is agile.

An easy way to arrive at a consensus is using the Fist of Five Rule. When trying to reach consensus, each team member holds up 1 to 5 fingers to show their level of agreement and support. Here’s the scale:

Fist: A no vote – a way to block consensus.

1 Finger: I am very opposed; we shouldn’t move forward (and yes, it should always be the index finger).

2 Fingers: I have reservations I’d like to think about.

3 Fingers: I can live with that and support it.

4 Fingers: I think it’s a great idea, I wish I thought of it.

5 Fingers: Wild unbridled support.

Try to get everyone to at least 3 fingers or better. That’s consensus. I can live with that.

It’s a great question and I don’t think there is an easy answer to it.  Speaking from my own personal experience, it’s been difficult extrapolating the success our small team of five developers had in the past to our larger organization of about 35 people.  There are many challenges as you scale agile up.  Agile practices depend heavily on collocated teams that are cross-functional in nature.  When you start scaling agile up, you need to consider geographic dispersion of much larger project teams that may not be as cross-functional as you’d like them to be.  This is just the nature of large organizations.  This can have an impact on communications and coordination of work across dispersed teams.  Another success factor that’s related to this in larger organizations is the use of matrix management.  Teams in large organizations are usually composed of a mélange of team members who, because of matrix management, report to and are managed by different parts of the organization.  This can lead to the fire drill mentality and “resource ownership” issues.  This can quickly degrade the level of commitment and the quality/value of functionality that the teams deliver.

Other obvious factors that can be relevant when scaling up are the development and testing environments.  Teams need to be able to continuously integrate their work and have a common infrastructure that supports this across a large organization.  Teams need to know quickly whether or not the work they’ve done is negatively impacting the rest of the codebase.  This is no small matter and can really improve or decrease the effectiveness and efficiency of agile development teams.

There are probably many more factors that are related to scaling agile up, but to me, the ones mentioned above seem critical.  Personally I don’t think you can simply extrapolate the success of smaller agile adoptions to larger organization-wide adoptions.  I think that each has its own distinct set of challenges that make it difficult to draw a line and say we had X amount of success here, so that means we’ll have 10X success when we scale this up.  However, that is not to say that large organizations cannot enjoy the benefits and successes agile practices offer.  They just have to approach it with a different mindset than smaller teams or organizations.  In fact, many large organizations have really recognized tremendous gains using agile practices.  If you’re interested, there is a great case study available about BMC Software adopting and scaling agile practices throughout a very large organization.  It’s available here.  It’s well worth the read and gives some great insights into how large companies adapt to make agile work for them.

I run through these questions because I think each one represents a potential failure point for agile adoptions.  Let’s take a look at each one.

1. How did your company adopt agile: top down mandate or grown organically? This is really important.  In the teams I’ve talked to and worked with, it always seemed that agile was adopted better when it was grown organically not when it was mandated.  The mandate approach assumes command and control and never leads anywhere good.  People need to want to do agile.  So how do you get people to want to do agile?  Show them small successes.  Let a single team or a few small teams start doing agile.  Then, as they show successes and learn some of the lessons, other teams pick up on it and want to do the same.  The teams that went first, help the teams that followed adopt agile and they pass on the lessons they’ve learned. In other words, you can’t just throw the agile switch and voila…everything is good.  Mandated adoptions often fail because there is no magic switch.  People resist change when it’s mandated.  They embrace it much better when it’s grown out of proven success.
2. Was your adoption done in stealth mode or full fledged “Hello world, we’re going agile”? The CEO or COO stands up and proudly announces “Hello world, we’re going agile” and then thinks in the back of his mind “I hope this voodoo works”. And, because there was such a public announcement of the company’s intent, there is extreme pressure to “make it work”.  This pressure leads again to command and control thinking of “make this stuff work” or we’re going to be embarrassed.  On the flip side, if you start in stealth mode, you work projects internally using agile practices but say nothing of it until the project is over.  When you client asks “How were you able to deliver value in a timely manner?” you can answer “With agile practices”.  Because there is no external pressure to live up to some expectation, stealth agile teams have an internal commitment to making agile work for their own good without being forced to do so to meet some external expectation.  Once they gain the successes on stealth projects, they’ll be more comfortable with announcing that they develop in an agile manner to the world.
3. Do you have real executive support for your agile adoption? Lot’s of executives have “heard” about agile and want to do it because everyone else is.  But, they don’t really understand the level and type of commitment an organization must make to truly adopt agile.  If you haven’t already noticed, one of the key things an organization needs to let go of when they adopt agile is the command and control structure.  It’s a very hard hard thing for most executives to let go of, and many never fully commit to and support a more servant leader approach to management.  Failure in agile adoptions occur when lip service is paid to “supporting” agile practices, but business goes on as usual: The command and control structure remains, long winded requirements documents are requested to support the inevitable scope disagreements we’ll have with our clients, deliverables-based contracts and project tracking remain, and percent complete and earned revenue calculations are the only important project metrics.  If organizations can’t come around to supporting agile practices and drop their old “bad” management habits, agile adoptions are doomed to failure.
4. What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule? If you’re going to adopt agile, you need to consider the types of projects you’re going to run agile on.  That means thinking about contracting in a whole new light.  If you’re trying to use agile practices on a fixed scope project, expect to fail outright.  Fixed scope is the antithesis if agility.  If you’re running on a fixed-price project, better chance of success, but only if scope is not fixed.  Fix your price and your scope:  FAIL.  And fixed-schedule, another bad option.  So, if you’re trying out agile on a project that has not truly been contracted to run agile, expect failure.  The answer is to work with your clients to educate them and develop agile contracts that both you and them can work with and live with.
5. Has your staff received any kind of agile training? “OK, so we’re going agile.  Here’s the 2-hour overview.  Go out and be agile!”.  One month later: Fail.  Why?  Agile is not easy.  It sounds easy and can be explained quickly.  But, there are many subtleties and nuances to agile.  For teams to really grock the whole agile thing, you need to invest some time and money for training.  An agile team needs to learn how to plan in a whole new way, how to develop user stories, how to develop tasks, how to assess themselves and their practices.  And, they need to learn about the heart of agile: commitment.  Unless teams deeply understand what makes agile tick, they’re going to have a difficult time being successful at it.  A two-hour “Welcome to Agile” powerpoint ain’t gonna do the trick.  Sending teams to something like scrum master training is well worth the time and money you’ll spend on it.
6. How many projects have you run in an agile manner and how long ago did you start doing agile? My advice here: give it room to breath.  It takes a few turns around the block to get agile running smoothly.  Teams need time to gel, get to understand agile and learn about themselves (see recent post on this topic).  Like I said before, there is no magic agile switch.  It takes time for agile teams to become successful.  The more time you allow it to run, the more likely it will be successful in the long run.  Too many teams hit the first agile bumps and hurdles and instead of trying to learn from them, they pull the plug and declare their adoption of agile a failure.  There are many stages an agile adoption goes through and some can be painful from many points of view.  Slow down, take a deep breath, and keep trying.

So, what should you do if your agile adoption is “failing”? Here’s a hint: Agile is HARD.  Ask yourself some of the questions above and see what might be causing the failure.  I believe that too many organizations only half-heartedly adopt agile and pull the plug far too early before it has a chance to prove itself.  Give agile a try, give it some time, and think hard about the six questions posed above before you pass judgement on your agile adoption.

There are a few things a ScrumMaster must do to help their teams learn from their mistakes.  First and foremost, the ScrumMaster cannot be a fixer.  When things are broken or not working the team, not the ScrumMaster, must figure out how to fix things.  If the ScrumMaster continually steps in to fix the problem, the team never learns how to fix a problem for themselves.  This leads back to the old command and control structure of more traditional development approaches.  Instead of being a fixer, the ScrumMaster needs to be an enabler.  The ScrumMaster needs to be aware of any problems the team may be having and provide them with whatever resources they need to solve the problem on their own.  It could be something as simple as a phone number for a key client contact.  Whatever it is that is keeping the team from solving their problem, the ScrumMaster is there to provide it…except for the solution itself.

The other thing I think a ScrumMaster must do is allow teams to make mistakes.  Because Scrum is, at its core, an empirical process, we expect certain things not to work…and we expect to inspect and adapt our practices to make them work better.  That means letting teams fail sometimes.  If a ScrumMaster always steps in and prevent a team from making mistakes, the team never get the chance to learn from them.  If a team doesn’t get that chance, they become inefficient at self-management, another key tenet of Scrum.  And again, this leads back to the old command and control structures of traditional project management.

So, my two pieces of advice for ScrumMasters: Let your teams make mistakes…and don’t be a fixer, be an enabler.

Now a disclaimer:  I’ve never worked on a shrink-wrap team, I’ve always been on consulting development teams.  Given that little disclaimer, I don’t understand how a customer proxy can really define what an entire unseen, unknown customer base really needs.  I know that some organizations do prototype or “focus-group” type testing to gauge what their customers want.  But my friend’s team develops on a gut instinct of what their customer base needs. I’m not sure this ever can truly deliver quality and value to a wider audience.  I think it leads to Microsoft Word-type deals, with tons of functionality that only a few people actually use.  Don’t get me wrong, I think a lot of good things come out of gut instincts.  I think there is a lot of value to anticipating user needs.  It’s part of innovation.

The other point my friend made was that in the shrink-wrap world of DVD-based delivery systems, organizations are hard pressed to keep up with the rapidly changing demands of large customer bases.  Their release schedules and update maintenance schedules must be horrendous.  They can’t respond rapidly to changing or evolving customer needs.  The best they can do is provide patches and updates via the web.  New functionality is released on the next release…on DVD…every 9 to 12 months.

I do see a solution to this problem and I think the folks at Rally really embrace the ever evolving needs of their dispersed customer base.  It’s how they gather and prioritize their customer’s needs that impresses me the most.  Rally has a community website where users can enter feature requests.  The other users in the community can vote on the usefulness of the feature requested and provide additional feedback and comments on the feature request.  Based on these entries and their associated popularity, Rally is able to understand their user needs and prioritize them.  Many of the features requested by their user community show up in very frequent releases of their web-based solution. No DVD’s or anything.  Just a quick release and instant functionality to their customers.  Speaking from personal experience, I’ve seen functionality we’ve asked for implemented within a single 7-week release from when we requested the feature.

To me, this is as close as you can get to your customers if you’re doing “shrink wrap” software development.  For those of you out there doing shrink-wrap development in an agile manner, how do you engage your customer base to deliver high value, quality software?  I’m very curious how customer proxies work in agile organizations?  How do you define and prioritize your customer needs if you never get to interact with your customers?  When I think of these types of questions, it makes me very happy to be on a consulting development team.  Sometimes I think I take the close relationships we have with our customers for granted.  After this conversation with my friend, I think I’ll value the collaborative nature of our relationship with our customers a whole lot more.

So, what does this have to do with anything (except that now you know that I ride my bike at lunch)?  While I was riding back, I thought, this is a lot like a big software development project.  A lot of development teams start out thinking “This is a 20-mile ride, I usually do it in 60 minutes”.  They try to figure out all the dependencies (i.e., the terrain, the wind speed), and feel really confident that they’ll get the job done in time.  Then they start building the software.  The wind is at their back…they’re cranking through the work.  Then, one day, the wind starts blowing.  This project has complexities we didn’t think of.  We didn’t know it was going to be this difficult.  But we still need to finish the job (we still need to get back to the office).  We can’t work or pedal any faster.  We know we’re going to be late.  What do we do?  The project goes into panic mode.  Do we sacrifice quality to get it done?  Do we sacrifice schedule?  Do we go over budget?  The reality is, most traditional development teams do all three at one point or another.

In agile, we don’t let the wind worry us.  Agile embraces changing conditions.  An agile team simply says, OK, it’s windy.  How do we work in the wind?  How do we work with the wind?  Do we have to make it back to the office?  In other words, agile teams can easily adapt to new conditions, new requests, new requirements, unknown complexities. And because we use prioritized backlogs with our customers, we don’t have to sacrifice quality (or value), schedule, or budget.

Aircraft are regularly called in for routine servicing.  The servicing was usually scheduled for about 3 days.  A QA specialist (or several QA specialists) examined the aircraft and used a set of cards to write up work orders for each item that required servicing.  The QA specialist then sorted the cards by theme (interior, engines, avionics, etc.), estimated how many items could be completed in 3 days based on historical data, and slotted them on a task board.  The crew chief for each “theme” area would pick up the cards for his team.  The crew chief and his team would triage the work items and prioritize them.  Then, the team members would select the work items they would work on and provided the crew chief with time estimates to complete each of the tasks they selected.  This allowed the mechanics doing the work to actually estimate the duration of their tasks.  The team would then commit to completing the tasks within the 3 day service period.  Each day, they’d check in with each other to make sure things were on track.  During the service period, the crew chief worked on some maintenance tasks, but he also made sure that everyone on his team had what they needed to get their job done.  At the completion of the service period, the QA specialist would come back and inspect each maintenance item and either accept or reject them (and FAA inspectors checked things as well). Team members were also encouraged to think about how they did their job and suggested new or better ways to do things (in fact, they received monetary incentives for coming up with innovative ideas).

Now, I don’t know about you, but this sounds very much like Scrum to me.  If you think about it, we have a highly complex piece of equipment with multiple integrated systems.  We have a mission critical maintenance program.  We have high priority items that need to be completed…you know, done done…to keep the aircraft safe and airworthy (and others that are lower piority like a reading lamp that isn’t working).  You can’t mess up here.  So how do you do it effectively and efficiently: Scrum.  Here’s how I see it:

We have a time boxed iteration (the 3-day service period).  We have a product owner (the QA specialist), a ScrumMaster (the Crew Chief) and a team (the mechanics).  We have a prioritized backlog (the task board and task cards) and team members selecting their tasks, providing task estimates, and committing to a team goal of having the aircraft ready to roll in 3 days.  We have a daily stand up (checking in to make sure they’re on track).  We have a servant leader ensuring his team has what it needs to meet their goal and we have a product owner review at the end of an iteration.  And most importantly, we have retrospection and continuous improvement.  Seems like Scrum to me.

So, maybe Scrum is just a repackaging of things we already knew that worked well.  It’s just being applied to software development now instead of aircraft.  Toyota picked up on much of this and Taichi Ohno implemented lean manufacturing there in the early 90′s with a lot of similar tactics.  Maybe we shouldn’t be too proud of ourselves for discovering something new…we really just rediscovered something old that worked and there’s nothing wrong with that.  So, let’s file this one under “Nothing New Under the Sun”.  Or better yet, let’s file it under “My Dad Was a ScrumMaster”, he just didn’t know it.

Aside from all of this goodness, Ryan is just a flat out great guy, a good friend, and very approachable.  Our team works closely with him and his folks at Rally to bring agile practices to the forefront of our company’s development activities.  I’d like to offer my thanks to Ryan for all the help he’s given us and for taking the time out of his busy schedule to share his insights about agile software development.

Q. You have had the opportunity to work with many software development teams in your career.  Is there something special that seems to define or set apart high-performance agile teams?

A. Cool tools/technologies, cool customers, trust and collaboration have made for fun, high performing teams in my career at 9 software companies and two consulting firms. Being successful enough to be able to continue to play the fun game was the reward. With regards to the special things that set apart high-performance teams, I do not claim to be the expert. Like most, I knew it when I was in it. But thanks to an Agile University instructor and friend, Christopher Avery, we have the research to really put our finger on answers to that question. His research (see great-teams.com) points to three top things that I would totally concur with:

• Trust
• Goodwill/Collaboration
• Clarity in Purpose

Q. The flip side of that coin is equally important.  What would say are the common pitfalls that cause agile teams to fail or be ineffective?

A. I assume you can plot teams on a normal distribution curve, and the great ones and the ones that fail make up the tip and tail of the curve. The ones that fail violate the things that make a great team. Another friend Luke Hohmann, Enthiosys.com, describes the anti-pattern as a “J-O-B.” Whenever it just feels like work, stuff-for-money, or you’re working with people who are painful, it becomes a J-O-B. When it becomes a JOB, you lose the determination to inspect and adapt agile, and you plateau as an agile amateur and ultimately fall back and typically apart.

Q. There are many agile tools in the market place today.  What are your thoughts on the necessity and value of tooling for agile teams?

A. All teams need agile tools, techniques and methods to reinforce the structure and discipline of agile. In the talk that Ron Jefferies and I gave at Agile 2007, we talked about three types of “tools.” There are tools that help you reduce the cost of iterating, tools that help increase your visibility within and across teams, and role-specific tools that help accomplish specific tasks. Of course, there is a continuum of low to high tech in all of these categories.

• Tools that help you reduce the cost of iterating a check-in, a story, or an entire increment include testing tools, mock-up tools, development frameworks, refactoring IDE’s, and testing frameworks that help you reduce your batch sizes. As your batch sizes of running tested features decrease, your agility level increases.
• Tools that help you increase your visibility across the lifecycle like task boards, agile project management and integrated build tools increase in value as the project grows larger. These tools build collaboration, measurement, discipline and trust to make performance more objective.
• Role-specific tools like backlog prioritization, specific types of test tools, and modeling tools help make steps in the agile process more effective. The need for these is varied based on the people in those roles and the technology in use of the project.

You have to think of the tools, techniques and methods as working to support building trust, collaboration and clarity in purpose as well agility.

Q. Your company actively promotes agile practices for software development.  How has Rally adopted agile practices and what value have you recognized from it?

A. As we have grown, we have matured our agile practices and disciplines to manage the growth in development, the business and our customer base. We followed an incremental adoption approach to agile, and the value we’ve recognized has steadily increased. Here are the rough descriptions of the transitions that our team went through.

Step 1 Started Out Iterating – Pull together a new team of 8 into a state of iteration “flow.” We set a two week iteration cycle and worked to stabilize the process so that we could deliver a consistent level of iteration acceptance. We used internal demos to steer our iterations and we gained increasing alignment, component-level quality and company-level visibility. However, we had little feedback that we were building something that was “really” valuable and our testing practices were not good enough to achieve 100% iteration acceptance.

Step 2 Increased our Agility to “Pull” – This came after we had a handful of customers and we moved the single team into a “pull” state. This included roadmap planning based on feedback, release planning to steer iterations and better acceptance testing tools and techniques. We used customer feedback to help prioritize and shape our backlog and better automation to reduce the size of defect pile we had to clean-up before release. We worked hard at this state to get to a zero-defect mentality both inside the iteration and with regards to overall technical debt. As a result, we achieved a consistent level of 90% iteration and 100% release acceptance levels.

Step 3 Scaled to Multiple Scrum Teams – We split the 20 person team that was working in a state of “pull” into multiple scrum teams to make meetings and communication more effective. We instituted scrum-of-scrum and product council meetings and built out the integrated build management system. We also instituted a stop-the-line philosophy with regard to broken builds. Set a goal of 90% successful fully integrated builds. We gained velocity in the individual teams, but struggled with the new hierarchy to steer a multi-team program. We broadened our product portfolio to include two products.

Step 4 Extended Agility Outside the Dev Team – We extended agility out to support and closed the loop with regard to feedback and defect management. By using our Agility Suite to link Salesforce.com and Rally, we tracked the lifecycle and cycle time of customer request. As a result, we gained customer intimacy and trust through increased communication and visibility into our backlog.

Step 5 Vision and Roadmapping – We then extended agility up to synchronize vision and roadmap across the company. Increased our discipline in business planning to help guide and synchronize our product vision and roadmap planning efforts. Also baked hack-a-thons into our regular release calendar on the last week of every release. We gained better alignment across the company and better day-to-day decision making across a distributed company of 75+ employees.

Step 6 Pull System Testing Forward into the Nightly Build – Working to move performance and security suites into the nightly process for all product editions and deployment options. Refactoring acceptance test regression suites to run in parallel and reduce run time by a factor of 10. Increasing the quality of the system and reducing cost of iterating with a faster regression suite.

Q. How does Rally gather and prioritize user stories or requirements from their large user community?

A. We prioritize at multiple levels and with multiple tools:

Daily tasks based on stand-up and any issues in production

• Iteration stories, every 2 weeks, based on iteration rank of ready items from the current release and any patch releases
• Release epics, every 8 weeks, based on value rank from roadmap, critical deals, market pressures, feature request voting by customers, hack-a-thon efforts and technical debt
• Product roadmap themes, every 6 months, based on strategic rank from market rhythms, market threats, market opportunities and the stage of each individual product in its lifecycle
• Product line resource allocation, every 6 months, based on vision, profit and loss, core purpose and business SWOT across the portfolio

Q. In terms of the scalability of Scrum and agile, what major differences have you observed between small-team scrum implementations and large distributed multi-team Scrum implementations?

A. The major difference between small teams and large distributed teams is the forced level of discipline. Many small teams can implement agile somewhat. With limited complexities, these teams can run with less discipline and fewer skilled “craftsmen” and still regularly ship quality software.

Large teams must increase their agile disciplines to manage the scale and distribution complexities or risk falling back to old ways. As a result, the level of tooling to manage cross-team communication, dependencies and signaling teams is a big difference.

Q. For organizations that are just starting out on their agile journey, what advice can you give in terms of cultural shifts they may need to make to support their agile teams?

A. Your blog post from mid-January said it best – take baby steps, celebrate the success and don’t bank all your savings from agile successes. Make sure to reinvest parts of your savings back into a continuous quest to learn and get better. This is a game of regular and continuous improvement.

Internally, we’ve seen great success by adopting agile practices using agile techniques (incremental, iterative, fully inclusive, guided by inspection and adaptation). Don’t try to bite off too much too fast.

Q. Your organization actively engages in and promotes Green IT practices.  Can you briefly discuss simple things every IT organization can do to green their business?

A. I think greening is just like adopting agile. We need to get our linear business process to become more feedback driven and sustainable. In this regard, the simplest things are not necessarily the right things. To green, you must get on a curve of incremental adoption. The right thing to do is to get folks from around the company to volunteer, set regular meetings, charter the group, baseline your issues and start picking off the visible, impactful and easy items. You need to build success and demonstrate value. It is really easy to “greenwash,” just like it is easy to “agilewash.”

Some easy things all of us can do:

• CF bulbs
• Motion lights
• HVAC timers
• PC power management software
• Building upgrades with the help of owner and city zoning
• Purchase Renewable Energy Credits for your server farm or travel
• Flex hours to support car pooling
• Work at home solutions

Q. How do you see agile practices contributing to the greening effort?

A. As I stated above, adopting agile and greening are both incremental improvement journeys, so teams that are on the expert curve to agility are in a good place to be successful in greening. The driving principles behind agile are the Lean principles of:

• Eliminate waste
• Empower teams
• Amplify learning
• Build integrity in
• See the whole
• Deliver fast
• Delay decisions

These are the same driving principles necessary to really create a sustainable company or industry. Fundamentally, I believe we have two perceptions wrong in the high-technology world.

• • 1. We have product mentality that drives us to follow a linear product lifecycle of taking materials, making products, transferring ownership and having customers discard them as waste. By moving software to a service model driven by agile, we can shift the power to software service providers and begin to change the entire high-technology industry to a more sustainable service model.
    2. We believe building software is a deterministic process and should be managed with traditional critical path methods of project management.

I have submitted this as a topic to Agile 2008. If you want to hear it, please jump in and add a comment here – http://submissions.agile2008.org/node/2100.

Q. In general terms, what do you think the future holds for agile software development?

A. Huge growth! This approach to software development is critical in a world with:

• Higher customer expectations for immediate action and quality
• Embedded computing everywhere
• The computer as collaboration environment
• Sustainable businesses networks
• More employees in software/IT because it is a sustainable and globally distributed market

A look beyond agile at the program level and into business agility and reliable innovation

• Closer connection to “the customer” through Web 2.0 communities
• Better tools to get the cost of iterating and current set-based development down
• Extended into other knowledge work areas

Believe nothing, no matter where you read it
or who has said it,
not even if I have said it,
unless it agrees with your own reason
and your own common sense.

• – 72% of CIO’s said that NO, they did not have a solid understanding of Agile Development Methodologies.
• – 72% of CIO’s said YES, they are open to adopting agile methods.

Now I don’t know about you, but if I don’t have a “solid understanding” of something, I’m generally not inclined to be open to adopting it!  I think I’d do a bit more research first.  Could this be the buzzword effect: “We have to adopt agile…it’s the latest and greatest” while in their head they’re thinking “What is agile anyway? I keep hearing about it”.

These same CIO’s went on to add their opinions on the importance for organizations to adopt agile methods:

• – 29% said extremely important, 50% said important, and 14% said somewhat important.

Hmmm…”It’s very important that we adopt something I don’t really understand.”  Again, maybe it’s just me, but I find these results rather funny…or scary depending on your point of view!

I think that unless you’re completely dominant in your market space, you need to be doing something like this to keep you innovative and on the competitive edge.  It’s the old innovation curves again.  You want to always be anticipating or defining what the next thing is.  If you don’t, you slide down the laggard side of the innovation curve and risk becoming irrelevant.  If you slide down that curve, it’s very difficult to get back up to that next innovation curve.  So, give your teams time to innovate…it’s good for your organization’s future, it’s good for your customers, and it’s good for the professional growth and health of your development teams.

I heard something recently from one of our agile teams when I listened in on a few of their daily stand-up meetings. For three meetings in a row, the same developer reported that he worked the same task all three days and was planning on working on it again.  One of the other developers picked up on this and said, “You only estimated 6 hours for that thing.  Are you having trouble with it?  Is there something we can do to help you out?”  There are two things I really liked about this comment.  First it showed concern about the estimate, but there was no blame attached.  It wasn’t “Hey, you said it was going to take 6 hours and now you’re 3 days in.  Are you really working or are you playing around?”  It expressed real concern.  And secondly, it asked the right question: “Are you having a problem with accomplishing your task?”.  Even though the first developer wasn’t reporting an impediment, the second was making sure than there wasn’t an impediment.  This led to a discussion between the developers about why this task was taking so long.  It turned out that the first developer was waiting on live data (not staged) from one of our clients and couldn’t make much progress without the live data.  I was really glad to hear this conversation take place between the developers.  It clearly illustrated the maturity of the team members to work collaboratively to identify impediments to reaching their iteration goal.

There are three key points I’d like to make about documenting agile meeting minutes.  First, I believe that the more you enable people to not attend agile meetings the more you encourage the behavior.  If team members have no place to read about the meeting or hear a recording, they’re forced to attend the live meetings.  If team members can simply miss a meeting and read a wiki entry about the meeting, while adding their own update to the wiki, you’ve enabled and encouraged the behavior of missing meetings.

Secondly, in agile development, we focus on developing working software, not creating documentation.  I believe this extends to meeting minutes.  If we time-box a daily stand-up to 15 minutes, that should be all we spend on the meeting.  If we’re required to document the meeting for those that missed it, we’re spending valuable development time writing up the meeting minutes.

My final point is in regards to a collaborative, tight knit team.  If we enable people to miss meetings, we begin to degrade the collaborative team environment that agile practices thrive upon.  The daily stand-ups and other meetings are a chance for the team to communicate with each other.  It encourages a collaborative team environment.  If team members are enabled to regularly miss meetings, they’re less likely to feel a part of the team and less likely to commit to the team goal each iteration.

So, to wrap this up….don’t enable people to miss meetings.  These meetings are crucial to the success or failure of your agile practices.

Our agile teams have examined our meetings and have effectively reduced our meeting time to the following: 2 hours for iteration planning, 15 minute daily stand-ups (and they’re usually shorter than that), 1 hour for our iteration review (usually shorter) and 1 hour for a retrospective (again, usually shorter).  This amounts to only 6 hours (or less) of meetings for every two week iteration or 7.5% of the iteration spent in meetings.  We think this is a manageable amount of time to dedicate to the various necessary activities of scrum to be both efficient and effective.   I think that anything shorter than these times would probably start affecting the value of these agile practices.  We are still planning without any problems and we are able to review two weeks worth of work in 1 hour or less with our clients.  We have also found that 1 hour is more than enough for our retrospectives.  Currently, we include these meetings in our project costs because we bid our projects as agile projects.  Our clients are aware of the value these meetings provide their final product.

So, based on our experience, I would suggest really examining the value of the meetings you use to keep your agile practices running.  If you and your team find that you are merely filling up time-boxes to do scrum by the book, inspect and adapt.  And remember, if you adapt your meeting times to be shorter and you are finding that you need more time for a review or for your planning session…inspect and adapt.  Scrum is an imperical “process”…keep experimenting with your meeting times until it feels right for you, your team and your product owner.  And, if you can agree with your client that these are project related costs that provide value and not overhead or operational costs, all the better for you and your client.

Trust works on several levels within our team.  There is the general trust in each other that when we commit to a backlog for an iteration, we will all work as hard as possible to complete those backlog items by the end of the iteration.  There also a level of trust that the scrum master and other team members will not judge team members at the daily stand up meeting or the retrospective.  This encourages an open communication of project successes and any impediments we are facing.  We report impediments not with the expectation of being looked at with suspicion, but being viewed as good.  If we can express our impediments openly, we all get better together…and that’s our key to success…trusting each other to raise issues and problems so that we can continually improve.  This also creates an atmosphere that is very conducive to true collaboration.

Although it sounds easy, trust is difficult to establish.  I shouldn’t really say difficult.  It’s that trust is not something you can just implement.  It grows over time and requires a mature team.  It also requires an organization that is willing to allow individuals to raise issues and problems in a judgement-free environment.  This is perhaps the biggest hurdle to trust.  Many organizations may be unwilling or unable to allow team members to express problems they uncover in the way a team works, etc., without a penalty.  True agile teams and organizations find ways to look at problems, issues, and dysfunctions as opportunities to grow and improve.  So, if I can give you one word to work towards as an agile team, it is TRUST.

I was really happy to see this.  It proved beyond a shadow of a doubt that our project teams are becoming mature agile practitioners.  They’ve realized that the issues uncovered in their retrospectives are important enough to warrant being put into a backlog.  This ensures that they won’t be ignored or forgotten about when the retrospective is over.  It puts the issues front and center and on par with development tasks.  And, it makes sure that we are actually going to do something about them within a time-boxed period.

So, what’s in your backlog?  Is your backlog filled with only development tasks or does it include stories about improving your team and your practices?  Take a look today and consider if you need to elevate these non-development stories to a higher level.

1. 69% of respondents indicated that their organizations are doing one or more agile projects.  Of those that hadn’t yet started, 24% believed their organizations would do so within the next year.
2. 44% indicated a 90%+ success rate at agile projects, 33% indicated between 75% and 90%.  It appears that agile seems to be working out.
3. Co-located agile projects are more successful on average than non-co-located, which in turn are more successful than projects involving offshoring.
4. 98.6% of agile teams worked adopted iterations, and 83% had iteration lengths between 1 and 4 weeks.
5. Smaller teams had higher success rates than larger teams.
6. 85% of organizations doing agile had more than one project completed, so it’s gone beyond the pilot project stage in most organizations.

Of course, this led me to my inevitable question that has been dogging me for some time.  If the adoption rates are so high amongst the mainstream development community, why hasn’t the GIS development community gravitated toward agile practices?  I know I keep asking this, but it really worth exploring.  To those of you out there in the GIS community, I ask you: should we conduct a similar survey to Scott’s and find out just what the state of GIS development looks like?  I’d like to hear your thoughts on this as I am seriously considering undertaking a survey like this for the GIS community.

Seeing that movie was the perfect impetus for me to write this post.  I’ve been doing a lot of thinking lately on how to take our company through the agile adoption process.  I’m thinking baby steps (minus the “Help!” scream hopefully).  Over the past few weeks I’ve spoken with a number of leading agile proponents about what they would do to adopt agile in an enterprise and the answer has been a resounding “baby steps”.  I’m glad to hear that because that’s how our small development team first adopted agile ourselves.  I don’t believe that an organization can just throw the magic agile switch and change things overnight.  I think that agile has to be grown organically in a series of steps that help organizations successfully adopt and accept agile practices.

The first step our team took was just getting into the agile “flow”.  We instituted some basic practices to get our team into a good rhythm and to introduce agile concepts.  We decided to begin two-week iterations on a single project.  We already had some half-way decent requirements definitions for the work.  But, we didn’t start prioritizing, building user stories, assigning story points, playing planning poker or anything else.  We just started with a simple, two-week iteration in which we tried to decide what we could complete during that iteration.  We planned the iteration collaboratively and really committed to completing everything we bit off for that iteration.  We also started the practice of a daily stand-up, an iteration review, and a retrospective.  That’s it.  We did that for quite some time until the team was comfortable with the flow of an agile, iterative development style.  It was working well, and it seemed to fit for our team.

Once we became comfortable with our new agile practices, we started to slowly introduce others into the mix.  We began re-writing our requirements as user stories.  We started playing planning poker to estimate story points.  And, we began to track our velocity.  As the ScrumMaster, I started to really protect the team from distractions and did everything I could to remove impediments for them.  Again, that was it for quite some time.  When we were feeling good about those, we introduced our client to the idea of prioritizing his backlog of user stories (it was a fixed-scope fixed-price contract, but we thought this was a good exercise to learn from anyway).  We also started to really emphasize acceptance testing.  Once we were alright with this set of practices, we took a look at what we should be doing on the actual development side to become more agile.  We introduced continuous integration, daily builds, lite versions of paired programming.  Again, just a few small practices that helped us slowly become more agile.  Our next step was release planning.  Around that time, we introduced some tooling for managing the projects (Rally) and we also began doing serious defect tracking and fixes with some tooling as well.  We had also decided to start implementing agile practices on some other projects that our team was responsible for.

When we felt that we had a handle on our own team, we started to evangelize to our peers and our organization.  The organization caught on after some convincing and started sending other project managers to Certified ScrumMaster training.  We were going to start sending members of our team out onto other project teams to help coach and guide them in their adoption of agile practices.  However, we left our old organization before we got to realize the full enterprise adoption of agile, but we were well on our way to getting them there.

Now, with our new company, we get to do it again…and we’re much smarter from our previous efforts.  And our new company has an organizational culture which is very supportive of agile practices.  As we move through our adoption process, I’ll keep you posted on our progress, but I’m pretty sure we’ll be taking baby steps first.  Baby step into the flow…baby step into agile practices…we’re doing agile development!!!

“One faces the future with one’s past.”

Short, sweet and to the point.  The quote really struck a chord with me because our development team recently learned this lesson the agile way.  Last Friday, we completed the second iteration of an enterprise GIS development project and conducted a sprint review with our client.  To our dismay, we seemed to have been off the mark in terms of what the client was expecting.  The client seemed disappointed and our team was as well.

After the review, we conducted a team retrospective and the main topic was “Why did we miss the mark so badly?”.  It was the right question to ask and sparked a very open discussion.  We discovered that we had not adequately uncovered the business cases behind the user stories, that we had a communications gap with our client, and that we didn’t do a thorough review of the client’s existing application.  We then asked the question “What do we do to fix this?”.  We decided that at the following sprint planning session, we would discuss the user stories with our client again.  We decided to hit the problem head on and increase our communications with the client and thoroughly review the existing application.

On Tuesday, we held our scheduled sprint planning session with the client.  We gave our apologies for our missteps, emphasized the value of agile for helping catch this issue quickly and initiated a great, open, and collaborative planning session.  To our pleasure, the client had identified the same set of issues as our development team had  and came prepared to give a demo of the existing application.  They were also very patient answering the questions our developers had about the user stories. In the end, everyone walked away from the sprint planning meeting feeling that we were back on track.

We also walked away with the feeling that our agile practices had done their job.  They helped us raise any dysfunction to a visible level very quickly, and also allowed us to resolve those issues very quickly.   If we had been developing in a traditional waterfall fashion, we could have been 6 months into development along the wrong track before anyone realized there was a problem…and by then it would have been too late.  We would have had angry clients, a discouraged development team, and a failing project.  Instead, we face our future with the full understanding of our past mistakes, a satisfied client, and a motivated development team.  You live, you learn…