The more I write about agile software development, Key Agility Indicators, and users seeing an environment of rapid change as their most worrisome business pressure, the more I wonder why agility, or flexibility, is not a standard way of assessing how a business is doing. Here's my argument:
Agility is a different measure and target from costs or revenues or risks. It's really about the ability of the organization to respond to significant changes in its normal functioning or new demands from outside, rapidly and effectively. It's not just costs, because a more agile organization will reap added revenues by beating out its competitors for business and creating new markets. It's not just profits or revenues, because a more agile organization can also be more costly, just as an engine tuned for one speed can perform better at that speed than one tuned to minimize the cost of changing speeds; and bad changes, such as a downturn in the economy, may decrese your revenues no matter how agile you are. It's not just risk, because agility should involve responding well to positive risks and changes as well as negative ones, and often can involve generating changes in the organization without or before any pressures or risks.
That said, we should understand how increased or decreased agility impacts other business measures, just as we should understand how increased costs affect cash flow, profits, and business risks, or increased revenues affect costs (e.g., are we past the point where marginal revenue = marginal cost?), or the likelihood that computer failures will croak the business. My conjecture is that increased agility will always decrease downside risk, but should increase upside risk. Likewise, increased agility that exceeds the competition's rate of agility improvement will always have a positive effect on gross margin over time, whether through more rapid implementation of cost-decreasing measures or an effective competitive edge in implementing new products that increase revenues and margins. And, of course, decreased agility will operate in the opposite direction. However, the profit effects will in many cases be hard to detect, both because of stronger trends from the economy and from unavoidable disasters, and because the rate of change in the environment may vary.
How to measure agility? At the product-development level, the answer seems faily easy: lob a major change at the process and see how it reacts. Major changes happen all the time, so it's not as if we can't come up with some baseline and some way of telling whether our organization is doing better or worse than before.
At the financial-statement level, the answer isn't as obvious. Iirc, IBM suggested a measure like inventory turnover. Yes, if you speed up production, certainly you can react to an increase in sales better; but what I believe we're really talking about is a derivative effect: for example, a change in the level of sales OVER a change in cost of goods sold, or a percent change in product mix over the percent change in cost of goods sold, or change in financial leverage over change in revenues (a proxy for the ability to introduce better new products faster?).
So I wonder if financial analysts shouldn't take a crack at the problem of measuring a firm's agility. It would certainly be interesting to figure out if some earnings surprises could have been partially preducted by a company's relative agility, or lack of it.
At the level of the economy, I guess I don't see an obvious application so far. Measures of frictional unemployment over total employment, I would think, would serve as a interesting take both on how much economic change is going on and to what extent comparative advantage is shifting. But I'm not sure that they would also serve to get at how well and how quickly a nation's economy is responding to these changes. I suppose we could look at companies' gross margin changes over the short term in a particular industry compared to overall industry gross margin changes to guess at each company's relative agility in responding to changes in the industry. However, that's not a good cross-industry yardstick...
And finally, is this something where unforeseen factors make any measurement iffy? If what drives long-term success is innovation, which is driven by luck, then you can be very agile and still lose out to a competitor who is moderately agile and comes up with a couple of once-in-a-genertion market-defining good new products.
Everyone talks about the weather, Mark Twain said, but nobody does anything about it. Well, everyone's talking about agility, and lots of people are doing something about it; but I don't think anybody really knows how effective their efforts are. Ideas, anyone?
Saturday, January 17, 2009
Monday, January 5, 2009
Some Personal Thoughts on Agile Development - Finale
So far, I’ve talked about my personal experiences as a programmer that have led me to anticipate – apparently correctly – that agile development would deliver consistently better results by cost, profit, and agility metrics. What about the down side? Or, to put it another way, what else could users do that agile development hasn’t done?
After I left Prime, I started as a computer industry analyst at The Yankee Group. I will always be grateful to Yankee for giving me the broadest possible canvas on which to paint my visions of what could be – as I used to put it, I covered “everything below the mainframe”. Of course, in the early 90s that was only ½ of the computing field … Anyway, one of the things I wrote was a comprehensive report called “Software Development: Think Again or Fail”. [yes, I know; I was a bit immodest in those days]
The reason I bring this up is that two things mentioned in that report seem to be missing in agile development:
1. High-level tools, languages, and components; and
2. Tasking programmers with keeping track of particular markets.
As far as I can see, agile theory and practice doesn’t give a hoot whether those programmers are using Java, Perl, Python, or Ruby on Rails. I use those examples because they all have been touted as ways to speed up programming in the Java/open-source world, and because only tunnel vision leads people to conclude that they’re anything but dolled-up 3GLs that do very well at handling function-driven programming and only adequately at rapidly generating data-access and user-interface code. Compare that to M204 UL, drag-and-drop VPEs (visual programming environments), and the like, and I am forced to conclude that in some respects, these tools are still less productive than what was available 13 years ago. The point is that, even if agile succeeds in improving the speed of the individual programmer, the other productivity shoe will never drop as long as the first instinct of managers and programmers is to reach for a 3GL.
The second point is that although agile does well with making sure that programmers talk to individual end users, that is different from following the entire software market. Following a market gives context to what the end user wants, and allows the designer to look at where the market appears to be going, rather than where end users have been.
So my caution about agile development is that my experience tells me that so much more can be done. The results are startling and consistent; but they could be more so. Agile development deserves praise; but the worst thing for software development would be to assume that no more fundamental changes in the paradigm need be done.
After I left Prime, I started as a computer industry analyst at The Yankee Group. I will always be grateful to Yankee for giving me the broadest possible canvas on which to paint my visions of what could be – as I used to put it, I covered “everything below the mainframe”. Of course, in the early 90s that was only ½ of the computing field … Anyway, one of the things I wrote was a comprehensive report called “Software Development: Think Again or Fail”. [yes, I know; I was a bit immodest in those days]
The reason I bring this up is that two things mentioned in that report seem to be missing in agile development:
1. High-level tools, languages, and components; and
2. Tasking programmers with keeping track of particular markets.
As far as I can see, agile theory and practice doesn’t give a hoot whether those programmers are using Java, Perl, Python, or Ruby on Rails. I use those examples because they all have been touted as ways to speed up programming in the Java/open-source world, and because only tunnel vision leads people to conclude that they’re anything but dolled-up 3GLs that do very well at handling function-driven programming and only adequately at rapidly generating data-access and user-interface code. Compare that to M204 UL, drag-and-drop VPEs (visual programming environments), and the like, and I am forced to conclude that in some respects, these tools are still less productive than what was available 13 years ago. The point is that, even if agile succeeds in improving the speed of the individual programmer, the other productivity shoe will never drop as long as the first instinct of managers and programmers is to reach for a 3GL.
The second point is that although agile does well with making sure that programmers talk to individual end users, that is different from following the entire software market. Following a market gives context to what the end user wants, and allows the designer to look at where the market appears to be going, rather than where end users have been.
So my caution about agile development is that my experience tells me that so much more can be done. The results are startling and consistent; but they could be more so. Agile development deserves praise; but the worst thing for software development would be to assume that no more fundamental changes in the paradigm need be done.
Some Personal Thoughts on Agile Development, Part 2
In Part 1, I talked about how I learned that the concepts of agile development could be effective, while I was at CCA as a programmer. But how does agile development achieve consistently improved results, as I found in the survey I mentioned? Well, I found some clues when I went to work for Prime Computer, right after CCA.
Prime was the first time I got to deal with project leadership in anything but a one-person project (except a 3-week stint at CCA). Prime was a very different company – thousands instead of 40-100 people, and therefore 40 software-development-related people in my own corner of the company out of more than a thousand; plus, Prime was really still a company where the software was aimed at selling the hardware. So I not only learned about development from a much broader and managerial perspective; I also learned about large organizations’ overall attitude towards development.
Insight # 1: Theoretically, doing a Gantt chart based on your experience and measuring yourself on being on time, within budget, and doing all the functionality is the way to go; in the real world, it has little relation to success. Here’s my story; I set out a schedule and sent it to my boss; in order to fund it, he figured out how to reschedule, and cut the time and costs by 25%; he sent it to his boss, who in order to sell it to the company head, did the same thing. So my best guess of how long it would take was sliced by almost ½. When I pointed out that this was probably not going to happen, my bosses reassured me that they understood that the numbers were optimistic – and then expressed concern during the project when things fell behind their schedule. I have seen this frequently enough since that I have cockily created Kernochan’s Law: Multiply the estimated time for a project by 4/3 ** (number of levels of management review) to get a realistic number.
Insight #2: There is no developer career path. In Prime’s case, after a certain level you could either be a marketer or a “Principal Software Engineer”. From that point on, if you stayed on the developer hierarchy, you would either be an advisor thinking grand theoretical thoughts or a manager; but as an advisor you would not expand your say in the non-technical aspects of the product, and as a manager you would move out of the developer career path. Again, this is a pattern I frequently see elsewhere: doctors doctor and also manage the hospital; physicists run biotech shops and also direct the research; software developers rarely are allowed to combine the technical and marketing aspects of product design as part of their career path, nor are they trained to do so.
What does this have to do with getting consistent results from agile development? Well, if you think about it, the number of levels of managerial review in agile development is effectively zero: it’s just you the developer and the end user for every change. Moreover, you’ve opened yourself to changes in the spec; so who knows what the realistic estimate for project end should be? And yet, when you do this, you look back at the end of the project, and by any realistic measure, you’ve actually done things faster – even though each change should mean you’re falling further and further behind your original budget. Agile will do consistently better in all realistic metrics, like development cost compared to what the same product should have cost by the old process, because it does not manage nor measure by flawed numbers and incentives.
Moreover, agile will also do consistently better because it implicitly gives good developers more of a professional career path. At the same time you think you are madly asking for intense programming spurts, you are actually asking for lots of programmer input into the non-technical design of the product, using the end user as an excuse. The reason the user is more satisfied is not just because he or she is listened to more; it is also that the programmer is combining technical and non-technical aspects in program design, making a better combined product. That doesn’t affect costs, except costs to retrofit; it does affect return on investment, customer satisfaction, and the “agility” of the resulting product (because some of the non-technical reasons for a new version have already been dealt with).
All right, so my experience tells me that agile development is a great idea and will deliver consistent results. Is it enough? As the British say, not by a long chalk. In my Finale, I explore what my personal story tells me is missing.
Prime was the first time I got to deal with project leadership in anything but a one-person project (except a 3-week stint at CCA). Prime was a very different company – thousands instead of 40-100 people, and therefore 40 software-development-related people in my own corner of the company out of more than a thousand; plus, Prime was really still a company where the software was aimed at selling the hardware. So I not only learned about development from a much broader and managerial perspective; I also learned about large organizations’ overall attitude towards development.
Insight # 1: Theoretically, doing a Gantt chart based on your experience and measuring yourself on being on time, within budget, and doing all the functionality is the way to go; in the real world, it has little relation to success. Here’s my story; I set out a schedule and sent it to my boss; in order to fund it, he figured out how to reschedule, and cut the time and costs by 25%; he sent it to his boss, who in order to sell it to the company head, did the same thing. So my best guess of how long it would take was sliced by almost ½. When I pointed out that this was probably not going to happen, my bosses reassured me that they understood that the numbers were optimistic – and then expressed concern during the project when things fell behind their schedule. I have seen this frequently enough since that I have cockily created Kernochan’s Law: Multiply the estimated time for a project by 4/3 ** (number of levels of management review) to get a realistic number.
Insight #2: There is no developer career path. In Prime’s case, after a certain level you could either be a marketer or a “Principal Software Engineer”. From that point on, if you stayed on the developer hierarchy, you would either be an advisor thinking grand theoretical thoughts or a manager; but as an advisor you would not expand your say in the non-technical aspects of the product, and as a manager you would move out of the developer career path. Again, this is a pattern I frequently see elsewhere: doctors doctor and also manage the hospital; physicists run biotech shops and also direct the research; software developers rarely are allowed to combine the technical and marketing aspects of product design as part of their career path, nor are they trained to do so.
What does this have to do with getting consistent results from agile development? Well, if you think about it, the number of levels of managerial review in agile development is effectively zero: it’s just you the developer and the end user for every change. Moreover, you’ve opened yourself to changes in the spec; so who knows what the realistic estimate for project end should be? And yet, when you do this, you look back at the end of the project, and by any realistic measure, you’ve actually done things faster – even though each change should mean you’re falling further and further behind your original budget. Agile will do consistently better in all realistic metrics, like development cost compared to what the same product should have cost by the old process, because it does not manage nor measure by flawed numbers and incentives.
Moreover, agile will also do consistently better because it implicitly gives good developers more of a professional career path. At the same time you think you are madly asking for intense programming spurts, you are actually asking for lots of programmer input into the non-technical design of the product, using the end user as an excuse. The reason the user is more satisfied is not just because he or she is listened to more; it is also that the programmer is combining technical and non-technical aspects in program design, making a better combined product. That doesn’t affect costs, except costs to retrofit; it does affect return on investment, customer satisfaction, and the “agility” of the resulting product (because some of the non-technical reasons for a new version have already been dealt with).
All right, so my experience tells me that agile development is a great idea and will deliver consistent results. Is it enough? As the British say, not by a long chalk. In my Finale, I explore what my personal story tells me is missing.
Some Personal Thoughts on Agile Development
Recently, I have been involved in a survey of development organizations, assessing their practices and how they are changing. It is not giving away too much, I hope, to say that the results were quite surprising to me. I never expected, for one thing, that the whole idea of “agile” development would have become so pervasive in so short a time – not only in the small innovation-seeking software companies but also in large non-software firms doing massive projects. Granted, it is more popular in the US than abroad, and granted, in a few cases “agile” seems more like a fuzzy marketing term slapped onto collaborative technologies. But time and again, users are getting specific – looking at variants of SCRUM and DSDM, using tools with Agile in the product name, mentioning extreme programming practices.
It is less surprising to me that agile programming is delivering results – consistently. You see, I’m a former programmer – although I haven’t done much if anything in the last 18 years. More specifically, I’m a graduate of Computer Corp. of America, whose Model 204 User Language taught me a lot about programming that neither schools nor other development shops came within a mile of suggesting.
At first glance, M204 UL seemed a bit like a third-generation language – say, PL/1. It had English-language variants of the usual C-like commands, plus string handling that was strongly reminiscent of SNOBOL. Ah, but then there were the data-access commands. These were superbly crafted to do what they said in an intuitive fashion, and to give the programmer full rein to optimize the code using simple, orthogonal statements. What do I mean by orthogonal? I mean that each different statement type covered a large, distinct set of operations, and together they covered everything “data” you wanted to do.
Now, what does this have to do with agile? Well, if you didn’t worry about little things like performance, you could rip off a program to do just about anything in nothing flat (remember, this is before GUIs). So some M204 UL experts did just that, traveling to user sites to customize like crazy. Iterative prototyping back at CCA was a way of life, not a whole new process.
The second thing that M204 UL taught me was that close ties with the user were good, not bad (up to a point; users couldn’t tell you where the market was going, just what they needed right then). I did several revs of an email product built using M204 UL, and what drove the specs for each rev was user input, because there just wasn’t enough bandwidth to do an elaborate, controlled development process. And guess what? The result was better, and was developed quicker, than just about anything else out there. As a one-person shop, I was turning out major revs every 6 months, if needed.
And finally, M204 UL and CCA taught me a great deal about the perils of over-controlling the development process. My last project was a development tool, done in parallel with a 9-person search-tool project. I was forced to sit in “design by committee” meetings all day, every day, for 5 weeks straight. The resulting file-search-tool design was thoroughly documented, bland, and highly complicated. I wrote out some hasty, vague specs for the development tool, because I wanted freedom to elaborate as I went. The result was that the search-tool team got kudos for their design, and I got put on probation – but they still needed me to do the development tool.
Well, to make a long story short, I finished that tool – a very original, easy-to-use one that sold just fine – in about 3 months, or shortly before I left. The search tool development was done in the same over-controlled manner that its design was, and after a year the project was cancelled – they just couldn’t get it to work. And that taught me that flexibility and room for change trumped control, at least for medium-scale projects – and, as we saw from the Internet, that goes for large-scale projects done iteratively and incrementally, as well. I’m not knocking control; but it has to be control in the service of flexibility, not preventing it.
So I learned, in my gut, that the kinds of ideas that agile is talking about now – fast “spiral” iterations, lots of user feedback, loosely-coupled programmers – could work. What about getting consistent results? Well, that’s another story – for the next blog.
It is less surprising to me that agile programming is delivering results – consistently. You see, I’m a former programmer – although I haven’t done much if anything in the last 18 years. More specifically, I’m a graduate of Computer Corp. of America, whose Model 204 User Language taught me a lot about programming that neither schools nor other development shops came within a mile of suggesting.
At first glance, M204 UL seemed a bit like a third-generation language – say, PL/1. It had English-language variants of the usual C-like commands, plus string handling that was strongly reminiscent of SNOBOL. Ah, but then there were the data-access commands. These were superbly crafted to do what they said in an intuitive fashion, and to give the programmer full rein to optimize the code using simple, orthogonal statements. What do I mean by orthogonal? I mean that each different statement type covered a large, distinct set of operations, and together they covered everything “data” you wanted to do.
Now, what does this have to do with agile? Well, if you didn’t worry about little things like performance, you could rip off a program to do just about anything in nothing flat (remember, this is before GUIs). So some M204 UL experts did just that, traveling to user sites to customize like crazy. Iterative prototyping back at CCA was a way of life, not a whole new process.
The second thing that M204 UL taught me was that close ties with the user were good, not bad (up to a point; users couldn’t tell you where the market was going, just what they needed right then). I did several revs of an email product built using M204 UL, and what drove the specs for each rev was user input, because there just wasn’t enough bandwidth to do an elaborate, controlled development process. And guess what? The result was better, and was developed quicker, than just about anything else out there. As a one-person shop, I was turning out major revs every 6 months, if needed.
And finally, M204 UL and CCA taught me a great deal about the perils of over-controlling the development process. My last project was a development tool, done in parallel with a 9-person search-tool project. I was forced to sit in “design by committee” meetings all day, every day, for 5 weeks straight. The resulting file-search-tool design was thoroughly documented, bland, and highly complicated. I wrote out some hasty, vague specs for the development tool, because I wanted freedom to elaborate as I went. The result was that the search-tool team got kudos for their design, and I got put on probation – but they still needed me to do the development tool.
Well, to make a long story short, I finished that tool – a very original, easy-to-use one that sold just fine – in about 3 months, or shortly before I left. The search tool development was done in the same over-controlled manner that its design was, and after a year the project was cancelled – they just couldn’t get it to work. And that taught me that flexibility and room for change trumped control, at least for medium-scale projects – and, as we saw from the Internet, that goes for large-scale projects done iteratively and incrementally, as well. I’m not knocking control; but it has to be control in the service of flexibility, not preventing it.
So I learned, in my gut, that the kinds of ideas that agile is talking about now – fast “spiral” iterations, lots of user feedback, loosely-coupled programmers – could work. What about getting consistent results? Well, that’s another story – for the next blog.
Subscribe to:
Posts (Atom)