© 2013 Jeff Sussna, Ingineering.IT
The software industry has been struggling with the topic of requirements for as long as it’s existed. The very mention of the word conjures up painful associations with other words like “incomplete” and “unmet”. Requirements have historically served as a fulcrum for conflict between those with needs and those charged with fulfilling them. Agile practices such as Behavior-Driven Development try to ameliorate this conflict by treating the requirements process as a conversation. BDD conversations still tend to focus on “requirements discovery”; in other words, collaboratively uncovering the development team’s obligations to the customer.
Upon reading the phrase “turn requirements into autonomous promises” in Mark Burgess’ “An Introduction to Promise Theory”, it occurred to me that Promise Theory might offer a way out of the requirements tarpit. Whereas requirements (aka obligations) generate external pressure to conform, promises generate internal pressure to satisfy. Ironically, this difference can make promises more trustworthy than requirements. Requirements discovery asks “what do you need from us?” Promise discovery asks “what can we do for you”? The difference is subtle but I think potentially transformative.
Promise-based software development transforms developers from order-takers to proactive, creative designers. Promises imply a strong motivation to succeed. You generally don’t promise to do something if you don’t care whether or not it happens. It likewise doesn’t make sense to promise something no one else cares about. Promise-driven developers thus will naturally gravitate towards promising things they believe have meaningful customer value. No one wants to burn a lot of time building something useless (especially if doing so makes you unable to keep your promise to build something else that’s more useful).This dynamic will encourage them to validate their beliefs through user-centered design techniques, so they really know what is in fact useful.
Professional designers try to go beyond understanding what customers want in order to create solutions that satisfy their underlying needs. Software development should operate on a similar level. It should do so at a deeper level than just the user interface level. A development team could, for example, promise to be able to add new functionality to an application quickly and easily. In order to make that promise, they also need to make another promise: to keep technical debt under control.
This example illustrates the power of promises in reducing distrust between technical and non-technical stakeholders. When the product owner asks why the development team wants to prioritize technical debt stories, the developers can answer in terms of a chain of promises. Because they created that chain, and linked a higher-order, customer visible promise (ease of modification) to lower-order, technical promise (controlling debt), they can easily explain the importance of one in terms of the other. Developers often struggle to explain technical logic in user-understandable terms. Promise theory can help there. Even better, shared visibility into the promise chain can obviate the need to explain it at all.
Conversely, promises can give customers greater trust in the development team. On the one hand, by the very act of having been promised something, they can sense developers’ desire to provide satisfaction. On the other hand, the tentative nature of promises surfaces the reality that customers’ needs are not always perfectly met. When imperfection does manifest, it’s not a surprise. The difference between “we will implement this feature by next Wednesday” and “we promise to implement this feature by next Wednesday” is subtle, but again potentially transforms the customer-developer relationship.
The nature of promises as statements with varying degrees of trustworthiness can help prepare customers for imperfection, and understand it when it comes. “We told you we weren’t confident we could finish this feature in time” is a common developer response to customer frustration. From the perspective of requirements, this exchange denotes failure. From the perspective of promises, it denotes a known possible outcome. Again, this turn of events accurately represents the real world. No software, even if it completely satisfies every requirement, perfectly meets every customer need. There is always something more to be added. Customers always have to work around some limitation, even if it’s a missing feature that no one could have been expected to foresee. Promises simply make this reality more manifest. Doing so removes some of the intensity that drives the conflict fulcrum.
Promises’ inherent consideration of imperfect outcomes also puts some responsibility for realism back onto the customer. Faced with less than perfectly trustworthy promises, they are obligated (pun intended :-) to make alternative provisions for satisfying critical needs. Doing so makes unkept promises less painful. This relationship applies throughout the customer-developer chain. If a developer estimates a week to build a feature, and the project manager tacks on an extra three days, and the project manager on the receiving end tacks on another three days, both project managers are making promises to their respective customers based on their confidence in the promises being made to them. This situation is perfectly natural.
Software projects are not monolithic, frozen moments in time. They evolve both in completeness and correctness. Promises address projects’ true nature by defining atomic expectations. Promise chains allow for higher-order aggregate promises. Are promise chains really any different from sprints or epics? Are atomic promises really any different from user stories? I believe they are, in a couple of important ways.
Promises are responses to user stories. User stories were originally intended to represent a unit of desired customer value, and to serve as a basis for conversation. Somewhere along the way we forgot this definition and turned them into micro-requirements. A unit of customer value needs a unit of development work to realize it. A promise is…well…a promise to do that work, in a particular way. In fact, “needs” might be a better name for “user stories”.
Promise chains provide more unified and thus flexible ways to represent aggregates such as epics, features, and nonfunctional requirements. A space of higher and lower-order promises can be arranged however one likes to represent different project views in time and space.
The relationship between time and space is perhaps the most important difference between promises and previous requirements management techniques. A promise divorced from time makes no sense. “I promise to implement Feature X” has no meaning. We all know the humorous response to “we’ll get this done by September”, which is “September of which year?”. You can only say “I promise to implement Feature X by next Tuesday”. Whether Tuesday comes and you’re not finished, or you are finished but it doesn’t work as intended, you’ve still failed to keep your promise.
One could object that it’s somehow possible to map the concept of promises to existing agile development techniques. Technically speaking, that might be true. The use of the word “promise”, however, introduces two critical characteristics into the discussion: emotion and uncertainty. Regardless of methodology, software is built by humans, for humans. Humans are emotional creatures. When customers don’t get the results they want, they feel frustration. When developers feel pressured to perform against their own wisdom and experience, they feel humiliation. A truly effective project methodology must account for the emotional dimension of work.
At least at the level of atomic actions, every project is characterized by uncertainty. We wouldn’t measure velocity, for example, if we could be certain we would always attain the planned velocity. We wouldn’t discuss blockers during scrum stand ups if there were no possibility of problems that could derail planned progress. Promises build an understanding of the uncertain nature of development work into the very language of its management. Ironically, acknowledging uncertainty at the atomic level can increase certainty at the higher level. If I understand the ‘algebra of confidence’ in my promise chain, and make arrangements for alternatives where that algebra doesn’t match the criticality of my needs, I can trust that the overall result will provide greater satisfaction and less pain. Since we are in the business of providing value, isn’t that the ultimate measure of success?
There is (at least) one place where Promise Theory and Agile/Lean/Continuous Delivery are in perfect agreement. The larger the granularity of my promises, the lower the confidence with which I can make them. “I promise to feed the cat tonight” is much easier to keep than “I promise to care for the cat”. Promise theory naturally encourages us to reduce batch sizes. We can use promise chains to express larger/longer promises while capturing variances in confidence at different levels of the chain. At the same time, we can keep our attention on the atomic promises of greatest immediate concern. That attention raises the those promises’ trustworthiness. Other promises in the chain can float off in the “definite maybe” background. As additional promises come under the microscope of the present, our new attention to them raises their trustworthiness. Promise chains thus naturally express the concepts behind a backlog.
Remember that promises bind space and time; trust in a promise thus has no meaning except as that promise synchronizes itself with the present moment. A key characteristic of Promise Theory is the ability of trust (and its importance) to vary over time. “I promise to feed the cat on September 1st” is much less trustworthy, and less important, on March 1st than it is on August 31st.
The example of the chain of project managers adding time to estimates made me realize that Scrum has made a fundamental mistake. Scrum uses the metaphor of pigs and chickens. There really is no such thing as a chicken. I may only be a stakeholder in your project. The only reason I’m there, however, is because I’m a pig in some other project. When you treat me as a chicken, you subtly devalue my participation. If anything, it should really be the other way around. With respect to the project in question, pigs have more control. Developers can write code; product owners can only hope that developers keep their promises to write code. Thinking in promises can help balance this relationship. The product owner cares whether the developer keeps their promises because the product owner has made their own promises. The manager who flies in over the project once a month does so because they’ve made their own promises based on yours. If all the players can understand each others’ promises, and the ways those promises’ trustworthiness rely on each other, they can recognize that there are no chickens, only pigs. To express it in the language of Promise Theory, we are all both promisers and promisees, bound together by trust.