It’s my way or the highway…

The last few months have been pretty busy for me and so I have dropped out of the online community for a while. Over the Christmas break I had some free time and so I ventured back in, caught up on some reading and tried to get a feel for the common issues of the day.

What I found was post after post condemning just about all things ‘Agile’    

“Ban the use of Story points”

“Agile is dead”

“Scrum/KanBan should be sent to the scrap heap”

“We don’t need: Scrum Master/Product Owner/Agile Coach/QA” 

There were some even suggesting that Agile had run it’s course and we should go back to Waterfall.

I found all this very disheartening, on one hand most of these were from people presenting a new idea or new techniques, and it is sad to say but in our culture it seems the only way we seem to know how to sell something is by presenting everything else as bad or with Click Bait statements, we all want to get noticed.  But when did ‘Agile’ become so black and white?

For me Agile has always been first and foremost about inspecting and improving – finding better ways.  But that doesn’t automatically make anything that differs from your approach Bad.  And it certainly doesn’t make everything New to be Good.

There is not one Right Way.

In almost every case the examples/justifications were examples of poor implementations of Scrum/Kanban; incorrect use of Story Points; or a person being ineffective in a role, or in some cases there were teams that had matured to a point where they were no longer getting benefit from a tool or a role.

But not one of those examples makes the tool or the role Bad.   In each and every case the team should inspect and adapt, and identify improvements.  If one team decides that Story Points do not add value for them, that is great, that team has found a better way that they can deliver software.

But that doesn’t mean that other teams that find them effective are automatically doing it wrong. If you find you can use a tool effectively and it works for you, then use it. Just keep inspecting and improving.  If a tool doesn’t work for you or you find an alternative tool that works that is great too. But try to understand why you are using a tool, what is your desired outcome and is there a better way for you.

As an anecdote, I was using a drill to make holes to hang shelves, I carefully marked and measured and then drilled. A friend was with me and he picked up a cross-head screwdriver lined it up on the wall and hit it hard, punching a hole in the plasterboard wall, far quicker than I was doing with the drill.  The technique was great for him in that situation, but when faced with wood or brick it was not suitable, and in both cases I still needed to measure and mark.  

Tools are context AND user specific, what works for one user in one situation does not automatically work for all users in all situations.

The same goes for the roles argument, I agree that there are some teams that have the versatility, the right mix of people and the capability to work effectively without one or all of the roles, but that doesn’t mean they are an ideal we should all strive for. Many teams find they are far more effective with those roles, and I would consider that to be just as much an ideal state as the other. If your team is effective and improving then you are demonstrating an Agile mindset.  Our goal should be to improve how we deliver software, not strive for someone else’s idea of utopia. Concentrate on improving YOUR team rather than mimicking another team in a different situation.

Declaring your way the only way is not demonstrating an Agile Mindset.

Explain the benefits, do not attack the alternatives

If you find a way that you feel works well and you want to share it, then explain what problem it solved and why you felt it improved the way your team worked, share that example, but please don’t do so by declaring all other tools WRONG.  What is right for you may not be right for everyone. You will just sound like a Snake Oil salesman.

Don’t reinvent the wheel

Having said all that we don’t need to reinvent the wheel and discover everything ourselves. We can benefit from other people’s experience and advice.

Both Scrum and Kanban and any of the tools mentioned can be badly applied, but when implemented with the guidance of someone with a genuine Agile Mindset (rather than a blind by the book interpretation) they can be excellent foundations from which you can evolve, by inspecting and improving, they are not the end point but a safe and structured starting point.

The same applies to the named roles, having someone with an Agile Mindset that can help create a foundation of understanding of the roles and when and where they add value can provide a structure and consistency that allows you to grow from a starting point that has proven to be effective for many.

Do not stand still.

But most of all, whether it be Story Points or the need for a QA, inspect regularly, assess what problem you are trying to solve in terms of outcomes, if you feel a change will show improvement then experiment and review.  Small changes are generally preferred, it is easier to see the impact and easier to undo if the results are not what was expected. Understand what you are changing and why so that you can properly assess whether the change was beneficial.

I have seen teams conclude a Scrum Master/QA/Product Owner is not necessary after all they can cover the role themselves (usually as the result of cost saving measures or because they are presented with a false notion that good teams don’t need help). Sometimes this works, but more often the responsibilities are performed less effectively when distributed among the team and so the net result is a reduction in the effectiveness of the team.

There are certain expertise and mindsets that often come with a role that is not fully appreciated until it is gone. This generally and understandably gets neglected when it isn’t the core responsibility of the team members.

