A 5th element for the Agile Manifesto

Robert Martin gave a keynote at the Agile 2008 conference. Entitled Quintessence, he talked about adding a 5th element to the Agile Manifesto. His suggestion was:

Craftsmanship over Crap

After discussion and thought, he later proposed a refined version:

Craftsmanship over Execution

This is meant to focus developers on writing good code vs. simply writing code that works. Both craftsmanship and execution are good things, but taking care to write good code is viewed as more important.

The attitude is described in the Principles behind the Agile Manifesto, but is not explicitly listed as one of the elements of the Manifesto itself.

Continuous attention to technical excellence and good design enhances agility.

But few people seem to think about those principles explicitly. The focus of many agilists is specifically on the 4 elements of the Manifesto itself.

But, is this really a principle that needs to be enshrined in the Manifesto? Shouldn’t everyone (ideally) take care of the details and be diligent in their jobs?

In my opinion, looking at the the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I don’t think it’s sufficient to be added to the list. Don’t get me wrong, I agree with the call for people to do good work, but to me that should be a given. The beauty of the manifesto is that it is concise. Each element is clearly distinct from the others and espouses a different aspect for the profession: people, code, customers and agility.

What’s missing from the Manifesto?
But there is something that is missing from the Manifesto. Most software is written for business purposes. It could be an internal IT team or an ISV, or part of some other technical product that will be brought to market. This context needs to be in the mind of development and QA teams as they produce and test code. And as they make decisions on what to do and when, they need to decide if it is important for the business or not. And if they don’t know whether something is important, they need to know enough to ask.

I propose the following as the 5th element of the Agile Manifesto:

Business alignment over engineering efficiency

Why? Because as trade-offs are made, as test cases are created, and bugs and issues are prioritized, the overall business context must be kept in mind.

No set of requirements will provide every constraint that needs to be taken into account. No set of user stories will be perfect, regardless of how intimate the Product Owner is with customer and market needs. No individual can tell the testers the best combination of tests that need to be run.

The focus of Agile is on “individuals and interactions”, and those individuals need to be empowered to make appropriate decisions. But, without the proper business context, they will not be able to optimize what they do.

Have you ever had software that couldn’t install properly? Or had licensing problems? Or found certain design decisions prevented the product from easily being OEMed by partners? Or had APIs in the product that were only usable by the developers who wrote those APIs? Or had user interfaces (radio buttons, check boxes, drop downs etc.) that functioned more like a developer’s logic path than a user’s intended workflow? These are are all cases where the business context was not kept in mind.

I once saw the following happen with a software product. A customer had purchased the product and licensed some modules. When they installed the product, the license keys for at least one module didn’t work. The module’s functionality couldn’t be enabled. The Support team identified it as a bug in the licensing functionality and escalated it to Product Management.

The PM went to the head of QA to find out more about the problem. The conversation went something like this:

PM: Hey, just wanted to confirm whether this bug with licensing is really a bug?

QA: Yes it’s a bug.

PM: Then it’s a regression right, because I know the licensing worked in the previous release.

QA: Yes, it’s a regression.

PM: So, how did we miss this? Who tested the licensing?

QA: [Looking at the PM more intently] No one tested licensing.

PM: Uhhh…what do you mean by “No one tested licensing.”

QA: Licensing wasn’t tested because there were no licensing changes between releases. We have to prioritize the work we do. We can’t test everything. What do you expect? Zero bugs? That’s never going to happen.

PM: Agreed, you can’t test everything. And I don’t expect zero bugs? What do I expect is zero surprises and licensing that actually works. Licensing is how we make money. It has to work or there is no business.

QA: Look, there will be a patch out tomorrow. And as I said, we can’t test everything. We didn’t test licensing. And I’ll tell you, if my boss was here right now, he’d support me in my decision.

PM: I have my doubts about that.

It turned out (thankfully) that the QA Manager’s boss didn’t agree with him. But, the QA head was not a junior guy. He’d worked in software for about 10 years. Yet he didn’t understand how important licensing was to the business. From his perspective, it was no different than any other “feature”.

I’ve seen this kind of thing many times from Engineering teams. It’s not just applicable to licensing. For example, when they promote the creation of SDKs and APIs when end-user functionality is what is required, or advocate for “rearchitecture” or “refactoring of code”, when neither provides any clear business benefit.

