Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

I’m not Attacking the Agile Manifesto Principles, I’m begging for Improvement

In 2001, following were a great set of principles for a Software Development team.

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Today I think some of them needs to be re-looked at for the following reasons:

  • Nature of Business: Internet has changed the face of businesses across the world. E-Commerce is an integral part of every business model today. Most businesses are going global, driven by the global demand and open economies.
  • Distributed Development: The world is more connected but at the same time more distributed than ever. Distributed Development is no longer a cost-saving scheme. Its become a necessity to take advantage of the global economy and un-even distribution of talent.
  • To think about it, Software Delivery is no longer the biggest bottleneck
  • Tools and Technologies have come a long way in the last decade. Esp. if you look at one aspect about Software development, .i.e. ability to quickly build and deploy software, its extremely simple and fast today. Tools like Google App Engine; Content Management System like Drupal, Django, CMS Made Simple; Light Web Frameworks like Rails, Grails, Cake, Seaside, Lift + Services like Heroku, Amazon EC2, Engine Yard Cloud. These clubbed with Social Networking Platforms, makes it trivial to get, if not thousands, at least hunders of impressions everyday.
  • In the Web 2.0 and Mobile space, companies are investing a lot of effort to building platforms over building apps. Building platforms and exposing APIs for others to build Applications is a quite a different ballgame.
  • There has been an explosion of the programming language and frameworks in the last decade.
  • And so on

Personally I would like to change/update the following principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

To think about it, Software is just a means, not an end in itself. Enabling and empowering the users and businesses is more important. Quite often we find development teams building a lot of wonderful software, which might even seem useful, but rarely does it truly enable the users. So I would rather have a principle which states very clearly that enabling and empowering the users & business is more important than building software. In fact, lot of times, I believe the best way to enable users and businesses is to provide them with little or no software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The whole notion of requirements seems so 20th century-ish. Requirements have a “mandatory” connotation. Agile is about collaboration and co-evolution of users needs. Also this principle feels more geared towards services or in-house IT shops. For product companies this is given. IMHO the spirit of this principle is that we should acknowledge and work towards letting the software evolve. Better the collaboration and feedback, better will the software evolve to being more meaningful.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

With the technology we have today, companies are deploying software multiple times a day. People are talking about Continuous Deployment, Perpetual Betas and so on. Yet, there are companies in the embedded software space (consider chips being embedded in your brain or software controlling your car) where deploying has a very different meaning and risk.  I like the spirit of this principle, but I see way too many companies delivering working software which does not result in any feedback. Which does not result in any inspect and adapt. I feel they are missing the point and the principle needs to explicitly state that its the feedback and inspect-n-adapt that is important, not the dumb delivering part.

Business people and developers must work together daily throughout the project.

As I understand the objetive of this principle is that business people and the developers collaborate, they understand each other’s point of view, they have more visibility into the decision making process, to help build the trust and respect, and so on. Personally I feel drawing a line and saying these are the business people and those are the developers rather creates the anti-collaboration pattern (at least sometimes). It also leads to “not-my-problem” attitude. I feel eating your own dog food, in some cases, is a very powerful technique. I guess these days I’m more and more leaning towards not differentiating between business and development. Those are 2 perpectives, that everyone on the team needs to have. Some will have more of  one and less of the other.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I completely agree with this. However, IMHO a lot of companies just pay lip-service to this. Even if they manage to hire motivated individuals, within no time they converte them into Zombies. Companies fail to understand what motivates individuals. Motivation is not a “thing” that can be achieved by claiming we are going Agile or declaring the team is self-organized. Different things motivate different individuals at different points in time. IMHO, one of the most important things for individuals is to have a sense of growth & learning. Having a sense of ownership and control. This really is about organizational cultural change. Quite a few start-up companies have the hunger and passion for success, to achieve something. You’ll find real motivation in these places.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

While I believe in face-to-face communication, I would not say its the most efficient and effective method to convey information in all contexts. There have been many cases when I could have chosen f-2-f discussions, but I choose to collaborate over the wiki. Sometimes discussions can be too fast for me to catch up or too slow to be patient. Sometimes one needs the space to think and research. Sometimes language can be a barrier to communicate. Open source projects don’t do f-2-f communication, they still seem to collaborate on extremely complex projects. There are times when f-2-f is extremely important and times when its not. There is simply no “the best”.

Working software is the primary measure of progress.

