Sociocratic decision making

Sociocratic decision making

Introduction

Quite often the challenges with making decisions are the following:

  • It’s difficult to get all parties involved aligned towards a decision.
  • Once a decision has taken, some degree of uncertainty remains if people actually support the decision.

Welcome to sociocratic decision making

Sociocratic decisions differ from autocratic (no to low support, but fast decision making), democratic (with majority vote) (at least 51% vote support), and consensus (broad support, but time-consuming process).

Sociocratic decisions are made with consent. Consent means there is no reason not to object. In other words, there are no compelling reasons not to agree to proceed and to try out whatever is being proposed. Any concerns raised can be taken into account. Objections must be taken into account and are to be resolved.

Prerequisites for consent decision making

  • participants involved are consciously thinking about moving forward with a proposal for next best action (“it’s good enough for now, and safe enough to try”),
  •  all participants consider each other equivalent.

Pattern for sociocratic decision making

  1. Introduce the matter to decide upon (in sociocracy 3.0 this called a “driver”: what’s happening right now that motivates us to present this matter?)
  2. Round of consent agreeing to the matter
  3. Present the proposal for next best action
  4. Round of clarifying questions
  5. Round of brief response – in order to get a first short indication of level of agreement
  6. Indicate consent (agree with consent, object, agree with concerns)
  7. Resolve objections (one by one) by improving the proposal (on the spot, or prepare for next meeting)
  8. In case of no objections (left): consider decision agreed upon: celebrate!
  9. Consider any concerns (optionally)

Note: the phrase “it’s good enough for now, and safe enough to try” is taken from sociocracy 3.0.

The next action of a decision agreed is to honor to check upon the outcome of the decision, and if necessary act upon improving it, in a next iteration.

Agile/lean podcasts!

Listening to podcasts

Podcasts are a great way to learn and to listen in to conversations with people you’ve might have heard of, but you don’t really know who they are. Podcasts are a tremendous source to learn about new topics – virtually anything!

I’ve been listening to podcasts for a while, mainly topics relevant to my professional occupation – but there are many many podcasts out there! I listen to podcast when commuting to work, on public transport or you can connect your mobile phone using bluetooth to your car audio system. At home in the evening, I can enjoy listening to a podcast (or an audiobook) – it’s a different experience than reading a book or blog – and I find it more relaxing.

Recommended podcasts on the topic of agile & lean thinking

Scrum Master Toolbox Podcast

Host: Vasco Duarte

Format: short episodes (10-15 minutes), from time to time a special longer episode

Content: Interviewing Scrum Masters world-wide

Why I like it: Vasco is a a great interviewer, the podcast has a clear structure, and Vasco is knowledge able on the topic – in other words, he can place questions and answers, he can put items discussed in a larger context. You hear real-world experiences of Scrum Masters. One remark: I do sometimes skip certain episodes if the interviewee doesn’t speak English good enough 🙂

The podcast has a fixed format: each week a Scrum Master is interviewed. Each day of the week, the Scrum Master interviewed is asked a question.

And some Belgian have been interviewed too! (Gunther Verheyen, Yves Hanoulle)

List of the episodes

Agile for Humans

Host: Ryan Ripley

Format: mostly panel discussions, sometimes interviews with a specific interview during a conference. Episode length around 1 hour average.

Why I like it: these podcasts are recordings of informal chats and panel discussions, with people like Tim Ottinger, Zach Bonaker, Amitai Schleier. By listening you can follow their thoughts process, hear pro’s and con’s and challenge their thinking with your own thinking.

List of the episodes

Agile Uprising

Host(s)Ryan Lockard, Andy Cleff and others.

Format: panel discussions, interviews

Why I like it:

  • The Agile Uprising are interviewing some of the prominent principal agile & lean thinkers. This is a great chance to hear some of the thought leaders, talking about the past, present and future of agile and lean. Interviews with: Mary and Tom Poppendeick, Martin Fowler, Jurgen Appelo, Jeff Gothelf, David Anderson, Joshua Kerievsky, Jason Little, Ken Schwaber, Ron Jeffries, Jeff Sutherland, Andy Hunt, Mike Beedle, Bob Martin (Uncle Bob), Alistair Cockburn, and many others!
  • The Agile Uprising had a project in which they interviewed most of the agile manifesto signatories. You can hear them speak about how the agile manifesto for software development came about, how the term ‘agile‘ was chosen, and how actually that meeting at Snowbird, Utah, in 2001 went.

