If you could point someone to just one link...

...as a quick summary of what agile is, which one would it be?

This is a question I just got asked. And I'm honestly not sure. It would depend a bit on who that "someone" was. But here's a very general definition for agile software development (ignoring the application of agile to other disciplines such as marketing) that I think might be OK.

Agile is an approach to developing software that:

• Focuses on prioritizing the most valuable features first
• Organizes work into short (typically 2 – 4 week) chunks of time typically known as iterations
• Builds and tests one or more complete new features inside each iteration
• Shows and discusses what they accomplished with the customer at the end of each iteration allowing regular feedback and guiding of the effort
• Acknowledges that it is nearly impossible to figure out completely up front what people want from a software system, and that their opinions and business needs will change as they start to see it built. 
• Relies on cross functional teams (developers, testers, whatever else is required)working as a self-organizing group to accomplish their goals. A good example of a self-organizing team outside software is a sports team, e.g. think how soccer players collaborate with the end objective of scoring goal(s).
• Employs a number of technical disciplines to allow incremental development, with a particular emphasis on the importance of regularly integrating and testing code with as high a degree of automation as is sensible

I'm sure there are much better quick'n'simple overviews along the lines of "What is agile?", but it's surprising what you get if you google that. Based on the couple top links I visited it wasn't ideal as an explanation for a  general audience.

Understanding progress: on points, velocity and when to add new stories

Building software takes time. Usually enough time that people are interested in monitoring progress and understanding when it will be done. Agile teams often use User Stories as a unit of work. Typically these are estimated in points enabling a team to record their velocity, that is, the number of points completed per sprint.

With this data, teams have a simple means to show progress. Interested parties can follow along quite easily, seeing how each sprint eats away at the features in the backlog and how many points are left to complete the product. Using the team’s average velocity will give a nice indication of how many more sprints are required to complete the features in the backlog: points remaining ÷ average velocity = sprints remaining.

There is one wrinkle to this otherwise simple scheme. As anyone who has developed software can tell you, the devil is in the detail. Something that initially looks simple can end up being more involved than originally estimated. Case in point: my team recently had a story like the following for a desktop client image processing product they are building:

 
     As an imaging assistant
     I want to be able to open JPG images
     So that I can process them

The story seemed to be straightforward and was implemented easily and quickly. All was well until we tried some particularly large JPG files. At this point things blew up with out of memory errors and the like.

So was handling large JPGs a new feature and thus a new story? Or was it obviously part and parcel of the original? In other words, the question is how do you deal with this and still report easily understandable progress?

The short answer is it doesn’t really matter. You can add new stories to the product to cover the new work that you discover. Or you can just do the work that was implied but not necessarily obvious from the original story. The formula for figuring out how many sprints remain still works either way. Taking the former approach your velocity is likely to remain fairly stable. Taking the latter approach you may see it bounce around a little bit more, or see it dip from historic levels if the team had a velocity established through more predictable types of work (e.g. maintenance on a well known product.)

The longer answer is that each approach has its own pros and cons. Depending on your situation one may be better than the other.

Adding a story, pros:

• Stakeholders can see the amount of work we original imagined was involved has grown and have more chance to comment on the necessity of these items – perhaps the complexities and edge cases discovered aren’t that valuable.
• It probably shouldn't matter, but velocity remains stable and nobody feels the need to cross-examine the team and ask "Why has your velocity dropped?" Done this way velocity may even serve as a crude indicator of team performance and improvements can be seen in higher velocity.

Adding a story, cons:

• It probably shouldn't matter, but there's likely a class of stakeholder that will question why all this "extra" work is emerging and ask how come we failed to identify it in the first place.
• If the team has the pleasure of using a computerized agile lifecycle management tool then each additional story is another thing to enter, estimate, prioritize, track and update status on etc.
• The number of points to complete the originally envisaged release keeps growing making some people anxious: "We don't know how much work is left to do, how can you ever hope to predict when it will be done?"

Not adding a story, pros:

• Nothing extra to track (though we probably need to clarify the acceptance criteria of the original story)
• Number of points to complete original feature set for the release remains the same (unless we discover a need for genuinely new features)

Not adding a story, cons:

• The potential roasting of the team: "Why is your velocity erratic/dropping?"
• The team might miss an opportunity to push low value work down the backlog.

Personally I'm most strongly drawn to the idea of not adding in extra stories. I like the simplicity and minimalism of this. The more items there are in the backlog the harder it is to grok the thing as a whole and more busywork goes into managing it all. I don’t think the “pros” of adding in extra stories are powerful enough to make it the preferred approach. And although there is the potential “con” of the team getting questioned about why their velocity is erratic or dropping, I believe this can be explained quickly in simple terms. I also think it’s a lot more straightforward, even comforting, for stakeholders to see that the size of the backlog remains fairly stable unless things they too understand as new work (features) get added.

Enemies of Agility: The Dirty Dozen

Developing software is hard. Agile software development represents one way to deal with the complexity and difficulty in a manageable fashion. Arguably the best way we've figured out so far. But it's not easy, and there are many impediments on the road to becoming a highly adept agile team. Below I present the "dirty dozen" impediments, or key enemies of successful agility that I've observed.

1. Management doesn’t understand agile
An individual team or two can get quite a lot of improvement by themselves. But to really scale up agility in an organization requires a deep understanding and commitment to the guiding principles from managers across a range of functional areas. Attaining that in a large corporate environment is surely hard. Even among the engineering or IT groups that might have more capacity or interest to “get” agile at a management level there are challenges. How can people many years distant from the act of actually creating software really understand what changes are occurring on individual delivery teams if they haven’t experienced them first hand themselves? How can they help shape and encourage greater adoption and performance, policies and culture if they are not actively engaged in a deep meaningful way with agile? How can they negotiate effective cross-department agreements when they don’t really understand how their teams are working?

It’s hard. Not impossible though. What it requires is a willingness at the management levels above individual delivery teams to immerse themselves in as much agile as they can. Go to conferences. Get the deep dive that your two day agile orientation course didn’t give you. Read books. Lots of books. Join mailing lists and discussion groups. Read the blog posts people put out there. Follow the thought leaders on Twitter. Participate on a team for an iteration – there lots of ways for people of different skills to do this. Pair with the PO to groom the backlog. Pair with a coder and/or tester. Do some exploratory testing, etc. etc.

Once managers have experienced being and doing agile they have a much greater chance of extending those principles up and across the organization.

2. Team doesn’t understand agile
Understanding agile requires more than sending one (or more) of the team off for a two day Certified Scrum Master course. And it’s considerably more than saying “go do agile.” I’ve talked with lots of people for whom this is all they’ve had, and it’s clear that the depth of understanding is far shallower than it needs to be to really improve.

From my experience two things are required for a team to really understand agile deeply rather than just go through the motions. Firstly, as suggested above with managers, people on agile teams need to really immerse themselves in the wider agile world. There is an immense volume of great stuff to discover, read, try and learn out there. Harnessing that will help a team understand what other people are doing and being successful with. Secondly, the team needs a coach, at least at the outset. The coach needn’t be an externally hired consultant; it could simply be an experienced scrum master or effective manager. Someone who can help guide the team away from common pitfalls and remind them of common pitfalls.

