Archive | Uncategorized RSS for this section

Helping overcome impediments between Managers and Agile Teams

Agile teams often experience difficulties when they have to deal with problems that occur outside the team and may require management involvement to resolve. I’ve seen several Agile teams lose motivation when they question whether managers are really committed to helping the team. Often the team struggle to be open with the manager about the perceived problems or how they could jointly come up with ways to improve the situation.

Here’s a hypothetical scenario based on my experience:

Mike, the Development Manager at a small company, asked Alice, an Agile coach, to come in and help introduce Agile to his organisation, starting with the key development team.

Alice ran some introductory workshops with Mike and the whole team. At the end of these sessions Mike told everyone “I’m really excited about the potential of Agile to help our organisation, starting with this team.  I want to do all that I can to support it”

When Alice came back to the organisation a few weeks later she found that the team were beginning to express doubts about how committed Mike was to adopting Agile. Mike had stopped coming to the daily stand-ups and worse, he wasn’t helping them remove the blockers they experienced with tasks that required a specialist user experience designer in another team.

The team told Alice: “Mike’s not doing anything to remove the delays caused by other teams. He says he supports Agile, but when we need him to help us out, he isn’t there for us. Yet again, the problem is with management! There’s no point us doing this Agile stuff if we’re not supported”

Alice agreed with the team Mike’s role is to help the team by overcoming organisational impediments. She decided to encourage Mike to attend the team’s daily stand-up where she hoped he’d recognise that the reasons for blocks which were causing delays on the tasks were things that he should help with. If Mike didn’t see this for himself, Alice would then model this behaviour for Mike by asking “What would it take to remove the blockers on those tasks? Would you benefit from help on those?” If this fails then Alice would be more direct to Mike by asking “What’s your view on talking to the team about the blockers and seeing how you could help?”

What’s your view of Alice’s approach to helping in this situation? Here’s my view – I welcome your thoughts if you see it differently.

  • Alice seems to assume that what the team complain about is valid – that Mike is not helping resolve the causes of the external blockages – without clarifying what the team have said or done to raise the issues they see with Mike. Alice seems to assume that the team’s complaint is valid without checking if the team have raised their issue with Mike.
  • Alice doesn’t ask the team for the reasoning behind the assumptions they seem to have made, firstly, that Mike is aware that he isn’t helping them, and secondly, he has deliberately chosen not to help them out. Alice doesn’t ask the team why they seem to think that Mike has deliberately chosen not to help them.  It would be useful to focus on directly observable data – what the team has seen Mike do or say that lead them to their views?
  • The next question is what have the team said or done to make Mike aware of the situation? Have they been explicit and described their point of view? If not, what, if anything prevented them from doing so?
  • Alice seems to jump straight to taking action to help the team out, and in doing so, taking responsibility for them, rather than discussing her approach with the team and giving them an opportunity to handle the situation more effectively.
  • Alice’s choice to ‘model’ the ‘correct’ behaviour for Mike, without explicitly saying that this is what she is doing, is an easing-in approach with the manager which may be based on assumptions that the Mike couldn’t handle being told directly. It’s likely that Mike will work out that Alice isn’t being direct with him, but rather than guessing what Alice’s view is, Mike is likely to feel puzzled or confused about what Alice is holding back.

Here are a couple of suggestions for how I think this situation could be dealt with more effectively.

Adopt a mindset of curiosity
First off, it’s worth trying to adopt a mindset of curiosity rather than certainty about the team’s view of the issue and the meaning and intent behind Mike’s behaviour. It’s common for the team in this situation to believe that they see the whole picture, that Mike is either lacking the right perspective or being deliberately difficult and the team’s task is to illustrate the obviousness of their perspective so that Mike will change. A more productive frame of mind is to believe that the team see many important things, but not the whole situation, Mike may see additional things they don’t and the task is to work together to design a productive way forward.

