But.... Where do I start?

I have been with a few teams now and I was reflecting on how I deal with each transition. I also paused to think how the teams I work with feel too, given we are both in a new unfamiliar situation.

So what have I learned?

1) Pause and think about where your team has been (and what they have seen)

Joining a new team, I am always interested in what they are doing. I think we should be more interested why they are doing it.

We often use the word journey and that's what I'm interested in more than the outcome. If we take time to understand how the team got to where they are, we can often understand more about what drives them, what scares them and how we might be able to help.

One team had a whole load of history which resulted in some seemingly odd behaviors. It all made sense once you understood their journey. This cannot be told by any single person - I heard several versions from several people and somewhere in there was what really happened.

Being sensitive to what the team has been through has been a key learning point for me. It has helped me tailor my own behaviors, language and coaching to get better results from the groups and individuals I work with.

2) Assume the best at all times, especially about people

Despite everything I can see and observe, I have to assume that people are doing the best they can, given the situation they are in and what they know. This is liberally taken from the Prime Directive, which is often used as a kick off to retrospectives.

To me, this applies at all times. It should be our go to place, even with people and teams we have only just started working with.

In one interview, we were doing an exercise where we show a board and ask the candidate what they can see and what questions they would ask of the team. There was an obvious issue where the same avatar was on 3 cards in the development column. The candidate went to great pains to say what the developer is doing wrong and it was not helping other problems they could see on the board.

They never once thought about why the person was doing that and that maybe they are doing things for the right reasons, given their own situation.

What if they were a contractor who was really worried about their renewal and wanted to show how productive they were? What if they had to pick up extra work because someone was on holiday and their stories had not been completed? What if the person really was working on these 3 things by putting in a load of extra hours because they were trying not to let their team down?

3) Make it all visible. Even if it doesn't look good.

At first things often look OK. It's only with transparency do we start to see the problems. Issues are often hidden away and need a bit of coaxing out so we can see the causes.

This takes some guts as people might not like what they see. It is the start of how we adapt ourselves and our processes - without being able to see the problem, you cannot start to fix it.

Transparency not only shows this to the team but also to the world outside the team. This is both a blessing and curse since you may have to deal with attention that you would prefer not to have. In my experience, the benefits definitely outweigh the problems.

4) It not about 'the' process it's about 'a' process

I like scrum. I also like kanban. Some teams need one, some teams need the other. Some teams need something else. Sometimes we need to start with 'something' so we can start to own it.

If a process is intended to evolve, when does it cease to be what it started out as? What makes Scrum, Scrum or Kanban, Kanban? If we embrace being able to adapt, our process will change as we solve problems and find new ones.

The right process is the one that helps the team build software in the best way for them. Often this is dealing with the situation they are in and the problems they face internally as well as externally. It changes over time as our situation changes.

Key to this is encouraging the team to own the process, to be invested in it. For me, a sign of a mature team is owning actions from retrospectives with the same responsibility as they have for building quality software. They are invested in both equally because combined they allow them to achieve their goal. This is built slowly over time with enthusiasm, retrospectives and responsibility.

Resist the urge to replace what the team have. Work with what you have and remember point 1.

5) Give the gift of consistency

In my experience, most things have already been tried by teams who have been around for a while.

Just because something did not work in the past does not mean it will never work. It might be that the time was not right. It is more likely it was not given a chance.

The difference between trying something and using something is consistency. You need to consistently do something for a while until it becomes habit.

These can look like rules and my goal is that these are owned by the team not mandated by myself. You know they have become habits when individuals would defend them if they were taken away.

Being consistent about applying something new is the enabler that allows this to happen. I was pretty terrible at this but I have seen the benefits of being rigorous in applying something new, so I had to learn how to do it. You know you are getting somewhere when others uphold the consistency too.

Why I hate 'Best Practice'

I hear the words 'best practice' almost every day. My eyes roll over and I look vexed. I don't mean to, I just hate this phrase.

I live in a world where we make things transparent so we can inspect and adapt.

How does this work with 'best practice'?

By adopting 'best practice' we are making the assumption that this is the ideal, that there is nothing left to learn.

We might also put this all in a locked box so we can't change it. It is 'best practice' after all - you will probably mess it up if you play with it.

So when one of my team recently said he could not change the QA 'best practice', I suggested that we absolutely needed to try.

Together we proposed we do something different - based on observation and experience - that might make the process better. We decided to run an experiment to test our own theory that the 'best practice' was flawed and can be improved.

We proposed how we could evolve the process and measure it's impact so we can decide whether we should keep the change.

So what is 'best practice' in a process that designed to evolve?

To me, it is the last thing that worked.

