Inevitably Agile

somethings are just inevitable …

Tag Archives: agile

Evaluate yourself : Scrum Master Shu Ha Ri Test

This post is the last in a series on the Growth Path of a scrum master:

(1) The Growth Path of a Scrum Master

(2) The SHU scrum master

(3) The HA scrum master

(4) The RI scrum master

(5) Evaluate yourself : Scrum Master Shu Ha Ri Test

A few weeks ago we did a survey on Growing Agile and used the classic Jnr, Int, Snr classifications for a scrum master.

We defined them as follows:

  • Junior – need mentoring
  • Intermediate – comfortable in role
  • Senior – coaching other scrum masters

These definitions above exclude time (years in role) and age. I still prefer Shu – Ha – Ri as people leap to fewer conclusions – in my opinion anyway.

Here are a set of statements to get you thinking about where you are. Perhaps in some areas you are the master? And you may still be needing assistance in others. (PS: Thats normal!)

(The numbering means nothing – its just to allow comments to be easier.)

  1. You have read a few Scrum specific books.
  2. You have read a few books on other agile topics – Kanban, Lean, Facilitation etc
  3. You regularly read blog posts and tweets related to agile topics.
  4. You partake in conversations (in person or online) debating certain aspects of scrum/agile with colleagues.
  5. You partake in conversations (in person or online) debating certain aspects of scrum/agile with strangers.
  6. You partake in conversations (in person or online) debating certain aspects of scrum/agile with friends/family
  7. You ask other scrum masters what/how they do things.
  8. You observe other scrum masters and offer them feedback.
  9. You invite others to observe you and give you feedback.
  10. The task board, burndown and other “wall artifacts”  are up to date.
  11. All meetings for the sprint boundary are setup.
  12. You prepare for each retrospective for a couple of hours.
  13. Your grooming is a team conversation with business.
  14. Your team works as a unit, not as mini silos (analysis,dev,test,qa)
  15. The team pulls their work
  16. You attend coaching circles to improve your skills
  17. You meet with other SMs from other companies to learn to be better
  18. You attend conferences and course to improve your skills
  19. You have conversations with team members individually to build your relationship
  20. You have conversations with your Product Owner to build your relationship
  21. You have conversations with Management to build your relationship
  22. You have conversations with team members and product owners not on your scrum team  to build your relationship with them
  23. You encourage small failure and the learning behind it
  24. You practise what you preach
  25. You have stories to tell on success and failures
These statements are off the top of my head … there are thousands more – please add yours to the comments and I will update the post (and give you credit!).
The things I mentioned above might come as a surprise to you. Since when is reading and relationship building part of your job description as a scrum master? Well – it is – if you want to be a good one. We try and teach these and other topics in our course Growing Agile Scrum Masters.  These are the keys to becoming great! Content includes: Coaching Self Assessment, Trust, Giving and Receiving Feedback, Listening Skills, Facilitation Skills, Detachment, Self Improvement, Team Assessment, Building Relationships, Scrum Training, Impediments, Motivation, Retrospectives.

The RI Scrum Master

This post is part of a series on the Growth Path of a scrum master:

(1) The Growth Path of a Scrum Master

(2) The SHU scrum master

(3) The HA scrum master

(4) The RI scrum master

(5) Evaluate yourself : Scrum Master Shu Ha Ri Test
In the Ri state, the team is hyperproductive. But what is the ScrumMaster doing and do you really need one? You need the ScrumMaster but they don’t have to do much. Here is an example of the qualities to look for if you want a Ri state ScrumMaster.

This is also a practicing scrum master but one with more exposure. Also active in coaching circles, gatherings etc. They talk,blog publicly about their successes and failures. They realize that they are on an ongoing learning journey. They bend the rules and can articulate that they are doing this. They know the pros and cons of doing this. Inspect and adapt is part of their daily life and thus everything they do is affected by this. They relish the opportunity to have outsiders observe their behaviors as they know the value in this. This scrum master will delay a sprint start in order to have a decent retrospective. They allow enough time during the retrospective for emergent learning and common understanding. Often these scrum masters have starting coaching at an organizational level. They spend time mentoring other scrum masters, product owners even management. They are calm when under pressure and can articulate to developers and business what changing the process means, implies and how in the long run will harm progress.

