I’m a Certified Scrum Trainer® (CST)!

After a 3 year journey, I was invited to a Scrum Alliance® TAC (Trainer Approval Community) in Vienna 2 weeks ago! The last 10 months have been intense, readying myself for this invitation. I didn’t know if I was going to get a TAC spot this year, but I prepared as though I was. No matter what happened, I knew that it was going to be a learning experience. An opportunity! If I got a spot and didn’t make it, it was also going to be a learning experience. No matter what happened, I was going to learn a whole lot – about me, my style, my knowledge, my materials…you name it. And I can safely report that this has been one of the most profound learning experiences of recent years! I am so grateful to have been given this opportunity and I decided to grab it with both hands (and feet :-)).

I worked hard for it, and I still feel privileged to have been awarded this badge (click on the badge for the certification details):

If you’re a Scrum Master, Agile coach or trainer, consider this path. It’s rewarding and there are many people along the way who are only too happy to help. In order for us to Transform the World of Work® we need more trainers. All over the world.

In Africa, we have only 4, all in South Africa. Africa is huge – there are tech hubs in many countries, large organisations who can benefit from the agile mindset. The place to start is here. At Scrum Alliance®.




To Scrum Or Not To Scrum?


When might you advise a client to apply XP, Lean or a non-Agile approach to workflow instead of Scrum?

Let me answer this question by describing an actual situation.


I once coached a programme of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This programme had been working in a waterfall manner for a year and had managed to automate a small subset of the business process.

A new CIO was employed and decided that this programme needed to implement Scrum because it would help with faster delivery. When I arrived the teams had been set up, consisting mostly of contractors from different contract houses. Project Managers were in-house and expected to be Scrum Masters as well. Teams were supposedly dedicated, but the programme manager repeatedly moved contractors in and out of the teams. The deadline had already been decided by the CIO.

It became apparent that the teams were set up for failure and that Scrum would be blamed. I thought that by focusing on Lean principles without worrying about doing Scrum right initially, it would start them thinking about improvements to their value stream and eventually lead onto adopting either Scrum or Kanban later on.


Major organisational impediments which due to the nature of the organisation (size, structure and politics) were outside of the teams’ control to resolve resulted in an interrupted value-stream, but for which they were being held accountable. Here are some of them:

  • Data sourcing – each business process was multi-layered with multiple data sources which the teams did not own nor have access to. Obtaining data required a long process with multiple approvals;
  • Environments – development, test and production environments were being built at the same time that the team needed them to do their work.

Programme-level impediments:

  • Teams were not stable – people moved in and out without notice to them and the Project Managers;
  • No Scrum Masters – Project Managers were expected to also be Scrum Masters – this created a conflict of interest and anti-patterns began to emerge;
  • Teams did not own their full value stream and yet were held accountable for delivery;
  • Each business process to be automated was 1 large story because they were not easy to break down into user value items;
  • Teams consisted of more than 10 people and had 3 Product Owners.

I recommended that teams adopt Lean principles and visualise their work, in its imperfect form, and start improving where they could because:

  • The Product Owners were present and involved – there was real effort on their part to help teams break their work down into manageable chunks taking into account the organisational impediments;
  • By visualising the workflow as it was they would start to see where all their bottlenecks were and having the teams and Product Owners focus on customer value they would begin to identify wasteful activities;
  • For me it was also important to help teams see that their current process was not value-creating, and by regularly looking for improvements they would start to look for different ways of getting around that which was seemingly outside of their control.

There are other ways of answering this question, such as using a complexity frame and the Stacey Complexity Model. As with all things that relate to coaching, the context of the organisation and the maturity of the team are important. In order to help them become unstuck I decided to start them off on this path, and bring in the learnings of complexity later. I felt that that this was, for these teams, a useful place to start.

What would you do? Please leave me a comment below.




Upcoming Talks and Workshops

I’m going to be giving a few talks and workshops over the next 3 months. Hope to see you there.

Scrum User Group of South Africa (Cape Town, South Africa) – October 2017 – Workshop: no one is as smart as all of us – rebooting collaboration. 

Learning Outcomes: Understand the characteristics of good collaboration; understand what are the favourable conditions for collaboration; gamestorm new approaches to collaboration.

Agile Personal Scrum

Personal: From Waterfall to Agile

This article was originally posted on April 20, 2013. Much has changed since then on my development and it is worthwhile reflecting back since then.

...for a long time now I've wanted to chart my Agile journey. It started 3 years ago and because I aim for continuous improvement personally and professionally, this journey will not be over any time soon.

To understand the above statement I feel I need to explain that before I fell into Agile, Scrum, to be specific, I had been a Project Manager delivering projects rather successfully using traditional or waterfall methods for 10 years already. I resisted Scrum for 3 months and when the magic started happening, despite my confused feelings about letting go and not trying to control everything all the time, I became an instant convert.