The lines between political science and organizational culture continue to blur. Those who venture into organizations need to become well versed in the dynamics of power. One such explanation of these dynamics is Steven Lukes’ the “Three Faces of Power”.

Three Faces of Power

1. Decision Making – The power to make and implement decisions

2. Non-Decision Making – The power to set agendas and therefore limit what is even being discussed

3. Shaping Desires – The power to manipulate what people think they want

Lukes’ work is an extension of Max Weber’s Three Types of Authority, in which Lukes argues that Weber only focused on the first face of power, Decision Making.

Others such as Kenneth Boulding have described these power dynamics as the carrot, the stick and the hug.

Regardless of the names used, by simply being informed about these types of power you can become more aware of your surroundings.

The Engineering Manager ordered the Developer to change his task estimate.

An order from a Manager to a Developer is the most public form of power and is an example of how the Manger wants to be perceived. This first face of power is rather easy to spot and diagnose.

This meeting lead by the Director of Engineering only had task estimation standards on the agenda.

A Director who is controlling the meeting agenda is a bit more subtle and requires a level of awareness to see. What is it that they hope to accomplish by limiting the agenda in such a fashion? Limiting the agenda is a technique used to prevent issues that could cause opposition. Do they address issues if they arise in the meeting or do they misdirect? The second face of power tends to leverage delay, inconclusive questions and bureaucracy to avoid the needs of the weaker team members. Sound familiar?

The CTO convinced his team that accurate task estimates are the key to hitting quarterly goals.

A CTO who has convinced his management team that his interests are in their best interests is far more difficult to identify and diagnose. It isn’t always obvious that the actions of the team are a result of coercion from their boss. They can convince people that their wants and needs are actually harmful to them. This third face of power is often aligned with ideological institutions.

These are just a few examples of the faces of power you may experience every day in a large organization.

I believe that being aware of these faces of power help me become oriented during an organizational transformation. Perhaps you’ll find value in them as well.

Ever walk into the kitchen of a technology company? Chances are you’ll find a mind boggling supply of candy, snacks, treats and a variety of caffeinated drinks. One could just pass this off as the bad eating habits of pale geeks who go home after work and live in their parent’s basements, but I’m beginning to believe something deeper is at work here.

New research leads me to believe that we may be collectively suffering from ego depletion.

Ego depletion is the idea that self-control or willpower is an exhaustible resource that can be used up. Interestingly enough, sugar (or glucose) intake helps us prolong our ability to make decision after decision throughout the day.

Initially it sounds far fetched, until you think about all of the decisions you make throughout a work day and how they correlate with your sugar intake.

Consider the number of decisions you had to make in order to get to work this morning. Now once you’ve sat down and booted up your machine, imagine how many decisions you make before you start to even code. After you’ve started coding (or writing your tests if practicing TDD) imagine how many decisions you continue make in the span of just 1 minute.

If you do the math you begin to realize that you make a staggering amount of decisions throughout the course of just one work day. Many of these decisions are under pressure with serious implications.

In addition to ego depletion, research has found that these decisions can be broken down into pre-decision and post-decision processes.

A prolonged period of pre-decision is not ideal for a team that thrives on quick feedback loops.

I believe we can use this new found research to help our teams be in situations where they can make the best decision possible.

Daily Standups - Urge teams to have the daily standup in the morning if possible. It is our daily plan and we need our team focused as we make decisions on what we are about to do.

Retrospectives - Bring candy or snacks into the retrospective. Team members are more likely to forget their manners when suffering from ego depletion. It isn’t just people, it even happens with man’s best friend too.

Iteration Demos - Schedule these early and bring muffins, donuts or pastries along with some form of juice. If the Product Owner is accepting the work, he or she needs to have the mental fuel to make the tough decisions.

Feedback Loops - How long does it take to compile and run tests locally? How long does it take to deploy a build to test or production? How long does it take to get an answer from the business on feature question? All of these affect pre-decision time spans and deplete willpower.

Some of these suggestions may sound like common sense, but I believe if we can align our techniques with these findings that the result will be a team that is in an environment where they can repeatedly make good decisions.

impediment – a hindrance or obstruction in doing something: “an impediment to progress”.

When you are an acting ScrumMaster or Agile Project Manager, it is common to seek out impediments so that you can help to remove them. Before you know it, impediments seem to be all around you ranging from the individual, team and organizational levels. A person can quickly feel consumed and overwhelmed by this new found responsibility.

A few years ago I was having a conversation with a colleague about all of the impediments I’d uncovered and how I needed to remove them as soon as possible. About half way through the conversation he interjected “These are not impediments, these are merely the tasks we need to complete our user stories”.

Then it dawned on me, I was so focused on removing impediments that I had begun to view our tasks as blockers to progress.

I was wearing impediment colored glasses.

Luckily for me I was pulled me back into reality before I started having conversations with the team on how every task was a blocker. I may not have made it out of the team room alive.

