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.
Saeed