Let the team decide

If a team feels they need a change I’d have far more confidence than if the decision was made by someone with little or no exposure to the team, or on the back of reading a blog suggesting “good teams don’t use Scrum Masters/Story Points/Scrum/etc.”

Advertisements

Were Pirates Agile?

A good friend of mine has been watching Black Sails and he commented at how similar the structure was to a Scrum team and so I did a little research just to see what parallels can be drawn from a a band of pirates and an Agile team.

image

They are self-organising and self-managing

A pirate crew was very much a self-organising structure, all crew members got an equal say in decisions. Officers were generally elected including the Captain and the Officers. Almost all decisions were made by way of voting or the crew voted to delegate decisions to an individual.  The crews were generally cross-functional, some specialist skills were in short supply so people with those skills were highly valued but generally crews were expected to pitch in and perform multiple roles.

They had a Product Owner

A captain was elected and his role was to set vision and direction, to be a single voice and he became ultimately responsible for the success or failure of the project, he would choose the next target or destinatation and would decide how to respond to navigation hazards that could be planned around. There were some perks associated with the job but generally loot was divided equally amongst the crew, a Captain may get 1.5 or 2 shares. Successful Captains would likely be re-elected unsuccessful ones may not be so fortunate.  There was a distinct lack of authority in this role outside of navigation and strategic decisions.

They had a Scrum Master or Team Coach

Crews would elect a QuarterMaster, their job was to ensure the ship ran well, he understood the process and would do his best to coach the crew into keeping a ship running well. But the quartermaster did not have authority over the crew beyond this.  Pirate crews were made up of runaway slaves, deserters from armies and ships or fortune seekers, many were not skilled sailors or fighters and most had a very strong aversion to authority and discipline.  Quartermasters were first and foremost coaches. They would encourage the crew to learn the necessary skills and to keep the workflow effective.  Quartermasters were likely seasoned sailors with lots of experience and the ability to understand how a ship works and how to coach the crew to do it. But unlike the Navy where discipline could be used to enforce order a pirate crew didn’t do this. If a quartermaster struck a sailor they risked being marooned as a consequence.

image

The crew had individual responsibilities

All crew members had responsibilities and were held accountable by their peers, all understood that the crew stood or fell on it’s own so anyone not pulling their weight or letting the crew down was a liability. Whilst there were officers the officers were organisational necessities not authority figures, it was about communication not control. Discipline was most definitely not enforced by officers.

But the best parallel is that they had working agreements

The pirate code – perhaps the earliest documented team working agreement?  Each crew had and documented their code and held the other members of their crew accountable to it. The code contained how decisions were made, what decisions were delegated. How loot was divided. How the team interacted with each other. It was clear that in most cases it was a flat structure and that roles were temporary and were elected.

Pirates were generally forbidden from stealing, destruction, sexual assault, fighting, desertion, gambling or breaking up the pirate band. Some even mandated an early bed time!

Definition of done

This one in particular amused me, but the pirate code contained a definition of done for a Pirate.  If a pirate earned 1000 pound then he may retire. If the pirate lost a limb they could leave the crew and would be given 800 pounds. (400 pounds if it was just a hand).

 

So are pirate crews agile?   yes they Arrrgh !

Why Scrum so often fails

I should start out by saying that I am a big fan of Scrum, I think those that devised the framework possessed an agile mindset but also were mindful of human nature. They created a framework that had in built checks and balances and prescribed solutions to many of the most common problems. They also had an understanding of system level thinking – I’ll come back to that later.

The core of the system though are the core roles Scrum Master, Product Owner and Development Team. This triad is what makes Scrum so successful (when it works) and in my opinion it is the absence of this triad that is the root cause of the majority of the unsuccessful adoptions.

It is all about the mindset

However, I don’t think it is the role that defines this triad but the perceived mindset behind the role.  Having a team that possesses a strong member with an Agile mindset, and the knowledge and skills to support it and the opportunity to focus on it; having a strong team member with a Customer mindset, a desire to engage the customer and ensure they get what they really want, and finally a cross functional development team with a strong Production mindset – that of delivering a well designed, high quality and maintainable product.

Scrum assigns named roles because they believe this give the best chance of having those mindsets on the team. But sadly it doesn’t guarantee them.  There are far too many Scrum Masters that understand the rules, but do not have an agile mindset so create cargo cults and many product owners that build what they want not what the customer wants.  And many development teams that over-architect, over-engineer or pay lip service to quality maintenance and even design.

