Author: Piotr Nowinski

Benefits of using Scrum [over waterfall]

Agile is probably the best approach when it comes to developing complex IT solutions. It’s widely used in product development, but unfortunately, it’s still not that straightforward when you’re working for external clients. The problem is that in far too many situations it’s the corporate purchasing department that awards the seller with a contract, and fixed-scope, fixed-time and fixed-schedule is the only solution you can pitch for and count on.

The good news is, however, that in many cases there is a place for negotiations and you can have a chance to present your vision of how the project should be delivered. You won’t probably end up in a T&M agreement, but you can have a chance to agree on the model that would enable you to benefit from using Agile and talk the client into some adjustments to the process.

I was personally involved in several discussions like that and I think that the most important part of your presentation is to concentrate on how the client can benefit from using Agile and what are the main advantages of Agile over traditional waterfall approach. It’s not the time for describing details of the framework, it’s your chance to present some convincing and easy-to-understand-at-first-glance slides that would hopefully result in awarding you with something better than fixed-scope, fixed-schedule and fixed-price agreement.

Below please find a compilation of slides that I used in some of my presentations, and that shows the advantages of Agile over waterfall approach. I hope you’ll find them helpful.

Link to SlideShare

 

Tracking progress of the release

Having a potentially shippable product every sprint lies in a heart of Agile, but in many organisations – especially the ones that don’t work in SaaS model – a product is not released to the market every sprint. Sometimes frequent delivery is not possible (i.e. in case some additional tasks like a translation of a documentation, legal approval, etc. have to be done at the end of the release) or it’s not even desired. What happens in such cases is that delivery to the market is organised in some more or less formal releases that are shipped every couple of months (internal releases can be still more frequent, though). Working with releases doesn’t require almost any extra efforts, but still, it usually involves some additional activities like release planning and requires for tracking progress on a release level.

Tracking and adapting to changes on a release level becomes particularly critical if release goals are directly or indirectly bound to some marketing or sales activities that require some up-front planning and synchronisation. Fortunately, tracking release progress is not a rocket-science and most software tool that are available on the market support this functionality. JIRA, the tool that I’m familiar with, provides you with 2 simple reports that you can use at easy.

Version Report

Version Report shows your progress towards completion of a release (estimated work). It uses average velocity and estimated amount of work remaining to predict a forecasted release completion date (a date when all the estimated issues in the release are estimated to be completed). In addition, Version Report can be also used to monitor how a scope of the release has been changing since the start of the release which can be a useful tool for checking if release planning was valuable (great input for adaptation and team’s retrospectives).

You can read more here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-version-report

Release Burndown

Release Burndown report shows how you’re burning story points of all the estimated stories that were planned for the release. It uses average velocity and estimated amount of work remaining to present a predicted number of sprints that are required to complete the release. Release Burndown report presents information on per sprint basis and therefore it can be used to track how much work was added, completed and left remaining in/after each sprint.

You can read more here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-release-burndown

 

Splitting large features into smaller stories – Elephant Carpaccio

