I do not think that word means what you think it means…

As an Agile Coach I naturally talk about agile practices very frequently, and participate in a variety of discussions with people of varied levels of understanding of agile principles and practices.  But there are certain words that I notice are used with a disproportionate frequency, and used to describe different things. One word in particular gets used very frequently with emphasis and rarely in the right context, that word is Efficiency.  And just for the record, I have been know to misuse it and am making a concerted effort to find the right word for the context, to that end I will try to clarify some of the situations where a different word may be more appropriate.

Efficiency seems to be used to convey such things as. Utilization, Productivity, Effectiveness, Velocity, and sometimes even Efficiency. Naturally I am not suggesting that people are not using English correctly, or that they don’t know what ‘efficiency’ means, but when you look at the examples below you will see that whilst they use the word efficiency in a way that is syntactically correct, they are missing the depth of their question or statement, and often the context. The preoccupation with efficiency results in behaviour that reduces the effectiveness of the team.

For example:

  • Isn’t Pair Programming less efficient than working solo?
  • Isn’t it less efficient to have a developer testing software?
  • Isn’t it inefficient to have the whole team doing story writing (or backlog refining, or stand-up, etc)?
  • Isn’t it inefficient to attend all these meetings, we’d be more productive here?
  • Wouldn’t it be more efficient if I specialize in this one area and all tasks come to me?
  • Wouldn’t we be more efficient and increase our velocity if we ignored technical debt or skipped testing?

I previously covered an example where maximizing utilization of resources was seen as being efficient, but that efficiency was at the expense of the profitability of the business. I think you are missing the point…

In most cases these questions are simply missing the bigger picture, or the larger context.

In KanBan there is a saying that any efficiency improvement on anything other than your primary constraint (your bottleneck) is just an illusion.

If something isn’t on your critical path then it shouldn’t be your focus. Of course as you make improvements to flow and address one constraint the critical path may change, but you should stay focused on the critical path. Identify your constraint and put your efforts there.

Isn’t Pair Programming less efficient than working solo?

The Efficiency of Pair Programming is a recurring question, and one that I likely will not quash here, and that is not my goal. The issue is whether the question of efficiency is the right word, or the right focus for your efforts.

The definition of Efficiency is:  “achieving a goal with the least effort or least waste.” 

Pair Programming assumes two developers at one workstation, and the implication of the question is that more can be achieved with less waste by working independently in parallel.

The problem with Efficiency is understanding what’s it is that you are measuring – what is your goal, and identifying whether this particular activity is your constraint in achieving that goal.

Let us take a car journey as a very simple example: What is the most efficient journey?  Is it driving at 50mph so as to use less fuel? Is it to get to the destination in the shortest time to reduce utilization of the vehicle, or could it be driving in the middle of the night when the roads are clear and the vehicle is not needed by anyone else?

In all of those examples we are focused solely on the individual journey itself and even then we still have ambiguity of which efficiency we are concerned with.  But very likely the reality in that situation the destination is just a step towards the goal. That isolated Driving journey is unlikely to be entire goal in itself – unless maybe I am a taxi driver, and even then I suspect my constraint is maximizing fares rather than reducing costs, so likely maximizing the number of fares rather than driving efficiently is my goal. Driving efficiently only at 4 am may not be the ideal business model.

The road less travelled…

If for now we assume that we are driving efficiently to use less fuel, because fuel is expensive and money is more of a constraint than our time. Then possibly the most efficient journey would be to combine multiple journeys into one (car sharing, or batch delivery), or make a phone call, in this context a journey not taken(or shared), is far more efficient than the most efficient journey.

I glossed over that fairly quickly, so take a moment to think about it. Efficiently doing an unnecessary task is just waste.

Efficiently doing an unnecessary task is just waste.

Time = Money

