« FP… on Using my car as road equipment | Main | FP...on Raindance Meeting/Seminar Edition »



Feed You can follow this conversation by subscribing to the comment feed for this post.


Re Belief #1: I believe this can be mitigated by having a good domain knowledge person, with some technical prowess, actually on the team. The idea being that they act as a proxy for the user. The other thing is that I don't know that this issue is particularly a problem with Agile per se - other methodologies don't cope particularly well either.

Ryan Martens


Agile is not a silver bullet, it is an alternative method to waterfall development. It has just as much discipline and you can achieve CMM level 5 using agile. It has been formulated by leaders in the industry over the last 15 years. (See http://www.AgileAliance.org) It takes Waterfall approaches and turn them upside down by fixing time and resource and estimating scope. By constraining the time box, you focus on delivery, force creative thinking and feedback. By making the batch sizes small, you benefit from the increased throughput and decreased distractions. By empowering the team, you move toward self-directed and higher performance. It’s all good.

I am going to start at the bottom of your list, because I do not think you have the right mental picture of what Agile is.

At the bottom of your post you state, you can not “can” software management or business management.

Agile is a method and not a “canned process.” The practices, norms and specific processes are situationally specific for all software teams. What is common is the belief that software is best done by following the method exposed by the Agile Project Management Network’s (http://www.agileprojectmgt.com/)Declaration of Interdependence (http://pmdoi.org/).

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

By admitting that producing great, continuously innovative, and highly valuable software is dominated by the “Theory of Constraints” (David Andersen’s book on Agile Management (http://www.agilemanagement.net/Articles/Weblog/blog.html) or Goldratt’s book, the Goal and his institute that is applying Theory of Constraits to all aspects of business (http://www.goldratt.com/) and not Critical Path, everything changes.

Good software teams do not often feel the need to change and see many obstacles or issues to moving to agile. Why fix it, if it ain’t broke? (More in Jim Collin’s “Good to Great” http://www.jimcollins.com/lib/books.html on that topic.)

I believe you move to agile to chart a path to high performance, innovation and greatness. There is no reason not to try it! Just have one of your teams jump in. I bet they won't go back.

Pete Behrens


Let me provide a bit more of a practitioners perspective to your posting based on over 15 years of leading product direction, engineering and development process.

#1 - Agile works well when the software team is already close to the domain space – You are correct that increased domain expertise across the team increases development speed. Though I do not believe that lack of domain expertise should lead you away from agile. Quite contrary, I would recommend it would dictate a more agile approach. There are two organizational patterns that I have found successful in assisting a team that does not have deep domain expertise. First, put a domain expert in the team. They can code, or be a business expert, but they are their for every question, issue, conversation, stand up meeting, etc. This will increase your teams knowledge faster than any other method. Second, split off a separate team to understand the domain through early prototyping. This will build domain knowledge and not hinder the entire team.

#2 - Agile works better for Software Companies, then company’s that write software – Implementing agile methods does not require a customer release at every iteration. You choose when releases are available as part of release planning independent of iteration planning. That said, I have worked with a service client with a hosted environment and thousands of live customers that release software every week. You can also change your customers acceptance model if you control the delivery mechanism and build customer trust.

#3 - Agile works for wide projects that aren't very deep – You commented "Bringing stuff together too often makes management happy, but ultimately adds time to the ultimate solution delivery time." A principal concept of agile - only working code provides value to the customer. I would argue that unless you know definitively that your “ultimate delivery” is completely well understood, the incremental deliveries where you bring it together are the only true measure of value to the customer and the best way to measure your accurateness in understanding of the “ultimate delivery”. The cost of extra time at iteration reviews are reaped when your solution meets your customer needs.

#4 – Everyone on the team works on everything, means no one is responsible for anything – I would like to propose that not having team ownership provides an environment for a “not my problem” mentality. I have witnessed many environments where a few on the team were killing to finish part of the system while the others were relatively relaxed. This is a classic delay waste that agile proposes to eliminate. In an agile environment with code sharing, the team takes on a shared responsibility for the delivery of value to the customer.

#5 – Waterfall chart bad, rejigger good – This comment indicates that your teams agility is constrained by business culture and processes. Most of your results will come when you can align the entire organization around agility. Look at Toyota or Dell as examples. They worked with their entire production line, suppliers, resellers – everyone in their value chain – to deliver higher quality and more customization for a better price. To learn more about how this applies to agile development read Lean Software Development by Mary and Tom Poppendieck (See http://www.poppendieck.com).

#6 – Agile works well when the product can comprehensively tested via Unit Tests – You are correct in your analysis that more automated unit and acceptance testing will increases your development speed. The larger and more complex a system, the more critical automated unit and acceptance tests are. That said, I have worked with a service company that delivers a production hosted environment every week (3 days of development, 2 days of test) without unit tests.

#7 - Agile won't work well in political environments - Your premise that engineering decides what gets developed in an agile process is wrong. Agile methods require a strong collaboration between product management and engineering – even more so than more predictive methods. Agile expects a high degree of involvement from marketing and product management.

Dean Leffingwell

I’ve spend my spent my entire career in software practices, in the 80s, as CEO of a software contract business, I supported the waterfall methods practiced during that period and personally led and published advances in requirements management and verification and validation techniques based on these practices. In the late 90s, As SVP of Rational Software, I was responsible for the commercialization of the Rational Unified Process, which is founded on iterative and incremental development, and there I became convinced that these practices were substantial improvements in the state of the art for software development.

More recently, like you, I was initially doubtful that the set of practices, now under the umbrella label of agile methods, would provide a substantial further increase in productivity and quality of the software process. But I didn’t really understand them. Now that I have substantial personal experience with these methods in multiple company settings, including my role as chief methodologist at Rally Software, I have concluded these practices hold the key to a substantial improvement in both speed and quality of application development and they can be applied to good benefit in virtually all application development settings.

I strongly disagree with the beliefs you’ve described in your blog and suspect that they are stem from a fundamental misunderstanding of agility. For a better understanding of real agility, I refer you to the Agile Manifesto (www.agilealliance.org) and I will use these common, underlying principles to discuss some of the beliefs you describe.

Mistaken belief #1: Belief #1: Agile works well when the software team is already close to the domain space:
Agile manifesto principle: Business people and developers must work together daily throughout the project.
In Scrum for example, a product owner is a role defined within the team, so whether the team has domain experience or not, they are obligated to interact daily with the customers and their proxies to assure that they have it. In XP, the customer themselves is often integral to the team environment. Moreover, I’m not sure what software process you would recommend to those teams who do not initially have domain experience, but I can’t imagine that you would conclude that the team doesn’t need to employ a model that assures that they are responsible for getting it!

Mistaken belief #2 - Belief #6: Agile works well when the product can comprehensively tested via Unit Tests.
Agile manifesto principle: Working software is the primary measure of progress.
While there is certainly a focus on unit tests in agile methods, as most experienced practitioners will tell you that there is substantial bang for the buck in this practice, the underlying principle simply states that the objective is to deliver working software, as opposed to plans, design documents, and software requirements specifications and the like. Test it as you will, but test it you must, and early and often.

I won’t take the time here to further debate your beliefs, but instead refer you and your readers to for a more comprehensive discussion of the true nature of agility and how these practices benefit companies building software in all shapes and sizes. This whitepaper can be found at: http://www.rallydev.com/white_paper_download.jsp


I agree with your scepticism. Was hoping someone would step up and debate your beliefs, but nobody really offered more than slogans and cliches.

My impression is that Agile is only accepted in a very small niche of the software world and not much by serious software practioners who use software as a component, because most of your concerns are widely shared.

The principles of Agile--value people over process, results over documents, flexibility over plans, etc. (paraphrasing) are attractive. And I am always interested in anything that can help in the swamp of creating quality software.

A lot of the practices are effective. Sometimes. With some people. On some projects. But they are not new. From unit testing to pair programming these are old ideas. And not all should be applied always.

Worse is the wave of Agile tools and companies (apologies to your other posters who are invested and employed there). But they will vehemently deny that they fix a process or toolset, even as they outline the six steps you need to take, the three forms you need to use, the duration and size of your meetings.

Worse yet, the idea of trusting the individual and providing the environment to get the job done seems to be lost. Ideally the team could say, "we reject this Agile stuff." The sellers of Agile say that this sort of rebellion must be crushed by management directives and "committment to Agile methods."

Putting the Agile ideas into practice has created some pretty bizarre misinterpretations. One of the previous posters even states that "only working code provides value to the customer." That strikes me as not only wrong buut offensive to developers--value to the customer is provided by breaking the code and adding features. If you manage to that, you would conclude that only airplanes parked at the gate provide value to passengers. All that flying around just wastes fuel and dirties up the cabin.

Reminds me of expert systems--cool ideas until someone tried to make it a product.

The comments to this entry are closed.

Lijit Ad Network