Design Thinking @ Scrumtisch Berlin #
This evening Mary Poppendieck gave a presentation on Design Thinking in Berlin. “What does
the US Military have in common with Apple?” In her talk Mary went into more detail about how increasing complexity
calls for a need to rethink design. Slides are
available online. Thanks for sharing them.
Mary started with a question for the audience on who in your
company decides what is to be developed: Is it the PO? Is it a “them” or is it “us”? In a world of growing complexities
and faster innovation cycles, thinking of them doing the design more and more becomes a huge business risk. It’s time
to start thinking of development teams as groups of people solving a business need - forgetting about the “that’s none
of my business” attitude.
Lets first dig deeper into the three steps of design (according to the book The design of design) the three steps of
design are:
- Understanding the problem: Actually finding out what is the problem, what is to be
designed is the hardest part. It’s best done in a small team as opposed to by a single person.
- Design the
solution: This step involves uncovering specific requirements and identifying alternative solutions - before actually
being able to judge whether an alternative is a viable way of solving a given problem, the harder part is identifying
possible alternative solutions.
- Implementing the design: This step must involve getting users and developers of
the resulting system work closely together.
To come up with a truly successful design these three steps most likely need to be iterated as what we learn in later steps has to influence earlier steps.
When it comes to
design, at traditional corporations there are various job titles for people involved with design. The graph
distinguishes teams developing products vs. supporting internal processes. It makes a difference between software and
hardware development. In addition there is a difference between people deciding on what to design (denoted in red) and
those deciding how to develop (denoted in green). When looking at Scrum all of these roles are combined in the role of
the product owner. When taking a closer look this seems to be a large over-simplification - especially when taking into
account that the product owner in general is realized not as a role that has to be provided for but as a job
description of one single person. It seems like this is too much work and too many hats for one single
person.In contrast Mary advocates a far more hollistic definition of the designers role: In current teams design is mostly being done up-front, in a very detailed way with results in the form of small user stories being handed over to the team afterwards. In contrast to that developers should be integrated in the design process itself - they need to participate, provide their input to come up with really innovative solutions.
Step one: Understanding the problem
The presentation went into more detail on three different approaches to solving the first step in design - that is understanding the problem. The first way was coined as the military approach. In the The operations process a chapter on design was added to cope with complex situations that do not match the expected configuration.
In such situations a combination of collaboration, dialog, critical thinking and creative thinking seems more important than blindly following command. According to the US military’s procedures design again is an iterative three step process: From framing the problem, to experimenting and building prototypical solutions, to making sense of the situation and possibly going back to earlier steps based on what we have learned. One important feature of successful design teams is that the are composed of people with diverse backgrounds to not miss details about the situation.
The second approach to design is the Ethnographic approach. Mary showed a video introducing design company IDEO. The interesting take away for me was that again teams need to be diverse to see all details, that designers need not only find statistics on existing products but also go out to the customer using the product and listen to those “experts”. The need to work under time constraints, work in a very focused manner, build prototypes - not to deploy them but to learn from them, merge them and throw away what does not work early in the process.
Coming from a data driven, Hadoop-y background, the third approach was the one most familiar to me: The data based approach focuses on finding success metrics and optimising those. When going back to the “Mythical man month” example of IBM building the IBM PCjr
- the team spending 2 years developing a product that was a horrible failure, a product that was judged very badly in
common it magazines: What could they have changed to do better? Well the solution almost is in the question: If there
are people writing articles to judge products, people that have criteria for judging product success - why not optimise
for their criteria? Another example would be Toyota developing the Lexus: Early in the process they decided to optimise
for a top score on each of the car magazine reviews. Turned out though hard it was, it was not impossible. And lead to
huge success on the sales side.
So instead of being caught in our little development bubble maybe it’s time to think bigger - to think not only about what makes our project successful but to think about what makes business successful. And while at it - why not measure success or failure of a piece of software by how successful it is monetarily? This leads to a whole new way of thinking about development:- Instead of a product
roadmap we start thinking about a business model canvas: What metric gives us information on the business success of a
new feature? How can we measure that? This can be as easy as click conversion rate. It’s closely tied to the way you
make money.
- Instead of a product vision we turn to measuring a product to market fit.
- Instead of a
release plan we start thinking about the minimal viable product: What is the least you can do to generate more
revenue?
- Instead of an on-site customer we start having a on-site developer. This is about getting developers
out of the building, get them to talk to your users and get this experience back in. Note: To some extend this is even
possible by looking over the user’s shoulder by analysing your log files. Ever thought of taking a closer look at your
search engines queries that return no results? Maybe instead of cursing the users that are too stupid to use your
interface it’s time to re-think your interface design or add more features to your search engine.
- Instead of
iterations we have a loop of building - measuring - learning about our product.
- Instead of an iteration backlog
at the end of each loop we have to decide about whether to preserve the current development direction or pivot it a
bit.
- Instead of a backlog of things to do we have a list of things to learn about our users.
- Instead of
detailed tiny user stories we have hypothesis of how our product is used that are validated or falsified by actual
data.
- Instead of continuous integration you have continuous deployment that is much more
interesting.
- Instead of acceptance tests we may have split tests, A/B tests or similar.
- Instead of a
definition of done including only development it suddenly also comprises validating the data - did we actually convert
more users?
- Instead of costumer feedback we are having a cohort-based metric, we start watching our users to
learn - they are rarely willing to give explicit feedback, but their actions are very telling.
- Instead of a
product owner we have entrepreneurs that have the business as a whole in mind.
Design a solution
Good industrial design is made up of ten principles: It’s innovative, makes the product useful, understandable, aesthetic, unobtrusive, honest (does not fool users), long lasting, thorough through, environmentally friendly - and most important of all there is as few design in there as possible.
As one example Mary mentioned the flight booking site Hipmunk.com that gives users the chance to sort flights by least agony. It optimises for the best flying experience - not the best buying experience.
In the end it’s all about building what the user needs - not selling what your build. It’s about watching your users and learning about their needs.Implementing design
One grave warning: Do not divorce design from development: Ford was a driver and racer himself, making him a great car designer. Wright flew the aircrafts he designed. Tom Edison thought through the whole process. Also in the tech industry the companies that are nowadays most successful were founded by people who are or at least were themselves very actively using the stuff they are building - think Bill Gates, Steve Wozniak and Steve Jobs, Sergey Brin and Larry Page. Takeaway is to do the job you are trying to automate, to have incremental development and delivery.
In the end it all boils down to how fast a learner you are: Not the most intelligent nor the strongest will survive. It’s the one that is fastest to adapt to change that will be successful. One commonly used analogy for that is the so-called OODA cycle coming from John Boyd: The tighter your cycle of observing, orienting, deciding and acting is, the likelier you are to be successful among your competitors.
Speaking of release cycles Mary gave a very nice graph of various release cycle lengths.
In her experience teams that have deployment cycles of six months and above are likely to spend one third of their time hardening their software. If you are down to a quarter it’s likely that the bottleneck is your business model. Maybe it is weird contracts or business partners expecting support for the exact version you shipped years ago. When you are down to a month per release you likely are running a software as a service model. As clarified later after a question from the audience for Mary this does include setups where customers basically buy a software including all future updates for a set period of time - including an automated roll-out. If you are down to daily or even just weekly releases you are likely running the product yourself. Mose likely then everyone is part of the team.
After
her talk Mary answered various questions from the audience: According to her experience Scrum defines the team way too
narrow by focusing on development only - with Scrum we are possibly getting perfect at doing the wrong thing very well - Instead of a product
roadmap we start thinking about a business model canvas: What metric gives us information on the business success of a
new feature? How can we measure that? This can be as easy as click conversion rate. It’s closely tied to the way you
make money.
- forgetting all about design and business.
One very general advise that leads to an interesting conclusion is to not waste your life, to not spend years of your life working on projects that are not needed by anyone. In the end this leads to realizing that failed projects are also caused by the developers not raising concerns and issues.
Mary is a huge proponent of trusting your team: Do not hand them detailed lists of user stories. You have hired great, senior people (or haven’t you??) - give them an idea what you want and let them figure out the details by talking to the right people.
When asked for tools to support the lean startup process in a startup Mary emphasized the need for communication. Tools are likely to only slow you down: Get people to communicate, to sit at one table. Have a weekly or bi-weekly meeting to get everyone in sync. Otherwise let developers figure out their way to collaborate.
The talk was kindly hosted by Immobilien Scout, organised by agiliero with some tickets handed over to the Berlin Scrumtisch. Thanks guys.