scrum-master

The flip side is that you can create Agile teams without team coaches and without customer representation, sometimes they are very successful. But my assertion would be that on those teams there is someone with an Agile Mindset and calls out the team when they deviate, there is someone or multiple people that make the customer voice heard and engage them often and there is a cross functional team dedicated to building the product right.

In essence I am saying that Scrum fails when those in the named roles fail to live up to the role. And that in cases where a role isn’t named someone or more than one steps-up into that role. But in either case if those mindsets are not present on the team it is a recipe for failure.

Agile is a Mindset not a Rule-set

Scrum fails in essence because we assume a Role is the same as a Mindset. In this case Correlation does not imply causation. There are many great Scrum Masters and Coaches out there who posses an Agile Mindset, but sadly there are also a great many that lack it and see the role as the application of a rule-set rather than the application of a mindset.

System Level Thinking

This failure of mindset extends to the tired old conversation of Scrum Masters (and coaches) making themselves redundant on a team.  There is a lot of talk about whether or not a Scrum Master(or Product Owner – or QA or designer etc etc) would be fully utilized on a team.  Utilization of resources is a point of frustration for me (Note my deliberate use of the word resources). If you are concerned about maximizing utilization of someone then you are failing to see them as a person or see the value they provide and they have been reduced to counting the number of hours they occupy a seat.

A coach does not become redundant on a team when the team performs their tasks for them, a coach becomes redundant on a team when the team develops an Agile mindset and has the skills and knowledge to apply it without the coach’s help (and even then I see value in a diverse perspective). Utilization should not even be a consideration, value to the system should be the consideration. The same applies to the other roles – PO, designer, QA etc.

It is all in the name

Naming roles on a team is a risk, as I have described above if you get the wrong person it can undermine the balance, there is also a risk of knowledge siloing, and perceived expectations and divisions of labour when you name a role by areas of responsibility.

But far, far more damaging in my opinion is giving names that imply authority. Any type of named leadership role embedded on a team (Manager, Tech Lead, Team Leader, Architecture Lead) immediately stifles opinion and inclusion and undermines self-organisation on a team. Where roles like Scrum Master and PO stifle horizontal knowledge sharing, hierarchy stifles everything – so in my opinion this is far worse.  If someone possesses a greater technical understanding there is no need to anoint leadership, it should be self-evident, and if it is not evident to the others on the team then likely the leadership title will subvert rather than support.  Equally A self-organising team should not need a team leader or manager.

Ultimately it comes down to balance.

If you believe a team will be able to balance the three essential mind-sets without named horizontal roles, then the roles are unnecessary.  If not (and I would err on the side of caution) then named roles give the highest probability of achieving this balance – especially if you have confidence in your hiring team that they are hiring for mindset rather than certifications. Those in the named roles should be sharing the mind-set as much as the knowledge.

But I if you feel there is a need for named leadership roles on a “self-organizing” team, ask yourself why you don’t trust the team to self-organize?

And finally if at any point decisions are getting made based on utilization of staff, in isolation and without consideration to the value they bring to the team. Then read the book “The Goal” by Eliyahu M. Goldratt.  It will help understand that a focus on perceived local efficiencies and a desire for maximum utilization can actually be damaging to the larger system. Or read my post on efficiency

churchill

 

 

 

 

Why do we use WiP limits?

I participated in a great discussion this week on the use of WiP limits.  For those that don’t know, WiP stands for Work in Progress, and is a measure of how many activities you have started but not completed.

It is important to note that this is not a measure of how many tasks you are currently actively working on.  If I started a task but have become blocked, so I start another then my Work in Progress is 2 – even though I am only actively working on one. WiP is a measure of how many started but incomplete tasks I have.

For example: call-waiting or being put on hold during a phone call:  You are talking away and get another call so you switch to the second call without hanging up, and when you get another call you take that too, how many people can you have on hold at once?  You are only working on one call at a time, although you must remember the content and context of all those other calls. For the people still on hold while you have all these conversations I expect they are wishing you had a WiP limit.  Your WiP-Work In Progress is the sum of all active(incomplete) phone calls.

Limiting WiP

There are many reasons for limiting Work in Progress not least because I hate being put on hold.  I will go in to some later and it is likely that if you follow any type of Agile framework you already limit WiP although you may not be consciously aware of it.

If you have a backlog, then you are limiting WiP. You are consciously choosing not to start new work immediately but are prioritising it and organising it to work on later. It is likely that you are informally limiting your WiP according to what you feel you or your team can manage at a given time. It is important to realise that this is a WiP limit even though it may not be conscious or scientific.

