I am a Scrum Master. What now?

-->

My Way to Scrum Master Certification

Why become a Scrum Master?

When you work as management consultant in areas such as Operations Excellence and Process Improvement, the interface to IT becomes more and more prevalent. In my last project at the German Stock Exchange this trend has finally reached me, someone who was never really overly interested in software development or anything that had something to do with IT.

At the stock exchange we improved processes, hence SAP workflows had to be changed and all sorts of other IT systems that were affected by them. After having sorted those processes, I got in touch with IT and told them about our desire to “add things” to the SAP environment and they gave me a change request form to fill in. A change request form – I have never seen anything like this.  

This was a very useful experience for me, as I realised that whatever we wanted from an operations point of view needed proper translation into “IT speak”. It’s literally like translating from one language to another. It gave me an insight into the minds of programmers and how they see the world. It is very structured, but also very different.

The rest of the project remained very IT focused. I had to deal with more change requests and also with testing and finally implementing our solutions. I realised that I am actually interested in this kind of work; not so much in programming, but being the (translating) link between Operations and IT.

One day, the German Stock Exchange had an internal training session about the Scrum methodology and I happened to take part. I realised that this was something I was interested in and put it on the backburner. About one year later or so I finally became a Scrum Master.

What Kind of Training is available?

I had a look to see what’s out there in the market. Ideally, I wanted something cheap and quick where I could do everything from home; or maybe some course in and around London.

Classroom based courses are usually around 2 full days and cost anything in excess of GBP 1000. Some of them had no certification attached, just lectures. Online courses were less expensive and usually around GBP 800. All prices were net, without VAT. So basically, when not having a big corporation behind, it is quite an investment with a certain degree of risk involved, as one doesn’t know what one gets.

I got in touch with one training organisation that offered lots of degrees and courses. I got the sales person on the phone and she offered me an online course for GBP 795 plus VAT. Six weeks later I negotiated her down quite a bit. Bingo, when she quoted a new and acceptable price, I agreed and the day after I started my online seminar.

The course was very good and basically a narrated slide show, with questions in between and quizzes at the end of each module. I cannot complain, it was all done very professionally. It took me 2 days to go through the training. But mind you, I have been a project manager and management consultant for 20 years and this was not something overly new, hence I did not need too much time to think things through.

As advice I can only say, negotiate a training package; and if you have time, like I had, take this time to get into the better negotiating position. Time works for you!

Training Contents

The training was delivered in 3 modules. The first module was about the history of Scrum within Agile, the second module taught Scrum as a methodology, and the third module was the Scrum methodology applied.

What was interesting for me, scrum is quite rigid in its application (i.e. daily meetings, regular review meetings, strict roles and responsibilities for all people involved, charts, etc) but also quite flexible, because the outcome of the project is not fixed at the beginning (like when using the waterfall methodology). And especially me, who has grown up in ‘waterfall’ this was a really great insight and I can see how and that it works. So yes, I am all bought in.

I am not going to say more about training contents, as the Internet is full with this information.

Exam and Certification

I passed the exam easily and am now holding my certificate as Scrum Master. I am proud of that. But I am also happy that I did not pay the full price for it, as this would have been a rip off for a 2-day online course.

The exam consisted of (I think) 35 questions and one needed 24 to pass. I was somewhere in the 30ies. Questions were multiple choice, sometimes tricky, but generally very fair.

Lessons Learned

My first thoughts after having completed were: I’ve unknowingly already been a Scrum Master. Of course I learned something new, as described above, but I have used major parts of the scrum methodology throughout all my professional life.

When managing projects I always have short daily review meetings with the same agenda as a daily scrum meeting. I also implement those daily review meetings with my clients as part of Lean Management when on any Operations Excellence project.

The Sprint methodology is also not new. I call it Gate Management and is more or less similar. One can only pass from gate to gate after having successfully completed all tasks. One difference is, sprints are generally of the same time period, whereas gates can be more flexible.