This might not be the last thing you tried since you always have scope for experimentation and learning.

In my world, nothing can be 'best practice' since we can always improve it.

Now that's what I call a plan.

Creating a bunch of stickies never felt like a satisfactory result from planning. This is a reflection on the progress made by one team to create a real plan of how to convert story into software.

Stage 1 - Creating tasks without conversation

The team's planning session creates stickies for various tasks that we need to develop the feature. This is led by only a few of the developers and it is almost entirely directed by them. The stickies represent pretty big elements of work and the estimates are pretty high - most are over a day in length. There are very few testing tasks, which are created by the QA guy only.

Observations:

• The team aren't thinking how to do this work - someone else has decided and are dictating the tasks as they see them
• The tasks are not very granular so detail is being missed and the resulting estimate is not very accurate
• The team is not owning the QA - they are creating 2 teams which might not join up to deliver the work

Stage 2 - Experimenting with Diverge and Merge

A recommendation from our Agile Coach gets the team using Diverge and Merge to create tasks. The whole team creates tasks in parallel and then they merge their stickies. This breaks the dependency on individuals leading and makes everyone think about what needs to be done. Merging creates conversation as some people think of things that others haven't and we all reach agreement where we have the same tasks. To make this work, it is need to follow the work through sequentially. You can optionally play a game to see who keeps the most stickies on the board, which keeps the session flowing.

Observations:

• The team don't really buy into Diverge and Merge but the sequential story of what needs to be done makes sense to them
• Involving more of the team means we have less direction from individuals - there is more ownership from the team rather than following individuals
• QA still a secondary process within the team
• Tasks are still quite large

Stage 3 - Creating tasks sequentially

SM encourages the team to explore how to do the work sequentially, encouraging quieter members of the team to contribute. Larger tasks are broken down and things we often forget also take time are included like documentation, deployment packages, merges. The QA guy is still doing the same thing but SM asks them to explain the approach to the team, which does not result in a lot of feedback.

Observations:

• Following a linear path through the tasks makes it easier for the SM to pull developers into the conversation
• The larger tasks were hiding detail that we need to discuss in order to estimate - breaking them down helps reveal these
• Asking the QA guy to explain the testing approach helps to breakdown the 'us' and 'them' - it introduces the notion that the whole team should understand testing, led by QA

Stage 4 - Team ownership of Quality

We start the planning by talking about testing not development, which was an action raised in a retro. The team create a basic test plan and everyone estimates the test tasks. There are clear gaps in knowledge as estimates are wildly different - team estimates and indicates which tasks need pairing for knowledge transfer.

Observations:

• Talking about testing first influences the order they develop in, so the tasks are a little different.
• The testing plan being known by the team means they can shift between development and testing tasks - this gives the team more options as to how they deliver the work during the sprint
• The knowledge sharing is clear and improvements are found easily as a part of the process - no retro needed for this one

Stage 5 - Team collaborates on an approach

The team realise some stories need more thought. If left to the sprint, these decisions need to be made by a single developer rather then by using the wholes teams skills. A retro action is to use a whiteboard session to discuss the approach before a story is started. The sessions visually describe the areas of the system making it easier to spot difficulties or additional tasks that might be missed with conversation alone.

Observations:

• Pictures work better and getting people to explain using the diagram helps too
• This is very Just-in-Time - is there an earlier opportunity for this?
• Some areas of discussion maybe go too deep - the team sometimes dive a little too deep into implementation.
• A retro action from the team empowers them to huddle if they need team ideas/consensus - this helps counter only one or two developers deciding things without anyone else knowing

Stage 6 - Planning using a whiteboard

The team move the whiteboard session to planning and then decorate the system areas using tasks as they follow the development sequentially. The team discuss testing as a part of the conversation, making testing more integrated into the development. By grouping the stickies to areas of the system, they are able to see how many of them could work on the story at the same time.

Observations:

• The combination of a picture and sequentially discussing the development works nicely - it helps expose tasks the team has frequently missed
• The team is starting to think more about how the tasks could be done in parallel by picturing areas they can work on without tripping over each other
• Testing tasks are easier to spot - impacts on existing tests are highlighted quickly

This journey took quite a few sprints. There were regressions as well as advances but when I look back I saw these stages of development. The retrospectives drove many of the changes but we also saw spontaneous creativity - using the whiteboard sessions to plan against, is a good example.

The key thing I saw from the team was a shift in focus. Instead of planning how to do the development, they are now thinking about how to deliver the story. This goes further than a list things to do - it should aim to answer the questions:

• What order is best to do these tasks in?
• Who has specialist knowledge that we need to leverage?
• What does testing look like for this story?
• How can everybody assist with testing?
• How can we get everybody working on the same story?
• What do we need to knowledge share on for the future?
• What does the final solution to this look like?
• What are the 'risky' tasks?
• Who else might we need help from?

What does your 'plan' look like?

Why Scrum teams between 3 and 9?

We all read the Scrum Guide but have you ever wondered why the band of sizes that is prescribed?

Recently, I have been working with a large team which was 10 people (8 developers and 2 QA). It was interesting to see the problems that came from this size team so I thought I would jot them down.

Problem 1 - Capacity
If you have a large team, you end up with a large capacity. A 2 week sprint for 10 people means an epic 540 hours (6 hours a day for 9 days, after taking out 1 day for ceremonies). That's a lot of work to prep and get ready! Most sprints we found it difficult to prep enough for a commitment against our full capacity, forcing us to bring more in mid sprint.

Problem 2 - Prep
Having mentioned prep, the larger the team the more difficult it is to get everyone focused. It also has the side effect of you sacrificing over a days development for each hour you prep. This is obviously scaled up, you cannot escape this - but the larger the team, the slower the prep felt which means the losses are amplified. We had an additional problem that our team area was not really big enough for everyone to see the ample 50" screen we used to access our backlog.

Problem 3 - Crowd Control
Prep and retro's were interesting times for the Scrummaster. Getting people focused and keeping them there was challenging. Finding a space which we could work with was a challenge. Prep sessions were either silent or we had too many voices at once, which we needed to work harder to bring everybody under control.

Problem 4 - Visualisation
Large capacity means lots of stories. We found it difficult to visualise the work simply because we could not get it all on the wall. This meant we often had stories 'waiting' to make it to the board. This made if difficult to see the full picture for both the team and the stakeholders.

Problem 5 - Ceremonies
With more people we needed more time for pretty much every ceremony - this ate into our sprint window. With lots of work the planning sessions often turned into epic half day marathons that everyone hated and retro's would take about 50% longer just because it took a bit longer to coordinate the team for each part of the retro.

Problem 6 - Sprint Composition
We had to be more careful about what tasks ended up in a sprint. With so many people, we often ended up with stories that blocked each other since they were in one area that shared code, unit or integration tests. This stopped us from being able to work in parallel on them. One sprint contained only stories for a single component, which caused us a multitude of delays as we tripped over each other repeatedly.

Counter measures we tried:

Split Prep - We did 2 rounds of prep, allowing us to sanity check the requirements and do investigation using the bare minimum of developers, minimising the impact on the team. Our desired outcome from this round of prep was that the developers involved would present the story to the rest of the team, replaying allows the PO to confirm solid understanding. By the time it got to the team we knew it could be done and had any investigation/spikes covered so it was all about spreading understanding of the story.

Timeboxes - when we had the full team at any session we enforced 1hr timeboxes. More than that and people were too fidgety to work with. If we needed longer we broke up for a 15min break to get refreshments and repeated the time box.

Diverge and Merge - in planning we asked the whole team to task out the story. There was obvious duplication but the differences were the interesting bits that leverages the teams different thinking on the problem - some people thought of things that others did not. We then had a game to see who could keep the most stickies on the board. This worked better than allowing one person to drive but was not always liked by the developers. Main benefit is you get everyone engaged.

Two Boards - for a while, we had 2 different boards for different classes of work. This allowed us to visualise everything but also meant we had 2 stand ups. Not going to lie, it was weird.

Two Retro's - we did 2 retro's for the first sprint so we could keep the groups small. Universally hated by everyone we did not do it again. The split was based on the classes of work we used to split the boards BUT people worked across the boards so it was very odd. Not recommended.

Huddles - we often had 2 standups a day to coordinate work. With a larger team, they can burn through tasks quickly when working in parallel on a single story. This meant more coordination that a single stand up was needed. Wasn't a bad lesson to be honest and we do this even now when tasks are not moving or causing problems.

In conclusion, the 9 boundary is probably arrived at from trial and error. We were only 1 person over the 9 but we saw some interesting effects - I would guess team 8 and up might see some of these issues.

We had 2 BA's as well as the PO and myself making the full Scrum team a whopping 14 people at the majority of the ceremonies. Although the Scrum guide only considers the development team, you might was to think a bit broader and how that might effect your ceremonies.

One question I was asked - why not split the team into 2? This team worked on a single product. Splitting the team would have meant extra coordination by the team to make sure that what they were working on was known about by the other team. The team were also concerned about knowledge transfer, which they had worked hard on in the last couple of months leading to much better product knowledge throughout the team - splitting the team could have set back this progress.

