Category: Ikke-kategoriseret

Posted on

Product Discovery

Product Discovery

Modern product-led organizations with a strong product culture will typically apply what has come to be known as dual-track Agile, each track with a specific purpose:

Dual-track Agile

Development work focuses on predictability and quality. Discovery work focuses on fast learning and validation. Discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking

Jeff Patton

All organizations, not restricted to the product-led ones, want to be effective and efficient. How they do it depends on their context and business model. For the modern high-tech product organization, the dual-track Agile approach has become one of the Good Practices (hard to claim any practices to be “best”).

We’re running Scrum and have people equipped with all sorts of Agile certifications, therefore we’re super good at Product Discovery! In fact, we’ve engaged a number of Agile Coaches to do even better!

You might actually be super good at Product Discovery, but it is not due to Scrum (or e.g., Kanban for that matter) and probably not due to your Agile Coaches as expressed by Marty Cagan:

… the vast majority of Agile coaches don’t have experience with tech-product companies, so their experience is limited to delivery. Therefore, they would more accurately be considered Agile delivery coaches. They understand the engineering and release side of things, but not the discovery side of things.

Discovery coaches are typically former product managers or product designers and they have usually worked for leading product companies. So they are able to work side by side with actual product managers and designers – not just reciting Agile platitudes, but showing the team how to work efficiently. 

It is hard for me to imagine an effective discovery coach who doesn’t have first-hand experience as a product manager or product designer at a modern product company.

Marty Cagan, INSPIRED p. 289-290

Melissa Perri follows suit, pointing-out that the adaption of Agile is not the same as getting great at product management:

Many companies … have eagerly adapted Agile, thinking it was a silver bullet for creating more value in software, only to be disappointed. Why? Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management.

Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset. 

Melissa Perri, Escaping the BUILD TRAP p. 26

Teresa Torres starts her book, Continuous Discovery Habits with the same point:

All product teams do a set of activities to decide what to build and then do a different set of activities to build and deliver it. While you’ll learn that these activities can and should overlap and interweave with each other, the work that is required to do each is fundamentally different.

… many companies put a heavy emphasis on delivery – they focus on whether you shipped what you said you would on time and on budget – while under-investing in discovery, forgetting to asses if you built the right stuff.

Teresa Torres, Continuous Discovery Habits p. 13-14

A lot has been and is being written about the Development / Delivery track. This post will take a swim in the pool of Product Discovery Techniques.

Marty Cagan sums-up the purpose of Product Discovery:

… the purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production-quality product, it won’t be wasted effort. And this is why we have so many different techniques in product discovery.

…

Much of the key to effective product discovery is getting across to our customers without trying to push our quick experiments into production.

… If you want to *discover* great products, it really is essential that you get your ideas in front of real users and customers early and often.

If you want to *deliver* great products, you want to use the best practices for engineering and try not to override the engineers’ concerns.

Marty Cagan, INSPIRED p. 163

If you haven’t already done it, I suggest reading the previous article From Vision to Delivery and Outcome in the product-led organization giving you a framework of reference before moving on.

The primary inspirational sources for this post

You’ll find a growing number of books and even more on-line articles on the topic of Product Discovery. In this post I’ll primarily seek inspiration in the following books:

INSPIRED
Product Discovery
Build Trap
Dare
Scrum for hardware design

The Product Manager

Before jumping into the pool of Product Discovery techniques, lets take a step back understanding the realm of Product Management:

Realm of Product Management

At the heart of it we’re finding exactly the Product Discovery discipline being where the modern Product Manager will spend a significant amount of time. Marty Cagan has repeatedly made it clear, that the Scrum Product Owner role is only a fraction of much larger role as Product Manager. Melissa Perri agrees: 

… people usually become confused between what Agile calls *a product owner* and *a product manager*.

When you look at the role of the product owner in most Scrum literature, the three responsibilities of the position include the following:

    • Define the product backlog and create actionable user stories for the development teams
    • Groom and prioritize the work in the backlog
    • Accept the completed user stories to make sure the work fulfills the criteria

… it leaves lots of questions unanswered and these questions are important for creating successful products:

    • How do we determine value?
    • How do we measure the success of our products in the market?
    • How do we make sure we are building the right thing?
    • How do we price and packet our product?
    • How do we bring our product to market?
    • What makes sense to build vs buy?
    • How can we integrate with third-party software to enter new markets?

Product ownership is just a piece of product management.

… product owner is a *role* you play on a Scrum team. Product manager is a *career*

If you take your Scrum team away, and Scrum as a process, you are still a product manager. Product management and Scrum can work well together, but product management is not dependent on Scrum. This role should exist with any framework or process …

Melissa Perri, Escaping the BUILD TRAP p. 37

Product Discovery principles

In chapter 33 of INSPIRED, Marty Cagan recommends following a set of core discovery principles:

    • It’s our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all modern product.
    • The hardest part of all is creating the necessary value. This is generally where we’ll need to spend most of our discovery time.
    • As hard and important as engineering is, coming up with a good user experience is usually even harder, and more critical to success.
    • Today, we know that the technology drives (and enables) the functionality as much as the other way around. We know that technology drives (and enables) design. We know that design drives (and enables) functionality. The point is that all three of these  are completely intertwined. This is the single biggest reason we push so hard for the product manager, product designer, and the tech lead to sit physically adjacent to each other.
    • The most important thing is to know what you can’t know (which is exactly what Melissa Perri points to above).
    • We must validate our ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, and not after.
    • Our goal in discovery is to validate our ideas the fastest, cheapest way possible. Discovery is about the need for speed.
    • We need to validate the feasibility of our ideas during discovery, not after (see later – can we build it?)
    • We need to validate the business viability of our ideas during discovery, not after.
    • It’s about shared learning. One of the keys to having a team of missionaries rather than a team of mercenaries is that the team has learned together.

Product Discovery principlesIn their book Product Discovery: A no-nonsense guide to building effective products and services, Marcus Castenfors and Martin Christensen provide us with their set of guiding principles (structured in the same way as the original Agile Manifesto).

These principles are fully in line with and support the other authors.

The British Design Council’s framework for innovation – also known as the Double Diamond model – applies the same principle as the Dual-track Agile model: Separate focus on Problem and Solution. In this illustration of the Double Diamond model, the iterative part has been made explicit:

Innovation model

Some teams are able to switch context between the problem and solution spaces within the same sprint. Other teams prefer “clean” problem or solution sprints.

The toolbox of Product Discovery techniques

Let’s start with a disclaimer: the breadth and depth of Product Discovery techniques is not only huge – it is constantly evolving making it impossible to provide a full map of all current techniques in all types of industries and business models.

Here I’ll try to provide an overview of the commonly used techniques – most of which found in my inspirational sources.

The majority of literature on the subject circles around purely digital products. The thinking is however fully valid and relevant for multidisciplinary products, the point being that we recognize and respect the constraints imposed by the physical world (electronics, mechanics, environmental, logistics, production, supply-chain, health & safety, regulations, norms, standards, certifications …).

For (purely) digital products, Marty Cagan brings focus to four essential product risks. Here with a fifth risk-area added, related to the production and lifecycle of physical products:

    1. valuable for the customer
    2. usable for the customer as intended
    3. feasible for us to build
    4. viable for our business
    5. feasible for us to produce and deliver the product (in serial production)

Through disciplined Product Discovery we want and need to gain insights and control over these five product risk areas, before investing heavily in the Development / Delivery of an actual product!

Now – let’s open the toolbox of Product Discovery techniques.

INSPIRED PART IV THE RIGHT PROCESS page 159-307

Marty Cagan has dedicated a significant part of INSPIRED to Product Discovery Techniques. I highly recommend reading the whole book. Here I’ll just scratch the surface.

DISCOVERY FRAMING TECHNIQUES

  • Opportunity Assessment Technique
  • Customer Letter Technique
  • Startup Canvas Technique

DISCOVERY PLANNING TECHNIQUES

  • Story Map Technique
  • Customer Discovery Program Technique

DISCOVERY IDEATION TECHNIQUES

  • Customer Interviews
  • Concierge Test Technique
  • The Power of Customer Misbehavior
  • Hack Days

DISCOVERY PROTOTYPING TECHNIQUES

  • Feasibility Prototype Technique
  • User Prototype Technique
  • Live-Data Prototype Technique
  • Hybrid Prototype Technique

The Lean StartupYou might be wondering – what happened to Eric Ries’ classic The Lean Startup in the list of inspirational sources?

I’ve found it misleading when it comes to the notion of MVPs. Just to strengthen my point, here is a quote from Marty Cagan:

Eric’s book did a great deal to help product teams, and to me, it is a must-read book for all product people. But I think most people would likely admit that the concept of MVP has caused considerable confusion within product teams, and I spend a lot of my time helping teams get value out of this critical concept.

… while the P in MVP stands for *product*, an MVP should *never* be an actual product (where product is defined as something your developers can release with confidence, that your customers can run their business on, and that you can sell and support).

The MVP should be a *prototype*, not a product.

…

I find that using the more general term *prototype* makes this critical point clear to the product team, the company, and the prospective customers.

… in this book I talk about different types of *prototypes* being used in discovery and *products* being produced in delivery.

Marty Cagan, INSPIRED p. 29-30

DISCOVERY TESTING TECHNIQUES

  • Testing Usability
  • Testing Value
  • Demand Testing Technique
  • Qualitative Value Testing Techniques
  • Quantitative Value Testing Techniques
  • Testing Feasibility
  • Testing Business Viability

TRANSFORMATION TECHNIQUES

  • Discovery Sprint Technique
  • Pilot Team Technique

Teresa Torres in Continuous Discovery Habits

First of all  – if you’ve not yet read Teresa’s book, I highly recommend doing so. It is impossible to give full credit to this important book here. I’ll just convey a couple of high-lights.

The Opportunity Solution Tree [OST]

Opportunity solution trees are a simple way of visually representing the paths you might take to reach a desired outcome.

The root of the tree is your desired outcome – the business need that reflects how your team can create business value.

Next is the opportunity space. These are the customer needs, pain points, and desires that, if addressed, will drive your desired outcome.

Below the opportunity space is the solution space. This is where we’ll visually depict the solutions we’re exploring.

Below the solution space are assumption tests. This is how we’ll evaluate which solutions will help us best create customer value in a way that drives business value.

Teresa Torres, Continuous Discovery Habits p. 30

You might recall the mapping from product strategy over product discovery to product delivery in the earlier post.

Below is an attempt to merge Teresa Torres’ Opportunity Solution Tree with the strategy-discovery-delivery map:

Opportunity Solution Tree

Opportunity solution trees have a number of benefits. They help product trios (ed. : Product Manager, Product Designer, Engineer):

    • Resolve the tension between business needs and customer needs
    • Build and maintain a shared understanding of how they might reach their desired outcome
    • Adopt a continuous mindset
    • Unlock better decision-making
    • Unlock faster learning cycles
    • Build confidence in knowing what to do next
    • Unlock simpler stakeholder management

Teresa Torres, Continuous Discovery Habits p. 30

To get the full story on how to leverage the use of the Opportunity Solution Tree, go read Teresa’s book.

Wrap-up

Yes – (continuous) Product Discovery is definitely a deep rabbit hole in its own right. The good news is that you’ll find a lot of helpful material out there to guide you.

Happy Discovery!

Posted on

From Vision to Delivery and Outcome in the product-led organization

From Vision to Outcome

How do we come from our vision to delivery and Outcome? And why talk Outcome and not only Output?

Melissa Perri has written a whole worthy-to-read book Escaping the Build Trap explaining exactly, why we need to focus on Outcome and not only on Output:

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value these things produce. When companies stop producing real value for their users, they begin to lose market share, allowing them to be disrupted. Companies can get out of the build trap by setting themselves up to develop intentional and robust product management practices. At that point, product managers can find the opportunities to maximize business and customer value.

Melissa Perri, Escaping the Build Trap p. 1

A lot has been (see e.g., my list of inspirational sources) and is being written about the inner working of a truly product-led organization. It is easy to get information overload and lose the bigger picture on how the various entities fit together from the high-flying Vision to the day-to-day execution in the product teams. The ambition with this post is to provide such an overview.

Understanding the big picture end-to-end in the product-led organization

If you’re not familiar with the OKR framework, you might want first to visit the previous post on Finding the rhythm with OKRs and Product. 

If you’re new to the concept of a product-led and agile organization, you might also want first to read the post, We need business agility in our high-tech Product company.

Finally – if you want some thoughts on the delicate balance process prescription and flexibility, you might want to read this post and this post.

Now having the basics in place, let’s try to understand the links from the top-level strategies to the day-to-day activity execution. Done right, the organization will achieve highly aligned yet (fairly) autonomous teams focused on producing Outcome and have integrated learning as a core element in its culture. 

How it all links together

Below I’ve illustrated three levels of focus / abstraction. In practical terms (unless we’re talking a very small organization) we’ll have additional levels covering e.g., Team OKRs.

Product Strategy
    • Product Vision
      The Product Vision is a subset of the full Company Vision
      It serves as a common North Star for the organization
      Main responsible: Head of Product
    • Product Strategy
      The Product Strategy guides which OKRs to work on
      Main responsible: Head of Product
    • Product Goal
      Mid-term (1-5 years) high-level objectives leading us to achieve our vision
      The Goals are the Objectives in the OKR framework
    • Product Outcome
      The Outcomes are the Key Results in the OKR framework
      Outcome can be seen as a measurable change in customer behavior

Note: In this simplified illustration, we’re going directly from the strategic OKRs to Product Discovery (in the Product Teams). In practice you’ll often have a further break-down of OKRs to the Product Team level with a quarterly cycle.

We’re now at the Product Team level, assuming that relevant Team OKR’s have been agreed with the Product Teams.

Remember that the Product Teams are empowered to Discover the best Solutions to the Problems (aka Objectives). The Product Teams are thus not presented with a given solution / set of features to implement (which would make the Team a Feature Team and not a Product team).

A lot of different techniques exist doing Product Discovery (read e.g., Continuous Discovery Habits, Product Discovery,  DARE or INSPIRED) , all sharing the same core principle: generate ideas (called “ideation”) / hypothesis and test these in a disciplined way. Some hypothesis test valid, others fail (read: we’ve learned new insights).

Another core principle is not to start Development activities before the given hypothesis has tested valid. 

Some product teams prefer to have “clean” sprints with either Discovery or Delivery. Others (more mature) product teams are able to shift context during the same sprint. This is also known as Dual-track Agile.

Dual-track agile

Wrap-up

The essence here can be boiled-down to one of the essential take-aways from Henrik Kniberg’s classic video on the Spotify Engineering Culture: Teams / squads being

    • loosely coupled (we’re highly focused on what problems are being worked on in which teams thus actively minimizing hard dependencies between teams)
    • tightly aligned (the teams share the same North Star)

Ready for more reading? You might want to (re-) read the article on how to achieve high-paced innovation.

Posted on

Finding the rhythm with OKRs and Product

OKR inspiration

An organization is much like an orchestra: you need highly skilled individuals working together in an aligned and transparent way according to a common heartbeat. Focus will in this post primarily be on OKR and Product.

Objectives and Key Results [OKR] has become a wide-spread and popular heartbeat-driven agile goal-setting and management framework creating alignment in organizations, vertically and horizontally.

This post will discuss the use of the OKR framework in general, and specifically in the context of high-tech product-led organizations

Note: Some of my inspirational background is found below.

Executive summary

The OKR framework is one among many goal-setting frameworks. It has become widespread and popular among especially high-tech companies with a fast-paced technology and business context.

Where e.g., KPIs and Balanced Scorecard focuses on Lag Metrics (looking in the rear-view mirror with clear goals for longer time frames), OKR has its focus on Lead Metrics and a strategic direction. What also characterizes OKR is the Agile mindset with relative short OKR cycles enabling integration of new learnings and insights.

What comes closest to OKR is probably the Hoshin Planning framework, though OKR is far more lightweight.  

Christina Wodtke: “OKRs are simple and hard. Running a marathon is also simple and hard. You don’t try to do it in one go. You build up to it“. The best implementation strategy is to start small, gain insights and expand the use of OKR from there.

OKR - in general

The OKR framework has these overall characteristics:

Objective - where you want to go

    • Is qualitative
    • Must be easy to understand
    • Short and to the point
    • Describe what needs to be achieved and importantly – why – the rationale
    • Be inspiring and motivating
    • Aspirational & challenging
    • 1-4 objectives per team

Key Results - how you measure the progress towards the Objectives

    • Is an outcome
    • Specific and time-bound
    • Measurable and verifiable 
    • Aggressive – yet realistic
    • Is quantitative, preferable as “from to”
    • 1-5 KR per Objective

Initiatives / key actions

Some organizations use the notion of Initiatives in addition to OKRs being actions derived from the OKRs stating how to reach the goal.

    • Activity
    • Measurable output
    • Directly controllable

Not easy - but worth the investment

OKRs are simple and hard. Running a marathon is also simple and hard. You don’t try to do it in one go. You build up to it.

Some companies try to jump into the deep end of the pool with OKRs.

Christina Wodtke, RADICAL FOCUS second edition p. 149

In essence what Christina Wodtke says, is that

    • you’ll most likely fail the first time trying to implement OKRs
    • you should start small with a pilot / experiment (entering at the shallow end of the pool)
    • you should learn, reflect and show tenacity until OKRs are working for you
    • you’ll want to keep it simple avoiding process bloat!

As with all frameworks it poses challenges in its implementation. Done right, the OKR framework promises

    • alignment and synchronicity in the organization, both vertically and horizontally
    • a bi-directional top-down and bottom-up planning approach rendering a number of advantages like
      → nurturing teams’ self-organization through empowerment
      → having teams (vertically) align with higher-level OKRs
      → having teams (horizontally) align with other team’s OKRs
    • transparency in who (teams) are working on what goals and in the progress to meet these goals
      → the OKRs are visible to everybody 
    • embracement of ambitious / stretch goals driving the innovation and growth in the organization
      → the OKR framework encourages experimentation and fast learning loops
    • agility
      → the regular review of goals ensures that they adapt (being agile) and not become static and stale
    • focus (note the name of Christina Wodtke’s books “RADICAL FOCUS”)