I have used something similar to a burn down chart at my first project as management consultant back in 1997 when measuring achievements and savings in a purchasing department in Switzerland.

As project manager I usually take on tasks from and for my consultants to help them achieve their targets and deadlines. I also coach them regularly and train them in consulting methods.

But then, what’s new is the fact that I know now why waterfall doesn’t work. I also learned the benefits of self-organising teams and many other principles of Scrum and Agile. I am looking forward to my first experience of fully using Scrum as methodology.

How to go forward

So where does this leave me now? The day after I got certified I went online in order to look for Scrum Master projects. There are actually quite a lot. But as usual, there are problems; in fact there are two:

1) Everyone wants a scrum master with tons of completed IT projects; and obviously my projects only ever touched IT.

2) Everyone wants an IT expert who understands programming, etc; and obviously my background is not IT.

But then, I do feel it was good to have this new competency. I remember when I became a Six Sigma Black Belt I did not have an immediate Six Sigma project either and it will probably be similar this time and pay back over time.

Also, I want to specialise as “translator” from business/operations to IT and lead a Scrum Team from that side of the coin. I do feel this is a good niche to start from. The only thing it takes now it to look around and have a bit of luck.

Case Study: Customer Service Centre

The Case Study

The director of the Customer Services Division of a bank asked for help. In the invoicing department of his middle office he is facing several problems which he would like to get solved. The invoicing manager of the area doesn’t see any fault in himself. Everything is always fine when asked about problems or how the area is performing; in fact, his standard message is: “We always manage our workload”. Upper Management heard that customer satisfaction went down quite a lot recently and would want to get a grip of it.

Invoices are produced monthly, always towards the end of the month. The manager says this is important so they can all focus, even though some invoices don’t need to be dealt with that way. Staff is highly specialised in their work streams of producing invoices. Their responsibilities reach from creating LANFs, printing and sending of invoices, customer services in regards to invoicing, dunning.

The team is scattered across various locations, which is the reason why the manager installed a monthly meeting. The meeting is scheduled for 2 hours and every participant reports what he or she did and what the issues were. The team consists of 15 people.

The director is only on site once a month for 2 or 3 days. He has heard that there seems to be a problem with invoices, but he can’t prove anything. The site director is there daily, but doesn’t have a lot of time for the invoicing manager. He thinks the latter is long enough in the company to be able to manage the workload without big interrogation.

When asking the employees, their main problem seems to be the impossibility to go on holidays as there is no one around to cover for them. Their sickness rate seems higher than usual, also staff turnover. Employees range across all ages and seniority. Their interfaces are usually customers, the operations team for whose services they produce the invoices, the sales department, IT, and other specialist areas.

When looking at their Explorer environment, it seems a total mess. Procedures are everywhere and nowhere, and various versions float around erratically, if there are procedures at all.  

The director wants you to make his life easier and come up with a Six Sigma project.


----------------------------------------------------------------------

The DMAIC Cycle

Six Sigma Projects follow this cycle. The letters mean and show phases of the project: Define, Measure, Analyse, Improve/Implement, Control/Follow-up. Personally, I don't like the terms Improve and Control, so I came up with my own. I have run a similar project and changed the case study to a degree to keep matters confidential.


Define

In the definition phase I'd look what the key themes are, the headlines of work streams that would go on a project plan. In that phase the project structure would also be decided upon - project manager, team members, steering committee, meetings, risk analysis, ...; a project charter would be written. 

The themes from this case study are pretty classical. The major one is Operations Excellence and particular work areas seem to be invoice cycles and planning, flexibility of staff, processes and interfaces, meeting structures, KPIs. Other themes are management coaching, the organisation (locations and team structures), and Customer Service Satisfaction. All in all, it is mainly an Operations Excellence project.  


Measure

2 things need to be measured - project success and operational performance. They don't necessarily mutually exclude one another, but in theory it can be said that the latter measurements are for and will continue after the project. 

