Monday, September 25, 2017

Sharpening the Saw at the Agile Coaches Symposium

Billie Schuttpelz and I at the Agile Coaches Symposium
One of the seven habits of highly successful people is called “Sharpening the Saw.”  It is taking time off for self-care and personal development.  I took time off from the blog and spent some time at the Uptake offices for the Agile Coaches Symposium in Chicago.  It was a great time and a valuable learning experience.

Working as a scrum master and agile coach is often a lonely duty.  You are spreading the word and sharing information with a skeptical audience.  Business and cultural forces often impede the agile maturity of the organization.  As a coach, you are spending your time serving as an example to others.  It is why it was nice to spend time with others in this profession and exchange information.

A few themes cropped up during the conference.  First, over 80% of the people at the conference said that had suffered from Impostor Syndrome.  It surprised me because when I have moments of doubt and disappointment, I chalked it up to something else. It is clear that those moments of darkness are Imposter Syndrome rearing its ugly head.  We did not have any easy answers to these issues, but it was still helpful to discuss them out in the open with others.

Next, there is a trend in the business world for Project Managers and other waterfall types of people to falsely brand themselves as agile coaches.  These falsely branded coaches create plenty of situations where people without experience or the personal qualities of coach try to bring agile to organizations.  The aftermath is typically a poorly applied implementation, and the agile movement undermined.  Collectively, we felt that some level of exposure and experience with agile was necessary to help coach others.  The consensus of the group was that a good coach, “Wares the shoes and can talk about the walk.”  So be on the lookout for agile coaches who cannot find comfortable shoes to wander around the office.

There were plenty of other discussions.  I even had a chance to talk about how my notion of story points have changed during my career.  The best part is spending time with other agile professionals and learning from them. If that is not sharpening the saw, I do not know what is.

Until next time.


Monday, September 11, 2017

Planning is Everything

This scrum master
wants to be more like Ike.
It takes plenty of emotional energy to be a scrum master or agile coach.  Developers need guidance, product owners need constant coaching, and upper management is always asking for status updates.  It is psychologically exhausting.  Along with day-to-day chores, you are planning and setting strategy.  This week I want to discuss how planning and responding to change are not mutually exclusive.

According to the Agile Manifesto, responding to change is more important than following a plan.  Situations in technology are changing at a rapid clip and an idea that seemed plausible an hour ago can be hopelessly out of date.  Agility depends so much on responding to change.  The unintended consequence of this is business leaders abandoning planning altogether because “We are doing agile we don’t need plans.” Let me try to add a little sanity to this discussion.

The manifesto states, “…while there is value in the items on the right, we value items on the left more.”  Planning has some value and should not be abandoned because we are responding to change.  It seems like a contradiction.

Planning is an integral part of agile.  A scrum team does sprint planning before the start of a sprint to decide what they are going to do.  The product owner does release planning to prioritize stories in the backlog.  A plan makes it possible for an agile team to understand the nature of the problems they are trying to solve.  It also allows them to learn how to respond to change when the inevitable happens.  It explains why Dwight David Eisenhower said, “Plans are worthless, but planning is everything.”  When a team plans they are going over possible scenarios which might happen during a sprint.  The team is also doing much of the analysis necessary to start writing unit tests and code.

To use a metaphor from music, Jazz and Blues musicians still rehearse even though much of their music is improvisational.  The players outline key progressions and cords they are going to play.  It is the plan they use for their performance.  Once the concert begins, situations may dictate a deviance from the scheme.  Thanks to the outlines figured out during the rehearsal, these musicians can respond to change.  The same thing happens to a development team during a sprint.

So responding to change is important but you cannot respond to change unless you have spent some time planning to understand what changes might happen.

Until next time.

Tuesday, September 5, 2017

When a team fails.

Failure Stinks!
I continue to assert that software development is one of the most misunderstood professions in the business world.  Numerous executives think what we do is magic or do not understand the creative nature of the activity.  It is not like working on an assembly line or collecting accounts payable.  There is plenty of uncertainty and opportunities for failure.  As a scrum master and coach, you have to deal with the failure of your agile team along with the personal failures that inevitably crop up in your career.

The saying in the agile community is that you should “fail early and fail often,” because failure is a brutal and efficient means of learning.  The notion of failure conflicts with the “cult of success” preached by motivational speakers.  It also contradicts notions of winning promoted in sports journalism.  I believe the failures in my life and career have made me a better person.  I also feel these failures were necessary milestones on the road to the success I have had in my life.  Failure is painful, but it does put into perspective the ups and downs each of us have in this life.  

Part of the educational process is owning up to and taking responsibility for those failures.  When your team fails to deliver software on time, you have failed.  It is incumbent on you understand what you did wrong and how to avoid the same mistake in the future.  There are situations where you do not have much control, and you still are confronted with failure.  It is unfair and unjust, but accepting that position and learning how to deal with it next time may lead to success in the future.

The acceptance of failure also does something else; it wins the respect of others who have been through the same experience you have.  You have endured the same hardship as others and have accepted responsibility for your shortfalls.  If you blame others or do not assume liability for failure, it will undermine your credibility as a leader and destroy teamwork.  I witnessed this first hand and could see collective eyes rolling as this individual began to speak.

So as a scrum master and agile coach, accept failure and take responsibility for it.

Until next time.