At ThoughtWorks we are often engaged by clients to help them get more Agile. We call these gigs “enablement” or “organisational transformation” and that’s often done as part of being staffed on a development project.
One of the challenges we face working with companies who are starting to embrace Agile development is that everyone has got their own idea of what that means. Agile has lots of general principles and standard practices. Things can get crunchy however when we start to make practices practical in a particular environment and practice some of the principles that we preach. When all the fine talk becomes action it can suddenly make clear any challenges with the existing culture and practices. Making these clear and resolving them is one thing but often these lines of friction and confusion remain unstated and people start down paths of sub-optimal practice.
It struck me the other day that while Agile has a famous Manifesto, Agile projects could do with a constitutional document of their own. Something that states what they believe in and how the world is going to be. There’s a time and a place for the endless flexibility of an unwritten constitution but revolutionary change calls for statement of intent. This is especially true in the case of teams that are starting off with Agile for the first time.
I’d like to suggest that the final part of kicking off any agile project is drafting an Agile Declaration of Independence. The key stakeholders gather in a glorious congress (or meeting room with donuts); representatives from IT, the business and the Agile coach come together and specify what Agile is going to look like in that environment. It’s a chance to hammer out some of the uncertainties that there may be and provide a project charter that will help as the team grows. Of course I favour customer collaboration over contract negotiation but this isn’t a contract – it’s the context of our collaboration.
A project declaration of independence might be something along these lines:
We the people of [project name] hold these truths to be self-evident:
That all story points are created equal and can be switched in and out of a release to accommodate change.
That a story is functionally complete when all acceptance criteria are met and that any new acceptance criteria require a new story.
We will plan to iterate over each story 3 times to perfect the usability of each feature.
We shall write tests before code and strive to maintain an 80% unit test coverage.
Developers will pair on stories and strive to rotate around all the functional areas in our system
[and so on...]
This isn’t meant to be a template, each team should work out their own guiding principles and what they will look like in practice but they should cover the main thorny issues on a project:
- How do we manage scope and accept change?
- What is “Done”?
- How are we going to work?
I also think it’s important that there is some ceremony here. Agree it and sign it at the end of the project inception. Stick it up somewhere in your project room. And make sure somebody uses really big letters because I hear the head of the PMO has bad eyesight…