Do you agree with my description? How would you describe a scrum master in ri?

The process in scrum for teams:

Things Ive noticed…
This is independent of the team. A scrum team can be in various states aswell and this will have an impact on the Scrum Master.
Read more about team Shu-Ha-Ri here:

The HA Scrum Master

This post is part of a series on the Growth Path of a scrum master:

(1) The Growth Path of a Scrum Master

(2) The SHU scrum master

(3) The HA scrum master

(4) The RI scrum master

(5) Evaluate yourself : Scrum Master Shu Ha Ri Test

In the Ha state, the ScrumMaster has a team that gets software done (all features tested and no bugs) at the end of the sprint, has a good product owner with ready backlog at the beginning of a sprint, has data that clearly show at least a doubling of productivity, and has strong management support. The team is positioned to work on hyperproductivity, the design goal of Scrum.

This is a practicing scrum master. They are actively in the scrum master role and doing this role full time. They read up about agile and scrum. They attend coaching circles, gatherings etc and get exposed to various scrum/agile problems from other organisations. They recognize their own weaknesses and strengths. They are able to be open and honest about where they are doing well and where they are not without taking it too personally. This scrum master works with the team and tries to build the team into a self organizing team. With time pressure they also stick to ensuring meetings happen on time. They wont drop a retro but they might cut it short. They structure the retros to get the team to do something they think/know is lacking. They will fight external pressures, like trying to change the sprint length, but often lack the explanation skills to convince others. They struggle with being seen as “people who stick to a process over the success of the business”.

Do you agree with my description? How would you describe a scrum master in ha?

In my next post I will explain my thoughts about the scrum master in Ri.

The SHU Scrum Master

This post is part of a series on the Growth Path of a scrum master:

(1) The Growth Path of a Scrum Master

(2) The SHU scrum master

(3) The HA scrum master

(4) The RI scrum master

(5) Evaluate yourself : Scrum Master Shu Ha Ri Test

A fairly new scrum master – usually they have completed the 2 day CSM course and possibly done some reading. I recall some of the things I did whilst in SHU state and cringe. This scrum master thinks they know everything about scrum. They quote from books and make statements like “that’s not scrum”, “you’re wrong, this is how it works” and “the book says…”. Often these scrum masters think they are in Ri – and thus as they know everything they can break some rules or bend them quite a bit.

When under stress or pressure this scrum master often falls back to command and control – this might be in the tradional project management way or in a more mother hen way. This scrum master when time pressured will ensure everything “looks” right. The meetings will be scheduled, the task board looks perfect. They drop creating a self-organising team and other soft skills. Another common sign is dropping the retrospective and rather going straight into another sprint.

Some other signs – extending the sprint by a day or two to accommodate the team, business critical delivery etc. They struggle with allowing the team or individuals to fail in order to grow. They see the team failing a sprint as a sign that they are personally failing and thus do everything they can to get a successful sprint.

Do you agree with my description? How would you describe a scrum master in shu? What are other signs?

From Jeff Sutherlands post:

In the Shu state, the scrum master sets up the process, helps the team get to a sustainable pace with known velocity and uses the Retrospective to introduce change that improves velocity.

In my next post I will explain my thoughts about the scrum master in Ha.

The Growth Path of a Scrum Master

This post is part of a series on the Growth Path of a scrum master:

(1) The Growth Path of a Scrum Master

(2) The SHU scrum master

(3) The HA scrum master

(4) The RI scrum master

(5) Evaluate yourself : Scrum Master Shu Ha Ri Test

