Scrum: Pain Points & Resolutions – Integration into the wider business

So you’re using scrum or another agile method in the development team, possibly in more than one team, but at this point it is still seen very much as a development practice and nothing to do with the rest of the organisation.

If your scrum adoption is successful then you will frequently find that its influence will spread out into the organisation especially around the sprint cycle with the business aligning itself with the heartbeat of an iteration. This doesn’t mean that all parts of an organisation will adopt scrum practices but they will at a  minimum understand how the process works and what, if anything, is expected of them.

To get a wider adoption in an organisation there are often several hurdles to overcome some of the most common ones are: Resistance to change, Scheduling work between teams, Clients and Job security.

Resistance to change

This is perhaps the most difficult hurdle to overcome, to do so needs the senior management within a company to recognise the value in scrum and sponsor its adoption within the organisation.

If you do not get this support from senior management you will run into problems, people will resist any changes that may be suggested by a scrum team to improve the business or changes in their own processes to help with the scrum team(s) e.g. people accepting the product owner role, business prioritisation of work to be done, etc.

If you don’t already have ‘buy in’ from senior management then the easiest way to resolve this is to get one or more members of senior management involved in the scrum process so that they can see how it works and the value that they gain through it.  If they can see the process at work and understand the value they gain through it vs. how waterfall projects run they can promote it to other members of management. 

If you follow this approach then you must be confident that you will succeed in completing all the work committed to and deliver something of business value, you need to set yourself up to succeed. If you fail then the management is likely to write the whole thing off, and whilst you may be able to continue with various agile practices and processes you will have to wait a while before attempting to convince management to adopt a different process.

You also need to ensure you get the right person in management, you need somebody who is interested in trying something new, open to change and willing to talk to other members of management and fight your cause.

Scheduling work between teams

If you have a project/product that spans teams, or teams still working waterfall, or simply need to co-ordinate with teams/departments elsewhere in the business you can run into problems scheduling when work will take place or just delivery of completed work.

To get around this the scrum master needs to engage with the other teams scrum masters/managers/product owners to co-ordinate when work will be done, delivered, ready for use etc.

The goal is to ensure that the separate parts of the organisation are able to deliver what is expected when it is expected, a side effect of this is that other non-scrum teams tend to start adopting some scrum practices to try and ensure they are meeting their commitments.

If the other teams are also doing scrum then it is usually just a case of ensuring the product owners, if they are different people, to understand cross team dependencies so that stories are prioritised correctly and which sprint they should be delivered in.

If teams do not wish to engage in the process you may need to follow the ideas in my last post in relation to scheduling work where a business arbitrator decides what work is done and when to ensure that the business works in a co-ordinated way.

Clients

Frequently business people are worried about the perception of the company by clients when they adopt scrum and the fact that the team is working in sprints so that delivery dates generally need to fit in with the sprint schedule and that this can be seen as inflexible because the team won’t accept changes to stories they are working on during a sprint.

In my experience the exact opposite is true, when you explain to clients that you are following the scrum process that they will be intimately involved, that the team will be delivering working software at the end of every sprint and that they are able to change the exact details of what they want up to the point where the story is included into the sprint then clients generally are very happy.

Scrum is no longer an unknown process, a lot of people in the business world understand what it is and if they don’t then take it as an opportunity to sell it to them, get them excited about the process and their involvement in it.

If the client is a little unsure their doubts usually fade when the team starts delivering working software, it inspires confidence that the software will do what they expect; react to changes that the client wants so that at the end of the next sprint they can see their changes have been implemented and their confidence will increase.

Job Security

When people first learn about scrum, the ‘self managing team’, continuous improvement, etc people often worry about their role in the organisation, they fear their role will disappear and as such they will lose their job.

Its only natural that this will happen and the way to help people overcome this is educate them about the process so that they can see that although their roles may change they won’t lose their jobs.

People may not be happy with a change in their role and this is again where senior management support is required to help the individuals through any transition period to find a suitable role/position within the organisation as it transitions to a new way of working.

Scrum: Pain Points & Resolutions – Planning & Scheduling

Very frequently when you are running with scrum or another agile process you’ll get objections like ‘you can’t plan with agile methods’, ‘how can we schedule what work to do?’ and ‘how can we commit to any deadlines?’

The myth with scrum and agile methods is that it is not possible to work out when functionality will be delivered, people usually fall back to waterfall and Gantt charts and say ‘look, if we do it this way we know when the work will be completed and can tell the client’

Unfortunately most people that have spent any time working on software projects know that this is pure fiction.  Having a chart that tells you when a piece of work will be delivered is a complete suspension of belief, just because the chart says it will be so doesn’t mean it will be.