Listen to the Manifesto Author Review. (currently 14 out of 17 of the original signatories have been interviewed)

I can highly recommend the episodes of the manifesto author interviews – the set of questions are largely the same for all interviewees:

  • What were your activities and professional occupations with regard to the “lightweight” software development processes prior to 2001?
  • How did you get invited to the event at Snowbird?
  • How did the event went? The day prior, the 1st day and 2nd day – you can insight how the word “agile” came about
  • What are your thought on how the agile movement grew, since 2001?

Agile Uprising List of episodes

Challenging Sprint Retrospectives

For the readers: A reference for organising retrospectives is the book “Agile Retrospectives – Making Good teams Great”, by Esther Derby & Diana Larsen. They describe the main steps of an agile retrospective.

The prime directive of retrospectives has been formulated by Norman Kerth in his book “Project Retrospectives: A Handbook for Team Reviews”.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

You can find online all kinds and sorts of formats (games) for retrospectives; I’ve found back a description of a ‘base’ agile retrospective, and I’d like to recommend this to anyone. It focuses on what went well, what could better, and next on identifying and committing to action points for improvement.

What are your thoughts about retrospective facilitation techniques?

Reference to post: “Challenging Sprint Retrospectives

Plan Do Check Act

Plan-Do-Check-Act

Een belangrijk element in een continue verbeteringsproces is een continue cyclus van plannen, uitvoeren, verifiëren en bijstellen. De uitdaging is om deze cyclus herhaaldelijk te blijven uitvoeren, zodat de zin voor kwaliteitsverbetering een continue gegeven wordt.

De indeling van deze stappen zijn de stappen zoals aanwezig in de wetenschappelijke methode: het formuleren van een hypothese, het uitvoeren van een experiment, en het evalueren van de resultaten (om de hypothese juist of fout te verklaren). Deze Plan – Do – Check – Act cyclus (PDCA) is gekend als de kwaliteitscirkel van Deming. PDCA vormt de basis voor continue verbetering en is een element van lean productie.

Scrum als ontwikkelingsraamwerk voor complexe producten heeft zijn origine in lean productie (lean thinking). Het artikel (The New New Product Development Game) spreekt over “incrementele verbeteringen”.

Hoe “Plan – Do – Check – Act” zichtbaar maken in een team?

Continue reading →

No Business Plan Survives First Contact With A Customer – The 5.2 billion dollar mistake.

Incredible story before the 2000 “dot.com” boom illustrating the lack of customer development.

Lesson learnt (by Steve Blank)
– Business plans are the leading cause of startup death
– No Business Plan survives first contact with a customer
– Rapidly changing markets require continuous business model iteration/customer development
– Your ability to raise money has no correlation with customer adoption

Source: http://www.businessinsider.com/no-business-plan-survives-first-contact-with-a-customer–the-52-billion-dollar-mistake-2011-1

Leancamp (Rotterdam)

Lean Camp is an unconference on topics as Lean Startup, Lean UX, Design Thinking, Product design, etc.

I like unconferences as each attendee has the opportunity to participate (you can propose a topic), and the interactivity is really high.

I participated in a discussion on integrating UX in agile development team; and how to maximise learnings from serious games – for example Playing Lean.

Continue reading →

Lean Startup – Playing Lean

Lean Startup

Lean Startup is a method, an approach for developing businesses, products or services. The method has been developed and made popular by Eric Ries. In September 2008, Ries first coined the term on his blog, Startup Lessons Learned, in a post titled “The lean startup“. His book “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses” was published in September 2011.

Continue reading →

Hypothesis

Assumption-driven development: hypothesis writing

THINK: assumptions and hypothesis

Instead of expressing “requirements” we consider assumptions and we declare hypothesis statements. A hypothesis statement is a way of expressing assumptions in a testable form.

Reality often shows that the creators of a product or services are not sure what a user actually needs or wants, or how it should work, with regard to the user experience. But quite often organizations, or companies simply proceed with their idea for functionality or user experience, without input what the user needs (or what the user thinks about it), and without checking (testing) with the end-user throughout the development process.

