Blog by Vinod Verma CSM - Agile Delivery Manager - Capgemini
In my role as a ScrumMaster, I’m very fortunate to have facilitated and be facilitating the delivery of interesting and enlightening projects that build a Data Science capability into the core operating model of new digital solutions; these help to drive out efficiencies and introduce greater assurance of risk. (Capgemini public sector framework).
‘Agile’ as a framework for software development has also been growing in prevalence over recent years and is now at the point where to suggest developing in a non-Agile manner would be unthinkable and often the first point of clarification in any bid response! The flavours of Agile are many but the one most are familiar with is Scrum and it forms the basis of the Capgemini Agile Information Management Framework.
I often find that even though a client requests Agile, they tend to have minimal empirical knowledge of what Agile entails and are very much set in their legacy ways of working, finding it difficult to break free. This is often compounded by organisational barriers which prevent a truly collaborative experience (common examples are a prolonged upfront user requirement gathering phase, lack of Product Owner involvement and the inability to release into a live environment). Addressing these issues can be tricky and often a pragmatic approach needs to be taken by the ScrumMaster, addressing questions like what the Minimum Viable Product would be and the use of a proxy Product Owner all help to accelerate delivery and help the iterative approach and deliver business benefit quicker. What I find increasingly invaluable though, is an initial up-skilling of those you’re working with on the Agile approach to be used in the development environment, this will help them understand the terminology and break down their own organisational barriers especially when employed top-down. Knowledge transfers are usually best conducted through short lunch and learn sessions with references to issues the client is familiar with, as well as the use of information radiators displaying Agile in action (swimlanes, burn down charts, etc.) as well as the deployment of a digital tracking tool. When the client knows that a ‘Sprint Plan’ does not have anything to do with how fast they can run, you know you’re in a good place!
Analytics development is also fundamentally different to traditional software development; as often the insights that a particular piece of work is trying to find is the unknown and may not be even present within the data, so defining a Sprint Goal can be rather complex. To address this issue the approach I would recommend is to break the requirement into set stages, starting initially with a discovery scenario, evaluating the underlying data and assessing the potential benefits of the results before committing to go any further. Once happy further stages can then be commissioned to refine the model in an iterative fashion increasing accuracy during each cycle. It would also be prudent to ensure that any initial piece of work has a realistic chance of success! It is this ability to produce valid Discoveries which will help make the Agile delivery a success and gain client buy-in.
My colleague Stuart McDonald, will be publishing the next blog in our series on the role of MDM in Big Data.