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.