Agile in the defense industry

Whenever I hear other software executives complaining about their "cascade" development process, I always ask them why they don't try more agile methods. And the most common answer is that they don't know how to start. In fact, if a book is all about agile development, it won't make agile easier. Explain to the project management team that you want to give up everything you know, and then try something completely different that really requires a whole description, which will take some effort to sell. Such changes tend to scare the management team.

But in fact, agile development is very simple and highly customizable. You can start to implement the agile principle anywhere in the development process and make changes until it is perfect for your team. The reason I believe this is because I have witnessed it. I work in the defense industry is a you write any line of code, you need to wait until enough paper documents are created, and these paper can consume a lot of animals in the forest home. However, in this seemingly "not agile" culture, we have also successfully applied agile principles and practices. With several versions of learning, my team now follows a customized agile process that is very effective and fits our "defense industry" environment. This article describes our Agile software development process and how we migrated from the traditional waterfall development process to the agile development story.

Process

Change 1: Using iterative development

The fundamental part of agile development is continuous integration and testing. Agile processes are dedicated to fast and frequent release of code to allow end users and stakeholders to use functional (albeit imperfect) software at the same time, making recommendations for timely tuning. Releasing the software that works early is like buying insurance against the possibility of failure. If you want to deliver the software that your customers like and eventually use, block it out and show it to your customers early and frequently. Otherwise, the last thing you can deliver to your customers is the software they thought they wanted at some point last year.

Adopting an iterative development style is a huge change for us, especially for a process that needs to be written out first. Our traditional waterfall process requires system engineers to give the requirements and then refine them into software requirements, which are eventually handed over to the development team (placed on a shelf and ignored). The development team can begin coding only after the software requirements are finalized and approved. Making the transition to continuous integration possible is to make the team realize that "good enough" is actually better than "perfect". I mean, the system team gets permission to give the software development team an original system component at the start of the process. The software team can then allow these raw parts to begin implementing prototypes. These early implementations, in turn, can uncover defects that lead to new and better system components. The team does not need to have "perfect" parts from the beginning. They just need a simple starting point and time to make more small changes.

The first step in our agile starts with converting a 1-year-old waterfall project into a few 8-week iterations. These "mini waterfalls" help us solve a few problems and drag the main process problems that are often forgotten into the spotlight-the cost of consolidation. Only one code integration per release is a nightmare, and we always spend more time dealing with it than we planned. But because the problem is not frequent and so scary, we all pretend it doesn't exist until the next version of the plan. When it comes to a process that allows us to experience this pain every one months, it is clear that we have a problem. We learn through each iteration, progress, and become more efficient when we integrate. At the end of the sixth iteration, we were twice times more efficient at solving integration problems and team connectivity problems than the first.

In the next few releases we began to shorten the iteration cycle until we found the one that was best for us. Now my team uses two weeks as an iterative cycle. Every two weeks we deliver the working, tested software and redesign the next two weeks. In early iterations, software and systems teams worked together to create requirements, prototypes, and Designs-a team's output was just as input to other teams. As the iterations go deeper, each team redefined their parts and collects feedback from end-users and stakeholders. In later iterations, the prototype becomes a defect modification to the product code and the development work to be processed and integrated within the corresponding two weeks. Overall, the advantages of iterative development are startling:

System engineers ultimately define what is the right system (very important in the defense industry)

Software development can begin much earlier and can truly contribute to system components.

Testers are able to see evolving features that allow them to gain more knowledge and confidence to play around with the system and identify problems rather than simply test requirements.

Integration is always painful, but code that integrates only two weeks of work is easy to manage. Another frequent integration allows you to learn the cause of the pain and then fix it in the next iteration.

Finding and fixing bugs in your code over the last 2 weeks is much easier than trying to solve code that hasn't been touched in months.

Integration allows you to build a closer relationship with the Test team. Developers work with testers, not as rivals.

When things start to go in the wrong direction, we can adjust and correct them as soon as possible.

Change 2: Keep the task miniaturized

The main point of sale for iterative development is that it allows for more frequent fixes and can find problems before the bugs get out of hand. These concepts can also be applied at a personal level. For example, if an iteration lasts for 8 weeks and a developer works for the 8-week task, and he may be heading in the wrong direction for the whole 8 weeks, it's hard to avoid a lot of overtime and help from other employees if you want to correct the problems caused by these 8 weeks.

After many of these problems, we have adopted a rule that "no task shall exceed 40 hours". This means that developers must reduce their work granularity to within 40 hours. It's just a simple process change, but the benefits are huge. Any task not exceeding 40 hours means:

The team does not generate a lot of code for each task, which makes it possible to have higher quality code checks-even to find deadlocks and race conditions. Check the 8-week code at one time, in other words, only to find spelling errors in the annotation.

Managers, peers, code inspectors, and testers have a better chance of understanding the work done within 40 hours or less. For example, a 32-hour mission to "display similar rental properties on a map" is more complicated than 400 hours, and more complex "map features" are easy to discuss, examine and test.

40-hour development can easily be corrected even if the direction is wrong.

Change 3: Using the partner system

Pair programming is a new concept defined in "extreme Programming", where two programmers work together to accomplish everything. The idea is that two developers sharing a keyboard make it easier to develop the right software for the first time, and save the back-end time of the software development lifecycle, although I've never seen it applied outside academia, and I don't know which developer would be willing to sit with colleagues 5 days a week, 8 hours a day, but this concept It's still very interesting.

Compared to pair programming, my team uses the "partner system" (right, like a field trip in kindergarten). The partner system is strictly not pairing programming. But we borrowed its core concept and made a corresponding change to the culture of our team to maintain its advantages. Every programmer has a "partner" in his daily work. Before a developer starts a task (remember, there is no scheduled task in our process to allow more than 40 hours worth of work) he has to meet with his "partners" to explain the problem and the methods used for the task. This process takes only 5 minutes, but it saves a lot of time.

The partnership system also applies to the architecture and design dimensions. At the design stage, feature designers meet with their partners at least every other day to discuss changes to their design line. With this process change, we can design the right things at the first time and significantly reduce the likelihood of discovering serious design problems during the development phase.

The advantages of the partnership system include:

Your "partner" is in a better position to do a code check because they understand what you are creating and why.

Before you try a solution, talk about it, often find many traps and prevent detours. I can't remember how many times the first five minutes of discussion in preparation for a task was "Wow, this is wrong." ”

In case you win the lottery or retire, you're just training a replacement.

Our future direction

A software process evolves as the team continues to learn and discover what makes the job better. Our team has made a lot of progress in moving from a stove pipe waterfall process to a tightly integrated, adaptable agile. We're still going to improve something:

We have started migrating from the traditional needs of those "early" parts. Accordingly, bring those high-level concepts, use cases, user stories, and system threads into the center stage. But demand, this unavoidable "evil thing", will remain as a contractor for government existence, but they are really a scary starting point.

We are working to further refine our unfinished taskbar and iterative planning process to improve the accuracy of our estimates. Software development estimates are a tricky skill to master, but it is extremely important for the budget and deadlines to be an ironclad industry.

Frequent iterations make the development and testing team tightly coupled into a team, but we still want to include system engineers.

Summarize

This article describes a simple agile process followed by a development team in the defense industry. It also provides some insights on how to migrate from a painful waterfall process to a more agile process. Running agile does not require remembering countless books, or a robe with the "Scrum master" tag behind it. Reading and attending training will give you new ideas, but the most important feature of becoming agile is the willingness to make small changes and adjustments. In simple terms, agility means having the ability to make changes when something doesn't work.