3. Team doesn’t understand end users
How can you make intelligent decisions about the software you are building and testing unless you have a deep understanding of the way it is used? Not understanding the product can lead to several problems: PO or some other key figure becomes a bottleneck; requirements become gospel and no intelligent interpretation is allowed; stupid things get done because people misunderstand needs; etc.

Depending on who and where your users are vis-à-vis the team this may or may not be easy to address. Ideally your users are accessible and team members can spend time with them regularly to understand better the world in which they work. Where this isn’t possible some effort should be put into finding ways to make sure the team understands the users as much as possible.

4. (Micro)managers who’re not on the scrum team interfering
This can be a particularly debilitating and frustrating class of dysfunction. How is a team meant to develop the ability to self-organize and self-manage if team member’s managers regularly disrupt matters?

This can manifest in a variety of ways:

• Dictating how work should be done
• Dictating priority thus undermining the PO
• “Refining” or challenging estimates
• Focusing on velocity over quality and predictability
• Injecting additional work
• Making promises to external parties without consulting the team
• Having conversations that influence technical decisions absent the team
• Confusing stakeholders by offering an uniformed, contradictory and out of date view of status

Managers may indeed have a lot of experience to offer to their teams, but micromanaging interference will sap teams’ engagement. Managers need to realize that they should go about things in a less directive fashion than they may have previously. Rather than push down decisions and work, managers need to harness the talents of a team and present the results up and out to the rest of the organization. Teams typically have (or can develop) regular and agreed upon venues and approaches for managing the how and what and when of their work. Managers who wish to influence things must utilize these to obtain team buy-in and agreement. Failing to do so invites resentment, apathy and underperformance.

5. Inappropriate or suboptimal tools
This is a problem that occurs more in larger organizations where well meaning people want to “standardize” on things. Things like last decade’s monolithic proprietary testing frameworks or agile lifecycle management tools that get slickly pitched to executives offering alluring reports to analyze all their staff but offer limited useful functionality to the actual teams using them day in and day out.

I’m not sure there are any good immediate ways to address this kind of problem. Perhaps when management obtains a deep understanding of agile principles such issues will diminish. In the interim, if the subversive option of simply going your own way, irrespective of corporate mandates is a possibility, I say go for it.

6. Poor technical and problem solving skills
Building anything but the most trivial software is hard. It requires good people. People with excellent technical and problem solving skills. This is as true of traditional approaches to software development as it is to agile of course. Good people will do better with a bad process than bad people with a good process.

Agile software development tends to “out” people who don’t make the grade more so than traditional forms of development where people could go weeks or months without having too much scrutiny applied to their work. The focus on building small, incremental, potentially shippable features in short blocks of time especially needs people with good technical and problem solving skills.

People need to be able to write good code: well designed, well factored, elegant and simple. They need to understand how to effectively use unit tests, to understand the benefits of continuous integration, pair programming, TDD, source code control, automated testing and on and on. They need to be able to approach problems with an engineering mindset, to solve problems scientifically, methodically. A team absent these skills will have problems.

7. Poor written and verbal communications
Having the technical and problem solving skills mentioned above is not enough. People need to be able to communicate effectively too, especially on agile teams.

When people are unable to explain themselves coherently there is a massive drag on the team (and potentially outside the team too). People have to clarify what people are saying are writing about. People have to dig for more information that is absent or not understandable in the original communication. People have to guess and may misunderstand. All of this is frustrating and costly.

8. Apathy
“It’s not that I’m lazy, Bob. It’s that I just don’t care.”

Some people are bored. Some people don’t understand what the purpose of their work is. Some people just want to be left alone to hack code and they perceive that agile gets in the way of that. Some people just want to be left alone to cruise Facebook. Whatever the cause, apathy will drag a team down.

Managers have a large stake in combating apathy. Assuming your company is doing something purposeful make sure people understand what it is, why it’s important and how they can help. Make sure they feel empowered to influence the work, the team, the tools. Help create intellectually interesting challenges that marry business needs with opportunities to grow. Support their learning and training needs. Shield them from soul sapping pointless drudgery. In short, make them give a shit.

For those wondering: what if we grow all these people with training, give them an opportunity to develop new skills and master new technologies and then they leave? Consider this: what if we don’t and they stay? Unmotivated, low-skilled, bored people will not a successful product make.

9. Inability to create good user stories
Admittedly one can quite happily apply agile software development principles without user stories. However, they currently sit as the most popular unit of work for agile software development.

A common “starting package” for a new agile team is comprised the set of Scrum ideas plus user stories as your unit of work, a product backlog and estimation using story points. For a team to get familiar with this is fairly easy. Scrum proscribes a set of standard meetings: sprint planning, daily scrum, sprint review and retrospective. Estimating in points requires a little more explanation and practice typically but eventually seems to work nicely for most.

The hardest part though in my experience is to understand and employ user stories well. The five most common problems seem to be:

• Stories for everything: setting up new servers, writing a summary of findings, having a meeting, etc. etc. Stories are about features the software should have that make sense to users of the product. This is closely related to the misunderstanding of velocity item below.
• Stories that are tasks: this is similar to the stories for everything problem, except that even when your stories are constrained just to product features it’s still possible to write them as discrete tasks rather than describing a full end-to-end feature.
• Stories artificially bounded by system architecture: It’ll depend on your users, but for most users of most applications they do not know or care that your product is made up of different components. Devising stories for “the server” and “the client” may well be an indication that you’re not thinking about features from an end user point of view but from a system design perspective.
• Abuse of the “as a  I want  so that ” formula: for many people a story is simply stating your requirements in this format. This often leads to rather convoluted looking stories. Couple this with the stories for everything or stories that are tasks problems above and you end up with things like “As the scrum master I want some administrivia completed so that I can report it to my boss.” This is pretty far adrift from where you want to be.
• Poor acceptance criteria: conveying who wants what and why is a good start. But it is also essential to bound the scope of the story with good acceptance criteria. Ambiguity leads to confusion, poor estimates, frustration and potentially disappointment.

There’s no easy cure for this problem. You need someone on the team or someone coaching the team to a point where they have a good understanding of user stories. That or everyone reads Mike Cohn’s User Stories Applied…

10. Lack of automated testing
Whenever you change software there’s always the risk that you unintentionally break something. Sometimes you can make good educated guesses about what may break as a result of your changes. Other times the most innocuous seeming change creates a cascade of fail in the most unlikely of places. To make sure your changes don’t break things that were working before you need to test your software.

If you test it manually then the more your software grows the more time you need to execute your tests. One can imagine how, over time, more and more of an iteration could be taken up with making sure the newly added features haven’t inadvertently broken those that were already there. Developers are left with nothing to do and test staff are run ragged trying to keep up. Clearly a bad situation.

While an automated test suite may take more and more time to run it’s nothing like the days or more that manual testing requires.

You simply cannot hope to incrementally add features, release regularly and maintain quality without automated testing.

11. Misunderstanding the purpose of velocity
Velocity is not a measure of all the work a team has done. It’s a measure of how quickly a team can turn a backlog of product features into working software. When people add stories for training or support or infrastructure maintenance, sometimes retrospectively, ostensibly to “capture the work” or “earn credit for what we’ve done” this pollutes your velocity. It no longer provides an accurate measure of how much a team can advance a product. You might as well record that people work 40 hours a week.

