Recently I sat in on Edwin Dando’s Professional Scrum Master course as part of my journey towards certifying as a Professional Scrum Trainer.  In the course, he kept mentioning different scenarios and normally it followed with a “Yes, it sucks to be you!” and then by “So what are you going to do to change it?”

This totally resonated well with me as it is the essence of agility in that its about inspection and then adaptation.   More importantly as a scrum master, this is about empowering a team to be self-organising and getting them to take control of the situation themselves. 

A team, company or individual that is just complaining about something and not doing anything about it deserves to be told “Yes, it sucks to be you!”.  It simply acknowledges their reality and making the reality harsh. As a coach, you are then empowering them to do something about it by saying “So what are you going to do to change it?”.  This simply highlighting self-organisation is needed.

Edwin, a big thank you.  I now have a new favourite phrase … “It sucks to be you!”

If you are planning to go through your Professional Scrum Master I certification, you may come across a question :

Is a Scrum Master a management role?
a) True
b) False

The answer is a) True.

I admit, the first time I saw this question I immediately said False.  In a recent discussion on LinkedIn the topic came up and there has been some furious debate around the role from many smart and experienced people.

Why there a tendency to say the Scrum master is not a manager

This is very simple, its the stigma and baggage that many people associate with a manager.  In hindsight, many Taylorism principles have been applied to software development and it has failed badly.  Many professionals have been burnt over the years and on several projects leaving deep scars of resentment to management involvement.

We have all intuitively known that the command-and-control, gated development has not worked whilst living through the pains.  Yet we complied with it as this was the “corporate governance” the organisation had adopted.  Traditional and Taylorism style managers have failed us badly and slowed progress.

The second instinct to say the Scrum Master is not a manager is that we encourage teams to be self-organising, meaning they manage themselves and thus the scrum master is not a manager.

Breaking the Stigma

As an agile community we need to learn to inspect and adapt and change things that are wrong.  The first thing we need to do is to break the stigma attached to managers in software development. 

Here is a definition of manager

man·ag·er

noun

1. a person who has control or direction of an institution, business, etc., or of a part, division, or phase of it.

2. a person who manages: the manager of our track team.

What a Scrum Master is a manager of

Scrum Adoption - A Scrum Master is different type of manager, not that of managing people but instead managing change within the organisation to adopt scrum.  They should have the authority to implement Scrum and thus be accountable to successfully implement it.  The Scrum Master needs to be able to take actions that will help the organisation successfully adopt scrum.

Blocks – Teams often experience blocks they are not able to resolve themselves.  A manager with the authority to approach other teams, departments to resolve the block is needed.  Giving the scrum master the authority to do this helps him/her manage blocks and get them removed.

Team – Helping a team learn to be self-organising and thus self managing does take a management, that is of process change management.  There is a subtle but true fact,  I the scrum master is not a manager, they cannot give the team accountability to manage as it is not theirs to give.  A manager, with the authority to instruct the team to self-manage is taken more seriously,  the team sees it as “the boss is telling me to self manage” rather than “a colleague is telling me to self manage”.  There-in is the a common problem in most teams.

Fail Safe – The scrum master needs to be able to create a real fail safe environment where the team knows they can safely fail without a boss complaining.  If the scrum master is a manager, the team immediately know it is safe.  This encourages the right behaviours in a team.

Inspection and Adaption – As a manager will be able to help the team adapt.  Both team and manager have the authority to make the changes needed to improve process. 

Training and Coaching –  As a manager the scrum master will be able to identify skill and career path opportunities for the individuals and thus the authority help with skills development of the team through training and coaching.

Why is it important to be a manager

Sadly many Scrum Masters are put into the position and are left helpless as they have the responsibility, but there is no authority bring about the change.  Every action is questioned and debated and takes time to resolve.  This only impedes the scrum process and introduces high risk that the Scrum will not be adopted correctly.

The Scrum Master is a new servant/leader type manager that does not follow traditional management practices.   All the tasks the scrum master does is a form of management, that of managing a team.  What may change over time is their involvement in a team, especially as the team becomes more self-organising, yet they are still there to help the team keep aligned with the business goals.

Help bring about this change, and empower scrum masters to have the authority to manage the organisation to correctly adopt the practice.

A Scrum Master without authority, has no authority to give.

- Brett Maytom

If you are battling to get teams to think relatively, think of bringing in four different size buckets.  Ask the team to throw each requirement (card) in one of the buckets based on what they think.

Using this technique you reemphasise consistency in sizing rather than accuracy.   I also leave some old requirements in the bucket to remind the team about the relative nature and if there is debate, I pull out an old card and say “Is this new card bigger or smaller than old card”

