Monday, 6 November 2017

Scrum Master or Agile coach

After seeing yet another "Agile coach bashing" thread on LinkedIn I felt the need to blog my perspective. As a former Scrum Master, I now call myself an Agile coach. Here is my two cents.

Who's bad?

The trend I see is for some Scrum Masters to paint anyone with the title "Agile coach" as greedy, money grabbing consultants that don't know what they are doing. They only exist to suck money from large organisations who don't know any better. They label themselves as "Agile coaches" so they can charge out at a much increased day rate. They are the bad guys, while the paragons of virtue are the scrum masters battling away in the trenches, refusing to sell out & change their job title for the sake of a few extra bucks a day.


Let's start with some basic logic.
  • Bad agile coaches exist. This doesn't mean all agile coaches are bad.
  • Bad scrum masters exist. This doesn't mean all Scrum Masters are bad.

Whats in a title?

Lets start with Scrum Master, this is a well defined Scrum role. I'm not going to go into the role and responsibilities here but needless to say there are many different ways that the role is carried out with varying degrees of success. 

In the "could do better" column, we see Scrum masters who:
  • act like/ are expected to behave as project managers
  • are line managing team leaders
  • are viewed as admin assistants that do no more than book meetings & meeting rooms, raise tickets, chase tickets, manage rally/ jira & the burndown charts.
Is this type of scrum master an agile coach? I would say not. If an SM is performing these duties only and relabels themselves as an agile coach then I think that leads to some of the ire that people tend to feel against the title of "agile coach". Just changing your job title for a few extra bucks or to infer seniority. 

On the plus side, there are many, many awesome Scrum masters who:
  • push themselves and their team(s) to do scrum really well (local optimisation)
  • look beyond their teams to influence other teams (global optimisation)
  • change their wider organisation (global optimisation)
Is this type of scrum master an agile coach? I would say definitely yes.

I don't care if they wish to call themselves a scrum master or an agile coach or a scrum ninja, that's their own business. If you are doing all these awesome things and spreading the good word and trying to improve organisations at a wider level then that is awesome. Please continue to do so.

What organisations want from an agile coach is different to what they want from a scrum master


Generally an org will employ a scrum master to work directly with teams to improve their scrum process. The SM might work with one or two teams at a time, mainly embedded, with little time leftover for changing the dynamics and processes of the organisation outside of the teams.

The focus here is on the internal Scrum workings of the teams with occasional stretching beyond the team boundaries. (Of course there are exceptional Scrum masters who will passionately stretch further and more frequently)

Generally an org will employ an agile coach for different reasons. To coach many teams to improvement and also to improve the organisation as a whole. The focus is higher level when it comes to teams but there is more licence and expectation to improve and influence the org culture, the management (at all levels), reduce organisational impediments to agility like financial/ budgeting models, recruitment models, organisational, department and team structures

I don't expect an agile coach to embed in a single scrum team for any great length of time (and not at all if it can be helped). If the agile coach embeds then what is the scrum master doing? An agile coach should look across multiple/ many teams and provide guidance for improvement, they should coach the Scrum masters & Product owners who in turn should coach their teams.

The title does not infer hierarchy

As an agile coach, I do not assume any hierarchical superiority or seniority over scrum masters due to my job title. My title denotes what i do. If I coach scrum masters that doesn't mean i'm above them in the hierarchy. It only means that its part of the job that I do. That is one of the levels I am usually working on. Enterprise or executive coaching are other levels that  people claim to coach at. I view these as different specialisms, not a hierarchical career path. If I consider myself to be a plain old agile coach I don't assume that an enterprise coach is senior or superior to me. I hope we are pulling in the same direction and that they know what they are doing. Note: The existence of an enterprise coach role doesn't preclude SMs or agile coaches from improving or coaching their enterprise

There's more to this than Scrum

I consider myself to be an agile coach not a scrum coach. For me this means that I need to have more in my locker than an ability to teach teams Scrum.  If I am actively working across a large organisation, coaching people how to adapt XP, Kanban, Scrum, as well as Scaled Agile techniques then I feel it would be wrong to label myself a scrum master. Scrum makes up only a portion of what I do.

What if I move to an organization that doesn't do Scrum at all? I can still call myself an agile coach , could I call myself a scrum master? That would be confusing wouldn't it?

I thought we were supposed to be on the same side?

I don't see the need to generate tension between agile coaches and scrum masters. I see us as all as being very much on the same side. If my understanding of the agile coach role matches what another person feels they do as a Scrum master then that's great. If you are coaching your own team to be awesome at scrum and you still have time & energy to tackle agility issues outside of your team then you are doing a great job. Choose your own label or use the one provided by your company but please don't assume the agile coach label means "glorified BAD, overpaid scrum master"

Thank you


Friday, 13 October 2017

The MVP Onion

I've been in some workshops recently where confusion arose around what is MVP in practice.
Its seems like there are many different interpretations of MVP and often that interpretation is determined by :
1. Risk tolerance
2. Type of feedback required

