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.

Interviewing Do’s and Don’ts

This is off-topic and not really related to Agile, this is just an area of interest to me and I had a few ideas I felt I wanted to share. I originally started writing this post when I was interviewing others, but since then the role has been reversed and I have been looking at a new role for me, I have applied for and been interview for a couple of roles and about a month ago I started a new job. Consequently I have been reflecting on past interviews and so I thought I’d share some of my opinions on the topic. In doing so I am also challenging myself to see how much of my own advice I followed when roles were reversed.

This is written primarily from the perspective of me as interviewer, and I think this helps, if you can put yourself in that role of the interviewer it crystalizes what you would expect, allowing you to better prepare and chances are if you would expect it maybe your interviewer will too.

First impressions

The first thing an interviewer sees is your CV(resume), put in some effort to make it easy for them to read. As an interviewer I want the chronology to be clear, I want your core skills to be clear. Chances are the job advert was pretty clear about what I am looking for, if I don’t see it quickly your CV is heading for the reject pile. It is worth putting some effort into getting your CV in a clear readable state. I don’t expect anything fancy, but make it clear and readable, no obvious spelling mistakes. And if you claim a core skill, be sure that your job history supports it, claiming experience as a Programme Manager, or an Expert Nerf Herder, but having nothing in your past to support the claim will get you binned.

Be on time

I generally telephone screen first and I will endeavour to call you at the time specified. Be there! Be somewhere you can talk freely without distracting background noise, taking the call in the pub or on a train is not a good idea (I’ve had both). Not answering is a waste of my time, likely I will have booked a room, I’ll have done preparation and I will have been there early to be respectful and courteous to you. If you don’t answer and I have to rearrange, you will be playing catch-up, that is if I call you back at all. I look for team players and respect is a crucial element of that.

Similarly for the face to face interview, be on time. Not only is being late disrespectful, the inability to plan a journey for an important meeting reflects very badly on your ability to plan in the work environment. Communicate difficulties for the same reason, ability to communicate will be one of the key skills I am watching for.

What to wear

This generates a lot of discussion with quite a variety of opinions, I can only speak for myself and my opinion. My former work place was fairly casual: jeans, T-shirts, and some dress more formally than others but it is not a formal work environment and only a handful wear ties regularly. But when conducting an interview likely all of the interviewers will dress up, they will be in ties and suits and business attire or at the very least neat and tidy. Why? Because it is a sign of respect to the candidate interviewing. So when you show up to an interview we expect the same level of respect.

It gets more subtle here, and the rules are not hard and fast but there are a few tips that really should be observed. Unless it is clear otherwise, men should wear a suit, Navy or Charcoal are the safest, grey if you can carry it off. Do not wear black, black says I only have one suit and I bought it for a funeral – get yourself an interview suit. White suits(not joking) or other colours are likely not going to work, it may work in some professions but in the land of the big corporations and the civil service it won’t do. And many SME’s are have inspiration to be bigger so assume similar attitudes. Women have a little more flexibility, suits are good but anything conservative and smart works.

Software companies tend to be more relaxed, but even in those the hiring managers and HR are likely to still be a little old school, or as I said aspiring to be seen as established companies so if in doubt go conservative. (This is not universally true by any means and in the software industry there can be an almost a reverse snobbery, with ties being seen as a symbol of conformance. Suits are treated in the same way as ripped jeans and scruffy t-shirts are seen in a conservative organisation. Personally I find this sad, I believe you should be allowed to wear what you are comfortable in. Sadly you can be ostracised for non-conformance in either environment.)

Note: For my last interview the interviewing company specifically said that the office was casual, and that I must not wear a suit. The rule here is that you do what is asked, but even so you will still be judged on your appearance. I wore jeans and a casual sports jacket to reflect the culture but I still made an effort to be clean, tidy, and conservative in appearance, even when told to be casual it is better to be on the safe side. It might well be that you can wear shorts and flip flops when you start work, but the interview, like it or not, is about assessing you and so smarter is better.

Attention to detail

It is not enough just to wear a suit, it needs to fit properly, you need to look smart, cut your hair, wear a suitably matching tie (also conservative) and learn to tie it properly (People that know how will notice). Wear smart clean polished shoes either brown or black, and again people will notice. If your shoes look tatty it shows a lack of attention to detail. Some of these rules can be broken if you do it right, I recently had someone interview in a light grey suit with no tie, but he was smart well-groomed and confident, he looked 100 times smarter than the guy before him who had an ill fitting suit and poorly tied tie.