I believe the one thing that makes the difference between excelling and flailing about in mediocrity is focus.

OKRs are a framework for creating and ensuring focus on what really matters, but they don’t work if you stuff them full of every single business-as-usual initiative you have going.

Christina Wodtke, RADICAL FOCUS second edition p. 134

You’ll have to watch-out for the pitfalls, some of which being

    • OKRs only cascaded from top to bottom
      → this will undermine the trust in real empowerment
    • OKRs used for performance evaluation
      → this will quickly lead to teams under-promising thus rendering the notion of aggressive – yet realistic – OKRs void
    • OKRs used for “business-as-usual” goals
      → this would undermine the point of OKRs having a growth-oriented purpose
    • OKRs used as a to-do list
      → remember that OKRs are about providing outcome and not output as would be the result of to-do lists
    • OKRs at the level of individuals when the primary modus operandi is for people working in teams
      → use team OKRs and only in special cases also personal OKRs
    • too many OKR sets for the individual to understand and navigate among. Below is an example of a de-focused use of OKRs. Even though we assume the OKR-alignment between levels, it still results in a massive number of data points for the individual to navigate among.
De-focused use of OKRs
    • Because focus is so fundamental for OKR to work, Christina Wodtke recommends only having one OKR set per company / business level per quarter. Marty Gagan similarly promotes focus in product-led organizations suggesting only 1-2 OKRs per team – and no personal OKRs.

It’s better if you spend an extra hour getting the OKRs right than loosing your employees’ focus by burying them with unnecessary language, dozens of priorities, and watered-down goals. 

Christina Wodtke, RADICAL FOCUS second edition p. 139

The rhythm seen from a helicopter perspective

Highly inspired by Christina Wodtke, this is an example of the overall and general hierarchical structure of OKRs:

OKR cycle

You might be thinking “this has clear similarities to some of Scrum’s ceremonies”. Yes – you are right, but OKRs do not have Scrum as a prerequisite, or the other way around for that matter. When it comes to implementing OKRs in an organization using some form of e.g., Scrum / Kanban you’ll of course need to define an relevant implementation strategy ensuring synergies and not overlap between frameworks. 

Later in this post we’ll shortly discuss the scenario implementing OKRs in a product-led organization already experienced with Scrum.

The OKR cycle good practice is to have four cycles per year – not too many and not too few.

Each OKR cycle starts with OKR Planning. As stated above, the planning should be a combined top-down and bottom-up approach.

Christina Wodtke suggests having a weekly Monday OKR commitment aligning all on the intention for the week (and celebrate the achievements in the coming weekly Friday check-in). 

The weekly OKR team check-in will typically have a structure well-known from the daily Scrums:

    • What is being worked on?
    • What is the status of our Key Results?
    • Are there any impediments or dependencies that are blocking the work?

The OKR review at the end of the each OKR cycle will often have a structure well-known from Sprint Reviews in Scrum:

    • Presentation of the results
    • Recap of the learnings and their implications
    • Questions and feedback

The OKR Retrospective has the same purpose as the Sprint Retrospective in Scrum – integrate learning with the purpose of doing even better in the next cycle. You’ll find many creative examples of how such Retrospectives are done. I’ve found the “should-did” method effective (maybe a future post will elaborate on the method):

Should-did

An often-cited example from Google

Supporting the work on the Chrome browser, the Google team used OKRs and Initiatives. This story is also mentioned by John Doerr in the TED Talk video below.

    • Objective: Develop the worlds most successful browser 
    • Key Results: At least 20 million active users per week end of 2008
    • Initiatives: Develop (also) a version running on Macs

As explained by John Doerr in the video, the KR ambition was raised a number of times:

Chrome OKR

OKRs in a product-led organization

The OKR framework is a general tool from used in our personal lives to strategy alignment in very big organizations. In this example we’ll assume the specific context of a product-led organization, highly inspired by Carty Cagan. Below is a general structure of such an organization – here with a certain size calling for numerus engineering and product directors / managers and multiple product teams. To quote Marty Cagan:

You need better – not fewer leaders

Marty Cagan

Should you not agree with this quote, I suggest reading EMPOWERED. You’ll come to realize that an organization definitely needs strong leaders/managers. Note that there is no natural law stating that bureaucracy is a consequence – but if you do not pay attention to the built-in autopilot, then you will grow bureaucracy.

Product-led organization

Product Team

The key organizational concept here are the Product Teams, each often responsible for some significant part of the organizations product offerings or technology.

Marty Cagan supplies these characteristics of such a Product Team:

A Product Team

    • is stable and cross-functional
    • is autonomous (though some dependencies will exist in practice) 
    • is self-organized
    • is given a (hard) business / customer problem to solve
    • is empowered to Discover the right solution to the problem
    • is measured & held accountable for the Outcome (business result)
    • perceives itself as a group of missionaries with a cause

Marty Cagan

Strategic Product Leadership

In this earlier article, you’ll find a description of the Head of Technology and the Head of Product. The essence is that they’ll provide the strategic context / North Star for the product teams. Yes – the product team is highly empowered to discover the right solution to a given problem, but it needs to be within an agreed strategic context.

Tactical Leadership / Management

These people-managers have a number of important responsibilities e.g., 

    • staffing of Product Teams in accordance with the Team Topology as decided in the Product Vision
    • coaching
    • agreeing on and tracking (typically on a weekly basis) Team Objectives / OKR
      • 1-2 objectives per team spelling-out the problems they are being asked to solve
      • teams must propose clear measures for success (KR) and discuss with management

Product Team OKRs

Marty Cagen is very explicit when the use of OKRs makes sense:

OKRs are not for command and control. Do not use OKRs if you want to control people’s activities. Only use OKRs if you want to direct your people towards desired outcomes and trust them enough to figure our how. OKRs only works for empowered teams, otherwise they are a travesty (a travesty reminiscent of how Agile is implemented in most companies, so not that shocking, buy still upsetting).

Marty Cagan in Radical Focus second edition p. 165

Highlights on OKRs from Marty Cagan's books INSPIRED and EMPOWERED

Reading Marty Cagan’s books you’re left with the same conclusion as Christina Wodtke: the OKR framework is simple on the surface but hard to implement. Below is an attempt to cherry-pick OKR highlights from INSIPRED and EMPOWERED.

Good Objectives

    • Must describe problems to solve –  some are customer problems, some are business problems
    • Qualitative
    • 1-2 objectives (less is more) per team spelling-out the problems they are being asked to solve. Note: Enforcing Christina Wodtke’s point on the need for focus.
    • Will often require cross-team collaboration to achieve
    • Longer-term objectives need to be broken-down the work into intermediate product results

Good Key Results

    • Tells us how we define success
    • Must be defined by business results (outcome) – not just output
    • 2-4 KR per objective. The first KR is normally the primary measure
    • One or more KR as a measure of quality [guardrail / backstop KR] because the primary KR must not be achieved by hurting something else. Note: Christina Wodtke uses the term “Health Metrics” for these quality KRs
    • Best OKR comes in active dialogue with the team. Teams must propose clear measures for success (KR) and discuss with management with the purpose of ensuring a strong ownership in the team. Leaders to provide guidance on how aggressive the team should be in pursuing solutions
    • Be aware of the temptation for teams to define a KR that is easy to measure vs what is most meaningful to measure

Assigning work

    • We’re asking teams to solve (hard) problems – we’re not asking empowered teams, held responsible for the Outcome, to build features
    • It is the responsibility of the Leaders to decide which problems should be worked on by which Product Teams. Objective assignment often requires iteration with leadership and team contributing in a mixed top-down / bottom-up process. Note: As mentioned above, one of the pitfalls to be avoided is a top-down only cascading approach
    • The objectives are determined from the Product Strategy being part of the strategic context provided by Strategic Product Leadership. Four main reasons for the importance of sharing the strategic context (vision / strategy) with the team:
      1. The goal and the why
      2. We’ll assign work to those closest to the problem and with the needed skills
      3. Because we’re asking teams to solve problems, the teams must take responsibility and be accountable for the desired outcome
      4. Teams are provided space for and empowered to Discover the right solution for the problem
    • An empowered product team will not stop (as a feature team would) if first solution does not work … it’ll continue to iterate
    • Teams are not “only” responsible for team objectives – critical fixes, responding to customer issues, providing assistance to other teams, technical debt etc. are also included. Marty Cagan calls this “keep-the-light-on” work
    • It is a leadership responsibility to set the level of ambition (in Discovery work), which is all about risk-management ranging from “roof-shots” to “moon-shots”. Leadership needs to communicate very clearly on this level of ambition
    • Sometimes high-integrity commitments on dates are required from the Product Team. High-integrity commitments must be the exception; not the rule (which would bring us back to the roadmaps)

Product Vision and -Strategy as the context of planning OKRs

Product Vision

The Product Vision serves the purpose of

    • providing meaning
    • keeping us focused on the customer
    • acting as a North Star providing the overarching / common goal / larger purpose across the organization
    • helping teams understand how their work contribute to the large whole
    • inspiration for ordinary people to create extraordinary products (note the sub-title of Marty Cagan’s EMPOWERED)
    • providing enough clarity enabling the product organization to have an architecture in place – but – do not build a full architecture in one massive effort (start with a Minimum Viable Architecture)
    • a primary driver for deciding the team topology; especially the platform teams are heavily impacted by the vision & architecture
    • an evangelism tool

Elements in the creation of the Product Vision

    • leverages industry & technology trends
    • if done well, it’ll be compelling, inspiring and empowering
    • needs not to be too detailed / prescriptive which can be a challenging balance
    • has a 3-10 years scope
    • is owned by The Head of Product – sometimes called the Chief Product Officer [CPO]
    • includes a description of the future situation which could include conceptual high-fidelity prototype (realistically looking but only smoke & mirrors), video, storyboarding, prototypes used in product discovery etc.

What the Product Vision explicitly is not

    • a roadmap of features & projects
Product Strategy

The Product Strategy serves the purpose of

    • guiding which problems should be solved

Elements in the creation of the Product Strategy

    • tough choices on what is really important (the important focus as highlighted by Christina Wodtke)
    • generation of insights
      • quantitative insights: Product data, hypothesis test on data
      • qualitative insight: User research
      • evaluative insight: Result from tests
      • generative insight: Did we uncover new opportunities?
      • technology insights: The empowered engineers are often the best to spot new enabling technologies
      • industry insights: E.g., follow the best industry analysts
    • active management (Servant Leadership not to be confused with micro-management): The product leaders must connect the dots / insights in various ways resulting in action; that is, which team should solve which problem (the Objective in OKR)
      • remove impediments
      • 1:1 – weekly tracking (e.g., OKR) and coaching

Logically the Product Strategy can be seen as a four-step process;

    1. focus, that is select a small number of truly important company objectives driving the Product Strategy
    2. generate insights
    3. action by deciding which Product Teams will work on which Objectives (Problems), allowing a mixed top-down and bottom-up approach
    4. active management

What the Product Strategy explicitly is not

    • a blank check for the teams to do what they prefer to do

Example OKR process with inspiration from EMPOWERED

This fictive company is a job-portal, serving companies and job-seekers.

Example organization

Examples of some of the team OKRs are shown here:

Example Team OKR

OKR and Agile frameworks

OKR is based on cycles with different frequencies. So are the various flavors of Agile frameworks. We’re not here to have meetings for the sake of meetings because some framework bible says so. We do not want two overlapping framework tracks with OKRs and some Agile framework. Our aim is to find a balance creating synergies.

OKR and Scrum

The rhythm in Scrum “classic” is given by the its ceremonies, most of (Product Backlog Grooming is not shown) which are found here:

Scrum Framework
    • Sprint: often 1-3 week timeboxed
    • Sprint planning: before a sprint starts, the Scrum Team together with the Product Owner (being the one owning the Product Backlog) sets the goals for the sprint and the activities to achieve these goals as Sprint Backlog Items [PBI]. Note: before the sprint planning meeting the Product Owner might have arranged a Product Backlog Grooming session
    • Daily Scrum: as the name says – daily (short) meetings
    • Sprint Review: each sprint ends with this review in which the team elaborates over / shows the achievements
    • Sprint Retrospective: will often be held directly after the Sprint Review with the purpose of structuring newly gained insights to be integrated in the next sprint; making the team perform even better

Below is a suggestion on how to merge the OKR and Scrum frameworks in a pragmatic way:

OKR and Scrum cycle

Pragmatism:

    • by only having OKR ceremonies every 2nd week
    • by having the OKR ceremonies merged with the Scrum Review and Retrospective ceremonies during the OKR cycle

Team ChallengeFor each OKR cycle the individual (product) team faces the challenge to meet the agreed OKRs by planning and executing the right work in the six sprints within the OKR cycle.

As elaborated earlier in this post, it is a product leadership / management responsibility to agree OKRs with the product teams for each OKR cycle.

Teresa Torres, Marty Cagan and others describe the product team as “a trio” with a Product Manager, A Product Designer and a small team of Engineers. As described to great depth in INSPIRED and EMPOWERED, the Product Manager role is an especially challenging one. Note that we do not have a Product Manager and a Product Owner. The role as Product Owner is a part of the much larger role as Product Manager. As Marty Cagen outlines here, far too many organizations erroneously believe that getting certified as a Scrum Product Owner at the same time enables the person to act as a Product Manager. 

Role

Primary responsibility

Product Manager

Solutions are valuable and viable.

Product Designer

Solutions are useable.

Engineers

Solutions are feasible. In some cases you’ll find senior level engineers taking the role as Tech Lead with additional responsibility of participating in the ongoing product discovery work.

Dual-track agileFor each sprint the team will agree which items from the Product Backlog (owned by the Product Manager) to pull into the Sprint Backlog. As described earlier – like here, the product team will typically have a dual-agile approach, iterating between Product Discovery and Product Development. Some teams prefer “pure” sprints with either Discovery or Development. Other and more mature / experienced teams are able to shift focus between Discovery and Development within the same sprint. Under all circumstances the team has a guiding star in their OKR set.

In organizations having grown beyond the start-up stage, the Product Managers can reach a stage of saturation with (project management like) activities impeding their primary focus. Some organizations mitigate these impediments by introducing Delivery Managers.

Delivery managers are a special type of project manager whos mission is all about removing impediments for the team. Sometimes, these impediments involve other product teams, and sometimes they involve non-product functions. In a single day, they might track down someone in marketing and press them for a decision or an approval, coordinate with the delivery manager on another team about prioritizing a key dependency, persuade a product designer to create some visual assets for one of the front-end developers, and deal with a dozen of similar roadblocks.

These delivery managers are typically also the Scrum Masters for the teams (if they have that role).

If your company does not have delivery managers – by whatever title – then this work typically falls to the product manager and the engineering managers.

Marty Cagan, INSPIRED p. 91-92

Shift focusThe product trio supported by the delivery manager must be able dynamically to shift focus between the OKR level and the very specific now and here Sprint Backlog activities.

OKR and Kanban

The comments are basically the same here as for Scrum; the big difference is another set of ceremonies.

Scaling

This is a subject responsible for numerus wildfires on social media. Try Google “scale Agile”. According to Marty Cagan, we’ll find basically two and very different approaches to scaling:

Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.

One is by scaling their leaders (the managers). The other is by scaling their process.

Marty Cagan

It is no secret that Marty Cagan is a firm believer in the first approach – scaling by leaders/managers (read his books) – and definitely not a fan of the latter. He is not alone:

A particularly unfortunate form of “branded Agile” concerns scaling frameworks. A worrying variant is the Scaled Agile Framework or SAFe. Essentially this is codified bureaucracy, in which the customer is almost totally absent. It is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done..Steve Denning, Understanding Fake Agile

There is no correlation between the size of the organization and it’s approach to scaling. The FAANG (Facebook, Amazon, Apple, Netflix, and Google) companies are definitely big, but they scale (primarily) by leaders / managers. They are all digital natives and grown out of a startup environment.

In contrast you’ll find a lot of other high-tech companies definitely having chosen the path of “scale by process”. My experience is that these companies often come from a classic production mindset and are definitely not digital natives. Having seen the writing on the wall, these companies have entered a digitalization catch-up game. Many of these organizations have chosen to use SAFe.

Implementation strategy

RipplesAs concluded earlier, implementing the OKR framework is not easy and calls for a well-thought implementation strategy. As mentioned in numerous posts in this BLOG (like here), a well-proven strategy is to start small with an experiment, and have the change ripple from there.

Some organizations will find it hard even to design and run such an experiment. Others, like a product-led company with a strong Product Culture, will find it much easier because running disciplined experiments is an integrated part of their modus operandi.

A simple yet strong way forward is to have a, carefully selected, team use the OKR framework. Their success is the most convincing argument you’ll ever find for other teams wanting to join the ride.

OKR Tools

On the long run you’ll undoubtedly benefit from a strong IT tool. But – start pragmatically with e.g., a whiteboard / excel file making you focus on learning the framework; not the tool.

Inspirational sources

A lot have been written about OKRs and the best way to use the method. In my list of inspirational sources, you’ll find e.g., these books addressing the topic:

Measure what matters
INSPIRED
Radical Focus 2nd edition
Radical Focus 1st edition
Build Trap

At a TED Talk in 2018, John Doerr (author of Measure What Matters) provided the essence behind the OKR method:

OKR is not the only strategy framework around

Yes – OKR has become very popular in high-tech and fast moving product organizations, but not the only student in the class. Just to mention a few:

    • The Balanced Scorecard 
    • Hoshin Planning
    • Objectives, Goals, Strategies, Measures [OGSM]
    • KPI
    • The 4 Disciplines of Execution [4DX]
    • …

OKR nor any alternatives are silver bullets. They each come with pros and cons. A future post might dig into the various strategy frameworks – and how to combine them.

Posted on

Intrinsic Motivators and Servant Leadership

Motivated

