Archive

Posts Tagged ‘pods’

Design Thinking and Product Management

October 9, 2018 Leave a comment

I came across a great article on Interaction-design.org today.  What follows is a short excerpt from that article.  Follow this link to read the entire article.  It really is a must-read for anyone interested in Product Management, Lean or Agile.


Interaction-design_Design-Thinking

Design Thinking’s Phases

There are many variants of the Design Thinking process in use today, and they have from three to seven phases, stages, or modes. However, all variants of Design Thinking are very similar. All variants of Design Thinking embody the same principles, which were first described by Nobel Prize laureate Herbert Simon in The Sciences of the Artificial in 1969. Here, we will focus on the five-phase model proposed by the Hasso-Plattner Institute of Design at Stanford, which is also known as d.school. We’ve chosen d.school’s approach because they’re at the forefront of applying and teaching Design Thinking. The five phases of Design Thinking, according to d.school, are as follows:

  • Empathise – with your users
  • Define – your users’ needs, their problem, and your insights
  • Ideate – by challenging assumptions and creating ideas for innovative solutions
  • Prototype – to start creating solutions
  • Test – solutions

It is important to note that the five phases, stages, or modes are not always sequential. They do not have to follow any specific order and can often occur in parallel and repeat iteratively. Given that, you should not understand the phases as a hierarchal or step-by-step process. Instead, you should look at it as an overview of the modes or phases that contribute to an innovative project, rather than sequential steps.


Grand Old Man of User Experience, Don Norman, who also coined the very term User Experience, explains what Design Thinking is and what’s so special about it:

“…the more I pondered the nature of design and reflected on my recent encounters with engineers, business people and others who blindly solved the problems they thought they were facing without question or further study, I realized that these people could benefit from a good dose of design thinking. Designers have developed a number of techniques to avoid being captured by too facile a solution. They take the original problem as a suggestion, not as a final statement, then think broadly about what the real issues underlying this problem statement might really be (for example by using the “Five Whys” approach to get at root causes). Most important of all, is that the process is iterative and expansive. Designers resist the temptation to jump immediately to a solution to the stated problem. Instead, they first spend time determining what the basic, fundamental (root) issue is that needs to be addressed. They don’t try to search for a solution until they have determined the real problem, and even then, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they finally converge upon their proposal. This process is called “Design Thinking.”

– Don Norman, Rethinking Design Thinking

outside the box

Read more…

Advertisements

Spotify Engineering Culture (Agile Enterprise Transition with Scrum and Kanban)

July 13, 2018 Leave a comment

Henrik Kniberg of Spotify put this video together back in 2014.  It describes the Podular Agile culture at Spotify.  It is both entertaining and informative, and I find myself going back to it every so often – as I did today.

Spotify+Engineering+Culture

You can find the video on YouTube here:  https://youtu.be/R2o-Xm3UVjs

Some highlights from the video:

  • Some concepts are more important than others:
    • Agile over Scrum
    • Principles over Practices
    • Servant over Master
    • Community over Structure
    • Enable over Serve
    • Trust over Control
    • People over everything else
  • Autonomous Squads
    • Be autonomous but don’t suboptimize
    • Alignment enables Autonomy
  • Fail-Friendly Environment
    • Fail faster than everyone else
    • Failure Recovery over Failure avoidance
  • Lean Startup Practices
    • Waste-repellent Culture
    • Impact over Velocify
    • Innovation over Predictability
    • Value Delivery over Plan Fulfilment
  • Experiment-Friendly Culture
    • Data-driven decisions
    • Chaos over Bureaucracy

Have a look and let me know what you think.  Does this sound like your Culture?  Was there anything here you took back to your team?

spotify-engineering-culture-part-2-agile-enterprise-transition-with-scrum-and-kanban-6960

 

Autonomy, Mastery, and Purpose. Motivation and the Podular Organization, optimizing for innovation rather than efficiency.

March 27, 2014 Leave a comment

Today I would like to talk about a couple of principles and a couple of books that have had an enormous impact on the way I work.  The first is “Drive – The Surprising Truth About What Motivates Us” by Daniel H Pink, which is a brilliant look at how the “carrots and sticks” motivational techniques of the past are no longer valid and why we need to think about intrinsic – as opposed to extrinsic (external) – motivators.  The 3 pillars of motivation are:

  • Autonomy – the desire to direct our own lives.
  • Mastery – the urge to make progress and get better at something that matters.
  • Purpose – the yearning to do what we do in the service of something larger than ourselves.

The other book I want to talk about deals primarily with the last point – “Purpose”.  Once properly motivated, how do we get everyone in the organization to feel ownership of the business?  The solution is to create a “business within a business”. And this is the subject of “The Connected Company” by Dave Gray where we examine the concept of the podular organization and optimizing for innovation rather than efficiency.

These principles fit in nicely with the basic tenants of Agile – the idea of self-organizing and cross-functional teams.  As with other Agile processes, it seems (although it is not true) that these principles are much more applicable to smaller, leaner, more start-up like companies.  I have seen firsthand how Agile organizations fall back into old Waterfall traps as the organization grows, middle management grows along with it, and communication, motivation, and innovation become secondary to efficiency and predicability.  In a world that increasingly requires people to think creatively, solve problems and remain flexible in uncertain environments, hierarchical, multidivisional organizations and extrinsic motivation just don’t work.  The answer is to build flat organizations around small, self-governing “business within a business” units, or “pods”.

My experience applying these principle has primarily been with Software Develop teams.  While Software development seems particularly suited to these principles, it is left as an exercise for the reader to think about how they might be applied to other business’s such as hardware development, or service organizations.  

Organizing a large company into a series of “business within a business” pods, allows each pod to function as a stand-alone business unit, ideally only answering to its customers.  These customers may be inside or outside the organization, but each pod delivers its own business value thus giving its members real, motivational ownership of the pods success.  This is how a company optimizes for innovation over efficiency.

Within the pod, team members are motivated by the intrinsic value of the units success.  Developers, designers, sales, support – every member of the team must feel ownership of the teams success.  Autonomy and Mastery come into play as each member of the team is encouraged to identify and provide working solutions to the day-to-day challenges of creating success.  The parameters for success become clear, aligned with the goals of the larger business, thus empowering every member of the team.

“The great innovators in business did not succeed on creativity alone,” Gray writes, “their success was a blend of creative thinking and business logic.”

A great article on Fast Company sums it up nicely:

“So if you want to set a context to bring out your teams’ inner Edisons, you need to align their incentives in three ways:

  • Incentives need to breed visible impacts on the business as whole
  • Incentives need to balance short- and long-term thinking
  • Incentives need to reward people for doing what makes the business as a whole more successful and healthier

In this way, a person’s individual work is linked to the collective endeavor. They get personal expression and collective validation. They’re incented to do their best work, for themselves and for the organization.”

 

%d bloggers like this: