Why is working harder such a popular management strategy?

The short answer: Working harder gives a short-term performance boost, but leads to a long-term decline in capability.

Organizations that commit to working smarter pay a short-term dip in output, but in the long-term enter into a virtuous cycle: improvement reduces effort for the same results, which is re-invested in further improvement.

Unfortunately, the opposite, vicious cycle is far more common. A decision to cut costs leads to working harder, which leads to a short-term performance boost with an unseen (delayed) trade-off. The decision-maker thinks "I got it right", feels vindicated, and applies linear thinking: more of the same should lead to further gains. This is wrong, but the bad effects -- losses in quality, capability, etc. --  are not be felt for some time. Meanwhile, committing to work "harder, not smarter" crowds out learning and process improvement.

Reference: Repenning and Sternan, Nobody ever gets credit for fixing problems that never happened [pdf]

Learn or Lose: Agile Coaching and Organizational Survival

by Daniel Prager

The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn. 

― Alvin Toffler 

Introduction

Overview: Change and evolve, or wither and die

For organizations to survive and thrive in the Information Age they must become truly adaptive. This will require a huge cultural transition away from the mechanistic, hierarchical, command-and-control approaches that were highly successful through the recent Industrial Age, but have now expired.

What is needed for survival is a transformation into true Learning Organizations. The essential cultural change is from a rigid focus on performance and risk-avoidance around a fixed (or infrequently changing) business model, to one that embraces continual learning, experiments, and small, typically reversible, changes.

Agile and Lean methods talk about learning and change, but I want to emphasize these facets as the central factor to cultural change. Without embracing ongoing learning and change, one may well upgrade one’s old approaches by cherry-picking elements of the new “Agile” way, but this is likely to only be a short-lived improvement. It is not enough.
 ...

Read the rest of my article on InfoQ

Adding triangles to YouPatch

The Racket Logo

Following my talk at RacketCon 2014 a few participants expressed interest in getting a quilt based on the Racket programming language logo (right).

Since I used Racket extensively both in inventing and developing YouPatch (www.youpatch.com) I thought it would be a nice gesture to make a free quilt design available to members of the Racket community.

However, just running the Racket logo through the YouPatch process (as it stood) made for an unsatisfactory result on two fronts:

1. The curves of the original design are excessively pixelated

   

   Original design: 230 pieces

   at a low resolution (right).
2. YouPatch's aggregation algorithm combines neighboring squares of the same color into larger pieces to reduce the amount of cutting and sewing— a key feature. Unfortunately it did badly in a few cases (especially so on simple logos like this) because it was based on the somewhat simplistic idea of chopping each block repeatedly into quarters. By looking at the original design you can probably see several places where neighboring pieces should have been combined.

So I improved the aggregating algorithm, achieving typically a reduction of 20% in the total number of pieces. [There's a trade-off here against the number of distinct shapes involved. I could get 30%, but we decided to restrict shape dimensions to reduce confusion during construction.]

Improved aggregation: 191 pieces

And I added an option to take a pixelated design and automatically and selectively add half-square triangles to reduce the "stair-casing" effect.

With half-square triangles: 279 pieces

Without the schematics, here's the triangle design in all it's glory:

The Racket Logo as a pixel quilt design with triangles

Racketeers, if you'd like this design free-of-charge, let me know and I'll generate and send you the pdf with all the instructions. You'll still need to buy the fabric and find a friendly quilter. [Try your local modern quilt guild if you don't know one.] 

Let me know what size you'd like: 

1. Small wall hanging: 32" x 32"
2. Medium wall hanging: 48" x 48"
3. Double bed or lap quilt for the couch: 64" x 64"
4. Queen bed: 80" x 80"

Now, in case you prefer another programming language to Racket, here's a sample of what happens to the logos of some other awesome languages that also have a liking for the greek letter lambda (λ):

Top-to-bottom:   1. original image    2. YouPatch squares   3. YouPatch triangles

At the time of writing the triangle-generating technology has not been built into YouPatch's self-serve features, nor have we finalized pricing.

I think you can see that this facility makes a big difference to logo-style pixelation (simple design, few colors, low-ish resolution), and of course it can be used for non-programming language logos! ;-)

It also can produce interesting arty effects on photographs. Here's the first pixel quilt featuring half-square triangles that we've actually made, featuring my daughter blowing bubbles:

1. Original image  2. YouPatch schematic  3. Actual quilt

The Racket logo is available for free, and we'll be making a triangle option available in 2015 as part of YouPatch, but the technology exists to do it now, so get in touch if you're keen!

My talk at RacketCon 2014

In September 2014 I was invited to speak at RacketCon, which was co-located with the larger and also excellent Strange Loop conference, both held in St Louis.

Here's my talk (and slides), which was well-received by a very nice and supportive audience:



In it I talk (for a bit over 30 minutes) about my overall philosophy, Lean Startup, Racket, and mainly about the YouPatch journey to date.

A Rosetta Stone of Agile Maturity Models

The Rosetta Stone

Please note: I have massively expanded on this post in an article appearing in InfoQ:

Learn or Lose: Agile Coaching and Organizational Survival

Go there for my deeper, more considered treatment.

* * *

Here's my attempt to line up a range of models, most not explicitly or exclusively agile:

Model	Stage 1	Stage 2	Stage 3	Stage 4
Folk classification	Cowboy	Waterfall	Agile (or Lean)	-
Shu Ha Ri	-	Shu (learn) Doing Agile	Ha (internalise) Being Agile	Ri (transcend)
4 stages of competence	Unconscious incompetence	Conscious incompetence	Conscious competence	Unconscious competence
Marshall model	Ad hoc	Analytic	Synergistic	Chaordic
Agile Fluency	Non-fluent	One star (focus on value)	Two / Three star (deliver / optimize value)	Four star (Optimize for systems)
Hofstede culture clusters	Contest	Pyramid	Network	-
Spiral dynamics	Orange	Blue, Orange	Green, Yellow	Turquoise

Disclaimers

1. In some Agile quarters "maturity model" is a bit of a dirty expression, in-so-far as it can be taken to imply a strict linear development, oblivious to context, so hopefully there will be some good debate!
2. I don't claim that the models line up perfectly. Each has its strengths, so I'm using it to point towards useful parallels and prompt further discussion.
3. Shu Ha Ri and Four stages of competence are usually taken to apply at a personal level, while the others apply at larger scales: to teams, organisations, and/or societies. I include both because I see the personal and cultural shifts as intertwined.

Commentary

It's early days in the paradigm-shift sweeping knowledge work and its coordination. Leading up to and following the signing of the Agile Manifesto in 2001 the early adoption of the Agile was all bottom-up, and came from software development groups.

Today we are seeing lots of top-down action, as well as the dissemination of Agile [and Lean] concepts and techniques well beyond software [and manufacturing] into most areas of knowledge-work. Executives are sponsoring Agile (and Lean) "implementations" in an attempt to cope with the challenges of an era of accelerating change and unrelenting competition.

But the shifts in mindset and culture needed to thrive in the "new normal" are vast. This applies to do-ers, to middle-managers, and to executives. [Those who think they can require change in their subordinates without going on the journey too, may well find themselves obsolete.] In my experience many welcome the change to a more humane and effective way of working, some adapt with a bit of effort, others misconstrue, bastardise and partly "get it", and a significant number are unwilling or unable to make the shift, at least on the first attempt.

When I first came across Agile methodologies in 2004 they were regarded as the province of elite, small-scale software development teams. I thought that there was no way large organizations would buy into the implicit challenge to command-and-control, and I had yet to realise that Agile ideas have so much to offer all areas of knowledge-work, not just programming, start-ups, and IT. By 2010, I saw that the shift was well under-way: the need for change now outweighed the blockers, but paradigm-shifts don't happen easily ... or overnight!

Today, as an Agile Coach, I find myself in the business of culture change, and I've gone hunting for models to quickly assess organisational culture in order to make clear, achievable recommendations for Agile intervention, implementation, transformation, or rescue. The aim is to make Agile coaching interventions faster and more effective.

After chatting with Matthew Hodgson of Zen Ex Machina about his brilliant application of Hofstede's culture clusters to diagnose organisational culture I wondered whether I could better target my own coaching efforts.

When I discussed applying the Hofstede/dgson with my then colleagues, a counter-proposal arose: what about Bob Marshall's model? This carried the day, and yielded helpful insights.

Some applications

The different mindsets that underly the different stages can give rise to interesting (and somewhat amusing) perceptual differences.

1. While recruiting in a fairly established corporate Agile environment (in which teams were operating reliably in late stage 2,  early stage 3) I would typically get one of two responses from job candidates who lacked previous Agile:

1. People from Stage 1 (ad hoc) backgrounds such as digital agencies would take one look and comment on the "incredible bureaucracy" of our practices. How did we ever get anything done!?
2. Those accustomed to stage 2 (waterfall variant) such as long-time bank employees would, by contrast, perceive our operation as a risky cowboy shop operating at break-neck pace!

In both cases it was necessary to gauge whether the individual would likely be able to make the transition. Generally, if they were attracted to our approach, for example if they felt that it addressed shortcomings in their previous work environments that they had found frustrating, there was potential.

2. As a coach, it's a very different proposition to work with an "ad hoc" group, typically confronted with organisational growing pains, compared to a more established organisation trying to transition out of command-and-control / traditional project management,  e.g. in order to become more responsive and/or creative.

In the first instance one needs to lead the client on a journey into discipline -- shu / doing agile -- before ha / becoming truly agile.

