Thursday, March 27, 2014

Exercise:: What motivates your team members?


 Top Career Motivators
Visual.ly Infographic
Understanding why an organization thinks it needs to change is enlightening.  Many times the people at the bottom ranks of the organization have no idea the driving forces that necessitate a change.   As a group brainstorm a list of possible reasons for the change.


Dialogue on the difference between change and transition.  How long does change take?  What is a transition?   Bridges Transition Model:  Ending - Neutral Zone - New Beginning.

Dialogue on the difference between satisfiers and dissatisfaction in the workplace (Herzberg's Two-Factor theory).

See Gallup's Q12 Employee Engagement survey.


First just capture all the reasons that might be the answer to - Why change?

Typical reasons (if you need to prime the pump - or when the answers slow down - throw one of these out to head in a different direction).
  • Current process just doesn’t work
  • Decrease time to market for new products
  • Cost reductions, improve effeciencies
  • Scrum is the methodology of the decade (soup de-jour)
  • We’ve tried all the others - maybe this one will catch on
  • The boss said so
  • Our competator is doing it
  • Exponential change rate of market space requires ability to “pivot” into new market spaces with our existing products
  • We don’t really know what our customers desire until we deliver it
  • Outsourcing is hard so maybe this will fix it
  • Our quality is too low - so Scrum will fix it
Debrief the list, discuss one or two items that need elaboration.

Options:

  • Dot Vote - 3 dots each - which is the organization true motivation?
  • 5 Whys? - Identify one item and ask WHY until you have a root cause motivation.

See Also:



Intrinsic vs Extrinsic Motivation
Herzberg's Two Factor Theory
Interesting links on Motivation

First Break ALL the Rules.


List of Agile Team Exercises

A list of Agile team exercises

Video series on Scrum (short takes)
http://agilecomplexificationinverter.blogspot.com/2013/10/learn-scrum-video-series.html

A Release planning and Scrum simulation - Priates of the Carriballoonian
http://agilecomplexificationinverter.blogspot.com/2012/04/procuct-owner-scrum-immersion-workshop.html 

Project success sliders
http://agilecomplexificationinverter.blogspot.com/2013/12/project-success-sliders.html

Quikie video explains relative vs absolute measures
http://agilecomplexificationinverter.blogspot.com/2013/11/relative-points-explained.html  

Dog Grooming - agile estimation technique
http://agilecomplexificationinverter.blogspot.com/2010/11/dog-grooming-exercise.html

Elements of an effective scrum board - checklist
http://agilecomplexificationinverter.blogspot.com/2013/11/elements-of-effective-scrum-task-board.html

Pick the Metrics to use to evaluate your team
http://agilecomplexificationinverter.blogspot.com/2013/05/metrics-for-scrum-team.html

If your Agile and you know it - clap your hands. Prove it - show me the practices that support a claim of agility
http://agilecomplexificationinverter.blogspot.com/2011/10/what-are-principles.html
http://agilecomplexificationinverter.blogspot.com/2012/08/exercise-mapping-engineering-practices.html

Definition of Done & Ready
http://agilecomplexificationinverter.blogspot.com/2011/09/exercise-definition-of-done.html

Intro the concepts of TDD & Refactoring
http://agilecomplexificationinverter.blogspot.com/2013/12/intro-to-refactoring-with-legos.html

Create a set of well known plays for the team
http://agilecomplexificationinverter.blogspot.com/2013/04/whats-in-your-play-book.html

Experience the power of prototyping and evolutionary design - Marshmallow challenge & video
http://agilecomplexificationinverter.blogspot.com/2012/04/video-of-marshmallow-challenge-at-agile.html

Pair programming exercise
http://agilecomplexificationinverter.blogspot.com/2012/09/exercise-pair-chess-game.html

What Motivates your Employees
http://agilecomplexificationinverter.blogspot.com/2014/03/exercise-what-motivates-your-team.html

Wednesday, March 26, 2014

Book Review: 5 Elements of Effective Thinking

I've listened to the audio book several times on trips across country, and each time I've said that I needed to buy the book (paper version) so that I could study it better.  So I did, and this is an attempt to outline the books major points.

The book:  The 5 Elements of Effective Thinking  by Burger & Starbird.

In the audio format I found it hard to visualize the 5 elements, perhaps because of the analogy to the classic elements of earth, fire, air, and water.   So before any confusion sets in, here are the author's 5 elements:


  • Grounding Your Thinking; Understand Deeply  [Earth]
  • Igniting Insights through Mistakes; Fail to Succeed  [Fire]
  • Creating Questions out of Thin Air; Be your own Socrates  [Air]
  • Seeing the Flow of Ideas; Look Back, Look forward  [Water]
  • Engaging Change; Transform Yourself  [the Quintessential element]
"In any movie, play, or literary work, media scholars tell us how to determine who truly is the main character of the story -- it's the individual who, by the end, has changed the most."  -- Burger & Starbird

Each chapter is illustrated with wonderful stories.  An example:  JFK's 1961 speech to Congress in which he challenged the US:  "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth."  The result of this challenge was not to start putting people in rockets and sending them to the Moon.  It was much simpler steps that built upon previous learnings.  Their example is the Ranger program, in which NASA tried 6 times to just hit the Moon, and failed before succeeding in the seventh attempt to crash Ranger 7 into the moon.  Learning in each attempt, solving bigger more complex problems by iteration.


Friday, March 7, 2014

Agile Tetrahedron move above the PM Triangle for Value

Agile Tetrahedron - ver 1
Who can explain the classic Project Management Triangle?  I've found that everyone has heard of it and uses it fairly well in a sentence. But when it comes to actually explaining the analogy to the triangle the struggles begin.  Some call it the iron triangle - as if nothing can stretch or shrink it's features once set.  I created a plastic triangle that was adjustable to illustrate the nature of negotiation of each of the sides.


I want to move beyond the classic three variable problem of the project (scope, schedule & cost) and envision a model that describe the value that a project represents while maintaining the constraint relationship that these classic triangular relationships represent.  Enter the Tetrahedron - a platonic solid.  The tetrahedron has four faces, each face is a triangle, it is the simplest form of a pyramid with the base in the form of a triangle.

Highsmith's Agile Triangle
Jim Highsmith introduce the concept of treating the PM triangle of cost, schedule, and scope as constraints in his Agile Triangle by adding a fractal triangle at the vertex of his triangle of value, quality and constraints.  While other's had explained the iron triangle as having an aspect of quality on the inside that one obviously would never vary.  Well then if one is not varying quality while do we talk so much about technical debt?  Jim does a great job explaining that the traditional aspects are constraints and that the desire of a business is to derive out of these constraints something of significantly larger value than constraint space represents.

"Quality is a value to some person."  -- Jerry Winberg
Discussing this with my colleague Rick Stephenson we envisioned a more physical and tactile model.  A model that retained the constraints concept from Highsmith, but added the multiple aspects of value -- business, technical and customer value.  We desired to represent these three types of value as separate and independent aspects that must be attended to by the project team while staying within the constraints.  Yet it is the desire of the project's sponsors to raise the values as high as possible while minimizing the surface area of the constraint space.  When these desires are modeled in the tetrahedron with physical objects one can start to get a gut feeling for the tradeoffs that directors and managers must make in the project.  Build upon a small constraint base and the pyramid may become unstable.  Imagine the table upon which you are building your model to be the platform for your application - when the platform is shaky and unstable the application needs much more base surface area to attain a sufficient height (values).

In the model of the Agile Tetrahedron I made above I cut the business value face a bit and the technical value face even lower.  The idea was to show that those faces may not be completely required to deliver customer value within a given release (constraint).  Yet, one can see that extending that idea to an extreme may prove dangerous with a shaky platform.

Agile Tetrahedron model: print, cut, fold, play...
PDF of Agile Tetrahedron model ver 2.3 - print, cut, fold, play...

See Also:
How to make the classic PM Iron triangle  out of plastic drinking straws.
Beyond Scope, Schedule, and Cost: The Agile Triangle by Jim Highsmith


Thursday, March 6, 2014

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


Wednesday, March 5, 2014

Before Scaling Up - consider...

Before one scales up their functioning teams (I'm assuming one would not want to scale up non-functioning teams - yet I've seen that done) one should look for alternatives to the scaling problem.

This scaling problem has been studied.

"In 1957, British naval historian and management satirist Northcote Parkinson [known for Parkinson's law: “work expands to fill the time available for its completion”] painted a cynical picture of a typical committee: It starts with four or five members, quickly grows to nine or ten, and, once it balloons to 20 and beyond, meetings become an utter waste of time – and all the important work is done before and after meetings by four or five most influential members."

Scaling up Excellence

Why Big Teams Suck by Robert Sutton is a Stanford Professor and co-author (with Huggy Rao) of Scaling Up Excellence: Getting to More without Settling for Less.

Studied in Academia

"After devoting nearly 50 years to studying team performance, the late Harvard researcher J. Richard Hackman concluded that four to six members is the team best size for most tasks, that no work team should have more than 10 members, and that performance problems and interpersonal friction increase 'exponentially as team size increases'.”

Studied in the Military

"Some organizations learn about the drawbacks of oversized groups the hard way. Retired Marine Captain and former U.S. Senator James H. Webb explained why the “fire team” – the basic combat fighting unit – shrunk from 12 to 4 during War II. Webb wrote in the Marine Corp Gazette that this “12 man mob” was “immensely difficult” for Marine squad leaders to control under the stress and confusion of battle. Coordination problems were rampant and close relationships – where soldiers fight for their buddies – were tougher to maintain in 12-man teams."

Studied in Health Care

"A Harvard Business School study by Melissa Valentine and Amy Edmondson of a large hospital’s emergency department [...] The crowd of 30 or so doctors and nurses who staffed the department at any given time were divided into multiple six person “pods,” each led by a senior doctor or “attending physician.” After the change, information about patients flowed more quickly and accurately and personal relationships improved markedly. Smaller teams reduced confusion and discomfort about who to ask for help and updates."

I think the general lesson learned is to not scale up, because the systems and structures that created and support the current organization will not bare the stress of scaling up.



Some alternatives to Scaling Agile:

Scaling Agile – the Easy Way by Arlo Belshee

Try to re-structure the organization in a way that doesn't require efficiency of scale to achieve the goal. For example WL Gore's organizational pattern a team based flat lattice.

Or Semco, "a Brazilian conglomerate that specializes in complex technologies and services. Semco is a self-managed company. Workers at Semco choose what they do as well as where and when they do it. They even choose their own salaries. Subordinates review their supervisors and elect corporate leadership. They also initiate moves into new businesses and out of old ones. The company is run like a democracy." -- Podular organization: a business within the business written by Dave Gray.


Try a fundamentally radical idea like Holacracy.  "Holacracy is a real-world-tested social technology for agile and purposeful organization. It radically changes how an organization is structured, how decisions are made, and how power is distributed."

Take a lesson from the US Government's FBI Case Management system.

Before you consider the leading market agile/scrum scaling tool-sets like SAFe, DAD etc. try this alternative approach:  Open Agile Adoptions by Dan Mezick author of The Culture Game.

“Scaling is actually a problem of less,” says Sutton in The Do’s and Don’ts of Rapid Scaling for Startups. “There are lots of things that used to work that don’t work anymore, so you have to get rid of them. There are probably a bunch of things you’ve always done that slowed you down without you realizing it.”
See Also:
The Agile Late Majority has different needs
The Scaled Agile Framework (SAFe) – A Review by Agile Scout
SAFe - but not good enough  by Ron Jeffries
Scaling Scrum: SAFe, DAD, or LeSS? by Peter Stevens
Scaling Agile Development LeSS - PDF by Larman & Vodde
IBM's Disciplined Agile Delivery DAD by Scott Ambler
Scaled Agile Framework SAFE by Dean Leffingwell
A Scaled Agile Framework® (SAFe™) Case Study by Brad Swanson
Large Scale Scrum (LeSS) @ J.P. Morgan by Craig Larman and Matt Winn
Case Study of a Difficult Federal Government Scrum Project: FBI Sentinel by M. James




Tuesday, February 25, 2014

Examples of Visualizations



The Periodic Table of Visualization Methods (aside: why people abuse the notion of the Periodic table of elements is puzzling to me - it's not just a table with iconic status - it's a predictive model in action; ... meanwhile, back to the visualization methods...) awesome chart with wonderful pop-ups to explain all the visualization methods.



So let's just go right ahead and include the predictive model of Mendeleev's table.


Example of the Periodic Table style applied to Scrum by my friend and colleague KaTe.
by Kate Terlecka
Agile Fluency model by Larsen and Shore - a intro video by James Shore: Your Path through Agile Fluency.








When you're into visual info, books on work processes, wonder and humor... you need a crateful of grateful - bet ya can get it at www.getlit.me here's a sample of Todd's book review info graphics.
Succeeding with Agile Governance

Want to visualize what that conference call really looks like - watch this video.


from Tripp and Tyler


Visualize the 5 SOLID class design principles.


Visualize what an org. chart should look like (if it was to be a useful tool; rather than an ego booster):

Visual.ly presents an interactive graphic depicting various sorting algorithms.


Big O notation cheat sheet. "This webpage covers the space and time Big-O complexities of common algorithms used in Computer Science."


The Cockburn project classification scale is a wonderful visualization for viewing projects as a group of activities and then deciding what process might fit around that project well.  I was very impressed the first time a saw Alistair's work on this, and it has stood the test of time.

Brian Marick's testing quadrants -- from a presentation by Lisa Crispin & Janet Gregory (see their book Agile Testing).



Linux (unix) performance management tools and the OS architecture stack.