STL Agile Open Space 2016 – Self-organising teams

I spent Friday at the St Louis – Agile Open Space 2016. [On Twitter see #stlopenspace ]

It was a fantastic day with a great group of friendly and enthusiastic people all eager to learn something new, I went along with a few of the other coaches from Asynchrony. All of us expecting something different from the event, being new to the area for me it was as much about meeting a few people as it was about learning, but it was such a good experience. And as it always seems to be the case, I learn a little and in doing so I discover how much more there is that I didn’t know that I didn’t know. The sheer wealth of my ignorance grows daily, but I learn something knew and I share what I can, and hopefully it balances eventually.

Self-organising teams

Did you know Dr Seuss was in favour of self organising teams?

There were a number of topics and discussions that drew my attention but the first that I want to share was a discussion on shelf-organising teams. A topic I am always very keen to discuss. The topic was raised by a Scrum Master whose team was moving in this direction and so she was asking for advice and to discuss experiences. Both internally to the team and how this would work with the rest of the organization.

The conversation was free flowing and we covered all sorts of aspects of the concept, as you can see from the post-it summary the conversation touched on whether a self-organising team should have a hiring budget and should be empowered to hire their own team, what the role of a Scrum Master should be in this environment. Even a somewhat controversial discussion on whether the team should be able to choose it’s own metrics and forcasting style when they are ‘consumed’ outside of the team.

Can there really be self-organising teams

The first discussion was one of hierarchy, there was an ‘acceptance’ for lack of a better word- by some of the group, that there is an actual or implied hierarchy and that a team has a manager or the PO or the Scrum Master, or the Team Lead is “in-charge” there was a variety of experiences and opinions on this. But we talked about what-if the team was truly self-organising, and if there was no hierarchy, could that and would that work. And how it could/would work.

I think we broadly agreed that there was no absolute need for hierarchy and a team could build a situation where there was shared responsibility and accountability (Yes I did manage to inject my favorite 5 dysfunctions of a team discussion to describe how you can build the layers of teamwork necessary to enable this to happen) I would say that we broadly agreed it was possible, but there remained a question of how practical or realistic this was in all cases.

We generally agreed that the team most of all needed a common goal, they also needed to have a level of competency, self-motivation, the ability to collaborate, and to have trust and respect for each other. We also broadly agreed that continuity of teams was important – teams that stay together longer are generally better, not a universal truth but as relationships are built over time it can be damaging to break up a good team.

Most people felt there were boundaries for how much empowerment a team could have in a pragmatic context. Growing teams, difficult personalities, changing products/projects and changing needs which impact team sizes. We talked about whether you could allow an organization to sort itself into teams and what the implications of this would be, especially in organizations where billing structures are based on team size or it is service driven.

The conclusion we drew was that a team should not be limited in what they consider possible for improvement, nothing should be off the table. If they believe they are better growing or shrinking or working a 30 hour working week, then any and all are reasonable proposals that a self-organising team could make. But we work in commercial environments and often a larger structure, we do not live in a bubble and for pragmatic reasons we must accept that there will be some boundaries imposed by the organization or indeed by law. But we should be pushing those boundaries and if we are told ‘No’ to something we genuinely believe would improve the team we should push those boundaries and challenge, ask why, and why again.

The Role of the Scrum Master

Does a Scrum Master or team coach fit in this context? This was a fun one to discuss, if you accept that there is no hierarchy and a Scrum Master is simply a role on team equal to any other, they are just one more specialty skill that a team can organize, they may choose whether they want or need a dedicated SM or shared SM or even need one at all, the same applies for a coach. However, there were some caveats here, a Scrum Master or Coach has a duality of purpose and whilst they are idealistically organized by the team, they also have an implied independent obligation to coach the team in to independence – and that probably includes independence from the Scrum Master. But again the choice is the team’s. A good Scrum Master will encourage the team to push boundaries and challenge themselves rather than using the Scrum Master as a crutch. We had a slight aside here where we discussed how a Coach or Scrum Master can grow emotionally attached to a team or teams and can find it difficult to detach themselves.

But in a Scrum team that is moving towards self-organization the role of the Scrum Master is clearer, they need to turn their focus away from the team, to step back and enable the team more independence, and create an environment where the team embraces responsibility and accountability, they are not only empowered but are encouraged to explore it. But at the same time the Scrum Master should turn their attention to the organization and protect the team, push for the team’s decisions to be respected and supported, coach the organization on the merits of empowering the team. Again this should be a role that lessens as the organization becomes accustomed to a reversal of hierarchy and lessen further when the organization begins to feel the benefit of the team organising itself.
Summary

This was just a few highlights of just one discussion of the day, I managed to attend 6 or 7 discussions or presentations and I may get time to write up some more of my notes in the coming week, but I hope this gives a flavour of the content and of the openness and enthusiasm of the participants and the shared knowledge and experience that was in one place. Companies and individuals sharing ideas and advice.

I thoroughly enjoyed my day and I’m looking forward to the next event.

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.

First impressions of my new role

I normally try to avoid making my posts too personal or specific, instead picking a topic to discuss, but I have started a new role a couple of weeks ago and I wanted to share my first impressions before I become acclimitised to the situation and the contrast is not so evident. Because I am so new it is likely that I have not observed all the quirks, and I suspect that there are a few warts hiding, but here goes, these are my first impressions…

Office space

The office is located downtown in an old warehouse with high ceilings with exposed beams and lots of open space, it is full of character and looks great but it isn’t grand or opulent, there is no sense of excess, it is functional and suitable for it’s use. If anything it is not big enough. There are well equipped meeting rooms, Cisco teleconferencing equipment in them to deal with the remote offices. Nearly all of the walls have been painted with whiteboard paint making every wall a dry wipe wall.

There is free coffee and free soda, free parking or free metro passes, which for a city centre location takes away a great deal of inconvenience for staff. Hours are flexible and people seem to arrive anywhere from 6 am to lunchtime, which I can only imagine makes some elements of teamwork difficult, but it is great for the workers.

Very few people have offices, I’d estimate less than 5% of the staff, and those that do have a clear need. In a fantastic example of a management team being in tune with the rest of the workforce, the CTO had a slightly larger office but when he saw that another team were struggling to fit in theirs, he volunteered to move to a smaller office so they could use his. It is very rare to see a leader voluntarily inconvenience themselves for the benefit of others.

Right tools for the job

The office is mainly open plan with teams sat together in clusters, the developers and the rest of the staff seem to be extremely well equipped, there is no sense of taking any shortcuts on providing teams with the right equipment. This may seem to be common sense, but it is the first place I have worked at in 20 years in software, where the developers haven’t had to fight very hard to get suitable equipment. That in itself is something you may have seen me write about often, developers work better with the right tools, and they are the best judge of what the right tools are.

Management

Really this is “What management?”, as there is none to be seen. I am still getting to grips with it and trying to see if there is something I have missed, but as far as I can tell the vast majority of the workforce are developers (I am including QA and UX in this category) and they all nominally report to the CTO, and with so many developers it is pretty obvious that management involvement in their day to day work is minimal. Essentially it extends to assignment to a team and assistance and support when requested.

How can you achieve such light touch management? My assessment is that they achieve this – By hiring the right people in the first place and trusting them. The almost complete independence is the aspect of this role that I am still adjusting too, as far as I can tell the workforce have such enthusiasm for the work that they even spend their free time working to improve themselves with work related activity, attending learning lunches, weekend hackathons, lunch time book clubs, lunchtime science fairs. I have worked with some great teams in the past, but this is the first time I have seen this level of enthusiasm for the work – and for Agile. Agile seems to be core to the culture of the organisation and the universal enthusiasm is refreshing.

They also want to spend time together in a social capacity, there are numerous social activities that are well attended, family games nights where the office is used for staff to bring in families to play games and eat pizza. There are lunchtime Halo groups that use the meeting rooms and big screens to play halo – or similar games. There are plenty of social lunches and company events.

Agile Team for Hire

For those that know me personally, I have been talking for years now about the notion that when you have a good development team, it should be considered a single entity to those outside the team – an engine or machine to be used as a whole. I have been proposing the notion of a business model where a team is sold as a whole and billed by the hour(or sprint) on a time and materials basis. My experience has often been about hiring individuals to produce a team and train them, build them and then use them, this takes time and costs a significant amount of time and money, it is a slow process of build-up before they reach the standard of a good delivery team, and then all too often the team is broken up and you start all over. I have for a long time had the belief that you could achieve more by creating/building a high performing team and by maintaining the cohesion of the team you are able to maintain the consistency of the performance, you will gain far better results by moving a highly functional team onto a new product than by building a new team each time.

What has struck me about this new role is that they have done almost exactly that. They have built the teams, they put a lot of effort into coaching them to maintain peak performance and they generally move teams to different products – when and where that is practical. This means that the teams have cohesion and consistency, and have a huge technical capability advantage over any internal comparison teams at clients, this is as close to my perception of how it should be done as I have ever seen. And to say that excites me is an understatement.

Development practices

I have long been a fan of TDD and BDD and Pair Programming, of continuous delivery and focusing on business value, customer interaction and sustainable pace amongst other things. The teams I have worked with in the past have seen my eagerness when they have adopted any of these practices, and I like to think I have helped them get the most out of some of these skills.

But having been here 2 weeks I am suddenly aware that I had my sights set too low and my expectations far lower than I perhaps should have had.

The teams here practice most of what I mention above, but also other techniques I have not been familiar with before like:

“Evil pairing”

“Mob Programming”

“12 Factor” see 12factor.net

“Pair programming during an interview”

And many others.

I will do my best to write about these techniques in more detail and share my experiences over the coming months.

Summary

It is not all a bed of roses, this is an organisation of hundreds of people and as we know that all problems are people problems and that all people (especially me) are dysfunctional in their own unique way, this adds up to a variety of problems. There are areas of the business that I feel are weaker than others, and some that I even think I can add value too. But the overriding sense is that the whole organisation is on the journey together, it is very promising.

As a coach it will be a very different challenge to what I have become used to. I’d say I’m not in Kansas anymore, but I’m actually far closer to Kansas than I have ever been. It is time I practice what I preach and see that there is always more to learn, always room for improvement. It has been a shock for me as I have gone from feeling like I was pretty knowledgeable and confident in my Agile coaching skills, I had become over confident and self-assured and this has been a huge wake-up call for me, I now realise that I am still a beginner and that I will be far more challenged in the hopefully years ahead. I am now in a team of 7 Agile Coaches and the quality of my peers is frighteningly high. The opportunities for learning are huge and my challenge to myself is to learn as much as I can from them.