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.

From http://www.yogawithjohn.com/tag/yoga-class/

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!