So how can you schedule using scrum? by using the tools that we already have – backlogs, velocity & story pointing.

Planning

You start by ensuring you have a backlog with stories that have the correct level of detail to enable the team to perform story pointing, this will then tell you the size of the work to be done; you can then use the teams velocity to be able to work out the amount of sprints you are likely to need to be able to complete the work.

What becomes particularly important is having a range for the teams velocity e.g. maximum velocity achieved, minimum velocity achieved and average or mean velocity which equates to a what the team will be able to achieve, should be able to achieve and may be able to achieve.

When these values are overlaid on the backlog it may prompt the product owner to reprioritise the work between the may be and should be done lines to try and ensure that a particular story makes it into a sprint and is completed.

 

Estimate vs. Commitment

One question often asked is why use story points, why not provide estimates in hours or days?

One very good reason is that story points are a unit of relative bigness, in and of themselves they have no meaning. If you say to a product owner a story is estimated to take 5 days to complete then frequently the product owner hears ‘that will take 5 days to complete’ when what the developer really meant was ‘if I am undisturbed and able to work on this and this alone and it all goes to plan I believe it will take 5 days’.

This is the trap of estimate vs. commitment where development say one thing and the business hears something entirely different, this is often the cause of friction when work is not completed when the business expects.

This is where story points help because they aren’t tied to any particular time frame, number of days or hours, so the likelihood of an estimate being taken as a commitment is reduced.

Scheduling

Scheduling the work to be done may not be a pain point, it all depends on the environment and amount of ‘resources’ you have.

If you are on a normal sized scrum team (7 people + or – 2 people)  that works for a single product owner on a single project/product then once the product owner has decided what work should be in a sprint you are good to go, no issues about resource or scheduling.

However, if you are a team that has multiple product owners and works on multiple projects/products it can become a real issue trying to schedule what work will be done when especially if you have smaller teams.

Whatever happens the team should not attempt to decide which product owners work they will do, it is not up to the team to decide which work has the most business value it is up to the business.

In a perfect world you could hold a meeting that all the product owners attended and they would form a self managing team and decide which work was of most value and attempt to work out a schedule between them of when to do each product/projects work.

Unfortunately we don’t live in a perfect world and most often than not each product owner will believe that theirs is the most important work and should be done first.  The easiest way to resolve this is to have an arbitrator for the business, somebody who can and will decide which work is of the most value to the business at that time and as such should have priority.

For this to work the arbitrator has to be a senior figure in the organisation, somebody that the various product owners will listen to and abide by their decision.  The arbitrator chairs the product owners meeting and will hear each product owners case as to why their work is the most important and the actual or perceived value that will be gained through doing the work, the product owners will also state how many sprints that they need to complete their work based on planning done with the team.

Once everybody has stated their case the arbitrator will be able to decide what order the work should be done in, there by scheduling the work for the team for the next sprint as a minimum but quite possibly for the next
3-6 sprints.

To ensure that the business can react quickly to changes in its environment (market opportunities, competitors products, regulatory/legislation changes, etc) this prioritisation meeting should take place every 2-6 weeks allowing for the schedule of work to change but ensuring that the team isn’t disturbed in the work they are doing.

Deadlines

So we have covered how to and avoid confusion over estimates and how to schedule work (if necessary), now the business wants to be able to commit to delivery but they are still feeling nervous about whether the team will be able to deliver on time.

So how do you allay these fears? You complete the work you commit to.

The team needs to ensure that the work that is taken into the sprint is completed which means you have to be honest with yourselves about decomposing your stories into tasks, about how the work is progressing and communicate with the team (including the product owner and customer) so that if anything crops up to affect the schedule it must be raised immediately.  By doing this the product owner and/or customer can make decisions as soon as possible on any stories that may need to be dropped from the sprint, changed or re-prioritised.

By doing this the business/customer is able to ensure that the stories with the most business value are completed.

Next pain point

The next pain point I’ll cover is in relation to integrating scrum into the wider business and problems that may be encountered.

Scrum: Pain Points & Resolutions - Support

If you are starting out with scrum as a team, or even new to scrum as a manager, the biggest hurdle to overcome can be handling support requests whilst attempting to complete the work the team has committed to.

The first question that is often asked by the team is - how can we commit to work in the sprint?

The easiest way to do this is when planning the sprint you work out the number of hours that the team has available for work and then take a pot of hours off the top to accommodate support during the sprint.

Doing this allows the team to then be able to task out the stories and commit to the work that they feel they are able to accomplish in remaining hours in the sprint.

The second question is usually - how will support affect the sprint?

With the hours taken off the top the sprint can continue as normal but the time taken for any support work needs to be recorded to show the time that is being spent and one of the best ways to do this is using a burn up chart.