Many teams transitioning to Agile struggle with delivering a potentially shippable product every sprint. Producing a piece of software that provides a business value to a client every 2 weeks seems impossible. Usually, teams say that they can deliver either front-end, or backend, or architecture design for a given feature, but not all these together.
It’s a common problem for many teams that are new to Agile, but my experience shows that it’s also a problem for more mature teams that prevents them from advancing to the next level of agility.
Why is that? IMHO it’s because many teams struggle with a concept of delivering software incrementally and they are much more focused on an iterative part of Agile paradigm. They struggle with understanding that larger features don’t have to be implemented in one chunk and that they can be built in several steps. It usually means that a given feature won’t be perfect from the very beginning, but it doesn’t have to be! It’s one of the key concepts of Agile – deliver value incrementally, wait for client’s feedback and adapt accordingly (if need be).
Many developers say that they can’t split a given feature into smaller chunks not because they are not capable of doing so, but because from their perspective something less than a whole feature is imperfect, non-functional and not worth presenting to any stakeholder.
It may be a huge problem because it influences planning and tracking & monitoring, and therefore impacts transparency and works counter short feedback loops. Improving it requires changing the mindset and adjusting way of thinking which is never an easy process.
The good news is that teams are not doomed to fail here. First, they learn how to split larger features into smaller chunks as they progress with Agile and gain more experience. In addition, Agile itself forces them to do so because there is nothing more embarrassing than holding a sprint review and having to explain to stakeholders that there is nothing to present and discuss.
In addition, it’s possible to encourage the right approach by doing some exercises with the teams. One of them is called “Elephant Carpaccio” which I hope you’ll find useful. It was originally proposed by Alistair Cockburn and you can find more details about it here.
I executed this exercise with my teams and I must say that the results are quite promising. Of course, there were a lot of discussions and complaining, but overall people liked the idea and said they learnt something from doing it. Pretty much everyone agrees it was a challenge to split an application they would deliver in 1 hr into 20 small user stories, each of them of a meaningful value to a client.
If your teams struggle with splitting large features into smaller stories I recommend doing this exercise with them. It’s bit “artificial” but should result in some fun and good discussions afterwards.

Transparency

Transparency is a key value in Agile organisations. It improves employees’ motivation and make the teams perform better. At the same time, transparency is difficult to achieve, because it usually requires serious changes to company’s culture and mindset. You can’t do it overnight, but fortunately, each and every step towards this goal counts.

Transparency allows for building an environment of trust and safety which is a foundation of great teamwork (you need teamwork to succeed and there is no real teamwork in the absence of trust – please refer to a great The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni). Transparency can’t be implemented top-down, it requires senior management working together with their teams on improving all company’s practises and policies.

The good news is that transparency is not binary. You can constantly work on this doing it step by step. Fortunately, full transparency is not a myth, because there are companies that are already there. A good example is Buffer that shares their thoughts, results and progress on their blog. I highly recommend reading some of their posts, because, in my opinion, it’s a great source of ideas for other teams and organisations.

Personally, I’ve never worked in an organisation like Buffer, but some of the companies I worked for were reasonably transparent. My experience confirms that transparency boosts trust and teamwork and makes everyone concentrate on contributing to organisation’s overall success rather than spending time on trying to game the system.

Recommended reading:

Art of Delegating

Introduction

Empowering people and teams is critical for organisations to gain competitive advantage and succeed. Smart delegating of responsibilities results in more engaged employees, better culture and improved overall productivity of a company. Knowledge and experience are shared among a larger group of employees which in turn increases organisation’s flexibility and agility. However, it’s easier said than done. Intelligent delegating is an art and it can’t be achieved overnight.

Micro-management trap

Most managers know that they have to delegate some of their tasks to the teams they oversee. The problem is that delegation can be implemented in many ways, and doing it wrong is counterproductive.

Many managers fear for losing a control, therefore, they don’t empower, but micro-manage. They assign tasks to employees, but stay too close to the details, break in on a regular basis and rarely accept final results without any “corrections”. As a result, a quality of work declines, because it’s impossible for employees to meet their manager’s expectations and people stop bothering with producing great results as they are going to be changed anyway.

Delegation is an investment. Employees have to be trusted and allowed to fail in a safe way to gain real experience. They need to be coached and it will take a bit of time and energy before they become competent. Delegation has to be carefully planned and level of responsibility has to be increased gradually.

How to delegate

Delegation is not binary – you don’t need to choose between delegating everything or nothing. Delegation depends on context, maturity of the team and individuals and significance of the decisions to be made. Responsibilities have to be delegated gradually, in a controlled way. You have to designate as much as possible to empower the team and let them build experience, but you also need to avoid introducing disarray and undesired side effects.

