Our New Development Process

Posted by: Dave Goerlich in Agile.

In Agile Development for Tiny Teams, I presented an overview of our original development and project management process. I highlighted a number of challenges we encountered by using it. Thanks to Jon Stahl, Josh and I were exposed to the application of Kanban to the software development process. I was convinced that Kanban was the right tool for us. However, the question of exactly how to implement it as part of a new overall development process remained.

We determined that our new process needed to be:

• Simple – Being a tiny team, the impact of time used managing the process rather than used generating billable work product is magnified.
• Able to handle concurrent projects – We needed to be able to support ongoing development needs of current clients while continuing to develop new clients and projects.
• Scalable – We will add subcontractors to our team as needs arise. Our new process must work regardless of the team size. It also needed to be easy to teach to new team members.
• Flexible – In addition to client work, Josh and I are partners in Prfessor.com which includes a significant amount of development efforts. The process needed to be flexible enough to manage these obligations too.
• Waste Reducing – We needed to address the four top areas of waste that I identified in our original process (see Eliminating Waste from Your Agile Process)
  • Work In Process (more than the bare minimum necessary)
  • Rework
  • Over-engineering the code
  • Repetitive tasks

From Jon’s presentation I realized that we really had two separate workflows, one nested inside the other. We never formalized that distinction, but when we began to view things in terms of MMFs (Minimally Marketable Features) the nested process jumped right out. Understanding this nesting was critical to the success of our new process.

MMF Workflow

Our MMF workflow is a customer facing part of our process. It relies upon regular input from the client and is the primary interface for our clients into our development process. Clients are welcome to look further into our process and see the details of their project. We have found that some clients prefer to let us completely handle the details. Our new process provides the ability for them to be involved in the process without being overwhelmed by the technology and implementation details.

MMFs flow through a 4 queue process:

The MMF workflow is the part of our business process that needs to interface with our client’s business processes. We found that providing the flexibility for our process to adapt to some level to fit the client has been very valuable. For example, for one of our best clients we maintain multiple Backlog queues – one for each aspect of their application. This organization of MMFs has proven valuable to them in support of accurately setting priorities. Another client was more comfortable with a larger Pending queue as it provides an increased interval between triggered planning meetings. We try, however, to keep this queue limit as small as possible in order to avoid thrash in the queue due to changing priorities.

Story Card Workflow

Nested inside our MMF workflow is our Story Card workflow. This is where the actual coding efforts are managed. The MMF workflow addresses behavior while the Story Card workflow addresses implementation. The MMF workflow is the customer facing portion of our process. The Story Card workflow is primarily for internal consumption. The first thing that happens when an MMF is pulled into the WIP queue is for story cards to be written defining implementation details. .

With our unique but complimentary skill sets, our original workflow was implemented through Kanban queues through which story cards would flow:

Estimation

Clients have consistently presented us with two common questions – “How long until I have this?” and “How much will it cost?”. Obviously the answer to both questions involve some level of estimation. We have formalized the process of estimation towards the primary goal of answering those two client questions in a consistent manner. MMFs and Story Cards are estimated using different methods.

MMFs are given a “shirt size” of small, medium, large or extra large. There is no scientific method for determining the shirt size of a given MMF. It’s a simple process of assigning a “gut feel” based on the description of the MMF. As further understanding of the scope and meaning of an MMF is gained, it is acceptable to change the assigned estimate. Continuous improvement applies to the estimates assigned too. These shirt sized estimates are used along with team performance data collected through the process to answer the question of “How Long?”

Story Cards are assigned a point value. We use the binary sequence of 0,1, 2, 4, 8, 16 as valid point assignments. We’ve determined that if a card should be assigned more than 16 points, it should be further broken down into smaller cards. To date, we have found that 8 points tends to be the largest value commonly used. Point assignment happens as the story cards are written, prioritized and added to the Backlog. We have transitioned from billing our clients by the hour to billing them by the point. These point estimates therefore easily compute to provide the answer to “How expensive?”.

Concurrent Projects

One of the most simple parts of our new process is the management of multiple concurrent projects.  We have set agreements with our clients, committing to a specified number of average points per week of development velocity.  With the rhythm of the development process, the actual weekly velocity for a given project varies.  We track our performance on each project to ensure that on average we are meeting our commitments.  Our clients have embraced this process as it provides them with both steady progress on their projects as well as a predictable monthly invoice from us.

For example, we have calculated that Josh and I can produce an average development velocity of 35 points per week.  Currently we have committed 10 points per week to one client and 15 points a week to another client, leaving us with 10 points per week we can employ on either project as necessary or on internal projects such as Prfessor.

Kaizen

Even though this process is serving us well today, we continue to improve the process.  Planning and writing this series of posts has triggered a number of ideas for ways we could further refine our process.  I know that external review of a process can many times uncover issues that those involved in the day to day operations miss.  I’d really enjoy hearing your feedback on our process, or about a process you’ve implemented to solve similar challenges.