What would be interesting to know and have measures about may be the following:
- Amount of invoices per invoice cycle
- How many kind of different invoice types there are (and whether they are comparable in terms of effort to produce)
- Customer service satisfaction data and how it is compiled
- Worked hours of the invoicing team, with over-time.
- Outstanding dunning items (receivables)
- Customer queries: the amount per day, worked hours, also query types
- Staff sickness rates
- Error rates of invoices (pre- and post-sending to customers)
- current KPIs to see what is already regularly measured
- etc.


Analyse

In the analysis phase it would be good to get some thorough data analysis from the measurement phase (above). It helps to understand the nature of the business and also hopefully shows patterns of seasonality, peaks and troughs, etc. 

Further or analysis would be:
- Processes. It would be good to understand the invoicing process(-es), how those LANFs are created, till they are sent to the customer. This includes interfaces to other departments. 
- Management training records. It is important to see what the managers and directors already know and whether they apply their knowledge. There might be a confidentiality problem with HR, but management can be asked directly what kind of training they have received.
- Staff training records. There seem to be flexibility problems with staff filling in for one another.
- Meetings. Joining operational meetings and see how they are conducted and whether they are any effective and efficient.
- Customer Satisfaction. Root cause analysis on customer queries. Maybe customer interviews.
- Organisational effectiveness. Analyse locations and communication between teams of the current organisation
- Work procedures. How are they written, if at all. 
- IT infrastructure. What IT systems and how well they are installed. 


Improve/Implement

It is difficult to predict what exactly will be implemented. But the following can be said:

- Balanced Scorecard to include measurements of customer service, staff flexibility and satisfaction, financials and processes. This is especially interesting because the department seems to have problems in the first 2 areas. The other 2 are pretty standard.
- Flexibility Matrix of staff. Cross-training of staff and making the more flexible to cover themselves. 
- Standardised and efficient invoicing processes, including all interfaces. Also dunning processes. This has the potential for big change requests in the IT infrastructure, which needs extra time to implement usually. 
- Writing procedures for those processes that can be used as training manuals for new or existing staff.
- Management coaching.
- Create smaller teams, maybe manage to move teams together into one location.
- Implement efficient and effective daily or weekly planning and review meetings with action plan and KPIs.


Control/Follow-up

The follow-up phase is very essential, as in this one all implemented improvements will be fine-tuned and more important, behaviours aligned. This phase is one of intensive coaching. It must be ensured that staff and management are not falling back into old behaviours. Audits will be undertaken, not only by consultants but also by staff and management; these are so-called compliance tours. 

Feed your Monster - How to conduct successful client meetings

Currently, I am tasked to work on 14 projects within a PMO environment within my client´s organisation. And it reminds me again that there are a few things which are vital for any consultant – be structured, prepare your meetings, and work on your tasks efficiently and effectively.

The use of “we” and “us”

First of all, whenever a consultant speaks he should speak in “pluralis majestatis” – the “we”. “We have created..., we have achieved..., we have worked on..., we have managed...!” It should emphasise that consultants work as a team and we do things together. Ramobs are no consultants!

Client Meetings or “How to feed your Monster”

Whenever you meet your client you need to “feed him”; this is mainly with information and to help him with decisions he has to make. Apart from the odd morning tour where a simple “How are you?” suffices, usually one should never go empty handed or without any reason to the client. Never!

So, before seeing him, prepare your meetings:
- What do you want to get out of the meeting?
- What information do you want to give him?
- What decisions do you want to be made?
- In case you need a decision, what options do you give him from which he can make a decision (do not come empty, always give him options to choose from!)?
- How do you respond to any of his potential objections?

Once the meeting has started, shut up and listen, listen, listen. Oh yes, and listen! You should not talk, the client should. Always listen to what he says. Successful consultants have good listening skills. Do not talk too much, do not always repeat what you said, and do not fall into the trap to try and educate your client. If he wants coaching he will say so. Otherwise, treat him with respect and the way you want to be treated. Look at your client´s body language and read it. You will see when he gets bored, impatient, relaxed, excited, agitated, etc, and manage it. Never forget, opposite you is your monster and you need to feed it. Your client is your tamagochi. You are in control. 