It has to be emphasized that to make a delegation work you have to define clear boundaries for the tasks assigned and employees have to understand the responsibilities they are assuming. Specific, well-specified goals and measurable key results may be very helpful, especially when the team is new to a type of actions being commissioned.

Any delegated task must be also followed by a delegation of authority (power, resources, etc.) required to get the job done. A level of authority should be set high enough to enable people gain experience, but not too high that things can easily run into chaos.

I suggested that micro-management has to be avoided, but it doesn’t mean that you shouldn’t monitor the tasks you delegate. Don’t track the details and give employees a freedom to act, but don’t hesitate to share your concerns or take a corrective action when situation slips out of control.

Balancing authority and accountability

It’s vital to keep a healthy balance between accountability and authority. Lack of harmony may calmly lead to failures and, as a result, delegation itself can become an innocent victim.

If somebody is accountable for a successful completion of a delegated task but has no authority to make it happen, she can easily become a scapegoat to blame. She isn’t doomed to fail yet has very little influence on how things are happening. On the other hand, if somebody has wide powers, but no real accountability for the results, it may lead to misconduct and evaporation of trust and teamwork.

Demonstration

Below please find a simple exercise demonstrating that a lack of balance between authority and accountability may lead to behaviours we need to avoid. Steps:

  • Pick 4 strong guys who will be lifting a chair with a person sitting on it. They play a passive role here.
  • Pick 2 volunteers – let’s say A and B – who play main roles in the exercise.
  • A sits on a chair and B is asked to say how far the chair (with A sitting on it) should be lifted up in the air. In most cases B says that it should be lifted as high as possible, close to the room’s ceiling preferably. Everyone, except for A, has a lot of fun.
  • Once done it’s now B who is asked to sit on a chair that will be lifted up to the same high he previously requested for. Out of the sudden A is the only person smiling.

In the first scenario B has a lot of authority and no accountability (he wasn’t risking anything). The second case shows that lack of balance between authority and accountability leads to unacceptable behaviours. In the first case B isn’t personally risking anything therefore he is more inclined to gamble and potentially compromise a success of his colleagues. Long-term it will destroy trust and teamwork and influence overall organisation’s performance.

The 7 Levels of Delegation

As stated in Jurgen Appelo’s Management 3.0 book there are 7 levels of delegation:

  1. Tell. You make a decision and communicate it to others.
  2. Sell. You make a decision and you explain your motivation to others.
  3. Consult. You make a decision based on a careful consideration of other’s opinions.
  4. Agree. You involve other in discussion and you make a decision together.
  5. Advise. Others make a decision after listening to your opinion.
  6. Inquire. Others make a decision and then share their motivations. to you.
  7. Delegate. You’re not involved at all.

The 7 levels of delegation can be used to define how responsibilities for some decision areas are delegated to individuals or teams (it helps to establish basic boundaries, levels of authority, etc.).

Delegation Board

A delegation board is a nice tool to visualise how different types of responsibilities are delegated to teams of individuals according to the 7 level of delegation.A delegation board can be used at many levels (team, department, etc.) and should be located in a place where everybody can see it. It supports setting boundaries and levels of authority and works as a powerful communication tool.

Further reading:

 

Inter-team Commitment Stories

Managing complex and lengthy projects is a challenge. When dozens of people are working on the same product in parallel there has to be a mechanism for identifying and resolving dependencies and cross-team blockers.

In traditional projects, it’s a PM’s task to ensure that all the team members are working on right tasks in right order. She is the one who decides about priorities, monitors progress and initiates corrective actions when required.

In the Agile world, there are self-organising teams that are accountable for delivering outcomes they committed to. There is nobody who defines how the work should be done or what actions need to be taken. Of course, there is a Product Owner who sets priorities, but there is no direct mechanism for synchronising work between various teams.

There are several frameworks (i.e. Scaled Agile Framework or Nexus Framework) for scaling Scrum that provide some solutions for managing complex product development efforts, but still it’s up to the teams how they self-organise around managing project dependencies.