A burn up charts provides a visible way to record the amount of time being spent on a particular task, story, etc.

The chart has a horizontal line showing the maximum number of hours that has been allotted, the blue line in the image, and each day the amount of hours that is spent is recorded as shown by red line in the image.

 

The third question is – will support cause us to fail the sprint?

The time available in a sprint is a fixed resource, this is a key concept that the business needs to understand. Excessive time spent on support can, and will, cause a team to fail a sprint .

If  the burn up shows the amount of time breaching the allotted time, as shown in the image, then simple mathematics tells us the team will have insufficient time to be able to complete the work they have committed to. 

At this point the team needs to talk to the business to decide what work from the sprint will be dropped OR that they the team should stop doing support.

It is most unlikely that any business will agree to stop doing support so stories will have to be dropped from the sprint to allow the team a chance to complete the remaining work, it is up to the business to decide which of the remaining stories provides the most business value.

The fourth, and final question, which is usually asked by the business is – if the team sets time aside for support what happens if they don’t use it?

If the team has found the amount of support less than anticipated they should be looking to pull additional work into the sprint from the backlog. 

As with everything to do with support there is a balancing act between the amount of hours you need to keep for support and work you could pull in. As an example if you are half way through a sprint and haven’t used any of the time put aside for support the team should feel confident that they can halve the amount of time in the support pot, but this doesn’t mean you should pull in the same amount of work as hours dropped since most likely there is insufficient time left in the sprint.  The best course of action is for the Scrum Master to do what they would do in sprint planning and calculate the amount of available hours, less the work already in the sprint, and the team work out what can be pulled in.

Next Pain Point

Next I'll cover planning & scheduling work with scrum

Scrum: Pain Points & Resolution – Management

After the issue of time you frequently encounter objections relating to the management of scrum teams.
One of the tenets of scrum is the self managing team but this frequently concerns management as they want to know:

• Who controls the what work is done?
• Who takes responsibility for delivery of the work?
• If things are not working out who steps in to sort it out?

These sort of things are normally done by a team manager (not to be confused with a team leader - whole different role) or in a bigger organisation may be shared between a manager and a project manager.

The simple answer to all of the above is - the team. 

The team being self managing means that they decide what work is done but don't forget that a scrum team includes the product owner that represents the business and as such they decide what provides the most business value.  Since the team decides what work they do they have to be the ones responsible for delivery of it and need to understand that it is up to them this understanding ideally comes from the Scrum Master but can come from a manager as I'll explain shortly.

If a sprint is not going well and not working then again the team need to resolve the matter, they must resolve the situation to allow the work to be delivered and again a good Scrum Master should guide the team through this, it is only if the team is unable to resolve the situation that the manager need to be involved.

So after all that you frequently get asked - so what is a managers role in scrum?

Within scrum a manager needs to move away from a command and control (C2) type management and instead work to turn themselves into a facilitator, another servant leader type role, who is there to help:

• To help the team improve their processes
• Solve high level impediments that the Scrum Master is unable to resolve
• Technical & Product evangelist to other managers & members of staff in the organisation
• Handle resourcing issues
• Synchronise backlogs across teams
• buy snacks for the team
• even clean the office if it will help

In reality the list goes on and on, the bottom line is that a manager needs to do whatever is necessary to support the team to deliver business value.

Authority

So you have a self managing team but what if:

• the team simply aren't self managing?
• the team are just going through the process but aren't really committed to it?
• the team simply are not delivering work?

If the scrum master/manager recognises that things aren't working then they will try resolve the situation with the rest of the team by attempting to coach them to get them back on track.  If this isn't successful it will fall to the manager resolve the situation.

At this point the likelihood is that manager is likely to revert to behaviours exhibited by C2 managers and tell the team what they have to do to get the scrum process working, it should be the last thing the manager wants to do but may be the only course of action available.  What is crucial is that the manager is looking to fix the process rather than simply reverting back to 'the old ways'.

The article 'Agile - A Way of Life and Pragmatic Use of Authority' on InfoQ gives a very good overview of this situation and what can/could be done.

Final thoughts on managers


Paraphrasing from a presentation by Henrik Kniberg on the managers role in scrum:

The manager can be the best catalyst or the worst impediment

What this says to me is that managers are vitally important in the process and need to engaged with it otherwise you may find your attempt to adopt scrum could be in trouble

Next Pain Point

Next I'll cover support and how that can be handled within scrum.

Scrum: Pain Points & Resolutions - Time

When you want to try scrum the biggest pain point is often the amount of time, real and perceived, that will be needed to implement the process.  This post attempts to outline the most frequently raised objections and potential resolutions.