Risk tolerance

The ruthless MVP of a fledgling startup company might be far too precarious for a traditional financial company. They may not be able to launch a streamline MVP that doesn't satisfy compliance or regulatory standards. When these requirements become part of your "minimum" then your delivery grows beyond basic VIABILITY.

Feedback Requirements

If you're launching a new product, you need feedback that tells you if customers need the product, do they want the product, will they use the product, will they like the product. 

Sometimes you might be using a new technology stack or trying to build something that hasn't been built before. In this case you need system feedback . Do the minimum you can that will prove you can build the product. It might be too rough and ready to launch but tackles your technical risks first. If you cant build it then there's no point in thinking about what will delight the end users.

Different Layers of MVP

This probably won't satisfy the purists but what i came up with was an MVP onion (nod to Simon Powers of Adventures with Agile - this onion is a homage to his Agile Onion!)

I found that this really helped people who were trying to reduce the scope of their initiatives to something that was more like an MVP but couldn't quite fit to a ruthless MVP due to organisational constraints.
I've also include the good old "Walking Skeleton", which is possibly even a subset of the leanest MVP. The minimum you can do to hang your product together functionally. 



TIP

At all times remember that you should build your product up from these principles, iteratively. 
You don't have to release your walking skeleton, but you should build it first. you don't have to release your MVP but you should build it, and then you have options around whether you should add more or not

Sunday, 8 October 2017

Why you need WIP limits

Why is this crazy person telling me to limit my WIP?

As an agile coach I often come across situations where I need to encourage teams to reduce the amount of work they have in progressEven though it sounds and feels counter intuitive to do less work, the fact is your team will get more DONE by doing fewer things at the same time.

Activity != Progress


In our scrum teams we naturally tend towards keeping everybody busy. Developers working on development tasks, testers working on testing tasks. History has skewed our mental model of what people should do at work so that we feel like we should always be busy, always processing work. 

This is a good model for the mass production of widgets or the processing of mountains of paperwork BUT a bad model for the production of complex, functional, high quality software.

We use user stories to represent units of complex, functional, high quality software and in scrum the game is to finish a number of these units every sprint. This goal is often overlooked in favour of keeping team members busy. As long as everyone is busy we will eventually deliver the user stories. This is possibly true but they will be delivered in an inefficient and unpredictable manner.

You are slowing your team down by not limiting WIP


What do you mean, how can I slow my team down by working harder on more stuff?

Well you are the guy who is so good at building car doors, that you have focused yourself solely on the optimization of your work for the creation of car doors. This results in the creation of many, many car doors BUT doesn’t deliver any completed CARS from the production line and now if you look around, the factory is full of the car doors and the stockpile is slowing your work colleagues down. They are tripping over doors and themselves. You are increasingly spending your time managing piles of doors, stacking them, shipping excess doors to storage, retrieving them when they are needed and we as a team are still not shipping any finished cars.



My previous blog post on this topic described how we favour working on our areas of specialty (dev & test) and how this results in teams starting more work in order to serve our specialisms.
This works well to keep individuals more productive (or at least occupied for more time) but it doesn’t work well for helping a team to deliver its user stories to DONE.

Instead of continuously creating car doors (pulling new user stories in order to perform new development tasks). What if the car door guy builds a limited number of doors? Just enough to keep the team going for a while. Then instead of building more doors, he stops. He is now “idle”. We don’t like “idle” time, we’ve been trained historically to fear “idle” time. However idle time (or slack time) is crucial if we want to ship any finished products.

How can we go faster when people are idle?

This goes against all your instincts. Team members should be busy. Developers should be developing. You need to change your instinct to read “Teams should be delivering finished work”.
Optimize your ways of working for teams finishing user stories, not for individuals finishing tasks
When car door guy creates just enough car doors to keep the team moving then stops creating car doors he doesn’t sit around being idle. He is a good worker, he wants to do good work and he wants his team to be successful.

His first instinct is to tidy his work-area. This means he will be faster and more productive when he next comes to build more car doors. His previous inventory of car doors is no longer cluttering up the production line. His colleagues are free to do their work more productively. We don’t need to transport car doors to/ from the store room. We have saved ourselves a lot of time and hassle purely by ensuring car door guy is doing less car door building. This is not to say we don’t value his work. We need car doors, we can’t build cars without them but once we have sufficient car doors to keep us going we have other work to focus on as a team.

Once the car door production area is spick and span, car door guy looks around for something else to do. He is really good at making car doors, but the team has blocked him from creating more than is needed. What should he do? He wanders over to his colleague further up the production line and asks if he can help in any way. He doesn’t feel like he can help much given that his skillset is only in the making of car doors. The team encourage him to work with a colleague and learn how to attach his car doors to car bodies. Car door guy expands his skillset and we are one step closer to having finished cars

