What IS Agile - and What Agile is NOT

(Image Used by Permission from Mark Shead)

Two years ago I became a “certified Scrum Master.” Not a lot was required. I was sent advance reading materials and then I attended a two-day training in a hotel conference center. As Agile was fairly new to me when I first joined AKF, it was a good overall review.

In attendance at the training were a number of “Scrum Masters” from a very large company you’d quickly recognize. They all had their laptops open and were busy with their day job and didn’t pay much attention to the training, leaving often for phone conference calls.

During breaks, I asked them about what they felt the difference between Agile and Waterfall was specifically for what they do every day. The answers were fairly similar “I was given the title Scrum Master two years ago, but I’m a project manager and our company does everything waterfall.” So for two years they had the title Scrum Master, were now just barely attending a certification training, and their company was still running waterfall and seemingly not about to change anytime soon.

This response is not a surprise. In our technical due diligence reviews for investors and senior management, we often hear they are an “Agile shop,” but when we drill down and discover teams cannot autonomously deploy code, that their work then gets put in a long queue for Infosec and other teams to review and often have to redo work, it is clear that they are Agile only in name.

It seems that everyone is moving to an Agile approach in their product (or software) development lifecycle. Some move with great success, some with great fanfare and for some it’s one of the last moves their company and engineering organizations make before failing miserably and shutting doors permanently. As often as not, companies just move because they believe it will cure all of their problems.

No new PDLC will cure all of your problems. Agile may in fact be best for you, but there are always tradeoffs.

We’ve compiled a list of 5 common misconceptions about Agile from our experience working with companies to solve problems. Be careful of these pitfalls as they can cause you to fail miserably in your efforts!

1) Agile is NOT a reason to NOT manage engineers or programmers

Engineering organizations measure themselves. In fact, many Agile methods include a number of metrics such as burn down charts to measure progress and velocity for measuring the rate at which teams deliver business value. As with any other engineering organization, you should seek to find meaningful metrics to understand and improve developer and organizational quality and productivity. Don’t let your team or your managers tell you not to do your job!

2) Agile is NOT a reason to have engineering alone make product decisions

You still have to run your business which means nesting the product vision to the vision of the company. More than likely you are paying business or product people to define what it is you need to do to fight and win in your market. Someone still has to set the broad strategic vision to which products will be developed. Engineers can and should contribute to this vision, and that’s where Agile methods can help.

3) Agile alone is NOT a cure for all of your product delivery problems

There simply are no silver bullets. With the right management and oversight, you can make any development lifecycle work. There are just cases where Agile methods work better. But don’t look to have a PDLC fix your business, people, or management issues!

4) Agile is NOT an excuse to NOT put in the appropriate processes

There is nothing in the Agile Manifesto that states that process is evil. In fact, it recognizes processes are important by stating that there is value within them.

Agile simply believes that individuals and interactions are more important – a concept with which we completely agree! Don’t argue that all process is evil and cite Agile as the proof as so many organizations seem to do. Certain processes (e.g. code reviews) are necessary for hyper growth environments to be successful.

5) Agile is NOT an excuse for lack of documentation

Another often misinterpreted point is that Agile eliminates documentation. Not only is this not true, it is ridiculous.

The Agile manifesto again recognizes the need for documentation and simply prefers working software over COMPREHENSIVE documentation. Go ahead and try to figure out how to use or troubleshoot something for the very first time without documentation and see how easy it is …

Programming without design, coupled with inadequate documentation makes one a hacker instead of an engineer. Do your documentation, just don’t go overboard and for heaven’s sake make sure you have working software.

Our one-day remote or in-person due diligence will quickly help you uncover your Agile pitfalls and highlight your strengths. Give us a call, we can help!