The book The Fifth Discipline by Peter M. Senge landed on my doormat recently. I ordered it after hearing Andrew Harmel-Law of ThoughtWorks mention it at the JFokus 2020 conference (article in Dutch). His takeaway was as follows:
"Placed in the same system, people tend to produce the same results".
Once I received the book however, a line at the top of the cover caught my eye:
"In the long run, the only sustainable source of competitive edge is your organization’s ability to learn faster than its competitors"
This statement rings so many bells I’d like to dwell on just that without even going into the book itself. There are two obvious yet often missed clues here that I’d like to share.
To learn, you must see
Agile does not only focus on getting a version of your product to the customer fast; the whole idea is that you then learn from how it’s received and used before building the next increment.
In order to learn and capitalize on that competitive edge, you need to be able to see how it’s received and used first. As stated in the Second Way in the Phoenix Project, it’s vital that you have feedback loops in your delivery process.
Instrument and monitor your application. Not just its memory and CPU use, but also how its APIs or even specific methods are being called.
DevOps. Your developers should have front row seats to see the results of their work in action and get feedback fast. Having a service desk or technical application management department are great ways to shield developers from customers' complaints. That can come in handy when they shouldn’t be disturbed, but creates a barrier to seeing and thus to learning. Try to find a sweet spot between the two.
Analyse usage. Don’t just assume you or your amazing colleagues from the concept & design department made the best possible UX. Track and measure it in production.
Do customer interviews. Don’t just look at what you expected to see. Sit with the customer and watch them use the product. Engage with them face to face.
If you cannot adapt, learning is pointless
Once you have the ability to see what your product is doing once it’s in the hands of the customer, you can learn from it.
But oft-forgotten is that learning is useless if you cannot adapt.
This is the Third Way in the Phoenix Project: You need to be able to experiment, learn from failures (and successes, I might add) and try again.
What’s crucial here is to consider the environment surrounding a development team. Many organizations have heard that agility helps development teams get more relevant things out the door quicker, but fail to see that true success requires the whole organization to be able to adapt. This is related to the point Andrew Harmel-Law made as quoted in my introduction above.
Team forecasts should not be seen as written in stone. The Scrum Guide changed the word commitment to forecast for exactly this reason several years ago.
The team may learn it can deliver more value given more budget or time. If a team delivers every two weeks but a budget can only be adjusted yearly (or never), you’re foregoing a chance to adapt.
Be careful when communicating exact milestones to stakeholders. I’ve worked on agile projects in eCommerce where the communications department still thought in ink: promises about exact features the project would deliver at exact dates were communicated far in advance, printed on flyers and catalogues and sent out to customers. This then became the leading argument in backlog prioritization, rather than learnings from earlier increments that other things would be more valuable to those same customers.
Your organization may have understood that having a great idea isn’t enough if you don’t know how to deliver it to customers.
Your organization may have understood that your development teams can deliver your idea incrementally to get value out there quickly and incrementally.
Does your organization also understand the importance of seeing and adapting that precede and succeed this learning process respectively, and how it can impede or facilitate this?