Using Agile to Achieve Rapid Failure

The Agile Manifesto has been with us now for over eleven years. As one of the dominant software development methodologies, it is becoming widely adopted and is meeting with a great deal of success. The Dr. Dobb's Journal IT Project Success Rates Surveys over the past several years indicate that there is a higher level of success using Agile over traditional, presumably waterfall, methods. With this success, decision makers are more easily convinced to adopt Agile with the promise of a cure for quality issues, low productivity and high costs. This article is intended to address some of the myths about agile and to provide insight into how not to go about adopting agile into your environment.
 

My company has had the good fortune to work with many different clients developing and testing medical devices. Many of these clients choose to work with us for years, delivering several products or product iterations to market. On some projects we get to follow our own processes. On others we are engaged as an extension of our client and follow their processes. When projects end, we have an internal postmortem review. Often our clients join us for a review of their own. From the reviews and by virtue of our consultation, our clients gain insight into how to improve their own processes. Hopefully, dear reader, the following will provide a premortem to your benefit.
 

Don’t Plan, Just Go

Contrary to some opinions, the first rule of Agile is not, “don’t plan more than two weeks out.” While writing software without a plan is exciting and can be very fun, doing so makes for very bad architectures. It also has a tendency to make quality assurance engineers cranky because they like to know what they are expected to test. If you are working on a medical device, an FDA examiner might also not find the daily scrum meeting adequate design input. Planning is a part of agile. Detailed planning is part of good project management.
 

In a recent interview, a medical device client of ours confirmed that they had initially adopted agile for all phases of product development. The results were disastrous. One could very reasonably argue that the company must have implemented agile incorrectly. However, the group was brave enough to revisit agile a second time. This time they implemented a more structured approach with formal requirements, architectural planning, and a fair amount of up-front analysis. They then approached production of the product using agile using the materials produced in product planning. This time they were successful and they continue to follow this methodology to this day.
 

Requirements Aren’t Needed with Agile

Stories are a fundamental component of agile. Stories are intended to be understandable by all members of the team, several of whom will not be software engineers. Sometimes stories can be used as requirements but often there is additional supporting material that is needed such as acceptance criteria. We had a client that had historically followed a very burdensome waterfall process with very low-level, detailed requirements and extraordinarily detailed test protocols. When faced with the prospect of faster productivity, better quality and lower cost, they leapt at the opportunity to adopt agile…with disastrous results. Unfortunately, they effectively threw out their detailed design work, created new stories with little detail and no supporting material and expected their team to produce efficiently. Thankfully they recognized that the project was not running well and brought the detailed design work back, reimplemented the requirements and got the project back on track.
 

Tools Make a Team Agile

When adopting agile, application lifecycle management (ALM) tools can be incredibly useful. Burn-down charts, graphical representations of work left to do versus time, can be impressive tools to visualize productivity. However, many of these tools are complex and require customization to work properly and efficiently.
 

We recently had a client adopt a new, web-based ALM system for their internal and external teams…with disastrous results. Reportedly, the project manager had used the system at a previous company. He was not trained in deploying or administrating the system and instead hired a support engineer in the Eastern Europe to handle those duties. Unfortunately, the system had constant problems. Engineers were unable to check in code, burn down charts would indicate negative work performed, inexplicable changes to work values would occur without any traceability as to who was causing the changes. And because the support engineer was half a world away, he was largely unavailable when we needed issues resolved. It was awful.
 

While that tool was powerful and may have been completely effective if configured properly, because it was not, the cost impact to the project was quite substantial. We use ALM; but, before we started using it, we validated it and created work instructions so individuals could use it without burdensome training. The product is stable, reliable, and provides those sexy burn down charts. We didn’t expect the tool to “make us agile” and we did have to customize it so it would adhere to our processes. You don’t need any software tools to be agile but if you choose to use a product, you should ensure that all the activities for which you plan to use it work as expected. This will probably require you to know how to customize the tool.
 

Agile Means No Estimating

A project manager I worked with in the past was very enthusiastic about agile and convinced his management that estimation was not as valuable as velocity. This is where those sexy burn down charts come in. While he was able to generate those, he was eventually asked to produce a project status report which he did using a simple Microsoft Excel spreadsheet. The decision maker, not impressed with the detail in the spreadsheet, naturally asked, “are we on track to complete the project?” As a standard project plan had not been maintained, the project manager was unable to answer this question. His project was summarily cancelled…certainly a disastrous result.
 

Estimation is the bane of most software engineers that I’ve met. Agile has some novel ways of helping engineers to perform estimates. As a generalization, for agile estimation, one has the team estimate relative size of tasks. For example, for work item A, the team will assign one point. Now for work item B, the team, by consensus, determines how many points B should be. If B is three times the effort of A, they assign three points. During a few initial sprints, the team determines its velocity, that is, how many points it can complete within that time. One then projects points over time to determine how long it will take the team to complete any set of work items. One can track, estimate and report on the status of a project by this means. In fact, one ALM product even integrates with Microsoft Project to help produce plans for those who wish to have project tracking in that format.
 

First, Drink the Kool-Aid

Software for medical devices can be implemented using agile methodologies. Full Spectrum uses a great deal of agile in our processes today and we are continuing to find ways to apply it throughout our company and many companies are bound to see the benefits of agile when adopted properly. But before drinking the Kool-Aid, realize that planning, requirements, application of good technology and estimation are still with us. That is, unless you want to meet with…disastrous results.

++++++++++++
Andrew Dallas is president of Full Spectrum Software and is widely considered a software technology expert in the medical device and life sciences industries. Dallas is a member of MD+DI's editorial edvisory board.