Quite frankly, organizations which have been in business for many years (decades) think (with some level of arrogance) to know what the customer wants and how the experience should be – but this arrogance will bounce back with failure: an unhappy end-user will trash the product and its experience if it deemed to be unfit.

Hypothesis statement

A hypothesis statement will require experiments to find out if which assumptions are right or wrong.

A first step is to list any assumptions: an assumption is a declaration of what we assume to be true. But it’s not considered a requirement, until we actually have facts and figures to support it. Assumptions comprehend both business and user assumptions. A possible way to start listing assumptions is to start from a problem statement. Problem statements are full of assumptions. When assumptions are listed, it’s crucial to select the ones that are the most uncertain.

A main principle of Lean Startup is to expose the highest risk first, so we can learn. The exercise of listing assumptions and hypothesis should be done with the whole team: everyone involved, so you can create a shared understanding from the start.

A hypothesis statement has the following format:

Hypothesis

Hypothesis

Note: This is a possible format, and there’s no obligation to follow this blindly, as long you understand the purpose and you have the different elements.

Outcomes (objectives) and metrics

It is essential to focus on outcomes first: what are we trying to achieve, what kind of objectives? What kind of user needs? Instead of directly thinking about features (solutions), we focus on outcomes. When creating the product, the progress will be measured against the outcomes. To be able to measure, you need to define a set of metrics. A good approach to this, is Objective-Key-Results.

Features (functionalities, stories, …)

Features exist to serve the needs that have been identified. To fulfill an outcome, you think about creating a certain feature (solution, functionality, story). It’s important to have the outcome first defined, and next think about possible features.

User assumptions

It is essential to know something about the customer, the end-user you’re creating the product for. Personas are a well known technique to make the end-user visible.

The clue is to approach the creation and validation of personas the lean way: personas are not the output of great research upfront, but are created and evolve like the product evolves. Personas created with lots of work upfront, and not updated afterwards are essentially throw-away personas: they become useless as soon as they are outdated, and concern a source of waste.

We prefer to create “ad-hoc” or “proto”-personas: these represent the best guess as to who is using the product and why. A proto-persona contains the information (demographics, behaviours and needs) of a certain type or segment of end-user relevant to the product being designed.

Resources

Lean UX book

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX book by Jeff Gothelf.
Lean UX (Jeff Gothelf)

Read more about the Lean UX cycle.

Read more about the Lean UX book.

Objective Key-Results

In any context, objectives (or outcomes) are important as they give guidance or direction; instead of only focusing on solutions.

(Solutions in the broad meaning: a product or service, an improvement, a feature, a functionality, …)

Quite often, solutions are proposed or defined without an objective in mind. To reach a certain objective, multiple solutions are possible. We want to track progress with respect to objectives, not only solutions.

When teams are given an objective, teams have the possibility to think for themselves what are possible solutions, and which solutions fit the best in the current environment (system, product, service, …). In general, teams who own part of the problem statement and the solution space are more motivated, more focused, more creative, as they feel ownership.

Objective Key Results

Objective Key Results

OKRs = Objectives + Key Results

It is a method of defining and tracking objectives and their outcomes.
[Source: wikipedia.org]

  • Objectives are what the organization or individual want to accomplish, and are typically subjective, qualitative. Objectives can be ambitious, can be challenging.
  • Key results are concrete, specific, and measurable. They describe how you will accomplish the related objective, and measure whether you accomplished the objective or not.

The clue is that Objectives Key Results can be defined on several levels in the organization: for example executive management, departments, products or services, teams.

How Google sets goals

Lean UX cycle

Lean UX cycle

Lean UX = applying Lean and Lean Startup principles to User eXperience.

Remove waste from the UxD process

Too much too often product (software) design and development is document-driven. With the agile manifesto and principles in mind, we want to focus on creating great and valuable products (software) and releasing these early and often to get valuable end-user feedback, in order to improve our products (software) iteratively and incrementally.

Forget about the overload of UxD deliverables that are created to communicate “specifications” to “developers”. Re-consider and only create those deliverables that truly serve a purpose. We value “making” over “analysis“; we value “building” over “specification“. Lean helps us to focus on flow and to reduce non-value creation (waste).

