Archive

Archive for the ‘Agile’ Category

Sprint Planning

September 23, 2016 Leave a comment

This post is meant as a few hints and tips for new ScrumMasters at Sprint Planning.  None of this is meant as this is how you have to do it, but it could be a starting point from which you can inspect and adapt.

Sprint Planning

When I started as an Agile Coach back in 2007, many teams were struggling with Sprint Planning because they were uncomfortable with uncertainty, or the Product Backlog didn’t exist or was in poor shape.  Either of these may result in very long Sprint Planning sessions.  Interestingly I am seeing a lot of very short Sprint Planning meetings these days, where 30 minutes is taken to select items for the Sprint, with the team hardly saying anything, sometimes only 1 person is speaking.  This is very efficient, but kind of misses the point of Sprint Planning.

Objective

  • Agree WHAT we are committing to as a team
  • Plan HOW we are going to meet this commitment

With modern implementations of Scrum, with a well refined Product Backlog (which the team have been involved in refining), that first part might be quite fast.  The second part is what I now see some teams skipping, there is no conversation about how they are going to do the work.  Often this is a symptom of them not really being a team.  So to a few tips for new ScrumMasters:

Have a Goal goal

Many teams struggle here because the top of the Product Backlog is an unrelated collection of items.  Sometimes this is done to make sure the whole team is busy in the sprint based on their specialisms.  If you do this you will never have a real team, and that maybe ok.  Scrum however is a team game, in the pursuit of a cohesive goal, that represents the value we are going to deliver together.  Therefore the first thing you do in planning is decide what you want to achieve in the next Sprint and then select the work that you will need to do.  This is the WHAT part of Sprint planning.  Don’t talk about How until everyone is clear about What.  The goal creates clarity and a sense of purpose.

Get Commitment

Get commitment of the team to the Sprint Goal.  Maybe commitment is a dirty word these days, some people prefer forecast.  However real teams are not afraid of making commitments to each other, not to managers, to each other.  Scrum works when the team decided what they can achieve and hold each other accountable for delivering it.  Therefore they must believe their goal is achievable.  Involve the team in the creation of the goal, that way they have even more skin in the game.

It’s a workshop how

It’s a workshop not a ceremony or a meeting.  Most of Sprint Planning is going to be a technical workshop about how they are going to achieve their Sprint Goal.  If it helps call it a technical workshop, maybe the team knows what that is.  There is nothing worse than everybody siting round a boardroom style table, calling the same tasks out for each Backlog item.  I suppose doing the same thing on different sides of the world is slightly worse.  The team will not be engaged.  As a ScrumMaster ask the team how they are going to achieve their goal and get out of the way.

Be Prepared

Be prepared as a ScrumMaster, but don’t get rigid.  An Agenda can be useful to you and the team, but you will deviate and thats ok, so long as it helps the team.

Don’t touch the pen

As a facilitator, don’t be at the front of the workshop capturing everything on index cards and sticks (or in your tracking system).  Sprint Planning is not where you need to put in your star performance at the centre of the stage.  Think of yourself facilitating at the back of the room, observing what is happening, when the team get stuck that is when you step in with an observation or question to move the team forward.  One rule I have is to never touch the pen, unless it is to hand one to a team member.  In this way the team own it.

Categories: Agile, Scrum Tags: ,

Bringing Joy to the World of Work

January 9, 2015 2 comments

In 2008 I was inspired by Richard Sheridan of Menlo Innovations, and their human focused approach to work. Following his key note at the Berlin Scrum Gathering I think a good focus for everything I do this year would be to bring Joy to the world as I interact with it.

Potential Areas of Interest for the Year

Following a bit of brainstorming with Helen Meek around potential sessions for conferences, we came up with six possible topics, but actually they are also areas of focus for reading, research and writing.

  • Risk
  • Release Forecasting
  • Motivation
  • Coaching
  • Transformation
  • ScrumMastering

Risk

I spoke about using Agile approaches to reduce Risk in 2008 at the Munich Scrum Gathering. Actually I still don’t think we focus on Risk enough, or we focus on the wrong risks. Risk should be part of the value proposition, risk is uncertainty and when we think about Value, yes we should think about customer value, but also validated learning/reducing a risk; maybe so that we don’t build something, this is also valuable. The Risk I see turn into an issue a lot is inherent schedule flaw, where others make commitments on behalf of the team, often based on making the sale rather than on any real notion of how difficult it is to deliver. As yesterday’s issues are likely risks for your next endeavor, lets learn and surly life will be more joyful.