By measuring velocity as just how many product features the team can implement in an iteration, and treating everything else as overhead you are in a much better position to predict how long it might take to burn through the rest of the backlog.

One of the reasons this problem can arise is a simple lack of understanding. That’s easy to correct. The more challenging problem is when teams are being evaluated by velocity: why did your velocity drop during the last iteration? Why isn’t your velocity increasing since we added Bob to your team? That thinking is missing the point. The value of velocity is improving your ability to predict when a product will have a certain set of features completed. It is not a means for measuring productivity.

12. Toxic team member
The toxic team member comes in many guises: antisocial, incompetent, arrogant, slacker, anti-agile skeptic or just general poor team fit. Irrespective of the particular flavor, one bad apple can cause a lot of damage.

I believe everyone deserves a chance to change. Some frank feedback may help. But, ultimately, if someone’s not working out they need to be…redeployed elsewhere.

What I got out of Mile High Agile 2011

This is a slightly longer than usual, rambling somewhat whimsical post. Sorry about that. There is some good stuff toward the end though. Well I think so anyway.

Last Thursday I attended the inaugural Mile High Agile conference put on by Agile Denver. The day commenced at an unnaturally early hour with me hurtling down the mountain to Golden and then doing battle with I-70 and I-25. Perhaps due to the early travel time the traffic was lighter than the nightmare I had envisaged and well worth it compared to my regular commute (from bedroom to basement via kitchen) for what I got out of the day.

What follows are my thoughts on what I got out of the conference, not all of them directly related to agile.

Earlier in the year when I first heard about Mile High Agile I volunteered to help with a couple of items – setting up the website along with another volunteer and the corresponding registration and payment system. It’d been a while since I’d done any kind of web content creation but we elected to make things really simple by just using WordPress with a suitable theme. Although this obviously meant there were quite a number of restrictions (especially since we weren’t hosting the WordPress blog ourselves) it did mean we could get going easily and quickly. Given the chance to do it again I’d almost certainly stick with WordPress considering the simplicity of our needs, but hosting it ourselves would be well worthwhile. That would likely let us get around the problems we faced by using plug-ins which you cannot do when hosting at wordpress.com.

For the registration and payment side of things we used EventBrite. This was a service I hadn’t used before (at least not in the role of a conference organizer) and I have to say it’s a pretty impressive offering. While our needs were simple (a handful of ticket types, a few dozen discount codes, simple reporting and so on) EventBrite just seemed to work without effort. Everything we ever wanted to do (bar one thing) seemed to have already been anticipated and worked well. In addition, I had occasion to use their support services twice which are very good and incredibly quick to respond.

In the couple months leading up to the conference last week I really enjoyed working with the folks that brought this together. My contribution was pretty small compared to others, but it was fun to be part of it and work with people really intent (passionate is so overused, no?) on making this happen. It was a real joy to see folks pitching in no matter their role offering useful ideas and commentary as things unfolded. I wish I could work with more people like that more often.

At the beginning it was unclear how many sponsors we would secure or how many tickets we could hope to sell. Due to a truly outstanding effort on the part of several people we exceeded all expectations. Just check the number of sponsor logos up on the site and note that we sold nearly 500 tickets. Not bad for such an incredibly tight timeframe and the first ever Mile High Agile conference! If you build it they will come. So long as you get the word out and market it hard too.

There were a few things that struck after the day of the conference which were nothing to do with agile but interesting insights to me. I’ve been working from home for quite some time. Although I thought I had quite a rich interaction with people on my team via phone, email and IM etc. it was nice to suddenly be in the fray of lots of tech people and talking with them. I was part of the gang that stood behind the registration desk which was insanely busy for an hour or so as the best part of 500 people arrived to check in. It reminded me of a part-time job I had way back in time as a teenager, working in a home computer store on Saturdays which were always insanely busy. I loved it. Definitely makes me hanker for more local, in-person interaction.

Another thing that was weird was that driving into Denver didn’t seem too bad. I’ve always found it less than desirable in the past, but after a series of trips into the city over the last year perhaps I’ve finally got a decent sense of how its all connected up in my head and feel more at ease with it. For some reason I’m feeling the urge to visit Denver more and more.

The final odd little insight was how nice it was to be surrounded by people who were enthusiastic about various facets of agile software development. Although you might have different views and experiences from others on details, there was this common thread of “getting it” (“it” being agile) and wanting to “get it more.” Perhaps meeting people whose viewpoint reinforces many of your own beliefs is nothing but an ego stroke, but it made me think how cool it would be to work with more people like that.

Turning to the sessions I was able to attend three, all of which were in the technical track. I really enjoyed them. I wish there was more – it’d be great if next year were a multi-day conference :-) It also made me think it would have been nice to present. I’m not entirely certain what on, but I feel like I’ve learned a lot over the last couple of years and it’d be fun to share some of that beyond just writing about it on my blog. Maybe next year.

The first session I attended was Agile the Pivotal Way given by Mike Gehard of Pivotal Labs. I confess I hadn’t really realized that Pivotal Labs did anything other than make Pivotal Tracker. Turns out that really their business is building software for people, often startups, and they seem to really approach work in a way that makes a lot of sense to me.

Mike mentioned that they pair program everything. This reminded me how much I miss pair programming. I’ve had two serious periods of pairing in the past and I’m pretty sure it’s the best approach for a lot of software development work. The first time we didn’t call it pair programming because it was just my 12 year old self and my friend hacking away on a Commodore Vic 20 writing games in BASIC, PEEKing and POKEing the screen to make games that rivaled Pac Man. Almost. But it was great. The other time was much more recent. It’s how I learned Java courtesy of a colleague pairing extensively with me. It’s also how the first release of one third of our product suite got built incredibly quickly, by just me and that other guy. If I’m going to be programming in the future I hope it’s pair programming.

Mike also mentioned how their “teams” were small, and unless their clients insisted there were no independent QA or tester roles and no PMs. They (the pairs of developers) did this stuff themselves. Thinking back again, the best software I’ve ever written was when I was completely immersed with clients and talking to them directly and I had to make sure it worked as it should. No middle man (or woman) interpreting customer needs and nobody else to leave finding bugs to, and since I don’t like my things to fail I sure as heck tested the heck out of my work.

All in all, I wish I knew a lot more about Ruby and Rails because they sound like a totally cool place to work. I’m not sure if Mike’s talk was meant to be a stealth recruitment exercise, but it could certainly work as one.

The second presentation I attended was from Chris Powers of Obtiva. He was talking about test driving front end code, and by front end code he specifically meant Javascript. It’s a few years since I’ve dabbled with JS and probably don’t have any dabbling in the near future, but it was still interesting and credit is definitely deserved for live demo and coding activities. The tool Chris showed was Jasmine, and while I have nothing else to compare it to it seemed pretty neat, and I definitely liked the BDD-esque feel and the ability to express both feature and unit tests. If I were to be doing any JS in the future I think I’d be checking it out.

