I have been running a coaching programme with my latest client for about 7 months now and it has been going down very well.  These aren’t new things as I have been running them for a while in my previous places.  Take a look at a previous blog on the subject if you want to know more. Though I have changed the curriculum and added more things in over time. These are a great source of enjoyment for me and it warms my heart when I hear old coachees have been taking this programme to their new places of work. My legacy lives on! <Hums the titanic theme tune>

So my latest programme was coming to a close and feeling festive I wanted to get the Delivery Manager community together to do something fun. I don’t need an excuse for this if I am honest. Even my boyfriend says that I always seem to get to do the cool stuff. So I came up with the idea of a MEGA dojo… for the full effect you have to do a dramatic voice and put in an echo.  THE MEGA DOJO  <dojo dojo dojo>  You get the picture.

So I invited all the delivery managers to London and planned the session with a great coach called Tom Bray here at my current client.

Our Agenda was:

• Welcome – Naturally a motivational speech from moi
• Getting to know you ice breaker  - We did unknown fact and what you would do with this object. The object was a little brown bag. Looked like santas sack to me
• Break out groups to draw me what is a ‘Coach’ along with skills and attributes – We covered this in the programme and so was a refresher
• Call out all the techniques we have learnt – Again this was to get them to think about how far they have come

• Dojo One – A 45 minute session where they could practice any of the techniques on each other in triads.
• Dojo Two – A further 45 minute timeboxes with different people

• We then closed it up with Clean feedback. This was important as in the Chapter Health check they said we don’t take time to give each other feedback. So we used the final 15 minutes of the session giving each other positive or negative clean feedback. This is so important in any community.  One I received certainly made me feel valued.

The feedback was resoundingly positive and just what we needed as a community.  I am super excited for 2020 as I am now looking to hand over the programme to a couple of talented coaches here. Plus I want to offer it wider to anyone who wants to learn.  This was just the cherry on the cake to see how far they had come.

Naturally any team day is followed by the celebratory 2 hour lunch.

Love these Agile Delivery Managers – Such an awesome bunch!

So that’s it from me, just wanted to share  cool things I have been doing.  I’ll tell you about my other cool thing around insights soon.

Merry Christmas

xx

Tis the season to be jolly..fa la la la laaaa, laaa la la la!

It is certainly starting to feel like Christmas now and it makes me want to do really fun things.   Christmas is my absolute favourite as everyone is happy and everything is twinkly and sparkly.

At the weekend I went festive wreath making and I really enjoyed it. Thank you to my good friend Lois who bought me this activity as a treat.

In other news,  a few of us were hosting a festive guild last week and we decided to bring back the party classic pass the parcel.

The premise being we wrap loads of cool prizes with questions and then press play on spotify   

We wrapped:

• Haribos (Veggie and none veggie)
• Big ole bar of diary milk
• 2 packs of planning poker cards
• Barefoot everyday coaching cards
• Turn the ship around book

The questions were themed around the Agile Guild and how we could make it better. They were:

• What could we help you with, for you to be able to attend Agile Guild sessions?
• Are the sessions too frequent?
• Is there a better way we could communicate information on the Agile guild sessions out to you?
• If you could choose a topic for a guild session in the new year, what would it be and why?
• What can we do to make the Agile Guild better?

To add more complexity my client is split across two sites and so we had to be really creative and have the same parcels in both locations and co-ordinate the music. It all got very rowdy, which is my favourite type of session.

All in all everyone seemed to have fun, and who doesn’t like getting a prize Thomas even said this was the best guild ever!

The fun didn’t stop there though.  We threw in an Agile quiz for good measures..even I struggled to answer some of the Scrum ones!  There was two questions in particular that made the group kick off and we had to cool their boots   Maybe another guild session to answer those bad boys! I think it’s more to do with the phrasing than anything.

So a quick and simple idea that you can play with your teams that is different to the ‘normal’ retrospectives. You don’t have to have flashy prizes, simples sweet treats will do.

Merry Christmas Everyone.

Happy New Year everyone and apologies for not blogging in such a long time. I don’t know about you, but I have no idea where 2018 went!  It seemed to speed past so quickly..

I have been busy with a relatively new client and was due to be there a couple of days the other week when ‘The Boss’ called up proclaiming  ‘man flu’, and wanted me to support him on his Certified ScrumMaster Class. Now, I don’t really buy into ‘man flu’ but he was a pitiful sight to behold, and so went along to do some of the heavy lifting. It’s been a good few months since I last trained Scrum, but it all came flooding back to me   It was while there that I got the inspiration for this blog. I met a man who was literally starting as a ScrumMaster 9am the day after the course, and he wanted to know what needed to be done in his first few days and weeks.   So I reeled off a few things for him to consider and then wrote him a nice poster with all the details on to take away. 

I have not heard from him since the class, but I am hoping everything has worked out for him!

I thought other people might be interested in this and so here I am blogging about it.  I have taken the liberty to expand on some of the points. I was going to make a mind map, but all the ones I tried would not let you export an image for free  

Stage 1 (First few days and weeks)

