Tackling the Scrum Challenge in a Large-Scale Digital Program
Real-Life Issues Addressed with Real-Time Solutions
23 October 2013
All of us have seen highs and lows of Agile teams while working in different organizations. The interesting fact is that each organization has its own version of Scrum methodology that is widely believed to be the savior of sluggish development and productive measurement. In most cases, either the collective program efficiency is missing or the model is designed to cater to one particular area of development. Studying different models will reveal to you the good, the bad, and the ugly practices, but one thing we should not forget is that we are there to bring efficiency and to change the way our teams are practicing digital development.
Each large-scale digital program has multiple projects running concurrently. Projects have numbers associated with them, whether in the form of man-hours, person-days, or even story points. At some stage these numbers are translated into a currency figure, and this defines the overall cost of your project.
Today we will discuss not just how we implement but also how we measure and address the day-to-day management questions around different project scenarios, all by using Scrum -- yes, all by using Scrum. This will be the end result and goal of this article.
Let's start with the program structure that is a flexible area and is based on different organizational factors, budgets, and priorities. Many organizations go through a process of defining the project road map before the end of a fiscal year, so they can align themselves with the rest of the organizational initiatives. This road map contains the approved business cases transformed into projects and ready for delivery throughout the year.
Here comes another challenge, in the form of nondigital projects requiring digital change or changes resulting from industry regulations and trying to push their way onto the road map. Now, if you have not built a capacity for such requests, your road map will always fall behind schedule. You can have some open project time slots and a small dedicated team, or you can treat these projects as a program itself if you have more than six per year.
Delivery and development
Projects are mere business cases with an extremely wide cone of uncertainty until they are on the organizational road map. The first step is to define and design the development scope. Let's bring Scrum into action right from the word go.
For this, you need a team comprising solution architects and product owners only. SAs will design the solution; POs will define the development scope in the form of user stories, get it agreed to by stakeholders, and create your product backlog. Repeat this for all projects and your end result will be a master backlog. You also need a next level of backlog management here to prioritize your stories.
On the basis of the product backlog, create your Scrum team(s). If your stories are impacting multiple platforms and teams, engage early and secure a tribe member.
Master backlog measurement
Your master backlog is now ready, consisting of multiple projects. It is time to measure it. Whether you assign story points or classify each story with t-shirt sizes, you need a dollar figure assigned to it. Remember, a total of all these figures should be equal to your approved project or program budget. If your development phase is different from the implementation or design phase, you need to calculate this thrice. But the principle remains the same: Your backlog size is directly proportional to your project/program budget and time is your currency.
Once you have completed this exercise, you can proceed with assigning time to people, relating it to the stories and the projects they are working on. Conduct your Scrum ceremonies. This will enable you to measure efficiency, and you will be able to answer whether adopting this model has really saved time for the organization or has instead made things more complicated. In most cases, you will get a positive result and much-needed support from the governing bodies and senior stakeholders.
We will now look into some real-time questions that we all face at some stage.
New project starts
You will get new requirements throughout the year, many because of industry regulations or business initiatives requiring digital change. In cases like this, repeat the same process of creating user stories and finally adding them to your master backlog.
Project is stopped
One of your projects is stopped. There may be many reasons; for example: Governance board rejected the change, infrastructure costs are not feasible, there has been a change in business priorities, etc. This will hit your running sprint, sprint plans, resources, and budgets. In cases like this, you can remove the relevant user stories from the master backlog and charge one month's worth of story time to the project and feed it back into the master backlog. This will address the resource allocation gap resulting from this incident and provide space to reprioritize your master backlog.
Project is delayed
You will encounter this factor in your development life cycle quite often due to internal and external factors. There will be instances when your QA environment is not ready or able to support, and there may be resource constraints, budget issues, or regulatory date shifts. In cases like this, stop your current sprint and move your stories back to the master backlog by first reestimating and then reprioritizing.
Priority regulatory work
Industry regulatory changes hit almost every organization. You may get one senior executive trying to jump off the queue and push your team to meet certain regulatory deadlines. Try to negotiate the remaining time of your current sprint and start development in the next sprint. You may have to kill your existing sprint if your regulatory changes are substantial and you have a small team. You will also see pressure from other platforms to join their checkpoints.
Current rating: 4.5 (2 ratings)