Skip to main content

The Agile Late Majority has different needs

Are we applying a great solutions to a poorly understood problem?   What is the question - we know the answer is 42.

The early adopters of Scrum were seeking a method of controlling the chaos of emergent product development processes.  They needed empirical methods to discern if the product was moving in a meaningful direction.  They were willing to risk accepting technical debt to validate working solutions in the hands of real customers.  They were focused on delivering value, they wanted a process that optimized on value delivery and embraced the learning process required to explore new product domains.  They were organizations capable of thriving on the edge of chaos.  Organizations in the early adopters phase seek to keep options open (decide at the last responsible moment), to pivot  upon learning about the opening market space, to fulfill an undefined emergent need.

"Intelligence should be viewed as a physical process that tries to maximize future freedom of action and avoid constraints in its own future." -- Alex Wissner-Gross

Tardigrade - an extremophile
These organizations are perhaps a small subset of all corporations - perhaps these are extreme examples - but they exist.

But extremophiles do not live in the calm waters of the Caribbean reef.

"Most executives I’m meeting with nowadays aren’t fundamentally trying to solve the adaptability problem." 
-- Mike Cottmeyer - Are we Solving the right problem? 

The Agile movement has reached the late majority of the diffusion of innovation curve.

The Late Majority:  "Individuals in this category will adopt an innovation after the average member of the society. These individuals approach an innovation with a high degree of skepticism and after the majority of society has adopted the innovation. Late Majority are typically skeptical about an innovation, have below average social status, very little financial liquidity, in contact with others in late majority and early majority, very little opinion leadership." -- Everett Rogers

My opinion is that this group is seeking a different answer than the early adopters or early majority.  Studying Rogers' diffusion curve and synthesizing some other really observant human behavioral ideas; I think it's very obvious that the late majority have a very different answer to the fundamental questions around why they are adopting Scrum.  I've asked this question for years in workshops.  The answer's haven't changed.  But the meaning behind the answers must be different than they were before.

Is it the value system of Agile that draws these companies into the Scrum trainers classroom?  No.  Is it the promise of the more collaborative and humane software development lifecycle for the employees?  No, many of these companies have already shed their employees by adopting the staff augmentation model of the 20th C. consultant/contractor model.

The answer this group of late majority scrum adopters are seeking is: a lowering of the cost of development and maintenance of software systems that run and maintain the business.  Very few projects that these organizations attempt are in the domain of seeking an innovative or emergent solution.  Sure they speak the current lingo of innovations but few are seeking disruptive innovation (what must of us think when the "I" word is mentioned), most are seeking frugal innovation (15 Types of innovation).

"Frugal Innovation is about doing more with less. Entrepreneurs and innovators in emerging markets have to devise low cost strategies to either tap or circumvent institutional complexities and resource limitations to innovate, develop and deliver products and services to low income users with little purchasing power."

This group is not seeking to open up the future options that an emergent process may afford them.

See Mike Cottmeyer's blog series What Problems Are Executives Trying To Solve With Agile?  It is a very good list - if you need an answer, pick one from his list - it's sure to impress.

Start with WHY - Simon Sinek
Perhaps we should start our agile transition with a serious question - Why?

I've asked this question, but just getting a few mid-level managers and the executive level sponsor answering this question may not be enough.  Is there a method of hearing the organization - rather than the designated spokesperson for the organization?  Enter Open Space Technology.  Why yes, yes I believe this may provide a collaborative way to answer the question without the filter imposed by a leadership visor.  Inside of the Agile movement it may best be expressed by Open Agile Adoption techniques.

Is Agile a solution for this cost reduction and predictable deliver of replacement solution domain of the late adoption mindset?  I believe they can see benefits of adopting the basic foundations of Scrum.  Of adapting the underlying Extreme Programming techniques that power the Scrum framework.  Yet the agility of the processes might be antithetical to the organizations purpose of delivering software.

A case in point:  a client in the data management of health care actually has the policy of allowing their clients to pick and choose (ala-carte) the software development process aspects that they are willing to pay for.  For example - the client may not wish to pay for the QA on a project, so the development group conceives that it is their role to deliver a software product without doing the QA.  Or perhaps the client doesn't want to pay for the project management aspect, or the architectural analysis of the solution.  Now this is an extreme situation - true.  One that none of us would like to be in - but can this organization adopt the Agile mind-set?  When the various directors and VPs of this organization say they want to do the Scrum/Agile thing - do they mean what I think they mean - or are we talking about very different purposes?

Alex Wissner-Gross - A new equation of intelligence - TED Talk

Agile Scout's SAFe Review

