Skip to main content

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.       Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.       You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, but you need them to stay around all the way through.
b.      You need your testers, including someone to do testing from a user perspective, from the beginning, not joining in at the end and being confused.
c.       You need to look at what the right balance needs to be between UX, analysts, developers, and testers.  One designer can go pretty far, but a starting assumption for agile is that you should have 1 analyst and 1 tester per 4 developers.  Then you would adjust the ratio, based on the specifics of the people you have and the project.  So the question would be:  do you have the right resources lined up for long enough?

2.       Environments.  In addition to your development environment, you need to have your testing environments and perhaps also pre-production staging environments set up from the beginning and all the way through to deployment.  And these environments should all be set up so that you can pull code into them at will using a tool like Go or Jenkins.

3.       Training.  I would recommend training your chosen team on the methodology you intend to use.  There are a lot of flavors of agile out there.  When you start, you should pick one.  If you're really agile, you'll change as you go, and it won't matter too much where you started.  It would be best if team members get this training just before you do your agile requirements workshop (see item 5!).

4.       Coaching.  You probably need to have a lead coach per team/work stream to help you over the bumps of culture, process, and tool change, for long enough to get through release planning and the first couple of iterations, about 1 quarter, if you have a reasonably sized project and you're doing 2-week iterations.  The coach will likely not be needed after the first quarter, because your teams will be fine on their own to move forward.  The coach is helpful at the beginning though, because this is hard to do on your own.

5.       Workshop.  Please use some kind of structured process for building your “release backlog” of “stories.”  You should allow 3-4 weeks for the provisioning and release planning phase of an agile project for 3-6 months.

6.       “Iteration 0.”  Before you start development, you should take another 2-3 weeks to get the development and test environment and strategy in place, as well as exploring the detailed requirements for your first development iteration.  Aim, then shoot, I say.

7.       GUI Guidelines.  If you are developing software which includes a graphical user interface, then before you start, you should have a GUI playbook of some kind, and you should provision someone who can instantiate the screens you need following those guidelines.  It limits debate about what can be on a screen if you go in with rules.

8.       Auditing.  If this is working correctly, you should always know what is going on, because you are there for it in person during the release planning phase, and you can see the plan and execution to plan in the project dashboards for your work streams.  You will have working software after your first iteration, and all successive iterations.  If there is a problem, it will be escalated when it is encountered, not at the last minute.

So as you get started, you should immediately be suspicious if:

a.       There is no high-level architecture.  In agile, we encourage teams not to go into detail on the architecture before it has been written in code.  But on the other hand, the big pieces all need to be known, and there needs to be a plan for evolving the code base from a small working program to a big working program that performs correctly.  No architecture is bad news.

b.      There is no plan.  There are “scrum purists” out there who will tell you “you’ve wasted your client’s money if you spend more than an hour on a site before you start coding.”  Totally and scarily wrong, at a large company.  The work should be presented as a set of work units, called “stories,” which should average a few days each in duration.  Big, vague stories are a bad sign.  The stories, moreover, should be traceable to a business process or screen wireframe, so that any business person with knowledge of the system can recognize what that story contributes to the system’s overall value.  There should be a plan, and it should be meaningful.

c.       There is no project dashboard, or you don’t have access.  You should have 24x7 access to a meaningful dashboard.

d.      You aren’t invited to an iteration planning meeting and a showcase for every iteration.  And the showcase has to show working software.  You should see proof at every showcase that the team is where they expected to be in the plan.

e.      You don’t get any escalations coming out of the planning workshop.  You are in the Stepford Project.

f.        The team performs perfectly in Iteration 1.  It is common for new agile teams to take 1-3 iterations to get their act together.  If your teams deliver perfectly to plan from Iteration 1, most likely someone is making them work crazy hours, and they are already calling in sick or with fictional dead relatives to escape the oppression.  I have seen this.

g.       You aren’t welcome to join daily standup “Scrum” meetings as an observer.  These meetings run very quickly, and getting them right takes a lot of practice, so it’s not good to jump in and start chatting, but you should certainly be welcome to observe and address the team afterwards.

h.      You can’t get metrics about software quality (code complexity, defect rates, performance, etc.).  You should be able to see those metrics.  You should also know your defect rates and once you go into production what the rate is of CRs due to “bad fit.”

9.       Sustainable Pace. Your project is late, and you may feel the temptation to ask everyone to work day and night for a year to get it done somewhat on time.  This is risky to quality, both directly and indirectly.  Tired people make more mistakes, and staff turnover creates a situation where ignorant people are driving the bus.  It’s better to properly staff it, to get a good result.  Plus your team will be happier.

10.   Beware of Zealots.  The world is filled with “definitive” information about agile software development.  Most of the classic information was written by people in an environment significantly different from yours.  Any time you see the words “it’s just not agile if…” you should beware.  Agile offers a lot of opportunities, but to benefit, you need to start with common sense, experience of human nature, technical expertise, and a lot of pragmatism.  You should never accept advice unless the person giving it to you can tell you why it would benefit you to do so.