If you follow Scrum: WiP is consciously and explicitly limited at Sprint Planning, often by estimating effort, or counting stories or calculating story points. The limit is generally set based on Velocity – our average achieved over previous sprints. If on average we finish 10 stories a Sprint, or we average 35 points, then that average is generally taken as the starting point for our WiP limit, we may choose to push for a few more, or if we are expecting to be slower due to vacation time, or known issues we may choose to commit to less. But in Scrum we don’t usually refer to it as a WiP limit. But that is exactly what it is.

KanBan is actually very similar, if we on average are completing 10 stories a week, then it is likely that we will consciously or subconsciously limit ourselves to only take on 10 new stories within a week, although in the case of KanBan this is not done in a Big Bang explicit decision but gradually over the measured period and is more a consequence than a plan (A Pull rather than a Push). We pull stories when we are ready and we pull at the pace we are working at, that just happens to be 10.

Slightly off-topic, but one of the crucial differences between Scrum and KanBan is that Scrum is a ‘Push’ model and KanBan is a ‘Pull’ model.  In Scrum we Push an amount of work to the board and spend the Sprint working to Remove(complete) it.  With KanBan we are aiming for a more steady amount of Work in Progress and will pull new work as current work is completed, which creates a smoother flow, but conversely lacks a unified time based goal or target.  But it is important to understand that both frameworks limit WiP and both focus on ‘completed’ work being the primary objective.

Why do we limit WiP?

I’d like to think it was obvious by now and I think the basic principle is, but there are nuances that may complicate things which may be where the cause for debate comes from.

At it’s simplistic level if I can only complete an average of 10 stories a week/sprint then starting an average of 20 a week without changing anything else is nuts, all that will happen is that on average 10 or more of those stories each week will remain incomplete and stay ‘in progress’ by the start of week 4 we will still have completed 30, but will have 50 now in progress.  Chances are by now we will actually go slower because we will be distracted and falling over ourselves trying to juggle more than we can possibly achieve.

Think of all those people on hold, growing frustrated at being ignored, and you trying to remember all those conversations, the phone rings again, can you cope with another caller on hold?

We limit WiP because we understand that by working only on what we can achieve, we can focus and be more effective.

Limiting WiP and WiP limits

“Ah but you have talked about Limiting WiP but you haven’t mentioned WiP limits” I hear you say…

And this is where I think the conversation really stems from and where we get into nuances.  KanBan began in manufacturing where work was passed from one workstation to another and there was a measurable flow through the system.   Limiting the production on one workstation so that it maintained pace with the entire system limits waste. Having one hyper-performing efficient widget maker that can produce widgets 4 times faster than they can possibly be used is wasted effort. And the same applies to a software process, we use WiP limits to regulate one part of the flow to maintain pace with the flow as a whole, the goal is to visualise bottlenecks and by visualising bottlenecks we can take steps to increase the flow of the whole system.

Other forms of WiP limit

But WiP limits can take many forms and are applicable to almost all aspects of life. The most common example used is a highway, when a road gets busy it slows down, when it gets very busy it grinds to a halt.  Limiting access actually speeds things up for everyone on the road, and ultimately more cars can get through far quicker.

But there are other less obvious WiP limits. A long-distance runner wants to increase her times, she starts fast but she runs out of energy and is slowing down near the end of the distance. By setting herself a slower time per mile early on (Pace is a form of WiP limit) she has a consistent speed and reserves energy so is able to run the full distance faster by slowing down during the early part of the race.

Are you dedicated to a single product/project?  That is a very low WiP limit of 1 project.

Do you use a calendar and try not to book two meetings at the same time, that is a very tight 1 item at a time WiP limit.

What about a budget?  Do you manage your finances as an individual or company. A budget is a WiP limit for your money, by limiting money spent on beer you have more available for clothes. By regulating your spending you can save for a holiday.  By remaining in credit at the bank you do not have to pay interest and so on.

Example of how to choose a WiP limit in a workflow

In the case of the widget maker, if the system can only use 10 widgets a day then we may set his WiP limit to 10, when he gets to 10 he is free to go and help someone else.  Suddenly rather than unused widgets we have an extra pair of hands to do other work.   But hold on! these widgets are easy to make and only take a short while to do, we could probably limit WiP to a lower limit and jump on the workstation as an when needed to produce more.  So how do we set the WiP limit?  My advice is not very scientific at this point.  Start by continue doing what you currently do and just watch, if your workstation/activity columns are sub divided in to doing and done, take a look on a regular basis and see where the biggest stacks are. If one column regularly has more cards on the done column than doing, it ‘may’ be a sign that you should reduce your WiP limit for that activity. Try it and see if it improves your flow.

