The Agile Toolchain for Dynamics 365
Agile software tools manage agile frameworks, which include roles, events, artifacts and rules. The most time consuming and complex tasks generally include product backlogs, release backlogs, sprint backlogs, user stories, tasks, impediments and defects – making these well suited for agile toolchain automation.
Choosing the right agile software tools, and leveraging the right capabilities within those tools, significantly improves your odds of succeeding in an agile CRM software deployment. The best agile tooling is highly influenced by your CRM software product and your agile process. This blog post will focus on agile software tools for Dynamics 365 CRM and an end to end deployment cycle that includes DevOps.
I'm going to post two related articles. This first post will share an agile toolchain, and a follow-on second post will identify a Microsoft DevOps toolchain. I'm not suggesting these are separate cycles, but this may help CRM software implementors who first adopt agile for their CRM software implementation, and then at some point down the road integrate DevOps.
Certain agile software tools are more tightly aligned with certain CRM software solutions. While best of breed agile tools such as Jira and Rally are popular with CRM deployments, I've found Microsoft DevOps is better for Dynamics 365 implementations as it offers tighter integration among non-technical (product owner, Scrum master) and technical (developer) agile team members and better facilitates DevOps integration. For an evaluation of agile tools, see Microsoft CRM Agile Tools Comparison.
The market leading agile software tools support the most popular agile methods. However, that support varies based on the agile tool template used to setup the project. DevOps project templates include Agile, CMMI and Scrum. The different templates support different naming conventions, processes and reporting.
Naming conventions generally have little impact. For example, the agile template uses the terms "user story" and "iterations" while the Scrum template uses the terms "Product Backlog Item" and "sprints." However, the role-based terms have bigger impacts. Where the agile templates uses status terms and process controls which can promote the separation of tasks on the Dev team (i.e., separate tasks for programmers and QA staff), the Scrum template does not. This is important as with Scrum, there is only one role on the Dev Team.
Toolchain Tools and Capabilities used with Dynamics 365 Deployments
Start with Business Outcomes
Two agile principals that set the stage for success include i) begin with clarity about the outcome and let it guide every step along the journey, and ii) outcomes should focus on customers and business value. Most implementations incorrectly focus on configuring, customizing or deploying CRM software. They believe that if you implement the application software, the business value and outcomes will consequentially materialize.
That's naïve thinking. Don't make the mistake of believing software features and functions are your goals; they are at best the means to the goals. Design Thinking is by far the best technique to align your technology project with the most important user, customer and business outcomes. Mural is the preferred tool to facilitate Design Thinking workshops and collaboration among virtual or decentralized teams.
Team Collaboration Tools
Microsoft DevOps Team Web Access is a portal for team members to access and manage product backlogs, release backlogs, sprint backlogs, user stories, tasks, impediments and defects. Backlogs start with user stories, and achieving good user stories accelerates many downstream processes. User stories should be written by users or their representatives (i.e., Product Owner, subject matter experts or business analysts) in the traditional form — (as a [role], I want to [goal] so that [user, customer or business benefit].)
Other agile user story best practices such as breaking down user story estimates to manageable durations, minimizing multi-situational or multi-conditional scenarios, and forecasting measurable value should be followed. But recognize agile tools often support poor practices. For example, most agile tools support nested conditions, however, these should generally be avoided and instead split into separate user stories.
User stories have to be estimated, and a great tool for the job is PlanningPoker.com. This online tool promotes gamification, collaboration and consensus building among virtual teams. By requiring all dev staff to reveal their user story estimates at the same time, the tool promotes independent thinking and prevents groupthink. Dev teams then expand upon Fibonacci user story estimates with Task estimates and record their daily work against tasks. This facilitates automated progress reporting in the forms of percentage complete and remaining work.
Aligning user intent with software delivery is a challenging task that is significantly improved with storyboarding and feedback management. Low fidelity wireframes or CRM software mockups bring visualization to user ideas and increase the likelihood that the user will receive what he wanted, irrespective of what he asked for. When combined with Design Thinking, storyboarding contributes to playbacks and prototypes.
DevOps offers a PowerPoint plug-in with shapes and symbols that are commonly used in creating software screen mockups. This allows BAs, dev staff and others to visualize user story output and get feedback before beginning software development. For my own Design Thinking prototypes I've supplemented the default shapes with a small library of Dynamics CRM software components that include process guides, dialogues, the social panel, form tabs, sitemap.xml and similar assets. Using this storyboard plug-in tool links the PowerPoint mockup to the user story, accelerates prototype development and increases the likelihood that developers will deliver what users want – the first time.
The Team Services Feedback Management tool permits Dev team members to submit requests for additional clarification. Requests are delivered by email and may include questions or a link to the dev environment so that the recipient can view work in progress and provide reaction. The recipient may choose to include text, screenshots, audio or video in their response back to requester.
Using this Team Services tool for feedback management routes the request to the right recipient, links the request to the user story and provides traceability for future reference. I've also used this tool to achieve consensus for user story values. User stories should include forecasted business value measurements in order to automatically prioritize the product backlog and demonstrate the overall business impact of each sprint increment. There's no single agile method to prescribe user story business value, but I've found using Fibonacci values instead of abstract ranges works well as it puts the development effort and payback in the same measurement scale.
Testing defects can be recorded with Team Web Access, Microsoft Test Manager or email using Mail2Bug. Mail2Bug is an open source extension that permits QA or UAT participants to create bugs from an e-mail thread by adding a specific recipient. It also appends the bug with follow-on comments to the email thread. Mail2Bug can be downloaded from github.
Virtual Project Office
DevOps Team Rooms are virtual project rooms for agile team members to collaborate, share content, review project or sprint progress, or review user story status. They are essential agile tools used to maintain clear communication and increase productivity.
They also provide many advantages – such as history, trends and traceability – when compared to the more popular method of email communication. Team Room Summary is a Visual Studio extension to create a consolidated view across multiple team rooms. This is helpful when members participate on multiple Scrum teams or managing Scrum of Scrums events. You can find this extension and many other Visual Studio Team Services extensions at the Visual Studio Marketplace.
These light weight reporting tools bring visibility to user stories. They typically display backlog items among the three columns of To Do, In Progress and Done. User stories are placed in a prioritized order in the To Do column at the start of the sprint and systemically advance columns as they are accepted and completed. I recommend Scrum Boards but also recognize they are overly simplistic. This is primarily because the status of "In Progress" is too broad. It would be more helpful to know if the In Progress backlog item was in analysis, development, unit testing, QA or any other step between To Do and Done.
Kanban maps your agile process to a Kanban board. This helps you manage the continuous flow of work with an interactive sign board. It also remedies the above weakness with Scrum boards by inserting additional columns that better represent the actual product item development process.
You will probably need to change the DevOps default states (from New, Approved, Committed and Done) to steps that better match your process. I personally like to have a column for every state which changes a user story resource assignment. To really get the maximum value you should also designate WIP limits for each column and split the columns to show Doing and Done states. You could also configure rules which define Kanban color coding and card styling.
A CRM DevOps best practice is to use WIP limits is to prevent Dev team members from accumulating too many user stories at any particular state. DevOps will display the WIP limits and actual WIP automatically. This can improve the flow of work by quickly identifying bottlenecks in any particular column.
For example, the above Develop column is at capacity and the bottleneck in the overall process. Additionally, by splitting columns into Doing and Done, we can also see when items are done in one step, but cannot proceed to the next because the next column is at its WIP limit. This brings visibility to bottlenecks which are not really stalled because of the state they are in, but rather the subsequent state that cannot accept them due to its capacity.
You may also want to add another swim lane on the Kanban to facilitate hotfixes. I normally use the label of "Expedite" for the second swim lane and use this path for high priority or out of band items that need to trump the normal process. The second swim lane can be collapsed when not in use. Kanban boards bring increased product item progress visibility, show wait times, identify the top bottleneck in the process at any particular point in time and improve velocity.
Project Portfolio Management
Microsoft DevOps Portfolio Management organizes multiple agile projects into a hierarchy for central or shared management. Product Owners or others may define top level goals such as Epics or Features, and each agile team's backlogs roll up into these portfolio backlogs.
It's important that sprint durations and dates align among the portfolio of projects. In DevOps, you will need to enable Epics and Features in the Settings page. Once you have done this, you will see three backlog levels (Epics, Features and Backlog Items) when selecting backlog items.