Ok, Im asking for it with this post. A lot of people who I respect profess the miracles of Agile development methodologies. Some have investments in Agile companies, others are entrepreneurs in Agile Software Tools companies, still others are guys I have worked with and known for over 10 years. But, I confess, I have problems seeing the light. And since I know only enough to be dangerous, this sounded like the perfect post on falseprecision.com..
As a backgrounder, I have worked within several different ‘company models’. These include 4 guys starting a company, 250 guys in a public company, 300 guys in a private consulting company, and thousands in an aerospace company. However, I think my best vantage point is the 4 guys starting a company, and the 250 person public company, and more specifically the transformation from one to the other. So, most of my “old man” beliefs will come from those vantage points.
Todd's Beliefs about Agile....
Belief #1: Agile works well when the software team is already close to the domain space:
As I understand it Agile empowers software engineers to make product decisions during the development cycle that will make the product better. This is accomplished by the team being immersed in the problem domain and translating the knowledge into code, features, etc. My experience is that this works well when the problem domain is software engineering or something closely related to software engineering. It works less well when the problem domain is fairly obtuse. The example, writing development tools vs an aircraft flight control system. It becomes prohibitive when the entire team needs to learn things not easily understood. A good friend of mine says my interpretation is incorrect and only a good product person needs the domain knowledge. I am still struggling to rationalize this with in-depth knowledge of the domain space..
Belief #2: Agile works better for Software Companies, then company’s that write software.
As the actual software becomes a smaller part of the solution, Agile becomes less easy to adopt. Raindance was actually a pretty good example of this. When we were small, had a handful of customers, no marketing, and a release was just something we did when we had something new. We would do releases every week. This wasn’t because we were anymore in-touch with our customers (we weren’t). In fact it was because we were just releasing software. We had no users, no agents, no resellers, no-one using it as 24x7 disaster recovery communications, no SLA’s. Now, our software is part of a solution, one that people use all the time. We actually have to promise our customers NOT to give them something new more then once a quarter.
Belief #3: Agile works for wide projects that aren't very deep:
Iterative development in general is a good idea, you know you have something rather then a bowl of mush. Bubbling this up to the project level takes more time then its worth when a deliverable does not have obvious impact on the product. Wide projects such as ASP web sites that are collections of servlets are pretty low complexity and it’s easy to make a new visible feature. I believe this kind of project lends itself well to Agile. Complex projects where small increments of work can only be demonstrated by unit test are less easy to combine into meaningful releases. Bringing stuff together too often makes management happy, but ultimately adds time to the ultimate solution delivery time. This vantage point is based on having a very mature development team, I would concede this point with more Jr. teams.
Belief #4: Everyone on the team works on everything, means no one is responsible for anything:
I have never had good success with projects where everyone works on all the code. Code is both art and science. Unless you let developers run with a problem they don’t feel attached to the project and the art-part gets lost. I didn’t just say that everyone is isolated, in an ideal situation everyone ‘can’ work on all of it, they just don’t usually. A great Raindance example; A major performance component of our system is something we call a Media Switch. It’s essentially a application layer xml packet router. The guys working on this absolutely buried himself in NIO, NBIO, SEDA and any other non-blocking IO schemes to deliver critical results. He worked on other things, but at the end of the day he knew it was up to him make the project work. It was both stressful and rewarding for him and Raindance got the best possible result.
Belief #5: Waterfall chart bad, rejigger good.
If your company is engineering centric and deployment is trivial then you can perhaps avoid the Waterfall chart world. However when a release (even if its only gui button) shockwaves through your customer base, partners, etc.. Your going to have a waterfall chart.. And if one part of the company is running by one, then its pretty hard to mesh your iterative releases into the only release the rest of the world cares about, the revenue generating one.. the world runs by a calendar, get over it.
Belief #6: Agile works well when the product can comprehensively tested via Unit Tests.
The more complex a system, the more difficult it is to trust that the ‘whole’ will function correctly based on the sum of the parts. Granted, you can construct unit tests all the way up to the entire system, but eventually it becomes prohibitively expensive to do that. The more complex the solution is the more likely the QA cycle has humans in the loop, and more likely it is to blow your iteration.
Belief #7: Agile won't work for "political environments".
My experience is the world is a political environment. From the company’s perspective the last thing it wants is the software engineering team deciding what features and functionality go into the product next. The sales and marketing teams are responsible for the lead engines and closing sales. Without these people being largely responsible for the product definition, it will be next to impossible to judge either sales or marketing performance. Any environment generating a lot of revenue is a political environment.
Ultimately I believe the title of Brad’s post title the most. Agile is mostly common sense. Who can argue with smaller releases that happen more often. My point is you can’t “can” software management, just like you can’t “can” business management.