Hi, share your knowledge with the community!

Agile Transformation Case

Anonymous A

I recently had a case interview with one of the major digital strategy firms which I bombed. The case was very basically detailed - "Our client, an international bank, wants to do an agile transformation within their IT organisation, can you put together a strategic plan?"

This consulting firm doesn't do IT projects, they're more of a higher level strategy consulting firm so any work they do with their clients is more around developing high level roadmaps and actionable plans that clients can implement themselves.

Does anyone have any thoughts on the questions and clarifications I need to ask the interviewer before beginning with this type of case? Also what would be the best way structure this type of case and how would an acceptable decision tree (or is project planning tree a better word) look in this situation?

Many thanks

  • Upvotes
  • Date ascending
  • Date descending
Florian replied on 10/02/2017

Hi,

well, while the company you recruited for is more of a digital strategy firm, I think this case is more about all the problems you run into when changing a waterfall organisation to an agile one.

My approach would have been as follows:

1) Find out about the company's current IT setup. I assume waterfall. This implies that a lot of work they do on projects is write up a 400 page tech-spec document, etc. So everything gets analysed, before any of the real work starts. Other interesting points would be:

- What does the company want to get out of agile, and how do they think of it (same with balanced scorecards a few years back, everybody does agile slightly different, so you need to understand what they want to implement)

2) Once you know what exactly the client is talking about, think about how to pull it of. There is a lot of risks and oportunities that come with agile, but it requires staff to work completely different than they did before:

Benefits:
- Staff is only pulled onto projects for when they are needed,
- Projects can move quicker as scrum teams have multiple expertises inbuild (testers and developers, business peoples, BAs, etc.)
- Ideally, ideas can be tested on prototype stages, before blowings millions of bank dollars to change systems.

Risks:
- I have seen documentation become an optional part of projects, as people are 'quickly pulled into the next' project. Will shoot you in the foot after a few years
- Not writing full technical specs leaves it open, whether the development will really solve all the problems you have
- Developers need to get used to 'not knowing all interdependencies' beforehand, so cards can grow
- Business Owners have a hard time not changing stories
- Something usually always is more complex than expected,
- Scope creep on projects is more prevalent, as there is not a technical definition document signed off which defines in's and out's
- The culture needs to materially change. Suddently people that did not work together need to work together.
- From my own experience, I have seen it fall apart because not everybody understands what needs to be done with agile, therefore don't underestimate the training and evangelism that will be required to do such an enourmous culture shift in the IT department while still working BAU on a lot of things.

Now that you know a lot of the risks, and the requirements (which you would have worked out in the conversation), you need to draw up the project plan. That should be a very typical change project, where the focus is heavily on education, training, to start with, and a smooth transition over a longer period of time, which will be checked in upon with milestones.

This is how I would do it, based on my experience in a bank that did that just - go from Waterfall to Agile...

Simon replied on 10/02/2017

For the clarifying questions, I would ask

  • What's our client's definition of agility, and how do they measure the sucess?
  • What are the majoy segaments of our client's banking business that use IT?

For the framework, I would try

  • Hornizontally, break down the value chain (money, credit, risk, HR management) of the IT department
  • Vertically, break down the operation (technical and organizational) of the IT department

The workflow I woud hope to drive the case is,

  • Identify the pain point that is limiting the agility of client's business, measure the projected improvement of a particular action, and gauge the associated risk.

(edited)

Odeh replied on 10/02/2017

Two clarifying questions to ask when presented with this are:-

  1. What is the bank's understanding of agile transformation?
  2. What are the motivations behind this need for a shift

Once you understand these 2 questions, you can put in place a better structure that addresses the bank's needs. One bucket will be the current operations, while a second bucket will be the capabilities available to the bank.

Similar questions
No similar questions available