Release Forecasting

Not always necessary, but it can be an effective tool to build trust with your customer(s). So simple, yet it takes discipline to do well. Having a backlog refined appropriately, taking into account that your backlog will probably grow, making promises based on a too optimistic planning velocity. It’s about openness and honesty so that better decisions can be made as early as possible. Which is surly a more joyful relationship than one based on smoke and mirrors and bad news at the end.

Motivation

It still surprises me how often managers do things that de-motivate the team, and either they are unaware of it or they don’t care. It is hard to motivate people, but really easy to demotivate them. People generally join a company motivated, but get worn down by things that are getting in the way of them doing a good job, they enjoy the work, if only they could just do it.

Coaching

Coaching as a discipline is an important skill that needs to exist in managers and teams alike in order promote the collaborative culture, where an Agile approach truly thrives. It is that collaborative culture where I see joy at work. This area is also about me improving as a coach.

Transformation

Many of us will have been involved in both successful and unsuccessful transitions (please provide your own definition of successful). When it is successful I have seen that joy. What have we learned from the failures? What was right about the success? What can we do to have more joy and less bahhhh.

ScrumMastering

The ScrumMaster is a change agent, seeing problems and helping the organization improve for the better, this role should help bring Joy to people by improving their ability to do a good job and have great relationships at work. However often the role is another word for Project Manager, or the technical lead is given extra responsibilities. There are also lots of CSM’s but very few experienced and skilled ScrumMasters.

Six area’s are too many, which area could do with the most work, what would bring you the most Joy?

I will at least commit to writing a blog on each area this year

Wishing you Joy for the upcoming Year

 

CSM and Lean Kanban Foundation with Visulisation

December 8, 2014 Leave a comment

A new experiment in London see’s me partnering once again with RippleRock, together we are offering a series of courses beginning the week of 16th February 2014.  The Certified ScrumMaster and the Certified Lean Kanban Foundation courses will be as interactive as ever, but will also benefit from graphical recording by Stuart Young from Illustration Station.  We are also putting on a Visulisation/Artistry workshop, which will be free to those who sign up for another course.  Each of the courses tells a story in its own right delivering value to those who attend; together the courses are trilogy, exposing attendees to a variety of practices, techniques and concepts for the Agile practitioner.

  • Certified ScrumMaster course, this CSM course includes graphical recording to provide a visual record of your learning experience.  With Mark Summers and graphical artist Stuart Young.  Includes the Visual Artistry workshop for free. (19-20th February 2015) +free visual artistry workshop – £950+VAT
  • Visual Artistry Workshop.  Learn how to use visual artistry as a tool to initiate projects, enhance learning and have fun with your teams.  With Graphical artist Stuart Young, supported by Agile Coaches Helen Meek and Mark Summers. (18th February 2015) – £400+VAT
  • Certified Lean Kanban Foundation.  Learn all about Kanban, once again your experience will be captured graphically.  With Helen Meek and Stuart Young.  Includes the Visual Artistry workshop for free. (16-17th February 2015) +free visual artistry workshop – £950+VAT
Stuart Young

Stuart Young of Illustration Station

Questions to get your Kanban System up and running

March 21, 2014 Leave a comment

Working with a team recently after some initial Kanban training we used the following questions to help us focus and get our Kanban system up and running.

The first question

  • Why do we want to use Kanban?  – If we can’t answer this stop, and it needs to be better than because we have been told to

Questions around the Work and how it flows

  • Are there different types of work that you deal with?
  • What happens to the work? -This is where we mapped out the flow of the work
  • How are we going to limit work in progress?
  • Do we need to respond differently to certain types of work? -different classes of service

Questions around our policies

  • When can work move into columns? – Entry/exit criteria
  • How does work come into the system? – Who puts work in the input queue/how often?
  • How does work get released from your system?

Questions around feedback mechanisms

  • How are we going to get feedback on the work from customers/stakeholders? – feedback on the what
  • How are we going to reflect on the process? – feedback on the how
  • How do we ensure that we are building quality in? – how do we get technical feedback?

These were some simple starter questions to get us started, however we expect that the answers to these questions will change as we continually improve and as your world changes.

Categories: Agile, Kanban Tags: , ,

Scrum Coaches Retreat Phoenix

December 4, 2013 Leave a comment

Another long trip over to the states this week to attend the Scrum Coaching Retreat in Phoenix. My main reason for attending is that I am involved in bringing the event to Europe for the first time in 2014.