Agile Has Not Crossed the Chasm, a contrarian view by Johanna Rothman 2012 and still relevant:
Bounce Back is too CommonHere’s the problem I see. We’ve seen several consultants and consulting organizations take the credit for the same large media organization succeed with their agile transition. Well, this same organization is on their fourth or fifth agile transition by now. They have the common problems of any significant process change: it’s difficult, culturally challenging, and the entropy of the organization is working against them. It’s easier to bounce back to chaos or waterfall

HBR article:  Embracing Agile  2016
by  Darrell K. RigbyJeff SutherlandHirotaka Takeuchi
Agile innovation methods have revolutionized information technology. Over the past 25 to 30 years they have greatly increased success rates in software development, improved quality and speed to market, and boosted the motivation and productivity of IT teams.

David vs. Goliath no more, Agile adoption is the new standard. by Joseph Flahiff - July, 2017
As Agile adoption grows, companies should not be looking to specialists to support agility, says Joseph Flahiff. Make Agile coaching a standard job requirement for team managers.
Post a Comment

Most Popular on Agile Complexification Inverter

Elements of an Effective Scrum Task Board

What are the individual elements that make a Scrum task board effective for the team and the leadership of the team?  There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams.

In general I'm referring to a physical Scrum board.  Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated.  And software applications offer features not easily implemented in the physical domain also.

Scrum Info Radiator Checklist (PDF) Basic Elements
Board Framework - columns and rows laid out in bold colors (blue tape works well)
Attributes:  space for the total number of stickies that will need to belong in each cell of the matrix;  lines that are not easy eroded, but are also easy to replace;  see Orientation.

Columns (or Rows) - labeled
    To Do
    Work In P…

Exercise:: Definition of Ready & Done

Assuming you are on a Scrum/Agile software development team, then one of the first 'working agreements' you have created with your team is a 'Definition of Done' - right?

Oh - you don't have a definition of what aspects a user story that is done will exhibit. Well then, you need to create a list of attributes of a done story. One way to do this would be to Google 'definition of done' ... here let me do that for you: Then you could just use someone else's definition - there DONE!

But that would be cheating -- right? It is not the artifact - the list of done criteria, that is important for your team - it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement. If some of the team believes that a story being done means that there can be no bugs found in the code - but some believe that there can be some minor issues - well, …

What belongs on the Task Board?

I wonder about these questions a lot - what types of task belong on the task board?  Does every task have to belong to a Story?  Are some tasks just too small?  Are some tasks too obvious?  Obviously some task are too larger, but when should it be decomposed?  How will we know a task is too large?

I answer these questions with a question.  What about a task board motivates us to get work done?  The answer is: T.A.S.K.S. to DONE!

Inherent in the acronym TASKS is the point of all tasks, to get to done.  That is the measure of if the task is the right size.  Does it motivate us to get the work done?  (see notes on Dan Pink's book: Drive - The surprising Truth about what motivates us) If we are forgetting to do some class of task then putting it on the board will help us remember.  If we think some small task is being done by someone else, then putting it on the board will validate that someone else is actually doing it.  If a task is obvious, then putting it on the board will take vi…

David's notes on "Drive"

- "The Surprising Truth about what Motivates Us" by Dan Pink.

Amazon book order
What I notice first and really like is the subtle implication in the shadow of the "i" in Drive is a person taking one step in a running motion.  This brings to mind the old saying - "there is no I in TEAM".  There is however a ME in TEAM, and there is an I in DRIVE.  And when one talks about motivating a team or an individual - it all starts with - what's in it for me.


Pink starts with an early experiment with monkeys on problem solving.  Seems the monkeys were much better problem solver's than the scientist thought they should be.  This 1949 experiment is explained as the early understanding of motivation.  At the time there were two main drivers of motivation:  biological & external influences.  Harry F. Harlow defines the third drive in a novel theory:  "The performance of the task provided intrinsic reward" (p 3).  This is Dan Pink's M…

A T-Shaped 21st Century Knowledge Worker

Knowledge workers in the 21st Century must have many areas of deep knowledge, while also be capable of collaboration across multiple other domains with dissimilar T-shaped individuals.  This description of a person is a metaphor.  Compare it to the shape of the "I" in the classic saying there is no "I" in Team.

I first read about Scott Ambler's term "Generalizing Specialist" - but it's so hard to remember the proper order of the words... get it backwards and it has an inverted meaning... T-Shaped is easier to remember. 
A generalizing specialist is someone who:
Has one or more technical specialties (e.g. Java programming, Project Management, Database Administration, ...). Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.  General…