The largest queues of done work are usually the area that needs limiting, but be aware of ‘bursts’ of activity, for example there may be a workstation that is only available for one day a week, in which case the queue for that workstation may need to be longer – or maybe you should be asking for more regular access to the workstation. But when imposing limits do it gradually and monitor to see if it improves the flow.

Anything in a done column is normally waste, if it is done and not in production that effort cost you money and is just sat there.  Sometimes that makes sense but the car industry learned that complete cars sat in storage amounted to $millions of wasted investment, that components stockpiled in advance was essentially big piles of cash that could be used more effectively, we can learn the same.

What I am saying is that a WiP limit being reached is a conversation trigger, a long queue is a conversation trigger, and so on. With so many things in Agile we create early warning systems to create conversations and make decisions when it is necessary.  We make small changes to the process and watch, we see what changes and if it is better we carry on, but look for another new small improvement.

Summary

WiP limits are not unique to KanBan, and like it or not you are already limiting your work and activities in all aspects of your daily life, you just perhaps didn’t realize it.  In the context of a KanBan board we do not arbitrarily impose a WiP limit because we can or because it is fun. We impose a limit when we feel it adds value, normally where we see a queue of completed work growing faster than it is being consumed. We limit various stages of the work because our goal is the output of the system (the whole team) and not the perceived utilization of individuals.  One team member being 100% occupied all day producing something that will sit untouched for a week is not efficient.

We are not trying to manage a system where our goal is to keep busy a group of individuals, our goal is to create a cooperative and coordinated team working towards a common purpose in the most effective way possible. A WiP limit is just one of many tools that can be used to enhance the prioritisation of work and focus the team on the true goal.

 

 

 

Agile for the real world.

I have once again this weekend been drawn in to reading articles and discussions on LinkedIn, mainly discussing how Scrum=Bad, KanBan=Good, or KanBan=Bad and ScrumBan=Good, and a variety of similar content that frankly is just noise to 99% of the people involved in Agile Software delivery. The reality is that most software professionals really don’t care.

Did I really say that?

It might be a little ironic and I might just be adding more to the noise but I’d just like to bring us down to earth a little.

My experience of Software delivery has been mostly large corporations and the Civil Service, and what I can say with a good deal of confidence is that the staff involved in software delivery want Agile, no question, they are overwhelmingly in favour. I suspect that a step back to Waterfall would see hands go up in horror and a great deal of frustration and maybe even many people leaving in protest.

But I see it as the difference between learning to drive and understanding how an engine works. Most, and that is a sweeping generalisation, but most of the teams I have worked with want me to teach them how to drive, they want to use the skills they learn and to be taught how to teach themselves. What they are not interested in, initially at least, is the mechanics of the car. When they become proficient that may change they may believe that for particular types of driving a different vehicle may be appropriate, but initially simply learning to drive and practicing the basics is as much as is needed and they are happy to have a car suggested to them.

Recently I have been working very closely with three development teams and indirectly with others, and of those teams I’d estimate that maybe 10% have an active interest in the mechanics of Agile Software delivery as a topic and probably less than half of those would give two hoots which flavour of Agile we follow, so long as we follow the principles – most see the framework as a tool like any other it is about getting the job done right. But 100% want to be shown how to use Agile techniques to improve their way of working, but they rely on an expert to guide them. They wouldn’t hesitate to tell me if they thought it wasn’t working.

Most have had no prior Agile experience other than minimal training. Many have been in Agile workplaces in the past but if I am brutally honest they seem to have been poor implementations, a few had good experiences and a very few have been exposed to more than one variation of Agile frameworks.

In the real world a development team wants to build software, perhaps a little over simplistic but a coder wants to code and a tester wants to test. Now I can encourage them to co-locate, cross-skill and try to mix things up, they can use Agile to improve and most have an inherent desire to be Agile and improve. I can show them how to use TDD or BDD, I can encourage them to Pair Program, and they will be enthusiastic and supportive. Most will join in Retrospectives with relish and find true value in Stand-ups, most see the value in Sprint Reviews and the closer engagement with Customers – Why?

Why? Because they are embedded in a framework that works for them, they see positive results and they like what they see. But that doesn’t translate to wanting to have a discussion on the finer points of Agile frameworks. Most don’t see value in a debate on the differences between Scrum and Kanban.

