Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Transition to Agile, how does it work? (Part 1)

I just started as an Agile coach for a big player in the financial market in the Netherlands. This company chose 2 years ago for a transition to Agile for all of their ICT projects and employees (app. 800) within the ICT-department. So I stepped in when a lot of transition work was already done and I was curious about how far they are.

The first impression was very positive. I am part of a team of 7 Agile coaches responsible for training, coaching and supporting projects in Agile techniques and practices. Each Agile coach is supporting 5 to 8 projects in a specific Business area and is also coaching the management team of that business area. The result of 2 years effort is visible. Everywhere you walk, you stumble upon Agile dashboards and stand-up meetings in process. Project teams gather around dashboards, in all different sizes and designs, doing a quick session to get in sync with each other and check if they can meet the goal where they gave their commitment to. Support and business representatives join the stand-up meetings and are actively involved in the result. What I also see is that the teams are learning and improving. Retrospectives are held after iterations and lessons learned are gathered and implemented in the next iteration. These improvements lead to more transparency, better collaboration and communication within the teams and between the different disciplines. This is already a big step forwards, but they are still not there where they want to be.

 The final goal is to get successful and predictable projects, a shorter time to market, better Business-IT alignment and really being Agile within the whole organization.

 A good thing is that this ambition level is stated in KPI’s of the managers. Transition to a different way of working is not possible without the commitment of management. By making it specific in KPI’s the right amount of pressure is there to get things changed. This is needed because there are enough hurdles ahead. Walking around in the projects I see that just doing the Agile practices like a dashboard and stand-up meetings, is a good first step but is not enough to become more predictable or to speed up the projects. That’s where I see work for me to do. The following topics are on my coaching to-do-list:

-      Sound estimations with the whole team responsible for doing the work. Scrum poker planning is a good practice to improve the estimations. But it is only valuable when the team learns from it. After each iteration, the estimates are evaluated and lessons learned are extracted and used for a re-estimate before the next iteration. By keeping the iterations short the estimates will improve fast during the project.

-      Burn down charts which give insight in the Estimates to Complete of the tasks. This asks for discipline in the project team to fill-in on a daily bases their ETC. Every day an updated burn down chart must be visible on the dashboard. Only than it is visible that progress is behind and actions can be done early, before the end of the iteration.

-      Shorter increments. The projects has to deal with a long period of User Acceptance Testing, Production Acceptance Testing, Regression test, Conversion dry runs etc. before Go live. This takes away all the benefits of iterative development because all risks are at the end of the project and the long duration of these tests prevents the IT-projects to deliver software frequently to the business. Shorter increments and more frequently releases to production is what we want, but how to solve those costly dinosaurs?

-      Implementing concurrent testing will help. This means testing is executed concurrent with analysis and development throughout an iteration. The User Acceptance Test is split up in user tests per iteration. Regression test can be automated and are updated each iteration. This leaves only a short UAT and regression test in the end. The same can possibly be done with conversion dry runs.

-      Shorter iterations. Some projects have difficulties with doing short iterations for several reasons and choose to have longer iterations with a heartbeat equal to releases (1 to 3 months). The challenge is to find the most effective way in the length of iterations by balancing the extra effort for rework and testing against the benefits of having fast feedback. Shorter iterations will lead to higher quality software and reduced complexity because of the smaller amount of work.

-      Whole teams; in some teams everybody is still doing his own thing without stepping outside their comfort zone and helping their team mates with other disciplines. It is more doing Agile than Being Agile. Team coaching will probably help the teams to change their habits, be more critical to what they do, use their creativity to solve issues and improve their team results.

 Curious about how this will work out? Read the coming parts of Agile Transition: How does it work?

About the author


Leave a comment

Your email address will not be published. Required fields are marked *.