A solution that can help resolve a problem of managing dependencies in complex Agile projects is a mechanism called Inter-team Commitment Story (please refer to Agile Project Management by Jim Highsmith).

Inter-team Commitment Story (ICS) is a form of a story that works as an agreement between two or more teams. It’s a kind of a contract that defines set of responsibilities on each party’s part and specifies what and by when should be delivered to get the dependency resolved.

ICS may be somehow overseen by an integration team or project leader (they can be the ones to identify the dependencies in the first place), but it’s teams’ responsibility to mutually agree how a given dependency will be handled. Of course, it’s also Product Owner’s responsibility to make sure that Inter-team Commitment Stories are prioritised accordingly and that a pressure to deliver business stories doesn’t make some teams blocked.

Inter-team Commitment Stories are planned and scheduled as all other stories in the product backlog. And most of all, ICSs are estimated so that the cost of managing team-to-team coordination is not hidden. The main advantages of this mechanism are:

  • dependency management and coordination work are visible,
  • it downgrades the coordination from project manager to teams that know the details,
  • it helps to build accountability,
  • it supports inter-team collaboration and builds cross-team relationships.

 

Estimating software projects

Couple weeks ago I came across a great article about software estimation by Pawel Brodzinski which made me think about how my approach to estimating software projects has evolved over time.

At the moment I work in product development where Agile approach is used to deliver new increments of software. We have stable teams and we use Story Points and Velocity to estimate and plan our sprints and releases. But I used to work in project-based companies where a reliable process for estimating projects was a key factor for our long-term success. It wasn’t important only from project perspective, but the estimates were used to forecast our revenue, they influenced recruitment, resorucing plans, etc. They had to be more or less right.

Estimating software projects is difficult, error-prone and time-consuming. Of course, one may say that Agile approach is a good solution to this problem, but unfortunately not all the clients are willing to follow it. In your response to many RFPs you’re obliged to provide 2 numbers (I call them “RFP twins”) – cost and delivery date – before you even have a real chance to talk the client.

My personal experience confirms that spending more and more time on estimating doesn’t improve the quality of an output you get. It’s even more misleading because adding more details to the scope definition doesn’t make the final estimates better, but it makes you biased by feeling more certain about what you have just come up with.

Years ago I thought that giving lot of time to senior developers to analyse the scope, break it down into tasks and estimate them, would give us an accurate project schedule and minimise a risk of failure. Project life showed, however, that it didn’t work as expected and that our estimates were usually wrong regardless of how much time we invested in getting them.

Over time my approach to estimating software projects has changed and I started using a different process for getting estimates. The first step is to define a team that is going to work on the project (something like 1 full-time visual designer, 2 developers and QA specialist, etc.) and then involve experts (that team, preferrably) to say how many days/weeks/months (units depend on an overall project size) that project is going to take. The scope is no longer split into fine-grained tasks, but it’s rather broken down into a couple of a high-level modules/functionalities/deliverables. The whole process is time-boxed to prevent digging into too many details and to minimise the effort that is invested.

The second step is to compare the results with projects of a similar type and size that were done in the past. I don’t have a precise definition of what “similar type and size” means, but the teams usually don’t find it difficult (it can be a project that a similar team worked on or a project with similar functionalities, etc.). This approach is far less “scientific” than the one described by Pawel in his article, but the goal and reasoning remain the same – to use historical data to verify the estimates and to avoid being biased.

Finally, the estimates should be provided as ranges (like “this project/functionality requires 2-4 weeks of a given team effort”) – bearing in mind the huge uncertainty creative software projects are faced with you should be aiming for a right order of magnitude rather than a precise number you’re never going to meet.