As an example: I have read a lot about #NoEstimates recently and I find it interesting, there are others in my organisation that I could discuss it with and share ideas. But honestly I suspect the teams I work with really don’t care, they use Story Points and T-Shirt sizing because I showed them how and because it works, they see the value. Would they change to NoEstimates – maybe, probably! if I encouraged them to, but the likelihood of the suggestion coming from the teams is low, and it is unlikely to have support or interest of the majority. Certainly not enough of them would have sufficient interest and understanding to make it an inclusive discussion.

However, The same was true of Pair Programming, initially I met quite a bit of resistance from the teams, one guy in particular was very much opposed and resisted, but I encouraged the teams to try it out for a Sprint and then another, and now it is a regular part of their routine and the biggest opponent is now the strongest advocate.

You may be thinking that these teams were not very Agile, or they are not sufficiently mature, but that simply isn’t the case. It just isn’t their primary area of interest. While I am reading about Agile techniques they are reading Tech journals or exploring new tools. As an agile practitioner these details and nuances matter to me, but to a software developer they are just another framework, another tool in their toolkit. The teams may be self-organising but sometimes it needs an outside catalyst to encourage them to push their boundaries.

My point is that software delivery is the goal, the Agile Methodology of choice is just a tool selected to do the job, don’t expect a horde of zealots raising pitchforks and screaming “Scrum”, or “KanBan” any more than they would demand TFS or Jira or any other tool. At least not until they have used it enough to be proficient. That debate is reserved for the agile practitioners.

I have seen Scrum adopted well and adopted poorly, the same with Kanban, neither is a silver bullet, and one is not better than the other (In my opinion). Again in my opinion, when I hear complaints about scrum it is generally because it is not Scrum, but an unchanged organisation that has applied scrum titles, or a cargo cult that follows the schedule without understanding the purpose. And sadly the current trend of handing out certificates to anyone that has done a half-day training course demeans the framework. Too many people see Scrum as a means of control rather than a framework of support, and sadly that is the weak underbelly of Scrum, the framework can be used to create self-organisation but can just as easily be used to stifle it if you have the wrong mindset.

Agile is a mindset much more than a process, the framework is simply scaffolding, but if your mindset is wrong the implementation will be wrong.

I love Scrum, I think it has so much promise and when used well I think it can be hugely effective, in most situations it would still be my starting point with organisations new to Agile, especially when management is not fully engaged. One of the likely intended side-effects of Scrum is that it becomes a tool to regulate the rest of the organisation and create stability for the teams to grow, it creates a protective bubble to enable agility to develop.  

So It saddens me when I see Scrum being seen as a barrier to agility. When ScrumMasters are wolves in sheep’ clothing and simply managers or PMs assuming a title and then undermining the framework, because they don’t understand the essence of the role. Where cargo cults masquerade as agile teams, and when they fail they blame Scrum.

My dad used to say that a “bad workman blames his tools” this was never more true than with Scrum. As a tool in the right hands it can be fantastic, in the wrong hands it becomes a fine quality chisel being used as a crowbar.  

The debate will continue and sadly because of its early success in widespread adoption Scrum has had many poor implementations and so is in danger of bad press which could ultimately spell it’s doom. Far too many experienced agile practitioners are advocating against Scrum based on bad experiences, but I for one believe that as a framework Scrum is good, but sadly there are too many cargo cults giving it a bad name. 

Hiring and firing in Scrum

I am exposing my ignorance here but I can’t find anything in Scrum that covers this, even Internet searches reveal very little so I don’t know if I am doing the right thing.

Scrum is about product delivery and so I am aware this is not in the scope of Scrum, but for it to work in practice we need to understand how it interfaces with business decisions. On many issues there is little or no conflict but on people management there seems to be a gulf and people for me are where product delivery starts and ends.

Most discussion seems to make the assumption that the team already exists and is highly motivated. But what if it isn’t, what if someone leaves? what if we need a new team?  What if a member of the team is not motivated or is downright destructive? How is that handled?

Hire a new team member

There are some situations that are easier than others. For example, the team is lacking an expertise or has insufficient people with a particular skill, or we simply need a replacement for someone that has left the team. We discuss it at a retrospective and the team conclusion is that a new team member would be a potential solution. I as Scrum Master can take that proposal to the programme manager (the business) and he will take the decision to hire (or not). The conversation likely includes the PO as it has budgetary implications.