When items land in the XL bucket, it simply means its too big for this round and they need to be decomposed a bit more.

I enjoy talking to lots of people and I often here of situations where a company has stopped using Agile or Scrum as it has “failed”.   I also hear things similar to “Agile is a bad word for us” or “please don’t use the A word”.

As with human nature, it is easy to shift blame instead of taking control of the situation and making it better. Too often it is easier to give in and be the victim instead of being the Super Star.   The root cause of this is simple fear.  Most of us are working for a salary and just surviving with several financial responsibilities.   When something goes wrong, ones self preservation and survival instincts kicks in as the consequence of admitting failure will be personally great.  Being a victim may result in a tongue lashing from management, but that’s it.

The simple fact is that software development is exceptionally hard and fraught with challenges which are unpredictable.  The only guaranteed fact with any development project is that there are going to be challenges, you don’t know how many or how big they will be.

Software development is an applied science where we have practices to solve both business and technical challenges.  A good management team acknowledges this fact and adjusts to manage the risk.   Scrum practices are geared to managing this type of risk with some core principles that need to be met. 

Scrum follows an empirical process control model where events that are unpredictable or poorly defined are frequently inspected and adaptations are made to respond to the changes.  In scrum there are frequent inspections giving the team and management the opportunity to inspect the situation and make adjustments to prevent failure.  These inspections are in the form of sprint planning, daily scrums, sprint review sprint retrospective and the backlog grooming process.

A challenge only becomes an obstacle when you bow to it.
― Ray Davis

The next philosophy of Scrum is transparency.  Its the ability for a team to be transparent about the challenges as well as the pressures the team find themselves in.  By being transparent, this allows the team to make others aware of the problems and manage expectations.  As an industry we deal with professionals and challenging news early; is far better as it allows for people to rectify the situation.  This is what “agility” is – the ability to adapt in changing situations.

Change is a process, not an event.
― Dani Pardo

The last is that of dealing and allowing for failure.  A team must be allowed to fail without the fear of loosing their jobs.  When failure occurs, the goal is to allow failure early as small failures can be corrected early without devastating impact.  If the failure were catastrophic, its better to fail early instead of late with wasting a lot of money.  There is hard evidence through reports such as the Chaos Report by the Standish Group that failure and challenges happen,  these need to be accepted and risk managed.  Scrum does this by encouraging fail safe environments where early failure inspected, made transparent and adaptation made to correct or terminate the work.

Failure is only the opportunity to begin again more intelligently.
― Henry Ford

When I hear “Agile failed”,  I immediately know the team is not inspecting and adapting.  Its not agile that is failing, but a problem lies with the culture, attitudes or understand of agility by the people involved.

I often meet new teams as well as people at user groups; inevitably after some discussion there are a few that have lots of bad things to say about their work environments. 

I am fortunate to be in a position where my exposure to different team and company dynamics is big and I get to see good, bad and outright ugly practices. 

The one topic where emotions run high is where individuals forget about the roles and responsibilities of the organisation, executives and the professionals employed to do the work.

Many professionals see organisational dysfunction and practices that could improve the dysfunction, yet the organisation does not change.  This leads to disgruntled team members. 

In this post I would like to set and discuss the work contract and use this as a starting point to to clarify some misunderstandings.

Meet Matthew

Matthew is hired as a developer in the team to build a web site for his company.  He has strong skills to do the work which prompted the company to build the site.   The company has also employed Sue to implement Scrum, she is the scrum master.  In some meetings the team (including business) decided on the Definition of Done and quality standards to meet.

When developing, Matthew chooses work on the wall that he likes doing as he prefers working on the web user interface and not backend work.  When asked to do backend work, Matthew complains and resists and takes shortcuts; he adds a few unit tests, his documentation is there but not of a high standard.

Matthew also constantly complains about attending sprint planning, retrospectives, scrums and reviews and feels it is a waste of time.  He feels he is capable of doing the work and that such meetings are pointless for him.

Matthew is also constantly challenging the business about how the build software and what features they are building and feels that most of it is a waste of his time.

Do you have a Matthew (or are one)? 

“Matthew, It sucks to be you!”

So as a professional you took up employment with your organisation to fulfil a role, in your negotiations you were interviewed and the type of work outlined.  You most probably agreed to the type of work you will do and signed some contract with your job description.  You agreed to sell your professional skills for a pay check at the end of each month.

You sold your sole to the the devil!  Well, hopefully not too bad of a company and the good thing this contract can be terminated. 

