2013: the state of agile


If you’re considering adopting agile, or have already done so but wonder how your adoption is going relative to other companies, you’re in luck. VersionOne has recently released the results of their yearly survey titled “The State of Agile“. For companies transitioning to agile or considering it, the report provides valuable clues on how to maximize the results of their change initiative. 3501 responses were collected for this survey.

Going over its contents, some things stand out:

  • Scrum is still the market leader and seemingly the only choice at the moment. Teams that have adopted vanilla Scrum, Scrum + Extreme Programming or Scrum + Kanban account for 73% of the total. Kanban-only implementations are at a low 5%. [1]
  • Agile passed the early adopter phase. 19% of all companies have been doing it for more than 5 years, and 53% for 2-5 years.
  • Agility is scaling past the individual team level. 57% of the respondents said they have at least 5 teams doing it and 38% have more than 10 teams.
  • Not all agile practices are equally popular. Some numbers I hope to see increasing in the future: 50% of respondents integrate development and testing, 47% do refactoring, 30% pair program and only 15 % measure cycle time. On the flip side, there’s a 10% increase in the usage of retrospectives in the last 2 years. This is good.
  • It seems we’ve found a scenario where agile seems to be difficult to implement: outsourced projects. Plans to run that type of project using an agile approach dropped from 77% to 39%.
  • There are still many misunderstanding regarding agile. The biggest concerns people report are related to a lack of up-front planning, loss of management control and lack of predictability. In my experience however, it’s often the opposite: teams and managers report they feel they have more control and optimized predictability after adopting agile. Expect a blog post on this soon.
  • I imagined everybody would report a faster time-to-market as a result of going agile. After all, that was the whole point of agility, wasn’t it? The percentage, 83%, while still good, indicates that more change is needed across the organization to reap full benefits. If I had to guess, I’d say it is at the portfolio and program management level or in the marketing or sales departments.
  • If you want to succeed, the most important recommendations are to involve senior management and to properly train everyone. At the same time, you must be ready to face the biggest barriers to change: company culture and reluctance to change.

In closing, I want to thank VersionOne for making the effort each year to make this happen. I’m sure it does wonders to their sales, but it’s also a very valuable resource for us agile coaches.

[1] It’s likely that the results of this survey are biased — after all, the majority of the replies comes from VersionOne customers. The report even indicates that 2/3 of the respondents are from the US and 3/4 are from companies with 100-1000 employees. As such, you might want to take the results with a grain of salt. I especially suspect that smaller companies and startups aren’t accounted for all that well. However, the general findings match my experience with companies adopting Agile.


Re-blog: How to be a change catalyst

Over at the Mozaic Works blog I’ve published a new post describing my view on change and some of the techniques I’m using when I try to initiate and catalyze it.

Re-blog: Do Agile Teams Have Performance Reviews?

I’ve been recently getting a lot of questions about managing performance on agile teams. Managers and HR professionals are used to the annual performance review process, where the manager analyzes a subordinate’s performance and plans their next improvement steps. This doesn’t seem to be congruent with a self-organizing team. So, how do we address this issue?

Read more: Do Agile Teams Have Performance Reviews?

Re-blog: Ask better questions in your daily meeting

I’ve published another blog post on the Mozaic Works blog. This time it’s about generating more learning during the Daily Scrum using a broader palette of questions.

Check it out: Ask better questions in your daily meeting.

YOU are the professional

You have a responsibility. And you’ve been ignoring it.

Almost every month I work with one or two new teams. So I get to see a lot of cool new products, ideas, environments and technology.

Unfortunately, I also get to see a lot of crap. Crappy code. Crappy team morale. Crappy project plans. When this happens, I put on my detective hat and try to get to the bottom of it. In most situations, after asking enough questions, I hear a common reason for the problems: “Our manager asked us to… <x>”.

It seems that managers ask us to write code without pairing or code reviews because that’s a waste of time. They ask us to start developing even if the requirements are unclear. They make us commit to deadlines we know are not feasible.

Why do they do that?

I believe most of the time the managers are trying to do a good job. It’s us, the techies, that are dropping the ball. Let me explain. As I see it, management’s job is to maximize the output of finite resources. So they try to negotiate bold goals hoping that would make everyone bring their A game and consequently the team will achieve its best result.

Unfortunately, in their continuous quest for better results, they often demand things that make sense only in the short term. In order to close a deal based on a certain scope and release date, they ask us to commit to both. To start that new project sooner, they ask us to skip TDD and architecture enhancements for the current project. And the list goes on and on…

And we agree

We have become conditioned to believe that we are not allowed to fight back, when that’s exactly what we should be doing. Our managers don’t always understand the architecture needs, what clean code does for long term code maintainability or how pair programming and TDD can increase the quality of a product.

But we do. And I don’t think we do a good job of explaining the long term consequences of the decisions we are being asked to make. We aren’t brave enough to step forward and have that difficult conversation. We retreat to our desks and lament our manager’s narrow mind to a colleague.

This has to change

As the IT industry moves more and more towards agile, everyone’s voice gets stronger. Every team members is encouraged to express their opinion about potential risks. Naturally, you should have a clear, economically motivated argument for rejecting a request. Not just managers, but every role in our industry should learn to think and reason in terms of (to name a few) customer value, efficiency, effectiveness, productivity or sustainability.

A few examples of arguments you could make:

  • Committing to an arbitrary release date could lead to penalties due to delays.
  • Eliminating automated testing and refactoring generates the need for a stabilization phase in which no value is being added.
  • Banning pair programming means that new team members will become productive in months instead of weeks.

My challenge to you is this: The next time you are being asked something that doesn’t make sense to you, remember that YOU are the professional. Think about the experience accumulated in all the years you’ve been building software. And dare to fight back for what you believe in.

Slides from ‘Catalyzing Change’

A month ago, I was asked by one of the members of the local agile meetup to share my thoughts on how one might drive a TDD adoption. Tonight, I held that presentation. But I slightly “extracted an interface” and gave a generic preso about catalyzing change.

By the way, I don’t think you can actually “drive” a change. You can however ignite a fire and catalyze the reactions.

Slides from talk at WebExpo Prague

This weekend I gave a talk at WebExpo Prague, on applying lean startup principles to product development. Here they are: