One of the key technologies that I preach (I am, after all, Chief Evangelist of IBM Rational) is agile methods. Since I’m focused in the systems space, my concerns are how to apply the principles and practices of agile to embedded software development, systems engineering, and systems of systems management. I have a special focus also on safety and security of these cyber- physical systems areas of concern I consider crucial for system success.
There are people who claim that agile cannot be applied to such systems because agile means there is no planning and no tracking; to them, “being agile” is just a license to hack away until they are tired, at which point, presumably, they are done. From my point of view, these people are clearly misguided, as well as from the point of view of other agile theorists.
Scott Ambler, talks about “disciplined agile” and a lot of his focus is on scaling agile methods up from small co-located project teams to entire organizations. In this view, agile is a very disciplined approach to development and requires planning and some rigor to succeed. I strongly believe Scott is right and it is this rigor that I bring when I apply agile methods to the systems space. A key part of this rigor is monitoring your success and modifying your approach to improve it.
On the other side, we have people who claim that the Harmony/ESW process (see my book “Real-Time Agility” for more) isn’t agile because it doesn’t rigorously follow their favorite agile dogma. I find this argument – that you should dogmatically apply an approach that emphasizes flexibility and uses feedback to change and improve its effectiveness – amusing, to say the least. It’s like “Jumbo Shrimp”, “a little pregnant” or “acute apathy.” An oxymoron is a statement whose inherent assumptions invalidate its own premise.
Agile methods really focus on activities that shorten the “time to value” – such as continuous execution, test-driven development, incremental development, and continuous integration. It does require planning as well, but a difference is that Agilistas understand that a plan is a map drawn for a geography that you’ve heard about but not yet visited. Such plans are incorrect in a variety of ways even if they are mostly ok.
A couple of weeks ago I was in Japan visiting a major electronics company wanting to use agile methods for their consumer products. They were very concerned about how you can plan products development when agile methods proceed without planning. They were under the impression that agile methods mean that there can be no plan, developers just hack away until they think they’re done. They were concerned about coordinating the efforts of hundreds of engineers to produce a single product using approaches that were only valid for small co-located teams. Again, they misunderstood the heart of agility – act where you can add value and do what demonstrably works.
People move to agile methods first and foremost to improve quality and secondly to improve their productivity. Mostly, it means that you continue to do the activities that you do in a more traditional process but you do them in a slightly different way and perhaps at a different time. For example, most traditional environments do have a unit testing activity that is performed near the end of the development cycle. The Test Driven Development (TDD) practices change when you do that (at the same time you develop the software, that is, daily) and a bit about how you do that (incrementally rather than all at once). The task is still largely the same but by rearranging how you perform the task, your time to value is greatly shortened.
Nevertheless, when we start working on a project, we have grand ideas about how the project will unfold. If there is one take home message I’ve gotten from over 35 years developing systems, it’s that the plan is wrong, in some detail great or small. So we adjust our plans based on success metrics, such as defect density or project velocity. And based on that feedback, we change what we do. Rigorously adhering to a workflow that direct evidence suggests is suboptimal is not only silly, it violates the basic premise of agile – “do what works.” Rigorous Agile is an oxymoron if I’ve ever heard of one.