I was talking to Ron Morsicato of Agile Rules at dinner at last weekend's Deep Lean conference and he was saying how he thought that Agile was a good idea for mission critical applications. That struck me as an interesting thing, and I've been thinking about that all week. I think he's right and here's why I think so.
Let's say you provide mission critical software and there is a problem reported in the field which requires a fix. Well, if you are doing traditional software development, you can't exactly ask the customer to wait until you finish your current release. And if you were to put out a fix for them using your main development path, that would probably take too long too. So, you have to have a critical-fix development path. By definition, this is a development process which is not used for regular development and it is not used very often (so one would hope).
As a result, you have one process for regular development and one process for critical fixes because your regular development process takes just too darn long. That means that when you most need for things to go smoothly you are going to use the process which is the least practiced and probably also something that only a handful of folks know or are allowed to do. Doesn't that strike you as just plain wrong? Imagine trying to explain that to the media!
Part of the idea with Agile, Lean, and especially Hyper Agile is that the path from deciding to make a change and being able to deliver that same change is as short as reasonably possible. If the "overhead" from start to finish for a critical fix is 4 hours, then any task should take you no more than 4 hours plus however long it takes you to write the code and the associated tests. Once you have this capability, then you really only need one development process which you use for both regular development and critical fixes! Thus, everybody is practiced in your critical fix process and everybody has experience with doing it. This will reduce risk and increase confidence in the results.
Something I've noticed a lot lately is that people often come away from a brush with Agile development thinking "gosh, we're pretty much already doing that now!" After thinking about it for a while I realized that there is a big difference between "pretty much" and "actually." :-) This got me thinking about how to make this distinction more obvious. I haven't come up with the perfect explanation yet, but I did come up with a "test" which can be used to see if you are Hyper Agile or not.
1. Did everything in the iteration come from the top of your backlog?
2. Is your backlog in highest-business-value order?
3. Are your iterations time-boxed?
At the end of each iteration...
4. have you written all of the tests that will be run at release time?
5. have all tests (not just new tests) been run?
6. do all tests (not just new ones) pass to the level that you would have at release?
7. are you as confident about releasing as you would be at an actual release?
8. there is no work in progress?
9. have you demoed all new functionality?
10. did you do root cause analysis on all problems?
If you answered "yes" to all of these, then you are getting the key benefits of Hyper Agile development. If you answered "no" to any of them, then you are not.
That doesn't mean that you have to do all of these in order to start experiencing secondary benefits. However, the primary benefits come when these are all happening in concert.
Hyper Agile (aka Hyper) is a development methodology designed to smoothly scale out from small teams to large teams and to maximize the potential of the development organization from a return on investment (ROI) perspective. I’m still working on documenting Hyper in full. In the meantime, here is yet another preview. Except for the practice of short iterations, each of the individual practices are best practices in and of themselves and can be implemented in conjunction with any development methodology.
Short Iterations - It has been widely stated that the benefits of Agile Development are producing value, maturity, and feedback faster; allowing early feedback to inform requirements to produce a better product, and increasing business flexibility. In my opinion, all of the benefits of traditional Agile Development can be directly attributed to the practice of short iterations, everything else is an enabler.
Automate Everything - The practice of automating everything is an extension of the Agile Development practice of writing automated test cases and fully automating the build process in support of the practice of continuous integration. If our main reason for existing as software developers is to automate manual processes, shouldn’t we be using automation more and more instead of less and less? Of course it makes sense that if we are going to be doing something new, there may not yet be off the shelf automation that fits the bill, but when there is, shouldn’t we use it?
Massively Parallel Virtual Pipelining - this is the process of breaking the lifecycle into as many separate steps as possible and then applying that lifecycle to each user requirement on an individual basis in parallel. This enables a high degree of asynchronous activity which in turn facilitates short iterations. I say a virtual pipeline because various stages of the pipeline may overlap with the same stages in other pipelines and because the various stages may be performed at different locations.
Development Hierarchy - A development hierarchy is simply a representation of the dependencies between groups that includes process steps such as integration, quality assurance, and code reviews. It encompasses a number of best practices including multiple isolation levels, gatekeepers, checkpoints, and always moving from a known good state to a known good state. It provides the structure for the parts of the virtual parallel pipelines that are associated with actual code. The fundamental building block of a development hierarchy is a branch.
Work Item Ranking - Work Item Ranking is done by putting all of the planned items into a single list. The first item is the highest priority item and the last item is the lowest priority item. This is also known as backlog in the Scrum Agile methodology. This practice vastly simplifies project planning, keeps you focused on your target market, and helps to prevent feature creep.
Estimation - At first glance, it might seem like estimation is a relatively simple and mundane task. Think about the task, compare it to your experience, give a rough guess and add a little padding. Actually, there is a surprising amount of literature that focuses solely on estimation. In the end, I think the most important part of estimation is to do it. I suggest you use the PERT method. It is widely used, and it is very simple. Take the least possible amount of time, add 3 times the expected, add in the most time it could possibly take, and divide the sum by 5. That’s it.
Writing Tests Early - Tests and requirements are very closely related. In order to write either one, you need to know the answer to the question “what is this supposed to do?” If the person responsible for writing the tests is struggling, it is a good early warning that it is not clear what the software is supposed to do. If it is not clear what the software is supposed to do, it is unlikely that anybody will be able to write the software to satisfy the end user. Thus, it makes sense to write the tests first to reduce the chance of writing code that does not reflect the needs of the end user.
Quality Quotient - One of the frequent objections to Agile (believe it or not) is related to quality. Since there is no good way to determine the exact quality of a product, it is difficult to empirically compare one iteration against another iteration to help to determine whether or not an iteration is ready for release. A quality quotient is a systematically calculated approximation of the quality of a particular iteration. The data that is compiled as part of the calculation of the quality quotient can also be used to guide future quality and process improvement efforts.
Meritocracy - Meritocracy allows developers to contribute outside of their traditional areas, to build trust in their capabilities, and to allow them to naturally gravitate to the areas where they are the most effective. An efficient way to implement meritocracy is to allow developers to create branches where they can implement their ideas. If they are successful in implementing their idea and the result is accepted, it is then a simple matter to incorporate the change into the development process.
Here are some thoughts about winning the Jolt Award as well as a discussion of Hyper Agile, the new methodology that enabled AccuRev to deliver AccuWorkflow on time with high quality.
It might seem like doing Agile Development is not compatible with compliance requirements. However, Software Configuration Management (SCM) plays a vital role in any compliance effort that involves software development.
This podcast covers the following topics:
- How SCM and Issue Tracking can help with compliance in an Agile project
- Process is a dirty word
- The Hyper Agile practices of "development hierarchy" and "one virtual site"
