Skip to main content

Empower - an action; not a command

You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering.

"When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency."
How does this misinterpretation occur?  Why do we humans mess up this simple act of communication?

Let's look at an example:

For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenured people to grow it's new "resource" of technical people.  This time the leadership decided that hiring some experienced people that had "done Agile" and "knew how to Scrum" might give them the needed energy to actually get somewhere with the initiative.  At least these experts could teach the new people how to do agile right.  I guess I was one of these "experts" (another term for a has-been drip under pressure).

Observing the new team for a few weeks I noticed they referred to their process by the label "kanban," yet they never appeared to move any sticky notes on their board, never made new ones or retired any old stickies.  Mostly they just pointed at them and talked about something not written on the note.  It was very difficult for the outsider (me) to follow the process they were using -- or maybe they were not using any process; and I was following them -- to nowhere.  This will take a bit more observation.

Although that was several months ago, and my memory is not the best at recovering details when there is no emotion overlaying the details, believe me there was little emotion at their stand up meetings, I'd call them boring (the meetings, not the people).  I don't remember in the 4 weeks I was observing that they ever shipped any software, never spoke about a customer visit, or discussing a solution with a customer - I don't think anything they talked about ever got done.

So, I some how convinced their manager that what they were calling a process, could not be named - and that wasn't a good thing (sorry Alexander that attribute is not the same as your "quality without a name" ).  It didn't reflect any known process.  He didn't know much about the process either.  It was labeled "kanban." Yet they didn't exhibit any of the behaviors of a team practicing the Kanban process, they didn't even know what steps the process might involve.  They had also tried scrum, but "it didn't work" either.  It was very difficult to discuss these failures with the team or the manager, they were reluctant to discuss what about the process had failed, nor what actions they implemented when these failures occurred.

I made a bold assumption - they didn't know anything about the processes they were espousing they were using.  They had been to training classes, therefore they knew ... something.  They could use the new lexicon in a sentence (90% of the time the sentences made sense).  But how do you tell someone they are ignorant (with the full meaning - that they no nothing about a subject and it's not their fault for having never been exposed properly to the knowledge).  That's a crucial conversation.  I rarely handle these well - I got lucky this time perhaps.  I suggested the team join me in a workshop to talk about the practices they are using and how these map to the Agile Manifesto.  We did this exercise and branched off into many valuable conversations.  During this exercise we decided they were already being Agile, so many of their practices supported the principles of the manifesto.  So the question was not if they were Agile, but how much was enough... could they improve their agility - did they want to try something different?  Along the way of this conversation we might have arrived at an understanding of a difference of opinion, when I used words in the lexicon I had intended to imply certain meanings that they did not intend when they used the words.  We often seemed to use similar phrases but rarely meant the same things actually happened.  That level of miscommunication can be tedious to overcome, while still keeping an open mind that the other person has something valuable to offer.

For example: they had been using the word "kanban" to describe the process they were using because that was the term applied to the Rational Team Concert (RTC) - template work flow the company created.  They had chosen that workflow because it was easier to use than the complicated scrum workflow the organization's PMO created.  Turns out it had nothing to do with the development process they were using.  They finally agreed that they were not doing Scrum, and didn't really know how to do it... they hadn't learned much from the powerpoint presentation (imagine that).

I got extremely lucky with one of the leaders of this team. She said to the team, that she thought the
team should give the scrum master (me) a chance, just go along with whatever I said, regardless of how stupid it sounded. Try it for a few weeks, it wouldn't hurt, and then in a few weeks decide if it was working for the team, or not.  I learned of this leader's suggestion to her teammates only months later.  It was without a doubt the turning point in the relationship.  After this d├ętente, the team members began to implement with ease suggestions on how they could implement Scrum.  One might say that this leader empowered me, but never said a word about it to me.

We did more workshops in a scrumy fashion, we had a board of items to complete.  We tracked these items on a board right there in the workshop space.  Sometimes we split the topics up more.

Sometimes the topic didn't get finished in the time allotted and we had to decide if it was good enough to continue with other topics and come back later to finish the discovered aspects.  We used the rate at which we were progressing day after day to predict that we wouldn't get all of the topics covered by the end of the week.  But that was good enough, because each day the team selected the most important, most valuable topics and we put off the lease valuable.  Sometimes a topic was dependent upon another item on the board and we had to cover some of a less valuable item so that the dependency was resolved.  In these workshops we covered many Agile principles, the Scrum process framework (3 roles, 3 meetings, 3 artifacts, and a lot more), engineering  practices (many originally defined by Extreme Programming gurus), local organization customs, terms, policies, and procedures.  Much of what was suggested by some agile or scrum nutjob was in contradiction with the customs and policies of the organization - at least on the surface.  Great conversations were developed where the team joined into filling the shared pool of knowledge.  This pool of knowledge now with company and agile/scrum knowledge was easily sorted into new understanding of how both systems could co-exist and interrelate.  It wasn't easy but it generally worked.