Last but not least, all the assumtions that were made during the process should be documented and stored along with the estimates. I even suggest that a thorough, generic list of assumtions is built over time so that it can be used as a checklist and therefore save time and make you not forget about “something obvious”. Moreover, assumptions usually enable you to come up with some changes to project scope that can be presented to the client and that could lower the costs of the whole endavour. From my experience I can say that such suggestions are usually a good starting point for more detailed discussions with the client (especially when the client was initially reluctant to do so) and makes it easier to convince the client to have some workshops with you before final cost/schedule commitments are done.

 

To summarise, I recommend using the following ideas when estimating software projects:

  • use historical and empirical data as much as possible to avoid biases
  • if only possible, organise workshops with the client to get a better understanding of the client’s needs
  • combine different approaches (i.e. statistical forecasting + sanity check by experts)
  • don’t spend too much time on estimating – it won’t improve your numbers after all
  • provide estimates in ranges (the project will take from n to m days/weeks/months)
  • invest in accuracy, not precision
  • document your assumtions

 

 

Rewards and recognition

Introduction

An effective reward system can motivate employees and increase their work performance. It can have a very powerful influence on people’s behaviour and, therefore, many organisations implement it as an integral component of their compensation strategy. However, not all reward programmes are beneficial. Moreover, inefficient systems are counterproductive, destroy creativity, hurt morale and disrupt collaboration.

A reward system can serve multiple goals and identifying the desired outcome is critical in developing an effective bonus programme. A good system should include some or all of the following objectives:

  • Attract talented employees.
  • Motivate employees and shape their behaviour in the desired direction.
  • Promote personal growth and development.
  • Foster teamwork and collaboration.
  • Increase employee satisfaction with their work.
  • Prevent talented employees from leaving.

Types of motivation

Extrinsic motivation refers to a motivation that comes from outside an individual. The motivating factors are external rewards such as money, grades or praise. An extrinsically motivated person works on a task even when she has little interest in it because of the anticipated satisfaction she gets from some reward.

Intrinsic motivation refers to motivation that comes from inside an individual rather than from any external sources. The motivation comes from the pleasure one gets from the task itself and external rewards have little or none influence on it.

As you can see extrinsic motivation and intrinsic motivation are both important ways of driving employees’ behaviour. Many studies suggest that intrinsic motivation is better, but please bear in mind that it is not always possible in each and every situation. On the other hand, studies have demonstrated that offering excessive external rewards for an already internally rewarding behaviour can lead to a reduction in intrinsic motivation, a phenomenon known as the overjustification effect.

Bonus schemes

Bonus scheme is probably the most popular and widely implemented reward system. The main problem with bonus scheme is that it may work quite well for top-managers or sales-type roles where numbers are everything, but it’s not that good for creative workers that deliver results that are difficult to objectively measure or assess.

What’s more, as soon as a bonus scheme is applied a reward becomes expected. That is, it’s seen as a part of annual remuneration and not getting it (or getting less than anticipated) is a disappointment. Being expected makes also no room for a warm feeling of achievement when the bonus finally arrives which doesn’t make it work as a true motivator.

Furthermore, in many cases, a bonus is tightly bound with the employee’s performance review which usually results in some people not getting it at all. And this leads to having a group of employees that were told they were failing in their job which, from their perspective, doesn’t sound very motivating.

Finally, bonuses awarded based on the results of performance reviews create jealousy among employees and increase a risk of cheating. Instead of doing good work many employees starts focusing on bogus activities and getting a good bonus. The metrics often also ignore the soft side of good performance, including teamwork and collaboration.

Example of a bonus scheme that led astray

I worked for a company where the quaterly bonus was calculated automatically based on a number of hours you spent on billable projects (sickness leave, training, holidays or periods of time when no client-related work was available were obviously non-billable). Moreover, you were able to get up to 130% of your bonus depending on an amount of overtime work you presented.