Someone asked me recently whether a waistcoat was appropriate for an interview, my response is that they will stand out, in the same way as not wearing a tie, if they look comfortable and confident and it matches their demeanour then it will likely be okay but it could easily come over as trying too hard or worse the only thing people remember. My advice would be to remain conservative and don’t wear anything showy or save it for a second interview. Unless it is for a role where that would fit in.

Again in the casual environment, you should make an effort to wear your outfit appropriately, and it is still important to be clean tidy and well-presented. Causal does not mean you don’t have to make an effort.

The Greeting

Whether on the phone or in person, greet with a smile and a clear friendly introduction. If in person shake the hand of everyone in the room if possible. If on the phone make a note of everyone’s names. If your name is difficult to pronounce say it clearly, and if you can do it without looking odd repeat everyone’s name that you are introduced to, it will help you remember and ensure you get the pronunciation right upfront.

I’m sure by now you are thinking that everything I have said is about appearance and not substance, and you are quite right, and that is because a lot of candidates are mentally rejected before we even get to the first question. A scruffy looking candidate that turns up late and cannot communicate a clear greeting is not going to fit in to any team I want to be a part of, no matter how technically capable they are. Communication and respect are the two qualities I value most and I will have a pretty good idea of those before you even sit down.

I will try very hard to reserve judgement and to impartially assess the answers to your questions, but the reality is that if you have messed up the first impression it will be hard to recover.

Please don’t bluff

No really, please don’t bluff. If you say on your CV that you are a Scrum Master be sure you can back it up, leading a Daily Scrum when the Scrum Master was off for a day does not make you a Scrum Master. Same goes for technical skills, you are not skilled in C# if you worked in the same company as someone that wrote C#. I know listing lots of skills gets you interviews, but if you can’t back it up you are wasting my time and yours, you will be rejected. If I sense you are bluffing in one area I will assume you are overstating in others. Tell me that you are a competent C# developer and although you haven’t done MVC you have every confidence you could, then I’m inclined to agree with you, but bluff and I’ll assume the worst.

Don’t be afraid to say “I don’t know”

I ask about a lot of skills and experience, I am interested in your exposure to pair programming, TDD, BDD, cross-functional teams, experience with Agile, not to mention various more technical questions. But you don’t need to know the answer to all, no one knows everything and one of the things I am looking for is how you handle your limits. I had a recent interview where I asked those questions on a telephone interview and the candidate wasn’t aware of BDD (Behaviour Driven Development) he said so and asked a couple of questions about it. By the time of the face to face interview he had done some research and done a Pluralsite course on Specflow and Selenium and talked quite animatedly about the subject, his initiative was of far more interest to me than him not knowing an answer. He was the only one of 35 candidates hired.

Nobody knows everything, it is important to be aware of your limits and how you push them. Again another candidate was asked a fairly tricky situational question, he didn’t know how to answer it immediately and asked for a moment or two to think about it, he was polite and we moved on, a few minutes later he brought the conversation back round, said he had thought it through and gave a very good well considered answer.

My assumption is that you can learn what you don’t know, but you can ONLY learn if you first acknowledge that you don’t know it. Someone that bluffs and I see it will be marked far far lower than someone who is aware of their limits.

Are you smarter than me?

I generally hire a lot of contractors so I am expecting a pretty high standard of candidates, as with any form of assessment or estimation it is very difficult to be absolute or objective, so my measure is me. I find it far easier to judge someone by a relative comparison to myself and my abilities than it is to an absolute scale. My general rule of thumb for technical roles is that if I think they could do the job better than me then I am satisfied and will invite them to a face-to-face interview where this interview becomes an assessment by multiple people including technical experts and some canned questions and tests. But I strive to be picky, I’d rather filter too many than have a team suffer from a mistake. Conversely I expect the same when I am interviewed, I expect the bar to be high and have to prove myself.

When interviewing less experienced candidates I am looking for an aptitude to learn rather than learned knowledge, I am far more interested in your willingness to adapt, than in how much you know. Be prepared to talk about how you learn new things, how you stay fresh.

Ask questions

