Software Craftsmanship: Project Workflow

In working through the topic of Software Craftsmanship for the past few weeks on this blog we've talked about how to approach software development from a code perspective.  I'd like to take a short break this week and talk about optimizing your project workflow in step with optimizing your code.

Over the past decade the Agile development movement has really taken over in the technology industry. You'll find many different forms of agile development used throughout the software industry. You'll even find many different flavors of the same form of agile used differently from organization to organization.

While there's no single one-size fits all solution when it comes to managing your project, it is important to have a base template to use as a frame of reference. My go to template is made of up a hodgepodge of different agile methodologies. The template is made up of three parts, and like any agile process, involves constant iteration through the parts.  This template is driven around three main concepts. First, the beginning of any project involves more unknowns and more risk than the end. Second, the process should involve creating features that are useful and complete. Third, communication, preferably face to face, is needed throughout the process.

Ideally this template is used in conjunction with some sort of Kanban process. A lot of people make the mistake of centering their process around Kanban. That in my opinion is a recipe for failure as Kanban helps you understand how to move work through a system but doesn't do a good job of helping you identify the correct work to move through the system.

Part 1: Identify The Problem Space

In this part you want to have an Initial Design Meeting. This meeting would consist of the project team, the key stake holders of the project, and any other outside tech advisers (like an architect or team lead) which may be able to provide insight into how this problem space fits in with other problem spaces throughout the organization.

In this meeting you want to Identify The Unknowns. The first unknown is what we're building. A quick discussion about what the problem is or what features the system is missing. Once we know what the problems are that we're trying to solve we can start creating straw-men for possible solutions. A good way to flesh this out is to create a few user scenarios that represent the desired workflow for solutions to our problem space. Questions to ask when evaluating the straw-men are:

1. What are the big open questions?
2. What risk do the unknowns represent?
3. What's in scope?
4. What's out of scope?

Part 2: Identify The Features

This next phase is all about defining the Minimal Viable Products. This is key as we want/need to know how we can provide some sort of business value as early in the project as possible. There are a couple of characteristics that I use when trying to determine if something is an MVP that I think are useful:

1. Can the MVP stand on it's own. I.e. if the project were to end or the company were to switch gears for a time, would the MVP still provide value to the business or would it need subsequent development in order to be of use?
2. Is success clearly defined for the MVP? Do we have a clear idea of what the definition of done means for the MVP?
3. Is the MVP achievable in a reasonable time frame?
4. Have we identified the external dependencies of the MVP?

When we're done identifying the MVP's we can organize them by things we can work on now and things that need more information to get started. Each MVP or a set of MVP's can constitute a project milestone.

Part 3: Create stories

During this step in the project workflow the team will get together and identify the stories associated with each milestone (or at a minimum the first milestone).  Take a gander at this article if you're unfamiliar with user stories. Breaking work out into individual stories helps us to keep focus on delivering on our milestone.

Once we've identified our stories we need to identify their dependencies and possibly associate some of the stories with other milestones if they have dependencies that can't be resolved early on in the process.

Lastly, in this part we create "bite sized" tasks for each story. This can be done all at once or, more preferably, at the beginning of each milestone.

Starting the work

Once we've gone through these three parts our teams can start their work. In order to be truly effective and stay agile, the team should work on one milestone at a time and not move on to next milestone till all stories for the current milestone are complete. During the teams daily stand-ups you'll want to report the status of each task/story and identify any of the blocking items that need to be resolved.