The retreat is unlike a conference or gathering, which sometimes only scratch the surface on topics; here you will go deep into issues that you are passionate about.

I am also hoping to get involved in some improvement initiatives in the CSC programme, either:
• An improvement of the application process, or
• Looking at how we better support coaches on their development path

That second issue is likely to be a central theme for the first European Scrum Coaching Retreat in London from 9th to 11th June 2014. Some information about the event is already here.

And you can register here, to get an early bird price

We will have our own website up shortly. I will keep you posted on anything interested that happens in Phoenix.

A testing bottleneck in my Scrum Team

July 14, 2013 Leave a comment

Recently I was working with a Scrum team who were struggling to get things to Done at the end of a Sprint, they already knew that they had a bottleneck getting things tested, but didn’t really know how to resolve it.  They are certainly not unique in having had this struggle, and it was really costing them partially done work, tester working long hours at the end of the Sprint, a code freeze 3 days before the end of the Sprint.  I also sensed frustration because they felt things couldn’t improve unless they changed the ratio of developers to testers (6 to 1).  That wasn’t going to change immediately and I do like to focus the team on the art of the possible, so what could we do?

I knew I needed to do a little bit of education on dealing with bottlenecks, therefore I gave them a 10 minutes intro on the 5 focusing steps from the Theory of Constraints and then we did a retrospective to come up with some specific actions for them to take as a team.

Identify the systems constraints

The team had already identified that the tester in the team was overloaded with work, especially at the end of the Sprint.  Unfortunately the tester was also starved of work in the middle of the Sprint.

Decide how to exploit the system’s constraint(s)

In this context this basically means looking if anyone else in the team can do some of the testing work.  This is also a subtle way of introducing the team to the idea of taking a whole team approach to quality, without telling them that’s what they need to do.  The kind of things that came up in the retrospective here were:

  • Look for opportunities for other team members to help out with the writing and running manual tests. (The team did not yet have any automated acceptance tests)
  • Other team members helping out with setup activities, i.e. environments
  • Production of tools that would allow the testing work to be done more effectively

Subordinate everything else

For us this meant looking at changing the way we work to get work to flow more evenly.  In this area we were looking at how we breakdown work and work more collaboratively as a team:

  • Break down items into smaller chunks so that they can get into test earlier
  • Write stories so that they are testable, so that parts of the story could be tested earlier
  • Create opportunities for earlier feedback from test, reduce waste of fining errors on test environment
  • There is no such thing as a bug in a Sprint, its just work that needs to be done before  the Story in Done
  • Limit items team is working on (Items in Progress), team members swarm on items
  • Investment in Automated Acceptance Tests, which would allow the developers to take some of the testing burden

Elevate the system’s constraint(s)

This is looking at how we can increase capacity or capability in the bottleneck area.  Which for us would mean hiring more people with the testing skills or providing some kind of training (be it formal or on the job).  You should only be thinking about this if you have tried everything you can think of in the previous two steps.

What the team agreed

The immediate things the team agreed to do were:

  • Breaking stories down smaller and also looking for opportunities to commit code regularly, as soon as something can be meaningfully tested
  • Involving the tester in design activities, so that the team could design/implement with testability in mind, also as a result there was less of a handover
  • Regular demo’s to the tester and Product Owner, whenever there is something to show
  • The tester would continually ask “what have you got to show me?”
  • Toolset to support Testing Diagnostics

It wasn’t agreed in the retrospective but subsequently they also started to get other team members helping out with testing tasks as well.

As a result of these actions, the code freeze was no longer necessary and the test activities were more evenly spread throughout the Sprint, they had less partially done work.  So this is a good step in the right direction.  To take it to the next level the team will need to focus more on swarming and investing in automated acceptance testing.  If they can start to do that over their next few releases, then the perceived issues of the ratio of developers to testers may become a mute point, as the team adjusts its skills and practices to be able to deliver high quality work.

Helping people with Kanban

January 29, 2013 Leave a comment

I have found that supporting people using a Kanban approach can be very rewarding.  The people I work with are generally passionate about what they do, therefore giving them tools that will help them evolve their way of working has met with enthusiasm.

For those people who are continually saying “we don’t want to throw the baby out with the bath water”, then Kanban could be a good starting point to improve the way they work.

I have also started running an introductory Kanban training course, typically with training I like to stay out of context to ensure that people understand the concepts.  However I am finding that with Kanban it such a great learning opportunity to put aside some time at the end of the course to apply the practices directly to attendees own context.

Categories: Agile, Kanban, Learning