Change is a reality of our businesses and our customer’s businesses. Without change, there would be no need to purchase new software. Yet many teams seem to both resist and embrace change at the same time. They embrace change because change leads to demand for new software products. And they resist change because it makes it harder to create new software products.
Compare and Contrast
I was reading a great high-level description of Scrum by Kelly Waters at the all about agile blog. He describes scrum as eight steps that make a great deal of sense. We can make the list even shorter to illustrate our points here, but his list explains Scrum better.
- Decide what needs to be done.
- Do the most important things first.
- Release the product incrementally as you complete items.
- Re-evaluate and repeat.
This can be considered a dramatic oversimplification of all incremental delivery processes. We can contrast it with an oversimplified description of waterfall processes.
- Decide what needs to be done.
- Do things in an efficient sequence.
- When finished, release the product.
We’ve written several times about the difference between incremental and waterfall processes. In addition to the practical benefits of an incremental process, and a pragmatic evaluation of the challenges and benefits of agile, there is an element of conflict that is worth exploring.
Change, Change, and More Change
There are at least three distinct types of change that we care about when creating software projects. Changes in need, changes in requirements, and changes in rules. Each change is progressively smaller, and happens with progressively increasing frequency.
Changes in Need
Changes in need happen when our customers decide that they need to change how they do business at a strategic level. They have discovered an opportunity in their markets, or decided to act on one. Or they are responding to a threat – internal or external.
As an example, Microsoft has dominated the office productivity application space for quite a while. Google has made several online-only applications that might compete with Microsoft. Most pundits discounted them as non-threatening either because of the online-only limitations, or the reduced (relative) sizes of features in the Google versions. But Google has also recently introduced a beta product called Google Gears – which leverages existing browser caching technology to allow applications to run in the browser when disconnected. Currently, it only works for Google Reader. But what happens when it works for docs and spreadsheets and gmail? This is a competitive threat to which Microsoft will have to respond.
Changes in Requirements
Changes in requirements are a function of how goals and needs are addressed. Product managers assess customer goals, and develop a strategy for satisfying those goals. This is an ideation process that discovers and prioritizes goals, and also determines which goals to address with software. Once the goals to be addressed in software are identified, requirements are defined that clarify what the software must do in order to satisfy the goals.
Tyner Blain has a goal of creating a community that helps improve everyone’s ability to create great software – and more specifically, to achieve Software Product Success. We’ve primarily addressed that goal by creating a blog, writing articles regularly around a set of topics focused on learning how to make products better. Over time, we’ve iterated in the blog with topic selection, design, publishing frequency, and functionality (like rating of articles). Almost three months ago, we changed our requirements – we recognized that what we can provide here is limited because we are writing all of the articles. We introduced the concept of nexus, where everyone who reads here can contribute articles (their own or others) that will help us all get better. Over 1000 articles have been read through nexus so far, and it is growing month over month. With time, we expect nexus to provide more benefit (great content being consumed) than the blog.
The requirements, as subordinates to our strategies for meeting the goal, are changing more frequently than the goals.
Changes in Rules
For a given goal, with a solution strategy defined by a given set of requirements, there are rules that affect how a product must do what the product is intended to do. Most software defines or implies a process for using it to achieve a benefit. In structured requirements, we talk about the use cases that enable a goal to be achieved. Those use cases can also be documented as process flows. One benefit of process flow diagrams is that decisions are very obvious.
Decisions are the result of the application of business rules. An example:
- Goal: Earn more than the risk free rate of return on our $1,000,000 cash assets.
- Strategy (implying requirements): Create a website for individuals to secure small (under $1,000) loans from us, at interest rates that generate sufficient demand, while mitigating risks such that we meet our goal.
- Requirement: Allow individuals to apply for and secure loans online.
- Rule: Adjust the approved interest rate by +1% for borrowers with a credit score below 600.
There would be many rules associated with calculating a risk-mitigating interest rate for loans, balanced against market rates available to potential borrowers. As we evaluate the effectiveness of the algorithm (manifested implicitly by these rules), we will want to change the rules frequently.
These changes to business rules must happen much more frequently than the changes in requirements. And those more frequently than the goal.
Enabling and Resisting Change
Imagine that it would take a year to define, design and implement a website that enabled people to apply for and secure loans. At the start of the process, if we define the goal, strategy (as captured in requirements), and rules. A year later, we deliver the completed product / website.
What are the chances that the goal has changed? The the requirements have changed? That the rules have changed? The goal is probably still the same. The strategy is likely still the same, although not likely to be as good of a strategy as it had been. The requirements that articulated the strategy most likely could have been improved, and certainly our understanding of them would (as well as our customer’s) would have improved. Unquestionably, the rules would have changed.
When a process does not allow you or encourage you to discover and embrace those changes and clarifications, the process is resisting change. Waterfall processes are insular, and they resist change.
When a process requires you to re-evaluate frequently through incremental releases and feedback, the process is embracing change. That is the crux of why agile is valuable. It embraces and enables change.
One thought on “Enabling and Resisting Change”