In the latter case, there is the tricky task of helping people unlearn the false lessons of command-and-control ("unplugging them from the Borg" in the evocative phrasing of the wonderful Stephanie BySouth) before nurturing the new mindset.

Which model is best?

Just as I love both my children equally, and I don't want to choose between different Agile methodologies -- but I *will* recommend one over the others in a given context -- I'm not picking winners here.  I wouldn't have included a model if I didn't think that it added substantively to the mix. However,  I will put in a vote for Bob Marshall's model as a good default starting place.

What do you think?

A compassionate reading of the Agile Manifesto

The four points of the Agile Manifesto read

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation 
• Customer collaboration over contract negotiation 
• Responding to change over following a plan

which Agilists are at pains to point out does not mean: "no process, tools, contracts or plans", but -- as the manifesto goes on to say -- "while there is value in the items on the right, we value the items on the left more".

Now Olaf Lewitz has written a wonderful articulation of why the items on the left are more highly valued than those on the right:

Now, when I read the four statements from a compassionate point of view, having worked with hundreds of organisations where people cling to documentation, plans, contracts, processes and roles, I have a more holistic perspective.  

All of the things on the right are commonly used for three purposes:  

1. To hide lies, to avoid trust, 
2. To cover somebody’s ass (make sure it’s not my fault), and 
3. To defer acknowledgement of uncertainty. 

 The basic emotion behind all of these strategies is fear.

In other words: the items on the right give protect against negative outcomes and the related fears, while those on the left emphasise freedom and fruitfulness.

Depending on the situation one may need to play some defence, but the ideal is to move forward positively.

Scrum Master characteristics: From Good to Great

A fantastic blog post from Geoff Watts (inspectandadapt.com) enumerated desirable characteristics of good Scrum Masters, and how to take them to the next level in Towards a Definition of a Great Scrum Master. He used elements of the list in his book: Scrum Mastery: From Good to Great Servant-Leadership.

I've added categories and reformatted the original list for reference and readability:

Accountability
A good Scrum Master will hold team members to account if needed.
A great Scrum Master will hold the team to account for not holding team-mates to account.

Communication
A good Scrum Master encourages people to talk to each other.
A great Scrum Master encourages people to listen to each other.

A good Scrum Master says what needs to be said.

A great Scrum Master knows the power of silence.

Growth

A good Scrum Master helps every member of the team grow. 

A great Scrum Master encourages growth as a team. 

A good Scrum Master notices areas for improvement in the team. 

A great Scrum Master recognises & highlights strengths of the team for them to build on.

A good Scrum Master will coach the team to succeed. 

A great Scrum Master allows failure & encourages the team to learn from their mistakes (from Christina Ohanian).

A great Scrum Master is chosen by the team and Product Owner. 

When she's done all she can, it's time for another great Scrum Master (from Mike James).

Servant-Leadership

A good Scrum Master serves the team. 

A great Scrum Master fosters servant-leadership throughout the team. 

A good Scrum Master  is wary of influencing the team with what they say & do. 

A great Scrum Master can act normally and the team still make their own decisions.

A good Scrum Master will be indispensable to a team. 

A great Scrum Master will make themselves dispensable. And wanted.

A good Scrum Master asks to understand so they can serve. 

A great Scrum Master asks so the team understands and can serve itself.

Teamwork

A good Scrum Master helps teams use "yes, but" effectively. 

A great Scrum Master helps teams find more space for "yes, and".

A good Scrum Master facilitates co-operation between people. 

A great Scrum Master facilitates collaboration.

A good Scrum Master listens to what is said in the daily scrum. 

A great Scrum Master listens to what is not said in the daily scrum.

A good Scrum Master will help maintain team harmony. 

A great Scrum Master will guide a team through disharmony to reach a new level of teamwork.

Inspect and Adapt

A good Scrum Master helps a team meet their definition of done at the end of a sprint. 

A great Scrum Master helps a team extend their definition of done.

A good Scrum Master will help teams optimise their process. 

A great Scrum Master will help the team get past process.

A good Scrum Master helps the team hold a balanced retrospective. 

A great Scrum Master helps the team hold a focused retrospective.

Working with the Product Owner

A good Scrum Master facilitates the Sprint Review so the team gets to demo to the Product Owner . 

A great Scrum Master ensures that the PO is already aware so the demo can be for other stakeholders.

A good Scrum Master will be a bridge between the Product Owner and the team. 

A great Scrum Master will reduce the need for a bridge.

A good Scrum Master helps write stories so that the team is ready for sprint planning. 

A great Scrum Master helps the Product Owner make time before and during the Sprint to write and talk to the team.

Relationship to the larger organization

A good Scrum Master protects the team from distraction. 

A great Scrum Master finds the root cause of those distractions and eliminates them.

A good Scrum Master helps a Scrum team survive in an organisation's culture. 

A great Scrum Master helps change the culture so Scrum teams can thrive.