Monday, February 20, 2017

Disagreement means learning

Listen and Disagree
It is invigorating to have back and forth between fellow agile professionals.  It represents the give and take of knowledge between people.  People inevitability disagree about subjects, and the practice of Agile is no different this week I would like to talk about disagreement.

One of the more interesting books about leadership is “Team of Rivals,” by Doris Kearns Goodwin.  The central thesis of this book was that President Lincoln had a unique leadership style where he relied on the opinions of political rivals in this cabinet to help him better manage the events of the American Civil War.  Having a room full of devil’s advocates made Lincoln a better leader.  Numerous other articles and books have also surfaced which emphasized that diversity of opinion and perspective is necessary for success and innovation.

Lately, my blog posts and discussion on the Google plus agile community are being challenged by coach from Europe.  Some people would recoil from this kind of push back; I do not.  This individual has credentials and plenty of experience in the field so while I may disagree with his opinion; I respect his perspective.  I am a firm believer in disagreeing with people without being disagreeable.

My approach to Agile and Scrum centers around the Agile Manifesto and Agile Principles.  The Scrum Alliance gave me formal training as a Scrum Master.  Finally, I have spent nearly four years in the role of a scrum master shipping software with domestic and offshore development teams.  I have seen some things and done some stuff.  My experience colors my agile knowledge and opinions.

The product owner has the hardest job in the scrum.  The Scrum Master is a Coach, Therapist, and often the bad cop which keeps things moving forward.  Finally, the development team generate shippable code each day and are the unsung heroes of the process.  I live this experience every day and hope each of you who read this blog gain from my knowledge.

Disagreement is healthy, and if you are not willing to consider other opinions and activities, you are not going to grow as Scrum Master.   Listen to others who you disagree with; you never know what you might learn.

Until next time.

Monday, February 13, 2017

When to Unleash the Kracken

Make sure you mean it!
I have called being a Scrum Master many things.  It is a coaching role.  Being a scrum master can resemble being a therapist.  I have even compared being a scrum master to a parish priest.  The job is not easy.  A scrum master has plenty of late nights and early mornings.  One of the things they discuss in training for Scrum Masters is an important responsibility.  A scrum master can terminate a sprint.  Trainers don’t often consider this awesome responsibility but this week I will.

When things go badly in spaceflight mission control can terminate the mission.  When that happens, the astronauts turn the ship around and head back to earth via the shortest route.  When things go wrong on a scrum team, we have what is called an abnormal termination.  The sprint ends immediately, the team does a retrospective and plans a new one.

There is a contentious debate in the Agile community about who has the right to terminate a sprint.  I belong to the ideological camp that a scrum master should have this terrible duty.  I feel this way because the scrum master is the protector of process and improvement of the team.  When the Product Owner or the development team is in a hopeless situation, it is up to the Scrum Master to recognize it and take draconian measures.

Terminating a sprint is a huge deal.  Do not do this lightly.  It should be the plan “C” or “D” for any sprint.  Terminating a sprint creates all sorts of attention in an organization and is profoundly disruptive.  When a Scrum Master kills a sprint, it is the equivalent of Zuse saying, “Release the Kracken!”  Do not do it unless you are certain.  Otherwise, it is like pulling a fire alarm because you do not want to go to class.

The following are the rare reasons why a scrum master ought to terminate a sprint.

Project funding has changed drastically-

In an uncertain global economy, projects get canceled, and new ones are spun up.  These events impact your plans.  If this happens, the scrum master may want to terminate the sprint.  The termination will give the Product Owner, development team, and Scrum Master a chance to take stock and decide what the next steps to pursue.

The Product Owner is fiddling with a sprint while it is in progress-

I working with a product owner who was under so much pressure they could not prioritize work.  Sprints would begin, and stories would be swapped out with others.  Things which were a priority during sprint planning would be dropped days before the end of the sprint and replaced with stories of equal size.  The development team was forced to try and do the same amount of work in half the time.  Confronted with this bad faith behavior, I hit the self-destruct button and brought it to the attention of my Vice President. Leadership replaced the Product Owner in the aftermath.  The development team resumed sprinting.

The team grossly underestimated the work they could do in the sprint-