This is crucial, it may be an odd thing to say but I can learn more from the questions you ask than from your answers to my questions. Come prepared with a number of questions to ask, some about the company specifically, so you can show your interest in this role specifically, but for the others make them questions that you are genuinely interested in discussing. If you can demonstrate passion and enthusiasm about a topic that is likely to be common ground with the interviewer. A new tool or technology or aspect of the role something that may open a discussion.

I am mixing context a little here, but when I look for a role I am aware that most people – including me – are driven by three things: Autonomy, Mastery and Purpose. If the description and questions from the interviewer didn’t make these goals clear for the culture of the organisation then ask questions that would clarify this, I am speaking for me now rather than generically but this is now a crucial requirement for me. See more on this – Dan Pink – Motivation

Ask the right questions

By this I mean don’t ask the wrong questions. An interview is not the place to ask about benefits or perks or working hours, and not salary. If the interviewer mentions these make notes but don’t ask about them. You can ask these questions later. A candidate that asks about working from home, or flexi hours may give the impression that these are crucial factors to them and may raise concerns about focus, motives and dedication. Even if unfounded it is better not to give the wrong impression.

Finally

Ask yourself, over and over again. “Do I really want THIS job” it can be very easy to be so excited about getting an offer that you get wrapped up in the enthusiasm that they want you, that you forget to ask – do I want them?

This new job could well be your day to day existence for the foreseeable future, do you really see yourself happy in this role. Consider all eventualities and try to be objective, sleep on it. It is not the only job out there. Just because they have offered doesn’t mean you have to accept.

This is especially true if you have oversold yourself or bluffed, getting the offer is a success but when you start work you have to deliver.

This is now the time where you ask about benefits and working arrangements. If you are uncomfortable with the salary offer say so, once you are in the role it will be far harder to negotiate.
Summary

A lot of what I have said here is my opinion and is subjective, and no doubt there are many different opinions out there. But this advice has served me well both as an interviewer and an interviewee. As with any topic like this I am delighted when I get chance to debate it and be challenged with new ideas, none of the advice should be considered fixed or universally true.

The most important advice though is that you should make sure the job is what you really want. When you are happy in your work and fulfilled everything else becomes easier. Whether you are an interviewer or an interviewee – Please watch the Dan Pink video it may make you rethink how you perceive your own or your team’s motivations.

Reading a Cumulative Flow Diagram

This is a very brief introduction to Cumulative Flow Diagrams, at the end I have included a link to a more in-depth explanation.

A cumulative flow diagram is very simply a fancy way of showing the status of a TO Do list or in Agile terms: a backlog of work – but is in reality just some very basic information in a pretty graph format.

Take a simple To Do list. I have 10 tasks, they can be “To Do”, “In Progress” or “Done”

We represent this by turning these blocks 90 degrees clockwise and stacking them:

What does it tell you?

Ideally the graph will trend upwards, with the Done section ever increasing until all tasks are complete. The axis show number of items on the y, and time on the x

We are interested in how steep the done section is as this tells us our true progress and our task completion velocity (not to be confused with Story Point Velocity). In theory we should be able to draw a line based on the trend line to predict when the remaining tasks will be done. However…

We are also interested in the rate of increase in the ‘To Do’ section, if we are adding tasks to the list faster than we are completing them the list will never be completed. So we are watching for the ‘To Do’ to level off and eventually stop increasing or at least be slower than the done. Otherwise we will have to draw a metaphoric line in the sand and say this is all we will do. In the previous example we had a fixed task list, but normally we do not.

In Agile projects we often analyse requirements and write stories as we progress – “just in time”, stories are added all the time to cover the next few days or weeks ahead and so you will often see the To Do section rising in line with the Done, but at some point the project has to end and at that point we stop adding stories and will complete. This is likely the most efficient way to get work done but make forecasting difficult. Too much up front planning is likely wasteful.

Finally we come to the most important part of the graph, the “In Progress” section. It is a measure of efficiency of a team how few tasks are in progress at once, lean techniques will sometimes measure the average ‘flow time’ how long tasks are in progress or the ‘Mean cycle time’

Teams should be striving not only to get things done, but to limit the Work In Progress,

In this graph the team were taking on more tasks, they look busier, but as you can see from the Done section, the slope of the Done is more shallow, ‘Doing’ was as the expense of ‘Done’

If you look at the graph the average time to finish a task at the lower point was around a week, but then by week 4 tasks are taking an average of over 2 weeks, it might be that they are bigger tasks or it might be that they are multi-tasking which is slowing them down. Watch for teams that take on more ‘In Progress’ it is a sign of problems, the team should be consciously aware of how much ‘work in progress’ they have and that it is manageable.

