How we got here, part 3
We follow these principles:
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.
Agile is a mindset, not a process or work pattern. It's a set of guidelines on what to favor, not a roadmap of how to execute. And, thanks to English, it's ambiguous and imprecise.
Here's an example of a mindset:
When taking your ship out of port, avoid hitting other ships or running aground on sandbars.
Don't go out to sea in a hurricane.
Great advice, right? But what if your ship has a hole in the hull and is in danger of sinking? You'd probably want to run straight for that sandbar to ground it rather than letting it flounder in deep water. Or what if your ship's purpose is to defend the port and an enemy warship is heading this way? If all else fails, ramming that enemy ship might be a good idea.
This is the difference between Guidelines and Procedures. Agile isn't a procedure - it's a set of generally good ideas which, in most cases, keep us on track to do well. But it has some glaring flaws, notably:
6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
At best, this is partially true. We all played the Telephone Game in kindergarten - where one person whispered something to the person on their left and it went around the room and "William Shakespeare" became "Squeaky Noodle". Mind you, every single interaction between individuals in that room were "face to face conversations" and yet the message got horribly garbled. Unmanaged conversations are a bad thing, particularly when the communication partners don't natively speak the same language, or they use email or other horrible practices.
Moreover, there's far too much ambiguity. In number 9, what constitutes "good" design? 11 - what's a "self-organizing" team? One that ignores HR's predefined job descriptions? Likewise, if team A figures out a way to do something FAR better than team B, should we let B continue to "self-organize" their way to inefficiency? I think not.
There are also a great many things omitted by this list. How are designs communicated? When are we ready to actually write code? What is the definition of a bug and how can we code solutions so they don't exist in the first place?
How can we be sure we're meeting the customer's needs, especially if the customer can't express what those are?
We can and must do better than this.