David Jeske divides the agile principles into high level, individual empowerment, and contract development. He embraces the first two, rejects the third.
David Jeske: Google’s Perspective on Agile
In Why do some developers at strong companies like Google consider Agile development to be nonsense? David Jeske embraces the high level agile principles and divides the remaining principles into those that foster individual empowerment and are suitable for leapfrog products and those more aligned with contract development efforts for a customer external to the organization.
High Level Agile Principles That Are Broadly Applicable
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
It’s interesting to consider when process, tools, and following a plan are preferable. Certainly in situations where predictability is valuable or where the process and plans embody values that are important to an organization.
Individual Empowerment Oriented Principles
Are Appropriate for Leapfrog Products
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- 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.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
These seemed to be clearly aligned with the needs of creative projects where teams are solving problems or developing new designs for the first time. These are also useful for internal change initiatives fostered by intrapreneurs.
Contract Development Oriented Principles Are
Appropriate for Serving External Customers
“However, there are other parts of the principles which are not a part of Google-style development culture. These are the parts which have led to the short-term focused Scrum process. They seem suited to particular types of development, most notably consulting or contract programming, where the customer is external to the organizations, runs the show because they are paying for development, and can change their mind at any time:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 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.
This style of short-term planning, direct customer contact, and continuous iteration is well suited to software with a simple core and lots of customer visible features that are incrementally useful. It is not so well suited to software which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine.”
David Jeske in”Why do some developers at strong companies like Google consider Agile development to be nonsense?“
This analysis crystallized my misgivings with certain aspects of Agile.
- Face to face conversation offers a number of advantage but at some point writing things down is superior.
- Changing requirements: some projects look a lot more like pouring the foundation for a multi-story building than pitching a tent on a campground. The irrevocable commitment of resources implicit in the first case and the way it shapes a range of decisions for at least a decade or three is very different from pulling up stakes and relocating after the first night when you realized you picked the wrong location.
Because most Google software has more of a B2C flavor I can appreciate his description of “very simple interface and tons of hidden internal complexity,” but for B2B software it’s incumbent on the vendor to explain in detail the expected reliability, known shortcomings, and total cost of ownership. There are “unthinkable products” but the customer appreciates their value once their features and cost are outlined.
Related Blog Posts
- Better, Impossible, and Unthinkable Products
- Entrepreneurs Need To See With Newcomer’s Eyes And Ask Stupid Questions
- Nature, Technology and Magic
- Seven Quotes on Learning and Measurement From Marty Neumeier
- Customer Development Helps Entrepreneurs Assess the Value of an Invention
- Deep Roots Are Not Reached By the Frost
- Paul Saffo on Forecasting Innovation in Silicon Valley
Photo Credit “Blue Rapids” by Jozef Jankol; licensed from 123RF Image ID 33655020