This kind of thinking has to be rooted out of the culture of software development. Other groups such as sales and marketing, albeit because they are close to the business side of things, better understand how to prioritize business needs. Software development needs to line itself up as well

We want efficient engineering teams. They should not be wasting cycles on non-productive work or work that has little value. But, that drive towards efficiency, velocity and productivity cannot be blind to the priorities and needs of the business. Those business priorities must be incorporated into the day-to-day decision making that takes place in a product development cycle.

When all teams in the company from Product Management, Sales, Marketing, Operations AND Engineering understand and embody the needs of the business, as often happens in the tightly-knit teams of a startup, the business can truly deliver on it’s promise and potential.

Do you agree/disagree? Would love to hear from you.



14 responses to “A 5th element for the Agile Manifesto

  1. The 5th element you propose is contained (from how I understand it) in this Agile principle: “Business people and developers must work together daily throughout the project.”, and I also think it can be filed under “Customer collaboration over contract negotiation” element of the Agile manifesto.

    Other than that, it seems that the communication and cooperation between different groups from your example definitely should be improved. It is unfortunately not a lonely case, I have also witnessed similar problems before.

    The misunderstandings go both ways.

    I can illustrate with your example – when engineering teams “promote the creation of SDKs and APIs when end-user functionality is what is required, or advocate for “rearchitecture” or “refactoring of code”, when neither provides any clear business benefit.”

    Engineers do know what the value of the changes they propose is, and it is a real value to everyone, but maybe they do not present it in a clear enough way to the business people. I think that is the problem, the value IS THERE, but the communication is not adequate, or the values are not presented in ways that produce those “Ah-ha!” moments when everyone gets the essence of the explanation.

  2. The iterative approach to agile is often supported by use of automated systems and it strikes me that the above licensing issue is a case that could have been prevented by extensive unit tests and test automation systems.

    The QA in the example is not to be blamed here. They will have had to perform a risk management and it is common that areas that have had no code changes are not deemed as risky as areas that have, unless there is prior history of instability – in which case, someone would need to be made aware of it. If the developers were coding in a clean manner, and unit testing, then there should not have been any builds reaching the QA department that broke pre-existing, and supposedly untouched, functionality.

    So to prevent this problem, both Robin Martin’s rule and your own were needed: Use good coding practises and ensure that the customer needs are known on every level of the company.
    As the poster above me said, the customer collaboration part of the manifesto does seem to cover your point already.

  3. Perhaps this business vs execution issue is the reason why roadmapping is a favorite topic for product managers. Most agile development systems seem optimized for developers but not for the business. It’s not that business-oriented product managers cannot talk to technology-oriented developers; it’s that some developers are praying to the shrine of technical excellence and ignoring the impact of their decisions on revenue and profit.

    I’ve long been a believer in “we’ll serve no code before its time” but I’ve also organized work so I can deliver something that has real business impact. I’d rather ship 100% of something than 70% of everything.

    And yes, some agilists and their product managers need to look beyond the manifesto to its 12 principles. That’s where the meat is.

  4. Jelena,

    Thanks for the comment. The principle “Business people and developers must work together daily throughout the project.”, is necessary, but it is not sufficient. First, I actually don’t think it is truly attainable…Software development needs interaction from the business side of things, but I’ve yet to see a shop were that interaction is everyday.

    Even with this principle, it doesn’t abstain the development teams from needing to understand the business implications of decisions. It’s no wonder that Engineering departments have been accused of living in ivory towers. They are part of a business, like every other business function and need to be aware of the realities of that association.

    This is why this principle needs to be elevated into the Manifesto. I give the writers credit for their brevity, but given that the Manifesto is a call for change in the software development community, one area the Manifesto doesn’t cover is the relationship between business and engineering. Once Engineering teams adopt and understand that, the real sea change in their profession will occur.


  5. Melody-Jane,

    You are right, automated testing would have solved the problem, but the lack of automation is not a reason to ignore testing licensing.

    You state that the QA is not to blame, as they made their decision based on risk assessment. And that is the correct approach from a purely technical point of view. But that is exactly why this new element is needed. They cannot simply work from a technical perspective. They need to look at things from the business perspective. Licensing is core to a software business. It is not simply a feature. It MUST work and it MUST be tested. The licensing example is simply one specific case for the need for a more business oriented focus. The priorities and needs of the business, not simply the technology must be part of the decision matrix.

    And until it is explicitly expressed in something like the Agile Manifesto, it will remain a gap that needs to be addressed.


  6. Steve,

    Roadmapping seems to be an issue for many agilists. I wrote about it here,


    Really there is no conflict, but I can’t tell you how many times I’ve heard proponents of Agile argue that creating a product roadmap is useless in an Agile dev culture because “the requirements backlog is constantly changing”.

    This comes from a lack of a understanding of the business context they work in. Businesses care about releases. They don’t care about iterations or sprints. Yet, I’ve heard developers state far too many times, that given the code can ship at the end of every iteration (let’s just assume that is true), why do we need long release cycles. Again, this is a lack of the business context.

    In the end, every employee in a company should have enough understanding of the business and it’s objectives to make more informed decisions in their jobs. This is true for sales, marketing, finance, product management and, yes, engineering.

    We need informed, educated professionals who deliver value add in what they do, not a bunch of technologists who are oblivious to the business they are in.


  7. Pingback: Product Management Reader: 13Nov08 | The Productologist: Exploring the Depths of Product Management

  8. The war between developers and product management continues. It is the product manager’s position in life to have been a developer who is now focused on business priorities. When I go to networking functions, I run into younger developers, who participated in the open software movement, or Agile, or was it just graduating from the university when they did, that want nothing to do with money. Where the heck did that come from? So don’t expect developers to get with the program. Most of them just want to create. They don’t seem to think about where their paychecks come from. Oh, I forgot! The payroll comes from the VCs.


  9. David,

    People do have different frames of reference, and that’s why the Manifesto is a good thing for the development community. It is a call for a change in attitude and culture amongst software development professionals.

    For those building commercial software — even open source products — they need to understand that they are a part of a business. For example, SugarCRM is an open-source CRM product. But it is part of a for-profit business. It competes with commercial closed-source CRM products.

    As long as developers are working on commercial software, they need to join the rest of the company and ensure they are aligned with the business objectives. Now every developer doesn’t have to be a business pro, but those in management — development managers, QA managers etc — should be mature enough to understand what the objectives of the business are and why not everything can be handled as purely a technical decision.

    The licensing example I provided was simply one of several instances I’ve seen over the years where technical decisions were made without understanding the business implications of them. At minimum they raise support cases, but can also cause business loss. Imagine the impression on the company that purchased the software. If they can’t actually even get the software license working, what could that imply about other parts of the product? Perhaps they should reconsider their purchase. It’s something that would run through my mind if I bought software that didn’t install or couldn’t manage licensing properly.

    The Manifesto is helping change the culture of software development for the better. This issue of business alignment is one area where it could make the change more impactful.


  10. Your amusing exchange between PM and QA made me wonder if PM need to move away from priority (high medium low) and work on ranking so that everyone is aware what is most important all the time. There needs to be rank within the release but also in the product. This will help the “About Us” ranked #4 in the release not getting priority over licensing ranked #1 in the product.

  11. Stewart,

    What you’re suggesting may work, but I think a lot of stuff that “product” would boil down to a “no regression in major product areas” or something like that.

    I look at it this way. The requirements documents basically focus on what’s new or different from the last release. Everything else should continue to work as defined or designed in previous releases.

    Obvious things like the installer and licensing should not need to be specified unless there are changes in those areas. If PMs need to specify that, then what else do they need to specify? The Dev/QA people are technical professionals, not automatons who will only do what is told of them.

    But the culture of development is far too skewed towards technical expediency and that has to change.


  12. Pingback: Happy (belated) birthday to us (again)! « On Product Management

  13. “Business alignment over engineering efficiency” is a goal of product management, not development. IMO, I want developers and engineers laser-focused on engineering efficencies, quality and other issues that they live & breathe. PMs need to ensure business alignment, requirements, priorities, etc. which is why we need a Product Manager’s Agile Manifesto. But hey, that’s just me …

    • Mark,

      Thanks for the comment. While I agree that the “Business alignment” rule applies to Product Management in general, in the context of decision making, and in light of the examples I gave, it is also something that Development needs to understand as well.

      As I wrote in the article:

      “We want efficient engineering teams. They should not be wasting cycles on non-productive work or work that has little value. But, that drive towards efficiency, velocity and productivity cannot be blind to the priorities and needs of the business. Those business priorities must be incorporated into the day-to-day decision making that takes place in a product development cycle.”