I would say enabling and empowering customers is the primary measure of progress. Sometimes we can make progress without creating any software. And sometimes getting rid of software helps us going faster. For ex: Lot of teams get zapped with Agile Project Management tools. You replace it with index cards on a wall and they progress much faster.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

To maintain a constant pace indefinitely is not sustainable. Let it be running, exercise or software development. Software development is a creative, problem solving, highly collaborative activity. Its not clear to me how to maintain a constant pace. As humans, esp. Software artists, we are not productive linearly. There are times when we are ultra productive and there are times when we have no idea what we are doing. I’m not questioning the need for Sustainable Pace. The interpretation of sustainable pace is very questionable. People dumb it down to a very mundane, clocking x hrs per week makes something sustainable. I think there is lot more to sustainable pace. I’ve worked on lots of projects were we have clocked more than x hrs every day and were able to sustain it for at least a few months. Looking back, I’m very happy I did. I would argue that if you enjoy doing something and truly believe in it, sustainable pace automatically falls in place.

Continuous attention to technical excellence and good design enhances agility.

As much I would love to agree with this, when I look around that the software that I happily use, they force me to disagree. Certainly technical excellence and good design is important, but there is a trade-off and its important to learn where to draw the line. Alas this is not easy. However these days building software is very cheap and one can afford to throw away working software more rapidly. In some context its cheaper to throw away software and rewrite it than to slowly, carefully, refactor it.

On a slightly different, but related note, a lot of people say Technical Debt is evil and one should stive to have Zero debt. This dogmatic statement clearly shows lack of business accumen. Short-term, low interest debts can be very effectively used to one’s advantage.

Simplicity–the art of maximizing the amount of work not done–is essential.

This is indisputable. Simplicity, simplicity, simplicity. I’m all for simplicity. If we can solve a problem without writing any software, that’s true simplicity. These days I have a habit of asking, “Do we really need any software? Can’t we do without? If we really need software, can we reuse something that’s already out there?”.

The best architectures, requirements, and designs emerge from self-organizing teams.

Software development is a co-evolutionary process, so there is no doubt that good architecture and design will evolve and exhibit an emergent behavior. Certainly a team who owns the software, cares about it and is passionate about it, will really help in the evolution.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I love the spirit of this. Inspect and adapt is important. But be aware of retrospective coherence & premature convergence. Also its important to understand my regular is not your regular. For teams which are doing iterations and sprints, may be end of the time-box is a regular interval. For some its too late. And for some who don’t do time-boxes, what is regular? What we certainly don’t want is more episodic ceremony. When something important happens, why wait? Why not tackle things as and when they occur. Even if we don’t resolve the issue, it’s worth at least a quick discussion. May be we practice “5 Whys”.