The real world

Graphs like that are rarely seen, most projects have a change of scope and will fluctuate, below is a graph taken from a real team:

The first comment that needs to be made clear is that this graph shows all items in the To Do list, some are very small tasks, some are huge, the size is not reflected, only the quantity. A small 2 hour spike and a large 20 point story are measured the same.

In this example we have two ‘In Progress’ states, the first is Approved, this means the story has been written, broken down, refined and in some cases estimated by the team and Approved as being suitable to work on. The ‘Committed’ state is work that is currently being worked on by the team.

‘New’ is the To Do list, and as you can see it is steadily increasing, or was until recently and then it took a dip, the dip wasn’t reflected in either the In Progress or Done sections which means there were stories removed, likely they were not relevant to the goal at hand.

You can see from the graph that tasks started to get moved to Done after the first week or so and have steadily increased apart from about 50% of the way through the graph when there was a notable dip in the Done section. Under normal circumstances Done only ever goes up, so this is a cause for interest for someone reading the chart. It is likely that a story was either thought to be Done but wasn’t and was moved back, or the solution was deemed unwanted and removed, either way it deserves comment.

The ‘In Progress’ is fairly consistent, a few times the ‘committed’ is widening and this may warrant exploring why but generally it is pretty steady. The number of items “Approved” is very narrow and may be a reflection of a problem, if there are insufficient stories available for maintaining pace. It is important when doing “just in time” preparation to get the balance right between having enough to sustain pace and too much so that there is waste.

Summary

As you can see the graph, like most graphs doesn’t give all the details. What it does do it prompt the need to ask questions when it deviates from the norm. It is unlikely you can determine the answer to your questions from the graph, further information will generally be necessary, but it can help you form the right questions.

if you are interested in reading a more in depth description of how these diagrams work please ready this Blog

Is structure supportive or restrictive?

I have been engaged in a discussion along these lines with a colleague over the last few days, it is a subject we both are interested in and one that I have been very much on the fence.

I began from a position of a very strong belief that structure was beneficial and that it provides a scaffolding that enables teams to grow. But my colleague took the view that once in place the structure becomes at best a crutch and at worst a barrier to self-organisation and agility.

This conversation is the basis for the usual discussion on whether a Scrum Master is necessary or should they make themselves redundant. Or – Do we need a designated product owner or simply a better understanding of product ownership?

Even to the point of whether there are any designated roles within the team, do we need to identify Devs, Testers, QAs, UX, BAs etc etc or can we consider all “Team Members” that are ‘T’ shaped, that is to say that whilst they possess specialty skills they are first and foremost team players able to cover most of the core software delivery skills.

Baseball

I am (very)English, so my knowledge of baseball is minimal. But today I had someone explain the finer points of ERA and ERA+ and some of the other joys of the statistics of baseball. I can sense you preparing yawns at this point so I shall go no further. But the conversation progressed to “Designated Hitters” players who do not field, they have a specialist skill, or are able to stand in to save the pitcher from batting (another dedicated role?) I may have misunderstood this, but it was described as an “abomination to the sport” by someone that clearly believes that it is a sport where the players must participate beyond their specialty. The converse argument presumably is that if you have exceptionally skilled specialists why should they need to participate in other roles – the team is more effective as a whole by them specializing. Okay so I am stretching the analogy a little, but the argument holds.

Should we specialize

Specialism may aid the efficiency or the effectiveness of the team, but is it still a team sport and can a team ‘self-organize’ if there a members that can only fulfil a specialty role?

And let us suppose that we have two expert catchers, and they have no batting or fielding skills, there is no benefit to having both of them on the team. And what if our best catcher is also a good outfielder, do we use our second best catcher in the catcher position because he only has the one skill?

My view started with the opinion that the most effective teams I have worked with had both a Coach and a Product Owner, that specialism in those roles is necessary to achieve the focus necessary to be optimally effective, both individually and for the team. In the case of the coach his input magnifies the team at a higher rate than adding another team member and for most medium or larger teams the product ownership tasks are demanding and require one person to have a view on many aspects of it – albeit that the team can and should be involved as much as possible.

I stand by this position, if our only goal was the effectiveness of an average team in average circumstances.