The third and final session I attended was given by Paul Rayner and was entitled Strategic Design using DDD. There was some though provoking stuff in this. First of all there was the Purpose Alignment Model by Niel Nickolaisen. It’s a simple idea whereby you can map out work onto a graph with four quadrants like so:

Of particular interest here is the notion that those things which fall into the top right quadrant are the ones you want to put your best effort into – you want to get the best people working on this and you want to really pay attention to the design of this stuff. By contrast, those items that fall into the lower left quadrant do not merit that kind of effort.

If I understood Paul correctly, he was advocating the use of the above to think through just how much effort you put into the design of various components of a system. That seems like a good idea. But what also struck about this from an agile and scrum perspective was how such a simple thing could be used to facilitate feature prioritization in product development. Now I’ve seen before the idea of having the stories (or themes or features or what have you) up on post its on a white board, and allowing people to move them around placing those the see as highest priority at one end and lowest priority at the other. But this would overlay a slightly more rigorous evaluation of things. If, when using the open whiteboard technique, someone places an item over on the high priority side I am not immediately sure why. If the whiteboard was divided into four quadrants like the above I would immediately see if they thought it was mission critical, a market differentiator or both. I think that could be powerful.

The second thing I got out of this session (actually a little afterwards, after Paul had blogged on the topic) was that the popular idea of “emergent design” is great if you can do it well. But how many teams really have the design and refactoring skills to pull this off? How many can spot good and bad directions to emerge to. Having a framework to first identify what components of a system merit more well-crafted design than others along with a set of good design skills to apply would indeed help I think.

The third thing Paul talked about which stuck in my mind was his "billboard test." The idea here is that if you take something you're working hard on and imagine it up on a billboard is it really the message you want conveyed? Consider his example: "Our logging framework kicks butt!" Frankly, unless your company actually sells logging frameworks realizing that you're putting this much effort into logging ought to give you pause for thought. Like say for example "Our test automation framework kicks butt." Or whatever. (Inside joke)

And that’s it. The trip home was quicker than I thought it would be too. Was very ready for the highway to have turned into parking lot but things zipped along nicely.

"If it ain't broke, don't fix it" vs. "Continuous improvement"

I don’t really remember when I first heard the phrase, “If it ain’t broke, don’t fix it,” but I’ve used it plenty. Upon reflection I’ve mostly used it to avoid doing boring or unappealing work – endeavoring to cast undesirable requests as wasteful and unnecessary changes.

Thinking about it though, there is a fair bit of wisdom in the saying. Researching its origins turns up a surprisingly recent (to me anyway) provenance. Apparently one T. Bert (Thomas Bertram) Lance, Director of the Office of Management and Budget in US president Jimmy Carter’s 1977 administration is often accorded recognition for first use (although there appears to be a reasonable case for it already being in circulation in the Southern United States). He is quoted in a newsletter as follows:

Bert Lance believes he can save Uncle Sam billions if he can get the government to adopt a simple motto: “If it ain’t broke, don’t fix it.” He explains: “That’s the trouble with government: Fixing things that aren’t broken and not fixing things that are broken.”

Hard to argue with that, eh?

Having used (and possibly abused) this phrase for years, I was given pause for thought yesterday when it was tossed my way. It’s not like it’s the first time that’s occurred, but it was one of the less regular occasions where I thought , “OK, maybe what I’m trying to change isn’t broken per se, but it could be better.”

For the last few years my work has involved a lot of change. My organization has transitioned (indeed continues to transition) from a very rigid, waterfall style process of software development to an agile one. When we started out we had a pretty naïve idea of what this entailed. We were already doing work in iterations – kinda – by providing a new build to our QA/testing people every two weeks. We made a series of small changes over a relatively short period of time (I wrote about those here, here and here) and ultimately we settled upon Scrum as our specific flavor of agile.

You don’t have to spend long with Scrum to realize that one large facet of it is pushing for something a bit different to the idea of “If it ain’t broke, don’t fix it” (which henceforth I’m shortening to IIABDFI.) It’s pushing continuous improvement, or Kaizen to borrow the rather snazzy Japanese word for it. This notion is baked right in to Scrum, with every sprint having a retrospective at the end where the team looks for ways in which they might improve things.

As much as I latched onto and used the IIABDFI idea, I find Kaizen considerably more appealing. IIABDFI is mostly a crutch for me to skirt doing boring work. But Kaizen appeals to my inner perfectionist. Anyone who’s worked with me can probably tell you that I have tendency (likely somewhat annoying) to always critique the status quo. I can’t seem to help seeing things that we could change that I think would make everything just a little bit better. This characteristic hasn’t served me too badly in the past, and when I’ve worked with people of a similar bent it’s created quite a good dynamic with people all interested in continuous improvement bringing in great new ideas and accepting them from others. There can be moments of trouble if two well meaning people hold strongly differing views on what constitutes "better", but mostly things are obvious enough as improvements that a little debate is all it takes to agree upon trying them out.

I’d never really thought about these two ideas juxtaposed though, until today. Kaizen really resonates with me. But, as IIABDFI says, changing things that aren’t broken is indeed wasteful. So, how to reconcile the two?

Well, I think its all about degree. If there’s a potentially worthwhile pay off, if it’s reasonably cheap to try, maybe it is well worth changing things that aren’t especially broken. You might learn through trying your new approach that what seemed reasonable before was, if not broken, ripe for substantial improvement. And if it doesn’t pan out? That should be OK. Trying new things involves some risk. Sometimes things don’t work and you need to revert to the original way of doing things. Unless you’re drastically affecting quality or productivity or some other key facet of software development then I’d argue that trying new things should be encouraged.

If, on the other hand you’re thinking of a disruptive or expensive change, and the outcome is uncertain, and what you’re already doing is seemingly OK, perhaps that’s a red flag. Perhaps that’s when you need a slap around the head from IIABDFI to remind you not to get carried away.

What do you think?

Shouting is not an agile value

The Agile Manifesto is well known:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Related, but perhaps less well known is the idea of Agile Values. Their origin lines in Extreme Programming, with there being five recognized values as of the second edition of Kent Beck’s Extreme Programming Explained.

In brief the five values are:

• Communication – amongst all on the team
• Simplicity – of design, emphasizing ideas such as implementing the simplest thing that will work and the acronym YAGNI (you ain’t gonna need it)
• Feedback – feedback from automated tests, from the customer and from the team
• Courage – to keep things simple, to implement only what is needed today, to refactor and throw away code that’s no longer needed
• Respect – for other team members, for the customer

