This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first seven parts of this series here:
Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players
Part V: Sprint Execution
Part VI: Key traits of Customer Champions
Part VII: Key traits of Development Leads
In Part IV (Key Players) we discussed that an optional role that someone on projects at your organization may play is that of a facilitator of smooth execution of sprints or Schedule Facilitator. People staffed in this role often have job titles such as Project Manager or Software Development Manager, and are typically only necessary on projects with more than a handful of people. These resources are tasked with aiding the development team in delivering the highest value, highest quality features out of each Sprint.
There are five key skills that help a schedule facilitator shine in agile organizations.
In an agile environment, often Microsoft Project is foregone in favor of using just-in-time Sprint planning (I’ll discuss this in a future post) where an “end date” is available for each Sprint (current and future) that has been loaded up with features from the backlog. As you look out further into the future from the current sprint, the reliability of estimates for future Sprints becomes more volatile. In this environment teams have to find another piece of software or means to track dependencies between each others’ features that they are assigned to in a Sprint. Developers are often good at identifying and reporting status on dependencies, but need help watching them. As a schedule facilitator, enable developers to communicate dependencies to you as they are identified during both design and implementation of phases of the project (you’ll have dependencies identified mid-Sprint, guaranteed). Then keep track of these by periodically asking the developers responsible for features that others are dependent on in the current sprint for the status of those dependent features. The challenge is to find a frequency in asking for status that is non-intrusive to their workday and also frequent enough that it results in change. Ask too often, and you get the same answer and irritated developers. Ask too rarely, and you find out there is a problem too late. See the “Report Status” skill for a way to alleviate this.
Another one of the biggest challenges development teams have in an agile environment is getting access to business resources. The Customer Champions closest to the needs of the customer are often responsible for many activities as part of their normal job, and their need to be available to developers for design of new software features is seen as an additional burden. One of the biggest things a Schedule Facilitator can do in this scenario is to help soothe this friction. A good Schedule Facilitator should help the development team with any logistics around getting access to Customer Champions. This includes meeting room planning, getting tools for collaboration on the project, and continuing to communicate to business resources the importance of their involvement in the design process. Business resources often need continual reinforcement of the value of their involvement to achieve success.
As a schedule facilitator one of the most common tasks is still reporting status. In a good agile project, the development team members themselves (including the Development Lead) should be enabled to choose and use the processes and tools they determine as best for their project to communicate status to each other. However at specific intervals, it will be necessary to communicate status to stakeholders such as customers, CTOs, or other high level management expecting an estimated release date or progress to date.
For starters, developers should have a meeting with the Development Lead, all development members, and the Schedule Facilitator to report status semi-regularly. The common format here is SCRUM and it typically happens once a day or twice a week. The goal here is to quickly go around the room and have each person report three things:
- What did you do before last time we met?
- What are you going to do next?
- Are there any roadblocks you need help with removing?
This meeting should not be used to gather completion status on features or to talk about their design. The goal is for each developer to talk for 1-3 minutes. This is a great way to raise visibility to all the development team members of what their colleagues are working on (though a tightly knit group won’t need this), and also to give additional opportunities to identify roadblocks that a Schedule Facilitator can help to remove. However it’s not sufficient for gathering all the information needed to communicate status to other stakeholders. This should be done through a tool or document that allows developers to update their status on features they are working on in a Sprint at any time with the following information:
- Time remaining on feature (hours or days)
- Percent completion of feature (up to 100%)
Throughout the week, give developers a tool to allow them to update these values at any time. Let them know when the Schedule Facilitator will be communicating status to stakeholders so that they have an opportunity to update their status. However once this interval is established, unless you identify a problem with a resource not updating their status, assume that the status each day is current. The goal is to let status reporting from the dev team be autonomous and not some once-a-week endeavor that wastes time by getting everyone in a room to read to the group numbers that are already available in a document or web-based tool.
Prioritize within the Sprint
As developers complete features assigned to them in a Sprint, they will pick up new ones off the backlog as described in Sprint Execution. This can get tricky when the business stakeholders are in the middle of re-prioritizing the backlog. A good Schedule Facilitator communicates with the business regularly to let them know when developers are going to need a new feature to work on, and asks them to expedite determination of the highest priority features on the backlog mid-Sprint.
As developers come up with new tasks to complete identified during design of features and fix bugs from previous ones, a Schedule Facilitator helps greatly in determining the order in which tasks are completed, bugs are fixed, and completed features are tested. Communication between the business, development, and QA when making these prioritizations is key to making sure resources know what effect changes in prioritization will have on them and whether there are other concerns that should be kept in mind before committing to the reprioritization.
Inform and Educate
Inevitably on agile projects (due to their being so adaptable to change), some changes will cause friction in the organization. Because business stakeholders can adjust the highest priority features to work on from one Sprint to another (as described in Backlog Management), at times there will be features that are not finished at the end of a Sprint, or new features requested that are difficult to implement due to dependencies or technical constraints. As a schedule facilitator, one of the most powerful things you can do is inform and educate the stakeholders to which status of the project is being communicated on these issues. Instead of asking a developer to spend 30 minutes explaining to the CTO the issues around implementing a feature, talk with your developers and then communicate this yourself. Schedule facilitators should be aware of the importance in giving developers time to complete their tasks, but never should they shy from talking with a developer when more information is needed to communicate effectively to stakeholders. One of the worst things a Schedule Facilitator can do is to communicate an issue to stakeholders with reasons or additional information that has not been confirmed by the development team as valid.
Lastly, when communicating decisions made in changes to project scope, vision, or direction by stakeholders back to the development team, it’s usually better to not discuss these until they are finalized as some developers will make changes to the way they implement a feature knowing a change is coming. This is great if you’re sure you are going to do it, but if the change isn’t for certain, you’ve now created a concern for a developer that may not blossom into even being one.