Sunday Book Review : Leading Lean Software Development by Mary Poppendieck

Leading Lean Software Development: Results Are Not the PointLeading Lean Software Development: Results Are Not the Point by Mary Poppendieck

My rating: 4 of 5 stars

Some of the best anecdotal stories on software development that I have read. Great wisdom and content, but failed to push me towards lean being significant short of a methodology. I think that if you are developing software you should read this book. Some people will love it and consider it a bible others will find it useful but not earth shattering.

View all my reviews

Deutsch’s Twelve Commandments of Conflict Resolution

If you want to make a difference you better be willing to embrace conflict. In fact, you better be creating and demanding it. How you deal with conflict is where the magic happens.

Here are some key points from Morton Deutsch’s “Cooperation and Conflict (pdf)”

“When it takes a constructive course, conflict is potentially of considerable personal and social value. It prevents stagnation, it stimulates interest and curiosity, it is the medium through which problems can be aired and creative solutions develped, it is the motor of personal and social change.”

Some benefits of cooperative relations:

  1. Effective communication.
  2. Collective and inclusive solution making.
  3. Cross functionality.
  4. Shared vision.
  5. Building on each others strengths.
  6. Mutual respect.

Negatives surrounding competitive relations:

  1. Personal agendas.
  2. Mistrust.
  3. Silo building.
  4. Hostility.
  5. Power hungry.

Deutsch’s Twelve Commandments of Conflict Resolution:

  • Know what type of conflict you are involved in.
  • Become aware of the causes and consequences of violence and of the alternatives to violence, even when one is very angry.
  • Face conflict rather than avoid it.
  • Respect yourself and your interests, respect the other and his or her interests.
  • Distinguish clearly between “interests” and “positions”.
  • Explore your interests and the other’s interests to identify the common and compatible interests that you both share.
  • Define the conflicting interests between oneself and the other as a mutual problem to be solved cooperatively.
  • In communicating with the other, listen attentively and speak as to be understood: this requires the active attempt to take the perspective of teh other and to check continually one’s success in doing so.
  • Be alert to the natural tendencies to bias, misperceptions, misjudgements, and stereo-typed thinking that commonly occur in oneself as well as the other during heated conflict.
  • Develop skills for dealing with conflicts so that one is not helpless nor hopeless when confronting those who are more powerful, those who do not want to engage in constructive resolution, or those who use dirty tricks.
  • Know oneself and how one typically responds in different sorts of conflict situations.
    • Conflict avoidance/Excessive involvement in conflict
    • Hard/Soft
    • Rigid/Loose
    • Intellectual/Emotional
    • Escalating/Minimizing
    • Compulsively revealing/Compulsively concealing
  • Finally, throughout conflict, one should remain a moral person, ie: a person who is caring and just, and should consider the other as a member of one’s moral community ie: someone who is entitled to care and justice.

A Facilitator’s Best Weapon. Emotional Intelligence.

As a facilitator one of your jobs is to keep things on track. There is a finite amount of time to get the desired objective/output. Sometimes it is important to remember that interactions that seem like they are going no where are the very thing that get the discussion beyond the surface level. Don’t kill the serendipity in conversation just to stay to the minute on your time line.

Training on Graphic facilitation

Facilitators need to have strong emotional intelligence to be effective. It is important to allow people to explore outside the “plan” of your intended your agenda. Let them stray off the path and use your inuition to determine when to reel them in. Improvise accordingly to get back on track. When you facilite with emotion and are open to possibility, instead of an iron fist, you will unlock the best in those you are facilitating.

How To Have an Effective Internal Agile Coaching Program?

Why are external agile coaches so popular?

I think that they are appealing to management because they have an external view of the organization. Organizations have a hard time understanding their dysfunction, if they are able to recognize it all. Outsiders bring experience from other organizations and don’t have fear in challenging organizational norms.

However, the use of external coaches long term is not very sustainable. How do we develop internal coaches (and programs) that allow, promote and encourage internal coaches to see their organizations through the eyes of an outsider while leveraging their institutional knowledge?

Lyssa Adkins lead a team at the Scrum Coaching Retreat that put together some thoughts about running an internal coaching consultancy (coaching services). It’s a great start, but I still challenge how do you get that outsider’s view? How do you not fall trap to the “Stockholm Syndrome“?

What if coaches had an exchange program, where they could spend time at other organizations or you could invite an exchange coach into your organization for a fresh perspective? Maybe this is just done by using external coaches and mentors?

