There is a lot of market buzz around agile service delivery. But when you push anyone who talks agile to give you specifics of how to do it, you discover that there is little actual agile service delivery getting done consistently. If the process works partially or at all it is built around the knowledge of a few agile promoters and a supporting set of spreadsheets or a mishmash of tools. This type of work process management is not really a system. Therefore, agile service delivery does not become an integral part of the company’s work delivery systems. In fact any progress made towards agile work delivery is often lost as soon as the subject matter experts that championed it leave the company or move on to doing other things. Another major challenge is that people, in general, have trouble thinking agile, and the tools they use for their everyday work quickly lead them back to the same old habits and ways of doing things.
So how can you institutionalize agile delivery in your teams? How can you make it a real system that works long after the original champions of the idea have moved on to other pursuits? Workflows are a key technology enabler for automating project workforce management processes. This article explores how workflows can be used to systematize agile project and professional service delivery.
The Workflow Drives the End User/Manager Entry Page
First let’s clarify the definition of a workflow-driven system. A workflow system provides a visual representation of your work processes. The graphical workflow engine allows you to draw your work process, similar to how you would design a diagram in Visio. The difference is that as you draw the process, the workflow engine actually enforces and manages the process, applies all of the business rules for you, and fires all related alerts and notifications based on specific actions or inactivity of workflow entries. You specify the fields and tabs to be included in the workflow entry pages that end users and managers see. You can define your work policy validated at point of entry, change approval routes and roles, and add/remove fields and notifications without the need for custom programming and without involving any IT resources.
Managing Professional Service Requests
The workflow shown below is an example of how a project workflow tool can be used to automate and track agile service delivery. In this example, a workflow is designed to prioritize and deliver service requests on a calendar month basis using agile methodology. Work is planned before the sprint (in this case a month) begins; and once a month begins the priorities are pretty much set and work has been assigned. No new work is assigned and nothing gets reprioritized in the sprint until the next month.
Team members work on the sprint’s prioritized service requests and try to get as deep into the sprint backlog as they can. Each service request is a workflow entry that is governed and audited by the workflow engine, the business rules and notifications you have put in place. The workflow entries (service requests) make their way through the agile workflow from Open to the various states until they are either Completed or Dropped. Note that because the agile process is controlled and managed using a workflow tool you can add (or remove) whatever states (steps), business rules and notifications you need to run your agile process effectively. All of the capabilities and power of a workflow tool are now an integral part of your agile delivery process. You can setup a notification for example that sends an email to the service delivery manager when a service request in a sprint is completed. Notifications can also be setup to notify the service delivery manager of any SLA compliance issues. For example, you can ensure that all service requests in the Submitted state are reviewed in a timely manner and either dropped or added to the backlog by setting up an escalation rule due to inactivity for all workflow entries in a given state.
Agile Service Delivery - Monthly Sprints
Here is how an agile workflow automates service delivery in this scenario:
1) New service requests: new service requests are created by clients or internal team members.
2) The sprint backlog: a service delivery backlog owner reviews the new service request entry. If the request has all the required information it is approved and the service request is pushed into the Master Backlog state. Service request may be rejected and pushed back into Open state if they do not contain the required information so that whoever made the request can make the necessary changes.
3) Prioritizing service requests: a few weeks before each month, the service delivery manager arranges for a meeting to review the service requests in the master backlog. In this example, it is assumed that service is delivered in monthly time boxes. Let’s say we are now in July and work is being scheduled for August, the delivery manager will push the highest priority backlog service requests that can be done in a month into the August sprint state; any larger multi month deliverables have to be broken down into monthly deliverable chunks and prioritized accordingly.
4) Execution: when the month begins, the delivery resources have a month’s worth of prioritized backlog service items to deliver. In the Agile world, this is called the sprint backlog. In pure agile model service resources would pick items from the sprint backlog and work on them; but you can also change this pure model slightly and assign each service request in the sprint to the most appropriate resources.
5) What gets completed and what gets dropped: as the calendar month end approaches you can see which service requests were completed in (August for example) and which ones are not going to make it. Whatever is completed gets tagged with an id (such as 08-2011 to indicate it was delivered in the August sprint) for identification purposes and is pushed into the Completed state. If a service request was not performed and is no longer relevant, it is pushed to the Dropped state. Unfinished service requests that still need to be done get pushed back into the Master Backlog.
6) Reprioritization: It is now time to plan the next sprint (for example September). The service delivery manager reprioritizes the backlog based on new and existing service requests and pushes the highest priority service items into the next sprint (September state).
This process repeats every month.
Note that in the above diagram the Dropped and Completed states are known as “sink” states. Any workflow entry can transition to a sink state at any time. It is just a shorthand and faster way of defining a state that all other states can transition to.
Burn-down Chart / Report
Work Remaining (in hours) vs. Status Reporting Period
Workflow-driven agile project and service delivery works magnificently for backlog management, sprint planning, routine work prioritization, and execution. One of the key reports an agile service delivery manager looks for is a burn-down report. In this report, the service delivery manager determines how fast the work is getting done and if the team is on track to meet the deadline; and if behind schedule, which items are likely to not be delivered in the current sprint. With a workflow-driven service delivery solution you can add the user defined fields you need to report on estimates, actuals and remaining work. The workflow tool can also be integrated with a timesheet solution that would make project time reporting and burn down analysis even more systematic and accurate. Using a timesheet system that supports burn-down reporting and asking end users to report project time on a weekly basis would allow you to measure work velocity based on the project time reporting cycle.
Delivering a Project Using an Agile Workflow
In the first example we looked at using a workflow to automate and track the agile delivery of service requests in monthly sprints. Now let’s look at how workflows can be used to deliver a multi-phase project. The following is an example of an agile workflow to be delivered in 2 phases (or releases) with each phase having three sprints.
Agile Project - Delivered in Phases
The project starts the same way all agile processes do. All deliverables are created as workflow entries and added to the master backlog. The backlog is prioritized by project managers and stakeholders who decide on what should be done in Phase 1; in keeping with agile principles Phase 2 and 3 are not fully planned. The Phase 1 list is also broken into three sprints and the project’s manager and sponsors decide on the backlog for every sprint. Each time a sprint ends, the deliverables which have not been completed get pushed back into the Phase backlog. The phase backlog is reprioritized and used to create the next sprint’s backlog. Once a phase is completed, those deliverables that did not make it are either dropped or moved to the Master Backlog for reprioritization. The same process is used to execute Phase 2 and 3.
How Agile Workflows Tie Into Traditional Project Management
Using a workflow-driven project and service delivery tool to implement and track an agile process has numerous advantages over all other alternatives:
- Project Gantt chart: It is easy to create a project plan (Gantt chart) out of the list of deliverable in a given state. For example, the Phase 1 backlog in the second example can be copied into a project plan. As work is delivered in Phase 1 the project’s Gantt chart is updated to track project progress and show what deliverables have been completed.
- Time tracking: A workflow solution that is tied into a time tracking application allows you to measure exactly how much time is spent on a workflow entry, making it much easier to report on estimates versus actual and estimate to complete for every agile deliverable.
- Project cost reporting and billing: All of the agile tools on the market today are focused on agile delivery and pay little to no attention to project cost reporting and billing, We believe this to be a fatal flaw of such systems because without a cost and revenue perspective any agile tool may actually create more inefficiencies and new costs that are not entirely visible to the organization. Detailed project cost and revenue reporting is an integral part of an agile project when a workflow driven project and service delivery solution is used to run the process.
Leveraging Workflows for Agile Project and Service Delivery
Using workflow-driven project and service delivery solution:
- Demystifies agile work and delivery. With a workflow solution, agile delivery is just another workflow, and you can create as many agile workflows as required, each with its own set of states, transitions, assignments, roles, business rules and notifications such as the two examples provided here.
- Transforms agile delivery into a workflow-driven process that is tracked, audited, reported on and analyzed with as much detail as you require.
- Institutionalizes agile delivery. You will no longer have to count on the knowledge of a few or a mishmash of tools that only some know well enough to use consistently. The workflow tool and the agile workflow is how everyone collaborates to deliver projects and services.
- Combines agile delivery with traditional project planning, management and status reporting by integrating agile workflows with project Gantt charts.
- Provides powerful and integrated project cost reporting and billing coupled into your agile process. Now you and your customers can actually measure how much various parts, phases and deliverables of an agile project are actually costing you.