When you attend a client meeting with a colleague the golden rule is – if you talk your colleague shuts up, and when your colleague talks you shut up. Give feedback afterwards, but do not correct your colleague during a meeting (unless he makes the worst ever blunder!) and always act as a team. When the consultant asks a question to the client the other consultant should not answer! Often, questions are of a sheer tactical nature. Oh yes, and do no forget the pluralis majestatis even if you alone did something.

When the meeting comes to an end, summarise! Tell the client what decisions have been made during the meeting and which actions are coming out of it. After the meeting, either do those actions straight away or write them down on an action plan and work on them systematically.

And that is it! Sounds simple, is sometimes not so simple, but it is the only way forward!

Technocratic Thinking about Behaviour Change

It seems that my behaviour change entry sparked off the most interest from what I can see in the Google statistics about my blog. Reason enough to elaborate a little bit about the fact that behaviour change is not some mufty-flufty stuff, but has to be taken seriously when being in the process of change. 


Whenever I want to write down an actual process in a company which is ISO certified I get the remark "Hold on, I will bring the ISO files". I would then reply, "There is no need for that, as I want the real process, not the written down one" and with that remark I usually bump into a brick wall, which in return, I will bring to fall most of the time. 


There is this perception out there, especially amongst people who believe in structure, process, order and organisation (let me call them technocrats) that once a process is written down and communicated it is also lived and effective! I am afraid to say, but this is the biggest reason for downfall after major change projects. 


In the very most cases I can prove that real processes are almost always different from ISO ones, especially when processes and steps in those processes are depending on people rather than machines. This means, a process "manufacturing steps of a metal tool" is more likely to be ISO-true than a process "the daily planning and review meeting". The first is a mechanical process with lots of machine and computer based activities, the latter is solely depending on people's behaviours. 


So, why do particularly people based processes vary so greatly from the agreed ones which one can find in ISO books and any other official process documents? The reason is that behaviour change did not take place! 


Let's refer back to the "daily planning and review meeting"; I am sure, when it was installed, an agenda has been designed, a room planned, the participants chosen, and the chairperson has also agreed on running the show. "Fine", we think (we as in technocrats or junior consultants like me back in the 90s then), "they all agreed, we explained the layout of the meeting, it should run smoothly. And in the end, it is a very simple tool in the management system anyway; it's only a meeting". 


But what one forgets when doing so is:
- Have the chairperson and participants bought into the meeting?
- Did we train the chairperson in running an effective and efficient review meeting? 
- Have we ensured the agenda is widely understood?
- Is the chairperson able to confront all participants in case they miss deadlines?
- Has the meeting time and location been agreed and communicated?
- etc, etc, etc....


Whenever a new process is installed, it needs following up! This is mostly forgotten. Whenever people are involved, one needs to ask oneself whether they have received sufficient training and coaching in performing these tasks, even if those are only basic ones. Regular follow-up after sufficient training is also important. Think about the 3 phases of learning (please look it up again on my previous blog about behaviour change), mechanical compliance is by far a stage in the process of change a company wants to find itself in. 


And now sit back, take out your ISO book and review its contents! Have fun! 

When does Behaviour Change finally occur?

I know, I wanted to talk more about KPIs, but yesterday my client asked me this question about behaviour change and I think it is rather important to elaborate a little bit on that. 


When I started my career back in 1997 with Impac there was a rule when doing area development in any department or area - time to installation of a new management system (or tool) is about 10 weeks. Apparently, so we were told, the University of Chicago researched that it normally takes that long till human beings adapt and change their behaviour. I still follow this rule of thumb - 10 weeks to installation. These 10 weeks include 2 steps, analysis and development. 