Focus on getting directly observable evidence rather than assumptions
It would be useful for Alice to ask the team to tell her what they’ve seen Mike say or avoid doing that leads them to believe he is aware of the blockers and has deliberately chosen not to do anything about them. Getting down to the level of directly observable data – what a video camera would capture – would allow Alice to understand more about the problem and potentially highlight how the team’s behaviour may (inadvertently) be contributing to the situation.

Strive to raise the issue with the people involved at the time it happens
An effective situation would be one where the team were able to raise their concerns directly with Mike and ask if he sees it similarly, or perhaps sees something that they are missing. For example, they might say:

“On our task board, there is a task that is blocked because we’re waiting on another team to do some work for us. Our understanding of the Agile process is that your role is to help us overcome these situations. Does that match your view? If so, can we share our view about what’s causing this blockage and how we could work together with you to remove it?”

In my experience working with teams using the suggestions above has created productive outcomes even in complex situations. I welcome your experiences or views in the comments.

Benny Devos: Systems Thinking in Financial Services

Benny works in ‘industrialised credit operations’ in BNP Paribas Fortis in Belgium (mortgage and consumer loans and insurance, across the value chain including rate revisions, partial re-imbursement, credit recovery).  The biggest challenge is management, the workforce like Systems Thinking.

Benny Devos talks about how they started with McKinsey working on ‘process improvement’. They used a stop watch to see how long it took someone to agree to a loan (it’s incredible to hear that this still happens). They averaged the time across easy and complex decisions – without any knowledge or understanding other than a stop watch! After 6 months the motivation was low, the workers’ council were complaining.  They went for McKinsey Plus and added an ‘emotional aspect’ by involving people on the floor. Instead of a stop watch they asked “how long do you think this task will take?” – they averaged the guesses and started all over again (single loop!).

Benny says once you get caught by Systems Thinking it never leaves you.  He worked with Barry Wrighton.

Purpose – what matters to the customers

They invited 350 people to call customers who had loans, or refused loans, to hear what they expected of us.  The easiest way to find out what matters to the customer is to ask them.  Logic such as “I know customers because I am one myself” is myopic.  The results was they were not working in ways that customers valued.  The branches were effectively ‘crying for help’.  Instead, after the McKinsey approach, if you had a file and couldn’t make a decision (missing data) you had to send the file back, you could not phone them (because you would miss the target). When it came back to the branch, they couldn’t do anything more with the file – if they could have they would already have done it.  The branch weren’t allowed to call the person who did the work, they had to call a call centre, who could only answer 50%. They had to escalate back to the group who identified the problem, who got back to the branch, who fixed the file, to send it back to the processing group.  85% of files were being sent back!   This was very confronting – easier for Benny because he was new, but for the existing managers it was like looking at yourself in the mirror and not liking what you see.

Demand – type and frequency

They worked with 1300 file s a day with up to 95% failure demand (the files were repeat files, after being fixed through help desk and second line support).  The only measures they had were SLA’s of 3 days.  But the SLAs were for a complete file which lead to ‘cheating’.

They used a new kind of project language using ‘bringing in, live with, get rid of … (process problem)’


There was an assumption that customers wanted a mortgage loan response instantly.  Knowing that there was a 3 day SLA didn’t help the fact that sometimes it was taking 25 days.  The customer wants confidence they can get an answer within a promised time, with one visit to the branch.  85% of times the customer did have to come back to the branch.  The measures we had were budgets, productivities and SLAs (internally foused at the department level). The new measures where varation, predictability of it, end to end custoemr times, iterations (numbers and kind of …), help desk calls (number and kind of …) and capability charts.

Capability charts focussed on the extremes; ‘why is that taking so long? as well as ‘why was that so fast?’


They used Process Mapping

System Conditions

There were two groups for loans; consumer and mortgage were separate.  There was an assumption that people dealing with mortgages weren’t able to deal with consumer loans. There were duplicate departments, managers, IT workflow tools (there was even a competition between departments).  They found that the demand was cut into pieces to fit into the silo-ed parts of the organisation.  HR rules meant that it was difficult to ask people to do different jobs.