What do I mean?

Useful deliverables (depending upon your context):

  • Branding and styleguide (by preference a living styleguide, to minimise maintenance effort)
  • Low-cost prototypes used in user testing
  • Low-cost sketches, mock-ups, designs, etc

Overhead deliverables:

  • Detailed User Interface specifications (for example including annotations of every screen)
  • Wireframes of every screen, every screen size
  • Visual designs of every screen
  • High-fidelity mockups (not reused in development)

Try to minimise the “upfront” creation of large UxD deliverables to be handed over to developers, instead rely on true cross-functional collaboration.

Cross-functional collaboration

True cross-functional collaboration (including designers, including UX people, including usability engineers, including developers, including product owners, including business stakeholders, marketeers, etc). True agile cross-functional collaboration is the foundation and the catalyst for collaboration and short development / release cycles. Agile re-focuses product (software) development on value creation and working products (software).

In every step of the cycle, and from the very beginning, the whole team is involved. The whole team approach aims to create a shared understanding with everyone, all the time. Knowledge, user feedback can be quickly spread and shared, and the team minimises the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).

Apply the scientific method

BUILD > MEASURE > LEARN

or

MAKE > CHECK > THINK

The scientific method exists for centuries and we are simply applying it to nowadays product (software) development.

"The Scientific Method as an Ongoing Process" by ArchonMagnus - Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

“The Scientific Method as an Ongoing Process” by ArchonMagnus – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

In Lean Startup this is known as the build > measure > learn cycle. This is an on-going process, it obviously doesn’t stop with 1 iteration. We also call this make > check > think.

Lean UX cycle basic

Lean UX cycle basic

The only way to create products (software) which matter for your end-users, which mean a difference, which serve their needs is:

  • by first focusing on outcomes (objectives) and next on features (solutions)
  • by getting in touch with your end-users, observe and measure how they use your products
  • by focusing on creating valuable experiments to expose risks and uncertainty
  • by improving whatever you’re making based upon that feedback
  • by building upon collective knowledge and wisdom and let the whole team flourish in creating the best experience
  • by creating products iteratively and not only incrementally
  • by minimising the total time going through this process
  • by creating an environment of continuous learning

Learn more about Lean, Lean UX and product development with experiments in follow-up posts!

  • Techniques to bring UxD and development closer together, why collaboration matters.
  • The scientific method and product development with experiments
  • How to organise user testing
  • How to incorporate validated learnings

Resources

Lean UX book

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX book by Jeff Gothelf.
Lean UX (Jeff Gothelf)

A few articles

Lean UX cycle

Lean UX: What is Lean UX?

Lean UX is about apply lean principles to User eXperience.

Why?

There are 2 main observations:

Bad UX. Failed products.

Unfortunately, there are still too many (software) products and services built and released on the market, that do not fit the customers’ needs. This is a long lasting pain in software development. Nowadays thanks to modern web & mobile technologies, possibilities are endless. But than again there are still too many useless, badly designed, wrongly understood, misfit products with failed UX.

Search the web for “failed products” and you get a few examples.

Creation of software by writing documents.

The purpose of creating software is to serve the users’ need, to solve their problem, to automate their work, to meet their goal, to be convenient in use. Software is an end, not a goal. The experience has to be right, it must properly function, the experience should be neat and crisp.

Unfortunately, when creating user experiences, many product (software) development teams are organised in a way so that:

UX people “produce” the “UX” and create a document, a deliverable (“the UI/UX spec“). “The spec” is delivered to the developers who will make the wonderful UX real.

Documents do not solve users’ problems; software does.

With the agile manifesto in mind:

Working software over comprehensive documentation

We know and we owe it to ourselves to focus on delivering a working product, to collaborate and to work to the highest standards, and to minimise any unnecessary intermediates (such as “the spec“). So why do still so many teams (agile or non-agile) keep on focussing on “big UX design upfront”?

Applying Lean principles to product creation and UX will help us to focus on creating a right product fit, by creating value, and by minimizing any waste in the process. Likewise agile, likewise lean, Lean UX is a mindset, a process change and a way of thinking how to create the right product in the right way.

Lean?

The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

What is Lean? (lean.org)

UX?

