Introduction

This book is a record of creating an agile process for my current team.

At first the team thought about Scrum, then Kanban, then Scrum, then Kanban again. They both seemed like a prescription for a specific problem. We don't think that we can shove our round problem into a square process hole.

We looked at Scrum and it was good to help limit the time to complete a prioritized batch of work. This seems to be able to help with improving estimates overtime and giving customers a hard delivery date.

Kanban seemed better at limiting the amount of single units of work in progress. This seems to be able to help optimize our ability to get work through our pipeline (optimize throughput) and be more flexible in what we prioritize and deliver to customers.

Both of them seem to be able to help on some level, but neither of them alone appear to be able to solve our problems and they both included aspects that we didn't need (e.g. stand up meetings are not absolutely necessary in a team that has good communication).

Our simple goal is to solve problems within fixed allocated cost budget. We have to do this within the context of very large projects to very small projects. We have new work, maintenance work, and support work. We have cross functional, cross project teams. Our projects are all fixed bid, but most have flexible schedules or flexible scope.

When we try to fit our problem into the context of some existing process it quickly falls apart. I believe we need to allow our process to evolve naturally. We should organically grow our process using agile principles. One principle of the Agile Manifesto is "people over process" and allowing our very smart people to grow into the right process as we mature together as a team.

We want to discover and define the problem, specify problem solutions, evaluate the solutions, and select the best one to implement, implement the solution, then rinse and repeat. This is the scientific method and our process should provide a framework for continuous improvement based on a scientific approach.

We use stories as the mechanism to express our implementation or specification for solutions to problems. Stories also represent the work to be completed on projects. A story can cover one or more features of an application. A feature defines a specific user problem and the various scenarios that must be implemented to solve the problem. A scenario is broken down into the steps to solve a specific aspect of the problem. The teams pull scenarios to implement and focus on its completion before starting a new scenario. Completion means the scenario is ready for UAT. UAT is deployed when a feature and an agreed collection of its scenarios are ready for UAT. A feature is considered done once it passes UAT. A story is considered complete when all of its feature scenarios are considered done. This is the current thinking and may change as we improve our process.

From a development standpoint our goal is to define and deliver solutions. Our hope is that we can deliver enough value in our development of solutions that we offset the development effort enough that we profit. So, developing a story and tracking its process through our system establishes a means of measuring and optimizing our ability to improve our profitability without sacrificing quality, but we have to find was to optimize time.

To accomplish this, as with our code, we have to have a certain amount of structure to help increase consistency, improve quality, improve process analytics and our ability to continuously optimize and improve. Hence, the exploration presented in this book.