From my experience though, behaviour change takes much longer. Well, it depends what kind of behaviour change we are talking about. There are 3 phases of learning and learning in my profession means changing behaviour. 


The first phase is called MECHANICAL COMPLIANCE.
Say, during a project we analysed that review meetings are not held, hence daily results can neither be talked about nor any corrective actions taken. So, after talking to managers and supervisors, drawing up an agenda for such a meeting, giving them a bit of training, we have the first review meeting. The manager and his supervisor do this every day, but people only attend because they were being told to do so. The meetings are not very good initially and actions not yet taken. This is mechanical compliance - doing so because of being told to do so. A characteristic of this phase - in case the meeting would be stopped people would not miss it and be happy to get on with life without it. 


Of course, daily review meetings are important, especially for a learning organisation. This is the forum to talk about achievement of the plan and in case the plan was not met, corrective action would have to be taken. Obviously, the meeting in my example would go on. People would attend for a few weeks, and slowly, the first actions would come up. Problems are being solved. Attendants of the meeting realise the benefit of having a structured approach to managing their area and deal with their problems. This phase is called COMPREHENSION. People understand why something (in my example the meeting) has been installed and how they can benefit from it. In case the meeting was cancelled, people would miss it and ask for continuation. The difference to mechanical compliance is that there is a very small risk of falling back into old behaviours. From phase 1 to phase 2 really takes about 2 to 3 months. 


But that's not enough. With comprehension alone there will not be any continuous improvement. Phase 3 is called FURTHER DEVELOPMENT. That's the phase where people take real ownership and develop something further. In my example about the review meeting participants would probably realise that a certain person from the organisation is missing and be invited to attend, the agenda could be changed, the meeting could be held at a different time, certain reports would be needed, etc.... 


Once that stage is reached "real" behaviour change will have taken place. This normally takes a few months. 

Just a few pics of Anne-Laure, Javier, and myself in the project room.

That's Peter and I in front of the posters which we developed for the effective and efficient meeting initiative.

Nissan, the Team

We had one task force from Nissan during the 2 projects, Peter B (picture above). He was a very good guy and lived in Northamtpon. He knew the company pretty well and helped us installing our new management tools rather swiftly.

In the first project my consultant was Anne-Laure, and in the second one Javier.

Each project lasted for about 4 months.

The main issue was, Nissan was riddled with "cultural differences". There were the Spanish employees in the 2 sites in Spain, the British ones in Milton Keynes, and there were myriads of Japanese employees who were in Europe for a certain amount of time and also included in the project.

I do remember problems with the Japanese. They were language barriers and also no interest at all in any European project, as they were all very focused on directives from Japan.

Nissan Research and Development

One of my last projects with Proudfoot was the one at Nissan R&D in the UK, but with further 2 locations in Spain.

The project was about raising personal efficiencies of R&D directors, and in a second follow-up project a similar approach was rolled down to the supervisors.

The core product was to eliminate non-value added time and add more creativity to the European R&D department.

We did that through coaching, implementing a new "efficient meeting format" and e-mail etiquette. Each meeting was to be fedback and coaching to the chairmen given. The new e-mail formats ensured unity in writing e-mail across the European sites.

In special vision workshops we introduced them to the idea of new creativity at the workplace.

Management Training

Management Training goes along with the operational installation. The main responsibility of training is to ensure "behaviour change" and that all installed new systems and tools are being used properly and that management does not fall back into old behaviours. Training is never ever there just for the sake of delivering training!

There are a few topics which are mostly on the training schedule (more detail in a later entry):
- What are management systems,
- Openness to change and the "curve of change",
- Efficient meetings,
- Confrontation skills,
- Effective Communication, and a few more.

Other topics are very specific and need to be tailor-made for the client. They would normally be in line with the area development.

Between training sessions are always coaching sessions where trainer and client work on the client's personal progress throughout the project installation phase and his behaviour change.

After my first project, the ice-cream one, I decided to go into training and was sent off to the corporate headquarters in Florida on a 3 weeks intensive course.