5 ways to speed up your Agile adoption

Too many people these days seem to think that adopting an Agile method is quick and easy. Not so! It’s definitely worth it, but the road can be long and hard.

In corresponding with a newbie, I gave a list of five ways they could speed up their adoption. Here they are, with a bit of explanation:

  1. Have a clear project charter. If you don’t know what your project is supposed to achieve, it will take you a lot longer to get there, and a lot of decisions will be muddled. Write up a clear statement of purpose, post it prominently, and keep it up to date when goals change.
  2. Shorten your iterations. An iteration is a regular, fixed-length period where you decide what you’re going to do, go do it, and then measure how much you got done. (By done, I mean 100% done and releasable, what some call “done done”. 98% done equals not done.) Keep iterations as short as possible. I recommend a week. Two weeks can be ok; three or four is risky. Three months is downright nuts.
  3. Release more often. As often as you can, get software out to real users. If you think you’re already doing it as often as possible, you’re probably wrong. Many teams release weekly, some daily, and a few ship several times a day.
  4. Get more data. You wouldn’t drive a car with the windshield painted over, steering by where you think you are, but that’s how a lot of people drive projects. Increase the volume and clarity of real-world data on product impact. Use that to evaluate what you’ve released, and to shape upcoming work. This can include guerrilla user testing, user surveys, usage analytics, customer surveys, user context research, sales data, and just having people over for a beer.
  5. Use an experienced Agile coach. I may be a little biased, but I think a good Agile coach can save a lot of time and trouble. There are a lot of good ways to be Agile, but there are even more bad ways, and it’s hard to tell them apart until you’ve been around the block.

The careful eye will notice a common theme here: improving feedback loops. The more feedback we get, and the faster it comes after our actions, the quicker we learn. That’s the engine that makes Agile approaches superior to plan-driven ones, and we can use that engine to speed up Agile adoption as well.


  1. Fictive Cameron:

    Great Post William. I think you pretty much nail it. The only thing I might add is that I think “vision” sounds a little better than “charter”. Vision feels more more like a group of people getting together to create something great. Possibly more motivational.

  2. William Pietri:

    Good point, Cameron. “Project charter” is a technical term, and some people, including a fellow named III, have done some good work in this area. I’ll find a link so that you and others can follow up.

  3. Michael Valenty:

    With one week iterations, how much time do you devote to your iteration planning meeting, iteration review and retrospective? We’re doing two week iterations to help amortize the meeting overhead, but our priorities are so volatile that we rarely make it two weeks without a surprises.

  4. William Pietri:

    Great question, Michael.

    Depends on the team size, but I’d expect to spend 90-120m for that. Add in a regular 1-hour meeting for estimation to prep for the iteration planning meeting, and <10 minutes a day for standups, and that’s less than 10% of one’s working time allocated for regular meetings. That’s about the norm for the teams I coach.

    I don’t think making the meetings happen less often should save much time. The more often a meeting happens, the less people worry about getting their thing in right now; there’s always next time. The less fresh things are in your minds, the more time it will take to cover them. Plus, you can keep shorter meetings crisper.

    If you feel like there is a lot of wasted time that would be doubled by having shorter meetings twice as often, then perhaps you should ask yourself why. Do people not come on time? Are the meetings not time-boxed? Do you lack effective ways of cutting short tangents, distractions, bloviations, and discussions with no outcome? Is the team not fully focused on delivering value early and often? Those are all things I regularly ask with bad meetings.

  5. Michael Valenty:

    Thank you for your thoughtful response. While I’ve got your ear, I’ll push my luck and ask another question.

    We have 4 developers, 2 designers and customer service doing double-duty as QA. We are maintaining our 10 year old version 3 monster CRM SaaS web based application, doing professional services integration contracts, biz dev, new features, and supporting a network of partners using our api. Basically, we are biting off quite a bit for a small team.

    The issue is that everyone wears a few hats so accountability is sometimes to “the team” and sometimes elsewhere. Our sprint goals are often secondary and therefore we miss out on important team dynamics.

    Some mornings at our stand up it feels like six islands and people just reporting tasks and why they didn’t work on the sprint cards. The team then gives up on the sprint goal because they are not in control.

    There have been a few sprints with good energy and good team dynamics, but it is fragile and I suppose my question is how to hold the line when the business goes through periods of chaos (priorities coming from many directions with little warning or time to respond). It’s not always like that, but we’re neck deep in it now and Agile is taking a lot of heat in the form of misplaced frustration.

  6. William Pietri:

    That’s kinda hard to say without seeing the situation and talking to people. However, I’d suggest that you consider these options:

    A) Do shorter iterations, so there’s less chance of disruption, and it’s easier for people to learn that they can wait a few days.

    B) Turn as much work as possible into cards and be strict about using Yesterday’s Weather to decide how much you can do. Something new comes up? Then something else gets put off.

    C) If you can’t keep all the urgent stuff away until the next iteration, assign one person to handle fires for the week.

    D) Do a lot of pairing. If it feels like islands, there’s probably not enough cross training or collaboration.

    E) Explain to the bosses that they need to decide between the appearance of doing a lot and actually getting a lot done. If people always feel behind, that’s not a sign of bad execution, it’s a sign of over-ambitious planning.

    Basically, you’re right to focus on the team feeling out of control. The team must firmly believe that the best way to serve the business is to be disciplined about how much work they take on, and how well they do it.

    Good luck, and feel free to drop me a line with updates.

Clicky Web Analytics