By limiting WIP team members will frequently be blocked from starting new user stories simply to serve their specialisms. This is a really good thing. It will result in a number of new and wonderful behaviours.

  • Team focuses more on the completion of finished products/ user stories (not just dev/ test tasks)
  • Individuals stretching their boundaries and learning new skills. (developers helping with testing, test automation, learning new programming skills/ languages outside of their main specialism)
  • Less waste and unfinished work in the system, means we can ship finished work faster
  • More refactoring and automation

Stop starting – start finishing


Once you’ve finished your stories you can play some more. Don’t pull in new stories before you finish your current in-progress stories and don’t pull in new stories if you still haven’t met your sprint commitment. Finish  the things you start before you start more things, it makes sense right?

Friday, 15 July 2016

Super Stories .... Features to the rescue!

Many moons ago i wrote a post about the use of epics. How to visualise them and use them as a starting point for large project decomposition (read it here). The world has moved on a bit since then but still I see people I work with struggling with some of the same issues. How to break big projects down into small, valuable, usable chunks that can be delivered quickly by development teams. In my previous post you can see how the epic user story is a stepping stone to reaching smaller, valuable user stories. These days I seem to be discussing Features a lot more with people.


Epics v Features


To begin with I find there is confusion around Epics v Features. Note: The Epic I refer to here is the original Epic user story, before SAFe decided an Epic was a different thing altogether

  • What are they & Whats the difference? 
  • How are they different to user stories?
  • What size are they?
Let start with addressing these questions

What are they & what's the difference?

The  way I see it?  There isn't a difference. Both should represent a slice of functionality or a capability that is too big to be a user story in it's own right. 

  • The feature or epic is simply a large user story. 
  • They should adhere as much as possible to the INVEST principles. 
    • Features should be independent, negotiable, valuable, testable. 
    • They probably wont be small and this will lead to issues around estimation.


How are they different to user stories?

When decomposing a large project, we want to get to a backlog of user stories to feed to teams. The first draft user stories we identify will often turn out to be much too big for teams to deliver in sprint. This will lead us to break the user story down into smaller user stories. Thus creating a parent-child relationship. The Feature could be something we initially thought was a user story, but once further refined turned out to be too big.


What size are they?

How long is a piece of string? There is no answer for this. Its a judgement call. I always feel that user stories should be small enough for each developer/ pair to churn through 2 or 3 stories per sprint. Rolling this up, I feel like we should be able to define features that can be delivered by a full team in the course of a sprint. 5 devs/ pairs doing 2-3 stories each = 10-15 user stories, surely we should be able to create a sensible piece of functionality from the accumulation of 10-15 user stories?? I'd like to think so.

Size is the main cause of confusion with regard to features. If its a valuable slice and its small, then its a user story. If its a valuable slice and it's too big then its probably a feature. Once complete, a feature should give us an ability to do something that we didn't have before. This is also true of user stories however we may often need to combine the value of multiple user stories to get a something viable/ marketable.

What a feature is not!

A logical grouping of user stories or tasks. The feature is supposed to deliver you a distinct slice of value, not an accumulation of disparate small chunks of value.

Tuesday, 2 February 2016

Agile is a team game

Agile software development is a team sport. I see so many issues when working with software teams that I have also come across in a sports team context. Teams are collections of people and to get a collection of individuals motivated and organised to achieve a common goal is not easy. I am convinced there is much we can learn from  the sporting arena to help us perform better as software teams. One example is the concept of Individual efficiency vs group efficiency.

Individual v team efficiency

A lot of what is important for the success of sports teams is also valuable for software teams. We create teams with a view to the Team achieving more together than the individuals would on their own or because the task/ deadline before us is unachievable without extra man power. 

Example: Amazing footballers like Lionel Messi, Cristiano Ronaldo, Diego Maradona could not  achieve anything on their own, they need to operate within a team structure to achieve any great success


Often organisations are trying to deliver projects to crazy deadlines which mean they need the extra manpower a team structure can provide. They cannot rely on the superstar, the Ronaldo, to do it on their own. For star players and gifted individuals, sometimes this means sacrifice. A sacrifice to how they would normally do things. A compromise of their individual efficiency for the sake of the team efficiency.

An example of this that we might be familiar with in software teams, might be where a team debates whether to break a large user story into multiple small stories. The star developer feels he can be individually more efficient by tackling the big story on his own in one go. However by breaking the work into smaller chunks the team gains a lot: ability to show incremental delivery, ability to spread the knowledge throughout the team, pride that the whole team can contribute rather than just one superstar, future reduction of key man dependency, shared knowledge of the system, early identification of risk/ complexity.

Often, using agile means sacrifice for the expert individual but it results in a stronger team, the herd is only as fast as its slowest member, not its fastest. This can cause conflict in some cases with the star player finding it difficult to sacrifice or to spend time coaching others to an enhanced level. The bottom line though, is that organisations need to have multiple, reliable delivery teams rather than a handful of exceptional individuals. 

Important! This doesn't mean we don't want to have exceptional individuals in our companies or teams but ideally these should compliment outstanding delivery teams, not prop up poorly functioning teams :)