Conclusion: These principles were a great starting point. Today, one needs to evaluate them in their current context and see how this maps to them based  on the points I’ve highlighted.

  • HackerChick

    Awesome, you've done a great job capturing some of the recurring challenges with agile and I think that if we are to be agile then we need to continually inspect & adapt to improve what agile means.

    Where can I sign? :)

  • http://twitter.com/saurabhbanerjee Saurabh Banerjee

    Great article Naresh! The publication of the Agile Manifesto is perhaps the single most important event in the world of software development. Rarely did we witness so much debate and discussion on this topic prior to the Agile Manifesto. These days I tend to think that we are over emphasizing the role of “process”. We need to shift our focus more on “what we develop” and how it adds value to the business. Everything else is secondary.

  • Manoj

    Naresh, unfortunately there is still a huge gap between the engineering and business folks when it comes to transforming to an agile mindset. The revision you are proposing makes manifesto principles slightly more alligned with the business…in particular the enablement and feedback issue you have highlighted. By definition, the “principles” themselves should be “agile” and “evolving”, but i expect business to also engage and drive this evolution and not just the engineering.

  • http://www.abhiesa.com/ Abhishek

    Simple Truth. Its amazing, how frequently the methodologies changes. Now, we need something which can adapt itself with future.

  • http://www.davenicolette.net/agile Dave Nicolette

    I agree that the time has come to revisit the principles. Can we dig even deeper than the suggestions you make here?

    For instance, consider “satisfy the customer.” Can we question the implied segregation between a “customer” and a “supplier?” Maybe what we really need is to re-think organizational structure.

    Consider “changing requirements.” The Manifesto already dances around the edges of the question of whether anyone can “know” what is required in advance. Can we question this more deeply? There are other ideas out there that may serve the purpose better, depending on context. A couple of examples: Capabilities-Based Planning and Real Options. This begs the questions of managing an “IT portfolio”, budgeting IT activities on a cost-center basis, and running discrete “projects.” IMO there are many opportunities for improvement in this general area. The notion of “requirements” contains unstated assumptions. Let's identify and question those assumptions.

    Consider “the team reflects” (etc.). There are practical tools to help teams and organizations with this practice that were not mentioned in the Manifesto, such as the Five Focusing Steps of the Theory of Constraints. Such tools offer concrete methods to implement this principle, taking it out of the realm of magic or blind luck.

    When you say “this is indisuputable,” is it really? What if through further technological advances it becomes cost-effective to develop five or six possible solutions to a problem and then throw away all but one of them? Maximizing the amount of work not done would lead us to choose the solution before building the candidates. That's certainly realistic as of today…what what might tomorrow bring?

    Since we're questioning things, why should we assume tweaking the Manifesto is the right thing to do? Maybe agile itself has by now served its purpose and is no longer necessary. Maybe it's time to define the next step beyond agile.

  • tobiasmayer

    Naresh, you make some great points, but the fact you feel the need to make them concerns me. Are there really people who are taking these principles word-for-word literally as if they have been carved on tablets of stone and handed down from Mount Sinai? I sincerely hope not.

    Surely it is the spirit of these ideas we care about. I don't think I've paid close attention to these principles since first reading them in 2003. But I got it: work differently, remove ego, listen, collaborate, emerge solutions, keep it simple, have fun, seek to improve, stop doing stupid stuff.

    The Agile Manifesto & Principles were a wake-up call to our industry. I wish people would just leave this historic document alone and treat it exactly for what it is: historical. We don't need an encoded set of rules to tell us what to do, we need concepts, ideas, vision. We need continuous dialog.

    Please let's not make the Agile Principles a hand-off document!

  • http://twitter.com/ipreuss Ilja Preuß

    Or maybe Agile isn't a step defined by the Manifesto. Perhaps it's a movement that was initiated by the Manifesto; or a community that was seeded by the Manifesto, and that continues to reshape the world of software development, and itself, guided by common values.

  • http://twitter.com/ipreuss Ilja Preuß

    Hi Naresh, a lot of good points. I'm not convinced that therefore the Manifesto needs to be changed, though – I'm very much with Tobias on this.

    “When something important happens, why wait? Why not tackle things as and when they occur. Even if we don’t resolve the issue, it’s worth at least a quick discussion.”

    I don't think retrospectives where ever meant to replace just-in-time problem solving. Instead, they provide a check point, an opportunity to share stories and discover things that we simply don't see if we don't stop for a moment and take the time to take a deeper look. Going to a mechanic when you hear a strange voice while driving your car doesn't replace the regular maintenance check, and vice versa. See http://iljapreuss.blogspot.com/2009/09/schedule

  • mikesutton

    Personally I think this blog is ahead of its time. I cannot expect less from Naresh.

    But!

    Let us first try and achieve the principles as widely as possible before deciding they need to change.

    Fundamentally the words on the manifesto communicate an intent, a mindset and an approach – those who simply act on the literal words are already lost – and no amount of 'improvement' will do. Those who really get that agile is about collaboration, changing the entire system (of which software delivery is only a part) do not need new words to understand the context.

    We should inspect and adapt – I totally agree. The manifesto words didn't start off perfectly and do need updating (with all due respect to the crafters – its not entirely a timeless piece). But we are not there yet.

  • Rahul Agrawal

    One message that I see surfacing again and again in various forms is : “We need to shift our focus more on “what we develop” and how it adds value to the business. Everything else is secondary.”

    Imagine if I blindly follow the best practice , process or whatever metaphor we call it, but if that does not add value to the business, then either my understanding/implementation of that metaphor is not correct or the metaphor needs to be re looked. It is also possible that both cases are true.

  • Rahul Agrawal

    One message that I see surfacing again and again in various forms is : “We need to shift our focus more on “what we develop” and how it adds value to the business. Everything else is secondary.”

    Imagine if I blindly follow the best practice , process or whatever metaphor we call it, but if that does not add value to the business, then either my understanding/implementation of that metaphor is not correct or the metaphor needs to be re looked. It is also possible that both cases are true.


    Licensed under
Creative Commons License