The problem with this situation is that there is an implied hierarchy, and that the appointed people in those roles may not be the best choice, that members of the team if enabled may be able to take on some or even all of those responsibilities. Essentially those enabling roles also become limiting factors to growth.

So long as there is a coach there, some of the team will use them as a crutch, the implied hierarchy may disguise or suppress dysfunctions, the coach may be more valuable elsewhere or in another role but is constrained. The same for Product owner, they can easily become a bottleneck as much as a facilitator/enabler. And let’s be frank how often is the workload for a coach or a product owner approximately 1 full-time employee. Chances are one or the other or even both will be grossly over or underworked and consequently stressed or bored.

The teams will never become completely self organising in those situations. Not until enough of the team are skilled and effective in those roles and are able to internally organize themselves. And that can and will only happen if they are allowed to grow into that.

What to do?

But of course just starting on day one and say “go organize yourselves” would be madness in most circumstances, the skills are not off the shelf skills and generally come more from experience than teaching. But having guidelines or even common practice of teams of that structure creates an expectation of what ‘good’ looks like, and it becomes a self-perpetuating concept.

My belief and I am conscious I may be a minority here, is that we provide scaffolding, but from the outset make it clear that the end goal is independence from constraint, that the structure presented is to enable learning and will eventually be removed. That we take our ‘T’ piece team members and we encourage them to diversify further, to become capable and aware of more skills. We support specialism, specialty skills ARE valuable but all rounders are more valuable.

Say no to designated batters…

We don’t want designated batters, we are a team, and in a team we still function near to 100% if/when we lose a player. If that means we lose some specialists because we favor all rounders, perhaps that is a risk we have to take. I don’t believe this means that we compromise on quality, it just means being more open to learning other skills.

Coaches should focus as much on teaching and enabling independence as they do on effectiveness. The pragmatist in me still believes that we are a long way from this ideal, and that in most cases the teams will likely organize themselves with designated product owners, QA, UX and Devs, as inevitably there will be some people that are more skilled than others, but I would like to see us blurring those lines to the point where it is difficult for an outsider to recognize.

The teams will likely still desire coaching and support in difficult situations, I am still of the opinion that we all benefit from coaching (even/especially the coaches), but if this can be owned by the team and it can be their choice as to who and how performs the roles we will be much closer to the goal of self-organization.

A lofty goal and one that will likely have a few hiccups along the way, but I am beginning to believe that we can use the scaffolding of structure to be a stepping stone to self-organization.

Scrum at Home – Agile for kids

There was a discussion recently that I participated in where someone asked if you could run Scrum at home for your children. There were a lot of interesting comments and a lot of good observations, generally the consensus was that Scrum was not suitable because most of the tasks for a child are specific to that child. But I shall explore in a bit more detail because I felt that the discussion missed the most crucial question that a coach should always ask.

What problem are you trying to solve?

Now I cannot speak for the people in that discussion so I shall speak based on my own observations and experiences.

Generally in agile we are about finding better ways to give your customer what they really want. But in the case of Agile for kids the goal isn’t what they produce it is far more about the learning on the journey. I want my children to learn to be self-organising, pro-active, quality conscious, results focused (not done until it is done), to learn to prioritise, to learn to communicate, in some cases cooperation and teamwork. The tasks/stories are merely tools for that learning.

This is a variation on the traditional expectation of mastery purpose and autonomy. If the tasks are household chores then it may be a stretch to hope a teenager will have an implicit desire to master the skill of mowing a lawn, purpose too, may be a hard one to cover on a week to week basis. Autonomy on the other hand may well be a motivator. There was no real shared vision.

How to motivate?

So if we accept that the motivators that we generally promote don’t apply then we need an alternative. In my case I chose a reward based system, it feels a little like an easy out, but for my example it worked and this is one area that I would be very keen to hear other ideas. Kids are difficult to organise, they have a very specific and well honed sense of what is fair – and often it is irrational, this was most definitely an experiment that could go badly wrong.

The constraints and selected framework

I chose a combination of Scrum and KanBan, partly because I know Scrum well but mainly because I felt that the problem lent itself to that solution. The stories would be a combination of household chores and homework tasks.

We chose a 2 week sprint model because most chores have expiry dates and were repetitive, and if I’m honest I took a few liberties with the KanBan board and the tasks.

Mom took on the role of Product Owner, Dad as Scrum Master, and the kids as the team.