It was supposed to be an objective measure that should lead to increased employees’ engagement, but the results were counterproductive:

  1. Creativity significantly dropped (it was against your personal interest to find better ways of doing things and deliver results faster).
  2. Tasks started to be overestimated.
  3. Quality declined (fixing bugs was considered as a billable work).
  4. Almost everyone started doing a lot of overtime work (but productivity didn’t necessarily increased).

As you can see implementing an objective bonus system is difficult, and in many organisations, it’s just a myth.

It’s not only about cash

Many people assume that money is the only motivator to make employees work harder and that it’s the only solution to address extrinsic motivation. Unfortunately, such an approach is wrong and long-term destroys intrinsic motivation which is usually more effective and more sustainable.

Please bear in mind that individual employees respond differently to a particular reward type. Some people are motivated by cash, but other can be more inspired by social rewards like praise or recognition. It’s, therefore, important to understand the motivational factors of each individual employee and distribute rewards based on employee’s preference and his resulting degree of motivation.

For example, you can reward employees by:

  • recognising personal or team achievement in front of others,
  • celebrating successes, organising events, etc.
  • delegating more responsibility to a team or an individual,
  • assigning an employee to a new, challenging task,
  • sending a team or an individual to a training,
  • offering perks or small gift cards,
  • giving additional time-off,
  • offering small gifts or services to employees’ families (tickets to SPA, a free babysitter for an evening, etc.).

The most important thing to remember is, however, that nothing will probably work until you create a friendly work environment and build a culture of trust. An effective rewards and recognition system is the next step, but definitely not the first one.

More ideas about motivating employees can be found here: 37 Ideas for Motivating Your Employees.

Involve peers

In a competitive, uncertain environments most of us work in, employees compensation plan should consist of two main parts – a stable, predictable salary and additional bonus that is dependent on how individuals, teams and a whole organisation are performing.

According to Jurgen Appelo a good reward system should meet the following objectives:

  • salaries are expected, but bonuses are not,
  • rewards should be based on teamwork and collaboration, not competition,
  • peer feedback the main driver in assigning bonus,
  • creative thinking and wisdom of the crowd should be used to grow and improve reward system,
  • bonuses should address intrinsic motivation.

The solution Jurgen suggests is a system (“merit money”) in which employees recognise performance and contribution of their colleagues by giving away a virtual currency to other team members.

Virtual currency

Virtual currency represents merits that employees can get from their colleagues and accumulate over time. You can use any name you think is fun and relevant (credits, points, hugs, etc.), but please make sure that no real money is used. For the sake of this post the term “credits” is used.

Sharing credits

Every month or so every employee gets an equal pool of credits to share. All the credits have to be shared with others, nothing can be kept for yourself. However, how the credits are assigned to others is a subject to individual’s decision – one can distribute all the credits to one person while others can spread it evenly among all their colleagues. Every person has his own definition of what the best performance mean, therefore, opinions of all employees are equal. At the end of the process, all the credits are distributed and people that efforts are valued the most earned the highest number of credits.

Cashing bonus

The credits people share and earn accumulate over time. From time to time (random intervals so that it’s not expected!) there is an option for credits to be cashed in using a fixed exchange rate.

A monetary value of the credits may depend on budget and company’s profitability, they can also be treated like shares on a stock market. Employees can have a choice – either they cash the credits or save them for the next round hoping for their value to increase.

The details of the process are a subject for a discussion with the team, but the idea is to make sure that credits are not routinely treated as money at the moment of sharing them.

Continuous improvement

Don’t be naive – people will try to game the system. But instead of cancelling it please involve employees in making it better. It’s in their best interest to have a fair and reasonable reward system, and I’m sure they will come up with many ideas worth implementing.

Evolution, not revolution

Please bear in mind that changing the current reward system doesn’t need to be a revolution, it can be done step-by-step. For example, 30% of the bonus budget can be assigned to a new programme while the rest is still distributed by managers based on employees performance reviews, goals, etc.

