Whenever I hear other software leads complain about their “waterfall-ish” development process, I always ask why they haven’t tried something more agile. The most common answer I’ve heard back is that they don’t know where to begin. The fact that entire books have been written on the subject of Agile software development doesn’t make it any easier. Explaining to your project management team that you want drop everything you know and try something completely different - that seemingly requires entire books to describe, can be a pretty big sell. That type of change tends to make project management cringe.
The truth is Agile software development is phenomenally simple and highly customizable. You can start applying Agile principles anywhere in your development process and make modifications as you go until it’s perfect for your team. I believe this because I’ve seen it work. I work in the defense industry where you aren’t supposed to write a line of code until you’ve created enough paper documentation to eliminate the woodland homes of a dozen animal species through deforestation! But, even in this seemingly “non-agile” culture we have successfully applied Agile principles and practices. Over the course of several releases my teams now follow a very effective Agile process that is tailored to fit our “defense industry” environment. This article describes our Agile software development process and how we migrated to it from a traditional waterfall development process.
The Process
Change 1: Adopt Iterative Development
The most fundamental aspects of Agile development are continuous integration and testing. Agile processes strive to deliver code early and often, allowing end users and stakeholders to play with functional (although incomplete) working software and make recommendations and course corrections. Early delivery of working software is like buying an insurance policy against a failed project. If you want to deliver software that the customer loves and will actually use, build it in pieces and show it to them early and often. Otherwise you might end up delivering what they think they thought they wanted when they were asked about it sometime last year.
Adopting an iterative development style was a very big change for us, especially starting from a process that requires everything to be spelled out first. Our traditional “waterfall” process required systems engineers to write requirements, which were then refined into software requirements, and then finally handed off to the development team (to be placed on a shelf and ignored). Only after the software requirements were finalized and approved could the team finally start coding. The transition to continuous integration was made possible by getting the teams to believe that “good enough” is better than “perfect”. What I mean by that is the systems teams had permission to give the software teams very rough systems artifacts early in the process.The software teams were then allowed to take those rough artifacts and begin prototyping implementations. These early implementations, in turn, found flaws, which led to new and better systems artifacts. Teams don’t need “perfect” artifacts to start from. They just need a rough starting point and time to make lots of small course corrections.
Our first step toward agility began by converting a 1-year long waterfall project into several 8-week iterations. These “mini-waterfalls” helped resolve several issues, and shined a bright spotlight on major process issues that are often forgotten – namely the cost of integration. When teams integrate their code only once per release it is a nightmare that always requires a great deal more time than planned. But because it happens infrequently and is such a horrible experience, we tend to block it from our memory and forget about it when it is time to plan the next release. When we switched to a process that required us to experience that pain every other month it became much more obvious that we had a problem. With each passing iteration we learned and improved and became much more efficient at integrating our software. By the end of the year at our 6th integration, we were a twice as efficient in terms of resolving integration issues and team disconnects than we were in our first iteration.
Over the next couple of releases we begin shortening the iterations until we found what worked best for us. My teams now operate in 2-week iterations. Every two weeks we deliver working, tested software and then re-plan for the next two weeks. During the early iterations, the software and systems teams work together creating requirements, prototypes and designs – with each team’s output acting as input to the other. As we iterate, each team is refining their artifacts and getting feedback from end users and stakeholders. In later iterations prototypes become production code with bugs found and resolved every two weeks inline with development. Overall the benefits of iterative development have been fantastic:
- Systems engineers end up defining the *right* system (this is important in defense).
- Software development can start earlier, and actually contributes to the system artifacts.
- Testers see features evolve over time, which gives them expertise and confidence to “play” with the system and find bugs they wouldn’t find otherwise by simply testing requirements.
- Integration is always a pain, but integrating 2 weeks worth of code is much more manageable. Plus integrating often allows you to learn what is painful, and fix it so the pain doesn’t occur in the next iteration.
- Finding and fixing bugs that were introduced within the last 2 weeks is much easier than trying to fix bugs that exist in code you haven’t touched for months.
- Integrating often builds a tight relationship with your test team. Developers and testers end up working together, rather than acting like adversaries.
- We can adapt and make course correction early when things appear to be headed in the wrong direction.
Change 2: Keep Tasks Small
The main selling point to iterative development is that it allows for more frequent course corrections, and the ability to catch problems before they get too big. These concepts can be applied at the individual level as well. For example, if iterations are 8 weeks long, and a developer is working on an 8-week task, that developer could be headed in the wrong direction for a full 8 weeks. 8 weeks in the wrong direction is not something that is easily overcome without lots of overtime and help from many other people.
Having experienced this type of problem many times, we adopted a “No task can be larger than 40 hours” rule. That means developers must plan their work to a granularity smaller than 40 hours. It was a very simple process change to implement and the benefits have been great. Having tasks no larger than 40 hours means:
- The team won’t produce as much code for each task making it possible to provide a much higher quality code review - one that can even find deadlocks and race conditions. Reviewing 8 weeks worth of code at a time, on the other hand, will typically only find spelling mistakes in the comments.
- Management, peers, code reviewers, and testers alike have a much greater chance of comprehending the work produced in 40 hours or less. For example the 32 hour long task “Make the map display comparable rental properties visually on the map” is much easier to discuss, review, and test than the 400 hour, more comprehensive “Map Feature”.
- The team can recover more easily from mistakes. 40 hours worth of development in the wrong direction can usually be overcome very easily.
Change 3: Use The Buddy System
Pair programming is a novel concept defined in “Extreme Programming” that pairs two programmers together for everything. The thought is two developers on one keyboard is much more likely to develop things correctly the first time, saving time on the backend of the development life cycle. While I’ve never actually seen it used outside of academia, and I’ve never known a developer who’d willingly volunteer to be joined at the hip with a co-worker 8 hours a day, 5 days a week, the concept is still very interesting.
Instead of pair programming, my teams use the “buddy system” (that’s right… just like on kindergarten field trips). The buddy system isn’t quite pair programming. We've taken the core concepts and softened them a bit to better fit our team culture, while managing to keep many of the benefits. Each developer has a “buddy” they work with on a daily basis. Before a developer starts on a task (remember, in our process no planned task is allowed to be larger than 40 hours worth of work) they must meet with their buddy and explain the problem and their approach to the task. It takes 5 minutes, and I’ve seen it save many hours.
The buddy system also applies at the architecture and design levels as well. During the design phase, feature designers will meet with their “buddy” at least every other day to outline their design changes. With this process change we’ve been able to design things right the first time, and significantly reduce the likelihood of major design issues being found later in the development cycle.
The benefits of the Buddy System include:
- Your “buddy” will be in a much better position to do a quality code review because they will understand the “what” and the “why” of the work you have produced.
- Talking through a solution before attempting it often uncovers many pitfalls and can prevent wrong turns. I can’t count the number of times a pre-task 5-minute discussion has resulted in statements like: “Whoa, that’s the wrong approach.”
- You are training your replacement should you win the lottery and retire.
Where We Are Headed
A software process will continue to evolve as your team learns more about what works best. Our team has made a lot of progress migrating from a stove piped waterfall process to using a tightly integrated agile and adaptive one. Here are some of the things we continue to work on:
- We are starting to migrate away from traditional requirements being “early” artifacts. In stead, high-level concepts, use cases, user stories, and system threads are taking center stage. Requirements will remain a necessary evil as a government contractor, but they are a terrible starting place.
- We are working to further refine our backlog and iteration planning process to improve the accuracy of our estimates. Estimating software development is a difficult skill to master, but is extremely important in an industry where budgets and deadlines are carved in stone.
- Frequent iterations have caused the development and testing groups to behave like a single cohesive unit, but we still have a ways to go to bring systems engineering into the fold.
Summary
This article describes the simple Agile process my development teams follow while working in the defense industry. It also provides a little insight on how we migrated from a painful waterfall process to a much more agile one. Running an Agile team doesn’t require memorizing countless books, or a special robe with a “SCRUM Master” label on the back. Reading books, and taking training will give you new ideas, but the most important characteristic of becoming “agile” is the willingness to try small changes and make adjustments. Agile simply means having the ability to make changes when something isn’t working well.
About the Author
Jeff Plummer is an Integrated Product Team Lead with General Dynamics C4 Systems responsible for leading teams of Systems, Software, and Test engineers for command and control software systems. Jeff can be reached for questions or comments at plummeronsoftware@gmail.com.