Generally speaking we’re as humans driven by a few intrinsic motivators

    • The deep feeling of a (higher) purpose
    • Being part of a team
    • Providing results and making a difference
    • Having a genuine influence on the decisions
    • Doing real and value-adding work – in contrast to pseudo work in a highly bureaucratic organization
    • Having the opportunity to grow – professionally and personally
    • Fear – for not being good enough, the unknown, loss, failure, getting hurt, death, loosing control, being alone, facing rejection, being inadequate … and the list goes on.

All these motivators are directly linked to the discipline of Servant Leadership which in itself is the foundation for strong and highly motivated teams.

The purpose with this post is to illustrate the link between these intrinsic motivators, Servant Leadership and motivated teams.

Servant Leadership

Servant Leadership

In the earlier article on the importance of missionaries and a strong product culture, you’ll find a direct line to Servant Leadership. And yes – simple on the surface, but extremely challenging in practice!

Strong and highly motivated teams

It takes time to build a strong and highly motivated team which is one of the core reasons why product-led organizations use stable product teams in contrast to ad-hoc project teams. The model below can be used for ad-hoc project teams though the latter part “ready to continue as a team” becomes void. The real benefits are seen with stable (product) teams.

The rationale behind this Team Performance model is to build and maintain strong teams.

    • WHY-WHO
      This first part is traversed faster and faster for each iteration due to exactly the continuity. 
    • WHAT
      For a product team this would be a (hard) business / customer problem.
    • HOW
      This is e.g., the product discovery in product teams finding the best solution to the problem.
    • DISCIPLINED-FLOW
      Solution implementation. Note the iteration to HOW as knowledge is gained in execution.
    • STRONGER
      The team has matured and gained new knowledge and insights making it even better prepared for the next problem to be solved
Strong team

Inspired by the Drexler/Sibbet Team Performance Model ®

Posted on

Coaching and the world of rabbit-holes

Coaching

We’ve all had that repeated feeling – tumbling-down a rabbit hole of complexity only to conclude that the GPS signal is lost. 

Rabbit hole

We’re like Alice in Wonderland in the search of where to go. Alice encountered the Cheshire Cat, hoping that it could coach her in the process of deciding where to go.

Alice – “Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where—” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“—so long as I get somewhere,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.” —

Alice in Wonderland: Dialogue between Alice and the Cheshire Cat

Cheshire Cat

The ambition with this post is to discuss strategies for coaching people maneuvering a landscape filled with deep rabbit holes – and hopefully be of more help than the Cheshire Cat.

Coaching

The importance of coaching is not new, but might have been underestimated. If you haven’t already done it, read Marty Cagan‘s important book EMPOWERED focusing a lot on exactly that – coaching (the whole Part II is reserved for this single topic). 

Marty Cagan is clearly a big fan of Bill Campbell (coach to Steve Jobs and other Silicon Valley leaders), quoting him in the book:

Coaching is no longer a specialty; you cannot be a good manager without being a good coach.

Bill Campbell

In essence coaching is about helping people grow competences in a given field – personal or professional.

There is unfortunately no shortcut escaping the hard work and pain growing competences – just like the kid learning to ride a bike … but coaching can help accelerate the process:

    1. The young kid is blissfully unaware of the hard fact: it cannot ride a bike.
    2. First time on the bike resulting in bruised knees: now the kid is painfully and consciously aware of not being able to ride a bike.
    3. Luckily the kid has a coach – dad – helping to gain balance. Now the kid just barely is able to ride the bide without falling-over: very conscious about the newly gained competence.
    4. As time goes the kid effortlessly rides the bike: it has become unconscious about the bike-riding competence.  
Competence matrix

Coaching people in a complex and fast-changing environment

Yes – I know – the field of coaching is a deep rabbit-hole in its own right. This post will not

    • attempt to survey the huge amount of general coaching literature
    • focus on specific frameworks – read e.g., Coaching Agile Teams

Based on my own experience, I’ll here share the essence of what I’ve learned has worked in a fast-moving and complex environment with highly educated and bright people.

Let's set the scene

The individuals being coached here are specialized in their field being Product Management, Project Management, Product Designer, Software Specialist etc. For the coach to be effective, he/she needs to have been there and done that.

You do not want to be (professionally) coached by a person having taking all the right coaching educations and having read all the right coaching literature, but not having a deep understanding of and experience in the subject.

Being a manager you’ll easily yourself get caught in rabbit holes, making it important remind yourself what your priorities are.

If you are a manager, you should spend most of your time and energy on coaching your team.

Marty Cagan, EMPOWERED page 34

As outlined earlier, coaching is an integral part of the larger discipline being Servant Leadership.

Strategies

First I’ll share some general recommendations and tools. Secondly, to be specific, I’ll provide an example scenario.

General recommendations and tools

In lack of a better word for the person being coached, I’ll use the term “coachee”.

Recommendation #1

If you’re like me, talking (too) much, it is imperative to remind yourself of the fact: you have two ears and one mouth meaning you should listen more than talking.

Recommendation #2

Remind yourself of Steve Job’s wise words:

It does not make sense to hire smart people and tell them what to do. We hire smart people to tell us what to do.

Steve Jobs

Being highly knowledgeable and experienced in the subject, it is very tempting to serve the solution. Don’t – you’ll deprive the coachee from an important learning process.

Recommendation #3

Do not make coaching something academic a using a smart coaching terminology (it is ok and beneficial to read the endless list of coaching literature, but keep the smart models and terms where they belong – in the books).

Recommendation #4

Do not get caught by the “Agile Coach” /  “Scrum Master syndrome” celebrating that you now have 287 variations of how to facilitate a sprint retrospective (of course using your own nice hand-drawings – oh no, never use Power Point.. ). NB This type of Scrum Master has too much free time – let him do some coding instead!

Keep it Simple, Sweet and to the Point. Do not distract the coaching process with “smart” facilitation.

Feel free to survey the endless list of coaching tools and methods. Professional coaching is not rocket science. It only takes a few – but important – elements

    • Be authentic and have an honest intention to help the person / team to grow
    • You need to have been there and done that yourself (e.g., how can you coach a Project Manager, if you’ve not acted as one yourself?)
    • Have a toolbox with a few but strong tools –  do not go crazy with exotic techniques – see Recommendation #4

Tool #1
Five key questions

You need to uncover what is at stake – what is the point to address. Five questions help you uncover that:

    • WHO?
    • WHAT?
    • WHERE?
    • WHEN?
    • HOW?

You job as a coach is now to help your coachee identify, what is at stake.

Tool #2
Visualization 

The closest thing we come to time-travel, is our cognitive capacity enabling us to visualize a future state in time. This is a very strong tool used in e.g., elite sports and project management (as outlined here).

You as a coach can help the coachee to see the big picture and to spark creativity on how to approach a challenging situation.

One specific approach is the written narrative.

The technique I’m talking about is writing out a narrative explaining your argument and recommendation. 

Marty Cagan

Example scenario

You’ve hired a young and fairly unexperienced Project Manager (now called your coachee). She does have a lot of education and theoretical insight, but lacks practical experience. 

Your organization has been through a process, aiming for a Minimum Viable Process Prescription combined with a highly versatile Pick & Use Toolbox.

Your coachee has come to you feeling stuck, not knowing how to get her primary stakeholders on the same page. “What they ask of me points in all directions” she says and brings attention to the Project Process Model – “I’ve searched through the processes, templates and checklists without any luck – I’m stuck, and I’m honestly a bit intimidated by these senior stakeholders“.

This is a classic example of an unexperienced Project Manager being too dependent on process prescriptions telling her what to do. She has jumped into a rabbit hole only to loose a sense of direction. Your job as a coach is to help her regain signal on her GPS.

Using Tool #1 you help her become specific and concrete on the issue blocking her. That process alone is very helpful for her – just explaining the problem triggers her to think in terms of solutions.

Now having uncovered the core problem and having considered solution alternatives, you facilitate a visualization process using Tool #2. “Let’s imagine that you’ve called the stakeholders to an alignment meeting and apply the solution approach we just talked about, what will happen?“, you ask – “how can you come prepared to the meeting without feeling intimidated?“

You’ve got the point by now. Layer by layer you peel the onion until your coachee has gained confidence what to do – she has a strong signal on the GPS again! 

Wrap-up

You as a leader / manager have an important responsibility, coaching your employees / teams. The trick is to keep it simple, sweet and to the point.

Posted on

Balances and the forces of complexity

Spinning Balance

The balances and the forces of complexity are all around us:

  • Invest vs consolidate
  • Bureaucracy vs humanocracy
  • Technology standardization vs freedom to chose
  • Build vs buy
  • Risks vs opportunities
  • Centralization vs decentralization
  • Dictate vs empowerment
  • In-source vs out-source
  • ...
Spinning top

With the constant changes in technologies and markets, organizations never find a steady-state. What was a working balance yesterday, might be thrown out-of-balance tomorrow.

Or put into other words: the balance needs constant adjustment not to fall over like the spinning-top needing maintained spin. Our job in our organizations is to understand and maintain these balances in ways working for us in our unique context.

The ambition with this post is to discuss the technological and organizational balances and the forces of complexity

Types of complexity

In an InfoWorld article you’ll find Justin Etheredge, cofounder of the software agency Simple Thread, provide the differentiation between “essential complexity” and “accidental complexity”:

Essential is the complexity in the business domain you are working in, the fact that enterprises are extremely complicated environments, so the problems they are trying to solve are inherently complex. 

The other area is accidental; this is the complexity that comes with our tooling and what we layer on top when solving a problem.

Justin Etheredge in InfoWorld, November 1st 2021

There is no reason to believe that the “Essential complexity” will flatten-out or even decrease. Global market forces will keep fueling it. What we can do, to some extend, is influence / mitigate the “Accidental complexity”.

Roughly speaking we have a few options available, dealing with “Accidental complexity” like

    • the way we organize and facilitate work in e.g., networks of highly aligned but loosely coupled teams 
    • encapsulate knowledge e.g., providing a higher-level of abstraction
    • enforce standardization and whitelisting of a narrowed-in technology selection

The notion of complexity encapsulation with higher-levels of abstraction is not new. It is all around us

    • when you turn-on the water tap
    • when you connect your computer to the internet
    • when you turn-on the engine in your car
    • when you flip the light switch
    • when you enjoy the inflight meal
    • when you compile a piece of source code
    • when you send an email
    • when you open a bottle of beer (yes – a lot of high-tech is behind a bottle of beer)
    • …

Our society and way of life is based and dependent on these high-level abstractions enabling us to leverage the vast underlying complexity.

Trend: explosion in IT permutations and feature-expectations

As discussed earlier, the IT-developers of today are facing a situation

    • on one side having more tools, services, frameworks etc. at their disposal than ever before. As Camille Fournier (head of platform engineering at Two Sigma) said in an interview with InfoWorld:

You are like a kid in a candy shop in the Cloud.

But as you grow and try make things fit together, the complexity absolutely multiplies.

Camille Fournier, head of platform engineering @ Two Sigma

    • and on the other side extreme challenges navigating the complexity explosion:

The shift from building applications in a monolithic architecture hosted on a server you could go and touch, to breaking them down into multiple microservices, packaged up into containers, orchestrated with Kubernetes, and hosted in a distributed cloud environment, marks a clear jump in the level of complexity of our software.

Add to that expectations of feature-rich, consumer-grade experiences, which are secure and resilient by design, and never has more been asked of developers.

InfoWorld, November 1st 2021

Encapsulation of technology complexity and higher-level abstraction

Just as you cannot expect the normal driver to understand all the complexity under the hood making the car move, you cannot expect the individual developer to know and stay updated on all the technological details in a high-tech product.

We need as individuals and organizations to decide on the balance between knowing all the intricate details and “just” being able to leverage the technology via higher-levels of abstraction. Again – this is not a new concept – even for highly skilled developers. E.g., an IT developer will use

    • C# (normally) without needing to understand exactly how C# is implemented
    • libraries, Cloud services etc. via APIs
    • …

But – abstracting each piece of the puzzle is no longer enough. Especially with the explosion of Cloud-services (see e.g.,  AWS’ Marketplace or the vast number of CNCF open-source projects), we need consolidated abstractions across abstractions. This multi-level abstraction is exactly on of the purposes behind an Internal Developer Platform [IDP].

In The IT Project part two – seen from a Technology perspective two examples on IDP were shown. Humanitec, being one of the IDPs, provides a balanced discussion on the IPD in the post What developer self-service shouldn’t look like. As cited below, it is (as always) a matter of striking the right balance; right meaning what is best in your specific context.

Developer self-service is the best thing that can happen to a team. “You build it, you run it” is what you would want for your engineering team. It’s setting the right incentives, unblocking developers, reducing cognitive load. Developer self-service means striking the right balance between overwhelming people by letting them operate everything and restricting them by building abstractions. 

Humanitec BLOG, August 27th 2021

Trend: the never-ending stream of framework / method Silver Bullets

Since Frederic W. Tailor, Max Weber and Henri Fayol we’ve seen new Silver-Bullet attempts again and again to harness the wild beast: how people work together. Add to that the never-ending list of “management literature”. My own humble list is just a tiny fraction.

This is of course great for the consulting industry and let’s face the uncomfortable truth: this will continue forever for the simple reason that you cannot put human behavior and interaction on a formula. 

Which is best (you’re right – a nonsense question)?

    • PRINCE2 ©
    • Scrum
    • SAFe
    • Scrum@Scale
    • Kanban
    • Half Double
    • Update: AGILE FLUENCY® MODEL
    •  …

or – here we go again – the latest Silver Bullet: FAST Agile from Fluid Scaling Technology:

FAST AGILE

Made in and for the Age of Disruption.

FAST harnesses the same creative organizing force of the universe itself
– self-organization.

FAST combines Open Space and Open Allocation to create a lightweight, simple to understand, and simple to master agile method – that scales!

Fluid Scaling Technology

In addition a pleasingly small (19 pages in version 2.1) FAST Guide is provided. How cool is that. For those of you like me being a big fan of Marty Cagan, FAST is seemingly directly facilitating the product-led approach detailed be Marty Cagan:

FAST aims to cater to Product Development as defined by Mary Cagan in his book Inspired. This represents a different way of working for software developers used to other now-traditional agile methods that are heavily focused on delivery only.

“A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives. They are empowered to figure out the best way to meet those objectives, and they are accountable for the results.” (ed.: quote from INSPIRED)

Fluid Scaling Technology

And yes – you guessed it: FAST comes with new definitions of values, roles, artefacts, meetings, principles for scaling …

Sorry, not even this latest of the greatest – FAST – will save you with the perfect balance for the same reason that all frameworks / methods fail: you cannot codify human behavior and interaction. 

In this article from Agile Alliance, Ron Quartel actually attempts such a codification:

I tried to codify the system, and we named the system Fluid Scaling Technology with the acronym FAST.

Self-Organization Eats Agile at Scale for Breakfast section 7.2 by Ron Quartel @ Agile Alliance

Encapsulation of organizational complexity and higher-level abstraction

Force frameworkYou can chose the seemingly easy route and adapt an already-made cookbook prescription forcing a framework over your organization. This is what has happened in a significant number of companies going all-in with SAFe.  

Just recently I attended a network meeting around Agile with representation from big (and successful) high-tech companies having attempted just that: adapted SAFe “by the book”. One of the representatives made it crystal clear:

“We do not want or have the time to survey all the frameworks/models available and adapt relevant parts – we use the SAFe roles, definitions, processes, artefacts etc. explicitly to form our organization and agile way of working” 

Let’s call this the “Brute-Force” approach.

Alternatively you can chose to do your homework, understanding the growing number of frameworks / models and have that insight combined with a detailed understanding of your unique context. Let’s call this the “Cherry-Picking” approach.

No matter what approach you chose, the purpose remains the same: encapsulate organizational complexity in a way enabling us to operate on a meta-level … the higher-levels of abstraction.

As outlined earlier, strict processes can be very helpful but also harmful:

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.

Jeff Bezos

First, I can’t help but notice that so many of these process people have never performed either the maker role or the manager role in a strong product company.  They have more enthusiasm than experience or knowledge.  Not only does this put exactly the wrong people in control of how teams work, but these people are prime targets for the armies of consultants and vendors that have figured out that these people are their best path into your company.

Second, in many cases, these process people are hired because the managers are not willing or able to do their job – especially in terms of coaching and developing their makers.  If that’s what’s really going on, then that is the problem that must be fixed.  A process person is a very poor substitute for a strong manager with the necessary expertise.

Third, process is a lot like religion.  People get fanatic about their favorite processes, and it’s very difficult to reason with a fanatic.  (As a side observation, my theory is that since these process people aren’t makers or managers, they tend to have more free time than the rest of us, and many tend to spend a good portion of that time on social media preaching their particular religion).

Marty Cagan, October 2021

Wrap-up

Technological and organizational complexities are here to stay for good and bad. What differentiates you from your competitors, is your ability to find and maintain the balances unique to you in a way best serving your business.

Posted on

The IT Project part two – seen from a Technology perspective

IT Project technology

This is part two in the series of two posts, discussing the Technology perspective. Missed part one? Find it here.

We’ll in this post discuss the Technology perspective in IT Projects.

The technology perspective - a double-edged sward

The technology perspective is not only a deep rabbit hole – it’s a double-edged sward on the one side offering nearly unlimited solutions to (digital) problems.

On the other side we’re presented with a growing cognitive load. Even the brightest and hard-working full-stack developer has no chance to stay on top of all technology permutations. This (potential) cognitive overload can and has to be handled.

IT as business enabler

Here are just a few of the opportunities and challenges faced by today’s IT-organizations:

    • Facilitate a strong alignment between autonomous teams
    • Facilitate encapsulation of complexity like services (see e.g., Backstage) and operations (like Serverless)
    • Making it easy to do things the best way and as standardized as possible (Spotify uses the notion of The Golden Path)
    • Automate processes like Continuous Integration / Continuous Deployment [CI/CD] 
    • Facilitate transparency with e.g., an Objectives and Key Results [OKR] system and various other metrics
    • The world of Cloud Computing offers an explosion of advanced services for the IT solutions themselves and for a fine-grained API-economyPublic API
    • Often we’ll have to manage a multi-context environment with e.g., AWS, Azure, on-prem Cloud (like Open Stack), ERP, PLM, MES, classic “monolith” legacy systems …
    • Cloud architectures can be based on (a lot of) microservices requiring e.g., a Kubernetes orchestration 
    • Container technologies like Docker provide portable application development
    • …