We began with a kickoff meeting where we discussed which stories we wanted to be done, this conversation was a mix of the jobs we wanted help with, what we felt the children were capable of and some suggestions from them as to what they felt that they could contribute. We produced a list of tasks, setting table for dinner, clearing the table and stacking the dishwasher, making beds on a morning, cleaning bedrooms, cleaning other rooms, mowing the lawn etc etc. Not glamouros but you get the idea.

For each story we refined it, we discussed a definition of done and we specified acceptance criteria, it was a discussion with all of us: did cleaning a room include dusting, or just tidying and vacuuming? Taking our the recycling had a specific date, but many of the other tasks had no expiry other than the end of the sprint.

We then agreed relative size points for the various tasks, one task was fairly easy so got low points another wastime consuming or was undesirable so got more points, we managed to reach an agreement on the relative size of all tasks but agreed that we would re-visit if we felt these were wrong later.

And then on to the reward, we agreed with the kids that we would link pocket money to the board, each story point would equate to an amount of money, pocket money would be paid at the end of the sprint but only and very clearly only for done tasks. We later modified this to being paid when a card reached the done column, primarily as I wanted to teach the children of the importance of completing stories and of prioritising those nearer to beng done.

With the acceptance criteria agreed we created a board, that had 4 columns (and a separate backlog). Columns were:

ToDo, Doing, Verify and Done.

At the sprint planning we would discuss which tasks the children wanted to take on, and whether they felt they could achieve them all. Some tasks were clearly specific to one child because of clear ownership or because the task was age or capability specific, but some were joint tasks e.g. cleaning the playroom, and some were for anyone.

All tasks went in the ToDo column and the kids were encouraged to move cards to doing when they started the task and to verify when they thought they were done. We encouraged them at breakfast to indicate what they would achieve for the day.

We also encouraged them to write new cards for homework tasks or personal initiatives, although these were not assigned points. Merely to help them visualise their work.

When a card was complete they would move it to Verify and ask the Product owner (Mom) to sign it off, mom would go with them to check against the Acceptance criteria and anything that fell short would be bounced back. I am glossing over the screams of how unfair that was, although perhaps I shouldn’t because of all the things I learnt from this experiment it was how important this particular aspect of it was. Being able to say – “but you agreed this last week” took the wind out of the sails of most of the objections, they still sulked but there was much more acceptance that the parents decision was fair because the rules were agreed with the kids in advance.

So task complete, pocket money paid, happy kids, happy parents, card could be torn up or saved for the next sprint.

At the end of the sprint we reviewed what had been done or not done, and even kept a velocity of sorts. A little competition between the kids. We also held a sort-of retrospective where we discussed what could be improved, although this was a harder concept for the children to understand especially the younger one. We discussed workload, priorities and conflicts – “I did more than my share” some cards were ignored because they felt it wasn’t worth the effort. And so on.

But we found that the experiment was for the most part a roaring success, the kids even started asking if there were extra jobs they could do. For joint tasks they used peer pressure to get them all contributing. Rather than having to remind them to do jobs they were reminding us to verify, as I mentioned there was less conflict over what a job entailed.

Problems with the experiment

There were two fundamental problems, the first was the reward mechanism, financial rewards don’t work very well for kids. My 8 year old would see a toy he wanted and when he had completed enough cards for that item, he would stop doing his cards, he didn’t seem to be able to get the concept of saving up for the future. This is something that I think is a reflection of his age, but it made for inconsistent results.

The second was outside interference, at first it was funny but we had a lot of negative feedback, some via the kids. I didn’t understand it, but it was enough to undermine the experiment. The objections were mainly around the reward mechanism.

The third less significant issue was there was a time overhead each sprint and it was not always easy with a busy family schedule to organise this. Although that as always is a question or priorities.

Summary

Overall, I thought it was a great idea, it certainly isn’t Scrum (and I would never claim it was) but it was Scrum-like and the routine worked well for kids. I felt that the kids learnt a lot from it and I certainly learnt a lot. But parenting is hard in general, it is difficult to know whether you are doing the right thing.

I saw them much more self-aware, motivated, it helped communication, and framed boundaries. The kids enjoyed the responsibility and the autonomy.

But in a lot of ways it was harder for me. As it was a mix of parenting and coaching, I found I needed to overstep my normal bounds of coaching and oddly I felt uncertain of how I should behave.

