Wednesday, May 18, 2011

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.


  1. Great post.

    I would like to add that as part of point 6 is that we must not, as an industry, forget to apply some of the better engineering practices that help here; logging, diagnostics and performance monitoring.

    As with all things Agile, care must be made to only implement these as much as is beneficial e.g. do you really want performance measurement on that LOB client application? Maybe. Maybe not.

    I think 6 is a great example of where Software Engineering techniques are not the anathema of Agile.

  2. I was nodding all the way through this one. Great crystallized list of things to look out for when a team is trying to get more agile.