The Kanbanand Guide
In my last post, I talked about some of the problems of Agile processes and suggested the introduction of a new process which takes some of the best parts of each of the popular processes and condenses them into the Kanban lean-style-thinking of limiting the work in progress.
For this post I want to clearly define what I am calling “Kanbanand” with two primary goals in mind.
- Allow someone who is interested in doing a Kanban like process to find enough information to be successful.
- Create a common thread for people who are already basically doing what I am suggesting.
Three Pronged Fork
I want to present Kanbanand as a three pronged fork. In my mind there are 3 distinct areas of a successful Agile process which must be addressed.
- Business and overall encompassing project process.
- Development practices, including standards and best practices.
- Infrastructure: build systems, deployment, source control.
We must know how to run our day to day process, how we physically construct our product, and how we actually build and deliver the product.
- Project is broken into stories which are small vertical slices through the system which are prioritized.
- A Kanban board is used to make the progress of a team visible and has limits to control the Work In Progress (WIP).
- At least once a day team members meet around the Kanban board in a stand up meeting to talk about the progress of the board.
- The team meets on a regular basis to have a retrospective to discuss how to better improve their process.
- Teams always pull in work, work is never “pushed” in.
- Once work has been approved as “done” it can never be “not done”.
- Find something to measure and measure it.
- The team is responsible for, and empowered to determine how the team accomplishes its goals.
- Roughly same sized stories over irregularly sized stories.
- Stories specifying what, over stories specifying how.
- Stories that are one sentence over stories that are one page.
- Talking about how to move the board forward over talking about what I or someone else did.
- Cross functional teams over specialized teams.
- All code is unit tested.
- Static code analysis tools are used to set code standards, all code must meet those standards.
- Any code that is done, is completely done. It is refactored, it is unit tested, it meets the quality standards.
- Code is never commented out. Anyone is allowed to delete any commented out code at any time.
- Determining code is meeting the quality standards must be done in an automated way.
- No one owns code, anyone can work on any code.
- Documentation is ONLY created when it will serve a known purpose and has an immediate value. (Code should document itself with good names and simple flow, unit tests document the low level requirements of the system. Automated tests document the behavior of the system.)
- Testing requirements come from the customer, not from the developer.
- Test driven development over writing unit tests after the code is done.
- Pair programming over working alone.
- Readable code over smaller sized code.
- Doing things right over doing things fast.
- Showing the customer over asking the customer.
- Impromptu discussions at white-boards over scheduled meetings.
- Building tools that will help make completing ten things faster, than completing one thing faster.
- Writing automated tests over manual testing
- Code is continuously built and integrated as soon as it is checked in.
- Builds build code, run unit tests, run quality checks, produce deployable bits.
- Builds fail if any unit test fails, or any quality check fails.
- Code is only deployed from the exact bits that were produced by the build machine.
- Code can be deployed to any environment with the push of a button.
- Production data never goes to any other environment.
- Developers can always run a local build which is the same as what will be built on the build server.
- Moving forward to fix problems over rolling back.
- Integrating soon over merging later.
- Quick builds over slow builds.
- Deploying on demand over deploying on a schedule.
That is my first crack at it. I have tried to keep the process as simple as possible, but still include as rules the things that I think are most important to be successful. I tried to keep the things that involved judgment calls as values. I believe this provides enough information to allow an organization to create a custom process that will work for them, but will still have enough controls to be consistent in the things that I feel make Agile practices valuable.
Let me know what you think or if you have any suggestions. I will update this post as this list evolves. I am sure there is something I missed or could state in a better way.
Like I said before, if you are doing some form of Kanban, you probably are already doing Kanbanand. If you are doing Scrum, your major change would be to drop the planning and instead try to get same sized stories while limiting your WIP.