The challenge with cognitive (over-)load

Over the fenceClassically an organization would do development in one branch, “throwing the result over the fence” to another branch doing operations.

DevOpsA more modern approach is known as DevOps (a contraction of Development and Operations) having a team own the whole ting. The principle is “you build it – you run it”.

Using DevOps we avoid “throwing the result over the fence” thereby increasing the speed-to-operation.

But – we’re still using time in the DevOps team to handle operational complexities related to the operations infrastructure. 

Note: Because (cyber-) security is a growing concern, the trend is towards DevSecOps.

DevSecOps automatically bakes in security at every phase of the software development lifecycle, enabling development of secure software at the speed of Agile and DevOps.

DevSecOps represents a natural and necessary evolution in the way development organizations approach security. In the past, security was ‘tacked on’ to software at the end of the development cycle (almost as an afterthought) by a separate security team and was tested by a separate quality assurance (QA) team.

IBM

The Holy Grail is to have the developers spend as much time as possible on developing value for the business / customers and as less time on infrastructure as possible. 

YAMLVirtualization (like virtual machines and container technologies) and Cloud technologies have improved that a lot with e.g., modelling infrastructure in configuration files. This is call Infrastructure as Code [IaC] (using e.g., YAML files). The infrastructure code is under version control and integrated in the full configuration. 

The DevOps team thus “only” have to configure the operations infrastructure as code, but it still needs a deep understanding of operations dynamics for it to create and maintain the infrastructure code.

Ultimately the DevOps team can spend little time on operations and focus on developing code. 

AWS Serverless5+ years ago a new computing paradigm saw the light of day, and was coined the Cloud Serverless Architecture. Not that there are no servers, but that the operations complexities became fully encapsulated. All the major Clouds providers (Amazon – AWS, Microsoft – Azure and Google – Google Cloud) have and mature Serverless services.

A simple Cloud architecture using AWS’ Serverless compute service, Lambda, is shown to the right. Understanding the full implications of Serveress is a big topic in itself, but here are some highlights:

    • 100% operations encapsulation (though you of course still have to design and optimize your application not to consume more resources that needed!)
    • pay only when used
    • automatic service provisioning and scaling – no worrying about capacity provisioning and de-commissioning
    • ideal for burst-usage and / or for unpredictable usage patterns
    • can potentially become very expensive to use if you’re not understanding, how your application consumes resources

Serverless is not a Silver Bullet. Its is one of the options to consider. Depending on the usage-profile, a non-serverless architecture can be a better / cheaper choice.

The Internal Developer Platform

The technology in itself – as e.g., an Internal Developer Platform [IDP] – can help

    • gain and maintain an overview
    • do things the best, most efficient and standardized way
    • encapsulate complexity

IDPTwo examples of an IDP are

    • Backstage
      Backstage originates from Spotify having made it available as open-source. It was accepted in the Cloud Native Computing Foundation [CNCF] Sandbox September 2020.
    • Humanitec
      The Humanitec IDP is a fully matured commercial product (with a free Community edition)

To be concrete the following will use Backstage as the concrete example of an IDP.

Can you spare the time, this video helps understand an IDP in general and Backstage in particular.

Backstage public adaptersToday [November 2021] Backstage has gained momentum having 50+ public adapters. Rather impressing!

As you might recall from part one, the Platform Team is one of the four suggested team-types. Some companies are taking it one step further seeing the platform as a product (yes – with a Product Manager) clearly signaling its importance. 

Have a look in EMPOWERED.

An emerging trend is that a growing number of companies are working to manage their internal platforms more like external platform products

Marty Cagan, EMPOWERED page 222

IDP (Backstage) - why use it?

An engineer should not have to be an infrastructure expert to be productive!

The infrastructure should be abstracted away from you, enabling you to focus on delivering code / business value.

Backstage is a one-stop-shop to find

    • all your tools
    • all the technical documentation
    • all the teams – who is doing and being responsible for what

Backstage helps

    • standardizing the way software is created in an opinionated (good practices in Spotify) way supported by templates (e.g., how to create a micro-service) – a one-click fully functional microservice with everything like CI/CD, documentation etc.
    • recuse the same technology stack – making it easy to do the right/best thing – also called a Golden Path

Spotify

IDP (Backstage) - what is it?

Backstage has three main areas

    • Service Catalogue
    • Service Definitions
    • Integrated Tooling via Plugins

Backstage

As explained in the video above, Spotify’s ambition with Backstage was/is to provide a “single pane of glass” for the developers. One of the neat tricks is the growing portfolio of tooling plugins allowing the developer to stay in Backstage (e.g., not having to context-switch between a multitude of systems / platforms).

Modern architectural patterns

The modern IT architecture

    • uses a microservices-based distributed pattern
    • uses a combination of sync / async-driven communication (e.g., Apache Kafka)
    • will automatically up- and down-scale infrastructure capacity
    • is build on redundancy with automatic recovery
    • supports a fully automated CI/CD pipeline 
    • wants to keep things as simple and fast as possible (e.g., preferring REST over SOAP) 
    • supports an easy-to-use service-discovery
    • provides transparency and debugging capabilities into operations, including easy-to-rollback
    • provides a rich environment on which to build an API economy and communities

These modern patterns are standing on – and having evolved from – past good practices like

    • the Enterprise Architecture Integration [EAI] bus with centralized business logic
    • distributed computing using CORBA, SOAP, XML ..
    • message-queuing like IBM’s WebSphere MQ

Wrap-up

More that ever, IT development is a team-effort for the simple reason that we as individuals do not stand a chance knowing everything needed to bring a solution from idea to full production.

The good news is that technology in itself helps us orchestra this delicate process. 

Posted on

The Project Manager – a thing of the past?

Project Manager - a thing from the past?

You might have noticed it: there is no “Project Manager” role in Scrum, nor in SAFe. Is that it then – end of Project Management?

The aim for this post is to have a nuanced discussion on the fate of the Project Manager.

Spoiler alert: the Project Manager role is alive … mostly … but new tricks are needed.

Context and competence

Let’s take a big step back, asking “what is the purpose of Project Management, Scrum, SAFe etc.?“. The simple answer is, that they are all means to achieve a given set of objectives. The principle is of course to chose the means best suited for the objectives at hand.

Context

Market matrixThese objectives are given by the context. Before even starting the discussion on the means, the context and thus the objectives need to be understood. As mentioner earlier e.g., here, the top-level context can be visualized as the matrix to the right.

The home for the classic project and thus the classic project manager is on the predictability-end of the optimization scale. Here you’ll typically find these characteristics:

    • High initial certainty on what the customer really needs at the end of the project
    • Scope is fixed and a detailed requirement specification is agreed
    • You’ll typically use a Requirements Management [REQM] tool enabling a bi-directional link between requirements, Verification & Validation [V&V] and the developed solution
    • A formal and structured Change Request process is agreed … because the reality is, that changes will happen
    • The approach strategy is often based on a sequential stage-gate model

At the adaptability-end of the optimization scale we find “Agile” practices. According to the various “Agile text-books”, the classic project manager role has lost its relevance. Here you’ll typically find these characteristics:

    • Low initial certainty on what the customer really needs at the end of the project
    • Scope is variable and the initial agreement is based on an initial set of (high- level) requirements and a vision for the to-come product / service
    • The “Agile Project” is based on ad-hoc Agile teams whereas in “Product Innovation” you’ll typically find stable, cross-functional and highly empowered product teams
    • High-frequency customer / user alignment
    • The approach strategy is often based on iterative learning / insight processes (using e.g., disciplined experiments) and incremental solution building in a way enabling frequent customer / user feedback loops

Competences

When confronted with the question “do you really not need the project manager?“, you’ll often hear answers like this from the Agile community :

“We do need a lot – not all – of the project manager competences … but we’ve mapped these competences in new agile roles thus no longer having a separate project manager role“

The three roles in Scrum thus need to cover the relevant competences in the project management toolbox. 

The product owner defines the what–as in what the product will look like and what features it should contain. The product owner is expected to incorporate stakeholder feedback to create the highest value product increments each and every sprint. Product owners maintain the product backlog and ensure that everyone knows the priorities.

The developers decide how to accomplish the work set forth by the product owner. Teams are structured and empowered to organize and manage their own work. The resulting synergy optimizes overall efficiency and effectiveness. Developers include anyone on the team that is contributing to the sprint goal.

The scrum master helps the scrum team perform at their highest level. They also protect the team from both internal and external distractions. Scrum Masters hold the scrum team accountable to their working agreements, scrum values, and to the scrum framework itself.

ScrumAlliance

In SAFe you’ll find a lot more roles between which to map relevant project management competences.

The key SAFe roles and main responsibilities at team level are:

    • Agile Team – responsible for delivery and quality of the work undertaken.
    • Scrum Master – responsible for ensuring the team works well and follows the processes.
    • Product Owner – responsible for prioritizing stories and ensuring they are well described and understood.

The key SAFe roles and main responsibilities at programme level are:

    • Product Manager – responsible for prioritizing features and ensuring they are well described and understood.
    • Release Train Engineer – responsible for ensuring the agile release train (the team of agile teams) work well together and follow the processes.
    • Customer – consumes the output from the agile release train. Could be external customers or people within the organization. The customers are the people who will have the final view on whether the output was valuable.
    • Business Owner – key stakeholders who are ultimately responsible for the business outcome.
      System
    • Architect/Engineer – responsible for designing and sharing the architectural vision across the agile release

The key SAFe roles and responsibilities at the solution level are:

    • Solution Manager – responsible for prioritizing capabilities and ensuring they are well defined and understood.
    • Solution Architect/Engineer – responsible for designing and sharing the architectural vision across multiple agile release trains, which means the solutions delivered will be fit for purpose.
    • Solution Train Engineer – responsible for facilitating and guiding the work done by all of the agile release trains delivering the solution.

The key SAFe roles at portfolio level are:

    • Epic Owners – responsible for defining an epic, articulating its benefits and facilitating its implementation.
    • Enterprise Architect – drives architectural initiatives for the portfolio.

Other key roles include:

    • SAFe Programme Consultant (SPC) – use their technical knowledge of SAFe to advance the organisation’s systems, and processes for developing systems. They are key to successfully implementing SAFe and often come from an internal centre of excellence or from an external consultancy. Agility in Mind has qualified SPCs as members of its consulting team.

agility.im

I’m not at this point entering the heated debate on SAFe, but you might want to find a short discussion here.

The future of Project Management

We’ll still se a lot of customer / user pains / desires most effectively being handled as a project with a project manager and an ad-hoc project team.

The reality is also that the business environment and the enabling technologies are changing at a speed often making the idea of a big-upfront-specification, void. Is the experienced project manager with a solid toolbox not able to handle such a dynamic context? Of course he/she is!

Project Management and Agile rolesThe Agile community wanted (my interpretation) clearly and strongly to divorce itself from the classic way of doing (software) projects. The project manager role represented the “old way of working” to an extend that it was not welcome in the Agile role definitions – not even as a variant.

The project manager in an Agile context will thus not find a 1-1 mapping between the classic project manager role definition and one of the new Agile roles. Many of his/hers competences remain highly relevant – but dispersed among a number of Agile roles.

Strategies for the Project Manager in an increasingly Agile world

Get used to the fact that more and more “projects” will not ask for a “Project Manager” in the classic definition. You need to educate yourself in ways making your competences match the needs in the Agile context. Need some inspiration? Check-out some of my inspirational sources.

From being identified by a role-definition as Project Manager …

The project manager is responsible for day-to-day management of the project and must be competent in managing the six aspects of a project, i.e. scope, schedule, finance, risk, quality and resources. Project managers work on specific projects that have definite outcomes, have time limits and have to stay within a budget.

These tasks typically include:

    • planning what work needs to be done, when and who’s going to do it;
    • looking at the risks involved in a particular project and managing these risks;
    • making sure the work is done to the right standard;
    • motivating the team of people involved in the project;
    • co-ordinating work done by different people;
    • making sure the project is running on time and to budget;
    • dealing with changes to the project as and when necessary;
    • making sure the project delivers the expected outcomes and benefits;

association for project management – apm

… you need to identify yourself with your versatile competence toolbox enabling you to meet the Agile context on its premises.

The role as Project Manager is not dead, but more and more business / customer problems / desires are best handled in ways not needing the stand-alone Project Manager role.

Posted on

The IT Project part one – seen from the Leadership perspective

IT Project leadership

This is the first in a series of two posts discussing the nature of the IT Project. 

We’ll in this post discuss the generally applicable characteristics of a modern IT Project seen from a Leadership perspective. This will be followed by a part two (update: here) taking the Technology perspective.

What is an "IT Project"?

Project technology sphereAn IT Project is a type of project with “just” one technology discipline – IT (in itself having a ton of different disciplines) – in contrast to multi-disciplinary projects including e.g., electronics, mechanics, physical production etc.

We’ll find IT Projects in a number of different contexts like:

    1. A Product Company developing own digital products
      Marty Cagan: “Great products solve real problems for our users and customers, in ways that our customers love, yet work for our business“
      Modern and successful digital product companies have a strong Product Culture with stable and cross-functional Product Teams empowered to find the best solutions to business / customer problems … being held accountable for the Outcome.
    2. A Solution Provider doing development on behalf of customers / partners
      Could be an outsourced project, based on an agreed requirement specification. The Project Teams in this context are measured on Output … they cannot be held accountable for Outcome.
    3. Organizations running internal IT projects supporting the business itself
      Typically anchored in an internal IT-department responsible for e.g., ERP, CRM, provisioning systems etc.

Scenarios 2 and 3 are very much alike, in that they apply a Service Mindset servicing the customer (note: not the real end-customer / user) or the business, and focus on ad-hoc Project Teams providing Output. These “Project Teams” can be everything from the very classic team to the super Agile Scrum team.

Scenario 1 is radically different applying stable and empowered Product Teams to serve the real customer and be held accountable for the Outcome. Here you’ll find a strong Product Mindset in a strong Product Culture.

The Leadership perspective

Project TransformationThe purpose for all projects including IT Projects is, logically speaking, to convert customer/user problems/desires to solutions meeting these problems/desires. 

In the classic / sequential/ Waterfall approach this would mean 

    1. Develop and lock a fully comprehensive requirement specification
    2. Develop a solution and verify that all requirements are met
    3. Deliver the solution to users / customers

In the “old days” it was actually realistic not only to build an upfront and fully comprehensive requirement specification. It was also realistic that the user’s / customer’s needs were stable making the solution relevant when delivered.

Today’s fast-moving business environment, combined with an accelerating technology innovation speed, often makes this approach void.

This is part of the project’s context within which you need to design an approach strategy minimizing risks and optimizing value.

Approach strategy

The contemporary answer to this type of IT-context is an approach combining iterative processes with incremental solution building. In their new worthy-to-read book Product Discovery, Marcus Castenfors & Martin Christensen provide us with these definitions:

Iterative means the repetition of a process to collect feedback and improve things for the next time around.

Incremental means taking small steps, working in small batches, with each increment buliding on top of what has been built before.

Product Discovery by Marcus Castenfors & Martin Christensen

The trigger

In one form or another, what triggers (also) an IT project, is a problem or desire being the core in the projects purpose. Realizing that creating a fully comprehensive requirement specification is neither realistic nor desirable, the process often starts with a vision combined with a few high-level requirements.

We’ll use the Time Machine together with the customer making a jump in time to the point, when we’ve just closed the project. Being a strong facilitator, you’ll help the customer to describe the situation, now meeting his problems / desires with the developed solution. This situational description, combined with a few important and high-level requirements, forms the vision / North Star for the project. As recommended earlier, you’ll benefit from also creating a hierarchy-of-objectives.

The three pillars on which to initiate the IT Project are thus

    • A clearly stated purpose
    • A strong vision with a few top-level requirements supported by a balanced hierarchy-of-objectives
    • An approach strategy

Did you, as part of your approach strategy, chose to use the Scrum framework in some variant, you (read: Product Owner) would drive getting the Product Backlog initiated based on the initial foundation – the three pillars.

This post will not unfold the Scrum framework itself in details. A lot of info is available – just Google it.

The Leadership role

Seen from a project team perspective, the best you can do a as a leader, is to adapt a Servant Leadership mindset paving the way for the project. I’ve previously given my take on a Servant Leadership definition:

Porpose

Provide meaning

Provide direction

Empowerment

Empower

Support

Support

Dual-track agile

The aim in all projects is to be 

    • effective building the right solution / product
    • efficient building the solution / product the right way

This translates into what is often called Dual-Track Agile:

    • Product Discovery – finding the right solution to develop
    • Product Development – implementing the solution

Dual-track agileHaving an iterative/incremental approach strategy, we’ll see the two tracks exist and interact in parallel.

The Development / Delivery track is at the core of Scrum. Product Discovery is a deep rabbit-hole in its own right. We’ll not unfold it here in details; just raise the awareness of its importance. Find more on the subject in e.g., these worthy-to-read books:

Your challenge is to decide what works best for you in your specific context. One of the obvious advantages running a purely digital project, is the avoidance of the physical constraints in multidisciplinary projects.

Strategic organization of the work

Here we’ll shortly discuss two related topics:

  • Team Topology
  • Cognitive Capacity

Team Topology

Team ToplogiesThe assumption is here that you need more than “just” one project / product team to get to job done; in fact you’ve identified a need for a network of teams. The big question is now how to find an optimal design of each team and their relation in the network. “Optimal” is not a text-book thing. “Optimal” for you is what makes best sense in your context.

Especially when talking software development, you’ll find the book TEAM TOPOLOGIES a valuable asset. I’m sorry to repeat myself, but here is yet another rabbit-hole to explore.

In essence, Mathew Skelton and Manuel Pais suggest a number of building blocks, based on four team types and three interaction modes.

The four team types:

    • Stream-aligned team
    • Enabling team
    • Complicated-subsystem team
    • Platform team

