Archive for February 2009
Upcoming Events
I noticed that Israel will be at a couple of Agile related events soon:
- March 3rd – Israel and Sebastian Hassinger will give a talk – “The Use of Agile Methods by the Entrepreneur” – at the local, Austin Agile user’s group. See the details over at the Agile Austin site.
- March 5th – Israel will be talking with rPath in a webinar on the topic of “Extending Agility to Dev and Testing via Virtualization and Cloud.” See more details here as well.
- March 18th, March 26th, and April 2nd – Israel will be talking during the Rally Agile Success Tour.
- April 30th – he’ll be over at PMI Houstn 2009.
Beautiful Software
Peggy Reed shared with me her thoughts about beautiful software. To quote Peggy:
Beautiful software goes beyond elegant GUI and elegant APIs.
Peggy will elaborate on this intriguing subject on March 18 in Denver as part of the Agile Success Tour organized by Rally Software. Until she discloses her “secret sauce”, I would allow myself to share one fascinating linkage: IMHO Peggy’s thoughts about beautiful software are very synergistic with Jim Highsmith‘s ideas about intrinsic quality.
Both the Rally team and I will elaborate on the subject after the March 18 event. Stay tuned…
From “How” to “What”
I have been speaking with various panelists in preparation for the forthcoming Rally’s Agile Success Tours. One emerging thread in these pre-panel discussions is the need to elevate the playing fields. Nobody doubts, of course, the importance of the nuts and bolts of Agile. But, just about every panelists I spoke with believes we should pay as much attention to end-to-end corporate business considerations. In other words, we are starting to shift from “How” to “What”, from the small scale roll-out to enterprise level Agile.
Stay tuned…
Early Warning Signs
Colleague Michael Mah describes comparing time-to-market, productivity and quality of a project team against industry averages as being outside the elevator. With the focus on iteration and release, it feels like being in an elevator – precious little contact with the outside world. For example, you do not know where other elevators are headed and what their speed is until you step out of the elevator. As long as you are in your “elevator”, it is quite difficult to objectively assess whether your Agile roll-out is or is not going well.
Until you collect the data and acquire the analytics to compare your team to other project teams in the industry, here are a few early warning signs for Agile implementations that might be heading toward trouble. Like everything in Agile, they give you the opportunity to take the input as call to action and apply the necessary measures to improve your process.
Time spent with Agile teams in the trenches
This is the simplest yet the most reliable warning sign. If you are the executive in charge of the Agile roll-out, examine your calendar over a certain period of time with respect to two questions:
- Do I spend enough quality time with the Agile teams to be able to notice the rest of the early warning signs listed below?
- Am I involved in a manner that clearly demonstrates my support of and commitment to the Agile roll-out?
The data you collect from your calendar is simple. For example:
- Number of stand-up meetings attended.
- Number of bi-weekly demos attended.
- Number of hours spent in release planning.
You do not need to say much in any of these forums. You might even choose to be completely silent through a stand-up meeting . However, you must spend quality time with the teams that are getting into Agile. Allocating 20-25% of your time to being with the Agile teams in the trenches is quite appropriate, particularly in the initial roll-out phases.
Failure to prioritize
The great advantage of this warning sign is that it can be spotted fairly early. In its implicit form, this sign manifests itself as multiple backlogs when one backlog should have sufficed from a product perspective. In its explicit form it manifests itself as everything is important statements and pressures. In severe cases you might even notice that the Product Owner is not really part of the team, that an us versus them attitude prevails.
Chronic reductions in scope
Flexibility is very different from mushiness around the minimum credible line of a release. Repeated reductions in scope, as distinct from substituting one requirement for another, is a certifiable sign of trouble. Something is wrong if reductions in scope happen one iteration after another. Something is terribly wrong if team members believe the Agile philosophy is supportive of scope reductions in an unconstrained manner.
In some cases the heart of the matter might be as simple as inadequate estimation techniques, not inadequate execution. However, until estimation accuracy improves, relationships between R&D and marketing and sales are likely to be strained.
This warning sign tends to manifest itself later rather than earlier in the Agile release. However, it is quite easy to spot.
Weak focus on outcome
This warning sign is a close cousin of chronic reduction in scope. It usually manifests itself as misplaced focus. For example:
- The focus is on the team progress rather than overall project progress
- Output numbers become more important than outcomes
- Managers and directors bicker about which team was “behind”
- Product marketing changes the backlog frequently under the “Agile flexibility” banner
Not keeping up
Keeping up with all facets of Agile practices amidst short iterations can be quite demanding. Watch out for repeated failures to keep up with:
- Builds
- Continuous integration
- Defects/testing
- Completing stories within the iteration
- Resolution of blocking issues
- Regular bi-weekly demos
- On-going release-ability
- Technical debt
This warning sign is best used in the aggregate rather than in a discrete manner. To properly use this sign, watch for cumulative effects rather than a single failure.
Acknowledgements: Many thanks to Igor Bergman, Walter Bodwell, Mike Lunt and Roy Ritthaler for sharing their warning signs with me and with the readers of this blog.
Your Customer as Your QA Team
An enterprising developer shared the following experience in the Agile Requirements Process workshop hosted today in Austin, TX by Enthiosys and Borland. As he did not have a QA team, he requested his end users to do the QA for his product. Asked how well it worked he responded with three words:
They loved it!
Batten Down the Hatches
“As you might expect, we are in a batten down the hatches mode.” These words, taken from an email an executive just sent, prefaced his decision not to go ahead with planned Agile projects due to the need to cut costs. His operating assumption is simple: His company must cut costs now and will somehow manage without investing in Agile software and consulting.
Real $$ are hidden in your software
In Estimating Software Costs, author Capers Jones quantifies five year cost of software application ownership (for the vendor). He examines three similar applications, each of nominal size of 1000 function points, as a function of the sophistication of the corresponding projects. The respective life cycle costs are as follows:
- Lagging projects: $2,316,000
- Average projects: $1,860,000
- Leading projects: $1,312,000
Jones goes on to issue the following stern warning:
All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.
Dwindling maintenance revenue streams complicate the situation
Revenues from maintenance services are subject to severe pressures these days as many customers are renegotiating service contracts. Igor Stenmark foresaw and foretold the phenomenon in November 2008. To quote Igor:
…sacred cows like software maintenance can become hamburger meat if users feel enough of a budget pressure.
Net net, as they say, the exec mentioned above is likely to face rising maintenance costs due to software decay over time. At the same time, revenues from maintenance contracts are bound to fall short of projections due to customers renegotiating their contracts.
The shiny new toy is not a cure
Recognizing the software maintenance conundrum they are caught in, many executives are pushing hard to develop new software to increase sales in order to compensate for the decline in revenues from software maintenance services.
What is missing is a serious commitment to improve the underlying software process. Software developed today might indeed be sold as a shiny new toy tomorrow. But, unless the software process is improved, a little down the road the new software will have similar maintenance problems. The corrosive effect of software decay on the shiny new software will become more and more severe as a function of time. The current business environment, hopefully, will change in a few years. However, the underlying software development and maintenance laws will not. No getting around it.
No better time than now
The numbers from Capers Jones cited above are illustrative of the cost savings you could expect to attain by modest investments in improving software process and practices. You might perhaps have more attractive cost saving alternatives available to you. However, if you don’t, there is no better time to invest in software process and practices than now.
How to Viral-Spread Agile on a Large Scale
In last week’s Agile Austin Distinguished Speaker Series, Sue Mckinney and Pollyanna Pixton presented the Agile/Lean work they carry out at IBM. Their approach to making Agile of interest to 25,000 employees in IBM’s Software Group stands in nice contrast to the classic quip “I am from Corporate; I am here to help you.” As a matter of fact, during her presentation Sue recounted how as a developer she disliked edicts that came from above when they did not suit context and reality in the trenches.
Sue’s presentation is available here. It deserves thorough reading by anyone who is concerned with scale and scope issues in Agile roll-outs. Here are some of the more interesting points:
- The initial impetus to go Agile was time-to-market imperatives
- The Development Transformation program which Sue drives at IBM provides a menu of thirteen Agile/Lean best practices a development team can choose from.
- The program puts an emphasis on adaptive planning
- The program stresses the importance of sharing both code and best practices
- An expanded community of 40,000 IBM’ers and >100 customers are part of the program
- Geographically distributed teams are considered the norm at IBM (given the company’s M&A strategy); Agile practices must take this reality into account
Interestingly, in the series of workshops she delivered at IBM, Pollyanna did not even speak about Agile! Instead, she talked about the various aspects of collaboration and team dynamics. You can get a good sense of the themes Pollyanna covered at IBM in her presentation on Collaboration and Collaborative Leadership in the Experience section of the Accelinnova web site. See Jean Tabaka’s note and Michael Cote’s note for complementary opinions on collaboration, organizational dysfunction and Agile.
Sue and Pollyanna are continuing their Agile roll-out work at IBM. Stay tuned….
Every Thirty Minutes
Colleague Jim Van Riper drew my attention to a point Kent Beck made in a recent presentation: Flickr deploys every 30 minutes.
The point Kent makes fits nicely with two themes that have been discussed in this blog:
- Number of active releases
- Releasing “always”
Between fast development and fast deployment I am starting to think in terms of software as water. Software could and should continuously flow on demand from the R&D lab to the customer. Such uninterrupted flow in the feedback loop between developer and end-user makes Agile extraordinarily powerful.
When Quality is Not an Option
Every cure to a problem begins with one obvious step: stop doing the thing that’s causing the problem. No general cure-all or best practice can directly address that first step perfectly for every singe instance. In the world of Agile development, organizations are often plagued with dysfunctionality that must be addressed before Agile methods can achieve the stupendous results those organizations are lusting after.
As I’ve watched people discuss and, more often, argue about Agile over the years, I’ve noticed that these folks often begin their quibbling over this first step: one side of the argument will assume the disfunction in the organization has been – or even can be – taken care of and is, thus, shocked that Agile would not work, while the other is focused on the existence of the disfunction and the impossibility of removing it.
As you can guess, I have no pat answer for how you clean up that problem: that’s the whole point.
It always strikes me that Agile methodologies work very well with functional teams: in fact much of the management side of Agile goes towards identifying (with the goal of getting rid of) dysfunctional team members and processes. Still, you don’t see much on the topic of “Agile firing.”
Other, pre-Agile approaches, however, tend to be the opposite: they’re built around helping an inefficient, dysfunctional base achieve “success” at software delivery. There’s some semantic difference on what “success” means there: for Agile it usually means high quality, for more cynical methodologies it can mean cashing the clients’ check, meeting KPIs, or otherwise CYA’ing instead of “doing the right thing.”
Those are broad generalizations, of course, but I’ve rarely found an agile solution that doesn’t involve making things better rather than dealing with the less than ideal team you’ve been given. Alistair Cockburn‘s work is an interesting exception here where-in he spends quit a bit of time assessing the quality of teams and then trying to match-up methodologies that will work with what you have rather then let you excel with what you wish you had.
The danger here is to think the conclusion is to ask if yourself if Agile will work in your dysfunctional organization. Clearly, if you have a dysfunctional organization, whatever it is you’re currently doing doesn’t work, by definition. But, the trap in that situation is thinking that Agile will help you avoid the difficult task of maturing and getting good enough to even start benefiting from becoming Agile.
“Where to Turn in a Downturn Economy?”
Jean has a nice post in the Agile Blog on team dysfunctions and Agile. Her recommendation on the subject is crisp:
If you are looking to Agile and how it can cut costs for your organization, consider the power of your teams. Work to engender trust and promote an ability to have constructive conflict. Empower your teams and amplify the learning that teams bring to organizations.
I will allow myself to go one more step. IMHO Agile exposes team dysfunctions and organizational pathologies. This is the reason Agile is so powerful on the one hand, and why it might meet strong resistance on the other.
The Agile Executive 