But hold on, the most efficient journey for me could simply be one that gets me to my destination on time, regardless of cost or duration. My time and the appointment are more important than the cost efficiency of the journey.  Sure I would prefer the journey to be shorter and cost less if that can be achieved without impacting on my goal, but my priority is being there at a particular time. A super efficient journey that gets me to my destination 10 minutes early so I can sit idle for 10 minutes does not help me to my goal, the efficiency gain is just an illusion.

For a while I used to car share, and it saved me quite a lot of money, but I was tied to a schedule and my journey was much longer. After a while I realized my constraint was time and not money. The ability to be flexible over my schedule was a much bigger constraint. My journey became more expensive but I needed flexibility to reach my goal. In other words efficiency in one area may not just be an illusion it may actually cost you more elsewhere as a consequence.

This is a far too common situation in business, a business will often go on an efficiency drive and look to cut costs without any consideration to the larger impact that the efficiency savings are causing. The focus becomes narrow and they delude themselves and often others that they are being efficient, when actually the true constraint is ignored.  The cost cutting creates larger costs elsewhere.

Why? What is the goal?

I don’t mean to labour the point, but to be able to understand efficiency we must first understand the true goal, and it is very likely that the true efficiency we are interested in is related to a goal at a higher level.

Let us revisit the Pair Programming.  Our goal in programming is to deliver a software solution, likely a quality solution that meets the client’s needs, with minimal support requirements. It is likely that they are also interested in maximizing return on investment.  So where does the issue of efficiency for programmers come in?

Pair Programming as an activity shares and grows knowledge, it often enables more creative solutions, the quality is higher, there is an inherent in built code review and QA in to the process. So the question isn’t so much whether Pair Programming is more or less efficient in terms of number of lines of code written; or stories coded; or bugs found; but whether it is producing a better return on investment overall in the context of our true goal: in terms of quality, support and meeting the client’s needs.

I don’t plan on answering the question to the satisfaction of the skeptics but I suspect my opinion is fairly evident.  My point is not to directly answer the question, the point is that the real issue is not what it first appears to be when the question was broached.

If your team is dealing with support issues, bugs, deployment problems, getting features to customers quickly and so on. Then it is possible that ‘coding time’ is not your primary constraint.

In this case the response to the question of efficiency is:  What are you measuring to determine efficiency? Or…   Is efficiency of one singular part of the process our primary goal or is it just an illusion? Would being more efficient help you to be more effective at achieving your goal?

Summary

In this example the word efficiency is taken in a context to justify behaviour that possibly diminishes the effectiveness of the team.  Lean principles do look to minimize waste and to be more efficient, but lean looks at the end to end flow and is only concerned with efficiencies when it is applied to the critical path or a bottleneck and ONLY when those efficiencies are removing waste in the context of our overall goal, not simply a small part of the flow.

If we improve efficiency at a point before a bottleneck all we do is pile up work faster, if we improve efficiency after a bottleneck or anywhere not on the critical path we fail to see the benefit because the flow is already limited by an earlier bottleneck, there is no net gain to our efforts. Our efforts are just an illusion.

As a very generalised statement we as individuals find it inconceivable! (Had to include it somewhere) to view our work as part of a larger scope, our desire to be efficient in our own little bubble often leads us to behaviour that is inefficient for the larger scope that we are part of.  We should be less concerned with being efficient in our roles and more concerned with doing what is effective for the larger system or team we are part of.

Efficiency is not the same as being Effective

Prefer being Effective over being Efficient. Make sure you are effective at achieving the goal first and foremost before even looking at efficiency, and then only if increasing efficiency does not come at the expense of being effective.

Visualising our work in that larger scope is one of the best ways of understanding where we are struggling to be effective and to highlight where the true efficiencies can be gained.  But try to see the whole process not just your part of it.

 

 

 

 

Advertisements

I think you are missing the point…

A brief story….

A team found that many of their impediments and problems with delivery were caused by a lack of access to IT operations or lack of responsiveness, they requested a member of the IT operations team be co-located with (and become part of) the delivery team. This was approved and trialled as an experiment.

