An agile coach was called to promote agile in a big bank. In one of his teams, half of the team is external consultants who have been there for 3-4 years. They currently implement Sales Force.

In the words of the Team's Certified Scrum Master, their Software Development Lifecyle is:

  1. Do a high level analysis for about 1.5 months In this phase everyone is creating user stories, since the Product Owner (PO) is too busy to write all of the user stories coming from all the workshops that are currently happening to lock down the system's specs. They claimed that this 1.5 month of discovery and design is necessary, since there is massive inter-connection amongst the pieces in Sales Force, and that they have to decide upfront what they can implement and what not (based on external dependencies).
  2. Create a Backlog with all the user stories that will be prioritized during the sprints by the PO, and run sprint planning sessions. Deliver in an "sprint" - iterative fashion for 3 months
  3. Last 3 months, back end / integration testing with the rest of the existing systems.

The consultant even mentioned that comprehensive documentation is needed in case something goes wrong, and they need to refer back to who's fault is it, so that the consultancy is in the clear.

They currently do stand ups (?) to report what they did yesterday, and what they will do today, but no planning meeting or retrospective, as they are in the "designing phase".

The agile coach raised this with a couple of other managers and they said in an eye rolling fashion "yeah, these (consultancy name here) do it their own way and have their own agenda."

The PO is clearly biased to follow the consultant's approach, since they have been working together for a while, and she has been a program manager for a while, and then converted to a PO.

Have you had experience similarly with external consultants who claim to have figured it out, but have got it all wrong, but are strongly positioned within a company?

Should the agile coach enforce a practice and claim that everything they do is agile, or should he let them fail and feel the pain before he intervenes?

  • Try not to use so many acronyms. I removed the ones I could, but I'm not sure what you meant by 'SF'. Also, why the (?) after stand-ups?
    – Sarov
    Commented Jan 9, 2018 at 18:44
  • SF = Sales Force. Corrected it. Because they are trying to enforce a style which I personally find useless. Since the work is established and finite, I find little use of the morning meeting. Nothing's wrong with it, I just think it's just an overhead as it stands. "Ok you had your meeting, now go back to do your actual work"
    – dqm
    Commented Jan 9, 2018 at 18:46

3 Answers 3


I have been in a similar situation (in a retail bank), with consultants offering what they call 'enterprise Agile'. The result was waterfall and highly problematic.

The consultancies are typically very good at lobbying support (especially with the executive). So it can be a challenge to call them out.

I would recommend to your Agile coach that they do the following:

  • First agree on what metrics you are trying to improve with Agile (e.g. time to market)
  • Suggest running some projects/teams using a genuine Agile approach and some using the approach suggested by the consultants
  • Time box the evaluation
  • At the end of the time box, see which approach has had the most positive impact on the metrics you are trying to improve
  • Very good suggestions. What metrics would you suggest / have used ?
    – dqm
    Commented Jan 10, 2018 at 12:28
  • Time to market (from first mention to production release), business satisfaction (typically via Product Owners), confidence in delivery team (again from the business users), frequency of releases, number of critical or severe bugs in production, business value delivered. There are usually some domain specific ones as well. Commented Jan 10, 2018 at 13:51
  • @dqm Beware that such experiments are generally inconclusive or misleading as there are too many variables in such a complex system (people performing cognitive work) to create valuable and valid evidence. If it were assembly line work then there would be no need for the highly paid and highly skilled technologists. Commented Jan 13, 2018 at 4:00

There is nothing agile about the consultant's approach and certainly not use of the Scrum framework. That is waterfall with some modern software development terms being misused.

Allowing an internal team to learn through controlled experimentation is a good mentality; permitting a consultant to waste money for any length of time is ludicrous.

  • Would you highlight this to managers who already hold deadlines on the project? What would be the odds that they would accept it? I agree to the controlled experimentation part.
    – dqm
    Commented Jan 9, 2018 at 18:49
  • "Would you?" I do it all the time. Each scenario has its own context and, therefore, result. Commented Jan 13, 2018 at 3:52

Try to identify the biggest pain point and articulate the Agile practices that will mitigate that

Looks like you are convinced that the existing approach will certainly fail:

...or should he let them fail and feel the pain before he intervenes?

However, you didn't say which aspect of their current practice you think is likely to cause problems, other than a general:

...no planning meeting or retrospective

You seem to have higher Management support, because they hired you and are paying for your services. However, your first attempt should be to try to articulate to the team what is the main weakness in their current process and how Scrum/Agile will overcome that.

For example, waiting till the last stage of the project to do back end / integration testing you might identify as a big risk.

Talk to the PO and also the consultants. At a minimum, you may be able to convince the PO. Even then if you run into resistance to change, then you can talk to senior Management and try to enforce the "everything should be agile" mandate.

  • The PO comes from a waterfall background and is comfortable with the status quo; if anything he support that. The team thinks they are doing agile / have done in the previous (same) implementation, i.e. "we are doing upfront spec to see the system requirements, and then we start sprinting". To sum it up, the team member and the PO think they're doing just find, and this is the only viable approach. The agile coach has tried "but what if" approaches, and was shot down every time "no, this won't happen".
    – dqm
    Commented Jan 9, 2018 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.