Agile Transformation Case

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...

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.

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.