Management Thinking Assumptions

Standard Vanguard issues were identified.

After Check, Comes Redesign (Plan)

The question was ‘given what the customer expects of us, how should we organise ourselves?.  The custom gives us a demand, we need to analyse, data entry and treat it.  In the old system a demand was split into 5 or 6 different requests.  It wasn’t possible for people to handle every type of demand (they have 160 different types of actions that are needed).  The goal was to have a maximum of one hand-off.  Other goals were end-to-end, first time right, one stop and minimise hand-overs, only do the ‘added’ value work and a client oriented approach.  They decided to be client oriented, rather than product-oriented by combing mortgage and consumer loans handled by the same people. The staff decided on the measures and the decision-making was integrated with the work.

Roll-in of progressive change

They started off with small teams (4 people in the beginning) so not a big bang approach.  They trialled the principles of the re-design. They had the right to experiment and make errors, and little by little it stabilised until the team said they could do more work and we increased the team to seven people.

They found that for some operations it took 32 days end to end involving 52 people.  After redesign, it was simplified into “decisions + contracting” –> “branch” –> “customer”. There were assumptions that it would take 2 years to train people in contracting, but experience showed 95% of demand could be trained in just two weeks!  The new redesign involved telling the decision makers to call the branch (previously prohibited).  The result was 10 days for end to end with 42 people.  The workload increased by 30% over that same period as well.

An example of mixed demand, where one customer had a mortgage and a consumer loan.  They used to have to split it, but after the redesign where the team could deal with both requests as a single piece of work, the end to end times dropped from 15 days to 5 days. 

Main Results

The ‘bring-in’ phase resulted in e2e times for 28 days to 12 days, handling this with 20% fewer people involve.  The workload was up 20% (+29% in amount of loans, +8% market share). In ‘live with’ e2e when from 10 days to 5 days, but they were able to offer more flexible mortgages with new features. ‘Get rid of’ if the customer needs help, they now start straight away, rather than waiting until they started the financial recovery process.

The Global People Survey across the bank showed that the groups involved had the highest motivation, but they were more critical of how well they were satisfying customers than other areas of the bank (possibly because they are more connected to the customers). Absenteeism reduced from 8.5% to 3.5% in 1.5 years. There were also no appeals in the appraisal exercise (previously there were 20 appeals out of 280, but last year there were no appeals).  People are more motivated by the work than by the money associated with the financial bonuses.  Last year they didn’t use their discretionary bonus funds for ‘paying off’ (my words) dissatisfied staff.

What is management’s role?

The hardest part is working with managers and helping them see their new role.  Their role becomes understanding demand, thinking outside in, engage staff, walk the process, allow staff to experiment with design and evaluate etc.  Previously managers used to be specialists at solving tricky decisions, but now they have to become a specialist in training (moving from ‘disablers’ to ‘enablers).  They now need to create conditions that enable workers to reach their goals.  They need to support and encourage the initiative of the workers.  They need to ensure that the process / initiative is end to end.  Also, building agreement with others outside the process.

Lessons Learned

In Benny’s experience, the managers who went through the intervention decided that they no longer wanted to do the new management role. They decided to step back and do other functions. They had 32 managers at the beginning and ended up with 19. You need leaders, not managers.  It’s not about big bang, but progressive change.  Everyone agrees with the logic of Systems Thinking but stopping “Command and Control” is not easy and requires vigilance, especially if the rest of your organisation is still using a traditional approach (it’s a lot easier to stand still and follow the heard).  Also, managers are often hired for analytical ability, but Systems Thinking needs more Emotional Intelligence than IQ/analytical ability.  The manager needs to have an enabling role, not a disabling role.

The roll-in started very small, with a small team, it made a lot of waves in the beginning, but the larger the team grew, the fewer waves that were produced.