We have all had the “ten-minute change,” conversation. A product owner or someone from the business asks for a change to the system.  The developer listens to the request absentmindedly and says the change takes approximately ten minutes to perform.  A week later the developer admits the change affected other systems and it would take longer than expected.  Soon the rest of the development team is sucked into correcting the situation.

As my mentor, Angela Duggan would say, “developers are afraid of looking incompetent or unskilled.” This fear pushes software developers to underestimate work.  The team commits to something and then realizes it is more complicated than first expected.  If your development team has with six weeks of work in a three-week sprint, it is acceptable to hit the reset button.

These are three of the rare situations where you might terminate a sprint.  If you have other suggestions, I would love to hear them.

Until next time.

Monday, February 6, 2017

Scrum should not be a cargo cult.

Scrum should not be a cargo cult.
Blogging about business and scrum opens you up to feedback and criticism.  Confronted by people who challenge your ideas allow you to reflect on your knowledge and beliefs.  A college of mine took offense to me referring to the meetings of a scrum as “rituals” last week.  I would like to address his concerns.

The primary criticism of my article was that I was encouraging a “cargo cult” kind of scrum.  The term comes from a Scientific American article from 1959 which documented primitive tribes in Melanesia coming in contact with missionaries and soldiers.  The connection prompted these indigenous people to create cults to encourage cargo to be delivered to them.  Primitive air strips, airplanes, and shipping terminals cropped up in the hope that actual cargo planes and people would show up.

The pre-modern culture felt if they mimicked the trappings of technology without understanding the principles behind that technology they would receive the prosperity which comes with modernity.  This assumption is wrong.  The tribes created many faux landing strips and cargo depots in the South Pacific.

People in the agile community, use the story of the cargo cult to illustrate the difference between going through the motions of agile and being agile.  In a perfect world, a business would reconfigure itself to follow the word and spirit of the Agile manifesto.  We do not live in a perfect world, so it is up to scrum masters and agile coaches to provide structure for the transition from traditional business to agility.

The events of scrum provide a means to help speed that transition.  Business people and developers are forced to inspect, act and adapt to changing situations.  That is the heart of an agile business.
When I refer to the meetings and events of the scrum as rituals, I mean the meetings should have purpose and significance.  I am not attempting to create a “cargo cult” in an organization.

I am glad someone challenged me on my assertions, and I look forward to more give and take in the future.

Until next time.

Monday, January 30, 2017

Why we have rituals in scrum

Becoming a scrum master is like becoming a priest
I am in the process of training a new scrum master at my office, and they asked why we have so many meetings in Scrum.  This week I wanted to share my thoughts on the subject.  The Scrum Alliance has plenty of documentation about Agile, the roles in a Scrum team, and rituals associated with it.  As an experienced Scrum Master, I wanted to dig a little deeper into the activities and explain why they are important.

The role of a Scrum Master is a complicated one.  I have written about the topic numerous times.  As I have grown more comfortable in the role, it occurred to me that this position resembles the life of a parish priest or Protestant minister.  You are always visible and accountable to the people you serve.  I firmly believe in the need for a human being to have ritual and routine in their lives.  Both Carl Jung and Joesph Campbell, mention that the collective unconsciousness is something which needs nurturing.  If we do this, then we are on the way to building effective teams.

The daily stand up-

Each day the team gathers around the metaphorical campfire and talks about what they have done, what they will do, and obstacles.  Working in an office creates a few anti-social behaviors.  It is very easy for people to cocoon into their desks and ignores others.  The stand up breaks people out of that unhealthy habit.  Each day for 15 minutes they interact with the scrum master and each other.  The group stands because it forces people to pay attention to one another.  It also keeps side talk to a minimum.  Finally, it helps foster a sense of teamwork because everyone is participating and involved in the success of the project.

After a few weeks or months, the scrum master should not facilitate the meeting.  Instead, the team should learn to run its stand-up meetings.  It is part of the ethos of self-organization.  It is essential to the success of agile at any organization.

Backlog Grooming or Refinement – 

The Product Owner has the most difficult job in agile.  They work with the “business” and the development team to create software each sprint.  Backlog refinement is where most of this job happens.  The Product Owner and the development team go over the backlog.  This meeting is designed to clear up any misunderstanding, explain user stories, and set priorities. It is an informal meeting with back and forth conversations.  The Product Owner facilitates this session.  It can be done regularly each day or scattered around a work week.  The keeps communication between the team and the product owners flowing.

