When working with the Anaplan platform, you can rapidly build prototypes that typically become the foundation of the production model. Unlike other platforms, very robust prototypes can be built by the model builders in early sprints so that stakeholders can see what the end model may look like. With Anaplan and the Agile methodology, we can quickly see if you are going in the right direction. We can create a prototype, sometimes 90% complete structurally, that can be “touched”, discussed, used, tested and critiqued in the first sprint. Unlike a traditional project management methodology, Agile runs iterative cycles, or sprints. Anaplan bases The Anaplan Way on an Agile methodology called Scrum. For more information about Agile, take the Agile suite of courses in Anaplan Learning Center. This chapter highlights Agile concepts that are important to the project, including tracking, daily Scrum meetings, sprint reviews, and the all sprint retrospective. It also includes a section on rapid forensic analysis which can be used when there are performance problems with the model. 777 Tasks Deliverable Tools Model build Anaplan Model configuration aligning to user stories Anaplan imports configured Anaplan exports configured Anaplan dashboards configured Anaplan User Roles and Security configured(joint ownership with client for all of these deliverables) N/A Project tracking Weekly status reports to project sponsor Agile Implementation – The Anaplan Way App Sprint Review and Retrospectives Sprints that have been adjusted when estimates are off, new user stories have been added Agile Implementation – The Anaplan Way App Managing the buckets whiteboard Deployment readiness In-tool instructions & administration documentation Performance test scripts with SLA Demonstrations to end users on future end-state Rapid Forensic Analysis Job Aid Change management Updates as needed to change management plan. Work with client on this. N/A All sprint retrospective Plans for improvement for the next release N/A
To people only familiar with a waterfall methodology, Agile can be confusing. Iterative software development may seem foreign. Emotions will come into play during the various sprints. At the end of the first sprint, the customer may seem skeptical. At the end of the second sprint, the customer will shift to excitement about progress – and may want all sorts of new user stories added. In later sprints, data issues rear their heads and the customer may feel it is too much to fix. Remember: project teams differ, and so will their reactions. Stay calm and carry on. Manage the buckets and you’ll do just fine.
People are more likely to complete the tasks they’ve been assigned if they make a verbal commitment to their team. Every Scrum team differs; consider these ideas for how to ensure the team is committed: Use the Anaplan tattoos. Ask people to show their commitment by wearing the (temporary) tattoo. Use the manifesto. Print the manifesto and have each member of the Scrum team sign it. If you have one place where you typically meet for your daily stand up meeting, consider creating a large version on flip chart paper and posting it in that space.
Use the Agile Implementation – The Anaplan Way App (AI-TAW) for project tracking. Download this app from the Anaplan App Hub. Learn the app capabilities in class 342: Agile Implementation App located in Anaplan Learning Center. Review the primary dashboards used in the App: User Story Details. The User stories dashboard acts as a tracking engine you can use in the app. User stories can be entered and then progress tracked from start to finish by percentage. Assigned users or project managers can update progress. This data impacts the Sprint Review, Project Phase Summary, and the Project Burndown Chart. Project Calendar. This dashboard displays tracking information on different timeline items such as the planning phases, sprints, IT environment benchmarks, data integration, and user testing. The dashboard tracks start and end dates, ownership of the tasks, and current status. User story. Track of all the user stories in the project here. Additionally, update user story status right in the dashboard. Daily Scrum Notes. Keep notes from the daily Scrum meeting on this dashboard. Keep and track outstanding action items on the bottom of the screen. Items can be entered, assigned, and status can be updated all in one spot. Sprint Review. This dashboard tracks many different items in a sprint including user story completions, status, and which user stories have not been started. It can be sorted by priority, project phases and people. Outstanding Actions. This dashboard calls out items listed in the Daily Scrum Notes dashboard. The dashboard includes a list of action items, status, progress, criticality, and who is responsible.
In daily 15-minute Scrum meetings, team members commit to accomplishing their next task. Commitment aligns a self-managing team. Most people are motivated to complete a task when they have made a pledge to the team that they will do so. Problem solving, status updates, and so on do not take place at Scrum meetings. The meeting consists of each team member answering these three questions: What did I do yesterday? What will I do today? What obstacles are in my way? That’s it. Quick, to-the-point, yet critical. If there are topics that require additional attention, these topics may be discussed after each team member checks in, or a separate meeting could be set up. Meeting time cuts into model building time.
Hold informal sprint review meetings at the end of a sprint. The team demonstrates a working product increment to the project sponsor. External stakeholders, management, and project teams who are interested in seeing progress may also attend this meeting. Gather feedback used to shape the direction of the remaining sprints and the final product. Most users provide better feedback on a working prototype than a user story – seeing how something works gives them all sorts of aha! moments. Agile’s iterative process allows us to build a product that couldn’t possibly have been specified up front.
After the Sprint Review meeting, schedule and run a Sprint Retrospective. This meeting of the Scrum team and project sponsor can be held right after the Sprint Review, after stakeholders, management and project teams have left. First, adjust the sprint backlog is adjusted redistribute the sprints if estimates were off. Second, review how the team process is working. Sprint Backlog. The project sponsor determines which user stories are considered complete. The Scrum Master returns incomplete user stories to the Product Backlog (Master bucket). Next, the Scrum team, Project Sponsor and stakeholders add any new user stories to the Product Backlog and Manage the Buckets! Review how close your estimate of time to complete medium user stories was to the actual time they took to build. If the numbers are not close, update the sprint plan. Note – during the review meeting that follows sprint two, the customer begins to see all of the potential of the Anaplan platform. They want everything and they want it now. Manage their expectations and always, the buckets! Team process. After reviewing the sprint backlog and adjusting the sprint schedule, focus on the team process. How well is the team working together? In addition to checking in on team ground rules, ask some additional questions to generate discussion: What did we do well? Did we miss any opportunities to collaborate? What are our team’s strengths / weaknesses? Do we have the right people in the right roles? These discussions bring areas that need improvement to light. Then, the customer is empowered to make decisions about what to do differently to improve. Are the ground rules in need of an update? Have some behaviors improved? Recognize the good changes and work on eliminating the behaviors that get in the way.
When the model includes most of what is needed to check its performance (after the second sprint), discuss service levels with the customer and agree on the service levels for the completed model: Determine core processes /actions. Examples include: Adding a promotion to a marketing app Assigning a sales rep to a territory in a territory and quota app Assigning a compensation plan to a rep Changing a leaf location in a major hierarchy Performing a major allocation Expect an average of five to seven core processes in a model. Establish the current performance baseline time in the model for each of these five to seven processes. Discuss with the customer any difference between the current performance and the desired performance. Some processes take time. Work to understand the project team’s reasons and requirements while doing all you can to manage expectations. Determine if the performance can be improved to the level the customer desires, using the Rapid Forensic Analysis Job Aid as a guide. You may need to have another discussion with the customer to decide what service levels should be. Document the agreed upon service levels and obtain a sign-off from the project team. This can be accomplished using email. Keep the agreement with the other project documentation.
Usability relies on good performance. No user wants to wait more than a few seconds for data. Anaplan defines usability as both response time of the Anaplan platform and the visual appeal of the model. You may experience poor model performance long before actual testing begins. Work to resolve performance issues sooner rather than later. The Rapid Forensic Analysis Job Aid provides various model attributes, the analysis tools used to determine that there is a performance issue, questions to ask and remedies to try.
Hold the All Sprint Retrospective meeting at the conclusion of all sprints. Include the entire project team. Reflect on the process and adapt the process for future releases. The meeting should not deteriorate into blaming or hostility. Important issues need to be addressed, not avoided. In order to avoid those situations, lead the team through a series of steps: Set the stage. Focus on the process, not people. Do not allow blaming. Gather data. Elicit fact-based information on the process. What worked well; what did not? Generate insights. Given any problems uncovered during the data-gathering step, what can we do to solve those problems? Decide what to do. Focus on answering these three questions: What do we need to start doing? What do we need to stop doing? What should we continue doing? Close the retrospective.
For the Implementation phase, your cornerstones include the items in the chart below. This chart is not intended to be an all-inclusive list; there are probably others that your project requires. Model Data Process Deployment Model build Following the plan for data clean up Include business process experts in Sprint review sessions Communicate project updates Begin writing UAT test scripts to ensure good testing of the model Determine if additional resources are needed for data clean up Include end users in the sprint review sessions