This post has been bouncing around in my head for months now.  There are A LOT of Certified Scrum Masters out there in the world – thousands, maybe more. I’ve met many Certified Scrum Masters, and maybe that’s why the whole certification thing bothers me now. I no longer see it as a status. Rather its simply a course I attended over 2 days. I don’t call myself a scrum master because of the course – I call myself a scrum master because of all the other learning I’ve done, the experiences I’ve had with various teams and the dedication I have to improving myself in that role.

A couple of years ago I came across someone calling themselves a Senior Scrum Master. The ego in me was annoyed that I didn’t have the title “Senior”. Then came blame, how did they get the title? What did they know or do better than me? And eventually the curious side: What does senior mean as a scrum master? What does Jnr mean? Is it applicable? Is it appropriate?

What happens if you were a Senior Project Manager and now you’re a scrum master. Do you need that title because that’s how seniority is communicated in your company? Do your salary brackets get defined using Junior, Mid and Senior?

I started thinking of the growth ladder for an aspiring scrum master. Not all scrum masters want to be agile coaches when they grow up. So how can you communicate at what level you are as a scrum master and how do you determine that level? What are the signs?

Then I thought about Shu-Ha-Ri and it fit the hole. This was a way for me to express my scrum master skills and evaluate myself. It also allowed for movement. Sometimes you are the master and other times you are the grasshopper 🙂

Shu-Ha-Ri refers to the 3 stages of learning and the concept comes from Japanese martial art.

  • Shu is the first stage, where the student is imitating and following the master’s steps
  • Ha is the second stage, where the student is showing understanding, and breaking away from the master’s steps
  • Ri is the final stage, where the student is showing mastery and fluency by creating their own steps

In my next post I will explain my thoughts about the scrum master in the Shu state.

I have proposed this topic as a talk at Agile 2012 – please leave me a comment with your thoughts:

Some interesting reading:

Our first Coaching Dojo

About 2 weeks ago we had our first Coaching Dojo. I tried to post this the next day, and then forgot totally! Better later than never 🙂

There were 6 of us in total and it was awesome! Our group is made up of 3 scrum masters, one developer, one product owner and one Operations Manager.


We started off with a quick into exercise and made idea cards for each other with: Name, Day Job, Company, Super Hero Power and Other interests. As most of us knew each other from previous circles this went quickly but also got us all chatting quickly.

The wine and snacks was also already flowing at this point – also helps the atmosphere 🙂

The next part was “Challenge Generation”. We had 10 minutes of silence to write on Index cards as many challenges as we could think of. We each came up with between 3 and 7. By this stage the wine consumption was making silence tricky …. lol