Sprint Planning – 

The Scrum Master, Product Owner, and development team get together to decide what they want to work on in the next sprint.  Using the refined backlog the team and the Product Owner decide what to do next.  This meeting is a little more formal as the team estimates and tasks out the work.  The meeting also ends with a consensus about what the sprint goals are and how to meet them.

Sprint Review or Demo –

One of my biggest frustrations I had as a developer was spending a year on building a software product and then showing it to the user community and having them say it is not what they wanted.  The sprint demo is designed to eliminate this situation.  After a sprint, the development team shows off their work to the Product Owner and the people who are stakeholders in the project.  Here they gather notes and feedback where they can improve.  The demo also shows the business that things are getting done and that they will have software in a measurable amount of time.

The Retrospective – 

The retrospective led by the scrum master.  It is a combination of rituals.  It is about what happened.  It is also a look forward at how to improve.  Everyone participates in the process, and everyone contributes.  It is up to the Scrum Master to take notes and help the team improve on how it is supposed to do its work.  The retrospective is the most difficult part of the scrum process, so a scrum master good at facilitating meetings is essential.

So this is my take on the rituals of Scrum and why we do them.  They are all important, and if you do not do them, the effectiveness of your scrum teams will suffer.

Until next time.

Monday, January 23, 2017

The Messy Nature of Software Development

Software is messy
I have been in the software business for nearly twenty years.  I began as an entry level programmer and made the transition to scrum master and agile coach.  It was not pretty or heroic.  It was a journey filled with personal and professional setbacks.  Sometimes, I wonder how I didn’t wind up begging for change on the side of the road.  Somehow, every setback I have faced has led to a larger and better opportunity.  This week on the blog I wanted to discuss something which we do not discuss often; the messy nature of software development.

If you are not already following Angela Dugan’s blog, “The TFS Whisperer,” you should.  One of the posts struck me for its honesty and courage.  She talked about how application lifecycle management and DevOps are “messy.”  I add that everything involving software is messy.

The creation of software is a new trade.  It began in the days of vacuum tubes after World War Two and had grown into an activity employing a total of 11.5 professionals worldwide.  The term bug came from a moth trapped in a box of the first vacuum tubes of the ENIAC computer.  Today, bugs represent any of the defects or mistakes we perpetuate in code.

In the seventy-plus years since the beginning of professional programming, the activity has not fundamentally changed.  Smart people work in isolation writing software code, and business people take it for granted that is works.  The reality is software is one of the few activities which has not been taken over by automation.  It is a creative and manual process. It is both an art and science.

Unlike construction which has a set rules for engineering and gravity software development lives in a strange world where the rules do not matter or change with each release.  Deadlines are either fluid or hard as stone.  People work late nights and early mornings to get the product out on time.  Personal relationships suffer as support calls intrude on anniversary dinners and you are asked to release software on Sunday afternoons.

The people who do this work are smart and creative.  Too often the demands of the business community force leaders to treat these people like machines which run on caffeine and pizza.  The people who write software have children, significant others, and aging parents.  They have felt and experience the entire range of human emotions.  They are more than points of data in an Excel spreadsheet or a line item in a project plan.

It matters because software is one few activities in business which is immune to automation.  It is manufactured by hand by these creative human beings.  So software is “messy” because people under great pressure author it every day.  Software development is “messy” because people make mistakes.  It is “messy” because people have emotions which are hard to control.  Finally, software development is “messy” because business people treat software professionals as interchangeable “staff” instead of skilled artisans.

I have spent numerous nights questioning my ability and worth thanks to the messy nature of software development.  I am sure that other software professionals have done the same. This business is humbling.  Angela and I agree; software development is messy because very human people are involved in every stage of its creation.

Until next time.

Monday, January 16, 2017

Explaining being a scrum master to civilians.

A scrum master is a servant-leader
One of the things which make working in the 21st century so dispiriting is most people cannot easily describe the work they do.  During the middle ages, people were farmers, blacksmiths, nobles or merchants.  The roles and job descriptions were easy to understand.  Today, the work of content curators and account managers creates plenty of ambiguity and misunderstanding.  This week on the blog, I want to clarify the definition of a scrum master.

