Archive for category: Coaching

Dealing with team conflict and problem solving – Drama Triangle Model

01 Apr
April 1, 2014

As a Team Coach or Scrum Master, conflict within a team is something we often have to deal with. Over the years I have come across a number of techniques that help resolve team conflict. Regardless of the technique you decide to use, its important to understand or try to see each individuals map of the world. Try to understand the position each team member is coming from, what state they are in, and how they interact with others based on the given scenario.

Drama Triangle

The Drama Triangle

Drama TriangleThe Drama Triangle is a model that will assist you, the Team Coach or Scrum Master, understand how the team member is possibly dealing with the conflict within the team or any given scenario.

The Drama Triangle is a model developed by Stephen Karpman, in which a person takes on one of three habitual psychological roles within a particular situation. It is important to note that these roles occupy positions of behaviour and not statements of identity. Also important to note that one may perform one behaviour type in one context and quite another in a different context. Kordis and Lynch have transposed the model into the following symbolic roles. The three roles are:

Read more →

Other blog Posts written by: Dillon Weyer

Tags: , , , , ,

Help me become a better ScrumMaster?

07 Oct
October 7, 2013

As a qualified and experienced Scrum Master, you are expected to help your teams solve their own problems and not solve them for them. It is far too easy to take on the role of solution hero and as a result old habits need to be overcome and new skills gained.

So how do I go about developing these skills? Experience alone might not be enough.

Scrum Sense (Peter Hundermark) and one of the most respected international Organisational Development consultants, Dr Siegfried Kaltenecker, are running a Leading Self-Organising Teams Master Class for Agile leaders and professionals on the 14-15 November 2013 in Johannesburg.

Be sure to book soon as seats are limited.

Other blog Posts written by: Dillon Weyer

Tags: , , , , , , , , , ,

Kanban and Scrum: I’m confused!

05 Aug
August 5, 2013

Scrum is huge. It is the pre-eminent Agile method by far, in use by 75% of Agile teams. It has been in existence for 20 years and its core description has been finely honed. Gartner says the majority of projects are being run using an Agile method. Jeff Sutherland reports that there are 600000 Scrum jobs advertised.

Kanban first emerged as a Lean-Agile method less than ten years ago. Five years ago it was hardly known. And yet already 24% of Agile teams claim to be using Kanban.

Why this rapid growth of Kanban adoption? Is Scrum wrong or broken?

I can offer only my own opinion…

As an Agile practitioner I have taught, mentored and coached Scrum teams for more than seven years and Kanban teams for only three, so my skills and knowledge are certainly biased. I still deeply believe that Scrum as a framework “bakes in” a wealth of good practices that support Agile principles. I believe we are still discovering how good this pattern really is as we learn more about brain science and leadership, just to name two fast-advancing knowledge areas.

Yet the Kanban method offers us some fresh practices that are especially helpful in some circumstances. So much so that I am introducing some teams directly to Kanban these days.

So what are the factors that lead me to apply Kanban over Scrum? Don’t treat this as an exhaustive list or as a “final” answer. Rather use it to have a conversation with your peers or your Agile mentor.

  • If a team is doing more reactive work than planned items, Kanban’s lack of fixed iterations may be helpful. An example is software support. But beware of separating support and development teams, as this can reinforce an us-and-them culture.
  • If your team has a mix of skills that makes it really difficult for the whole team to collaborate on items, Kanban may enable a board design that visualises this better. An example is an IT infrastructure team. But beware of reinforcing silos of knowledge and a non-collaborative mindset.
  • If your team has a mix of work types that must constantly be prioritised against one another, including both reactive and predictable work, Kanban’s classes of service may help you. An example is a single team that must field “popcorn” requests from a multitude of stakeholders that makes planning even a week or two ahead too difficult. But beware that this is not simply an excuse for a lack of discipline on the part of stakeholders…or even team members.
  • If your team’s customers would rather have a predictable turnaround time for a piece of work than have a release plan for a “project”, Kanban’s metrics may be a good fit. But beware that a Kanban board is not simple to operate effectively.
  • If your team has struggled to get Scrum to work for them, you may be tempted to deploy Kanban as a “Scrum failure pattern” (or vice versa). We see plenty of this. In the majority of cases, it hides the underlying unwillingness to take the tough and unpopular actions that are needed to overcome deep dysfunctions in the organisation. So beware of seeing Kanban or Scrum as an easy way out.
  • Lastly, Scrum has helpful mechanisms “baked in” to many of the “process” problems that teams experience. With Kanban, your team will need to install these themselves. So Kanban is not for sissies and you will need to develop a deep understanding of how to improve Lean processes.

As an Agile practitioner what should I do?

As the well-used metaphor goes, if you have only a hammer, then everything looks like a nail. So I believe it is important to add tools to your Agile toolbox. And, importantly, learn how to use them and practise their use.

So, as an experienced Scrum Master I suggest you read some books, attend Kanban training and find a team to practice your new skills with.

Remember that this is only my opinion…

Other blog Posts written by: Peter Hundermark

Tags: , , , , , , , , , , , , ,

Thinking for a living

06 Mar
March 6, 2013

If you think for a living then you are a knowledge worker. And I will argue here that any investment you make in learning Lean-Agile methods will be the best investment you can make for your career. It is also the best investment your organisation can make in ensuring business sustainability in the long-term.

In August 2012 Gartner signalled the death knell of Waterfall. The world has finally woken up to the simple fact that predictive methods are unhelpful for managing knowledge work. All the evidence over the last two decades points to some form of Lean-Agile empirical method as the only sensible way forward for managing knowledge work. In fact Gartner, perhaps optimistically, predicts that 80% of software development teams in 2013 will use some form of Agile method!