Time required for all the meetings

The first objection is frequently related to time require to hold the various meetings which in turn reduces the time available by the developers for actually developing/supporting the software.

This can be a fairly easy objection to overcome as the majority of these activities were always going on in the organisation and scrum just makes this time visible to managers.  It is true that additional time will be taken up by daily stand-ups but as they are time boxed and should be no more than 15 minutes it is a small price to pay for ensuring everybody is up to date with the state of the work.

Time to perform related tasks

The next objection that is usually raised is related to the extra work people will have to do on top of their normal duties, it usually becomes more of an issue when you explain that you really want a dedicated person to take on the role of ScrumMaster let alone the need for a person to handle the Product Owner duties.

This is a far harder objection to overcome with only a limited number of resolutions to the problem.

The easiest way to resolve this is by having the support of senior management who understand the need and can reorganise roles/work as necessary to allow people to undertake their new role/responsibilities.

If you don’t have the explicit support of management to reorganise the work but you do have their implicit support to allow you to try and implement scrum as long as “the work gets done” another possibility is looking to share some of the work done by the people that are to take on new roles/responsibilities to give them space to do the work that is required.

The hardest situation is where you are trying to implement scrum without management knowing, and more than one team have done this.  To be successful the people involved have to make time to be able to perform the work which they will need to do and you’ll need dedicated people that understand what you are trying to achieve.

New technical practices slowing development

In relation to time this is the last objection where management believe that practices like Test Driven Development, Continuous Integration, Collective Code Ownership let alone Pair Programming, will simply add time to development.

This is the easiest objection to overcome as there have been many studies done in and around these practices showing the advantages and benefits of each and you can lay out what the organisation should expect you to be able to deliver if you are allowed to implement them.

Start by picking the practices you feel most confident with so that you can show tangible benefits of what you are doing which will make the managers feel happier with what you are doing and more likely to allow you to attempt the practices you are less familiar with.

So what's next?

Hopefully when you’ve overcome these objections you will be able to start doing scrum but be prepared as this will then cause more problems and objections to be surfaced but I’ll try and cover those in the next few posts.

Agile – Making progress

I have been meaning to post this for a while but DDD SW got in the way so this is a catch up on the situation from my post Agile - Bringing it back on track, as promised I will be posting my ‘Pain Points & Resolutions’

So we had successfully completed the sprint and started our meetings, the team was a little more confident in what they were doing this time.

The demo to the various product owners went well the only niggle being that a member of the team was questioning if we should release a piece of work we had done as during the sprint the product owner had identified another story that they wanted done.  A small discussion ensued with the outcome being that the understanding that we will always deploy work done in a sprint, we don’t hold any work over until further work is done.

After the demo the retrospective went well with the team selecting items they wanted to focus on in the next sprint, the only point of contention being the manager who looked after the team started demanding items to be looked at and trying to change what had been selected by the team to focus on.  The team didn’t accept this and although uncomfortable for the manager the discussion that followed showed the team starting to self-manage and decide their own fate with the result being a small compromise with the team picking the items to focus on but acknowledging the managers concerns.

The sprint planning went fairly smoothly, the hours were calculated, the stories were ready with enough detail (thanks to the Scrum Masters backlog grooming) and the tasking went well.  Only issue we ran into was the team attempting to do more than was on story but fortunately when this was pointed out the team stopped.

So it looks like we’re making progress, I’ll post on what's been happening to the team after my series of posts on ‘Pain Points & Resolutions’.

Presentation slides – So you want to try scrum

 

Sorry for the delay (not used to making presentations available online), but you can now get to my slides here.

As promised I will be posting ‘Pain Points & Resolutions’ shortly.

DDD SW

So yesterday was DDD SW and I along with about 29 other presenters tried to inform and entertain the people that attended our sessions.
The day went well and I think that everybody who attended would agree that it was a really good day.  I also went to the geek dinner afterwards which was great and I would suggest that if you attend a community event and get the opportunity to go to a geek dinner do go.
As I promised all of the people who attended my session I will be creating a series of articles following on from the presentation all about pain points experienced when attempting to use/adopt scrum and potential resolutions.
All I need to do now is work out what I could present next …

DDD SW presentation

I am doing a presentation at Developer! Developer! Developer! South West (DDDSW) tomorrow entitled ‘So you want to try Scrum?’ which is intended to cover the basics of Scrum and some common pain points that are frequently encountered by people trying to adopt scrum/agile processes.

I will be following up the presentation by posting the various paint points and some solutions on the blog as additional material as well as making my slides from the day available.

Hope to see you tomorrow, if not come back here to pick some tips on resolving pain points in scrum.