My sweet spot seems to be around 6 - large enough to deal with holidays and sickness but small enough to enable knowledge transfer. This also feels about right in all the ceremonies.

My Retrospective on my Retrospectives

I have been doing regular retro's for about a year since I changed direction career-wise. I have recently been looking over how my style has changed and looking at why these changes came about.

Working with an experienced Agile coach has certainly been the catalyst - Helen Meek has pointed out many areas of improvement which I have been gradually working on over the last few months. Other inspiration was from an amazing talk from a lady who works with kids on the Autistic spectrum called Gina Davies.

She describes how she centers attention around a box. There is something different every time in the box and the kids she works with respond to this by sitting and waiting to see what happens next. You don't realise how effective this is until you see some video - kids with ASD don't get 'waiting' but after a relatively short amount of time, they start to participate and want to wait to see what happens next. The box is 'magic' - something new happens every time.

So this got me thinking, what's my 'magic box'? The obvious answer is the retro. It should be fun and engage the team. It should be something we all look forward to. Here's my observations on things that I have changed over the last 6 months:

Keep it Fresh - One of the key things I have tried to uphold is to never repeat the same retrospective with a group. I mix up sections of the retro or come up with a dedicated retro to target a specific area that the team needs to improve on. Sometimes I am inspired and come up with something completely new, other times I spend some time putting something together using the awesome Retromat.

Experiment - Each team is different. Different styles and techniques fit with some teams and are lost on others. Experimenting with formats lets you continuously improve getting the team involved and engaged. You also learn what works for a given situation - your retro style and format may well change depending on the sprint and team morale.

Sit back, relax - Helen encouraged me to sit back and watch the team rather than stand up and direct. Sounds easy but your team may now be a bit lazy! By you sitting back 2 things will happen - first your team will need to get more involved and second you can observe your team and start actively getting people involved. Helen encouraged me to direct, rather than lead which is a really nice way of seeing it.

Stories not Events - I have noticed that the events that stick out are usually the bad ones. These are usually the ones brought up with allows for improvements but does not help with celebrating successes. We should be pepped by the end of a sprint! Using timelines you can encourage storytelling, allowing you to replay a sprint from beginning to end. You can journey through the sprint, looking at what happened so you can see both the good and bad points.

Be prepared! - I spend as much time prepping a retro as doing one, if not more. Since I vary my format, I have to spend some time thinking about what I am going to do. This is a good thing and the team deserve it. Playing out the same retro might feel safe but I should imagine the team dread it after a few months. Dedicate time to preparing your retro, fitting it in with the teams personalities and requirements.

I'm sure there is more but these are the ones I have had on my mind recently. Enjoy!

Symbols not words

It is rare that something I try just works but this is something that was simple and helped one of my teams.

We were finding it awkward to track the overall state of a story on our manual board. Without this it was easy to miss something interesting during the stand up and even more difficult for the business to look at the board and understand what we were working on.

The team always talked about 'bringing an item into play' so I started to use a CD/DVD play symbol to indicate the items we were currently working on. This quickly evolved to use the stop symbol to show a story had not been started yet, a pause symbol to show the story had something blocking it and eventually a fast forward symbol to indicate that the team were swarming on that single story. Once we used the eject symbol when a story was pulled from the sprint due to a really late change in customer requirements.

It seems almost trivial, but the mere fact we could see the state of all the stories on the board helped with:

1) WIP - before it was too easy to start working on something without finishing something else. There were several instances where we had a high WIP and some items could not be done by the end of the sprint. Being able to see status of the board pretty much stopped this overnight. Never quite understood why but the added visibility meant it was much more difficult to hide opening another story, allowing the team to form and keep an agreement on WIP.

2) Stand ups - we focus the stand up on the 'in play' stories, drilling into each one and organising the day around closing them. We often update the symbols to reflect what we agree to do for the day e.g. pausing a story so we can swarm on another one if we feel it is stuck and we won't incur waste in doing so.

3) Waste - the states of the story give clues to any waste that might be happening during development. If a story is paused - do we have a delay or hand-off? If a story is in play but seems to be stuck in a particular phase of development - maybe we have re-learning happening? If we have to play a paused story - maybe we should be looking for task switching? I can ask questions that help the team see waste and record it more accurately but the clue's start with status of the story.

We have also used padlocks to indicate if something should not be touched - happens occasionally if we are working on anything that needs approval by the organisation but we are slightly ahead of the curve and have already planned the item.

The key observation is that everyone 'gets' these symbols. They convey specific information quickly and easily with no training required. They drive team conversations and most importantly, the team has adopted them which is probably the best endorsement you can get.