This contract is pretty simple and Matthew needs to get this:

The company tells you what to do, in what order to do it and when to do it.  Matthew, you don’t have a choice here and it is not your call to make.  The company has bought your time and can pretty much do anything they want with your time.  Legally, if the work is in line with your job description you have no leg to stand on.

So

• If the company gives you an order of work, you have to do it in that order.
• If you are requested to attend meetings and contribute, tough you are paid to do that.
• You can advise business on better processes and practices, but it is not your call to make.
• You need to be a professional and accept that you are paid to do the work, get on with the job and do it to your best ability.  If you are going to take shortcuts; I am sorry to tell you that you are not a professional.

Sorry mate, suck it up or start your own business where you can make the decisions.

For some time I have been preoccupied with trying to compare what the software development industry is similar to and have had some interesting discussions with colleagues.  There are many articles on why it is not like engineering and why it is not a science. 

Engineering has been around for thousands of years and the mechanics are well understood, albeit complex.  We understand physics, motion, mechanics, structuring and have proven formulas to solve problems.  Building engineering solutions are somewhat easier as the problem and solution are well understood.

If software development were a science the we would have strict processes and practices in place.  We cannot seem to even agree to these practices and process, but I would agree there are many scientific principles that are applied.  I would also say that software development is not a pure science, but rather an applied science.

As a industry we are in the game of manufacturing software and build a product that we ship at the end of the day.  But we are unlike manufacturing as they have a proven recipe that they put on a production line to create a large volume of the same product.  We are more similar to the Research and Development division of these manufacturing companies that are building and improving their first prototype and coming up with the correct recipe.  But unlike the manufacturing industry, our effort to mass produce the product and give it to the consumer is much less.

In the past we have failed and looking at it in a new light

As an industry I would say we have it horribly wrong; the Standish Group’s chaos report shows 68% of projects fail or are challenged. If you were an investing person, would you put your money into a venture where there is only a 32% of it going well?

Being in the consulting game, I get to see many different projects and different companies around the world.  I am shocked at how few are working well and smoothly with everyone being happy. 

In the past 5 years, I have observed it getting better especially where teams have thrown out waterfall and start using some agile practice.  Yet, there are still many challenges faced by many teams as the practice not mature and still evolving.

We are similar the health industry

I say the medical industry as it is more of an applied science.  There are many scientific practices and patters, but there is still a lot of uncertainty and empirical practices.

Doctors and Surgeons have studied our anatomy and learnt techniques to deal with known problems.  They have also learnt skills to analyse a patients problem through a process of elimination.  They eventually come up with a prognosis using their best judgement. 

We too have learnt software patterns, practices and technologies and apply these skills to new problems.  In many cases we go through a process of elimination on what the best approach or technology is.  We come up with a solution that we think will best solve the requirement.

Software Development is a practice

Many doctors rooms are called a “practice” as this is where they practice their discipline of resolving problems through elimination.  More often than not they get it right the first time, but there is still a significant amount of patients that they work on a trial-an-error basis.  This is an applied science going through the process of elimination.

Software development could be said to be a practice too and not dissimilar to the medical industry.  We are presented with a requirement that is a bit ambiguous, similar to how a patient will describe the complaint.  We would analyse the requirement and using our tools, frameworks, patterns and experience we would come up with an approach to deal with the problem.  We will choose the path through a process of elimination

As with the medical industry, they don’t get it right every time and go through a process of elimination to come to a solution. Sometimes the get it wrong and complicate the problem more and then they have failures too.  We too solve problems through a process of elimination.  We attempt to solve the problem and also have varying degrees of success and failure.

As a software industry we have come a long way in a very short time unlike the medical industry that has been around since the beginning of mankind.  As a new industry we are still trying to find our feet and establish practices.

We have had some great ideas and some rather bad ones.   I think the biggest failure in the software industry is our practice of managing work.  We have tried to manage software development as if it were an engineering practice or

Try run a hospital in a waterfall manner

In waterfall we need to come up with a project plan to manufacture a product.  Can you imagine being asked to set up a project plan for the running of a hospital (with an emergency room) over the next year.  Also to treat running the management of the hospital as if it were a production line in a manufacturing concern.

Lets complicate it with the need to know up front what patients are going to come in so you manage resources, what you are going to be doing and how much it is going to cost.

Just like a hospital, we know we are going to get requirements coming in and that we have the skill to deal with each.  We also know that some are going to be easy and others are going to take significant more effort.  The greater majority of requirements will be done, but there will be a bit of trial and error and possibly a few potential disasters along the way. 

You never know what you’re going to get!