Production View (Build Fast)
Many large legacy organizations are moving toward agile delivery methods in hopes of releasing faster to market. Based on my experiences, they look at it solely from a production view of getting software released faster and more often. This view has them believing this will result in getting more features released.
These organizations are still spending a lot of time doing upfront planning to define the business case, then lock down scope and budget before building the solution. In most cases, this happens without direct involvement of the product development team. This is on top of cycles of presenting the business case for approval. In some cases, all the time spent going back and forth getting the plans approved is not even tracked.
Only then is “agile” applied at the producing code (feature) level. At this level, you can only sub-optimize producing code. This is why these organizations obsess about velocity. I have heard many times from leaders — “…moving to agile will mean I can deliver more features faster.” There’s a focus on trying to produce widgets as fast as possible, only to let these features pile up and collect dust before they are actually released.
Developers feel they are just cranking out features like a short order cook instead of helping craft the solution like a gourmet chef.
Is this what we are really striving for? Why are we trying to deliver all the features at once? Do we really need all the features?
How do we know we are delivering the right thing? What if the customer/user changed? What if we are wrong?
Running agile as a feature factory is not where the real value comes from. The real power comes from rapid learning and discovery. What features end up released is the by-product of what we learned from frequent customer interactions.
Discovery View (Learn Fast)
Is it better to produce more features, or is it better to solve the right problem with the least features?
The real benefit of agility is not about delivering more, it’s about delivering less — delivering only what is required. It’s being decisive about what to build and what not to build. It is about using every sprint as an opportunity to learn and make a decision — stop? Build more? Refine? Remove?
Agile, used properly, allows team collaboration from the start: identifying business problems, then creating experiments to explore solutions to those problems. Those solutions can be experiments, launched rapidly and in the most minimal way to build just enough solution. These experiments are meant for minimally learning what is needed.
In a discovery-focused organization, we want to solve the right problem, as efficiently as possible, not produce the most features. How can we minimally build something to validate the hypothesis? Instead of campaigning for a full-scale budget for features to build, why not spend less time to get smaller budgets to be able to prove or disprove our hypothesis as quickly as possible? The quicker we prove we are wrong, the quicker we can stop spending money on it. The quicker we learn we are right, the more iteratively we can invest in it. The way to get there is to validate our hypothesis as quickly as possible…then do something from that discovery! Stop or build a little more. This way we minimally build only what we learn from customers rather than everything we tried to predict upfront and budget for.
From my experience, scrum teams (or product development teams) feel more engaged when they participate in ideation of the solution, rather than just translating requirements into code. This active participation always results in better solutions than up-front silo’d requirements specification & design.
In the book Lean UX by Jeff Gothelf and Josh Seiden they used the phrase, “It’s not iterative if you only do it once”
Jeff and Josh also articulate:
A shift from “Requirements” towards Assumptions
A shift from “We Know” towards “We Believe”
A shift from “Let’s Build It!” towards “Let’s Test It!”
Jeff and Josh also worked with Scrum.org to co-create the Professional Scrum with Lean UX certification course to help introduce a lot of proven tools to shift from simply the production of code towards the discovery of a solution.
The efficiency from agile comes from limiting the amount of work by being decisive. It’s about reducing the number of projects by working on the right things. How do you know you are working on the right things? This is where the speed comes in. The speed from agile comes from reducing the time from discovery to validation.
I would like to leave you with 3 things:
- Calculate the current time from idea to an approved business case. Add this to the time from when the Product Development team starts until the software is released. Write that down. Then, select one initiative and take a Discovery view to develop it: Define a problem. Do the bare minimum you need to get three to five sprints worth of budget approved to solve it. Work directly with the team to create experiments and build iteratively until you’ve solved the problem. Compare that time & cost to the previous approach.
- Create roadmaps that articulate problems to solve or opportunities to explore. This allows the development team to be able to contribute to the ideation process.
- Get really good at meeting your sprint goal every sprint. Unless you get a working increment each sprint, you are not agile. It can only be validated by a customer for learning if you get to ‘done’.
Every keystroke is precious so I will end here.
Watch my video below.
Lead how you would like to be led.
Dave
Twitter: @DDame
Medium — https://medium.com/dave-dame