and the three interaction modes:

    • Collaboration
    • X-as-a-Service
    • Facilitating

Yes – it can seem like bit of a mouthful, but the book is far from academic. In fact – it is clearly written by practitioners having been there and done that.

Team Topologies provides a practical, step-by-step, adaptive model for organizational design and team interaction, treating teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity.

TEAM TOPOLOGIES

Cognitive Capacity

If you in some way are or have been involved in modern  software development, you’ll definitely appreciate the fact that a lot technologies exist out there. The advances in Cloud services have accelerated this universe making it virtually impossible to stay on-top of all innovations in IT technology. 

We as humans remain to have the same cognitive capacity meaning that one individual, say a full-stack developer, simply cannot know it all. Until we get some AI-implant in our brains, we have basically a few options to cope with cognitive overload:

    • Encapsulate knowledge and make it easily accessible via e.g., a Service Catalogue and/or Cloud technologies like Serverless computing 
    • Split knowledge / work between people / teams

We’ll return to the technology aspects in part two of this series.

Wrap-up

The approach to a modern IT Project is highly iterative/incremental because

    • the digital business environment is under constant pressure for change 
    • the underlying technologies are evolving at an exponential rate

Leadership’s ability to nurture the project execution environment and pave the way, is equally important as highly competent teams.

Stay tuned for the up-coming part two (update: here), with focus on the technologies in an IT Project.

Posted on

Balance between process prescription and flexibility

Prescription vs flexibility

Finding the optimal balance between process prescription and flexibility, is what all organizations are aiming for in their quest for excellence.

There is, however, no textbook-optimal balancing -point. What works best for you in your organizational context, will differ from  other organizations having their unique context.

The aim for this post is to discuss some of the factors influencing such a balancing-point in a project-oriented organization.

In a hurry? Jump directly to the wrap-up.

 

Before diving-in, here is a couple of quotes to get us up from the chair.

    • Process is a double-edged sward as expressed by Jeff Bezos:

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.

Jeff Bezos

    • This comment from Marty Cagan on “process people” also provides some input for reflection (note: what Cagan means by “maker” is a person doing the actual job – not just formulating processes for others to follow):

First, I can’t help but notice that so many of these process people have never performed either the maker role or the manager role in a strong product company.  They have more enthusiasm than experience or knowledge.  Not only does this put exactly the wrong people in control of how teams work, but these people are prime targets for the armies of consultants and vendors that have figured out that these people are their best path into your company.

Second, in many cases, these process people are hired because the managers are not willing or able to do their job – especially in terms of coaching and developing their makers.  If that’s what’s really going on, then that is the problem that must be fixed.  A process person is a very poor substitute for a strong manager with the necessary expertise.

Third, process is a lot like religion.  People get fanatic about their favorite processes, and it’s very difficult to reason with a fanatic.  (As a side observation, my theory is that since these process people aren’t makers or managers, they tend to have more free time than the rest of us, and many tend to spend a good portion of that time on social media preaching their particular religion).

Marty Cagan, October 2021

No matter the specific organizational context, the same goal applies: We want happy customers and a viable business!

How we get to that goal, is what differentiates organizations.

The Balancing Act

Given your unique context, the challenge is to find the optimal balance between process prescriptions (telling people how to do stuff) and trust (people will figure-out how to do stuff).

Let’s discuss a few balancing scenarios.

Scenario #1 - (very) high CMMI level

In this scenario, the prerequisite for gaining access to the customers is a very high and durable CMMI assessment (above level 3). Being able consistently to follow (and being able to prove it) and continuously improve project processes is key for this type of organization. It needs to have a stringent waiver-mechanism making it transparent, if a project needs to deviate from the established processes. This is the lean-machine / feature-factory mindset.

Balance

Here the balance is heavily to the prescription-side. Such an organization will typically have a very big and complex process-universe (recipe cook-book). 

In this type of scenario you’ll typically find a dedicated process-office with the purpose of developing and maintaining the process-universe – and do internal audits ensuring compliance to the processes.

Pros

Having and methodically following a  prescriptive cookbook ensures a high degree of predictability and consistency across projects.

If the domain is stable (e.g., “only” digital) and the nature of the projects are fairly similar, then you can expect significant lean-effects … like optimizing a production line.

Cons

It takes a lot of time and effort to build, mature, implement and maintain such a complex cook-book. 

For some people such a highly prescriptive universe can seem bureaucratic and even repulsive.

Failure is not really an option. 

Scenario #2 - a strong project culture

In this scenario the customers are not having e.g., a formal CMMI level as a prerequisite.

What is important for the customers here, is the company’s project culture and history being able to meet expectations. 

This project culture is based on a set of core principles and values:

    • a trust in people, providing psychological safety, that they’ll do the right thing without having to be directed by a detailed cookbook
    • a Minimum Viable process / governance prescription in exchange for a highly versatile Pick & Use Toolbox
    • knowledge is a shared asset developed and maintained in facilitated Communities of Practice [CoP] by the doers – not in some central process office

We’ll return to this Pick & Use Toolbox later in this post.

Balance

More trust in people than prescriptions telling people what and how to do stuff.

Pros

This people-centric approach, showing trust in people vs dictating strict process rules, creates engagement and motivates innovation.

Cons

If you are having an unexperienced organization and/or a poorly designed Pick & Use Toolbox, then the risk is high loosing control over the projects.

Scenario #3 - PRINCE2 © 

The customers in this scenario are subscribing to the PRINCE2© model, done “according to the bible“. These are typically government customers. Being excellent in that specific project management model is thus a fundamental prerequisite for the business.

PRINCE2 is a very rigid and highly controlled methodology (hence the name PRojects IN Controlled Environments). It is a stage-gate model with a lot of processes, components, techniques etc. covering project management. It does not cover the actual delivery work. You’ll want to have a solid reason (like a prerequisite in the market) for investing in such a heavy model. 

In all fairness – should you not find it relevant to invest in PRINCE2, then you’ll still be able to benefit from elements like e.g., the strong technique, Product-Based Planning.

Balance

The model is highly prescriptive on the project management level. How (delivery) work is actually done, is out-of-scope in PRINCE2.

Do not buy the argument “we’re not special – we can buy / adapt a general process”. The fact is that your organization is special with its unique context. No silver-bullet exists (not even PRINCE2).

Pros

If what your customers expect from you, is excellence using PRINCE2 the right way, then you have a strong sales argument. Go for it!

Cons

People agitating the use of PRINCE2 will down-play the size of the PRINCE2 manual with the argument “you can tailor PRINCE2 down to the very small project”. The fact is, that you need a deep PRINCE2 understanding for this.

Scenario #4 - SAFe ©

In this scenario we’re assuming classically thinking and classically organized companies. These companies have come to realize, that their modus operandi impedes their ability to innovate and stay relevant in the market. The CEOs have concluded “we have become too bureaucratic and slow – we need an effective detox cure making us Agile!”.

Many organizations in that situation choose the popular Scaled Agile Framework [SAFe ©] – introduced in 2011.

A word of warning: do not try to start a balanced discussion about SAFe on social media – unless you want to start an uncontrolled wildfire. With the risk of being flamed I’ll here give my take om Pros and Cons.

UPDATE #1: Talking about wildfire – see e.g., this LinkedIn post from John Cutler on SAFe.

Balance

SAFe is highly prescriptive with a lot of terms, roles, processes ..

Judge for yourself:

SAFe

Pros

If your organization has deep bureaucratic roots with a classic mindset, then initiating the detox cure with SAFe can – for some organizations – be a relevant starting-point breaking the ice.

SAFe should thus be regarded as the initial dosage of the detox cure – not as the end-target … if the end-target is less bureaucracy and more agility.

Cons

Steve Denning characterizes SAFe this direct way:

Essentially this is codified bureaucracy, in which the customer is almost totally absent. It is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done.

Steve Denning

You may not 100% agree with Denning, but SAFe is overwhelming and not exactly characterized by a “Minimum Viable Process” mindset.

Scenario #5 - highly regulated context

Your company might live in a highly regulated context, say Medical Devices. In that case, you’ll need to comply to a number of international standards like ISO 13485:2016. Your products are literally about peoples life and death which is why a very rigid risk-management approach is required. 

ISO 13485:2016 specifies requirements for a quality management system where an organization needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and applicable regulatory requirements.

ISO.org

Balance

The balance is heavy on prescriptive processes, traceability and on documentation.

Pros

Being excellent meeting the formal quality requirements is a door-opener in your market – even a way for differentiation in the market.

Cons

If you’reorganization does solution projects for its customers in a variety of markets, it’ll be hard for you to meet and keep on top of the specifics in e.g., ISO 13485:2016. This is a specialized area, not ad-hoc adaptable when you get to run a new solution project.

Being in control

Before opening the Toolbox, let’s take a step back, asking “what is it that we want to achieve running projects in the first place?“

The answer is that we want to be in control of the core product / projects risks:

    • valuable for the customer
    • usable for the customer as intended
    • feasible for us to build
    • viable for our business
    • we’re able to produce the product (in serial production)

PendulumHere it is important to distinguish between bureaucracy and control. Bureaucracy, dressed as prescribed processes, is one of the means to maintain control. In the other end of the spectrum, you’ll find a Minimum Viable set of mandatory processes combined with a highly versatile Pick & Use toolbox.

Being in control is thus not a matter of being “bureaucratic”. You have to act disciplined and be in control of your projects no matter where the pendulum swings. The alternative would be flipping a coin. How you get in and maintain control is a decision you have to make given your context, project culture and values.

Control balance

BalancedWe’ll here assume two mature and equally successful organizations with fundamentally different cultures and value-sets. 

One regarding its employees as gears in a lean-optimized machine. 

The other organization only has a limited number of mandatory processes, but instead a trust that the employees can and will do the right things with support from a highly versatile Pick & Use Toolbox and a strong leadership.

Example: what is inside the boxes (here from an org. with a Minimum Viable Processes mindset)?

This organization has – carefully – chosen a set of rules of the game for all to comply to. The core purpose is to ensure always getting the basics right and ensuring transparency.

This organization, believing strongly in people, has reduced formal governance with decision boards / steering committees to an absolute minimum. Instead, the projects are empowered to do the right things, and be held accountable for the Outcome. 

This is highly different from e.g., PRINCE2’s strong emphasis on the steering committee leading the project – not the project manager (“only” being responsible for the project execution on behalf of the steering committee – and especially the Project Executive owning the Business Case).

    • Getting the basics right
      Specific conditions must be established and peer-reviewed before formal commitment. 
    • Transparency throughout execution
      Having highly empowered projects, being accountable for the Outcome, the organization has implemented an Objectives and Key Results [OKR] IT-system and highly disciplined maintenance and review processes.

This could sound like no leadership / management exist. This is far from the case. The difference to the classically thinking / organized companies, is that the leaders / managers here exercises a Servant Leadership mindset with the purpose of creating the best possible context for the projects to excel within. The point is to have better – not less leadership /management. 

Make no mistake – the Minimum Viable Processes approach does not mean minimum viable expectations towards the organization (including project manager and team). Actually the direct opposite. For this to work, the organization needs to have highly skilled employees, engaged and motivated to do the right things the right way.

Knowledge-sharing and -development is of fundamental importance as materialized in the organizations Pick & Use Toolbox. Here you’ll “find it all” like

    • Good Practices (hard to claim any “best” practices) like e.g., templates for how to sign-off a delivery with a customer
    • Guidelines for how to use various tools
    • Process for how to order xyz in the most efficient way
    • And not at least the wealth of techniques used in project management and in the technical delivery activities

This organization has chosen to have facilitated Communities of Practices [CoP] as a way to accelerate knowledge sharing and -development. Large portions of the Pick & Use Toolbox is naturally owned by the network of CoPs (in sharp contrast to the central process office telling the doers how to “do”).

Yes – you’ll also find many of these elements in a high-prescriptive organization which is no surprise. It is just common sense to have e.g., your configuration under control.

Wrap-up

Your unique context is everything. It is hard work to find your balance here – and sorry – there is no “go and buy” easy fix model / framework.

Auto-pilot

Most organizations have a natural built-in auto-pilot set for the destination of increased bureaucracy. Some organizations have a high awareness of its existence, actively forcing another and less bureaucratic – more “agile” destination. Amazon and Tesla are two strong examples. The majority of organizations are willingly running on auto-pilot – even amplifying its effect with arguments like

    • we need more process prescription / governance, rules, check-lists etc. for us to manage our growth
    • it is a prerequisite for us to do business in the selected market
    • our people are not smart enough / experienced enough and need to be told what to do and how to do it
    • …

Adding new process prescription is the easy route to take in the response to scaling. The difficult route is stronger leadership / management (look at Amazon and Tesla). Marty Cagan formulates it this way:

Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.

One is by scaling their leaders (the managers). The other is by scaling their process.

Marty Cagan

Detox

DetoxMore and more organizations have come to realize the effect of the “auto-pilot”, now calling for a bureaucracy-detox cure.

A lot of such detox cures are being offered today. They are typically known as “Agile Transformation”, “Digitalization” or some Silver-Bullet framework. 

Unless the organization fully appreciates the root-cause, being the auto-pilot, such detox cures will not last. Companies with classic roots are in for a challenge. Many have tried drinking the Green Stuff, didn’t like it, and back on auto-pilot.

E.g., Amazon and Tesla have a clear advantage both being digital-native companies driven by leaders with a strong start-up mindset. They do not need the detox cure in the first place.

Posted on

From Innovation to (physical) Production and Continuous Improvement

Innovation to production

Are you “only” involved in purely digital / IT products, then you might want to skip this post … unless you want to appreciate the complexity being faced by people working with multidisciplinary products. 

The modern high-tech product company needs at the same time to optimize for

    • Fast-paced product innovation
    • Production with a consistent quality

At first glance it can seem like an attempt to mix oil and water, but never the less this is mandatory for success. If you want your customers to love your products, you need to supply products that (inspired by Marty Cagen)

    1. are valuable for the customer
    2. are useable for the customer
    3. meets the customers quality expectation

(1) and (2) basically have to do with the Discovery of the right product. (3) is in essence about predictive (physical) production. As mentioner in an earlier post, Tesla is an (extreme) example of this.

This post will discuss the full Product Lifecycle from early innovation to (physical) production, and the continuous product improvement feedback-loops. 

In a hurry? Jump directly to the wrap-up.

An overview seen from the height of satellites

Product Lifecycle ManagementThis is the top-level view of a Products Lifecycle. It gets 

    • invented
    • produced with continuous improvements
    • phased-out

From this height of satellites we do not see the details on how 

    • the product is born
    • the product is matured for production 
    • the on-going product improvement loop works

Six SigmaThe need to deliver what the customers need, with the right quality and in a lean way is far from new. The various flavors of e.g., Six Sigma, dating back to the last millennium, exemplifies that.

Scrum for hardware designAdd to that the suite of other ISO quality standards, project models and of course the Agile spin-offs for non-software domains as e.g., in this book (which by the way includes a description of how Saab Aerospace applies Scrum in the development of the Saab JAS 39 Griben fighter jet making it highly competitive to Lockheed Martin’s F35 fighter).

Feeling a bit overwhelmed?

Take a deep breath!

Do not let all these frameworks / models / standards drag you around. Just like you do not want to be enslaved by “the right way to do Scrum” or “the right way to do PRINCE2”,  you do not want to build a bureaucracy with process prescriptions not working for you.

There is only one right way, and it is the way that works for you!

What I highly recommend is to invest (a lot of) time understanding all the various standards, frameworks, models, tools etc. thus acquiring the insight needed for you to take enlightened decisions on what elements to use and what not to, given your unique context.

Elon Musk is very clear about (too many prescriptive) processes:

I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.

Elon Musk

In the case of Tesla, being a digital-native company, as much as possible is automated with a heavy IT-setup and state-of-the-art robotics. So yes – Tesla has a lot of processes, but processes to be followed by machines. The intellectual and innovative part is not dragged-down by strict process prescriptions or multilayered project governance. I guess (not being a Tesla employee) that Tesla has a versatile pick & use toolbox of good practices and tools. As mentioned earlier, Tesla uses Communities of Practice (CoP) to share and develop knowledge across teams.

OK - so what do we then do?

Assuming that you have done your homework, having a deep understanding of your own business and having equipped yourself with a solid understanding of all the relevant methods, frameworks, standards, tools etc., you can start the hard work.

You might want to use your Time Machine travelling the Product Lifecycle all the way from the initial inception of a product-idea over innovation to production, continuous improvement and finally to the phasing-out of your product. During your journey keep asking a few simple but important questions for each time-jump.

Before looking at the questions, let’s define a few assumptions and recommendations: 

    • Assumption: Throughout the Product Lifecycle you want to find the right balance between formal structure and flexibility. This balance will naturally shift depending on, where you are in the Product Lifecycle.

Structure vs flexibility

    • Assumption: You consider the intellectual capacity as the most valuable asset in your company thus being very aware of, how you use it:
      • Where IT-systems and/or robots can do the job, don’t waste intellectual capacity
      • To the extend you define formal and mandatory processes, you’re making sure that they create business value
      • You want to make it as easy as possible for your employees to do the right things the right way
    • Recommendation: Do not answer the questions with “we need to do that because model / framework / standard xyz dictates us to do so“. You need to see these models / frameworks / standards etc. as optional means to meet your objectives; not objectives themselves (with a few regulatory exceptions).

Here are the recommended questions:

    • What minimum viable structures and processes do we need to facilitate alignment in the organization?
    • What can we do to get the most business value from our combined intellectual capacity?
    • What can we do consistently to deliver the quality expected by our customers?

Answering these questions you can, if relevant, consider elements from the range of models / frameworks /standards / tools etc.

That is just common sense!

You might be thinking “this is just common sense – nothing new here!“. The reality is that most companies have a natural tendency to build bureaucracy, “talking to itself”:

Pseuco-workThe typical spine-reaction to increased complexity in classically structured organizations is stricter Project governance, more control bodies, stricter and increasingly complex Project process prescriptions, more checklists, more reporting, more detailed planning – even for stuff that cannot be planned. Decisions are delayed, needing to travel up and down the hierarchies. The odd thing is that the biggest decisions are taken far away from where the biggest insight and information is. A bit sarcastically some describe this as “HIPPO” meaning the Highest Payed Persons Opinion. 

Not convinced?  Read e.g., the book Pseudo-work: How we ended up being busy doing nothing.

In other words: if you’re not tough on the recommended questions above, then the auto-pilot in your organization will bring you to another destination characterized by more or less untethered bureaucracy. This has and is happening to a lot of organizations. Guess why you see all the “Agile Coaches” popping-up wanting to free organizations from the burden of bureaucracy through “Agile Transformations”?

True, an external facilitator is often an effective way to get such a transformational process going – though it is not rocket science – just hard work (and it is!)

Example context

Before going for a quick ride in your Time Machine, let’s assume the context outlined earlier with a high-tech product company innovating and producing a range of multidisciplinary – a combination of high-precision mechanics, hardware (power), electronics, embedded software and application software – products.

The company has decided on a brand-new product range with intelligent capabilities making it predict and seamlessly adapt to a users needs. This product range is expected to have it all (though depending on the solutions discovered by the Product Teams):

    • Electronics, sensors and IoT-connectivity
    • Embedded software
    • Hardware (power)
    • High-precision mechanics
    • Mobile application
    • Cloud services leveraging the computational power for the Deep Learning AI

It is a B-t-B product intended to be integrated in other OEM’s product range like robotics.

The company has been through a big digitalization / Industry 4.0 transformation process in its quest for the holy grail: fast-paced product innovation. The company is now highly digitized enabling the Product Teams to have e.g., real-time updated BOM-cost estimates (and estimated lead-time) available. The company has also come a long way with its AME (Advanced Manufacturing Engineering) using robotics, industrial IoT, Machine Learning etc. All bits and pieces are traced through solid Configuration Management (including e.g., PLM – Product Lifecycle Management).

Each produced product instance has a fully detailed configuration following that instance to the grave. As described earlier with Tesla, the company is capable of changing components during serial production and maintain full traceability for its use in specific product instances.

Broadly speaking the company has two types of products, the ones that

    • are very stable in production during the Product Lifecycle having no or very few changes / optimizations
    • are expected to evolve radically with a lot of changes, needing a high degree of agility in the production

The production set-up for the first type resembles the traditional lean one-piece flow (for which Toyota is famous with its TPS). The company’s production set-up for the 2nd type resembles what Joe Justice calls Massively Parallel Concurrent Manufacturing [MPCM].

    • Traditional lean one-piece flow (the Toyota production system is famous for it) makes change very expensive … encourages getting it perfect before deploying to production … resulting in long lead-time for changes … which again delays getting feedback from production to improve design … rendering the slowest possible deployment cycle. The traditional lean one-piece flow is completely inappropriate if you want speed of change!
    • In contrast, Massively Parallel Concurrent Manufacturing [MPCM] is optimized for change. Here there is no one-piece production line at all
    • In MPCM we’re using massively automated unit and integration tests (like with a build-server in a software environment)

Joe Justice

In his example we’ll assume that the new product-range is of the 2nd type – that is MPCM – with a need for a very high degree of agility in the production.

During the digitalization transformation process it became clear to the company, that it over the years had built too much of a bureaucracy in an attempt to control and set rules for everything. Now the company has shifted 180 degrees towards a Minimum Viable Bureaucracy. 

In “the old days”, before starting to use stable cross-functional Product Teams, the company would follow its project management process, in its core being inspired by PRINCE2. Its approach to this new product-range would initially be to build a Business Case arguing the viability of a product development project.

Venture CapitalToday, looking in the rearview mirror, the company has come to realize that such a Business Case included a lot of guess-work for the simple reason that the solution was not known at the time of writing the Business Case. The company has taken the consequence and changed the way it funds product development: today it uses a Venture Capital [VC] approach with metered funding.

Instead of the classic governance reporting compliance / deviations to the (doubtful Business Case), the Product Teams (being accountable for the Outcome) now act with the mindset as if being (an internal) start-up seeking VC.

In the “real external world” of start-ups you’ll be expected to convey a convincing set of arguments, for why the Venture Capitalists should (continue to) fund your endeavor. You have to be concrete and facts-based in your arguments e.g., referring to validated experiments and new insights. Try show a Business Case based on guesswork, and you’ll probably not get the requested funding.

At some later stage you’ll have gathered  enough evidence and certainty to provide valid estimates on market potential and  cost to expand production. Given the need for a major investment in production capabilities, it would be natural at this point in time to provide a Business Case (which a real Venture Capitalist would request).

Example jumps in the Time Machine

Given the example context above we’ll make a few time-jumps, each time asking the three questions

  • What minimum viable structures and processes do we need to facilitate alignment in the organization?
  • What can we do to get the most business value from our combined intellectual capacity?
  • What can we do consistently to deliver the quality expected by our customers?

The VC-style funding model will not be mentioned as is applies everywhere.

Time-jump - Product Teams have been tasked with (hard) problems to solve

We’ve jumped to the point in time where a network of Product Teams has been defined and each Product Team has been tasked with (hard) business / customer problems for which it is empowered to discover the best solution, making the new product-range come to life.

What minimum viable structures and processes do we need to facilitate alignment in the organization?

Radical Focus 2nd editionWhen operating with autonomous and highly empowered teams, we need to ensure a strong alignment and transparency between the teams. Through the Product Vision and -Strategy we’ve already established a strong and common North Star. In addition we need full transparency on the progress in each team.

The company has decided to use the OKR (Objectives and Key Results) system in a disciplined and methodical way to achieve this transparency. Read more about OKRs in e.g., Christina Wodtke’s Radical Focus books. 

Implementing a well-functioning OKR practice is a major challenge in itself. OKRs will become the governance backbone throughout the full Product Lifecycle.

At this point in time the primary focus is for the product teams to discover solutions to the business/customer problems. The problems have been defined in a way minimizing dependencies between teams though teams in the network need actively to align and share insights.

What can we do to get the most business value from our combined intellectual capacity?

This creative process of discovering the best solutions to the business/customer problems needs a versatile pick & use toolbox – not a lot of prescriptive processes.

Let’s recap – the objective for this product discovery is to balance the core product risks – before investing a lot in the development of the solutions:

    • valuable for the customer
    • usable for the customer as intended
    • feasible for us to build
    • viable for our business
    • we’re able to produce the product (in serial production)

In the pick & use toolbox you’ll find e.g., techniques to formulate and test for hypothesis. As discussed earlier, this discovery process for multidisciplinary products is far more complicated compared to single-discipline digital products.

The pick & use toolbox of course also contains a lot of best practices, guides and tools covering all the engineering disciplines involved. Knowledge sharing and -development across the teams is extremely important for the company. It has a number of facilitated cross-teams Community of Practices (CoP). The CoP facilitators ensures the life and dynamics in the CoPs making it as easy as possible for the team-members to participate and contribute. Many elements in the pick & use toolbox are owned and maintained by the CoPs.

You’ll in the pick & use toolbox most likely find several elements from e.g., Six Sigma. Where he company in “the old days” would have prescribed the use of such Six Sigma elements in mandatory processes / check-lists, the company today trust the Product Teams to pick & use the tools most relevant for them.

What can we do consistently to deliver the quality expected by our customers?

The best way to achieve quality is to build-in quality from the start. To that end you might want to pick elements from e.g., Six Sigma like the D-FMEA and have that D-FMEA evolve throughout the product development.

A core theme in Product Discovery is the disciplined design and execution of experiments, testing for a given hypothesis. Some of the Six Sigma elements like DMADV or IDOV could be relevant.

Time-jump - preparation for the 0-series production

We’ve jumped to the point in time where preparations are being made for the 0-series production run of this new product range.

Single-item runs have been made in a production-staging environment resembling the serial-production environment on selected and critical areas. This staging-environment has allowed the teams to validate the design-for-manufacturing and thus the product risk “we’re able to produce the product”.

What minimum viable structures and processes do we need to facilitate alignment in the organization?

The production processes will be automated as much as possible to be run by robots / systems. These processes must have a very high quality and precision. Six Sigma tools like P-FMEA (P for Process) could be relevant here.

The company is, like Tesla, using well-defined DoR (Definition of Ready)  and DoD (Definition of Done) for parts / subassemblies. To the extend possible, robots / systems validate the DoR and DoD throughout the production process.

You might want the use e.g., the PPAP tool ensuring that sourced parts will meet DoR.

What can we do to get the most business value from our combined intellectual capacity?

The humans in production will primarily work with programming of robots, QC-systems, logistics processes, maintain DoR / DoD definitions etc. The aim for the company is thus to automate production for several reasons:

    • Robots / systems operate consistently with the set tolerances – better than humans
    • Robots / systems do not make human mistakes like forgetting to scan a bar-code or provide production data
    • Free human capacity for creative tasks not – yet – manageable for robots / systems

What can we do consistently to deliver the quality expected by our customers?

This is again very much about stringent formulation of DoR / DoD including acceptable tolerances. These definitions and tolerances are constantly measured and monitored during production. It could be relevant to apply statistics from the Six Sigma toolbox. 

With full traceability the company can trace-back customer-complaint cases to the single product instance and the measurement results for that specific instance. This will again allow for a very targeted course of action if a range of other product instances are needed to be exchanged as a preventive action.

We want these quality checks to be as automated as possible. Realistically though some human intervention can be needed for the final QC release. I’ve e.g., seen that Tesla has a (human) driver take the final car over a series of bumps checking for squeaky sounds (some day this will definitely be automated too).

Time-jump - continuous product improvement

We’ve jumped to the point in time where full series production is running. Because of its strong configuration management and AME combined with heavy data-collection during production, the company has the optimal platform for continuous improvement of its products. Remember, as mentioned earlier, that the company’s production set-up for this product-range is optimized for change using Massively Parallel Concurrent Manufacturing.

And not “only” that, this production platform allows for pre-ordered and customer-specific configurations without jeopardizing quality or speed. 

As also mentioned earlier, this product-range needs to evolve radically from its original inception for it to stay relevant in the market. Luckily the company has managed to establish a network of strong Product Teams around the product-range. Together with the Head of Product they keep the Product Strategy updated (and maybe even adjust the Product Vision) making sure the teams are working on the most relevant business / customer problems.

What minimum viable structures and processes do we need to facilitate alignment in the organization?

The most important structures are the Product Vision, the Product Strategy and the OKR system tracking the progress of the problems (objectives) being worked-on by the Product Teams.

What can we do to get the most business value from our combined intellectual capacity?

(Also here) it is highly relevant to have the strong and versatile pick & use toolbox. Such a toolbox and the CoPs across the Product Teams are major elements in the optimal use and development of knowledge. We want to keep process prescription to a minimum viable level not impeding knowledge use and -development. 

What can we do consistently to deliver the quality expected by our customers?

The context here is very similar to what happened during our first time-jump, where the network of Product Teams were provided with the initial (hard) business / customer problems to solve. 

Solving the continuous improvement problems calls for the same innovation power. The difference now is that we have a product baseline in production to which changes must be made is a very disciplined way. You might be thinking “yes – and it is here we need a significant amount of prescribed processes, check-lists, control-bodies etc“.

Well – no. The Product Teams (being accountable for the Outcome) are fully aware of the quality-aspects. Remember that the Product Teams are stable in sharp contrast to the classic ad-hoc project team. Remember also that the Product Teams are cross-functional, meaning that they also have production technology experts on-board.

Wrap-up

The main take-aways are 

    • more trust in the Product Teams and less process prescription
    • always understand what (objectives) you want to achieve before deciding on the means (which could include the vast range of frameworks, models, standards, tools etc.) – never let the means themselves become the objective (with a few regulatory exceptions)
    • formal / prescriptive processes are important and relevant at some stages in the Product Lifecycle – and counter-productive in others – depending on what you want to achieve and optimize for at that stage
    • when you feel an urge to define new process prescriptions, check-lists, rules, control bodies etc., ask yourself:
      • do we need it – is the added bureaucracy worth it?
      • did we fall in the trap letting the means (frameworks, models, standards ..) become the objective?
      • how can we maintain a Minimum Viable Bureaucracy?

 

Posted on

You got a new project – now what?

Start Project

Congratulations – you, as an external project management consultant, have been asked to run a project for your customer. Now what? How do you as fast as possible get a firm grip on the steering wheel? Are there some fairly generic approach to get your project started?

Classic-agileLet’s define some assumptions, setting the context for this post:

    • your project is classified as a classic/agile project (see the illustration to the right) based on ad-hoc project teams allocated from the functional line, and being measured on the ability to deliver output. In contrast you’ll find the “Product Innovation” segment based on stable cross-functional product teams being empowered to discover the best solution to (hard) business / customer problems and held accountable for outcome. Many of the previous posts, like this one, have addressed exactly that product innovation context.
    • your customer has a big home-grown project process / governance universe, probably to some degree inspired by a mix of frameworks / models like Scrum, PRINCE2, Kanban, SAFe, Half Double, PMI, AgilePM, Six Sigma, ISO 9001 …

You do not, at least initially, have the luxury and time to deep-dive into the customer’s project process / governance universe. You need, as a project management professional, to bring your own experience and framework / model agnostic toolbox to get quickly started. 

The aim for this post is thus to discuss a general approach for you to get your hands on the steering wheel as fast as possible.

At first glance this post might seem a bit long, but trust me, this is nothing compared to reading e.g., the PRINCE2 bible + the Scrum bible + the Kanban bible + ISO 9001 + … have e.g., a look at some of my inspirational sources. 

The high-level structure

The classic errors seen with less experienced project managers are (also)

    • A fixation on and dependencies of the process universe making it hard to get quickly started
    • Too quickly starting execution before having a solid overview

In contrast, the experienced project manager is able to act independently, building the overview before entering execution. I’ve found this generic high-level structure effective:

Understand the fundamentals

Here is a list of fundamental elements that I’ve experienced as a solid starting-point:

  • Purpose
  • End-goal and (hierarchy of) objectives
  • As-is situation
  • Key stakeholders
  • Significant challenges, risks and opportunities
  • Top-level milestones and dependencies
  • Business Case
  • Compliance requirements on processes and tools
  • Available competences and capacity

Purpose

“Why are we doing this project – what is the rationale?” is the most important question at all. The answer to the question is what releases the energy and engagement in all of us in the project. We’re all only humans, and without a clear purpose / rationale, we’re simply not able to feel engaged (sadly I’ve experienced far too many projects fail exactly because of an unclear purpose).

Formulating a sharp, crisp and engaging purpose is not easy and close to an art-form. Example-features of a well-formulated purpose:

    • It is simple, easy to understand, remember and explain for others
    • Aim for no more than three bullets thus avoiding a long shopping list
    • The purpose must support a clear scoping of the project thus “only” cover the rationale  – not more
    • The purpose must express a business rationale / benefit for the project owner and thus not “only” a technical solution
    • The purpose must be held within the influence-sphere of the project
    • If relevant the purpose could describe the delta from old to new

The principle is: keep the purpose short, sweet and to the point.

End-goal and (hierarchy of) objectives

Time machineAnother classic error seen among less experienced project managers is the reactive activity planning-forward mindset. They’ll quickly loose sight of the real end-goal.

All professional project managers need to have a time-machine in the garage and be fully capable of providing guided tours in it. The governing principle is start with the end making sure that the end-goal will drag us as a future magnet in the right direction; also in the case where we’ve taken a de-tour from the direct path to the end-goal.

Being the facilitator and time-travel guide, you’ll bring relevant stakeholders to the point in time where you’ve just closed the project. You invite your passengers to step-out, asking them to describe what they see.

Your aim is to have the time-travelers provide a rich situational description of not only what they observe, but also what they note as especially important and/or successful. Using a Six Sigma term you’ll identify CTQ (Critical To Quality) areas.

This rich situational description of your end-goal will act as the top-node / project vision in your “hierarchy-of-objectives” or “product-breakdown-structure” (a term used in e.g., PRINCE2).

Being the facilitator / time-travel guide you can use e.g., the notion of the Whole Product Whole productto inspire and challenge your travelers. Example:

    • the generic product is some IT-functionality enabling your organization do something new / better than before
    • the expected product, adds to the generic product in three areas
      • experience
      • enrichment
      • extensibility
    • each of the expected product areas further details what becomes the whole product
      • experience
        • training
        • user support / superusers
        • on-line documentation and business processes
        • self-service functionality 
      • enrichment
        • installation, configuration and operation
        • formal quality certification
        • 3rd party functionality integration
      • extensibility
        • open APIs enabling an API economy
        • protection of Intellectual Property Rights 

Some of the features of the Whole Product might not be immediately obvious, but rest assure, if you do not deliver on them, then they’ll become very visible in a bad way at a later stage.

Your job is now to take your time-travelers gradually back in time until reaching the as-is situation. For each step you’ll be asking

    • What objectives had to be met / product delivery made before the situation this point in time?

This way you’ll progressively build a hierarchy of objectives. You and your time-travelers will most likely learn new insights in the process requiring you to go back and forth in time. No worries – this is perfectly normal.

What you end-up with is a hierarchy-of-objectives unfolding the objectives to be met for you to reach the end-goal. This hierarchy-of-objectives is valuable for a number of reasons e.g.,

    • It is a strong communications tool across stakeholders keeping us all on the same page
    • It is a strong basis for your planning

Note that we at this point in time “only” talk objectives – not the detailed requirements or the activities needed to meet these objectives. You can think of the hierarchy-of-objectives as the naked tree. Later on we’ll supply the leaves being the activities.

The principle is: start with the end and do not talk detailed requirements and activities before having understood the objective(s).

As-is situation

As indicated under Purpose, a project’s main rationale might be to bring the company from an as-is situation to a future situation. In that case we also need to understand the as-is situation.

The as-is situation can be everything from being lean, mean and well-functioning to a de-railed situation needing a fire-extinguisher.

The principle is: if the purpose of your project is to bridge the gap between a future to-be situation and the current as-is, then you (also) need to understand the latter

Key stakeholders

