Q&A: Scrum's Role in Agile BI
Scrum is a core part of agile BI. We explore what it is and why it's so important to BI practitioners.
- By James E. Powell
- July 9, 2013
Scrum is a core component of the agile methodology, but what makes it so popular. What is scrum and what impact does it have on a BI team? For answers, we turned to William McKnight, whose session, Agile Project Management for Information Projects, is part of the TDWI World Conference in San Diego (August 18-23, 2013).
BI This Week: Why do we have to become more agile?
William McKnight: Information managers have a lot of work to do. We need to partition our workloads into platforms that support the workload's unique characteristics. Many of those platforms are new, which requires understanding and vetting -- and possibly failure, which has to be fixed, obviously. We are sitting on a very important asset of the organization -- data -- and we need to put it to work. Agile moves the information management function through its paces on as rapid a basis as possible.
Why scrum?
I'm not necessarily picking scrum out as uniquely best. It is important to pursue an agile approach and execute it well. Execution is more important than the one you choose, but scrum incorporates the hallmarks of agile important in information management. It has a general emphasis on people over processes, an emphasis on a working project over all else, and minimization of long cycles of acute time planning, opting instead for educated speculation.
With scrum, you collect project requirements into a project backlog to be implemented in "sprints." You execute full life cycle ("potentially shippable") sprints every 2-4 weeks based on value of business requirements, then choose another batch of requirements to work on in the next sprint. I'll be teaching how to do all this in my course. I've been running my projects for years with scrum.
I've heard scrum can get pretty rough, with all the deadlines. Is there such a thing as scrum etiquette?
You are correct that the constant deadlines take some getting used to, but most people do if they're getting into scrum in the right way. Scrum is appreciated because the team actually delivers results. Yes, there is etiquette in the scrum I teach -- stuff that falls outside of the basic scrum rules that will help everybody in their adoption cycle.
There are things you don't say, such as using "you" to make insinuations (intended or not) about teammates. You also generally want to keep your focus on the future and not the past, except for in the retrospective meeting. That's your chance to review, but it's only for improving the process going forward, not finger pointing. You succeed or fail as a team in scrum. Also, the daily meetings need to be well organized with everyone following the agenda, coming on time, and being prepared.
Does scrum mean we have to deliver a full implementation every two weeks? Should we hire 30 people to make this happen?
The ideal scrum team size is 7-8 multi-capable individuals. In information management, this gives variability to the assignments. In one sprint, a team member might be deploying their core skill of data integration. In the next, because the focus has shifted, it might be data access. This may not be that member's best skill, but this is all considered at the beginning of the sprint. Sometimes the fact of completing tasks in an order is more important than shoehorning tasks into a person's top skill set. Most people enjoy the variability that agile brings, but it is a cultural change. Once you get the hang of it, if you have the workload, you can run parallel sprints, even with the same scrum master, but keep the scrum teams to 7-8.
Does scrum mean no documentation?
Not at all. Scrum facilitates whatever is necessary and acknowledges the realities of what documentation will be produced whether it's asked for or not. Make it what you need. If documentation is helpful to the short term or long term, it should be done. I certainly advocate documentation and I'll spend some time with in my session on the documentation for information management projects I recommend, including non-functional requirements, architectural decisions, the logical data model, interface technical specifications, data conversion maps, data migration plans, user interface design specifications, test plans, and business process diagrams.
What's unique about your course?
This is a teaching of agile from the perspective of someone with many projects active and completed actually using it. These projects are information management projects that I've had to customize scrum for, over time. I'll be sharing those customizations. The value of generic agile or scrum training to a TDWI audience is practically nil, as is a waterfall project management class. I'm including roles, documentation, and some organizational change management material to round out a full boat of training for anyone with leadership responsibility at their shop for information management such as data warehousing, big data, analytics, or business intelligence.