The Scrum Master as a Square Peg

Your scrum master is a square peg.

I have said repeatedly agile is a reformation to the business world.  It is not an uprising with torches and pitchforks.  It is a smart and conscientious people seeking reform and the abolition of corruption in business.  It is thankless work. Today on the blog, I would like to talk about the job and how it requires devotion to be successful.

The scrum guide makes the role of scrum master sound easy to fill.  A scrum master is a servant leader.  A scrum master is a person who promotes and supports scrum in the organization.  Finally, they help others understand what helps and interferes with the delivery of solutions.  It sounds simple but is a career fraught with peril.  A scrum master is often a misfit inside the organization doing what they need to do to get work done.

A scrum master ruffles feathers daily.  It means being on the phone, making sure network permissions are correct.  It is attending a meeting so the development team can concentrate on delivering value.  A person in the job spends plenty of time asking uncomfortable questions and does not accept, “…because we have always done it that way,” for an answer.

Scrum mastery requires being the person who points out when the emperor’s new clothes are illusionary.  The scrum master gets work done and being able to ship product to customers often silences critics inside the organization.  Paradoxically, this kind of success breeds organization resistance because you are upsetting established patterns of work and culture.  It is leadership without authority which drives ineffectual people to resentment.  It is the opposite of the go along to get along personality, which often crops up in corporate organizations. A scrum master by their very nature is an iconoclast.

It explains why a scrum master is often a square peg in a round hole.

Until next time.

A River of Leadership

Leadership is like white water rafting.

The world of software development is an untamed river of uncertainty and innovation.  I swim in this whitewater of ambiguity and get caught up in its currents regularly.  Technology never rests, and the pressure to sink or swim is always present.  Being a leader is more perilous because you are also responsible for the wellbeing of others who work with you.  I want to take a closer look at those responsibilities of leadership.

At the recommendation of my colleagues, I am stepping forward and founding a chapter of the Agile Coaching Exchange in the greater Chicago area.  It is a new role for me and something I have not done before.  I am gathering speakers and attempting to set up venues for the group to meet.  I have been a participant in these kinds of gathering for years, and now I am organizing them.  It makes me respect the people organizing meetups and user groups more because I understand how much hard work it is.

The experience reminded me of a blog I authored about leadership.  A person has three choices when confronted with a challenge; lead, follow, or get out of the way.  It is time for me to show some leadership in the agile community instead of ranting like a voice in the wilderness.  It is not the traditional leadership I was trained earlier in my life to adopt.  Times change, and so does leadership.  Claire Croft mentions this in an article for Forbes magazine.

The global economy is changing too quickly.  Sears and ToysRUs are gone.  The internet reaches over half the world's population, and it is growing by 2% annually.  We measure success in days instead of years.  Finally, the job I have today did not exist when I was a college undergraduate.  It means traditional notions of leadership are not going to adapt to the turbulence of the current business world.

It means leadership needs to come from inside.  You have to play up personal strengths and work with your shortcomings.  Instead of a mask of command, a leader should expose themselves to others to build empathy and radical candor.  It includes being kind to yourself and others because we are all fighting unique struggles each day.

I continue my adventures rafting the unsettled river of technology.  As the water rises and falls, I will change my leadership style to navigate to the next destination.  I am grateful for each of my readers, who are sharing this journey with me.

Until next time.

Start Writing Unit Tests!

It helps when you test your code.

Software development is a difficult process.  It is filled with trial and error.  Developers must contend with vague requirements and impossible timelines.  It explains why the profession has a high failure rate.  I think we can do a better job and today I would like to discuss the easiest way to help reduce failure.

When I first learned about software development, the notion of software testing was primitive.  Often software testers manually went through the software attempting to find bugs.  It was a tedious and time-consuming process.  Automated testing began to pop up in the world of JAVA and then spread to the Microsoft world.  At first, developers chaffed at writing unit tests calling it extra work and unnecessary. 

After the initial resistance, the engineers and developers began to see the importance of unit tests.  Unit tests ensured the code functioned when checked back into source control.  It also made sure a change in one part of the code would not break a different portion of code.  Automated testing had another impact.  Manual testing became unnecessary and if freed up people to deliver more value in the organization. 

Automated testing not only cut back manual tests, but it also makes the release of software faster.  What usually would take three weeks to release could now take as little as three weeks.  Thus, automated unit testing reduced labor overhead improved the quality of software and increased the time to market for software.  Instead of chaffing at writing a unit test, the real question is why you haven’t started writing them.

Until next time.

Self-Organization Works If You Let It.

Teams cannot be assembled like Lego bricks.

I spend much of my time working with agile teams.  A big challenge is often these people are thrown together and forced to behave as a “team.”  The self-organizing team is one of the most critical pieces of an agile project, and it is one of the hardest things to create.  I wanted to spend some time discussing why building teams is so difficult.

In most business environments, a team is formed by hiring consultants and putting them together with existing employees.  The team is broken up, and the consultants are laid off or moved to a different project when work is complete.  The approach from an accounting perspective might make sense, but it creates plenty of unnecessary work.  Teams are continually going through Tuckman’s stages of group development and are in the “storming” stage of team maturity.  In a more agile environment, work comes to teams, and then the teams do the job.  The group moves on to a different project when they finish work.

According to the Harvard Business review teams which stick together have a 19% decrease in defects and 30% decrease in budget deviations.  The bottom line is that spinning up units and disbanding them is a foolish use of company money.  So what makes the team self-organizing?  Yvette Francino has an excellent blog on the subject.  In short, teams which self-organize have a few properties:

1. They hold themselves accountable for success and failure.
2. They healthily handle conflict.
3. They have a common goal which they strive to achieve.
4. They have a standard way of working.
5. Finally, they have stable membership.

These traits make an excellent self-organizing team, and it is up to agile coaches and scrum masters to hold them accountable.  Notice that these requirements do not mention test-driven development, SOLID Development, or other technical paradigms.  Most of these skills are soft skills.  It means that a team needs to learn how to work together outside of the technical skills, and this is difficult.  People have egos and subtle hierarchies of expertise and authority.  Add to the mix unrealistic deadline pressure and micromanagement from outside leadership, and you corrupt the five characteristics of self-organization.

So look toward creating more functional teams and allow upper management to understand how they are more successful.

Until next time.