What if coaching groups were shared among multiple organizations so that the best of each organization could be preserved, but the negative aspects could be seen with a critical eye?

Insert your what if.. in the comments below…

Hacking Standups – I Feel Exposed

At Integrum we regularly find new things to try as a result of our regular team retrospectives.  Recently, the team had a lot of discussion about what it takes to make teams great.  There was a lot of discussion about the necessity to be vulnerable with each other in order build deeper levels of trust.

The team decided to add something to our daily stand up.  We added the question “I feel exposed because…”.

The results were interesting.  We found that often times the things that left people feeling exposed were early warning signs to problems in getting the work done.  Seeing these before they became road blocks actually had the effect of increasing productivity.

Additionally, it allowed many team members to express fear in a safe way.  Allowing others on the team to help them move through it.  Ultimately, we did not stick with the hack because our team changed significantly and the new team was much closer and didn’t feel the need to explicitly state how they felt exposed.

How are you hacking your SCRUM ceremonies?

Four Building Blocks of High Performing (Agile) Teams

Building great teams is hard work. When it comes to Agile teams there four building blocks that have to be present. You might consider it the starting DNA sequence for building a high performing team. If the team lacks any of these it will not stand the test of time.

Empowerment

The team has to be empowered. They must have the permission to do what they see fit to succeed. Great teams take full advantage of opportunities to self-organize.

Trust

The team must trust each other and those that they are doing the work for. If they have a lack of trust, they will not be able to express the proper vulnerability that will open them up to greatness. This is usually the number one piece of DNA missing from most teams/organizations.

Power of Inspection

The team must constantly be scanning, observing and inspecting their work and the environment around them. Not just at the end of an iteration, but at all times. Every interaction has to be filled with curiosity and question for doing it better. The drive towards the path of excellence has to be extremely strong.

Ability to Adapt

The has to be able to act on the feedback they are collecting for improvement. Just noticing ways to improve is not enough, they have to be vigorously applied and built upon.

When teams can assemble these building blocks, they have unlimited potential. How are you unlocking these in your team?

How SCRUM Teams Are Like The Three Branches of Government

I like metaphors. I can’t help but think that the roles of a Scrum Team could be compared to the three branches of government.

Executive Branch (Product Owner)

The role of the executive branch is to hold sole authority and responsibility for the daily administration of the state. They do not create the law, but are responsible for its execution.

In Scrum, the product owner is has the final authority to what gets delivered. They are ultimately responsible to the organization for the product. In some circles they are even considered the “single wring able neck”. The product owner does not perform the work but are responsible for it’s delivery.

Legislative Branch (Development Team)

The role of the legislative branch is to pass, amend and repeal laws. The legislature appoints it’s own leadership. They define who will do what duties and appoint their own committees. They congregate in the same room to deliver the work.

The development team’s role is to do the work. They appoint their own leaders and are self organizing in who will do what duties to complete the work at hand. They work in a team room to deliberate on the work.

Judicial Branch (SCRUM Master)

The role of the judicial branch is to interpret and apply laws on behalf of the state. They are critical in the resolution of disputes. They do not make laws and they do not not enforce laws, but rather interpret them and apply the facts.

In a similar way, the Scrum master interprets the principles/values of agile/scrum and applies them on behalf of the organization. They are critical in resolving conflicts and removing roadblocks to progress between the team (Legislative) and the product owner (Executive). They do not perform the work and they do not define the work or it’s priority, but rather they help provide balance and guidance for success.

When we start to think in these terms, perhaps it is easier to understand why one person shouldn’t hold two different roles at the same time? (ex: I’m the scrum master and a developer or I’m the scrum master and the product owner.)

Ruby Revolution Rebuttal

Mark Turner has made a great response titled “Ruby never powered a revolution” to counter my recent post “Ruby is Just a Bunch of Tools“.  Excerpts from Mark’s post bold.

“I decided he was wrong.”

Mark, I am never wrong.  However, I have been known to be mistaken a time or two. 🙂

“Ruby was never about revolution, Ruby is about making us, as developers, happy. For many of us it was a language whose syntax, expressiveness and quirks touched the right nerves. It was the feelings we got about the language that made us want to use it. It wasn’t it’s speed (lulz), it wasn’t it’s libraries and it sure wasn’t its popularity. For many of the people that have been using Ruby for a long time, at one point they dreamed of getting a job that paid them to write Ruby. Today they are plenty of jobs.”