So how can you determine what is and what is not an impediment?

Tip #1 – People are not impediments
As tempting as it may be, do not label people as impediments. Once you label a person, you begin to subconsciously dehumanize. People can certainly be challenging to work with, but once you cross that bridge to labeling them as blockers it can be difficult to bring them back. If you find yourself doing this, you may very well be wearing impediment colored glasses.

Tip #2 – Impediments are often types of waste
If you find yourself struggling to determine whether something is or is not a blocker, try comparing it to the common types of waste in lean.

• Transport
• Inventory
• Motion
• Waiting
• Overproduction
• Over Processing
• Defects

These types of wastes do not always line up 1-to-1 with your blockers, but they can be a helpful guide in determining whether or not you are off base with your assessment.

Tip #3 – Ask your team what they think
It was a team member who pulled me back into reality, however not all team members are assertive. Who’s to say that the ScrumMaster is the sole designator of impediments? Ask your team what they think. It will give you the opportunity to do a bit of root cause analysis. Quite often, what you see as a blocker is only a symptom of something deeper.

These are just a few tips that I’ve found useful navigating the treacherous landscape of impediments.

What else has helped you identify blockers with your team?

AgileDC is a wrap and I’m pleasantly surprised by the turnout (400!) and quality of presentations. Other than me being absent during the keynote (you know the one where Sanjiv was looking for me) and the fact that my car was locked in the overflow lot with David Bulkin… I have no complaints!

I will call out two specific moments that really caught me by surprise and made the conference for me:

Siraj Sirajuddin’s session on The Influencers Mantra – This session blew my mind. It challenged the way I approach agile adoptions and stripped many biases away in the process. Siraj has a mojo about him that is rare. His session could have easily been several hours on one bullet point alone.

LeanKitKanban conversation with Jon Terry – I had met Jon once before at Agile2011 where we spoke about all of the cool things that the Startup America Partnership was doing, but this was the first time that it dawned on me how LeanKitKanban was different. It is a kanban tool applied as kanban. It also allows you to do what you need and then gets out of your way. I cannot say I work with too many tools that can do this elegantly. I found it refreshing to see people bootstrapping it up and not attempting to please everyone by turning their product into bloatware.

The other highlight of my experience was of course the Retrospective Workshop I facilitated sans-slides. I think this freaked out the conference help as they had to track someone down that could turn off the projector and raise the screen. It was based on an earlier workshop in which I’m iterating on using a Course Canvas. Needless to say people were skeptical at first but I won most of them over by the end. The ROTI graph only had 1 vote below average, which I find promising.

I’ve posted a few videos of the session below. Bonus points if you can find Dave Rooney.

One last note, if you are active on Twitter here are many of the handles of the local DC area agilists that were in attendance. I highly recommend following them!

Sanjiv Augustine
Siraj Sirajuddin
Tonianne DeMaria Barry
Paul Boos
Derek Huether
George Dinwiddie
Bob Payne
Max Keeler
Devin Hedge
Manoj Vadakkan
Richard Cheng

AgileDC will need a bigger venue next year and I’m looking forward to it!

In attempting to create courses and workshops to educate people on agile techniques, I found that I’ve struggled to find the right flow.

So I created a tool to help me do just that.

Introducing the Course Canvas.

It uses techniques rooted in agile and visual management to allow me to craft a course with less effort than a cumbersome outline.

It is also a Minimum Viable Product, as I only built just enough to learn whether or not you will find it useful.

Take it for a spin and let me know what you think.

The folks at DZone were kind enough to invite me over for a chat during Agile2011 to have a conversation about agile, kanban and lean startup.

In case you have not already heard, there is a recent press release on Scrum.org with regards to the adoption of Scrum Extensions.

Today’s announcement marks a new era in Scrum’s evolution by making available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework.

Now I’m all in favor of extending Scrum, and even the name Scrumology (apologies to Kane Mar who probably gets a fair amount of my hate mail) was my take on all of the ways in which you may need to extend it to succeed in your organization. In fact, I’ve taken quite a bit of criticism for my rather progressive take on the Scrum philosophy over the years.

So on one hand, I feel somewhat validated that Scrum.org has opened it up for extensions.

On the other hand, Scrum no longer belongs to Jeff Sutherland & Ken Schwaber.

Scrum belongs to you.

It belongs to Project Managers who stepped into the ScrumMaster role and felt the pain of letting go of years of ingrained command and controlism.

It belongs to the Product Owners who doubled their workload as they assumed all of the duties of the role while still performing their Product Management job.

It belongs to the Developers who threw up their hands in frustration when they realized their existing engineering practices were woefully outdated and had to be radically changed in order to potentially release every iteration.

It belongs to the Testers who realized having stories thrown over the wall to them on the last day of the iteration was unacceptable.

It belongs to the Graphic Designers who let go of their holistic design tendencies and learned to compromise in iteration releases.