The fuller definitions can be read on Wikipedia (or of course in Kent's book).

One blindingly obvious thing you’ll notice is that shouting is not an agile value. Never was, never will be.

Well duh!

So why do I mention this? Oh well, you know. It’s not like there aren’t some managers who use that as a “technique” for trying to get what they want. It doesn’t necessarily have anything to do with agile, although regrettably I’ve seen it (and once done it myself) in response to somebody just not getting our new technical practices that came along with the agile adoption.

In my case it was due to extreme frustration with somebody who seemed almost perversely reluctant to commit code to the source control system. He was passing around changes to other colleagues by emailing them Java source code. This wasn’t the first difference of opinion about developing software I’d had with the gentleman in question. He harbored some curious ideas and was not enjoying our change over to Scrum.

I confess I rather lost the plot as we were there in the office late at night desperately trying to make sure the team made their sprint commitment. I blurted out rather loudly “What the $#@! are you doing?” I did quickly apologize and later after we’d got the job done we went to dinner and made up. I’m not proud of that moment and it’s not a “technique” I ever intend to use again.

Nonetheless, there are folks out there of a more strident nature inclined to use it far more frequently. I don’t know if their threshold for frustration is lower than mine or if they just need an anger management class or what the deal is. Suffice to say though, as an approach to trying to coach staff into doing what you want it’s not a winner. Indeed it’s a completely toxic behavior. Even if Mr or Ms. Shoutypants has great ideas people are very unlikely to ever “hear” them because they’ve written him off as an aggressive belligerent asshole.

Patience. Now there’s an Agile Value. In fact it’s a key one I believe. Stimulating, inspiring, managing and maintaining the change to agile practices takes effort. It takes leadership. And it takes patience. And so I propose that we add to communication, simplicity, feedback, courage and respect the value of patience.

Mind your language!

I find it hard to pick out a favorite quote from Guy Ritchie’s cult movie “Lock, Stock and Two Smoking Barrels.” It’s just chock full of great lines.

Ignoring the obvious masterpiece from Rory, one exchange that I’ve always remembered with a smile is between Harry’s enforcer, Big Chris and his son (who is of course known as little Chris). They’re visiting someone who owes Harry money, and Big Chris’s son rifles through the indebted man’s belongings. Upon finding a serious pile of cash he exclaims: “Fuckin’ hell John, do you always walk around with this in your pocket?”

Big Chris, despite the dubious London underworld he and his son inhabit appears to have aspirations for his son to remain reasonably polite. He replies, “Hey! You use language like that again son, you’ll wish you hadn’t!” Unless you’ve seen it, it’s hard to appreciate the energy with which that warning is delivered.

Despite immersing myself in agile and Scrum and the language that comes along with that, and despite doing my best to socialize it over the last couple of years in my engineering group I think there are limits. Just as Big Chris doesn’t necessarily want his son to use the lingua franca of the underworld everywhere, I think you need to consider how far outside a development team you use agile and scrum vocabulary.

One of the three legs of Scrum is transparency. But being too transparent isn’t necessarily a good thing (think body scanners in airports, for example).

Maybe, if your entire organization has decided to operate using scrum, in everything from sales and marketing to operations, HR and accounting as well as engineering then you can happily talk about daily scrums, sprints, points and stories and velocity. But if they haven’t, then I think you have to balance carefully the education of those groups with whom you interact and the language you use.

For me, there are three key pieces of terminology that I am, with hindsight, wondering about the wisdom of sharing widely.


Story
Yep, I don’t think we should be talking about stories. Now don’t get me wrong. That doesn’t mean I don’t think we should be using them. On the contrary, I’ve said it before and I’ll say it again, one of the most profound books for me as I was learning about agile was Mike Cohn’s "User Stories Applied."

The concept is great. As a unit of work it’s perfect. For organizing requirements it’s helped tremendously.

However, as a term to use with unsuspecting business stakeholders, customers and so forth I’m not so keen. Frankly it sounds rather ridiculous. I’ll stick with feature, thanks very much.


Sprint
Few people with practical experience of dividing your development up into fixed duration timeboxes is a bad thing. But do we have to call it a sprint?

One of the things I like about Scrum is the fact that done right nobody’s having to dash like a lunatic to cram in all the last minute jobs to ship your product. Instead what we have when we do it right is a predictable, sustainable, humane way to utilize teams.

Sadly sprint conjures up anything but that vision.

These days I prefer to describe that we work in short two-week cycles, and if I need a short snappy name for them then iteration works just fine.


Points and Velocity
I’ve pulled these two terms together as they really go hand it hand. At least, if you’re estimating stories in points but not measuring your velocity you might want to reevaluate what you’re trying to achieve.

And these two are a little different for me than story and sprint. Whereas those are just unnecessarily goofy in everyday conversations with the wider business, and alternatives can serve us better, points and velocity need very careful handling, whatever you call them.

Here’s the problem – points and velocity are a tool for the team to be able to evaluate their performance, to plan and make reasonably firm commitments. Stakeholders outside the team should be concerned more with what gets done and in what order. The Product Owner and team together can use points to respond intelligently to new requests, to switch things around, and figure out what fits where and what needs to get dropped.

But start telling your stakeholders too much about average velocity, the points involved in a particular story and you inevitably risk them starting to focus on points rather than the “what should we do” and “what order should we do it in” issues. Perhaps in a really mature agile environment were a deep understanding of what points and velocity are for this wouldn’t be an issue. But early on in an agile adoption I think care is needed.

Too much data on story sizes in points, team velocities and so forth risks the following questions:

“Can’t you do more points per sprint? Why didn’t you make your commitment? Why has your average velocity dipped? Why does the tracking team have a higher velocity?”

Those kinds of discussion are not the most value one can extract from a stakeholder. I don’t want to see agile teams micromanaged by a group of well meaning people who know nothing about agile software development. But we are baiting them into doing exactly that if we report too much detailed data about points and velocity. Before you know it they’ll be looking at your definition of done suggesting we don’t need to do unit testing and who knows what else…

I say keep the dialog with stakeholders confined to steering the product, negotiating the relative priority and let the team use points and velocity data to communicate what can be done for any given release.

Put another way, what do you really want customers and stakeholders to concentrate on? The minutiae of your process? Or innovative product ideas and how they should be prioritized in the backlog?

Scrum Master: Tools of the Trade

(or "How Rally Could Improve Their Software")

---

When a team is employing Scrum to project manage their software development efforts one facet for consideration is how to keep tabs on things: the backlog, the stories and associated acceptance criteria, the current state of affairs and so on.

The things one uses to do this are the “tools of the trade” for a Scrum Master, indeed for the whole team.

Much advice is given about keeping this simple. Much advice is given about the idea of visual management techniques including “information radiators” that constantly, clearly and loudly proclaim the state of affairs. These should be intuitive to read, easy to work with and not intrusive.

The quintessential approach to this is the use of a team area with a task board of some kind along with perhaps a burn down chart. We've done this at my company in our early days of agile adoption and it worked extremely well. The main benefits I saw were:

• You can take in the state of an iteration in a glance. For instance, got most of your Post-its on the left and it's near the end of the sprint? Looks like trouble...
• You don't really have to train anybody how to use it, it's dead simple
• People not intimately involved in the project day-to-day (read: management and executive sponsor types) can quickly "read" it and get value from it
• It's quick and easy to work with...adding a story, task, note, changing status...
• It's always present, you don't have to "go" to a website, tool or what have you

Of course, it works best when you have a fully co-located team. When there are team members that can't visit the task board in person then this approach weakens considerably. This is one reason why a team may turn to a tool to aid them in creating a virtual task board. Part of me feels that this is treating the symptoms rather than the root cause...that is, you should look again at whether you really need to have a team spread out over different offices. However, I also recognize that that optimal arrangement isn't always practical, whether for financial or political or other reasons within an organization. Sometimes your talent is spread across the world and you can't bring it together. Anyway, I digress...

The other seemingly valid reason for a tool to replace the simple white board and Post-its I consider to be related to managing a group of teams or a portfolio of products. There will be very legitimate needs to roll up the status associated with individual software development teams to obtain a higher level view of the work of an engineering department. If teams are in different offices or countries, it's clearly impossible to run from one team room to another to update oneself on how all the teams and products are doing.

So clearly there are at least a couple of reasons why you may reach a point where you need a tool to help your agile teams coordinate and track their efforts.

My company reached this point. We chose Rally.

Here's a quote I happened across on the Rally Products Overview web page (it doesn't always show up, seems they cycle through various quotes) -- “The usability of Rally is one of its main selling points.”

