What I Learned from the Business Model Canvas Workshop
How can you make developers happier, more engaged, and poised for innovation? If you relied on developers to achieve your goals, how would you foment these potent productivity multipliers?
My feelings, as a developer, are that freedom and responsibility are the key — explain the problem, and then let me and my team pursue your goals with frequent collaboration and minimal constraints. I say this because when I am not being pressured, and I feel important, that’s when I feel at my absolute best. My developer friends express this preference, too.
Freedom and responsibility are extremely dangerous, though. Not only can they unlock peak potential, but they also risk catastrophe. Instead of helping our organisations to steam past competitors, we can can get too focused on clean code or microservices, forgetting we are supposed to be making someone’s life better.
If we want the freedom and responsibility, we need to have a deep situational awareness. This is why I think the Business Model Canvas is a marvellous tool for improving alignment between developers, executives, and just about anyone else in an organisation.
Having experienced the alignment benefits of the Business Model Canvas, I wanted to get the opinions of others who have operated within a variety of different organisational structures and cultures. So I ran a Business Model Canvas workshop for the London Agile Leadership Community.
In this post I will tell you will what I learned at the workshop and where I am focusing on improving my understanding in the future.
Workshop Format
So that you can contextualise my musings, I’ll first explain the format of the workshop. I thoroughly enjoyed the workshop and there was a high level of interactivity, so I think it worked well as a learning activity. If you want to run this workshop yourself, you could use a similar format:
1. Explain my motivations (20 minutes):
“Teams work best with the freedom and autonomy, but for that to work they need to be aligned with business intent — hence the business model canvas..”. Also took questions during this activity.
2.Talked through an example pre-prepared Business Model Canvas (10 minutes)
3. Split into groups of 3 or 4 and chose a random business out of a pot (e.g. Spotify, Wonga, OpenTable)
4. Created Business Model Canvases for chosen business, reflected on alignment benefits, and used the canvas for business model innovation (45 minutes)
The full instructions were printed out and given to each team. You can view them in full here. During this activity each team also had a sample Business Model Canvas that was printed out.
Each team drew their canvas on A3 paper. However, if you have a lot of whiteboard space or big screens, you don’t have to use paper. For electronic versions, I sincerely recommend canvanizer.com
5. Reflection on workshop and alignment benefits of the BMC (20 minutes).
During this final part of the workshop we quickly went round each team and asked them what business model they created and how they found the activity. We then explored whether they thought it was good for aligning developers and business intent and ultimately if they would use it to engage their developers.
Yes — the BMC and Alignment Can be Beneficial
As the timebox for the hands-on phase of the workshop neared completion, I glanced around the room and noticed each group still deeply engaged in creating canvases and discussing the potential benefits. It appeared to me that people were getting value from the activity.
As we then went round each team for their thoughts post-canvas creation, the general opinion was that the canvas could be useful for alignment. As you would also expect from an agile event, the mood was generally supportive of alignment.
In addition to just acknowledging the canvas could be useful, we heard a few anecdotes expressing the problem with the lack of alignment. We heard how a shared vision created by a tool like the BMC could have prevented considerable business problems in a number of scenarios — both in cases where the business could have communicated better with engineering and vice-versa.
A number or reservations and caveats were raised in regard to using the canvas as a tool for alignment, though. Understanding context and applying principles and practices judiciously still applies with the BMC. A few of those caveats are discussed next.
Find the Appropriate Level(s) of Detail
A vocal concern raised by multiple teams was that the BMC is too high level. We had the example where a developer working for an organisation the scale of BBC could gain little actionable insight from a canvas for the entire organisation. A per-product or project BMC was suggested as the alternative.
I have been using the canvas on smaller projects, where one BMC was enough for the entire organisation. So I didn’t have answers based on experience to give. In fact, this was something I learned from the event. I actually hoped to meet people from a variety of different backgrounds to get a variety of opinions and perspectives such as this.
To answer the question, though, I would look back to the motivation: alignment. As a developer I want to feel a sense of purpose and importance. I want to understand why I am engaged in a project and how I can have a greater impact beyond just writing code.
With this in mind, I think some understanding of the bigger picture is necessary. An entire company BMC, a purpose, a mission statement, or a vision could be useful for that in addition to a more detailed summary at the project-level.
As an example this could implemented with a business-level and project-level BMC or business-level mission and a project-level BMC — whatever it takes to provide me with a clear end-to-end view so that I understand the importance of my work and can studiously optimise for the system as a whole.
Collaborative Cross-functional Activity
Almost ubiquitously, each team voiced their opinion that creating a Business Model Canvas should be a cross-functional activity, engaging not just developers but a variety of technical and non-technical stakeholders. It was suggested that just throwing a BMC at tech teams would do very little to increase engagement.
My first experience with the BMC was actually a developer-led initiative. We knocked up a canvas and took it to the exec driving the new product idea. He pointed out how different our vision was to his, and from that point we started to have more meaningful discussions about the product. So I fully concur with the view that producing the BMC can benefit from cross-functional participation.
One concern that was raised with this approach is similar to the HiPPO (highest paid person’s opinion) phenomena, whereby an imperious manager may dominate. If you feel that this could be a problem, try creating an initial version without those people.
Even though this could or should be a cross-functional activity, it can be initiated by anyone. Either business-minded people can engage with developers, or keen techies can show an interest in business objectives. All it takes is for one person to arrange a workshop and invite the right mix of people. Anyone who cares enough can do that.
How Autonomous Should Teams Be?
We didn’t get universal agreement on the level of autonomy a development/delivery team should have. In particular, there were a variety of responses to my affirmation that delivery teams should be able to decide which work item they should work on next.
My belief is that teams should be able to look at their backlog and make a decision about what is the most beneficial to complete next — they can decide if a technical task like upgrading software is more important than a value add that customers are clamouring for.
To be clear, I want to emphasise that I was envisioning a cross-functional team who would engage with stakeholders to understand the value of each ticket. That’s why I think the canvas is useful — it helps those doing the work to understand how it creates value, so they can decide what is the top priority in terms of system-level benefits.
But a number of opinions and anecdotes indicated that this level of responsibility could be damaging. We heard stories about developers who did not want to engage or take the responsibility. I’ve definitely met many of these jira-focused developers, so I can fully relate to the concerns being raised.
We also heard the view that management should be more decisive in these situations and that there was little benefit in having the teams make these decisions.
With an infinite amount of time we could have explored each person’s experiences — size of company, development culture, agile process — and reached a deeper understanding of the type of projects and organisations where increased autonomy leads to improved system-level outcomes… if at all.
Huge Thanks to ALC, 7digital and Everyone who Came
it’s not often I get an audience of non-technical managers and stakeholders from a variety of companies whose opinions and experiences I can directly learn from. Accordingly, I am very grateful to Frank & the London Agile Leadership Community for allowing me to run this workshop and sharing their thoughts and opinions.
If you’re based in London or just stopping in the area, I would recommend attending ALC events if you want to have fun and learn from experienced leaders who have worked for the likes of Amazon and the BBC.
Since we ran the workshop at 7digital’s offices, I’d also like to thank my good friends (and former employers) for allowing us to host the event at their cosy offices.
