I think I agree with the spirit of this post but disagree with some of the details. Or maybe I just need some clarification.

You state that an agile project lasts no more than 30 days – and that in itself is a measure of success. Therein lays my dilemma. Usually in agile development a 30 day sprint or iteration is just one of the many “periods” of development, not the entire cycle. Typical product development using agile methodology uses sprints or iterations that vary in length from 1 week to 30 days, but nowhere does it require completing an entire project in 30 days.

If you refer to solving an internal business problem (that may appear complex) then I would tend to agree with you, although even these situations may require a couple of sprints and cannot be deemed a failure or non agile if they extent to 2-3 sprints or more.

However if you are referring to software product development (since you refer to lines of code), you’re completely off. It’s like saying Excel or SAP or Oracle need to be developed in 30 days.

I have been running Development teams for many years and I have adopted an agile methodology about 8 years ago. Frankly – I will not do anything but agile; as it’s the only way I can ensure success and relevancy. In the last 7 years of practicing agile development I’ve built many successful commercial software products -- not once have I completed a product in 30 days. At best I can probably point out to building a prototype. Every single one of my products runs anywhere from 3 to 9 or n sprints of 30 days each, depending on complexity.

I find no correlation between the number of lines of code a developer writes and the success of the agile methodology. Lines of code are not a good measure of agility. I would argue that testability is a good measure instead. For example building certain functionality may require large libraries with lots of lines of code. Likewise, various development tools produce large amount of code as a byproduct… so every sprint you can have a large net influx of new lines of code. Does that mean one loses agility? Absolutely not! At the end of a sprint, one determines success based on accomplishing or not the goals of the sprint, not the number of lines of code a developer wrote.

The true criteria for successful development using agile is that at the end of the sprint you end up with an operational product, that is testable and has some level of QA, not that the entire system or product is finished within a 30 day sprint.

Agile forces both customer and developer to constantly prioritize the important features up font. That means that as you start the new sprint, you go again through prioritization, requirements, design, etc…

Your description of a “problematic” project is really not representative of an agile development style and bears no correlation to the reality of agile software development. Sometimes developers need to be added to the team based on plan. With agile you figure that out pretty quickly. That’s why you’re agile – you can react quickly to customer/product demand and requirements. Likewise, no one involved in agile development should ever claim that they don’t know what’s going on. That’s what daily scrums are for. Sometimes you do have to work 12 hours day… Development is exciting and that’s just part of it. Every successful product has these crazy experiences and stories as part of it.

One last point, sometimes demos of the system at the end of the sprint do crash and the lead needs to set the proper expectations with the business owners. A crash of the system is a very immature way to consider whether the business problem is in process of being resolved or not, or whether the goals of the sprint were met or not. The business owner needs to see above that. Bugs do happen – let’s not panic about it.

I do agree with you about the simplification paradigm and that the focus should be in finding elegantly simple solutions.

This article makes an excellent point to not over think and over complicate solutions to business problems. One of the concepts that is an oversight in this article is that many times when you involve IT to build a solution (from scratch most of the time) which involves writing code the solution gets more complex than generally is needed.

There is a whole wave of Enterprise Applications that puts the control of building a solution into the hands of the people who need to solve the problem....the business person or unit owner.

These applications allow the business person to automate, measure, enable efficient workflow, and allows them to be able to report every step of the way to ensure the process is being executed as planned and that the problem is truly being solved.

No two businesses are alike and every organization has to approach each problem in a way that best suits their business. Additionally, no two business people are alike and a platform approach to solving business problems is what organizations are moving towards. Business users need to be able to build new solutions on the fly, expand upon current applications/solutions, integrate existing solutions and unify the information silos....with minimal involvement from IT.

The output of solutions should not only solve a business problem it should increase efficiencies along the way. Creating a simple solution to a business is not always the answer, applications should be made in a way to empower the business person and streamline a complex issue so that it is complex in design but not complex in implementation.