Now I'm sorry, I don't mean to offend either the man being quoted or the people who've worked hard at Rally building this software. But it's far from a shining example of highly usable software.

It's my assertion that information radiators like a task board that a co-located team would use are basically the Gold Standard.

So, if you’re going to try and create some software that can be used in place of this then you should try damn hard to get as close as possible to that Gold Standard. I know there are other issues like concurrency, responsiveness, reporting, user management and so forth. But at the heart of a bit of software like this, it is my belief at least, should be a tool that empowers a team, not a tool that is awkward to use and gets in the way.

So what's my beef with Rally usability? Well, having thought on it a bit I believe my criticism falls into three main areas.

1. The Software is not Task-Centric

And when I say this, I'm not talking about the tasks one can break stories down into. I'm talking about the fact that different roles on a Scrum team regularly and repeatedly engage in certain tasks but that there are no options in Rally that particularly support or enable these. Instead it feels an awful lot like a small set of database tables with some views layered on top and then exposed as HTML. Various ways to slice, dice, subset and drill down my releases, iterations, stories and so forth is fine, but I'm looking for something more.

• I want a tool that supports the Product Owner in release planning.
• I want a tool that supports the Scrum Master in sprint planning.
• I want a tool that supports the team on daily stand ups.
• I want a tool that supports the team during sprint reviews.
• I want a tool that supports the team during retrospectives.

Rally does of course contain various list views and so forth that help with this, but it seems to me that none of them are really conceived to aid any of these roles in any of these tasks. It's more a small set of Lego bricks you can arrange as you see fit to achieve your ends. And yet it would be so much more useful it the "bricks" were assembled into larger constructs that supported the various Scrum ceremonies and tasks that people on the team perform.

2. The Software Looks, um, Less Attractive than I Would Like.

I know people have worked hard on this, and I don't mean to completely disparage their efforts. I'm not even saying I could necessarily do much better (although I'd like to think I could...) but consider:

• In general, there's a "designed by an intern programmer circa 1996" feel to things
• The Dashboard looks like Jetspeed 1 That's not a good look for anybody.
• In general, screen/form layouts are pretty unattractive and hard to scan: content is not well bounded, poor typography, colors, etc. Take the basic detail view of a user story, or the pop-up edit a story view…labels not emboldened, field boundaries unclear, it just looks like my 12 year old designed it after reading "HTML in 24 hours".
• Look at the new Reports --> Epic Progress app that was just released. Was somebody really happy with how that looks? If I was Product Owner I surely would not be.
• Why does editing a story have to spawn another browser window? Why not in-place? Rally allows a certain amount of in-place editing in list views so why not the full form? Nobody wants extra browser windows hanging around…
• Speaking of in-place editing, there's a disconcerting "twitch" or "jump" when on the Plan --> User Stories view and you in-place edit something.
• The tabs don’t stand out enough so it’s hard to “read” where you are, especially since so many “views” look so similar. There's not enough contrast with almost everything being in very drab black/white/blue. Use some more of the Rally Red maybe. Also I find the tabs are not very responsive, they “lag” as you move over them.
• Why is the icon you can click and drag to reorder things different between Plan --> Backlog and Plan --> User Stories?

There's more, but that's a good representative selection of the things that strike me as looking unattractive.

3. It's Just Not Intuitive

I know agile and Scrum pretty well. The software then ought to be fairly intuitive to work my around. And yet it isn't...

• It's Confusing how the backlog tab only shows things that *haven’t* been assigned to a sprint and/or release (can’t even remember which, but stuff disappears from here)
• It's confusing how story hierarchies are shown in Plan --> User Stories but not Plan --> Backlog…in fact the whole parent/child thing is confusing. Why not have first class support for the common theme --> epic --> story structure?
• Plan --> Releases gets its own tab just for defining a simple release "record"? Navigation from here to see “stuff” slated for a particular release is non-obvious. Could be much nicer.
• “Page Tools” vs. “Actions…look different, kinda confusing…
• Column headings etc. look lost...it's just not clear that they are column headings.
• Plan --> Plan … really? What does that mean?
• Track --> too many options. None seemingly optimized for daily stand-ups which is the #1 tracking activity in Scrum.
• The "Task Board" doesn't work unless your stories have been broken down into tasks. OK, maybe that's why you call it a task board, but not everybody sees value in further decomposing stories. I don't, rendering the task board useless. Even if I did want to break stories down into tasks the view doesn't lend itself well to, say, sharing via WebEx for a stand-up with a distributed team.
• The URLs are useless: I can't copy/paste a URL and IM it to a colleague. No matter what I'm doing the URL is always https://rally1.rallydev.com/slm/rally.sp

OK roasting more or less over. Given that the product is a tool for use by agile teams and that it's developed using agile principles and practices, I'm not convinced it's an especially good "advert" for agile. I'd like to think that if Rally were being truly effective here then there would be a much nicer product as a result.

This is of course all just my own personal opinion, and I freely admit I have not worked with the product for that long. Maybe I'll grow to love it and think it the best thing since sliced bread. Presently however I do not. I think there's a lot of things that could be done to improve above and beyond adding things like the Epic Progress app (do we really need yet another view of progress?). I suspect this scathing rant bars me from applying for the Product Owner job in Boulder ;-) but if I did have that job, these are the things *I'd* be prioritizing high on my backlog. I note they are also looking to hire a Usability Analyst which has to help, although they're only looking for someone with 2+ years experience and I wonder if they don't perhaps need someone a tad more seasoned...

Cucumbers, and why it suddenly matters that I suck at regular expressions

This week I have been playing with a new testing tool. Well, sadly not all week as my wonderful HP 8710 laptop snuffed it on Monday morning and despite my best efforts could not be coaxed back to life. This blog post (and my playing with the new testing tool) comes to you from my new Lenovo T410. It’s a bit “toy sized” but it does boot in under 10 minutes (a welcome contrast to the HP) and the build quality is better (although it’s hardly got the aesthetics of a MacBook Pro.)

Anyway, the new testing tool I’ve been playing with is Cuke4Nuke which allows Cucumber to work more easily with .NET projects. That sentence probably is pretty baffling so let me back up and explain what all this Cucumber-y themed goodness is about.