The most important stakeholder is the Project Owner being the chairman of the steering committee. If your customer is thinking in PRINCE2 terms, your steering committee will in addition have a Senior User and one or more Senior Suppliers. It might also happen that your customer is not having a structured approach to steering committees in which case you need to advice / coach on the subject.

A project without a strong and clear owner is doomed. If the project does not have an business owner, then why run the project?

You need to understand all your (most important) stakeholders – not “only” the steering committee – and have an initial dialogue with them. 

The principle is: always understand and maintain a dialogue with your customer and stakeholders

Significant challenges, risks and opportunities

Through the initial dialogue with your stakeholders, you’ll start building an understanding of challenges and risks needing active management. Do not forget also to seek opportunities for your project to benefit from.

In the international quality standard ISO 9001:2015 you’ll find the notion of Risk-basted Thinking [RBT]. Even if your customer’s processes are not subject to a ISO 9001:2015 certification, the mindset behind RBT is widely applicable.

Def. [Risk] “the effect of uncertainty” – might be positive or negative comparted to what as intended.

Def. [Opportunity] “a set of circumstances which makes it possible to do something” – taking or not taking an opportunity represents different levels of risk. An opportunity is thus not merely the positive side of risk.

    • RBT will weigh the risks from proceeding or not proceeding with an opportunity or curse of action and decide on implementing mitigations or not. The point: prevention is better than cure.
    • RBT is an attempt to balance between insufficient diligence and strict formal Risk Management (seen in e.g., ISO13485 Medical Devices).
    • Resulting from RBT is a clear decision on Accept (take risk), Avoid (not proceeding), Mitigated (make the risk more acceptable).

ISO 9001:2015

A lot of different approaches exist to uncover risks in a project. One particular effective approach is called pre-mortem. Using your time-machine, you’ll jump to a point in time where your project unfortunately went totally off-rails, now asking: what de-railed the project making it go over the cliff?

The answers to this question generates (potential) risk-areas.

The principle is: promote Risk-Based Thinking throughout the whole project

Top-level milestones and dependencies

Maybe your project is part of a larger program with a milestone plan defined across the included projects. You of course need to understand such a plan.

In addition, you need to understand (initially on a high level) what natural milestones exist in your project and how the dependencies are between these milestones. Yes – you’re right. The work done with the hierarchy-of-objectives is a great help here.

You might be thinking “hey – I’m actually expecting (approach strategy) this project to be run as a highly Agile project – why would I care about a milestone plan?” My experience is that a milestone plan modelled with (hard) dependencies is a very helpful tool also when doing Agile planning; e.g., in the prioritization of the Product Backlog.

Should your customer’s formal project process requirements prescribe a stage/gate model, the milestone-thinking is again very helpful.

The principle is: without too much detailing, a milestone plan modeling the higher-level dependencies helps you plan, maintain and communicate the big picture

Business Case

Some customers have a very strong and mature use of the Business Case being the center-piece around which the project evolves. In e.g., PRINCE2 the Business Case is such a center-piece with the Product Owner, owning and being accountable for it.

Other customers have a more vague documentation of the business rationale, but in all circumstances you need to seek and understand whatever business-rationale documentation exists for your project.

Well, in some projects is does not exist al all – yet. It might be part of your initial assignment to drive the development of such a business rationale.

The principle is: always understand the business rationale behind your project – if no clear rationale exist, do not run the project

Compliance requirements on processes and tools

Your customer will, with 99% certainty, have some form of defined project- and governance process. You need to understand the level of mandatory prescriptions for you and the project to comply to. 

Your customer might also have a suite of (IT) tools, some of which are mandatory to use.

Make sure to get an understanding of these requirements (and opportunities) as fast as possible. You do not want to invest a lot of time and energy travelling down a blind road.

The principle is: make sure as fast as possible to understand the formal constraints (and opportunities) on processes and tools

Available competences and capacity

Depending on when you’re assigned to the project there might / might not exist an overview of competences and capacity being made available to you in the project.

Make sure to be able to staff an initial core team together with whom you’ll bootstrap the plan for the project.

The principle is: start small with a strong core team and expand from there

Approach strategy

With the insights collected above in The Fundamentals, you have a solid basis on which to define your approach strategy. You can think of the approach strategy as your overall plan for how to get from the as-is situation to your end-goal … your project vision (remember our time-travel) … in the way minimizing risk and optimizing business value. 

Here are some inspirational features for an efficient approach strategy:

  • Your strategy is based on a solid understand of the given context (The Fundamentals above)
  • Your strategy will apply a Risk-Based Thinking mindset in a quest to prevent risks vs curing occured risks
  • Your strategy must be easy to understand and communicate

This can be a bit abstract, so let’s bring it down to earth and define an example-context and some strategy-challenges with in it.

Example context

Let’s assume that your customer is a successful high-tech product company with a global footprint. Your customer innovates and produces a range of multidisciplinary – a combination of high-precision mechanics, hardware (power), electronics, embedded software and application software – products. 

Your customer is highly focused on the continuous improvement of the end-to-end business agility and has identified a need for a more integrated PLM (Product Lifecycle Management) / configuration management. This is much more than “just” an implementation of some IT-functionality. It is also very much about business processes and the humans using them … globally.

Just to give you an idea on, how high the bar can be set, this previous post gave a glimpse into the extreme innovation and manufacturing world at Tesla.

Your customer has the three core ISO HLS certifications 9001:2015, 14001:2015 and 45001:2018 plus a number of other international certifications. During your getting “The Fundamentals” right, you of course also need to understand, if your project has a dependency on these certifications (in this case most likely the business processes in the company’s QMS – Quality Management System). Think “The Whole Product”.

Strategy challenge #1

Challenge: No one is able up-front fully to specify the requirements to be met. In fact – the best solutions to the business problems remain to be discovered. 

Strategy element #1: This is a classic example of an experimentation strategy. We cannot (because we do not know it) provide the project team with a solution to develop. What we can do is task the project team with (hard) business problems for which the team needs discover the best solution. Our previously defined hierarchy-of-objectives comes-in handy again.

Teams trained in and experienced with hypothesis-formulation and experimentation-design to test the hypothesis, can work very efficiently. 

The principle is: fail fast – learn fast. Such fast feed-back loops are highly effective and helps us validate a solution before investing efforts in its implementation.

Strategy challenge #2

Challenge: (Some of) your stakeholders are impatient to see concrete results, fast and continuously.

Strategy element #2: We clearly need to show results on a continuous basis. A “big-bang waterfall” approach is not an option. The IT-part of the project thus calls for an Agile approach thinking in terms on “vertical slices”.

Agile cakeIn the “old days”, we would work with “horizontal slices” e.g., building the server-layer, then the middle-ware and finally the user-application layer. It would thus take a long time before the users could see anything. 

As illustrated here, the “vertical slicing” can be seen as a cake (the illustration to the right). When e.g., tasked with “Pay order with credit-card”, the “full-stack” team will work simultaneously on “Data Layer”, “Middleware” and “Web UI” to produce and deliver the ability to pay order with credit-card.

Not only will we satisfy a need to show continuous progress and delivery of functionality. Equally important we’ve established the important feedback loop enabling us to get feedback from the stakeholders and have that feedback / learning integrated in the rest of the project. 

For this to work, we need a working CI/CD pipeline.

The principle is: slice your architecture in a way enabling you to deliver working functionality after each sprint

Strategy challenge #3

Challenge: Many users tend to be skeptical – we’re doing ok today, so why this change (we’re getting tired of all these constant changes).

Strategy element #3: It is only human asking the simple question “what’s in it for me?”. You can of course try intellectually to argue, why the to-be situation is attractive and creates meaning. With the words of Daniel Kahneman, you would be talking to the slow-thinking type 2 operating system in the brain making-up 2% of all our thinking. The remaining 98% is what Kahneman calls the fast-thinking type 1 operating system.

The challenge for achieving sustainable change, is to anchor the to-be situation in the type 1 operating system through involvement and action-training.

The principle is: make change concrete and de-mystified through involvement and action-training

Strategy challenge #4

Challenge: The project maturity is low (well-below CMMI-2), with parts of the organization in reality not understanding the nature of a project and what it means to be involved in a project. The notion of “Agile” is definitely not broadly known or appreciated.

This lack of project maturity / professionalism has historically been manifested in e.g., activity plans without clear objectives and strategic thinking … or put into other words: lack of an approach strategy.

Strategy element #4: The way it is, is the way it is. Respect the status and do not expect or ask the organization to perform on a level currently unreachable to it. Invest some time in understanding where the biggest pains / challenges are in the organizations project execution ability, and gently nudge it forward with carefully chosen doses of improvement initiatives to the level making it valuable for your specific project. 

The principle is: always understand where the organization currently is and improve from here to the extent it makes a profitable Business Case for the specific project

Strategy challenge #5

Challenge: Even before you enter the project, it is under a significant time-pressure with a hard deadline. If this deadline is not met, the factory’s supply-chain will break. 

Strategy element #5:  All experience says that allocating more people to a project in this situation, only makes it worse. The only two viable strategies mitigating the risk of missing the hard deadline are

    1. Scope reduction
    2. More work done in parallel

The nature of your project and its organization will determine the appropriate course of action. 

The principle is: mitigate the situation with the project team at hand – do not try to force more people into the project

Baseline planning

Having understood the fundamentals and having defined a situational approach strategy, you are ready to base-line your plan. How you do that is highly dependent on your approach strategy.

Approach strategy

Transparent execution

No matter where your project is on the scale from fully classic big-up-front-specification Waterfall to pure Agile … or a mix in-between – you need to ensure transparency in the execution. How you do it and what tools you use is again highly dependent on your approach strategy.

Wrap-up

The core message is:

Always have an approach strategy derived from the context in which your project exists. 

Update

This update to the original post suggests the use of visual communication, enabling you to convey the big picture on one page. Inspired by The Grove‘s Graphical Game Plan [GGP] this can help (and force) you to communicate the essence of your project:

Graphical Game Plan
Posted on

Innovation, continuous development and production of multidisciplinary high-tech products

Pace of innovation

If you’re in a company “only” developing purely digital products, lucky you. You do not have to manage the added complexity in developing and producing multidisciplinary / mechatronics products.

Should you not be so “lucky” and happen to be with a company doing multidisciplinary product development, this post is for you.

An earlier post scratched the surface on how to approach this type of innovation challenge. Here we’ll go a bit deeper, and let’s start with the holy grail as formulated by Elon Musk:

Pace of innovation is all that matters in the long run

Elon Musk @Twitter, Apr 2020

Spoiler alert: There is no equally simple answer to the simple question – how do we achieve fast-paced innivation?

What does it take to achieve Fast-paced Innovation of multidisciplinary high-tech products?

Fast-paced innovationLet’s assume the availability of a time-machine enabling us to jump to the point in time where we’ve reached the goal of achieving fast-paced innovation of our high-tech products.

Exiting the time-machine we’re especially noting three capabilities, developed to excellence:

    • We’ve managed to reduce the calendar-time introducing new products / upgrades by applying parallel workstreams 
    • We’ve managed to achieve a high and sustainable cadence within each work-stream 
    • We’ve managed to keep all the core product risks under control

Below we’ll unfold each of these to-come capabilities.

Parallel work-streams

  • Minimal dependencies between Product Teams - dependencies kills speed and agility
  • Strong alignment between Product Teams - they need to share a common North Star
  • Strong Configuration Management - without it chaos is just round the corner

Minimal inter-team dependencies

The key unlocking this capability is found in the software community and its object-oriented design practices; especially the notion of encapsulation being the discipline of hiding (encapsulating) complexity behind an interface. In the software world such an “interface” is also called an API (Application Programming Interface).

A widespread practice in software development is called “contract first” with contract meaning a stable interface. Do not start implementing the complexity behind the contract, before the contract is agreed / signed. Jeff Bezos (Amazon) is famous for his clear message on the importance of contracts / interfaces in Amazon:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn’t matter what technology is used. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be fired.

Internal mail in Amazon from Jeff Bezos

As a side-note it is worth mentioning that Amazon has managed to build an extremely successful API business via AWS (Amazon Web Services).

This notion of encapsulation behind stable contracts / APIs applies directly to the non-software domains. Now the contracts are in the form of mechanical and electrical interfaces.

Importance of stable interfacesWith agreed stable contracts, Product Teams can work (fairly) autonomously thus achieving a high degree of parallelism rendering accelerated product development.

In reality the contracts / interfaces are semi-stable. Given a Product Team sees a need for adjustments to the interface-specifications, this Product Teams is taken the responsibility for the coordination efforts with relevant other Product Teams and stakeholders. Without strong and disciplined Configuration Management this could easily degenerate into chaos. 

But it does not stop here. The product design with stable interfaces enables component flexibility in production.

See Joe Justice’s description below of how this is taken to extremes in Tesla’s production. Components entering a Tesla factory is checked against specifications and interfaces being their DoR (Definition of Ready) to be used in production. Sub-assemblies must in a similar way meet a well-defined DoD (Definition of Done) thereby ensuring that it is Ready for the next production step. In Tesla these DoD / DoR verifications are of course done by robots. All this means that changes in hardware configurations happens all the time (which you’ll definitely not see with any other automotive producer).

In addition to the concept of autonomy / encapsulation, we also need to make sure that the Product Teams work towards the same North Star thus staying aligned.

Shared Product Vision and -Strategy: A shared North Star

Multiple earlier posts have elaborated on the importance of having strong product Visions and –Strategies as the driver to task the Product Teams with (hard) business / customer problems to solve and keep the Product Teams aligned. We’ll not repeat that here, just emphasize its importance.

Strong configuration management

Configuration Management is a very complex, yet vitally important, discipline ensuring that we always have a real-time up-to-date and valid understanding of all the details and dependencies in a product. Without it – forget about fast-paced innovation.

One of the key aspects of a strong Product Culture is the disciplined design and execution of experiments, testing a hypothesis. Understanding exactly what configuration is subjected to such experiments is fundamentally important. Without it a company like Tesla would not be able to have its extreme continuous product development.

Part of this Configuration Management is full production traceability. Two instances of the same product (e.g., a given Tesla model) can have different configurations following that product instance from cradle to grave.

High cadence

  • Limit WIP and/or time-boxing
  • Limit physical dependencies

Limit WIP and/or time-boxing

The Agile community has a lot of empirical evidence showing that working in small batches at a time renders a cadence superior to the cadence achieved when working in big batches – at least when it comes to software development. 

Logically the same principle will apply to non-software development as long as due respect is shown to the physical constraints not present in purely digital products.

Limit physical dependencies

As mentioned earlier a number of initiatives can be taken to reduce the impact of these physical dimensions:

    • use simulation models / digital twins
    • use evaluation kits
    • move relevant parts of hardware to software using e.g., Field Programmable Gate Arrays (FPGAs)
    • maintain the fast and disciplined experiment / learn Product Culture as in pure software products
    • learn from the software guys: encapsulate complexity behind stable APIs / interfaces
    • test integration interfaces again and again – experience clearly shows that problems show-up here
    • use the 3D printing technologies that has become both highly advanced and mature

The more we’re able to reduce physical dependencies, the better we’re paving the way for Set-Based Design.

Set-based design (SBD) is a complex design method that enables robust system design by

1) considering a large number of alternatives,

2) establishing feasibility before making decisions, and

3) using experts who design from their own perspectives and use the intersection between their individual sets to optimize a design (Singer, Doerry, and Buckley 2009).

Model-based engineering (MBE)/model-based systems engineering (MBSE) with an integrated framework can enable the use of SBD tradespace exploration, for some situations (i.e. early-design stage with low fidelity models), in near-real time (Specking et al. 2018a). 

Guide to the Systems Engineering Body of Knowledge

Again – strong Configuration Management is essential.

Risk-control

Marty Cagan has listed four key products risks for especially purely digital products. We need to add a risk-area related to the production of physical products:

  • valuable for the customer
  • usable for the customer as intended
  • feasible for us to build
  • viable for our business
  • we're able to produce the product (in serial production)

Balancing these risks and making fact-based decisions is core in a strong Product Culture as highlighted in earlier posts. The point is that we need to understand and balance all five risks. 

Wrap-up

The good news is that achieving a high-paced, sustainable innovation and production of high-tech product is both possible and profitable. Tesla (and SpaceX) are examples of living proof.

The bad news is that it is difficult and hard calling for a fundamental reprogramming of the more “traditional” product company with a traditional modus operandi.

Bonus information

If you can spare some of your time, the videos below by Joe Justice provide an insight into how e.g., Tesla thinks and operates with high-tech product innovation. Nothing less than mind-blowing!

Update

This update to the original post will aim at cherry-picking from Joe Justice’s insights provided in the videos.

    • Working with Bill Gates, Bill’s opening question was always “How much of this can we do in parallel?“
    •  Joe Justice’s approach has significant similarities to Henrik Kniberg’s “Spotify Model (though Henrik Kniberg emphasizes that is it not a “model”)
    • “It is all about speed of feed-back loops“
    • “If the company is structured around the cross-functional teams … that is your company structure … you don’t need any other hierarchy“
    • Making sure that everything fits together from the autonomous teams calls for continuous integration …  “If something is difficult, do it all the time” (done by robots to a high degree)
    •  “Every car has a digital twin (red.: configuration) with a details down to the single bolt and glue used … everything!“. “This is a major IT-project!“
    • “Tesla is a digital-native from Silicon Valley making it comfortable doing changes in real-time“
    • “There is no marketing department, there is no competitive analysis department … because everyone has very clear encouragement to approach the law of physics“. “Any product goal less than what is physically possible is vulnerable to competition“

If something is physically possible, not only is someone doing it, but there is also an award show

Elon Musk

    • “Traditional lean one-piece flow (the Toyota production system is famous for it) makes change very expensive … encourages getting it perfect before deploying to production … resulting in long lead-time for changes … which again delays getting feedback from production to improve design … rendering the slowest possible deployment cycle“. “The traditional lean one-piece flow is completely inappropriate if you want speed of change!” 
    • “In contrast, Massively Parallel Concurrent Manufacturing [MPCM] is optimized for change. Here there is no one-piece production line at all“
    •  “In MPCM we’re using massively automated unit and integration tests (like with a build-server in a software environment)“
    • Knowledge sharing and -development across teams is facilitated using Communities of Practice (CoP)

