Agile vriksasana pose in front of a Waterfall Goodfon.com
You are standing on a moss covered rock a short distance from a high waterfall that pours into a deep pond before flowing further downstream. The creek is surrounded by tall trees that provide a high canopy and shade. The air is cool and a gentle breeze blows through the trunks of the trees around you.
Your body is agile. Your weight is shifted to one leg. The entire sole of your foot remains in contact with the mossy rock. Your right knee is bent and your right foot placed on your left inner thigh. Your hips are open, with your right knee pointing towards the right. With the toes of your right foot pointing down, your left foot, the centre of your pelvis, your shoulders and your head are all vertically aligned. Your hands are held above your head pointing directly upwards and clasped together, completing the vriksasana pose.
You feel a faint mist of water from the waterfall hitting your face and arms and you start mediating about the ten commandments of the Agile Framework for Analytics Teams.
1-Understand how Agile is Different
Analytics teams often struggle choosing between the traditional sequential but inflexible Waterfall methodology and a newer iterative framework, called Agile, which has made a lot of in-roads in analytics teams as it is more adaptable to changes.
Waterfall plans well in order to avoid change, Agile assumes change will happen. Waterfall manages requirement gathering early on and is relatively inflexible to changes afterwards. Analytics business users often do not know what they actually want until they have played with a working model. If they have different or new requirements it can be too late or too expensive to make the improvements. On the flipside, Agile allows changes even at advanced stages. Agile strives to create a Minimum Viable Product as fast as possible, despite the difficulties of defining a scope so early, so that business users can play with it and provide feedback. From that moment, users can line up requirements in a progressive way and get faster solutions to their problems based on its priority.
Waterfall runs serially, Agile runs in parallel. A Waterfall project is divided into successive phases. Although certain parallelization is possible, phases are mainly serial. A later phase does not start until the previous one has ended. However, Agile staggers the project into consecutive iterative sprints. Sprints typically takes two weeks, have clear deliverables and are focused on improving the model based on business users’ feedback.
Waterfall tests at the end, Agile tests throughout. Waterfall keeps most testing activities late in the project, giving testing teams time to understand well the project. However testing this late is risky if not managed well. In Agile, testing of each sprint is done while the sprint is underway, so changes are easier to implement. However, testers are required throughout the project impacting cost drastically.
Waterfall works for users, Agile works with them. Waterfall does not really require the participation of business users, since it is an internal process. However, Agile focuses on business user satisfaction, involves them throughout the development phase and allows frequent monitoring by them. With business users regulating the requirements’ priorities, the analytics team understands better what is key to the user’s needs and can deliver insights accordingly.
Waterfall estimates cost and times better than Agile. Waterfall’s foreseeable workflow with clear start and end points and a fixed evaluation process makes it simple to estimate costs and timelines in absence of changes. In Agile, every sprint is of a fixed time duration but understanding how many sprints will be needed can be challenging since changes are allowed to happen.
Waterfall might be slower than Agile. Waterfall needs a few phases (e.g. requirements) to be accomplished before coding commences. This means business users need to wait to view a Minimum Viable Product. In contrast, Agile is often faster because coding starts even before requirements are totally clear and because involving the client in every sprint accelerates convergence of products and expectations.
Waterfall makes it easier to communicate. Waterfall‘s predictable timelines and exhaustive documentation makes it simpler to give updates, even to a CEO. Agile does indeed supports essential documentation, but its dynamic nature makes it harder to update parties who are not deeply involved.
Agile is far more difficult to run. Most organizations are used to Waterfall and methodological project leaders find no difficulty with it. Agile is considered a risk for teams without experience as it requires both users and teams to understand it well. Also, agile is far more demanding for technical teams who develop every feature within each sprint, since the intensity is exhausting.
2- Move into Agile Progressively
It is very difficult to switch from traditional Waterfall methodologies to Agile. The rule of thumb is that as much as one third of the team might choose to leave, one third might remain but might not be able to adapt, and the remaining third might succeed to change.
C-Levels leaders like Waterfalls’ detailed planning and accurate budget estimations but many data professionals instinctively turn to Agile. Consequently Analytics teams often use a hybrid which retains Waterfall’s clarity and traceability while embracing Agile’s adaptability and flexibility.
A first step towards creating a hybrid is to parallelize Waterfall tasks as much as possible. This method is called Agifall and means that you can begin developing some components of the analytics model while the planning phase is still in progress. Graphic designing and testing can also be done in parallel with the development phase.
Another quick improvement to Waterfall is to approach planning and change management in a user-centric manner involving business users as much as possible, rather than just following an IT-driven approach.
A more advanced hybrid, called Water-scrum-fall, is to start projects in Waterfall but switch rapidly to Agile. The initial Waterfall stage would involve planning, requirements gathering, budgeting, business analysis and release management. As soon as there are enough details to begin development, the team switches to Agile sprints.
3- Structure your Team into Scrums
For their data-transformation efforts, Companies require dedicated Agile teams which focus on developing and delivering Minimum Viable Data Products and processes that can be released, tested and enhanced quickly, thus accelerating the organization’s ability to gain insights and business value from their own data.
Agile teams are called scrums. Scrums are multidisciplinary project squads including data scientists, data engineers and analytics consultants as well as IT and business professionals. Scrums work best when members are staffed full time. They cannot be 50–50 players. Analytical Scrums need to operate as a network of empowered teams that learn together and collaborate with business users.
Scrum teams are not a Project Management Office (PMO). However as the analytics transformation advances, a PMO could be helpful in monitoring scrums’ activities and ensuring that data efforts proceed as planned.
The Analytics department, which we will call the Analytics Factory is the collection of all scrums and is organized as a matrix whose columns are called Tribes and whose rows are called Chapters. Tribes are groups of scrums working in the same functional area such as marketing analytics, digital analytics or operations analytics. Chapters are groups of professionals from different tribes who share a technical expertise, such as data science, data engineering, or analytics consulting.
Finally, the community of employees who share interest in analytics, independently of where they sit in the org chart is called the Guild. This is basically the fan club of the Analytics Factory.
4 –Solve Problems worth Solving
In many organisations the Analytics Factory strives to solve problems that are not really worth solving, wasting time and resources. Often management vaguely requests data scientists to find actionable insights in the data. Most data scientists do not know which actions can be taken or what insights are trivial versus remarkable. The business users who have the problem lack data science understanding to even express it and data scientists end up solving whatever they understood, eventually creating a solution that is not helpful and often too complicated.
The Analytics Factory should be focused on problems looking for solutions, not on solutions looking for problems such as “What can we do with blockchain? What can we do with cloud? Or with graph theory?”
Customer needs are crucial in discovering valuable problems worth solving. In fact, work items are often referred to as user stories in order to emphasise the importance of the customer in analytics. Problems that are worth solving should be aligned with the strategy of the business, be achievable within the existing data maturity level and have a positive measurable business outcome. All candidate projects should be assessed rigorously against these criteria with a robust examination methodology, such as Problem Derived Innovation Analytics (PDIA). Both business users and data scientists should be part of the problem examination team. The Analytics Factory should be independent enough to reject pet projects which do not pass this methodology.
5-Joint Ownership & Customer Centricity
Crossing the waterfall is only possible through collaboration (Workaway.info)
Business users unfortunately do not often involve the Analytics Factory in their decision processes. Moreover the Factory is often not customer-focused enough to get into the shoes of business users.
To make it worse, interactions between the Analytics Factory and IT are not better than with users, typically limited to data requests and solutions thrown back and forth over a wall. There is a cultural clash between analytics scrums and IT teams which typically run on Waterfall. Agile analytics teams usually feel that things are not moving fast enough under IT’s rigid procedures, while IT teams feel things perpetually being done ad-hoc and in a rush.
Quite the contrary, analytics must collaborate closely with both IT and business functions in all projects involving data migrations, data management or modelling. Joint ownership is paramount to define requirements, exanimate problems worth solving and assure quality standards. Joint-ownership also provides for longer term acceptance of analytics solutions and easier integration in the organization. In fact, according to A.T. Kearney, leading companies in analytics have a bias toward collaboration while laggards overemphasize technology tools.
Scrum teams need to include representatives from business units (such as information owners or subject matter experts, who really understand both the business challenges and how the business works) and from IT (such as developers or IT engineers) to faster get their feedback in every sprint rather than at the end. Moreover, analytics scrums will benefit from physically collocating with their IT and business peers to set and work toward realistic and relevant strategic goals, to break down cultural barriers, to cross-pollinate knowledge and to communicate more efficiently.
6- Adopt New Forms of Communication.
Frequent and broad communications ensure that everyone understands how important data is, how to implement data projects and what the impact is.
Scrums should of course share their insights and outcomes with their supervisors and project stakeholders. But most important is to make the transformation’s achievements visible outside the team. Not only business and IT leaders directly involved in the project should receive regular reports but the whole Analytics Guild should be involved, using every digital and physical channel available, including newsletters, lunch & learns, social media, collaboration tools or even datathons, not forgetting traditional face-to-face updates or videoconferences.
Moreover, dispersed scrums can use social-networking and collaboration technologies such as slack to achieve the same effects as they would from co-location.
7 – Measure Everything, Chiefly Adoption
Karl Pearson, the founder of mathematical statistics, said: “That which is measured, improves”. There are two important things to measure in the Data Factory.
Firstly, outcomes of analytical should be strictly monitored and rendered graphically using charts. Outcomes should of course involve intrinsic parameters of the models such as accuracy, precision and recall, or process-oriented indicators such as the percentage of data mapped or fed into a data lake. Most importantly they should reflect business outcomes such as campaigns take-up rates or savings.
One business KPI is especially important: Adoption. Adoption needs to be measured and extensively communicated but is often forgotten. From the moment the organization embarks on its data journey, it should be clear to everyone that math and data are not enough: the real power comes from adoption. Financial and ROI metrics are important but second to adoption.
Best agile teams wallpaper their offices with posters or large TV screens, showing key daily metrics. Teams can also use web tools but even in the digital age nothing beats the power of displays on your walls.
Secondly, project management metrics tied to Agile should be also observed. Most teams work based on two-week sprints. Schedules need to strictly monitored and team members need to have clear responsibilities linked to specific results. The best way to keep track of to-do, ongoing or finished activities is using visual tools. Best teams, for example, put tasks on post-its on a board on the wall to review and assign tasks.
Scrums usually review their outcome and process indicators in daily Stand-up Meetings, intended as a communication vehicle for the scrum and not as a status update to management. Stand-ups take place with participants standing up to remind people to keep the meeting short and to-the-point. These meetings are usually 5 and 15 minutes and take place at the same time and place every day.
8 – Run Experiments and Fast Decisions
Rather than just planning and supervising, managing analytics is a self-correcting process. This makes it difficult to plan timing or outcomes. For those unfamiliar with data science, this can seem quite messy. For example, determining in advance what parameters will work best in a deep learning model is unfortunately often impossible. It can only be done through experimentation.
As a result, senior leaders should give cross-functional scrums the flexibility and empowerment to make on their own important decisions relating to data migration, architecture and modelling. Scrums must be fully committed to a test-and-learn approach and cannot wait for weeks for approvals from top management.
9- Connect Data to Business Actions
This experimentation and empowerment climate, with time, needs to engulf people across all business functions. Decisions in many teams today are governed by HiPPOs (highest paid person’s opinions). This can be especially damaging if HiPPOs decide based on instinct or not so relevant experiences, when the choices could have been tested and supported with statistical proof.
HiPPOs often like chilling by the waterfall blocking the flow (The Daily Mail)
An algorithm should not be a final objective. Companies must embed analytics in their operating models and day-to-day workflows. For example, in order to decide which website design or marketing messaging is most effective, managers should determine success metrics and sample sizes, run a few experiments and let the data speak for itself. Digitized data points and advanced machine learning algorithms are speeding up feedback cycles. Using analytics as part of their daily activities, business people can make data-focused decisions, build consumer feedback into solutions and rapidly iterate new products, instead of relying on consensus-driven data-agnostic HiPPOs.
10- Build Momentum through Pilots
Starting a transformation with a small number of quick-win pilots is the best way to show to IT that change in data management is possible, and to demystify data to the business users while pointing out the potential value of data to both sides. Pilots can also overcome resistance and build up enthusiasm.
Analytics leaders should carefully choose pilots that can deliver quick wins and move the needle: On top of addressing problems worth solving, pilots must have a high chance of success, a substantial and rapid payback and visibility across the company; Pilots must also be simple and not require fundamental changes in data handling. They should need no more than four to six months to complete, and their value should be demonstrable within weeks because it needs to be clearly and broadly communicated.
While the first pilot is still ongoing, the analytics team needs to start more pilots. Running a successful pilot after another builds up momentum toward the development of repeatable solutions and processes.
Progressively, simple pilots give way to more complicated ones, which do require fundamental changes in data infrastructure. For example, data lake implementation is a heavy IT process that can take years. However, companies can apply an agile approach piloting a range of data lake technologies and processes, testing them and refining them before getting to the optimal solutions
Most pilots will be imperfect because they will still have to deal with badly assembled integrations and processes. But they will help to correctly prioritize problems, to define the scope of data initiatives and to identify the capabilities and scale needed for fully operational analytics. Like everything in Agile the transformation roadmap gets defined through test-and-learn.
Finally, pilots need to scale up into solid run-time solutions, while building capabilities, processes, organizational models and data infrastructure. This may last 12 to 18 months.
The biggest risk with pilots is not being able to scale them up. While pilots are typically successful, companies often end up killing the program as soon as they need to reallocate funding for new initiatives. It is important not to stop there and to treat the pilots as a strategic priority. Scaling up pilots requires up-front planning and thinking through the readiness of the organization, its resourcing constraints, its leadership bandwidth, and the pace of the transformation.
About the Author
Pedro URIA RECIO is thought-leader in artificial intelligence, data analytics and digital marketing. His career has encompassed building, leading and mentoring diverse high-performing teams, the development of marketing and analytics strategy, commercial leadership with P&L ownership, leadership of transformational programs and management consulting.
References
- “Building an analytics team for your organization”, November 2014, Emilie Harrington
- “Making data analytics work for you—instead of the other way around”, Oct 2016, Helen Mayhew, Tamim Saleh and Simon Williams, McKinsey
- “Building an Analytics-Based Organization”, 2014, AT Kearney
- “How to Integrate Data and Analytics into Every Part of Your Organization”, June 201, Carl Carande, Paul Lipinski, and Traci Gusher, HBR
- “Putting artificial intelligence to work”, September 2017, Philipp Gerbert, Martin Hecker, Sebastian Steinhäuser, and Patrick Ruwolt, BCG
- “Why Managing Data Scientists Is Different”, August 2015, Roger M. Stein, MIT Sloan
- “The Secrets to Managing Business Analytics Projects”, September 2011, Stijn Viaene and Annabel Van den Bunder, MIT Sloan
- “Understanding Agile Management”, Darrell Rigby and Jeff Sutherland, HBR, April 2016
- “Enhancing the efficiency and effectiveness of application development”, Michael Huskins, James Kaplan, Krish Krishnakanthan, McKinsey, Aug 2013
- “Agile vs Waterfall – How to Choose between them?”, cygnet-infotech, August 2012
- “Water-Agile Hybrid Approach, Is there such a thing?”, Patrick Neal R. San Lorenzo, July 2015
- “The Pros and Cons of Agile and Waterfall”, Kevin Lonergan, May 2016
- “Agile Team Organisation: Squads, Chapters, Tribes and Guilds”, Ashley-Christian Hardy, Feb 2016
- “Using Agile to accelerate your data transformation”, Dec 2016, Chiara Brocchi, Brad Brown, Jorge Machado, Mariano Neiman, McKinsey
- “How to mess up your agile transformation in seven easy (mis)steps”, Christopher Handscomb, Allan Jaenicke, Khushpreet Kaur, Belkis Vasquez-McCall, Ahmad Zaidi, McKinsey
- “A smarter way to jump into data lakes”, Mikael Hagstroem, Matthias Roggendorf, Tamim Saleh, Jason Sharma, August 2017, Mckinsey
- “Problems Worth Solving”, Paul Morrissey, Sep 2017