Not even this!


  1. Having *both* an Iteration 0 and a workshop is a smell. Following your advice, that would be 5 to 7 weeks of work that delivers absolutely no value to the stakeholders.

    If you absolutely need both, and I'd be 'suspicious' if you did, then pare them down to just what's necessary to get started. For example, can establishing the technical environment be part of the first iteration? If not, then why? If the environment is so complex that it takes longer to create, then be suspicious - the group probably isn't following "do the simplest thing that could possibly work".

    Similarly, if the UX people insist on having 100% of interaction design completed before the team starts, be suspicious. You *can* start before that point.

    You have a lot of great advice in this post, particularly with respect to staffing. However, be careful with the startup items, because they can lead groups to doing Big Design Up Front which discourages changes as the result of the inevitable discovery of information while the product is being built.

  2. Thanks very much for your perspective, Dave. I absolutely agree that you should do the minimum possible at project start. Your questions are absolutely the right ones to ask--do we have to do this? Why? Agile discipline requires that we always ask these questions with urgency.

    The point I'm really trying to make with this blog post is that agile at scale (and the scale I'm seeing could be for SMBs, not just huge enterprises), is a different beast. Once the questions have been asked, then we need to be confident and not defensive when we answer, "yes, in this environment, we absolutely need to do these things."

    The Scrum framework, in particular, sets the expectation that in ALL environments, it is possible to set up shop and get going in the matter of a couple of days or hours. My perspective, which comes from testing out agile philosophy and practice in seriously complex environments, is that we need to be more sophisticated about our views about what agile methods to use in different contexts.

    Two clarifications may help:

    1. "Just what is necessary to get started" is a relative term. If you're piloting an agile project in a corporate environment which may require 2 years for purchase and installation of new hardware, and which may spend 9-12 months on the "requirements phase" before starting actual coding activities (which might take only 3 months), allocating 5-7 weeks for project startup is unbelievably speedy, and, I can guarantee you, does not allow full setup of anything.

    2. In a complex corporate environment, agile may offer its BIGGEST return on investment in those first 5-7 weeks, because the workshop and Iteration 0 activities force the team to actually understand the project owner's intention thoroughly, and face risks in a timely way. Value to stakeholders isn't solely measured by working software.

    If your funding authority has allocated $300K for a project which will actually take $2M investment to complete, your team delivers measurable value, from a budget perspective, by giving executives the opportunity to pull the plug right away once they know the projects costs may now clearly outweigh projected benefits. Otherwise you seriously risk that the project teams will burn somewhere between the budgeted $300K and the actually needed $2M before someone discovers that there is a problem, and then the whole thing may be scrapped. Those 5-7 weeks of work, allowing for a "fail fast," have now provided significantly valuable avoidance of waste.

    By the way, not really the main point, but I absolutely agree that the interaction design need not be 100% complete--just the design GUIDE, so that when you talk with your stakeholders, you don't have to keep revisiting the basics, like fonts, menu frameworks, and policies around how much can be on one screen, and how much scrolling is allowed, don't get revisited endlessly. How much is needed in the guide will vary by project, as well--maybe the menu frameworks are not needed, etc.

  3. Great post, Elena. Auditing points are very interesting. Do you think this check list will properly scale down to projects which are less than 6 months duration? (that's what we do mostly)

  4. Hey Shan,

    I would expect these to work very well for a project of 6 months duration. In fact, I wouldn't want a team to do full story breakdown for more than 6 months at a time anyway. Cheers,


  5. Dave and Elena,

    Just want to add that I had experience in a recent project, where the points about the workshop and GUI guidelines were not done.

    Now I do not suggest that these are mandatory, but in this case it appeared we had two problems during Sprint 0.

    1. It turned out that the initial designs were not approved on the highest level in the organisation, which then took several weeks to work out the politics.

    2. There were no user stories or even epics defined at Sprint 0. The 'marketing speak' still needed to be translated into something a little more concrete.

    Basically, the whole team was stuck for several weeks. My experience is that such a slow start makes for a few tough retrospective meetings, the whole team starts to feel insecure about the project.

    Had these points been considered, this could have been prevented.

    Personally, I like checklists to keep me organized. But there are a few rules to them:
    1. Create your own, tuned to your own organization.
    2. Items on a checklist are not mandatory, if you can explain why they are not necessary.
    3. Never assume your checklist is complete.

  6. Hugo! Totally agreed! My list is made from things that went wrong that I'm trying not to relive. As I tried to say, maybe I can help someone ALSO not relive those areas of pain. If so, good. If not, good as well. Glad to get your additional validation about bad things that can happen if you aren't prepared with some of these things--I think one difference about working in a large enterprise is that you can't "just work it out" for most things. It could take weeks. That's why you want to consider having a checklist! Would love to see whatever lists you have as well! Cheers,


  7. Thanks Elena,

    That is the most sensible and pragmatic view on scaled-up Scrum agile that I've read in a while. I particularly like point b. It's an investment decision for a large organisation and needs up-front thinking. Not too much, just enough. That's where the art rather than the science comes in.


  8. Great post! The details of the checklist may change from environment to environment, but it illustrates the point you can't just one day turn on an Agile switch and be Agile.


  9. We've been actually using the Agile methodology in our company for years now. This post has been very relatable. —

  10. Agree with Dave Rooney about workshop AND Iteration 0 but the workshop should be IN Iteration 0..


Post a Comment

Popular posts from this blog

Pragmatic Business Analysis: Let's Start Calling Ourselves Product Managers. Seriously.

If you are a current or recovering Business Analyst, you may remember Scott Ambler's assertion in his essay " Rethinking the Role of Business Analyst :" A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.   Remember, BA is also the abbreviation for band-aid. Image courtesy of I have friends who switched to Curad for their fabric bandage needs, they were so annoyed by Ambler's witticism, even though Curad never had the mysterious tiny round bandages that don't do anything, but you feel incomplete without them. In the past, business analysts were always first to go, when a company decided to institute an "agile" policy where everyone on all teams would get called a "developer," supposedly because everyone on the team could do everything needed, but generally because everyone on the team was, in fact, a developer. Often times, the next step

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it. Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it? I've recently posited that we shouldn't even think of doing agile projects without capturing and recordi