Ultimately we stopped the experiment, but I still feel it was a valuable learning experience and I would like to repeat it in the future. I would need to re-think the motivation aspect as that was really the weakest part.

However, I would heartily recommend it to anyone with older children, and I’d love to discuss ideas on how better to motivate.

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.

How We’re Using Blocker Clustering to Improve

I have just heard of this for the first time today and I think it is such a good idea. I am a firm believer that metrics can be used to help and this is a great example of where focused metrics can show the true impact of what might otherwise be perceived as a minor problem.

I also don’t see this as limited to KanBan either, it would work just as well on a Scrum Board, and a moment or two identifying the impact of impediments is time well spent.

Can I also add that impediments are not limited to blockers: extra work, anything slowing you down, lack of tools or other resources etc also counts as an impediment.

Matt Philip's Blog

I’ve been helping a team at Asynchrony improve using blocker clustering, a technique popularized by Klaus Leopold and Troy Magennis (presentation, blog post) that leverages a kanban system to identify and quantify the things that block work from flowing. It’s premised on the idea that blockers are not isolated events but have systematic causes, and that by clustering them by cause (and quantifying their cost), we can improve our work and make delivery more predictable.

The team recently concluded a four-week period in which they collected blocker data. At the outset of the experiment, here’s what I asked a couple of the team leaders to do:

Talk with your teammates about the experiment
Define “block” for your team
Minimally instrument your kanban system to gather data, including the block reason and duration

The first two were relatively simple: The team was up for it, and they defined “blocker” as anything that prevented someone from doing…

View original post 427 more words

A man walks in to a bar…

I heard a riddle the other day that seemed so appropriate to use as a story writing analogy that I had to share.

A man walks in to a bar and asks the barman for a glass of water,

The barman reaches down pulls out a shotgun and blasts a hole in the wall just to the left of the customer’s head,

The customer, says thank you, leaves a tip on the bar and walks out.

Why did he leave a tip?

The answer is that he had the hiccups. This makes for an amusing riddle but at the heart of this riddle is the very essence of story writing.

The customer has a need, in this case it is to be rid of hiccups, but rather than expressing his need, he phrases his requirement in the form of one possible solution. There is nothing really wrong in what he has proposed but by presenting a solution rather than a need he has limited the potential solutions and limited the scope of the solution provider – the barman. The customer may simply have been thirsty and just also happened to have hiccups, in which case the solution provided did not meet his immediate needs and may well have caused other problems – for example if he had a sensitive disposition.

The barman on the other hand is either a very good or a very bad solution provider, he has ignored the customer’s request, or possibly delved deeper, he has used other means to extract the true needs and requirements and provided what he believes to be a better solution, and judging by the tip, he got it right.

The lesson from this though is that the best user stories express needs rather than solutions, and the best solution providers explore various options, they ask questions and make assessments based on other factors and only propose solutions after they have understood the underlying need being addressed. Sometimes a solution may create conversation but often a suggested solution limits creativity.

And for me one of the great things about Agile is that very often a customer may not know what solution they want until it is proposed to them.

A user story need not be specific, nor detailed, it is best described as the basis for a conversation. The need should be explored before a solution is provided to reduce the desire to shape a need to fit a solution.

If and when a story is presented to you in the form of a solution, then explore deeper, try to get to the heart of what they are trying to achieve, it may be that their proposed solution is the best one, but without understanding the need you can never be sure.

Is Agile a Quantum Leap for a Project Manager?

I have been asked why you can’t have Project Managers in Scrum, and there are a number of discussions on boards that have entertained me, where there is a question about whether there is such a thing as an Agile Project Manager?

The problem for me is that Project Managers are measured on the wrong things, their objectives conflict with Agile goals they are almost always put in a position where they are pressured to conform to a dysfunctional notion. I see them as a sort of dysfunctional Sam Beckett from Quantum Leap “…striving to put right what once went wrong and hoping each time that..” well you get the picture. There is a notion that the plan in their mind is more important than the reality in front of them.

But in Agile we value “Responding to change over following a plan”

At it’s heart, the job of a Project Manager is to plan a project – usually in fine detail, and then to manage the project to ensure it doesn’t deviate from the plan, and when it does deviate, which of course all but the simplest projects do, the PMs job is to take corrective action to get a project back on plan. It is about dates, and deadlines and the all-important plan. (cue lightning, harsh shadows and ominous Gantt charts).