The team started understanding the process of Scrum and working toward getting stories in the backlog to done.  Slicing stories that had proven too large in the past and delivering working software to the business each sprint.  They developed the ability to easily estimate a story or an epic set of stories within minutes.  Their ability to read their task board and predict which stories (if any) were not going to get completed within their sprint time-box that they quit wasting time tracking a sprint task burndown.  They understood that if they got into a new domain that ability might be diminished and they could easily revert to tracking task aspirin (a unit of effort; not time) on a chart in the future. The team knew their velocity and could accomplish a sprint planning session in about an hour.  They could predict when they needed to spend more time in refining tough stories before planning and they learned how to slice stories for value and leave the fluff on the cutting room floor.

But all was not well with a performing team...  (cue the scary music - set up a scene with dramatic lighting) ... the manager was looking for a way to measure the team.  And as people are wonting to do... without any thought they look for a dashboard to tell them how well the "team is being run."  They want to know if the "team is being driven at their top performance", and they need some numbers to prove it.  Generally this is a warning indication that many conversations were wasted and no learning occurred,  in hindsight the wrong person was doing too much of the talking and the other didn't draw from the pool of shared knowledge but instead just admired the pool from the shore, never bothering to enter.  The team's manager wanted me to build a dashboard tool using the company's tool of record (RTC) that would give him all the numbers that prove his team is performing well.

I've made a strategic decision over the years to not become the tooling expert - especially with the bountiful assortment of tools the software project management industry offers.  Needless to say I didn't want to become an expert in RTC (a tool rumored to be on it's way out for this organization that was in their 3rd Agile adoptions curve).  I asked what this dashboard would have on it, what it would display, etc.?  The answer fit on a sticky note, because that's what I had with me... something like velocity, the backlog, and what the team is currently working on was the manager's response.

Here's my Nth mistake.... I hoped the request would dissipate as many thing in a transition tend to do, so I wasn't motivated to create a dashboard for the manager that would reproduce the team's well maintained Scrum task board.  I offered to work with him in reading the board, he attended many of the team's Scrum sessions at the board, rarely engaged but appeared attentive.

[this story will continue ...  as I've lost my round-toit --  wonder if it's with my marbles?]

See Also:
Why we cannot learn a damn thing from Toyota or Semco by 
Post a Comment

Most Popular on Agile Complexification Inverter

Innovation in the Automobile Industry

In the 1900s the automobile industry was the most important and innovation industry in the USA.  But one could question if this was good for our society in the long run.  And one could question if they actually innovated.

In the early 1900s there were few automobiles, very little infrastructure created to support the industry.  For example the road system was still designed for horse drawn wagons and the wagon wheel (remember a steal rim and wooden compression spoke wheel).  The future US Highways, or the 1950s Interstate Highway System at the cost of $425 billion were decades and many innovations away. There was no gas service station, there were however horse stables, farriers, and blacksmiths in each town along the roads.  There was no real "road map", there was no road naming system, like was created in 1926 - the United States Numbered Highway System.

The industry employees millions of people, and was a large factor in the economy of the USA.  It created or was created b…

Software Development terms applied to Home Construction

Let's Invert the typically wrong headed view of Software Development project management as a construction project.  We can map it the other way just to see if it works... to have some fun, to explore the meaning of phrases we toss around quite frequently.

Normally Project Management terms come from a construction domain.  We are going to apply the lexicon of modern software to the construction of a home.  We will follow the construction project and meet some of the people doing the work.

This is a very small (8 homes from $600,000 skyward) program in my 30-40 year old neighborhood.

About 6 months ago I saw the programs landing page go up.  It gives casual observers and some of the stakeholders a general idea of the intent of the program.  And most importantly who to contact for additional information if you happen to be interested in their products.

The Refuge program has 8 product projects and has them running independently.  Yet much of their DevOps infrastructure has already b…

Timeline of Social Networks -or- the Long Haul

I was listening to KERA's Think and they mentioned the concept of social networks.  It got me think...

But the book Long Haul, is its own interesting story - A Million Miles and Counting - A Trucker's Tale.

“The Long Haul: A Trucker’s Tales of Life on the Road”
Did you know 41 million people move in the US a year?  Having moved a few times in my life, sometime with the Bed-Bugger's help, this book is a great insight into that life.
Author: Finn Murphy's CB handle - "U-Turn" The radio interview noted the concept of social networks in the 21st century.  What is a highway - but a manifestation of a social network - a trail across the land.

a timeline using the Knight Lab Timeline JS tool kit.

See Also:

Social Media - Tracking its Exponential Growth video
Social media has overtaken porn as the #1 activity on the Web
List of social networking websites - Wikipedia

The World's 21 Most Important Social Media Sites and Apps in 2015

The Growth of Social Media - infog…

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…

One Dark and Stormy during a Hurricane

I'm from the Carolina's where legend has it that our family commonly just hunkered down in the home on the coast and waterways than to head for inland shelter. Now that's from the old school days of barely improved (read paved) roads. They counted a storms severity by how high on the back porch steps (about 15 - top to ground) the water reached.  I don't recommend this action in todays world of long range forecast and transportation options.

I do recommend a drink or two in a hotel bar, far far away.

This is the week that Harvey came ashore in Texas.  I live on a hill in the little old town of Grapevine outside Dallas and Fort Worth.  And thank you all for letting me know that a storm is coming... I didn't get out and walk Malibu before the rain hit, so I grabbed a hat and we went anyway.  Much nicer walk with the drizzle, I'd say.

I'll raise a glass to you - if you were not smart enough to do the responsible thing, at the last responsible moment.

I do re…