But this is where it gets tricky, if they agree and a vacancy is posted, who sifts the applications? I’d want the team to have a say. There are a number of practical reasons it can’t be the whole team, typically there may be over 25 applicants for each role, that is a time consuming exercise, there is also an element of privacy to consider, so as Scrum Master I take it on myself, or the team chooses a delegation perhaps asking a few of the team for input, but hopefully as Scrum Master I am best placed to understand the requirements of the team as a whole.

Assuming I also filter with telephone screening, that is another time consuming task, is it okay to class it as an impediment that I resolve myself? And if so when I have a shortlist of just a few and want face to face interviews, again it can’t be the whole team so I ask the team to select a representative and typically the interview panel will be a Scrum Master the Product Owner and a team member. But if I am objective the Scrum Master has had significant influence in this decision, so does that undermine the sense of servant leader if I am effectively shaping the hiring decisions?

Also if that is considered an acceptable model, it is actually no different to when I was a department manager which immediately makes me stop and question whether the SM has too much authority in this scenario. That aside it feels right to me, it is pragmatic,the team gets influence but the time consuming aspects are shielded from the team. The only real danger is that the SM has a disproportionate influence on the process.

Build a new team

The second scenario is similar, the programme manager has more work or a new product and needs a new team. Best people to hire a Scrum team are likely a Scrum Master and Product Owner, possibly with input from a team member on an existing Scrum team. But this time there is no team to say what skills are needed, it becomes the judgement of the PO and SM. We are back to implied authority again.

I said at the start that I am on shaky ground, is this the right way? I haven’t seen recruiting, talent acquisition and interviewing as key skills for a Scrum Master or Product Owner, but in the last 18 months I have hired at least 15 people. I have bolstered one team and built up another team from nothing. Which as anyone used to recruitment will tell you is a significant time commitment. But whilst I don’t think of it as a Scrum Master responsibility, I can’t think of anyone else better placed and better suited.

Fire someone

But now I move on to a negative issue, let us consider a scenario where the team has a dysfunctional member, they are disruptive and by their behaviour they are holding the team back and coaching cannot solve it. It can be very difficult to get a team to deal with this in a self-organised way. So much time is spent team building, that pointing fingers at a member can be hard, especially if they are popular despite their behaviour. 

As a Scrum Master this is possibly one of the hardest issues to face, helping a team to see that improvement means hurting one of themselves is challenging to say the least, getting them to do so publicly in front of the party in question is almost impossible.  It can potentially be risky from an employment law point of view if the person feels this is done in a hostile manner. Managers are trained to focus on behaviour, and will normally be in possession of facts to support behaviour based criticism or discipline. Other team member may not be.

I see two ways to handle this the first is that the SM goes outside the team and reports his opinions and observations and has the person removed by a trained manager, chances are this is what the team wants but is unwilling to say so. But this in my opinion is wrong, it places the SM in a position of authority and the team have backed away from autonomy and independence. The right but harder way is to force the team to make the difficult decision and for the team to discuss openly and request changes. To essentially bench the disruptive influence. This may be raised as a retrospective discussion and a good SM should be able to focus the discussion where it needs to go, keeping it behaviour based and factual to avoid making it personal, sometimes retrospectives can be tough and even unpleasant but retrospection must be honest.

I didn’t say it would be easy!

Is this now management?

But in all this what I have proposed is moving the Scrum Master well in to the realm of management. Recruitment, discipline action, are yet another skill set to add to an already diverse role.

What I have described has worked, I’ve been there and done it, but just because it works, it doesn’t make it right and doesn’t mean it will work again.

Where in your opinion is the line drawn between Scrum and the hiring and firing decisions and how can we safeguard the SM from losing credibility by gaining authority?

Useful Scrum Metrics

Which do you use and Why?

I have already blogged about some common metrics but here are ten that I use or have used most frequently.  It is my aim to summarise them here and expand each in greater detail over the next few weeks. (I will come back and add links as I do)

Warning!

Before we begin, the first piece of advice that can be said about metrics is that before you record data or use metrics you should really ask why you are recording the information and how it will be used.

If you cannot be sure that the metrics will be used for the benefit of the team then you shouldn’t record the metrics and certainly shouldn’t use them.  If ever metrics are misused they become worthless as they are very easily gamed, especially if the team feel they will be abused.

Metrics are almost always reliant on honesty and there are not many metrics that couldn’t be ‘gamed’ if someone was motivated to do so.  Never attribute reward or penalty for a metric or even multiple metrics. As soon as you do they are broken.