NB. Getting CoPs to function will probably be a topic for a future post.

Posted on

ISO 9001:2015 in a nutshell

ISO9001:2015

The ambition with this post is to provide a, hopefully, quick and easy to grasp understanding of

  • What ISO 9001:2015 and its purpose is
  • Where ISO 9001:2015 makes sense
  • The structural overview of ISO 9001:2015

ISO 9001:2015 and its purpose

In its core, ISO 9001:2015 is about consistency and predictability aiming for customer satisfaction and loyalty via conformity to customer requirements and applicable legal and statutory requirements. It does not provide any measure of quality-level / maturity (as is the case with e.g., the CMMI model) – it “only” addresses consistency of the “quality”.

To achieve this, ISO 9001:2015 prescribes a set of requirements to Quality Management Systems [QMS].

Context and where ISO 9001:2015 makes sense

Process areasTo keep focus we’ll here assume the context of a high-tech product company innovating, producing and selling its own multidisciplinary (electronics, hardware, mechanics, embedded software, application software, Cloud services …) products. The company has three core product process areas (A), (B) and (C). 

It makes perfect sense to aim for consistency / predictability in (A)

    • Serial production of products with the aim of delivering a consistent product quality level
    • Customer delivery projects with the aim of conforming to the classic “project iron triangle”

In contrast, trying to enforce strict process prescription in (C) or (B) will be highly counter productive defying what we want to optimize for – adaptability.

Just to be clear – as mentioned in numerus earlier posts like here, the areas (C) and (B) will benefit significantly by having a rich pick & use buffet of processes and good practices. The difference to (A) is that we here aim for a minimum viable process prescription.

The rest of this post will thus assume that we’re in process-area (A).

How ISO 9001:2015 is structured

A number of ISO’s international standards, including ISO 9001:2015, share the same structure called HLS (High Level Structure) or annex SL containing 10 clauses:

    • Scope
    • Normative references
    • Terms and definitions
    • Clauses 4-10 below being the ones subject to formal audit
High Level Structure

As indicated, the HLS evolves around continuous PDCA improvement cycles. Visit ISO.org for details.

Examples of other ISO standards based on HLS

Posted on

Renewable Tech – the journey towards a strong Product company (part 3)

Renewable Tech part three

Here in part 3 we’ll discuss Renewable Tech [RT]’s strategy for how to bring live to its vision.

Recap from part 2

Part 2 outlined RT’s vision to become a strong Product company thus making a radical shift in the business model from being a provider of customer-specific solutions.

The vision is essentially to build an organization filled with missionaries, working in a strong Product Culture.

Executive summary

Transforming RT from being a solution provider to a product company is, not surprisingly, a complex and difficult challenge. It is a reprogramming of RT’s strong genes:

    • From an Output-based business model to an Outcome-based business model
    • From a Project mindset to a Product mindset

To make it worse – the transformation cannot be planned up-front, at least not in details, for the simple reason that we have not only a lot of known unknowns, but definitely also a lot of unknown unknowns. 

The only sensible way to learn insights, uncovering the unknowns, is through disciplined experimentation. This is why the core of the strategy below is based on experimentation, here in the form of an internal start-up given the name RT-accelerator.

Start small and grow from there

As outlined in part 2, RT is determined to grow a strong Product Culture with one of the traits being a culture of experimentation, which will form the backbone in RT’s strategy reaching for the vision.

    • RT needs to protect the current business while at the same time reaching for the vision
    • RT is keenly aware of the fact that currently more unknowns than knowns exist on how make the vision come to live thus making a detailed roll-out plan impossible – and counter productive
Ripples

RT will start by throwing a small stone in the pond – running an experiment – and let the insights and learnings spread from here. This stone will be in the form of an internal start-up.

The internal start-up

Golf putting

The purpose with the internal start-up experiment is make unknows, known, and generate insights thus testing the hypothesis “the vision is viable in RT“.

If the experiment falls flat to the ground, it does not undermine the running business. If on the other hand it turns into a success, it’ll be the most convincing argument for the rest of the organization to adapt.  

Running this start-up experiment is like putting on the green in golf. You need the give the ball a fair chance. If you do not hit the ball hard enough, it might not even reach the hole. We thus need to make sure to design the experiment in way that a failed experiment cannot be argued with not having been given a fair chance.

Let’s look at the experiment design ensuring that we hit the ball hard enough … but not too hard. We also need to find a balance between the experiment not being too narrow and not being too broad.

Experiment design

As recommended earlier, we’ll restrict the experiment to one product area: RT expects the area of condition monitoring and predictive maintenance, applying ANI, to grow significantly in the future based on currently not known innovative high-tech solutions. We’ll call the internal start-up “RT-accelerator“.

This is the top-level decomposition of the condition monitoring and predictive maintenance product area:

    • Physical sensors with site-local control electronics, mechanics, network infrastructure and hardware
    • Embedded controller (edge-) software, local 5g IoT and predictable network capabilities
    • Cloud-based monitoring capabilities base on e.g., ANI with strong APIs enabling RT’s customers a seamless integration with their relevant systems like SCADA 

For areas of importance designing the experiment, we’ll here seek inspiration from the previously presented Innovation Power Wheel.

Business agility

Innovation power - product culture

Innovation Power: Product Culture

Here we’ll discuss how to include the elements from a strong Product Culture in the experiment design.

Product Culture: Culture of experimentation

The rationale behind experimentation is to gain insights and facts / data upon which to make qualified decisions. These experiments will typically fall within the four generic product risks:

    1. is the solution valuable for the customer?
    2. is the solution useable for the customer?
    3. is the solution feasible for us to build and produce?
    4. is the solution viable for our business?

We do not want decisions to be made by gut-feeling or by HIPPO (Highest Paid Persons Opinion). We’ll insist RT-accelerator to be able to demonstrate insights / facts gained through e.g., experiments and have decisions made on that basis.

RT-accelerator design element: Use fast but well-designed experiments to gain insights / data upon which to make qualified decisions.

Product Culture: Culture of open minds

In RT-accelerator we maintain an open mind for new and better solutions to the problems – without bias on the source of ideas.

Fall in love with the problem, not with the solution.

Marty Cagan, INSPIRED p. 129 on Product Vision

RT-accelerator design element: Maintain an open mind allowing innovative ideas for problem solutions thus not getting fixated on one solution. This also is related to dual-track agile having discovery and delivery running in parallel.

Product Culture: Culture of empowerment

We want the Product Teams in RT-accelerator to use an Outcome-based business model meaning that we’ll hold the Product Teams accountable for Outcome. In exchange we’ll empower the Product Teams to find the best solution to a given business / customer problem.

Product Leadership will agree OKRs (Objectives & Key Results), Objectives being the Problem to solve, with the Product Teams.

RT-accelerator design element: Empower the Product Teams to find the best solution to a given problem, and hold the Product Teams accountable for the resulting Outcome.

Product Culture: Culture of technology

As already stated several times, technology is the product. As we’ll return to under organizational structure and servant leadership, Product- and Technology leadership have an important role ensuring the perimeter – including strong technology strategies – within which the Product Teams operate

RT-accelerator design element: The Product Teams must be provided with a strategic context, which includes strong technology strategies.

Product Culture: Culture of business- and customer-savvy teams

As outlined by RT’s executive team in the vision, these Product Teams need to be both business- and customer savvy. That is, serving the real customers and understand the constraints under which the business stakeholders operate.

RT-accelerator design element: The RT-accelerator Product Teams are not only allowed but required to maintain a high-frequency interaction with (potential) customers – directly – with the purpose to test hypothesis / assumptions. In addition, the Product Teams are required to understand the constraints under which the business stakeholders operate.

Product Culture: Culture of skill-set and staff diversity

Covered by the culture of open minds.

Product Culture: Culture of discovery techniques

The discovery techniques are highly correlated to the culture of experimentation. This is about developing a diverse discovery toolbox and about understanding the applicability of each discovery tool.

Marty Cagan’s INSPIRED is filled with such discovery techniques. One particular important technique to master is the “Discovery Sprint Technique”, also known as a “Google Sprint” because it originates from Google Ventures.

We want the RT-accelerator Product Teams not to apply e.g., the MVP (Minimum Viable Product) technique the wrong way. A common misunderstanding is that a MVP is in fact a “Product” suitable for consumption (the phrase “P for Product” in MVP is probably what misleads people). It is not. 

The MVP should be a prototype, not a product.

Marty Cagan, INSPIRED p. 29-30 on Minimum Viable Product

What RT-accelerator brings to the market must comply with RT-accelerator’s brand and quality expectations. A prototype / MVP is not meeting these criteria.

RT-accelerator design element: Have the Product Teams, supported by relevant coaching, develop competences in discovery techniques.

Organizational structure

Innovation Power: Organizational structure

RT-accelerator is carved-out and getting its capacity from the RT mother-organization. In some areas, like (serial) production, RT-accelerator cannot realistically be self-contained thus needing an appropriate interface to RT’s production facilities. Most of the leadership / management functions can realistically not be allocated full-time for RT-accelerator thus requiring the given leadership / management functions to act in a double role in RT and in RT-accelerator.

RT-accelerator

We’ll here define the minimum viable leadership / management structure for RT-accelerator to test the hypothesis “the vision is viable in RT”. We’ll return to RT’s role as VC (Venture Capitalist).

Org. structure: CEO, CPO and CTO

In the classic start-up, the founder is also the Head of Product and Head of Technology. For RT-accelerator we’ll aim for a person acting in a combined role as Head of Product and Head of Technology. This could e.g., be one of the directors (with a solid market understanding) in RT’s R&D organization.

We’ll call the combined role in RT-accelerator “CCC“.

Org. structure: Functional managers

The functional managers will have to balance their normal role in RT with their part-time role in RT-accelerator.

Org. structure: Product Manager

Here we’ll operate with one full-time Product Manager [PM] covering all three Product Teams – see Product Team Topology below. As mentioned several times earlier, e.g., here, this is a very challenging role. This PM could be sourced from e.g., the current and classic Product Management area in RT, or from the group of Key Account Managers in RT.

Org. structure: Product Team Topology

Our aim is to have these three Product Teams as decoupled / autonomous as possible, yet highly aligned.

Team Topology

Each of the three Product Teams will be provided with the needed cross-functional competences for the individual team to minimize the dependencies for competences outside the team. 

What happened to the project manager – why is that role not mentioned explicitly above?

The short answer is that we’re not running delivery projects in the classic way like seen with e.g., PRINCE2©.

The slightly longer answer is more nuanced. Many of the solid tools found in the project management toolbox are still valuable, used in the right context. The Product Team Template mentioned earlier does not include an explicit project manager role. It does include a Tech Lead, a Scrum Master and a Product Manager (with one of the responsibilities being the Scrum Product Owner, owning the Product Backlog). In practical terms this means that the relevant project management competences are expected in the Product Team. End of the day, the Product Teams are self-organized including the needed level of planning.

Project managers from RT can have different paths into RT-accelerators Product Teams, depending on their profile and interests:

    • Product Manager (including the Scrum Product Owner role) if the RT project manager has a strong commercial profile
    • Tech Lead if the RT project manager has a technically strong profile
    • Scrum Master if the RT project manager is experienced with e.g., Scrum / Kanban. NB – some teams do not need a Scrum Master at all.
    • Delivery Manager. In INSPIRED chapter 19, Marty Cagan presents his definition of and rationale behind the “Delivery manager” role:

In growth-stage and enterprise companies, many product managers complain that they have to spend far too much of their time doing project management activities.

Delivery managers are a special type of project manager whose mission is all about removing impediments for the team. These delivery managers are typically also the Scrum Masters for the team (if they have that role). They are all about helping the team to get stuff live faster, not by cracking the whip buy be removing obstacles that get in the way.

If your organization is small then it is ok not to have a delivery manager.

Marty Cagan, INSPIRED chapter 19 on The Delivery Manager Role

Note that we’ll not let RT-accelerator be enslaved by e.g., what the official Scrum Guide says about the Scrum Master role. If what works best for en given Product Team in RT-accelerator, is to have the Scrum Master cover some project manager tools / techniques, then it is perfectly ok. We want to have a non-dogmatic approach.

RT-accelerator design element: Carve-out a viable RT-accelerator organization from the RT-mother organization.

Servant leadershop

Innovation Power: Servant Leadership

What is important to understand is that RT-accelerator uses an Outcome-based business model having the Product Teams empowered to find the right solution to a business / customer problem, but being held accountable for the Outcome.

This is fundamentally different from the classic Output-based business model with (project-)teams being told what solution (from e.g., a feature roadmap) to develop and deliver.

The Outcome-based business model calls for Servant Leadership contrasting the Output-based model with a more classic Command & Control leadership style. The following is expected from the leaders / managers having a (part-time) role in the RT-accelerator experiment:

Servant Leadership: Provide meaning and strategic context

Product- & Technology leadership (called CCC in RT-accelerator) has the important responsibility of ensuring a compelling, inspiring and empowering Product Vision. This Product Vision will act as a common North Star throughout RT-accelerator and support the alignment of the autonomous Product Teams. 

Servant Leadership: Provide direction

The Product Teams are given (hard) business / customer problems to solve (note: in contrast to being told what solution to implement). CCC is (also) responsible for the Product Strategy, in essence describing the business / customer problems to be solved.

We’ll use the OKR technique to agree Team Objectives (problems to solve) and Key Results to monitor progress. The use of OKRs is new in RT-accelerator (and in RT) thus calling for some coaching to get started. 

Servant Leadership: Enable (real) empowerment

The leaders / managers need to see themselves as facilitators in contrast to their normal command & control mode.

Servant Leadership: Support teams and individuals

This is about coaching, supporting teams to interact, removing impediments and ensuring fast decisions. Included would also be the active facilitation of CoPs (Communities of Practice) across the Product Teams. A future post might take a deep-dive into the nature of CoPs.

RT-accelerator design element: The leaders / managers in RT-accelerator need to train Servant Leadership including getting Product Vision and Product Strategy right. We’ll also need a (minimum viable) process for the disciplined follow-up / review of the Team OKRs.

Minimum viable governance

Innovation Power: Minimum Viable Governance and VC-style funding (also called metered funding)

As other start-ups, RT-accelerator needs funding for its product development. RT will act as the Venture Capitalist [VC] with whom RT-accelerator will seek funding.

The Product Teams will, as would be the case with a “real VC”, have to present a convincing case documenting factual progress and compelling reasons for continued funding. In the initial stages, progress will primarily be in the form of gained insights / learnings.

It would be natural for the Product Teams to use the transparency already in place: The Team OKRs.

Minimum Viable Governance: The Business Case question

In the majority of organizations doing product development, you’ll find product roadmaps based on a prioritization of Business Cases (in its core being a viability calculation based on cash-flow).

When the Product Team is presented with a problem to be solved, it does not (yet) know the solution to the problem thus not knowing the cost to solve the problem or what incoming cash-flow the to-be-identified solution will generate – the basics for the cashflow and NPV calculations in a Business Case. Demanding Business Cases at this point in time would be pure guess-work.

Is what you’re saying that Product Teams in a strong Product company are not using Business Cases?

Depends – in the initial stages we know, what we do not know: the solution to the problem and the resulting cash-flows. In later stages having settled on the solution, it can become relevant to develop a Business Case; especially when large investments are needed.

RT-accelerator design element: We’ll need to define a minimum viable governance & funding process model. 

Innovation Power: Minimum Viable Process Prescription and a rich pick & use Buffet

We want to achieve and balance two objectives:

    1. Have rules of the game presented in clearly understood in prescriptive processes. We’ll do our utmost to have as few mandatory processes as possible.
    2. Facilitate knowledge sharing and -development. We do this by encouraging the development and use of a pick & use buffet with best-practices in various areas. We want the ownership of this buffet shared among the CoPs across the Product Teams.

Process balance

RT has for a long time developed a project process universe (for customer-specific solutions) with a lot of processes, check-lists, governance structures etc. – why not just recuse that in RT-accelerator?

Because the existing RT project process universe is built to serve an Output-based business model for customer-specific solutions, optimized for predictability within the “project iron triangle”. See quadrant (C) in the optimization matrix. In contrast we want RT-accelerator to optimize for innovation as depicted in quadrant (A). The two modus operandi are fundamentally different.

But – we do expect some natural overlap, especially when it comes to bringing solutions into (physical) production.

Shared assets

RT-accelerator design element: RT-accelerator is not committed to comply with the existing project process model in RT. In fact, RT-accelerator will focus on building its own best-practices for product innovation and adaptability supporting the Outcome-based business model.

Innovation power - technology excellence

Innovation Power: Technology Excellence

As stated earlier, the basic assumption is that the individuals from RT allocated to RT-accelerator have solid technology insights and experience.

In RT-accelerator we’ll focus on system engineering / architecture as a means to minimize dependencies internally and between teams. This is because such dependencies kills effective innovation and business agility. 

The software guys have shown the way for several years with object-oriented designs and encapsulation behind stable interfaces / APIs. We need this notion of encapsulation to permeate the full product, also including the physical dimensions.

This is also known as “contract-first” with contract meaning the interface. The better we get at this discipline, the better we can facilitate teams working towards the same target (staying aligned) and at the same time working autonomously.

The discipline of testing / validating integration interfaces must be an on-going effort not postponed to some “late integration stage”. The software guys call this CI (Continuous Integration). 

RT-accelerator design elements: The Product Teams and the functional managers in RT-accelerator need to focus on engineering disciplines allowing a high degreed of de-coupling between teams.

Other experiment design criteria

Experiment duration

Long enough to follow the end-to-end dynamics from business / customer problems to Outcome.

Hypothesis pass criteria

A combined qualitative and quantitative assessment will be developed.

Follow-up and handling of impediments

RT’s executive board maintains a Kanban board with impediments from RT-accelerator with the purpose of quick mitigation and transparency.

Proudly powered by WordPress