May 21, 2005
Agile Software Process ImprovementMuch of my time professionally is spent helping organisations to build their capability to deliver software. There are lots of different approaches to improving software development processes, but I've never find them to be as practical as I'd hoped.
I like consistency in approach: whatever works for managing successful development projects should work for managing successful improvement projects. After all, a project is a project (is a project).
As SPI projects usually involve a considerable degree of complexity, and therefore uncertainty, it makes sense to apply agile values and practices to the SPI process in a lot of cases.
For example, if we apply agile values:
then should we not get better results?
Many SPI efforts are completely overblown. Process consultants design elaborate and highly prescriptive processes, involving dozens of different roles and hundreds of artefacts, and then expect the client orgnaisation to adopt the whole thing in one big hit. Little thought is given to how much of the process actually creates value in the end product, and we end up with considerable amounts of redundancy and wasted effort. In Agile SPI, we should try to do the simplest things that will deliver the desired results.
Another failing in many SPI projects is the way in which process consultants try to "improve" things without interacting much with the people who'll be enacting the process, or with the people paying for the improvements. This is like trying to direct a movie from your home office - which is a just a tad unrealistic. Process improvement is all about positive change in the client organisation, which requires a considerable amount of listening, influencing and mentoring. In fact, once you understand the goals of your SPI project, most of the remaining work involves rich and effective interaction with the process stakeholders.
Watt S Humphrey of the Software Engineering Institute at Carnegie Mellon once said: "If you don't know where you are, a map won't help". Agile projects require objective feedback to let you know the outcome of each action. Without that, you are flying blind. How do you know that the improvements you've made really have improved things? How do you know if the process stakeholders actually understand the process, and are comfortable executing it? Instinctively, many of us have a phobia of turning over the card to see what's really what. Perhaps it will be bad news, and we don't like bad news, do we? Process improvement without objective feedback is like never checking the balance of your bank account, or driving a car with your eyes closed. Generally, it leads uninformed decision making and, ultimately, distaster.
Some of the changes that need to be made in SPI take some nerve to recommend, and hutspar to carry out. Sometimes the team is just too big, and the only sensible course of action is to trim the fat. Sometimes the developers are just too junior, and you need to replace them with better people. Sometimes, the HR department get in the way and you have no choice but to go over their heads to get the people you need. Sometimes, the whole setup is just plain wrong and you need to hire new offices to create a productive working environment. These are the kinds of changes a lot of process consultants shy away from recommending, because they know how painful it can be. If you're getting paid very well, the last thing you want to do is rock the boat. Similarly, some of the changes you might want to try will have no guarantee of success - but you won't know that until you try them. You shouldn't be afraid to suggest diffgicult changes, nor should you be shy of taking some controlled risks and adopting a "suck it and see" approach when it makes sense to do it. In the line from Dune, "fear is the mind-killer". Don't let your SPI project fail because you're afraid to do what it takes to succeed.
It makes sense to apply agile values to process improvement, but what about agile practices? Is there anything we can learn from eXtreme Programming, for example, that might help in an SPI project?
If it makes good sense to write the test before you write the code, so you can better decide what code you need to write and so that you can get rapid feedback on whether your code works (as well as ongoing feedback that your code still works), then surely a similar approach to SPI might succeed?
What are the tests in SPI? Well, if the measure of progress in XP is working code, and the tests check that the code really does work, what is the measure of progress in SPI and how can we test that? The measure of progress in software process improvement is, unsurprisingly, improvement. So our SPI tests should tell us whether we got the improvement we set out to achieve. In order to do that, we need to measure the thing we're attempting to improve. If our goal is to improve maintainability, we need to measure maintainability. If our goal is to improve productivity, we need to measure productivity. Measurements are to SPI what tests are to XP. A working system is one that satisfies it's suite of tests. A working process is one that meets its performance targets.
When we write code, we introduce flaws - or "code smells", as author of the book Refactoring, Martin Fowler, calls them. Try as we might, we never get the design 100% right first time. Refactoring is the discipline of improving the design of code through small, low-risk and reversible changes. It enables us to incrementally refine the software design as we go. Refactoring and TDD go hand-in-hand. Refactoring is needed to "clean up" the design after we pass each new test, and the test suite is needed to ensure that our refactorings haven't broken anything.
Similarly, any process we try to put in place will have flaws - let's call them "process smells". As time goes on, even the best teams let their standards slip, and processes - like code - have a tendency to "rot". It makes sense to view SPI as process refactoring, and any effective SPI effort needs to incrementally improve a working process, using measures to tell us if we've inadvertantly broken the process. In that sense, we should strive to always have a working process right from the start. It may have few of the features of the process we're aiming for, but it should be capable of deliverin working software at the very least. Once we've created that initial capability, we can apply small, low-risk and ideally reversible improvements to refine and flesh out the process to meet a wider set of performance goals than the rather blinkered objective of simple delivery.
In the next post, we'll look at how other agile practices can be applied to software process improvement...
Posted 16 years, 3 months ago on May 21, 2005