• Meet the team and get to know them and what they want to achieve. Agree regular 121's to keep the conversations flowing.
• If the team is already up and running, spend some time observing.
• Organise a team building event. Encourage team members to get involved in the organisation.
• Has the Team used Scrum or Kanban before? Do they need to have some sort of training?
• Meet the Product Owner. Get to know them, their history and what they want to achieve. Discuss both of your roles and what you expect from each other. Discuss what to do if you do not agree with each other.
• Discuss the product with the Product Owner. Understand the Vision, roadmap, commitments, issues and risks.
• Review the Product Backlog. If it does not exist, we need to help facilitate creating one. Do we need to complete user story mapping?
• Set up regular sessions with the PO to keep collaborating. Encourage them to sit with the team.
• Does the team sit together? If not organise this. Ensure that the team has either a TV or visual board.
• Create an initial board to start putting work on. This can be refactored as you get the team up and running.
• How does the team store information? If some form of wiki, SharePoint or other doesn't exist. Think about creating one (after discussion with the team)
• Facilitate getting a team Definition of Done.
• Set up Sprint or Cadence structure in diaries. Plan for more refinement sessions if the team has to create the backlog from scratch.
• Set up a holiday chart and make visible in the team space.

Stage 2 (Coming weeks and months)

• Understand 'other' teams, people or third parties we might have dependencies with. Meet these people and agree ways of working.
• Create a stakeholder map and plot all of the key people on. Plan how you can meet all of these people.
• Understand Staff Liquidity. Implement knowledge share as needed.
• If using Scrum, think about creating calibration stories for referring to in estimation sessions.
• Set up team metrics (CFD, Burnup, Burndown, Lead time Distribution, Defect ratio, Waste, Work in progress, Net flow, Live status, Bugs, time to deploy, % automation, % fails of automation, build times, ticket age, throughput rates.
• Consider if we need to create 'End of sprint one page' report for stakeholders.
• Refactor the Board. Think about how to visualise: Blockers, Avatars, waiting, dependencies, issues and risks, different types of work, expedites, defects, WIP limits, capacity allocations, abandoned work, external teams collaborating with you (to name a few)
• What engineering practices do we need to consider and implement? Understand what is done now and work with the team to define where we want to be.
• Understand what the release process is, and the frequency of this. If people are involved outside of the team. Become their friend!
• Understand current state of play for : Tooling, environments, levels of automation, CI/CD strategy, testing strategy, Source control, coding standards, online tool such as VSTS or JIRA.
• Work with the Product Owner to create a Release Plan and any metrics they need to help manage flow of stories, value and delivery.
  
  

I am sure there are things missing and so feel free to leave comments for other people to get the benefit of your knowledge as well. I can then add them in for an AWESOME list!

I will try and not leave it as long next time.

To quote Jerry Springer ‘Look after yourself, and each other’

Helen

xxx

Whether you use Scrum or Kanban as a delivery method, as a ScrumMaster you must be able to help the team or organisation understand and use the methods or frameworks.

This involves an element of teaching, coaching and mentoring. I have already looked at one way I have been establishing a coaching stance at my clients in my ‘Coaching Dojo’ blog earlier this week. Now I want to share with you something that Carlo Beschi and I put together for a conference and now subsequently using to help people become better trainers within the same organisation.

I regularly train non certified Scrum Classes and I am also an accredited Kanban trainer for the LKU. In fact, I am also a Train the Trainer for the LKU (ooooooo I hear you say! )

This means I spend lots of time thinking about how to convey messages in a simple and fun way, that everyone gets and can practically take back to their work places and start using.

I am one of the first people to turn off with my three second attention span if you just talk at me. Equally if you want me making random shapes with my body, then you are going to lose me too. For me it’s about getting the right balance of the two and really thinking about who your target audience is and what you want to get across.

I have seen many great trainers over my years and love the Sharon Bowman’s ‘Training from the back of the room’. So when Carlo and I put together this offering it was a blend of all of our years experiences and what we have learnt from our own training and research.

Our strategy was to include as many good and bad practices as we could . If the students could recognise them in us, maybe they could recognise them in themselves. To help facilitate this we created Bingo cards and of all the techniques we were planning on using in the session. As soon as they had a row, we encouraged them to shout ‘Bingo’. Not only was it educational, but it meant they kept focused throughout the session and had a little fun along the way. We rewarded winners with chocolate.

The first half of the deck is sharing different thoughts and practices for running great training sessions. You won’t get this sense from the deck, but throughout the class we were using all the different techniques we were talking about so they could see them and experience them in person. 

The second half is about handing over the reins to the attendees and getting them to put into practice everything that they had learnt over the course of the session.

We gave them a time box to go away and plan a mini training session and we had 2 decks of cards for the topics, normal ones like story points and user stories and then wild cards which are harder topics such as probabilistic forecasting.

You will see in the slides that there is a lot more content around them than just words on a page. Apologies, but without writing a whole book this is hard to convey.

Carlo and I first run this at the Agile Tour and we got some really great feedback from the attendees. Now I have adapted it further and we are going to use it to facilitate a half day session at my client to train people in preparation for a software craftsmanship course, they are planning on running internally. We hope that they also take many practices into the sessions that they are about to write and plan.

Our slides are in the public domain and you can find them on my slide share here: https://www.slideshare.net/helenmeek/effective-teaching-v20

Maybe have a think about how your communities train each other and whether there is any value from any of the practices that we call out. Don’t forget that the practical element of any training is extremely important, and so that’s why we have included it with the provision of valuable feedback to the students.

I know so many great trainers from my peer group who I admire. I took the opportunity to contact a few of them and ask them for some of their top tips. Keep an eye out for these in the deck and thank you to everyone who contributed them.

I wanted to share these slides with you because I feel it’s important to help grow and harness the expertise in our industry. Together we have so much knowledge and by creating a sharing culture we can truly become awesome and transform the world of work.

Thanks again to everyone who was involved in this and special thanks to Carlo Beschi my co creator.

You never know, we might run it again at conference near you

I wanted to share with you a blog by my good friend Doug Idle. It is about a conference session that we created together for London Lean Kanban Days.  I was going to write a blog on this, but I thought his was already perfect. I am very pleased to share it with you. Enjoy x

I recently had the opportunity to attend a two-day course on Kanban (KMP2, for those in the know) taught by the fabulous Helen Meek (Accredited Kanban trainer and all-round Agile Coach). Knowing my love of all things Lego, Helen asked if I’d be interested in working together to find a way to demonstrate the scaling of Kanban and some of the KMP2 curriculum in 90 minutes rather than two days using bricks. We targeted presenting at the London Lean Kanban day in April.

We knew that we couldn’t teach the entire curriculum in 90 minutes (there’s a reason it’s a two-day course) so we decided to concentrate on six of the seven cadences in the session. We wouldn’t cover the Strategy review because it was just to big to fit in to the session and isn’t covered in KMP2 either. What we would cover would be:

• The three delivery cadences — the daily standup, queue replenishment and delivery planning
• The three improvement cadences — the operations review, service delivery review and risk review

… and we’d do it all with Lego!

We asked the group or 30 to self organise into teams. One member of each team would be the Service Delivery Manager who would be responsible for:

• Facilitating key meetings
• Supporting collaborative decision making
• Sequencing and scheduling work
• Helping the service understand its performance
• Working to improve the overall service
• Collecting data using the supplied lead time chart template
  
  

Each team would be responsible for constructing one part of a plane — either the fuselage, undercarriage, wing or tail. Each team was provided with the exact set of parts they needed to build all of their components, Lego style step-by-step instructions, a Kanban board and a set of laminated order cards.

After the teams had been setup and the SDM was ready to go, we kicked off by giving them a one-minute Daily Standup (the first cadence) and then building us one red, one blue and two black planes in four minutes. After the first run and a short retrospective we gave the teams their first opportunity to scale out by introducing dependencies between them. To reflect the dependencies, we gave them a new Kanban board to use.

At this point, we introduced the second cadence: Queue Replenishment. In this cadence, teams decide what to select from the pool of options. By moving work to the ‘Ready’ state they are making a commitment to complete it. Under normal circumstances, the meeting is no more than 30 minutes in length and would include key decision makers and stakeholders. Most teams will run a scheduled queue replenishment meeting — although on demand replenishment is desirable, it is often hard to coordinate. We gave our teams three minutes to run their queue replenishment and coordinate with each other.

After giving the teams another set of orders, we started them on their second run (a daily standup and some building) along with a retrospective afterwards. After the second iteration, it was time to introduce the third cadence — the Service Delivery Review. In this cadence, we look at whether or not we are delivering according to customer expectations. We look at a single Kanban system and include key people from each activity (dev, test, analysis etc.). The group compares current capabilities against fitness criteria metrics and seeks to balance demand and risk. The session is typically 30 minutes in length. After conducting a short Service Delivery Review, we asked the teams to scale out again — this time with all five teams forming a single service. On this occasion we didn’t provide a board since testing of the game had shown that the teams had outgrown anything other than a full scale whiteboard and we weren’t able to carry one around for the session.

During each scaling out session, we asked the teams to consider their policies, review their work in progress (WIP) limits, working together agreements and delivery lead times.

The Delivery Planning meeting was the fourth cadence we introduced. Here, we plan what can be delivered and form a commitment to our customers. Issues about delivery are raised in this session, solved and/or taken to the Risk Review cadence. Key attendees will include anyone who accepts the deliveries or is involved in the logistics of delivery. Specialists are present for their technical knowledge and risk-assessment capabilities. This is a decision making meeting and could be 1–2 hours. We conducted a five-minute delivery planning meeting where we asked the teams to estimate their percentage confidence in the third iteration orders we’d just given them.

For the third iteration, we introduced two new classes of service — a plane which had to be expedited and another which had to be completed by the end of the iteration as well as a fixed date plane, which had to be delivered by the end of the fourth iteration. Once more, the teams had five minutes to build the planes including a one-minute daily standup.

At this point, we introduced the fifth cadence, the Risk Review. In this, we look at problems that put our delivery capability at risk. Anyone with information, experience of recent blockers or managers from dependent services may be in attendance at this meeting. As a result of the session we may review the assigned Class of Service and/or explicit policies. Techniques such as blocker clustering can be used to analyse the work. Sessions can be 1–2 hours in duration.

We then kicked off the fourth and final iteration, asking the teams to build us 12 planes — four of each colour.

After the last iteration, we introduced the Operations Review. This is a ‘Systems of Systems’ level review and would be facilitated by a senior leadership team member. Here, we review the demand and capability for each system with a particular focus on dependencies. Improvement suggestions, actions, decisions or required changes to strategy with designated owners are the key outcomes of this meeting. The duration can vary depending on the number of services. With a large number of attendees, it could last up to two hours.

Although it is no substitute for the KMP2 course, the 90 minute session does give a really good look at six of the seven cadences, as well as giving attendees the opportunity to put them into practice.

After our successful outings at the Kanban Coaching Exchange and the London Lean Kanban Days, Helen and I are looking for opportunities to run the session again — so hit me us if you’re interested.

Doug Idle is a Senior Agile Delivery Manager. When he’s not delivering awesomeness he spends his time listening to Guns ’N’ Roses and rocking stages with his Velvet Revolver tribute band.

Tweet.

One of the key areas of my role I am super passionate about is people! They are the highlight and sometimes the lowlights of each of my days. But ultimately by loving, cherishing and harnessing their awesomeness, we can do great things in communities. I also think about my role sometimes as throwing a pebble into the community pond and the waves and ripples that come out carry on with them.  Deep for a Monday I know!

I wanted to share with you today one of my little pebbles that I kick started with my biggest and oldest client. For those that know me, you can work out who!

The History
Many years ago I hosted a meet up group with Rachel Davies where I saw her run a coaching dojo. I enjoyed it immensely and saw endless possibilities with it.  So, I took this format and experimented with one of my insurance clients at the time and had some great success with this, and I saw how it really helped the ScrumMaster there grow.  This is the same place I met my good friends Richard Arpino and Doug Idle. If you like they were my original lab rats  

Why I am passionate about Coaching Dojos?
I see many role disciplines in my career revert to the old classic of, you tell me your problem and I will solve it for you. We know this is not the optimal way of getting people to think for themselves and ultimately people know the answers deep down, we just need to help them unlock it.
So in the coaching dojos we give people the tools they need to unlock potential and ideas within themselves and each other. I have seen managers become less tell and more coach, which reduces burden and increase the ability for leadership and the coaching of others. I love that ‘A-ha’ moment when my students use it for the first time in 121 or retrospectives,  and they come back beaming from the results. I have run these in many organisations, but often run also at the London Lean Kanban Days conference.

What is a coaching Dojo?

Each dojo has a time box e.g. 10 minutes and we ask people to bring real life situations they need help with. Work or personal is fine and we have strict confidentiality rules.
We introduce different models and give people the opportunity to practice these.

You have three roles:

• The Seeker –  Person needing help
• The Coach – Person to coach
• The Observer – Provider of feedback

At the end of the time box we ask for feedback from the seeker, coach and observer (in that order). By doing this the coach gets the valuable opportunity of feedback and this can really shine a light on some of the bad habits we have or don’t even know we are doing.

What types of habits do you see commonly?
This is not an exhaustive list, but can include:

• Not really listening. Maybe thinking about new questions or solving the problem while the seeker is speaking.
• Butting in when the seeker is speaking
• Trying to give people the answers to their problems
• Using cognitive bias on situations
• Lack of patience or self awareness of what your body is doing

The Coaching Dojo is about teaching you awareness of yourself, different models to use and a coaching mindset/stance. It is a great playground to practice safely in.

So how did you scale this?

Originally with my client we opened coaching dojos up to 65 ScrumMasters, and for at least a year we ran monthly 1 hour sessions where we would introduce different models and practice. However we wanted to make this more of a rolling program and something a little more formal.  We also didn’t want to limit it to just the ScrumMaster community, because developers, testers, product owners, you name them! Can get value from these skills.

So we created a 2 month program and kicked if off with a taster session so people can drop in and see if it’s something they want to do. Each 2 month program is a commitment and so the expectation is that they will commit to 1 hour per week for the duration.

We had lots of learnings along the way:

• Originally I had about 4 sessions a week and it was getting crazy, and so I sought the help from my good buddy Richard Arpino and Chris Toby to help organise. My long term goal was always to hand this over the organisation to continue without me. The real test of success!
• We also had lots of no shows which is very frustrating, but since we changed to a 2 month program we have found this to be so much better.
• People were always very compliant in sessions, rather than difficult as some can be. So when this happen the lead coaches step in with example.
• Keep the groups static as this builds trust in the peer group. You also find they start working closer with each other in the wider business.
• We run small groups of 4 people, this allows one person to miss a session. We keep them small so we can focus on individual growth, rather than sheep dipping.

We have had so many learnings along the way, and this is really about experimenting and finding the right fit for the people.  But something must be working as we have a waiting list now!

So what is the curriculum?

There is now a formalised curriculum and we created a knowledge bank where people can go and see useful information about the models and coaching in general. Plus an internal coaching Facebook page where we put daily words of wisdom and new ideas they can try. We have book recommendations and are encouraging people to practice as much as possible.  The lead coaches can then support and debrief any difficult situations when they take these practices back to the teams.

Our topics:

• Powerful Questions
• GROW Model
• The 5 Whys
• Active listening
• SARA Model
• DESC
• Dealing with difficult people
• CIGAR Model
• Contracting in Coaching
• OSCAR Model
• Clean Language
• Real Options

It does seem a lot, but each program is built from a subset of these and we are adding more all the time. Especially as I am on the Barefoot PG course

Each of these modules have supporting documentation and we may spend more or less on one than others, depending on experience in the group.
We also have different stages of groups. The first 2 month program is level 1 and 2 and so developing.

So what next?

We want to launch a level 3 which looks deeper into the art of coaching people and more practice of course. We are thinking about doing these in larger groups as they have already mastered the basics. We need to work this out and so ideas are welcome.

So we scaled by putting a program in place and by having three people that can run a max of three groups at any time. We could add more lead coaches, but we found scarcity made people invest in this more! I believe we have trained about 100 people from all different role types.

For the last two months I have pretty much handed everything over to Richard and Chris.  I just pop along when they need help or I have some free time. I leave them for pastures new in a week or so, but I know I have left in strong and capable hands. Plus I look forward to seeing how they can advance the program further.

There is so much love for coaching dojos in this organisation and I see how it has made a difference in the communities here. 

I look forward to my next adventure, when I can try something similar/new like this again.

Call to action!

So what are you waiting for? This is something you could set up and try with little investment. If you want some help or advice, please get in contact and I will support you however I can. I look forward to news of your experiment.

I once asked a friend of mine ‘What would be the one thing you would change about Scrum?’ He pondered with that question for a short time and then responded. ‘I would change the name of the Sprint Review’.

This intrigued me and followed a conversation that reminded me of a few core principles that I had pushed to one side in my mind.

Quite often I hear teams refer to these sessions as a ‘Show and tell’ or a ‘Demo’. I had never felt passionately about a name before until I had spoken to my friend. I thought back to the sessions that I had been seeing recently and wondered, were they just a demo or were we truly collecting feedback?

The Sprint Review is actually a form of retrospective.

It is about:

• The Product Owner telling the stakeholders what it is we have achieved against the Sprint Goal
• The Product Owner advising of any key decisions that have been made in the Sprint
• The team facilitating what changes have been made to the product
• The stakeholders asking questions and providing feedback. With the team and Product Owner filtering changes back through the Product Backlog
• Confirmation of when the Stories will be shipped
• Any discussion on the future strategy of the Product
• The Product Owner closing down the session and advising the candidate stories for the next sprint

In preparation of the review the team would have completed the Sprint to the Definition of Done and spent no more than an hour or two preparing for the Sprint Review (depending on length of sprint). These are informal sessions and there is no expectation to create flashy power points.

Work that is NOT DONE is NOT SHOWN…..

As with all ceremonies, they should be a regular heartbeat and the customers know when to expect them. The same time and the same place every 2 weeks is the dream, but sometimes tough to achieve.

As a ScrumMaster I would expect the team to self-organise over the Sprint Review. I might add a task to the Sprint Backlog during planning as a reminder to the team that this needs to be prepared for.

I have once let my team fail here. In one company I got fed up of reminding them to prepare for the Sprint Reviews and so one day, I just didn’t. Let’s just say that didn’t happen again

When running large reviews, it is critical to be prepared. Often I book the meeting room 15 minutes before the allotted time so the team can go in, set up the machines and open any tabs that they might need. I am always conscious that we have lots of people and so avoiding time spent on waiting is something we can always do with removing.

If you find that you are not getting people attending the Sprint Review , then think about your advertising. As a ScrumMaster I have put up posters, gone to visit stakeholders 121, sent mails around the office, floor walked inviting people that might have an interest or dependency.

In larger organisations where multiple teams rely on the same people, then you need to collaborate and find out what would work best for your attendees. You might need to experiment with this.

Ultimately, I do what it takes to get people to the Sprint Review.

Once the team have shown the fruits of their labour, we then need to do the most important part. The part that is always forgotten……collecting the feedback.

In an organisation recently I experimented with giving them post it notes and the format

• What did we like about these features?
• What didn’t we like about these Features?
• Great ideas to improve?

They did look at me a little crazy as this was something radical to them, but it ultimately got them to think about what we had just shown and enabled the Product Owner to get valuable feedback on where to head next.

How do you collect feedback in your Sprint Reviews?

At the end of the meeting the Product Owner should then give the attendees a view of the candidate stories for the next Sprint. I impress the word ‘Candidate’ on you because they are not confirmed until you have completed Sprint Planning.

Remember, the Sprint Review should not be the first time your Product Owner has seen the work. They should be looking at this regularly during the sprint, as with bringing in stakeholders to get early sight. Nothing in a Sprint Review should be a surprise!

I am often asked ‘What do we show, if there is nothing to show?’

This is an interesting question and a great one to exercise the 5 whys on:

• Why do you have nothing to show?
     - Because the testing was not completed
  
• Why was the testing not completed?
     - Because the developers did not get the work to us until the last day (hopefully you spotted the dysfunction there!)
  
• Why did the developer not complete the work until the last day?
    - Because we did not get everything we need from the PO (Dysfunction)
    - Because the story was too big (Dysfunction)
    - Because the PO changed their mind mid Sprint (Dysfunction)

You get the picture. Remember what I about the ScrumMaster remorsefully looking to establish and remove dysfunctions of the team? There are visual and verbal clues over everything you do.

Other things to watch out for is where teams are not vertically slicing and so just delivering component parts. I also had this at an organisation recently. The question I ask them is ‘If I pulled the plug on your feature right now, what value have I got for my money?’ Because if I was truly being iterative and incremental, I would have still got something I could sell…right??

If I pulled your Sprint right now, do you have something that could still be used?

On the odd occasion there is a small config or non-client facing change, then assume your attendees don’t want to see physical code. Remember they are likely to be from the business. In this instance it is perfectly acceptable to just explain in plain English the change you have made and move on.

Another beautiful technique I saw a team do was story cards. One of the developers created it and used it to explain to clients complicated technical code changes that sat deep in a system. It was his way of articulating what they had done.

See the blog here for more details: http://tlaalt.blogspot.co.uk/2015/07/describing-value-using-situation-cards.html

Other tips

• Consider if your stakeholders are distributed having two way video so you can see what they are doing and reactions to the product.
• Consider actually getting some interaction from your stakeholders. Invite them to play with the product in real time.
• You do not need to tell your stakeholders how many story points you completed.
• You don’t have to justify why stuff was not done.
• As ScrumMasters we can help this practice to be clear, transparent and engaging to the attendees. Use the walls and visualisation to help the session.
• If the Product Owner cannot facilitate the Sprint Review as they are out of the office. Ask for a volunteer to do this the same as any other the session.
• NEVER CANCEL! I have only ever cancelled 3 in eight years and 1 of those was because it was Christmas.  If you are cancelling these, its probably because you are hiding something.

If you take one thing from this blog, then that should be.

‘The Sprint Review is more than a demo, it’s about gathering feedback, inspecting and adapting’

My friend suggestion for renaming was ‘Sprint Product Retrospective’

My friend, is the funniest man in Agile….Nigel Baker

Finally….

I asked Paul Goddard for a tip of the week. He said ‘Listen with your eyes closed, you hear much more!’

Did you know that in original Scrum books by Ken Schwaber he talks about one of the roles of a ScrumMaster was to get enough chairs for the Daily stand up?  The first pilot company also used to take significantly longer than 15 minutes also. Oh how we have evolved

If I said to you ‘The Daily Stand Up’ what words immediately pop up in your mind?

The words or phrase that pop into my mind are:

• Synchronization
• Swarming to release value

It is so easy to forget what the key outcomes of a Daily Stand Up meeting is and get caught up in the mechanics of it.

In a nutshell we want:

• Team members to talk to each other and collaborate on the work that has been committed to.
• To understand what problems are impacting us and what any potential upcoming risks are.
• What value we need to unlock from the board.
• Whether we can complete everything still we set out too. If not, there are expectations to be managed.

Did you know your most valuable pieces of work are actually the items that are waiting to be tested and deployed?  This is because we are only potentially a short stop away from benefits realisation or important feedback.  As teams we need to be focusing on ‘Finishing’ things, rather than starting new work. This might even mean that developers have to test!.  So a key outcome for me as an ScrumMaster is about teams swarming on getting whole items across the board and releasing the value early. 

There are a number of different ways to run them.  If you are in the early stages of Scrum you are quite possibly using the three questions:

• What did you do yesterday?
• What are you doing today ?
• What stands in your way?

Over time I expect teams will alter this for their needs rather than slavishly following rules.

I vary the technique depending what traits I see the team exhibiting.

1. I alter the three questions to just be.
   - What is everyone working on today?
   - What impediments or risks have we?
   - Can we still meet our commitment?  Handy to have your burn down on the board to aid this conversation.
   
   I tend to drop the ‘What did you do yesterday?’ questions as I trust that people come to work to do their best and that they are talking as a team where dependencies arise.  They do not need to justify to me what they did.  People shouldn’t feel as if they have to account for every minute of the day.
   
2. Walking the board is also a great technique and useful when you have non-technical people wanting to know when their stuff is going to be done.  This technique really helps with swarming.  This is the practice that Kanban teaches. Typically we work from right to left looking at what it is going to take to complete this work. It is an opportunity for the team to pair together to get items over the line.
   
3. If I have a team with lots of blockers, then I might just get the team to talk about these key items to see what we can do as a team to keep things moving.

I might vary running these meetings in different styles on a daily basis to get different information shared. You don’t have to do the same style every day. 

In whatever technique you run a key thing I see happening time and time again is ScrumMasters being reported to or ‘Running the meeting’

We need to think about how we can stop this from happening, They are not there to report to you!

Top Tips

• Did you know that the ScrumMaster doesn’t even need to be at the Daily Stand ups?  The team should be able to facilitate this for themselves and manage their impediments.  Pop off for a cuppa and see if you team springs into action!
  
• Don’t stand in front of the board.  We should be as standard facilitating from the back of the room and so the focus is not on us.  If you have not heard of facilitating from the back of the room….find out!
  
• Don’t call out the name of the person who you want to speak.  Use ‘Who’s next?’
  
• Use a prop such as a ball to get the teams to throw around and speak.  This helps them to decide who they want next to speak.  No one is looking at you either, because they are focusing on the person with the ball, and then not dropping it.
  
• Rotate the role of facilitator around the team, let them all have a go.  I used to play ‘Spin the pen’ and if it lands on you, then you are facilitating for the day.  If some people are nervous of this, then it’s a perfect coaching opportunity for you.  Always ensure that you give the facilitator positive and improvement feedback.

The meetings should be in a regular heartbeat and so teams know the time and the place of the meeting as standard.  The time to update the board is NOT during the meeting.  People should be doing this on a regular basis throughout the day and not just saving it up.  This will help you to keep it to the recommended 15 minutes per day.

Did you know you don’t have to run these in the morning?  Teams can actually choose whatever time is best for them.  You can even have more than one a day if you are working on critical tasks. Some teams even have them last thing in the evening so that they are set up for the day to come in and get cracking. The key is whatever ever you do the team is getting value from these sessions.

A technique that I adopt to validate this, is to ask the team members to raise their hand of they feel they are not getting value, because maybe the conversation has diverged into problem solving.  This is a sure fire way to make sure that you keep things on track.

We keep the sessions to 15 minutes to promote valuable synchronization. The chances are if they are taking longer, it’s because you are problem solving or not talking about relevant items.  One team I had used to take 20 minutes to complete their stand up.  This was fine, because the value they got was worth the time they spent together.  Try and avoid extending it out much further

If you do have lots of problem solving, then maybe your need to book 15 minutes after the Daily Stand up so the team can then brainstorm what they need to, but have a clean finish to the previous meeting.

The most powerful tools we have as ScrumMasters is observation and facilitation.  Observe what you are seeing and always challenge whether we can improve the way that we work.  Use your facilitation to guide the team and to help them decide and achieve for themselves what needs to be.

We are there as ScrumMasters to grease the wheels of the teams, reduce lead times, protect the values, principles and practices and to ensure that we continuously improve ways of working.  Quality is also at the heart of everything we do.

So reflecting on your daily stand up meeting today, what could  you do differently.

I want to thank: Nigel Baker, Geoff Watts, Bazil Arden and Alex Gooding.   I asked them all what their lesser known top tips or facts were in preparation of this article and they provided their input.

Tweet.

Had another glorious day out with my nephew last week. This time I took him to Blakeney for a picnic, more crabbing and then we went out on Beans Boats to see the seals at the point. I love animals and going to see the seals has become like a pilgrimage each year for me. Disappointedly we did only catch 5 crabs, but I blame my brother who forgot the bacon. Fish heads just did not cut it!

We also had the Agile Coaching Exchange (ACE) with Nigel Baker who presented his Optimus Prime and Change session. It addresses organisational evolution towards a Scrum Method. Nigel is one of the funniest people in Scrum I know and he didn’t disappoint me on the night, his humour was on form. Most amusing had to be the teaching of the pisello technique. Well you have heard of the pomodoro technique of time boxing for 20 minutes, well this is the time boxing of 20 seconds. It translates to Pea!

So on the topic of changing organisations I want to talk about one of the key challenges that I tend to come up against.  When people ask me what the best part of my job is I say ‘people’. Ask me what the worst is and I say ‘People’

Every coach has faced people who are happy with status quo and don’t outwardly support the way the organisation is heading with its delivery method. So as coaches, how can we help them on the journey?

A few years ago I was introduced to the 3 zones model.

The Comfort Zone

The comfort zone is where we are the majority of the time. It’s the location of the skills and abilities we’ve built up over our career. In the comfort zone we are the most ‘comfortable’ . However we cannot develop ourselves and build new skills when we are in this zone. It consists of the abilities we can already do easily.

The Panic Zone

Have you ever become so worried you can’t focus? Then you’ve probably been in the panic zone at some point of your life.  Activities in the panic zone are so tough that we don’t even know how to approach them. The overall feeling of the panic zone is that you are uncomfortable and possibly discouraged. Like the comfort zone, we can’t make progress or learn in the panic zone.

The Learning Zone

Between the panic zone and the comfort zone is the learning zone. You only develop yourself further by embracing activities that are in the learning zone. The skills and abilities that are just out of reach are in the learning zone; they’re neither so far away that we panic nor close enough where they’re too easy.

So how does this relate to organisational transformation?

When we go into organisation as coaches and come across resistance, it means that we have possibly pushed people into the ‘Panic’ zone. We have to identify what their panic is and then work with them to resolve it. Here are a few examples of ‘panics’ that I come across most frequently:

• What does this mean to me? Will I still have a job?
• What if I cannot do this new role?
• I do not want to dilute my skills
• I was a manager, am I not anymore?

There are many more examples, but we need to consider how we approach the change and not push people into ‘Panic ‘ and shut themselves down. We need to articulate the change through a vision and ensure that we know what the current end state is anticipated to be, and how people fit into that picture.

We need to anticipate that certain people will need 121 coaching to help support them through the change and consider how they can be incorporate into the change to help influence others.

People are at the core of our business and so we need to invest the appropriate time and effort supporting them through the change and our lives as coaches will be easier.

There is another category of people who do not openly show their fear with reluctance or negativity. These are the ones who claim to get and support Agile, but their behaviours tell you otherwise. They think they are being cunning to disguise their true feelings, but it’s pretty apparent. The above won’t work for them, but I reckon that's another blog in itself!

Final thoughts

I want you to consider your approach to working with individuals, teams and organisations and how you can coach them to be in the optimal place of the Learning Zone.

One of the best bits about working in London is the number of restaurants you have at your disposal. Being from Norwich I have pretty much been to every restaurant in the city so it is exciting to be faced with so much choice in London.

My most recent quest has been to find the best steak in London. Luckily, I have a couple of friends who help me indulge in this pleasure and we have been working our way around them.

Part of the experience at the end of a meal is a retrospective on where we think the restaurant rated on the Meek Scale. The scale is based on:

• Taste
• Cost
• Ambience of restaurant
• Service
• Portion Size
• Value for money

Taking all of these into account we rate the restaurant out of 7 and I have formulated my list of favourite restaurants. Being a geek I have not just done this for steak restaurants, but for all restaurants I have visited in the last 15 months I have been in London. As you can imagine it is quite a list

I guess this information would be valuable to the restaurants as I would expect they continually look to improve the experience for the customers and best practice for their staff.

So why do we not do this for the teams we are working with?

Well firstly we would never want to rank teams or have the information used as a stick to beat them. But the concept of holding a team retrospective based on the best practice we see in really high performing Agile teams sounds useful.

At my last client I introduced something called Evolutionary Stages to of the teams. I cannot take sole credit of this as it was initially created by Steve Garnett, however the other RippleRock coaches and I certainly drove it to the next level of adoption.

The concept is a tool that enables teams to self-reflect on where their Agile, development and testing practices are compared to best practice and taking it one level further to the company’s long term goals.

I have written a user experience report on our journey and findings for your enjoyment.

Final Thoughts

Continuous improvement is vital in the tough and changing world that we live in. If organisations are going to continue being profitable and market leading we cannot afford to rest on our laurels. We need to be continually thinking about evolving ways of working.

Evolutionary Stages is a great tool to help you focus on team and organisational practices, tracking from start to the end point of your journey. We often forget about our starting point and fail to celebrate our successes along the way. Let’s stop and celebrate what we have achieved.

If you happened to be interested in my list of ratings for restaurants I have visited – then drop me a line and I will send it to you

Tweet.

It’s been a pretty interesting couple of weeks with my adventures taking me to Kingston for a new client (note don’t get on slow train!), holding the Agile Coaching Exchange with Liz Keogh, and waving good bye to a client I have spent the last 15 months with.

For those that couldn’t make the exchange this month you missed Liz talking about complexity theory, and I have admit she managed what two others couldn’t do and that was to really help me to understand what Cynefin is. I think the breaking point was the inclusion of an exercise that made it seem real to me, and working in groups that helped to reconfirm the learning. I am not sure I am ready to write a blog about Cynefin yet, so I have included a few photos of the event and a link to Liz’s blog who covers it a whole lot better than I would. Thank you Liz!

Next week I am pretty excited to be attending the David Anderson Train the Trainer Class as part of the Lean Kanban University. It will be the first time I have met David and I am hoping to extend my knowledge further to really support driving good Kanban in organisations. It doesn’t hurt either that it’s in Turkey. I am sure I am going to have loads of good stuff to blog about on my return.

Photo of actual place of learning (wooooooooo!)

So my topic of the week is something that my colleague Mark Summers and I presented recently at both Scrum Gathering Las Vegas and XP2013 Vienna. It is also something that we both are very passionate about Growing ScrumMasters for the Future.

The challenge we faced was an organisation that was growing vastly in size and with an enormous intake of new ScrumMasters, who had a varied degree of experience and knowledge. We wanted to be able to support them in their knowledge and create a safe learning environment for them to put key skills into practice. From that point forward the ScrumMaster Education Programme was created.

Over the 6 month period that we ran the programme I put together an experience report of what we did and learned. I wanted to share with you that report so you can read and see the success that we had. Building this programme and watching our ScrumMasters grow was something that I took great enjoyment from and something that I am pretty proud of.

Click here for the ScrumMaster Education Programme Experience Report

Click here for the ScrumMaster Competency Framework

Even though I am leaving this client, I am happy in the knowledge that we have built a strong community of practice, and that they will continue to educate themselves without me. I have no doubt that we have been nurturing the Agile Coaches of the future.

Good bye guys, I am going to miss you all.

Final Thoughts

Learning is often something that gets pushed to one side when all hell breaks loose in the office. We practice Continuous Improvement in our teams, so why do we fail at doing this personally?

My mission for you is to learn something new this week.

Tweet.

I love being an Agile Coach! However it has its ups and downs, such as you inevitably end up coaching yourself into something you didn’t want to do or face.

My latest self-coaching started when ‘The boss’ brought up again about me blogging. I found myself making the usual excuses and moving on the conversation swiftly. It was only on my end of the day self-retrospective I asked myself ‘What am I afraid of?’ and so here I am blogging.

Damn I’m a good coach!

On further reflection I started thinking about all the good and bad experiences I have had and so this is the start of me telling you about them, but firstly I want to tell you a little bit about me.

So where did it all start? Well on June 3^rd 197x…..…only joking!

My history is of an IT Project Manager working in a large insurance company. I was there for 12 years and I am thankful for the people I met and everything that I learnt. It was on one of these cold Norwich mornings that one of my developers said to me they wanted to do iterative development on my 'traditionally' led project. I look back and laugh now at my dismissive response and realise now how much I have grown and changed. I was that command and control Project Manager, a pretty fierce one at that.

It was a year later that I was introduced to the woman who would become my Agile yoda and change my belief of myself, how we deliver projects and how to structure organisations forever. It's through the coaching and mentoring of her and many others on my journey that have got me where I am today. I think that everyone who knew old & new Helen will testify to the massive change in me and it’s something I am very proud of. Who said you can’t teach an old dog new tricks :)

So fast forward to 2012 and I was fortunate to become one of the Ripple Rock family and be given the opportunity to go out and do what I love and feel passionate about.

So what am I passionate about I hear you ask?

· Shopping  - I am obsessed and had to snigger when ‘The Boss’ told me I was thrifty this week. He has obviously not seen my designer bag collection or the massive wardrobe I am now building myself.

· People - My mission is to meet as many people and teams as possible and to really coach them to be the best they can be, Agile or personally.

· Organisations - I want lean mean feature team machines (nice ring to it!) My mission is not to sell Agile to organisations but to coach, guide and mentor them to realising the benefits that are important to them and their customers.

· Community - I am all about the Agile family and actively look to bring people together, share knowledge and to have fun. So I am one of the co-founders of the Agile Coaching Exchange (ACE). Look this up for now, but no doubt I will be telling you all about it in the near future.

So that’s a little taster of quirky ole me, hopefully you are still reading and might even want to pop back every now and again to see what’s going on in my world.

Final thoughts
I have faced my fear today. What fear do you need to face?

Helen