You have (hopefully…) heard of Test Driven Development (aka TDD) as an approach to developing software. For those not too clear what it is, a quick explanation goes like this: Instead of writing your application code and then writing a unit test afterwards (you are writing unit tests, right?) you start out writing your unit test first. Now, this may at first blush sound somewhere between stupid and impossible. If you’ve only heard that one line explanation you’re missing a subtle but key point: when you start writing that unit test first, you need only write enough for it to fail. Then you go remedy that fail by writing production code. Obviously at the outset that point is reached pretty quickly…the moment you reference the class under test (which doesn’t exist yet!) your test will fail. You can’t even compile it:

public class TestWidget
{
    public void Widget_Assemble_Success()
    {
        Widget w = new Widget(); // can’t compile
    }
}

So then you switch to your application production code and implement the class under test. But (and this is important) only enough to make the test succeed. At the outset that doesn’t require you do any more than simply create the class:

public class Widget
{
    //implementation to be done
}

At this point your test will now compile (and pass, kinda) and you can work more on the test until, once again, it breaks or fails. In the example here that’d be trying to call the Assemble() method on the Widget class. Again we couldn’t compile as this method doesn’t exist in the production code class. We’d remedy that over there and then finally add some kind of Assert into our test, which would fail and then finally we’d get to the meat of implementing the method under test.

That little “dance” back and forth between the test and the class under test may sound a little convoluted and unnecessary, but it’s what helps tease out the initial design of your class under test. It’s what puts the “test driven” in test driven development. It really makes you think about the API, the method signatures, naming etc. of your class under test and after you have the “aha” moment that comes with this approach it’ll all fall into place. Suffice to say I’ve found it really helps not just with driving the design but also with maintaining focus too. Trying to write sizable amounts of production code before unit tests was always liable to lead to me wandering all over the place. That could just be me of course.

OK, back to Cucumber. Cucumber is not in fact a TDD tool or framework. But it’s related. It’s a BDD (behavior driven design) framework. This is a step forward in the evolution of test first development, and for me brings together a number of interesting threads:

• user stories


• specification details, acceptance criteria


• customer/product owner involvement

There’s a (sometimes unpopular) truism in software development: it doesn’t really matter what the requirements say, the software does what it does. The truth is in the source code. That is the only artifact that is up to date and can unambiguously (hard to read code aside) tell you what the software does.

Now what’s really cool here as far as I’m concerned is that Cucumber (and other BDD related tools) let you bring the specification in alongside your source code. Not just in a “store the requirements doc in version control” sense, but something much more useful. Your specifications in Cucumber are written as a series of features (think stories) along with some scenarios (think concrete examples of expected behavior) which then get hooked up with some glue code to the actual production code to test that they work. In other words, the plain English requirements are now an executable specification. With the click of a button you can test which of your features are correctly implemented.

This makes a boatload more sense than deriving tests from a requirements document. The tests *are* the requirements document.

This elegant brilliance (yes, I gush) comes at a price however.

Firstly, your feature requirements have to be written in a particular format. This doesn’t actually seem to be too onerous, and results in some pretty readable material. Here’s an example feature for a system designed to act as a database of hiking trails:

Feature: Search for trails
    As a hiker
    I want to find nearby trails
    So I can go for a hike

    Scenario: Search for trails nearby
        Given my location is "Rollinsville"
        And I'm willing to travel up to "10" miles
        When I search for nearby trails
        Then "Crater Lakes" is listed in the results

The key part here is the “given, when, then” section. This is what we will end up tying to an automated test. Above it, as you can see, is our user story in conventional format providing background and context.

You can imagine that we might have additional scenarios here related to finding trails that allow dogs, disallow mountain bikers and ATVs etc.

Despite the constraint of the specific structuring required here (and there is more richness available than this simple example) it seems to me that you could get a long way with this approach, and it’s not beyond the realms of possibility for these features to be directly authored by the Product Owner or business analyst.

The second portion of the “cost” of this approach is implementing the code to tie these scenarios to the system to test it. This is where regular expressions (regex) and my weakness with them come in to play.

If you’re not familiar with regular expressions, they basically provide a very succinct means of performing pattern matching operations on strings. See http://en.wikipedia.org/wiki/Regular_expression for more information.

To connect the scenarios up involves writing regular expressions that match the text in the “given, when, then” stanzas and pulls out the key inputs to the tests. In the example above this would be the location (Rollinsville) the distance the hiker is prepared to travel to a trailhead (10 miles) and the success criteria (Crater Lakes).

Those regular expressions, which are wrapped up in C# Cucumber attributes on methods to identify the given/when/then processing look like this:

[Given("^my location is \"(.*)\"$")]

[Given("^.*travel.*\"([0-9]*)\".*$")]

[When("^I search for.*$")]

[Then("\"(.*)\" is listed in the results")]

All of which may or may not read easily for you, depending upon your experience with regex. Mine amounts to little more than a fairly limited quantity. I’m pretty excited about the possibility of executable specifications, BDD and testing applications this way and plan on trying it out in anger over the coming months.

And this is why it suddenly matters that I suck at regular expressions.

Location, location, location!

They say there are three important characteristics of real estate: location, location and location. The same is true, I think, for the characteristics of a scrum team. Where they are located has a profound effect upon their success and productivity. Agile advocates recommend collocation of a software development team and proximity to the customer.

This isn’t some whimsical notion, or a cunning anti-outsourcing ploy. It advocates this because it works. We have been trying to build software in a somewhat predictable and satisfactory way for a handful of decades now. We’re finally learning enough to understand what works. And what works can be summed up in a few sentences (hint: read the agile manifesto). With respect to scrum teams and their location, it comes down to:

• they need to all be together
• yes that includes their scrum master
• yes that includes their product owner

The idea that agile software teams can be twice as productive as old school waterfall teams, maybe even 5 or 10 times as productive is, unsurprisingly, highly appealing to those who manage development teams for a living.

But here’s where things get weird.

Before IT executives were paying attention to agile, they were paying attention to off-shoring and outsourcing. These appeared to offer a way to substantially reduce labor costs associated with software development and other IT activities. Software engineers in Eastern Europe cost less than Western Europe or the USA. And those in India cost less than their colleagues in Eastern Europe. You can go further still, to China, where engineers cost even less. It’s probably only a matter of time before someone sets up a militarized compound campus in a failed African state and you can get engineers for who knows how little.

Irrespective of location these are all potentially good engineers, and this pursuit of cheap labor is not, in and of itself, the weird part. In a globalized world of free trade it’s inevitable.

What’s weird is when people blindly ignore one of the most important principles of agile software development (locate your team altogether in one place with your customer) and try and distribute software development teams across the globe. That’s trying to have your cake and eat it too.

There are some folks that try and suggest, perhaps with their consulting fee in mind more than anything else, that this is just a reality of today’s globalized marketplace.

I understand to some extent how they are OK with that, but to me it’s just a sitting-on-the-fence response that avoids calling out the stupidity that is taking place. The cognitive dissonance produced by the equally dogged pursuit of agile adoption *and* offshoring is at times almost painful.

Scrum teams have the potential to reach 10x productivity of conventional teams. You’re not going to do that though without dedicated people acting in a motivated fashion. You’re not going to get that with a distributed scrum team.

Let’s say your business has its center of gravity in a high labor cost country like the US. And you have a software product that you need to develop for that business. You have quite a few choices how you go about this: scrum or non-scrum, team based in the same location as your business's center of gravity, offshore, outsourced or some combination thereof..