UX or User eXperience is about the user experience, but also the whole customer experience. It’s more than design aesthetics. It’s the result of the combination of design, interactions, architecture, technology, business goals, etc.

UX iceberg

UX iceberg

Source: UX iceberg;
http://arquiteturadeinformacao.com/wp-content/uploads/2012/03/ux_iceberg.png

Lean UX

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX (Jeff Gothelf)

Lean UX (Jeff Gothelf)

Getting out of the deliverables business

Once upon a time, there was a marketing guy, with great ideas for a new software application.

He hired a business analyst, who described all those ideas in formal fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created detailed the User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to a functional specification, and trying to figure out how to connect it to existing infrastructure and systems.

Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect visual designs for each and every screen of the application. Given the functional specification, a technical analyst created a technical specification and application design trying to capture all the given information, in a deliverable that would make sense as input for development. Sometime later, a copywriter was given the assignment to write on-screen text labels and copy, based on the wireframes. And even some times later, a tester was given the assignment to understand the requirements and write test scenarios.

Development was about to get started!

Sometime later, during development, some concerns rose about the User Interface of the application and a usability engineer reviewed the User Interface specification to give some advices and remarks.

So, what do we observe?

  • The work goes sequential
  • Individuals doing their own thing, producing output: deliverables, documents!
  • Time passes by
  • Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation

Let’s retrospect.

Silo teams

The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?

Focus on outputs, not outcome. People are appreciated for their output: mainly documents and the quality of those documents.

Those documents are written by an individual, or a group of individuals of the same expertise – documents are passed on (with or without explanation). Output of one phase, is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each individual needs to re-interpreter the work of the previous. No real sense of ownership.

It’s a very time-consuming process. From inception to actual start of development, it can take months – depending upon the size of the project.

Assumptions, lots of assumptions! Hypotheses based on those assumptions. A requirement spoken by the guy from marketing – as great as it might be – remains an assumption until proven by the market: feedback from real end-users: the customer.

There is little to no opportunity to react and correct the design of the new software application, when new insights or market conditions come up meanwhile developing.

Probably the whole process is overseen and controlled by a commanding officer.

Where’s our marketing person? Out of sight

A chain is only as strong as it weakest link.

Teams used to a sequential process have become accustomed to handoffs between specialists. Each team passes off their work to the next team. Each of these handoffs includes overhead in the form of meetings, documents to review and approve, waiting time, etc. Anything which does not directly contribute to the goal of the project: creating software – is waste.

Let’s reconsider.

Once upon a time, there was a marketing guy, with a great idea for a new software application.

A team was gathered with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team together made this set of skills, not an individual for each required expertise. Together with the marketing guy, the team formulated the business goal and desired business outcome of the new application.

The team focused on the outcomes that would address the main customer need of our application. In a lightweight manner, the idea was conceptualized: the team formulated some hypotheses: valuable features that they considered as a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next the team draw some UI sketches on paper. The team set out a test by linking together the UI sketches to an “interactive” prototype for internal validation. Taking into account the received feedback, the team refined that small set of features to the level of user story with the main acceptance criteria.

The team decided to prototype directly in HTML/CSS as this was the preference by the web developers. The team organized a user test with some of the key customers and external (non-customer) people. From these tests and the earlier defined metrics, they concluded and prioritized a number of improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed upon decisions), the prototype was improved and a next set of functionality was discussed.

Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with real back-end data.

Over the course of time, the team improved the product with feedback of customers, they included new insights, they dropped a few – previously considered “must-have” – features, and they integrated a new online service that appeared to be a good fit to the solution.

So, what do we observe?

The focus is on creating working software, that’s what we care for!

Documents do no solve user’s problems, working software does.

The focus are the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs and in that problem space possible solutions (hypothesises) to address those user needs are presented and challenged.

Feature development is prioritized. There’s no all-inclusive upfront analysis, there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges or rather there’s a sufficient design up front.

We eat the elephant in small chunks, but we prioritize the chunks.

The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.

Instead of an open-loop system, the project is organized as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.

Lean UX

What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are documented and are self-explanatory in terms of logic.

Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery in an iterative and incremental way.

Yes, there are exciting times ahead!

More info on Lean UX? Read the book by Jeff Gothelf.