The Agile Architect
Why You Should Let Greed Accelerate Your Agile Development
If you think this is going to be an article on evil product owners and how they just want everything, you're going to be disappointed. Our Agile Architect explains how 'Greed-Accelerated Development 'is the completely achievable desire to want more from your work than just the immediate benefit while not paying any additional price for it. Bwa Ha Ha Ha!
I have a new favorite term, Greed-Accelerated Development (GAD). I coined the term in jest recently but it's something I've been thinking about for a long time.
Normally, in software, greed is a bad thing. We think about greedy product owners and greedy customers who want everything now without realizing the sacrifices they are asking others to make in order to satisfy them. Gruelingly long working hours, low code quality, poor user experience...These are all things we expect when we get greedy.
Greed-Accelerated Development, as I think of it, does not lead to any of these things. In fact, just the opposite. It raises the quality of the software, allowing the team to produce more while working less. But I'm getting ahead of myself.
What Is Greed-Accelerated Development?
Greed-Accelerated Development is a strategy to encourage that all work by the team is expressed as product features. This includes development, testing, delivery pipeline, documentation and anything else.
The question to constantly be asking is "How do I turn this effort into something that will benefit my users?" Another way to ask the question is "What is the benefit the team is getting from this effort and is there a way that this can be valuable to our users?" This is not just a question for product owners. Everyone on the team should be asking this any time you put effort into something that is not already a user-facing feature. And if it is a user-facing feature, you should still be asking how you can get more out of it.
Don't worry. I hear you screaming "But you are going to increase scope by doing this!!!" Nope. And that's the trick. GAD is a strategy for work you are already doing!
Here are some real-world examples:
Example #1: Be Greedy About Configuration Management
In a previous article, I wrote about Branch By Abstraction using Feature Toggles. This is a technique for code branching which is a completely developer-centric need. Users have no need for code branches, abstract or otherwise.
From a GAD perspective, we can ask ourselves what user-facing features we could get from our work to build feature toggles. One answer is that it enables a per-feature licensing mechanism. For example, if you want a "Home", "Pro" and "Enterprise" version of your product, the feature toggle capability enables this.
Of course, there is additional work to go from feature toggles to a licensing feature. Don't build that piece until you need it. But if our product owner thinks that a licensing feature could be useful in the near future, this helps us think through our feature toggle design decisions from a new perspective.
Example #2: Be Greedy about Test Coverage
If you've done much with automated testing, you've probably experienced the effect where test code you've written eventually makes it into the product itself. So why not be greedy about this from the start?
Imagine that you are building a set of APIs. For testing, you have a choice of many different technologies. You already know that the test code is going to act like a client of those APIs, calling them multiple times across all of your tests. You will quickly realize that you are repeating the same sequence of client calls throughout your tests, leading you to consolidate your client calls into convenience methods.
But embrace GAD. Instead of building convenience methods as part of your test code, is there a way to make these convenience calls a part of your product?
Of course there is or I wouldn't have asked the question! Any user of your API will need to make these same calls. So build an SDK. And if you are going to build an SDK, you'll want to do it in the technologies of your real clients. This will have several effects:
- It will drive your choice of testing tools to allow you to write the SDK in a technology that is compatible with your real clients.
- It will drive you to build the SDK with the same quality as your production code. You might not have done this if you had just created convenience methods that would be used only in test code.
- You can use this same SDK in your real client, ensuring that the test code is interacting with the APIs in the same way as your client code.
But we need to consider scope creep, too. So if we are going to invest in an SDK, can we do it in a way that doesn't add time to the project? First of all, we could keep the SDK private so that we don't have to worry about the effort to provide end-user documentation or a release pipeline. We could also provide it as example code for our users with no guarantees. In either of these cases, we are building value now for our efforts while making progress towards a real, supported SDK either now or in the near future.
Example #3: Be Greedy about Features
Asynchrony Labs' Mobile Field Kit (MFK) contains many examples of GAD. Here's one of them:
Two of the tools in MFK are our Maps tool (think Google Maps but with live people and sensors moving around) and our Images tool for sharing and annotating images.
We knew that we had to rebuild both of these tools for various reasons that don't matter to this story. Our initial inclination was to start with the best open-source mapping tool and the best open-source image drawing tool. Then, we started asking the question, could we invoke GAD and get both tools from the same development effort? We realized that we wanted our users to be able to annotate on both tools. It bothered us that the experience of annotating on a map would be different from annotating on an image. Technically, we knew we could build the tool once to satisfy both requirements. But would the user experience hold up?
We weren't sure. But we did know that we could develop the Maps tool first with its annotations and then see if it would be applicable for the Images tool. This had significant impact to our design of the Maps tool, the largest being that we had to support more than one map open at a time. (This was a limitation of our previous implementation.) We also had to support different map data on each display. These design decisions didn't change the level of effort but did provide clarity as to what we were building.
It took us several months to finish the Maps tool. We were looking at a similar effort to rebuild the Images tool from scratch but instead we finished in a couple of weeks. Recognizing that an image is just a flat map with a cartesian coordinate system, we were able to use the same code for both tools. In fact, you can have multiple maps and images open at the same time. When we enhance one tool, the other is enhanced, too. Quite a payoff for a group of greedy developers!
Example #4: Be Greedy About Documentation
Swagger is a great example of GAD in action. The developers of Swagger weren't satisfied with documenting their APIs on paper. Surely they asked themselves the GAD question "If we want to document our API's, how can we do it in such a way that it directly enhances our product?" And their answer: "Let's generate the documentation from our code and display it through a dynamically-generated user interface that allows users to interact with the live system. We never have to write documentation again!! Yay!!!"
Final Thoughts: Why Embrace GAD?
While greed in product development is often thought of with negative connotations, GAD is a good thing. It is a framework for thinking about how to get more out of the work you are already doing. When asked how we can accelerate our efforts, we often consider ways we can go faster. We should also be thinking about ways we can get more from our current efforts.
Greed-Accelerated Development is not about future-proofing, violating YAGNI or scope creep. It is a creative process to drive ideation around novel solutions to the problems we already need to solve while producing enhanced user value from the same effort.