A couple of days ago while at QCon San Francisco, I had a series of conversations with a person involved in software development at a major financial institution. He really wants to start using Agile techniques, but isn't sure of the best approach to take to convince others internally. I gave him some pointers including my recent article "Software Developers Can Learn a Lot from Salespeople." As I was thinking about this I realized that Agile is actually a perfect fit for financial institutions!
Software projects are highly unpredictable. More often than not they are either late, over budget, missing originally planned contents, much lower in quality than originally planned or a mix of all of the above. Another area of the business that has similar problems with predictability is sales.
When was the last time that salespeople were expected to tell you exactly what their financial performance would be? Sales people can't predict exactly which deals will come in during a quarter, nor exactly what the amount of any particular deal will be, but they are expected to hit their quotas and they are expected to show results on a regular basis and CFOs are perfectly happy with how their salesforce goes about their process. They may not be happy with the actual results sometimes, but they approve of their process.
What sales does and what Agile teams do are exactly the same! They are both working with unpredictable quantities. Developers in an Agile team may not be able to predict exactly what will be the result of any particular release and sometimes not even the result of an iteration, but they can be held accountable to produce a regular flow of high business value software on a regular basis and to be able to demonstrate that the software is actually done on a regular basis as well.
So, if the organization is comfortable with the sales process, they should be equally comfortable with Agile development. In fact, anybody involved in the business side of software development should be very uncomfortable with anything other than Agile development and be actively working to figure out how to get their development process to be more like sales.
This post has only briefly touched on the comparison of software development and sales. If you are interested in a full comparison, please take a look at "Software Developers Can Learn a Lot from Salespeople."
Deep Lean was a 2-day event held at MIT, organized by the New England Agile Bazaar, and sponsored by AccuRev. Speakers included Jeff Sutherland, Nancy Van Schooenderwoert, and Mary & Tom Poppendieck. Here is a quick overview of the weekend.
Day 1
What a great first day at the Agile Bazaar's Deep Lean event. Jeff Sutherland started the ball rolling. All of the speakers were excellent (all weekend) at stopping right at the allotted time.
Broken Development – Jeff Sutherland
First Jeff showed us what a mess traditional development really is. Then he started to show us how Scrum can help. He didn't get through all of his material due to all of the questions from the audience, which was fine because the discussion was riveting.
Thrashing – Mary Poppendieck
According to Mary, even when development teams are doing Agile well, there is almost always one problem remaining: thrashing. Thrashing is when you are spending more and more time to do less and less. She showed us the root causes of thrashing which include excessive context switching. For instance, if you have two tasks and keep switching back and forth between them to show progress to multiple stakeholders, you will actually finish both slower than if you had focused on one and then the other. My favorite part was seeing a video of how the Toyota Type G loom could stop itself when it detected a defect in the fabric it was producing… without modern electronics!
Lean Principles and Scrum – Jeff Sutherland
A very straightforward subject which was well presented. Basically, Scrum overlaps with much of Lean by default and a deeper understanding of Lean will improve your experience with Scrum.
Value Stream Mapping – Mary and Tom Poppendieck
During this talk there was a point at which the audience broke up into teams to try value stream mapping on real world examples. While this was a great idea in concept, I don’t think there was enough time allotted to make it worth it. Considering this was one of the very few (only?) hitches in the whole weekend, I really didn’t mind. Besides, it is well covered in their first book on Lean which you should just go out and buy anyway.
At the end of the last session about 25 of us went to the nearby Cambridge Brewing Company for dinner and conversation. The CBC is a local favorite for the tech crowd and well worth checking out if you are ever in Kendal Square for an hour or more.
Day 2
Coming of Age of an Agile Company - Nancy Van Schooenderwoert
Nancy observed that Agile adoption has a high mortality rate. That is, well intentioned projects start up but then fail. This is a topic that is near and dear to my heart because part of my mission is to help make Agile mainstream. That is, to get Agile to the point that any team anywhere working on any project can pick it up and be successful quickly.
Nancy used a number of (painful) stories to illustrate her points. One of the things that struck me about the circumstances was that there were many problems which had nothing to do with Agile, but rather just plain old good development practices. For instance, don’t use your production environment to test code whose only claim to fame is that it compiles!
Leadership in Software Development – Mary Poppendieck
Mary took us through a fascinating tour of leadership and management styles and methods from the early 1900s to the present day: from Taylor to Charles Allen to Taiichi Ohno to Deming to Kaoru Ishikawa.
Real World Experiences in Creating Agile Companies – Jeff Sutherland
Jeff showed graph after graph on Scrum benefits. The only thing keeping me from being hypnotized by the rapid succession of graphs was Jeff’s take-no-prisoners style. Summary: Scrum works.
Panel Discussion
Lots of great Q&A; too numerous to summarize here.
In summary, this event was a rare treat and if you have the opportunity to attend one of these events in the future, I highly recommend that you go. As both a sponsor and attendee, it was well worth it.
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.