The main advantage of this system is that it involves employees by delegating to them a process of recognising performance of their peers. It’s people’s, not manager’s, decision who, in their opinion, contributes the most to the overall success of the team and what kind of behaviour is valued the most.

The process is motivating in 2 ways – delegation of responsibilities improves engagement and, in addition, it promotes optimal behaviours. Long-term, it enhances teamwork, improves morale and makes the whole organisation perform better.

Kudo cards

Bonus scheme or merit money is not the only solution that can be used to motivate employees. It makes sense to combine it with a simple system of saying “thank you” to other people in a nice, recognisable way.

Kudo cards sound like a good solution here. Kudo has a form of a handwritten card that you use to dedicate your appreciation or praise to one of your colleagues. The idea is that every employee can recognise any other person in the organisation and no approval from management is required. Kudo cards are stored in a box that is easily accessible by all the employees. On a regular basis, the box is opened in a kind of ceremony and kudos are handed over the receivers in front of all of their colleagues.

It’s a low-cost system that can have a huge influence on people’s behaviour. Of course, it can be organised online, there can be a small gift associated with a kudos earned, etc., but the idea stays the same.

Further reading

 

100% utilisation myth and slack time

In my recent blog post I covered a topic of limiting Work in Progress. I briefly mentioned that in many companies working on many tasks in parallel is somehow more important than accomplishing them.

100 utilisation myth

Many organisation believe that their employees should always be busy with work which results in aiming for their constant 100% utilisation.

At first glance it may sound reasonable – after all, we’re getting paid for having hands full of work, aren’t we?

Well, I think that employees are not paid for being 100% utilised, but for getting things done. In my opinion, getting software out of the door is far more important than working hard on dozens of tasks in parallel for a sake of being busy.

But it means that smart organisations should optimise their processes for effective deliveries, not for keeping everyone busy. It’s counterintuitive, but allowing for some slack time gives better results than aiming for 100% utilisation of the staff.

Why is that?

  • Multitasking

While working on a task you always get somehow blocked at some point of time (i.e. waiting for somebody’s feedback, facing a blocker, etc.) and therefore to stay fully utilised you need to switch to a different project. You multitask. You handle many things in parallel.

  • Context switching

Multikasking reduces quality and productivity because it involves a lot of context switching. Humans don’t actually multitask at all – we fast-switch. And switching between tasks requires context change and it takes time we need to get at full speed back again.

  • Time to market

Decreased productivity means than less things (if any!) get accomplished in the same period of time. High utilization inevitably creates queues of projects. Delivery dates slip and time to market increases.

  • No time for innovation or improvement

Planning for 100% utilisation creates a terrible environment for work, an environment of no innovation. Innovation requires creative workers to have time to observe and think. But it can’t be planned or scheduled. Innovation usually emerges as a result of slack time which doesn’t exist in organisations striving for 100% utilisation.

  • Projects get longer to complete

When a partially completed tasks sit idle, waiting for capacity to become available, the overall duration of the project grows. 100% utilisation also means that there is no time to handle urgent, unexpected issues and therefore even more planning effort is required to squeeze them in.

  • Delayed feedback

Increased time to market delays feedback, causing developers to follow unproductive paths longer. Delays make it hard for companies to adjust to evolving market needs and to detect weaknesses in their product before it’s too late.

Again, it’s counterintuitive, but you will deliver your projects cheaper and faster if you allow for a fair amount of slack time.

Slack time

There is no precise definition of a slack time, but it basically happens when any team member, for whatever reasons, is “blocked” because of WiP limits and cannot do regular work (i.e. developer cannot code or QA cannot test).

Slack time usually results in working on improvements of any kind or, in good, self-organising teams, advancing the current flow by helping resolve the bottleneck (i.e. developer picking up QA tasks).

What is the right balance?

While striving for 100% utilisation is harmful, it doesn’t mean that having as low utilisation as possible is the right approach either.