From the perspective of the development team this was a major success, delivery times improved, delays were reduced and the major constraint to delivery was aleiviated. In short software projects were delivered sooner and with less complications, the overall cost of delivery went down dramatically.

However, the management team decided to remove the IT ops team member and retrurn them to their old team on the basis that they were not being fully utilized.  The notion of a human resource not being fully utilized was too much for them to bear.

[Please note when I say utilization – that is on IT Ops tasks – they were using ‘slack time’ to support the team in other ways]

When I challenged this decision, I was told that they were unable to increase headcount for IT operations staff unless it could be demonstrated that existing resources were more than 100% utilized on IT Ops tasks over the course of a normal week.  So anyone not 100% utilized was considered a problem for them and became a burden on other team members.

This same IT operations group has a huge backlog of work and lead times were extremely long, they were a major bottleneck for almost every aspect of the business operations.  Sadly the management team did not see any correlation between the absence of slack time and the long lead times.

Too often the dependency on IT Operations and their perceived hindrance to business operations, leads to unnecessary conflicts and frustrations. Usually felt by the staff on the IT Ops teams. But it is because IT Operations are so important that they get this reputation.

How can you justify extra resource if you are not fully utilizing the ones you have?

I have no doubt this is a common story, “how can you justify extra resource if you are not fully utilizing the ones you have?”  In principle this would appear to be a perfectly reasonable and logical statement, and I can understand why many management teams fall into this trap. But it is the wrong question.

What troubled me most was that we had demonstrated that the impact and delays suffered by the delivery team in just this one example were actually costing the organization so much that they could easily pay for 5 or more additional IT operations staff with the benefits gained. And more so that this situation could be repeated all over the business.   The response from the IT Ops manager was that I was missing the point, and they couldn’t justify underutilizing staff.  Their measure for success was maximizing utilization of staff, and not supporting business goals, like say profitability.

I see this mainly as a failure of the business, for not making clear to management where they contribute and how they impact on the larger business objectives. That combined with a manager that either doesn’t see or doesn’t challenge this omission leads to perpetuation of dysfunctional behaviour.

Managing resources effectively not efficiently

I apologize for comparing people to resources, but in this context it is applicable.

Could you imagine if that same principle was applied to other resources?  Your PC would be taken away if you didn’t use it 40 hours a week, you would be forced sell your car because my guess is that you only use it 10% of the time. You would wear the same clothes every day.  Cooking would be a nightmare if you could only have food where all ingredients took exactly the same amount of prep time and cooking time.  I’m getting silly now but it is the same principle, by totally ignoring the reason why we have a resource and focusing entirely on maximizing it’s utilization we behave in really rather perverse and contrary ways.

In any other context the notion that anything less than 100% utilization prohibits buying a second item (regardless of how beneficial) is plain nuts.

Please do not misunderstand, I am not encouraging waste by this, I am encouraging understanding of how resources are being used. When you are meeting the business goals and your flow is optimized, that is the time to look at whether reducing waste is possible but to do so in a way that ensures that any reduction in waste is not hurting business goals.  It may turn out that just like your car, the optimum utilization is less than 100% and availability and responsiveness are valued higher than utilisation.


Summary

In this situation, I am very proud to be “missing the point” and I wish far more managers would take the time to understand how their role impacts the larger business and perhaps they too will miss the point and start asking important questions. IT Operations in particular are the lifeblood of so many businesses and their actions can make or break a business, understanding all the areas of the business that IT operations supports and how the cost of delay is often significantly higher than the individual cost to operations of that task or that ‘resource’.  The ability for IT operations to prioritize and  react promptly to the needs of a business is a far better measurement than measuring utilization of staff.

I’d highly recommend that anyone in IT Operations reads the book The Phoenix Project by Gene Kim, and ensure that anyone that benefits from the service they provide also read it.

Understanding how you contribute to the goals of the business is so important, and if after that you truly believe that your role should be maximizing the utilization of resources and not supporting the business achieve it’s goals, then I would suggest it may be you that is missing the point.

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:

cfd1

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

img_0049
 

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.