Thoughts on Agile (Part 3): the Principles
In my previous post I went over each line of the Agile Manifesto to see if I could find a deeper meaning in the language. To summarize, my general conclusion was that Agile is as much (if not more) about business efficiency than it is about software development, encompassing principles that can be extended to any problem-solving field of industry where rapid response to change is a key aspect of adding value for customers. I also said that I believe it is possible to plan for maximum agility, in a sustainable and predictable way, and that the 12 Agile Principles reinforce this possibility (amongst other things). This time I want to go through each of the Principles one by one and explain my take on them.
Number 1
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Meaning: the customer is king and our top aim is to provide our value for their money.
Note: it does not just say “give the customer what they want”, it specifies the delivery of value in order to satisfy. By extension, what the customer wants may not always be valuable, and what the customer needs may not always be what they want. So be prepared to exercise your creativity and judgement to maximize the value you can provide.
Also, note that this principle emphasises the delivery of valuable software “early” (i.e. before the usual or expected time), and not “immediately”. When done well, the value of software emerges as a manifestation of the components you build, and cannot be forced simply because the sprint deadline is in two weeks. Likewise, you should demonstrate the software you build when ready, and not build your software for the purpose of an arbitrary demonstration. Contrast this with Number 3.
Number 2
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Meaning: change is inevitable, so embrace it and realize that changes to requirements are what keep us gainfully employed. Being able to harness change and leverage the value added by late changes is what makes a process Agile.
Note: a prerequisite for harnessing change is being able to contain it, i.e. ensure that change (even last minute change) does not reverberate throughout your project. Make it a strength of your team to be able to respond to change rapidly and efficiently without incurring medium- or long-term cost.
Number 3
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Meaning: break your project up into manageable deliverables, keep your timescales rapid and focus on meeting your targets. Stretching your timescales out to multiple months, or even years, before you have anything worth delivering is no good for your customers or for your team.
Note: this principle emphasises the delivery of working software “frequently” (i.e. regularly or habitually). In this case, “working” simply means functioning or able to function (i.e. not broken). If your software project is accumulating bugs and cutting corners for the mere sake of expediency, then all you are doing is compounding technical debt. Contrast this with Number 1.
Number 4
Business people and developers must work together daily throughout the project.
Meaning: your team must gel and interact, no one person is above or below helping the team reach its project goals.
Note: it does not state that “developers should listen to business people every day”, it specifically talks about both business and development working together as peers in a two-way conversation. So development must not lose sight of the business needs to be met, and business must have an appreciation of the technical challenges to be overcome. Neither will benefit without co-operation from the other.
Number 5
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Meaning: make sure you hire the right people, give them what they need to do their job well and let them do that job. Do not micro-manage.
Note: understand what you are doing and why, and find good staff who will share your vision and passion. If you give smart people a goal to believe in and they will want to follow you.
Number 6
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Meaning: in our natural state humans are master communicators, and we can convey more understanding in a 20 minute conversation over coffee than we can in a dozen pendulous emails.
Note: efficient and effective communication is about establishing a clear understanding between people. Even if that understanding is wrong, then at least it is better to be wrong than vague. A vague understanding makes it impossible to learn from ones mistakes.
Number 7
Working software is the primary measure of progress.
Meaning: your business will not achieve sustainable success without delivering at least minimum viable quality. Any success in sales will quickly flounder if quality is found to be lacking.
Note: the distinction between “working” and “valuable” was made in Numbers 1 and 3. Here we recognise that software must work before it can even begin to add value. Any perceived value that software may provide will instantly be lost (along with the goodwill and patience of customers) as soon as it breaks!
Number 8
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Meaning: burnout will lead to disenchantment and failure. Regularly grinding your team into the ground is a sign of poor management and/or insufficient resources. If you have to pull out all the stops as part of your standard operating procedures then those procedures are not Agile!
Number 9
Continuous attention to technical excellence and good design enhances agility.
Meaning: agility does not happen by accident, and sustainable agility emerges from high-quality design, technology and development.
Note: this is my favourite Principle because it is the most ignored! The idea that Agile is simply responding to change as fast as possible, without any consideration for the consequences, is alarmingly common. Altering software may be materially simple but it is conceptually complex, especially when considering how a single change in one area of code can have a ripple-effect throughout the system if appropriate checks are not in place. The need to constantly revisit and refactor your code because it was done poorly/haphazardly/”without any real idea what we were doing at the time” could not be considered agile by anyone, but seems depressingly common in many Agile environments.
Number 10
Simplicity - the art of maximizing the amount of work not done - is essential.
Meaning: keep your process lean, and avoid wasting time, resources or money.
Note: since change in inevitable do not resist it, but do be resilient to it. Localised changes that require further work beyond the boundaries of the original problem space are not just wasteful, but also avoidable. Contain and accommodate change with minimal impact in order to achieve maximum agility.
Number 11
The best architectures, requirements, and designs emerge from self-organizing teams.
Meaning: no person is an island in a development environment, regardless whether they are a manager, developer, product owner, business analyst, architect, project manager or stakeholder. Once a team reaches the point where it can no longer self-organize (either because it is too big or too dispersed), then quality of output can only deteriorate. Thus by working together in small, well-connected and efficient teams it is possible to gather the best requirements, create the best designs, plan the best projects and implement the best architectures.
Note: the word “emerge” can mean various things, but in its simplest form it just means “comes out of”. It does not imply anything about the mechanism by which that emergence might happen, and certainly makes no suggestion that it should just occur by magic without any creative effort!
Number 12
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Meaning: record-keeping, coupled with regular feedback, frank honesty, and self-correction, is the essence of a self-organizing team.
Summary
Going back to the question posed at the start of this post: is it possible to plan for maximum agility, in a sustainable and predictable way, and do the Agile Principles reinforce this notion? Well, as the first Agile Principle highlights, the top priority of Agile Development is and has always been to satisfy the customer through early and continuous delivery of valuable software. The other Principles simply highlight key areas on which to focus in order to maximize your team’s agility: customer service, business management, communication and interaction, product quality, feedback and self-improvement.
While both the Manifesto and the Principles are deliberately broad in their advice on being Agile (there can never be a “silver-bullet” solution to solve every problem), there are three Principles that specifically describe what constitutes Agile or agility (2, 8 and 9): they state that, in order to be Agile, a process must be able to add value by harnessing change in a sustainable way, and that this can be augmented with a regard for technical excellence and good design.
I would add to this that the acid test for any degree of agility is being able to assimilate change with minimal overhead, i.e. making an unexpected change to a project should be as simple and safe as pulling a feature request off a sprint backlog. This is also an essential essence of good software design: encapsulating areas of potential change in your software in order to decouple the rest of the system from any impact resulting from those changes. Only with high-quality software design, project planning, technical excellence and a well-integrated team can you be sure to make agility an integral characteristic of your development lifecycle.