The Elevator Pitch

When I am at social functions, networking events or family gatherings people ask me what I do for a living.  I say scrum master and I get a puzzled look, and they ask me, “What kind of job is that?”

This is what I say.
“I build software and help developers and businesses develop software on time, on a budget, and with minimal bugs.”
The person nods and smiles, once this sinks in and switches to a new topic.

The Scrum Master Syllabus

When I describe the job of a scrum master, it often looks like a college syllabus.

A good scrum master is:
  • An excellent communicator with individuals, small groups, and the organization.
  • They understand the agile manifesto and principles of Agile and practice them every day.
  • They are a trainer and coach making product owners, developers better and their job.
  • They educate business leaders and stakeholders on how agile is making their business better.
  • They are good listeners
  • They have grace under pressure
  • The can educate developers on TDD and SOLID development
  • They are servant leaders
  • They ship working software regularly.
  • They make a god damn difference.
These are the signs of a good scrum master, and I try to aspire to these goals each day.

The bottom line.

Being a scrum master is a hard job.  It is also a calling of sorts closer to being a priest or pastor than a software professional.  A good scrum master can reinforce your belief and faith in agile, or they can turn into a tool of oppression.  I have never been into oppression, and I want to be someone who makes a difference.  That is why I am a scrum master and why I have such high standards for the profession.

I hope this clears up any misunderstandings.

Until next time.

Monday, January 9, 2017

Continuous improvement is a scrum master job.

Development is a lot like theater
One of the greatest things about my job is that I spend numerous hours working with people.  I am learning new things on a constant basis.  I also spend time teaching others how to be better in the workplace.  It is this back and forth which keeps me going into the office.  This week I was asked about how you inspire teams to make continuous improvement.

Business professionals use sports metaphors to describe what they do.  I was never any good at sports, so I look business through the filter of music and performing arts.  I think it is a more constructive way to look at the work.  There is no scoreboard hanging over the cubicles in the office.  Business leaders are often too busy to chart out plays, and there is no playoff season or championship.  Business is an ongoing activity.

To me, the world of work resembles repertoire theater or a jazz orchestra.  Each week the company needs to put on eight shows a week with a matinee on Sunday.  The quality of the performance needs to be professional grade because people will not pay big money to see an elementary school recital.  People get sick, and performers drop out but in show business terms, “The show must go on!” If the show does not go on then, people do not get paid.  The cruel arithmetic of performing arts is that quality must be outstanding and that people must want to purchase your product.  Otherwise, you starve.

So as a Scrum Master or Agile Coach you need to look at your job as if you were a theater director or the leader of a jazz band.  Instead of being autocratic about the work, you will need to be collaborative.  You will have to get to know the people you work with and understand them as people.  Do they have children, are they single, is this their first job or do they have experience?  Do they show up for work on time?  Are they prepared?  Can they improvise and can they handle the pressure?  As coach and scrum master you need to know.

Once you understand the above, you can lay out the goals and mission of the team.  Scrum is good about this.  Each sprint has a beginning, middle, and end.  The release of working software should is like a performance.  When the curtain falls, the scrum master and the team decide how to do better job next time.

I am a big believer in the 1% principle.  Each sprint, I want to improve the performance of the team by 1%. If I have thirteen iterations in a year, the team has increased its performance by 13%.  Over a period of five years, that would be a 65% growth in efficiency.  That is the kind of return which creates pay raises and promotions.  So create small increments of improvement and meet them.  Over time, you will be amazed by the results.

Finally, Agile and Scrum can not overcome a poor work ethic, incompetence, or stupidity.  Being average is not sufficient.  As a coach or Scrum Master, it is your job to help everyone become a better team member.  People unwilling or unable to improve must go.  It is best for the individual and the team.  It is one of the hardest decisions to make.  As someone laid off multiple times, I speak from experience.  Each time I have lost a job I have bounced back and been a better developer.  Nothing focuses the mind quite like unemployment.

So look at your role as a theater director.  Get to know your people.  Collaborate with your team and hold them accountable for small improvements over time.  Finally, remove people from the team holding them back.  Being a scrum master is not easy, but it is the most rewarding job you will ever do.

Until next time.