Let’s assume we’ve decided we do want to use scrum, so we can eliminate the non-scrum approaches. Now, if we’re to be responsible about this, we should be considering a couple of things:

• how can we develop this product economically; that is getting the most product out for the money invested
• how can we develop this product effectively; that is making the best product we can, getting the customer what they want

Now those salaries in low-cost labor countries that are maybe ~1/5th the amount of their high-cost labor country counterparts do look pretty tempting: “Dude, they could be 5 times slower and it still would cost the same.” Kind of. Ignoring infrastructure, opportunity costs, dissatisfaction from lateness, reduced quality due to misunderstood communication etc.

Hmm. Maybe we can mitigate the risks of them being so far from the customer by distributing a team: "Let’s have some talented senior people in the high-cost labor country, and augment that team with lower cost labor. Yeah. That’ll be the best of both worlds." Except of course you’ve now pissed off your talented people by asking them to play babysitter. And having to accommodate early morning calls. Or late night calls. Oh, and with that immense time zone difference? There’s no chance for them to really chat and help each other out. The high bandwidth face to face communication of agile isn’t helping here at all. I suppose you could fly people around all the time. Soon going to start eating into the big pile of cash you’ve “saved” though.

Double hmm. So on the other hand, what if we focused solely on staffing a team with people where the actual business is that needs the software. Yes, a team in the high-cost labor country. But concentrate on getting their productivity up to that 5x level? Well then you might say, in many ways, they cost no more than the low-cost labor staff. But it’s better even than that. They have a full sense of ownership, they’re engaged. The customer is happy, they are able to work with the team to get just what they want. No more telephone game and lost details thanks to ambiguous email messages. Not only this, but they get it 5x faster. Oh, and we don’t need that expensive infrastructure to support developing software in two places. Holy crap. How can this *not* be the right way to develop software? Anything else is missing a chance for competitive advantage, is being financially irresponsible; is, frankly, stupid.

Adopting Agile: Where should the emphasis be?

Many benefits are touted for those who chose to adopt an agile approach to software development. Some are more typically cited by coaches and tool vendors as a kind of sales tactic:

• your teams will become more productive
• you’ll ship business value sooner
• customers will be happier
• you won’t build features that aren’t needed

Others, perhaps less vigorously or frequently stated include:

• development proceeds at a sustainable pace, not burning out your staff
• quality typically improves, particularly if one adopts a lot of the supporting technical practices advocated by XP
• for most people, it’s a more fun, interactive and collaborative way of working leading to higher job satisfaction
• the time needed for feature development becomes more predictable

There are more than these but for the purposes of this blog post these will suffice. The question I want to ask (and answer) is, when adopting agile, where should the emphasis be? What benefits should we champion and pursue?

From the perspective of managers and company executives, those items in the first list really resonate. This is understandable; they correspond with responsibilities that those people have. But how exciting are they for those people actually on the teams that have to do the real work of creating working software?

Well, I would argue probably not very exciting at all. I think it’s a misconception, but the “your teams will become more productive” and “you’ll ship sooner” benefits are often interpreted by teams first encountering agile as “you want me to work even harder!?”

This reaction can be compounded with the introduction of daily stand-up meetings. “Oh, so now you want to micromanage it and check in on my progress every day?”

Both of these interpretations are (thankfully) incorrect. This is not the motivation for agile done properly and not what should be going on. It’s easy to see though how this misconception could arise when so much emphasis and commentary exists about those two benefits and how often they get trotted out.

This is why I would argue that the sensible approach is to focus on the benefits in the second list above. Emphasizing changes that bring these benefits are much more appealing to those people actually doing the work. They’re a much more humane and rewarding set of ideas. In my opinion, and experience from the last year, agile done right will really focus on the teams. On empowering them to control much more of the work and how it gets done.

I know that I, as a team member, would feel much better knowing that sustainable, predictable development was valued. I’d feel much better that the increased transparency of Scrum would serve to highlight impediments to my work, that would get the attention they deserve and promptly remedied. I’d love knowing that the organization valued quality and craftsmanship in software development. I’d enjoy not having to estimate every last detail in fractions of hours. I’d almost weep with joy at not having to comb through hundred page specifications of poorly written and ambiguous requirements documents.

Best of all though, focusing on these things, and aiming to unlock that second list of benefits will, I firmly believe, lead to those benefits in the first list. It’s inevitable.

Wot no team room?

You don’t have to do much reading on agile before you come across advice about how to arrange the environment for a team. And it’s pretty different to what most of us have available in a corporate office environment.

Much as a dedicated “war room*” for each team with no cube walls in the way, copious amounts of whiteboard space and additional private areas to retreat to would be nice, we ain’t got it. From what I know, not much of the corporate world usually does.

So what can you do? Well we recently decided to try and make the best of our lot. Previously, our teams were scattered to the wind over an area housing a mix of people from the organization. This had actually been purposefully done -- the idea being that it would get folks from different groups talking in an impromptu and synergistic fashion. Turns out that wasn’t quite the case. I won’t say no good came from it, but as we adopted agile, the physical separation of our teams was noticeable.

What we decided to do was try out a reorganization, where each of our teams were placed in contiguous blocks. We couldn’t get rid of the cubes, but we could make better use of them. We divided up the space into three groups of cubes, assigning one group to each team. Then we let each team negotiate amongst themselves exactly who would sit where in their group.

Now any large move like this is going to receive a mixed reception from those involved. Not all cubes are created equal. Some are of the premier variety; they are by windows, larger in size or have less “traffic” passing by them. Now understandably anyone losing that is not going to feel like their situation is improving. There’s often precious little comfort or individual benefit available in the uniformity of a cube farm and I for one can more than empathize with the desire to hang on to what you’ve got.

However, there were enough people in favor and the benefits espoused in a myriad blog posts and books seemed compelling enough to give it a try.

A little while later and I polled folks for their thoughts on things. The response was overwhelmingly positive, and while there were a few people who felt it was not an improvement most people were extremely happy with it. The following are just a few representative quotes that say it better than I could ever hope to:

“At first I thought that there was no real point - we weren't so far away, we could just walk a few steps, but I found out differently. We do interact more and include each other in conversations by heads popping up over cube walls or by overhearing ... so I was skeptical but am now a believer.”

“Honest opinion: It is the best I came across in 10 years of my life with Perceptive.”

“I actually love it”

“...communication has improved significantly now that we are all sitting together. I can't think of any downsides. “

It seems to me that our teams have taken things to a new level, which is clearly reflected in their positive feedback to this change. One recurring theme from people was how this had helped establish a much stronger sense of team, and of “being in it together.” Psychologists say a large part of job satisfaction comes from getting along well with the people you work with. I’d like to think that this change has had a positive impact in this way for our teams. By bringing teams together not only have they a better environment to do their job, but there’s more camaraderie too, which I makes things just a little bit more pleasant and fun for everyone.




*War room vs. team room. War room = aggression, danger, stay out. Team room = inclusive, fun, friendly. You decide... I forget who I originally saw tweet that, and I may not have it verbatim, but I liked the gist of it. In my opinion the world of business is too full of BS terms inspired by conflict: “war room”, “aggressive” time lines etc.