example of a challenge (from

“CTO thinks agile teams are wasting the time of business stakeholders and wants to stop their involvement with agile teams.”


I explained the basics of the format we would use for the night (adapted from this post:

  •  Split into 2 groups of 3.
  • There are 3 roles: Seeker, Coach and Observer.
  • Take 10 minutes in your group to tell the others about your challenges (the ones on the index cards) and select one challenge as a group to work with.
  • The person whose challenge it is becomes the first Seeker. Decide who will be Observer (takes notes of what is being said, body language etc) and who will be the Coach (coaches the Seeker). Do this for 5 minutes…
  • Then swap roles (move to left makes it quick and easy): Repeat as above for 5 minutes, then switch roles and again repeat.


NOTE: If you are the seeker – try and own the problem especially if it isn’t yours to start with – try and apply it to your company and put in some personal things, helps create a slightly different situation and stimulate more creative thoughts.

Everyone in the group of 3 should have been through all the roles. Now take 10 minutes to read through the observations everyone made. This is the fun part … there were lots of giggles and “Wow – do I really do that??”.


We then switched up the groups and repeated the whole exercise above with the new group.


At the end we had a 10-20 minute retrospective and asked the following questions:

  • What was the experience in your group?
  • What did you learn as Agile Coaches?
  • What did you like about the Dojo format?
  • What are your ideas for improvement?

As a group we decided to try another format next time – more one-on-one role playing with an observer. And in the following session another format group role-playing. We think all the formats will have value and be interesting.


I had an amazing time. Our group members have all been to Coaching Circles before and so there was already a trusting bond between us. The challenges were personal but no-one took them personally or defended them. Everyone was open to learning, and trying new ideas. All of this was a testament to how mature we all are in our daily agile practices. I look forward to our next session 🙂

Agile Games – Scrum Gathering South Africa

Over the last 2 weeks I have been kept busy with the South African Scrum Gathering. I was co-presenting Agile Games (which is blogged about here) and a Product Owner team session, which I will write about shortly. There were 2 Agile Game sessions held – one in Johannesburg for 30 minute and one in Cape Town for 90 minutes. Due to the duration being so different Karen Greaves and I decided to do all different games at these sessions.


All the Jhb games were originally played with Alan Cyment.

  • Vampire
  • Singing, Numbers, Clapping
  • Columbian Hypnotist

Read more on how to play these games here:

This session was also video taped – – Enjoy!!

Cape Town

Singing, Numbers, Clapping

(originally played with Alan Cyment)

Read how to play this here:

Discussion points:

Non Musical Chairs


Form groups of 5 to 15, arrange chairs in circle facing outwards. Pick a “Chair Person”.


Goal is for the “Chair Person” to sit in the empty chair and for the rest to prevent this.

Rules: No touching the Chair Person. No moving the chairs. If you stand you must move chairs. Once Chair Person is sitting all raise hands and wait for other groups to finish.

Once all done, have a 1 minute retrospective (the Chair Persons must huddle in a corner and not watch). Repeat for 3 rounds.

Feedback: Everyone stands in a circle, shoulder to shoulder.

Discussion points:

Broken Skype
(Invented by Sam Laing and Karen Greaves – adapted from Broken Telephone)


Come up with 3 hand signs – 1 simple, 2 complex. Have people stand in rows all facing 1 direction, looking at each others backs – max 10 persons in a row.


There is no talking allowed. Facilitator taps on back persons back, they turn around. Show the sign ONCE. That person turns around and taps the person in front of hims back, repeat until you get to the front. Widen rows and have front people show the sign they got. Now show the actual sign.

Round 1 – use the simple sign (We used ASL for “technique”)

Round 2 – use the complex sign (We touched our ears, two fingers to nose, two fingers to palm)

Round 3 – have the rows form circles. Again you will show the person on your left the sign ONCE and so on. Everyone can see the sign but may not “act it” until it is their turn. They can correct at will based on what they have observed. At the end form a large circle and all do the sign together. (We used ASL for “copy cat” and then “empty glass”)

Feedback: Everyone stands in a circle, shoulder to shoulder.

Discussion points:

(originally played with Carlton Nettleton)


Find 2 origami things to make – keep them fairly simple. We used a frog and a box. Have loads of blank paper in correct starting shape, and print out enough instructions for half the audience.


Round 1: Get everyone to partner up and sit back to back. One person will fold, One will read instructions. The one building may not see the instructions, the one explaining may not see whats being built. Pick easier origami(frog) and hand out with paper to built it. 5 minutes, build as many as possible.

Round 2: Collect all papers. This time sit facing your partner. Now the one reading can see whats being folded.Hand out other origami and paper. 5 minutes, build as many as possible.

Round 3: Collect all papers. This time sit next to your partner. You can both see the instructions and the folded paper. Only one person may fold. Teams can pick which origami they want to build. 5 minutes, once the one is build – hand out the other one to build.

Feedback: Everyone stands in a circle, shoulder to shoulder.

Discussion points:

Water Game
(Invented by group of delegates and Sam Laing at Agile 2011)


A glass per person, a straw per person (bendy ones are great – but plain straight ones work as well), a jug of water per team of 5-7 people.


Form teams of 5 to 7. Aim is to fill as many glasses with water as possible in 2 minutes, using only the straws. You can suck water but not into your mouth – only to top of straw – don’t cheat!. Have all teams hold up glasses at end and pick winner. Pour water back into jug. 1 minute to inspect and adapt.

Repeat for 2 more rounds.

Variations – have glasses of various shapes available. Have various types of straws available. Hand out more straws or less. Hand out scissors.

Feedback: Everyone stands in a circle, shoulder to shoulder.

Discussion points:

Don’t Blow It


Many balloons, and blindfolds – we use kids party masks and blanked out the eyes. Split into groups of 3 to 5. Volunteer a person to fetch the blindfold and balloons.


Goal is to blow the biggest balloon (not the most!).

Rules: Only the blindfolded person can touch the balloon (and hence blow and tie it). Balloon must be tied to be considered “done”. Team says whether to blow or stop. Volunteer a blower for each round. Facilitators can randomly pop balloons to insert some fear and laughs and jumps! Each round is 1 minute.

Round 1: everyone stands close – shoulders touching.

Round 2: can stand anywhere.

Round 3: No talking, can only communicate with blower via touch.

Feedback: Everyone stands in a circle, shoulder to shoulder.

Discussion points:

Jumping Circle Close
(Invented by Sam Laing and Karen Greaves)

Read how to play this here

Feedback Door
(Idea from here, but adapted: )

As you can tell from the feedback – everyone seemed to have an AWESOME time – Karen and I included. Agile Games are not for everyone – some people prefer more serious discussions and formal learning sessions – but hopefully even those sceptics will see the value in these games oneday.

If you attended either session – please leave us feedback in a comment as we would love to improve – Thanks!

Coaching Dojo … in Cape Town :)

The Coaching Circles in Cape Town are immensely powerful. They have grown from strength to strength and have evolved to become much more than we originally thought possible 🙂 Many people from various roles and with varying ranges of experience are getting to learn new things, seeking advice from peers and bounce ideas around like minded individuals.

I am looking for something a little different though. I would like to practice my coaching skills with other coaches and learn from them, perhaps show them something new. Amongst these skills are: Listening, Observing, Questioning, Feedback and many more. I stumbled upon the idea of coaching dojo’s and would like to try it out. Essentially it is role playing with team members taking a turn to seek coaching, be the coach and observe the interaction.


“When Japanese martial artists want to deepen their knowledge, learn new techniques, and advance their skills, they gather in a training center, the dojo. “


The Learning Objectives:

  • Practice listening without judgement
  • Gather information more effectively
  • ask different kinds of questions to understand real problem
  • Become aware of how you coach
  • Observe other coaching techniques and styles
  • Gain fresh insight into a problem you may face at work


Basic Concept: 10 minutes per round (min 3 rounds, max 4)

Form groups of 3 (if uneven can have 1 or 2 groups of 4)

  • 1 “Seeker” of coaching
  • 1 “coach”
  • 1 (or 2) “observers”


Pick a card with a challenge or discuss a real challenge for you (Seeker). Then Coach and Observe. 5 minutes total

Each provide feedback (seeker 1 min, coach 1 min, observer 3 min) 5 minus total

Switch Roles – can change topic – seekers choice.


At end – group Retro: 10 minutes

(depending on size of group can use various facilitation techniques for this)

  • What was your experience with your group?
  • What did you learn?
  • What did you like?
  • What are your ideas for improvement?


 Who is this for?

This is not intended to replace the coaching circles. It is for those particularly wanting to improve coaching skills. With that in mind, you need to be actively practicing coaching for at least a year to join the dojo. This means you regularly coach/encourage/train others you work with. If you think this could be for you PLEASE let me know by leaving a comment – thanks!

When will these start happening?

From what I can see the current Coaching Circle session will be ending with a group retro on 26 September 2011.

I’d like to propose the first dojo happen in the second week of October (10th to 14th). I reckon it will take a minimum of 60min – but would like some chat time before/after – so 90minutes should be perfect.


I’m open for ideas – ideally a company with bigger open area, or house with large lounge? Very casual. Very social.

Ideas / Thoughts???

Please leave comments below with your thoughts or questions or suggestions … I would LOVE to hear from you 🙂



Inspiration and formats from here:






Powerful Questions

This post has been moved to my company blog – you can read it here:

Hooray, We’re Agile Testers! What’s Next?

So first off just a little note to explain that I left this session early to go and see a dentist – so my notes only cover the first part only. Oh and a little disclaimer – these are my notes and so they might not all make sense … 😉

Agile2011 session : Advanced Topics in Agile Testing by Lisa Crispin & Janet Gregory

… blurb off Agile2011 site
“Your team successfully adopted Agile, you have traction on practices such as CI, TDD, maybe ATDD. Still, you see lots of room for improvement in testing. Do you sometimes miss or misunderstand customer needs? Is it sometimes hard to complete all testing activities each iteration? In this interactive tutorial, you’ll practice ways to better understand and capture customer needs; collaborate more effectively and enjoyably with developers and other team members; improve continuous integration and delivery; manage technical debt; plan and estimate in ways that ensure testing “keeps up”.”

Test Manager – should be a people manager and not a micro manager. Needs to coach testers and not manage them.

Question: Do we need metrics?

Main aim is to stay potentially shippable.

Cultural influences

Key take away: You cant force but you can influence.

Culture Exercise: Transitioning from previous practices to agile practices.
Ask “what do you want to achieve”
Have pilot and involve Test Manager
Expose “improvement areas” in the “we have always done” conversations

QA label & responsibility
– team with no job titles
team to deliver and take responsibility
litmus test – agile or not – perhaps you just need to leave if its not your cup of tea?

transparency and visibility – show the value and ROI
explain the benefits and the costs → articulate, use the team to help with this.

“testing is not a phase” – shift your mindset
Develop a learning culture – no blame
Give time to learn and develop

Book Recommendation – Tribal Leadership

Customer Issues
requirements – story mapping, mind mapping a feature/theme from a testing perspective
features over quality

Aim: Find questions and then get them answered

Pics from session:

Specification by example
ask your customer for examples
– include undesirable behaviour
– shows intent
– turn them into tests
– automate them

Story done vs feature done – what is difference?

Its easier to sell documentation than automated tests. Automated tests are living documentation.

User persona’s for exploratory testing
Jonathon Kohl – man & machines
James Whitteker – whats the value of a tester
James Bach

What are the most important things in your product?
Make rough notes on exploratory testing to figure out how to learn when we missed things.

Quadrant for tests at feature level:
* idea – adjust the pyramid to your needs
Push the tests as low as you can to get the fastest feedback.

Making Testing keep up
– mini waterfall
– unmaintainable code and tests
– insufficient automated tests

Stumbling blocks (smells)
– refactoring requires updating all the automated tests

QA manager -> managers the test community of practise. Need to recognise the value testers in an agile team

Invest in quality – under commit
Plan less work than you think you can do
Reduce the temptation to cut corners
Create tasks for learning skills, refactoring automated tests

Book Recommendation – Clean Coder by Bob Martin (Say no!)
Review of book:

Using a specific tool will prevent devs from helping out testers because they dont want to learn the tool.

Test automation code is as critical as production code – the whole team needs to understand this.

If devs automate then testers are free to :
– help customers specify examples
– think of the right test cases
– do manual exploratory testing
– think of more good questions

Testers are sometimes taught things that dont work in agile like “ wait until its all done” – you need help unlearning this.

Non co-located teams are ‘dislocated’

Levels of testing – Product, Release, Sprint

What will I take away from this session?
That a manager should coach people rather than manage them, focus should be on a culture of learning.
To keep in mind that our main aim should be to stay potentially shippable.

Link to presentation:

A little bit more on the presentation here:

24 August Update: A post by Riaan Rottier on the session:—hooray-were-agile-testers-whats-next/