All we need is a strangely dressed hologram saying “Ziggy predicts that if we skip all testing of the software there is a 93% chance that we will meet our deadline and the software wont devolve in to a pile of un-maintainable junk for 9 months and 3 days.”

The project Manager then gets to ‘Leap’ to a new project without having to stick around to see the mess left behind.

This is in so many ways the very opposite of an Agile philosophy, I see nothing wrong in having a plan, understanding the vision and the goals is crucial. Even some milestones are often beneficial, but the more detail there is in the plan the more waste there is. Everyone including the Project Managers know perfectly well that the plan is flawed, just like every other plan they have ever produced, the difference is that in Agile we accept that the domain is too complex for a fixed and immovable plan. In agile we adjust as new information becomes available, but the traditional Project Manager wrestles with reality and desperately fights to shoehorn a complex reality into a flawed plan. We all know this, the statistics on ‘failed’ project plans are staggering and yet some still persist in this notion of creating fixed plans and punishing teams for deviating from them.

Agile in contrast focuses on getting the customer what they want, and they do this by getting something to them as early as possible and as often as is practical and then responding and re-evaluating, changing the plan to accommodate the customers evolving requirements. Maximizing value early for the customers benefit.

So can there be an Agile Project Manager? I don’t know, but if the role involves valuing following a plan over responding to change then it becomes an oxymoron. And with a Product Owner and a Scrum Master I fail to see what useful purpose they can serve in a Scrum framework.

Not having a plan is not “Being Agile”

What sometimes gets lost or at least confused is the notion that ‘Agile’ is at its core it is a form of project management, a style of planning. One of the main benefits of Agile is that it is restrictive and limiting. It forces focus and prioritisation and it limits work in progress, it mandates reflection and improvement. Doesn’t sound very Agile at all does it? Terms like “Limits”, “Mandates”, “Restricts”, “Imposes” are commonly used in most Agile Frameworks. But in comparison to most of the traditional planning frameworks it is a very flexible way of planning a project. But the flexibility is controlled and structured – the Agility refers to the plan, not to the framework.

Far too often it is misinterpreted – (probably deliberately) as being an excuse not to plan, an excuse not to limit work and an excuse for not prioritising. How often have you read in forums or heard people complain that not being able to change direction during a Sprint is not Agile, or that “we are too Agile for Scrum”, “we can’t predict what our priorities will be for the next iteration”. But before you can have an Agile plan you must first have A plan.

The term Agile is too often used as an excuse not to plan, it’s success and popularity have meant that the term is commonly used and often by those that don’t know what it means but are looking for a ‘framework’ to justify their disorganisation, their failure to plan or as an excuse for cutting corners.

My experience is that Agile is not about reducing work, or about reducing control, it is the opposite. Adoption of Agile methodologies does not reduce work, it focuses you on doing the most important work first, and to do that work to a defined and consistent quality standard. It imposes control and restrictions, there are rules in all of the frameworks, many of them rigid, or at least have a significant cost to unplanned change.

Anyone that thinks adopting Agile will be easy, or that adopting Agile means they don’t have to plan, or document or design or prioritise, has missed the point entirely.

If your organisation is too busy to plan, doesn’t impose quality standards, and flits from one task to the next often without completing the current task or project, simply reacting to the immediate crisis – and there are many departments and organisations like this – then Agile will look very inflexible and restricting, it may feel far less agile when first transitioning to an Agile Framework. But ironically organisations like these where there is little or no planning are probably more in need than those following traditional planning methodologies.

The archer must know what he is seeking to hit; then he must aim and control the weapon by his skill. Our plans miscarry because they have no aim. When a man does not know what harbour he is making for, no wind is the right wind.
Seneca

Seneca uses two analogies there that I find extremely useful conceptually for describing the importance of planning. The first is the Archer, when planning a shot an archer needs to know his target, and he needs to understand his environment and then he pulls together skill, experience and focus to make that shot, if he is interrupted before the shot is made it is likely wasted effort.

Similarly for a ship, if it makes for one harbour one day because the wind is favourable and then another the next day, the ship could be zigzagging all over the place without ever reaching any harbour. Or possibly if the harbour is chosen because of the wind, it is likely not the desired destination, just an easy one. Neither alternative gets results, although in each case the ship is likely making good speed. Rather like many project plans where we feel satisfied if everyone is busy even if we are not actually completing anything.