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

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.

Last week I was fortunate to go to Sapanca in Turkey with the Lean Kanban University (LKU) for the Train the Trainer (TTT) course. It was a little daunting to work with 7 other candidates that I didn’t know from all over the world; however we soon bonded as a community in a shared goal.

Class of Sapanca July 2013

It was great to finally meet David and some of his team who came with him (Mike, Dragos, Janice, Agnes and Mihaela) and to hear the journey they have been on with Kanban. The stories and learning they shared were extremely valuable and really helped me to understand how others across the globe had gone about their adoption and the roots of Kanban.

The course also highlighted that no matter how much we think we know as coaches, there is so much more out there to learn. Whilst it was a challenging week, I definitely believe I have grown in my Kanban knowledge and feel confident to co-train my first course next week. I am actually excited about the opportunity to share my knowledge and passion for Kanban as a newly Accredited Kanban Trainer (wooooo!)

Back to the Basics

I love the fact that Kanban (like other methods) has Values, Principles and Practices and this is something that I use and quote regularly to keep me true to what I am practicing. As practitioners & coaches we need to keep these close to our hearts and make them part of our everyday life.  You would not believe how many situations I find myself in day dreaming about flow optimisation. I can’t even go to Mc Donald's now after Kanban Dan ruined it for me with his drive through flow scenario

Lets take a minute to remind ourselves what they are:

The Values

1. Understanding
2. Agreement
3. Respect
4. Leadership
5. Flow
6. Customer Focus
7. Transparency
8. Balance
9. Collaboration.

There is an awesome blog by Mike Burrows in this area.

The Principles

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current roles, responsibilities & job titles
4. Encourage acts of leadership at all levels from individual contributor to senior management

The Core Practices

1. Visualize
2. Limit Work-in-Progress
3. Manage Flow
4. Make Policies Explicit
5. Implement feedback Loops
6. Improve Collaboratively (using safe to fail experiments)

I challenge you on your perceived knowledge of Kanban . There are so many misconceptions out there that it’s just about visual management, but it is so much more.  Kanban is an evolutionary method that uses scientific theory to enhance the flow of work in the system. There is also a misconception out there that Kanban can only be used in manufacturing, but this is not true. It can be used in software delivery, but also any knowledge work.

Kanban doesn’t imply that it is the end to end solution and recognizes that we pull from many different tool boxes in its application.

Part of the TTT course was based around the AKTs bringing case studies for how we have  implemented it in the organisations we work for and so I have not only experienced this first hand for myself, but seen other organisations deliver great results also.

Final Thoughts

What beliefs have you formed about Kanban or any method without really understanding what is at the heart of them.  We are often dismissive on little facts or one negative experience. Like learning to drive, maturity comes over time and with practice. Chances are that we may have a prang or maybe even a write off, but we still continue to drive and learn from the experience.

Consider getting yourself on a course and see how an AKT can open your mind.

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.