Kanban and Scrum are the pre-eminent Lean-Agile methods for managing the work. Of course workers need additional good practices for executing their specific skill or craft. For example, modern software developers will apply Extreme Programming (XP) practices.

Scrum famously has its genesis in the work of two Japanese researchers into Knowledge Management, published in Harvard Business Review in 1986. Jeff Sutherland applied their finding in a software team in 1993. He worked with Ken Schwaber and others to formalise Scrum during the coming years. There are hundreds of thousands of people with formal Scrum training and millions practising it.

Much more recently, from 2004, David Anderson evolved work he was doing with the Theory of Constraints to emerge the Kanban method. Other leaders have contributed to a fast-growing body of knowledge. By 2012 there were many books and international conferences on the topic and the practice of Kanban is exploding.

The latest worldwide Agile survey places Scrum and Scrum hybrids (most commonly Scrum + XP) first with 66% of the Agile market and Kanban second with 24%.

The term Lean was coined in 1988 to describe the Toyota Production System. For our purposes Lean Product Development and Lean Leadership are the most important applications. The name Agile derives from the Agile Manifesto in 2001, to which the Scrum founders were signatories. In some circles there is much rhetoric about whether Scrum is Lean or whether Kanban is Agile. My simple response is “who cares?”.

How do we make sense of this? What are the essential similarities and differences between Scrum and Kanban? And where should we use which method? As usual, there is an abundance of (mis)information and not enough clarity. Let’s start with a few obvious problem scenarios.

Many organisations that attempt to ‘do’ Scrum are not actually willing to make the adjustments to their ways of working, ways of managing and company culture that are needed to realise the hoped-for benefits. Scrum is not the silver bullet they hoped for. So some look for the next shiny thing…and discover Kanban. By now, a number of these organisations have also dumped Kanban in search of something easier. And some have gone back to Scrum.

Some organisations are trying to use Scrum to manage work that is really not complex, sometimes repetitive and whose arrival rate is highly variable. Such work is not conducive to being planned in week- to month-long fixed increments. It is more suited to being managed using clear policies and SLA’s. Kanban is likely a better fit here.

Not all situations are so obvious, though. It’s tempting to say something like “Scrum is best for work that can be planned and Kanban is best for work that can’t”. However this is a dangerous over-simplification. The difference in culture between one organisation and another may be a better indicator of the appropriate process to choose. A good starting point to seek guidance is Henrik Kniberg and Mattias Skarin’s free mini-book.

My core message is this: 1) In the world of software development the traditional methods of managing work belong with the dinosaurs. 2) If you want to be equipped to make good decisions in the future Lean-Agile world you need to educate yourself in both Scrum and Kanban. 3) You will quickly discover that you need to develop your so-called “soft” skills and learn how to manage the inevitable organisational change.

 

Other blog Posts written by: Peter Hundermark

Tags: , , , , , , ,

Kanban and Scrum

06 Feb
February 6, 2013

In August last year Gartner signalled the death knell of Waterfall. All the evidence over the last 25 years points to some form of Lean-Agile method as the only sensible way forward for managing knowledge work. Kanban and Scrum (together with eXtreme Programming) are the pre-eminent Lean-Agile methods. I would argue that any investment you make in learning these will be the best investment you can make for your career and also the best investment your organisation can make in ensuring business sustainability in the long-term.

You might think it strange that a company named Scrum Sense would talk about Kanban. The truth is that Kanban was a baby in diapers when Scrum Sense started, while Scrum was already the de facto standard in the Agile world. When Maritza van den Heuvel approached me in November 2009 about the possibility of hosting David Anderson in Cape Town I jumped at the opportunity. He visited early in 2010 and we had a great time exploring this new process with him. We learned a lot and I’m tempted to say that we also helped clear up some mis-conceptions about Scrum.

Three years have passed and Kanban now has a significant presence in the Lean-Agile world. The latest worldwide Agile survey places Scrum and Scrum hybrids (most commonly Scrum + XP) first with 66% of the Agile market and Kanban second with 24%. Impressive growth in just about 5 years. Why is this?

As usual, there are some good and some bad reasons. Let’s start with the bad. Many organisations that attempt to ‘do’ Scrum are not actually willing to make the adjustments to their ways of working, ways of managing and company culture that are needed to realise the hoped-for benefits. Scrum is not the silver bullet they hoped for. So some look for the next shiny thing…and discover Kanban. By now, a number of these organisations have also dumped Kanban in search of something easier. One client of mine who did this has largely gone back to Scrum.

There are good reasons too. I see organisations trying to use Scrum to manage work that is really not complex, sometimes repetitive and whose arrival rate is highly variable. Not conducive to being planned in week- to month-long fixed increments. Much more suited to being handled using clear policies and SLA’s.

By now you are asking yourself what the differences are between these to Lean-Agile methods, and where to use what. This is, naturally, a non-trivial question. A good starting point to seek answers is Henrik Kniberg and Mattias Skarin’s free mini-book.

My message is this: if you want to be equipped to make good decisions in the future Lean-Agile world you need to educate yourself in both Scrum and Kanban. And along the way you will realise that you need to develop your so-called “soft” skills and learn how to manage organisational change too. This is why Scrum Sense offers introductory training, advanced training, master classes and consulting that cover Kanban, Scrum and Leadership.

 

Other blog Posts written by: Peter Hundermark

Tags: , , , , ,