It belongs to anyone who tried Scrum and watched it fail in a spectacular fashion because the organization was not structured to support it.

I could go on and on as there as so many stories to tell, but my point is that we’ve been trying and failing at Scrum for many, many years now. We’ve learned Scrum the hard way, where theory is stripped away and we are left with the reality in front of us.

I have the utmost respect for Jeff Sutherland & Ken Schwaber, but this notion of submitting Scrum Extensions for approval is a troubling one to me. I can only hope that they will not assume the role of yet another gatekeeper.

Release and Iteration kickoffs can be challenging. Luckily for us, some of the same techniques we use to manage the flow of work within a Release or Iteration can be used to help us with our kickoffs.

Kanban 101 reminds us to:
- Make Work Visible
- Limit Work In Progress
- Help Work to Flow

Kanban Story Sizing:

Create 3 columns before beginning your story sizing exercise. Label them Ready to Size, Sizing and Sized. Place all of the stories you wish to size in the Ready to Size column. Pull the stories through each column as you progress. Since I’m usually planning with one team, I only put a WIP limit on the Sizing column and keep it at 1.

I use Index Cards for this exercise, but you could project your Agile Lifecycle Management software up onto a wall or Skype it and accomplish the same thing.

Kanban Story Tasking:

Create 3 columns before beginning your story tasking exercise. Label them Ready to Task, Tasking and Tasked. Place all of the stories you wish to task in the Ready to Task column. Pull the stories through each column as you progress. Since I’m usually planning with one team, I only put a WIP limit on the Tasking column and keep it at 1.

I use Index Cards and Post-its for this exercise. The Index Cards start out with no Post-its in the Ready to Task column, then once we move it into the Tasking column the team begins to generate the tasks by writing them down on the Post-its. These are stuck up onto the wall below the Index Card, and then once we are finished we bundle them up with the Index Card and move them to the Tasked column.

You do not have to follow this exact style of course, and you can easily adapt this to your Agile Lifecycle Management tool much like I suggest above with the Story Sizing exercise.

In both Story Sizing and Tasking, I find the coupling them with a timebox for the session will help manage the flow and team focus.

I would not go to the extent of tracking time through the columns, however it should be obvious when your flow is getting bogged down. I find that it tends to happen with the larger stories (yet another reason to size small).

“A good engineer thinks in reverse and asks himself about the stylistic consequences of the components and systems he proposes” – Helmut Jan

This advice is not limited to engineers. It also applies to many of us who want to produce software that actually matters to people.

Thinking in reverse, yet leaning forward can yield innovative results. This can be especially helpful when you feel as though you’ve become stagnant in your day to day activities.

Applied to Lean Startup

As the Lean Startup movement continues to gain momentum, one has to be careful not to blindly speed through the Build -> Measure -> Learn loops.

As Eric Ries stated in his Mixergy interview, even though you act in:

Build
Measure
Learn

You need to first think it through in reverse:

What do I need to learn?
What do I need to measure to learn?
What do I need to build to measure to learn?

It may sound awkward, but the subtle shift in thinking really blew my mind when I first realized how it would affect building out minimum viable products.

Applied to User Stories

Mixing things up can also help you inspire innovation when writing User Stories. I was first introduced to this by Lyssa Adkins a few years ago.

Instead of following the standard User Story format of:

As a user,
I want feature,
so that benefit

You can work in reverse from the end to the beginning:

So that benefit,
I want feature,
as a user

This forces you to think about the benefit first, and then trace it back to what feature would provide that benefit. You can then trace the benefit back to the user.

This subtle shift in the way you approach writing User Stories can profoundly affect how you think about your features. It may help you realize that a benefit or feature you initially thought was useful does not have any user demand.

Applied to Behavior Driven Development

Another method of applying this technique is with regards to Behavior Driven Development.

Instead of following the gherkin approach of:

Given context,
When event,
Then outcome

You can work in reverse from the end to the beginning:

Then outcome,
When event,
Given context

Doing so will help you think about the desired outcome, to the event that triggers the desired outcome, to the context that surrounds the event that triggers the desired outcome.

There are other applications of this reversal of thinking, but you should get the idea in the above examples. Try them out when you feel as though something just isn’t working and you need to shake things up.

When: October 26th 2011

Where: AgileDC

What: It can be difficult to convince team members to speak up in a retrospective. Each individual needs to have his or her voice heard, and by incorporating silent work techniques you can foster participation in those who may otherwise be left out.

Come to this interactive workshop as we explore the power of silent work and group collaboration in retrospectives. You’ll walk away with real world techniques to help bring out the inner voices of your team.

If you are still on the fence about attending, I’m including my slides and a few pictures of what this workshop will entail.

I may tweak the format a bit depending on the audience and room layout.

If you have any questions about the workshop or suggestions on a silent technique not listed please leave them in the comments below!