Q&A: Agile Basics and Best Practices
How can you increase customer satisfaction and deliver project results faster? Laura Everson of Mayo Clinic in Rochester shares agile best practices ahead of her keynote presentation at TDWI's World Conference in San Diego.
- By James E. Powell
- September 9, 2014
[Editor's note: Laura Everson's keynote address at the TDWI World Conference in San Diego (September 21-26, 2014) takes a close look at a dozen agile best practices that can increase productivity and customer satisfaction. In this conversation, Laura reveals the basic characteristics of agile as it relates to BI and offers a selection of agile best practices.]
BI This Week: What is agile development?
Laura Everson: Agile has become increasing popular over the last 15 years as development teams have sought new techniques to effectively meet customers' business needs. On big data projects utilizing methods that complete development phases sequentially can result in customers not reviewing BI solutions for a year or more. This time lapse causes a high risk of not meeting customer expectations because of changing or misunderstood requirements.
Per the Agile Manifesto, agile methodology considers the value of a project's individual team members and their interactions over processes and tools to develop working software in stages. Active user involvement is incorporated throughout the project to determine requirements and business priorities. The project team develops small, incremental releases to provide frequent delivery of products. This benefits customers, who view progress and own refining requirements along the way. Additionally, this collaborative approach benefits the team with manageable goals, stresses less documentation, and promotes flexibility throughout the project life cycle. This results in happier employees and greater customer satisfaction!
Can agile work for big data projects?
Yes! Agile development can work with both software development and big data projects. The standard practices of agile incorporated with a few best practices can create an effective development methodology for big data projects. However, they require a more advanced application of agile methodology and a commitment to utilizing best practices because of a combination of big data and integrated tables.
Let's start with the standard practices you mentioned. What are they?
Agile practices typically include a co-located development team, sprint cycles, planning sessions, scrum meetings, demonstrations, and retrospectives. For new users of agile, these are the first steps to integrative flexibility in development.
Co-location. A co-located development team of 6-12 people works with a customer who provides regular feedback to the development team. The customer who provides business knowledge is known as the product owner.
Sprints. Sprints are designated amounts of time (two weeks, for example) during which work is completed and demonstrated to the customer. Multiple sprints are completed during the entire project life cycle.
These are work sessions during which your team decides what development will be completed and then demonstrated at the end of the sprint.
Scrum During the designated work days of the sprint cycle, team members provide updates on development and identify any barriers.
Demonstration. At the end of the sprint, your team presents a demonstration (demo) for the customer.
Retrospective. After the demonstration, the development team meets for a retrospective (retro) to discuss what went well and what didn't go well during the sprint. For example, if a relationship in a database between two tables was to be coded and the output shown to the customer, if the coding did not return data during the demo, what caused the failure?
What are some of the best practices you mentioned?
Once a team is accustomed to co-location, scrums, and using sprint cycles with planning, demonstrations, and retrospectives, there are additional techniques that can help even more! Advanced best practices include creating a backlog, pre-planning, value-pointing user stories, delivering value iteratively, and measuring value.
Backlog. A backlog of work is created early in the project so that a pick list of development work is available. The backlog is created by decomposing the work into sprint-size objectives called developer stories -- in other words, chunks of development that can be performed within a sprint. The backlog is also the basis for estimating the length of a project.
Pre-planning. Before the standard planning session, a pre-planning meeting to prioritize the backlogs will ensure the planning sessions become an efficient hand-off of work to the developers.
Business requirements for functionality are determined with a technique called "user stories." A customer states what data they need and explains why this particular data is needed. The customer then assigns a numeric value (value points) to each of these stories. This value directs development. By ranking the value of each user story, the customer's perspective and priorities become clear. The customer feels confident that they are understood and the development team gains insight on the end value of their work. That is the ultimate happy ending to a user story!
Delivering value iteratively. This practice delivers value to the customer before the end date of the project. Delivering value to the customer in every sprint can take many forms. Using a relational data warehouse may raise standardization or data issues that may not have been obvious to the customer in the previous standalone system. You also deliver value when you build customer confidence by demonstrating work performed throughout the project; don't wait until all work is finalized. The opportunity to provide interactive feedback during development and the direct involvement in determining the order of release to production also adds a valuable sense of control for the customer. For customers, value is found in functionality and quality; after all, they will be using the product long after you have moved on to the next project!
Measuring value. There are several ways to measure value. Value metrics in the form of graphs depicting the progress of work can be developed. One agile best practice I can recommend is to use charts to build customer confidence that work that will provide value is progressing. The reaction of the customer at the demonstration concluding each sprint will also help you gauge how your work is received. Are they scheduling additional colleagues to come to the demonstrations or taking the development out to show others? Monitoring reactions to value metrics is crucial to understanding how the customer will perceive success.
Why take the time to learn and implement advanced agile best practices?
One word: satisfaction!
Management satisfaction with the overall functionality and organization of the development team increases. Output of quality deliverables to the customer is completed faster -- the development teams at the Mayo Clinic in Rochester using advanced agile best practices found a 40 to 60 percent reduction in development time. How? Agile reduces coding fixes by having the customer involved in design decisions and determining data relationships The cost of fixing coding defects goes up exponentially when found in production rather than during development or testing. Keeping the customer close to the development and engaging them in demonstrations during every sprint provides vital feedback to readjust development as needed.
Customer satisfaction increases when value is delivered incrementally so they have confidence their end product will solve their business problem. There is pride in ownership!
Team cohesion and satisfaction results when a pattern of effective work habits results in meeting the goals of each sprint. Implementing advanced agile best practices will increase quality while reducing development time. Teams feel an increased responsibility to meet the needs of the customer they've come to know. This ensures that delivery of a quality product that answers the customer's business needs. Teamwork plus increased productivity plus fewer fixes plus less paperwork plus personal contributions equals happy teams!