I think I consider Rails, Ruby for right or wrong.  Ruby purists can bitch and moan about that all they want, but the reality is if Rails didn’t exist Ruby would have virtually no adoption and barely be considered a real language.  I think a lot of the idealism I speak about came from the Rails community.  Driving for testing, convention over configuration, etc.. Hell the fact that active record got people to the point where they aren’t writing SQL queries is simply an amazing feat.  Something Smalltalk and the likes were never able to get widely adopted.

Define plenty of jobs.  The Ruby community is microscopic in the grand picture of programming.  A quick search of Dice.com for ruby yields 1,735 results, .net yields 9,986, java 17,239. While this is impressive it’s still a fractional portion of the world today.

“At the heart of Derek’s argument it would seem that the abundance of tools, and the creation of those and new tools or workflows are somehow unrelated to changing the status quo or spreading new ideas. I don’t understand this argument. I get a smile whenever someone decides that a tool doesn’t fit their needs so they make their own. I get exited whenever someone brings a new idea to Ruby or is unhappy about the way a library/application they use works so they fix it.”

It is not the abundance of tools nor the creation of tools that is the problem.  It is that the community thinks technology is the answer to everything.  Instead of pushing against the status quo to think differently.  The drones are just trying to make the status quo faster or more efficient.  Making a better (speed, syntax, etc) test framework is not the same as introducing the concept of TDD or BDD for the first time in a meaningful way to get wide spread adoption.  I am not seeing any real creativity from the community, it is all geekery instead.  While a faster, cooler, automated foo is great, it’s not pushing the industry forward.

“Derek also has a point about the abundance of “non Ruby ideas” at regional ruby events.”

I articulated this poorly.  I was trying to say that we are too focused in on hearing speakers talk about tools they have written instead of talking about the possibilities of where the community can go.  Regional conferences used to be about people sharing cutting edge ideas and trying new things.  Now they are about the “speaking circuit” for tool/library authors to pimp their shit or the Ruby personalities to measure their community e-peen for organizing a conference.

Personally, I have seen other platforms start to catch up and people that are more language agnostic seem to be moving the industry forward the most.  I am finding the revolutionaries more in the Agile community than the Ruby community at this point.  Ruby has a special place in my heart (as does Rails) for inspiring me to stand up and fight for change.  To not accept the status quo as reality and champion the future.

I write this as I prepare to speak at Agile 2011 this week.  Am starting a new Django project with a team while doing agile coaching at a .NET enterprise client.  While still committing code to a Ruby project for a Fortune 50 client.  Guess I’m an innovation slut instead of a Ruby whore these days.

 

Ruby is Just a Bunch of Tools

I have always liked Unix because of it’s mentality that lots of small tools chained together could be more than an opaque larger tool.  In this instance.  I mean Rubyists are a bunch of Tools not of the useful kind.

Maybe Zed is right an Rails is a Ghetto.

I had planned on writing something up, but seeing how these notes are almost 6 months old.  Im going to just publish the list of thoughts instead.

Ruby used to be about revolutions and new ideas.  Now it is just about tools.  The community revolted against the status quo.  They won.  Then they gave up.  I guess it is hard to be motivated to work after winning a revolution?

The leaders have disappeared.  The second and third wave are just implementors.  They are not idealistic.  The Merb team emerged full of new ideas and a swagger of yesterday but all that died when they merged back into Rails.

It used to be about changing the world.  Now it’s just about tools.  Workflows are broken and complex.  We fix them with tools instead of ideas.  Regional Ruby talks are littered with talks about tools or non Ruby ideas.  No one is talking about ideals and communities of change.

Where did the leadership go?  It was great to see Liz talk about BDD not being about tools and Dan North pushing back on Craftsmanship.

We have become the drone army.  We are losing.

Sometimes Team Perspective is Needed

The benefit about working on a high performing team is that everyone expects excellence.  There is always a drive that it could be better.  Nail a perfect 10 and then ask how it could be an 11.

Over time it is easy to forget how far you’ve come.  If you are constantly inspecting and adapting take a moment of silence to remember how far your team has come.  Remember excellence is a journey and not a destination.  Recollecting the past can be a stark reminder of how far you’ve come.

Our joke today:
3rd World Problem: “Hey we don’t have any source control”
2nd World Problem: “We don’t have tests”
1st World Problem: “My tests take longer to run than I would like”

What’s your perspective today? Share a memory with your team mates and remind each other how far you have come.