Have you ever heard tales of teams that were paid for number of lines of code written or for number of bugs fixed.  I have worked at companies where the annual bonus was dependant on a high management approval rating in an annual employee survey.

Any environment where you are effectively penalised for honesty loses all hope of trust, transparency and integrity and your metrics become worthless.

If there is even the hint or suggestion that any of the metrics will be used for anything other than self-improvement and introspection again they immediately become worthless.

 

But that being said as a Coach measurements can be very useful. Measurements, metrics and reflection and retrospection are hugely valuable for coaching an individual or team on how to improve.  An Agile Coach or Scrum Master has a variety of metrics available – and these 10 are by no means a comprehensive list, actually it is a very limited list, Each project or development environment is different and so tailoring appropriate metrics to your particular environment is important, not all metrics apply to all projects.

One last note is that there are myriad tools for tracking projects, some will measure these metrics but many won’t and it will be necessary to manually record the data. It will often be difficult to backdate if you haven’t been recording it.

In projects I work on I try to keep a lot of metrics just for myself, much more than the team uses.  If at any point I feel there might be value in a metric I will bring it to the team and allow them to decide if it has value and if they are interested. But too much becomes confusing.  As a rule of thumb they team only really have interest in a few of these, although which ones may vary over time. Keeping metrics without using them is also a good way of avoiding them responding to inspection.

Beware of context

I am also aware that metrics can be misleading if taken out of context. Information can be dangerous if misunderstood, if I choose to publish metrics in reports or in the office on a wall I will work hard to make sure the context is clear and if appropriate there is an explanation. But even then you can be sure that someone will misuse the information, so be prepared!

 

1 – The Burndown:

This is probably the most often used Scrum metric. In essence it measures work outstanding at the start of the sprint and a line is drawn converging on zero at the end of the sprint and each day the progress or burn-down is measured. The goal being to complete all planned(and emerging) work by the end of the sprint.

2 – The Velocity Chart:

The velocity chart can take many forms and can be used to track a number of key factors. In the most simplistic form it is a bar chart showing the number of points or sometimes the number of stories completed in the recent sprints.

3 – The Velocity Committed/Actual Chart:

Sometimes the velocity chart can be further enhanced to show committed points compared with actual points, this is useful when the team is not consistently delivering on commitments.

4 – Release Burndown

The principle is that for a given product we measure the Burndown of the entire product in a similar way to a Sprint Burndown, it may take the form of a cumulative flow diagram or be similar to a velocity chart.

5 – Cumulative Flow Diagram

A cumulative flow diagram tells all sorts of stories about a project, essentially it measures the number of stories in various states as the project progresses.

6 – The Burn-up

The Burn-up measures the actual effort expended in the sprint. In a perfect world it would be an exact inverse of the Burndown.  But rarely do we predict all tasks in advance nor estimate the ones we know accurately. It can help see where time went and improve our estimates.

7 –  Flow time, Lead Time, Cycle Time

There are some varieties in how these terms are used but I use a simplified version as follows:

Flow-time is the time from when a story is started to when it is completed by the team.
Lead-time is the time from when a story is added to the backlog to when it is completed into production – from conception to getting the value.
Cycle-time is the average time from when a story is started to the point where it is completed – we could be working on multiple stories at once, or overlap them. e.g. each story could have a flow time of 3 weeks but we could stagger them to deliver 1 per week.

Using averages for these allows us to measure whether we are improving over time.

8 – Health check survey

A health check survey is more touch-feely than the other more raw metrics but can be useful for gauging the team’s own opinion of their progress and behaviour. You can measure opinions on anything, from software practices to interactions with other teams, to quality of stories, anything the team has an opinion of can be measured.

9 – Predicted capacity : Actual Capacity

Each sprint during planning – stories can be broken into tasks, each of those tasks can be given a time estimate.  When totaled up and the team has committed to the Sprint content, this total effort estimate is the ‘predicted capacity’ at the start of the sprint. This is the important number.  Tasks will almost always be added as the sprint progresses and many of the task estimates will be off, but the initial predicted capacity is a measure of what the team is anticipating the workload will be for the sprint.

In theory the actual capacity of the sprint is simply the number of team members multiplied by the number of hours available in the sprint, excluding, planned holidays, planned meetings, predicted time on non-sprint activities.

Tracking these figures allows the team to gauge whether the capacity is realistic in relation to the previous sprint, the end result will be a (hopefully consistent) ratio.

10 – Scope creep

This can be covered by the cumulative flow diagram, and by the release burndown, but sometimes it is useful to explicitly report on what has been added or removed from the Scope each sprint.