Optimal utilisation should be a balance between a cost of delay (which grows exponentially when utilisation becomes too high) and cost of idle resources (which usually declines linearly when resource get more and more utilised). There is no one-size-fits-all solution, because it very depends on the organisation, nature of the project, etc., but in many cases, however, a sensible utilisation target is around 80%.

Last but not least, it’s very important to note how utilisation is calculated. Nowadays, corporate stuff (meetings, reports, emails, etc.) can consume lot of time and therefore it automatically decreases utilisation. Please bear in mind, however, that 80% utilisation target refers to time left for project work, not overall employee’s capacity. Of course, every organisation may approach this problem in different ways, but in the end “corporate burden” can’t be excluded from the equation.

 

Limiting Work in Progress

In many organisations being busy is valued more than delivering the results. At first sight, it may sound quite reasonable – after all, we’re all paid for having hands full of work, aren’t we?

Unfortunately, it doesn’t work that way. In a vast majority of cases, the more tasks we try to complete, the less we really accomplish. And pushing yourself to work even harder doesn’t change anything.

Why is that?

The scenario described above is quite common for many teams and it’s usually caused by an excessive Work in Progress (WiP). WiP is anything that is started but not yet completed. It’s a User Story that was started, but hasn’t been Done yet – it’s either blocked, or awaiting QA, or resides in any other halfway state.

Excessive Work in Progress is harmful for several reasons that, among others, include the following:

  • It leads to mistaking activity to accomplishing valuable work.

Limiting WiP introduces slack time which is regrettably not acceptable in far too many organisations that blindly follow “100% utilisation” approach. The truth is that fair amount of slack time is desirable; it happens when any team member, for whatever reasons, is “blocked” because of WiP limits and cannot do regular work. I’ll cover slack time and 100% utilisation myth in a separate blog post.

  • It diverts our attention from what’s of the highest priority to less important tasks.

When we get blocked it’s much easier to move on to something else rather than bend over backwards to get an original task or blocker resolved. Unfortunately, in most cases it implies an implicit, ad-hoc prioritisation instead of following an original order of work (after all, an original task was of a higher priority – otherwise you wouldn’t be working on that, right?).

  • It’s exhausting mentally.

Please bear in mind that anything you have started but not finished occupies some part of your available mental capacity. And the more WIP, the more mental energy is consumed with trying to keep track of it all. Although one can argue that even with many tasks started people work only on one of them at the time, unfortunately, it’s not true – Zeigarnik Effect suggests is that our brains will be switching context despite what we consciously think it would do.

  • Context switching is a cost.

Context switching prevents us from getting into flow which is a key to being highly productive. Usually, it’s exemplified by talking about distractions and interruptions (instant messages, phone calls, etc.), but having too many tasks in progress causes the same problem – it works counter to flow. We’re most efficient when allowed to complete one thing uninterrupted. Switching between tasks requires context change and it takes time we need to get at full speed back again. Multitasking  harms our productivity.

Now, as you know that Work in Progress should be limited, the question arises how it can be achieved? The solution may differ from team to team, but the common idea is to disallow to have more stories in “in-progress-like” status (In Progress, Awaiting QA, Awaiting Code Review, Blocked, etc.) than an upfront agreed threshold. It basically means that none of the team members can take on a new item if a given number of tasks are already being processed.

This approach is usually backed with a simple guidance that whenever you finish work on an item you should check if there aren’t any unassigned tasks starting from the rightmost part of the board (that’s closest to the Done column). And you either pick one or you move one column to the left (towards To Do column) and keep repeating the whole process until you find something to work on.

Agile is not about being busy, but about delivering value to the clients. Delivering it fast to foster learning and outperform competitors. And Work in Progress limits encourage a culture of “done”. Moreover, WiP limits make impediments, blockers and bottlenecks visible and enable the team to swarm around them to get them resolved as soon as possible. WiP limits smooth the flow and increase overall team’s productivity.

So, please stop starting things and start finishing them!