NuGet came on to the scene recently and provided the package management and repository, but is somewhat lacking in script ability.

Enter Chocolatey. Built on PowerShell, it allows you to perform apt-like management of applications and their dependencies on Windows. You can start using it in your MSBuild projects or as a general purpose environment for scripting out steps to configure or setup a computer with a specific set of software and its dependencies.

Unfortunately however, many teams fail to understand the nuances of the backlog and that using it effectively requires strict adherence to a set of rules, or all the flexibility that can be gained with agile processes is lost. This post attempts to highlight some mistakes I’ve seen made on teams adopting a backlog that can be fatal for those that fail to heed them.

#1 – Starting the next sprint without communicating and getting buy-in from all parties

This one should never occur if you have read my previous post, or practically any SCRUM/Agile process, but it’s amazing how often it happens. Technical leads can assign tasks to the next sprint and communicate them to their direct superior, without that manager or resource also communicating them to the rest of the business. I’ve seen this happen where 2 weeks into the sprint executives are upset about their feature not being delivered in the current sprint. I’ve also seen this happen where folks higher up in the organization add tasks to the next sprint and commit the development team to them without giving the development team a chance to give their sign off as well.

It is absolutely critical that anyone who can make a decision that impacts the feature set, design, implementation, or testing of the software sign off somehow on the tasks slated for development in the next sprint. It’s preferable to have a document or approval somewhere since early agile adopters need to be held accountable to their commitments to see the process work, and improve their analysis, estimation, and scheduling skills as a result.

#2 - Calling sprint tasks done when they have not been tested

This one gets controversial since some teams feel that testing should be done for a feature in one sprint in the next, but I’ve found that if it is done this way it often leads to two problems. First being that developers tend to not test their code, figuring they have an entire sprint past that to find and fix bugs. Second being that developers tend not to involve QA early enough in the process. As the design of a feature emerges during a sprint, QA resources should be involved regularly at key decision points, so they can formulate test cases as soon as requirements or stories are agreed upon, even before they are built.

Inevitably, bugs will be found in code. So developers should have a percentage of their total workload for a sprint reduced to allow for some percentage of that time to be spent fixing bugs and communicating with QA. Optimally a sprint should include enough time for a tasks to be completed with test cases for each decision created just-in-time for each decision, as well as at least one round of full testing of the feature to complete. This also assists in determining at the end of a sprint whether work remains to complete it. In the case that it does, a new task should be added to the backlog to finish the work that is remaining. This allows the backlog to be prioritized such that completion of the task can be deferred if it becomes less important when the sprint concludes. This leads into the next point.

#3 – Failing to carry over unfinished tasks into the backlog

In teams just starting to adopt agile, many times they are coming from a prior culture of finger pointing and unrealistic goal setting that results in a protectionist mindset. Developers and managers first adopting agile will have a tendency to want to show all tasks added to a sprint complete at the end of that sprint. The thought is that if they don’t finish the tasks, they can’t show progress to the executives further up who may be skeptical of agile. Unfortunately, this is the wrong approach and sets a precedent for the unrealistic goal of having that happen all the time.

Part of following an agile process is providing transparency into problems with estimation, design, and planning and this can only be done if people are allowed to make mistakes and improve. A developer who fails to complete a task on time will learn to estimate better in future sprints if given the chance, or just learn to hide their failure better if forced to act as though their tasks are complete when they really aren’t. A developer who begins to implement a feature only to find it is more complicated than originally intended or the scope missed key things will also learn to do better design work if given the chance, or they will continue to do a shabby job at defining things if forced to act as though they can still meet the deadline for ill-defined tasks. For a healthy team following the backlog, it should be normal for sprints to end with some tasks incomplete at the end-of-sprint meeting. It is the job of the development manager to communicate this and the reasons for allowing it to his superiors.

#4 – Failing to revise estimates for tasks during a sprint

This is related to #3 above and also embraces the reality of the unpredictability of software development. When a task is assigned to a sprint without the waterfall type documentation such as requirements documents, screen mockups, class diagrams, etc. it is completely normal for a developer to discover that the original estimate they provided was too small to complete the task in that sprint. At this point there are a number of possible solutions.

If the task is determined to be much larger in scope than intended, it can be deferred to the backlog and flagged as requiring a re-estimate. The task on the top of the backlog that can fit into the current sprint for that developer can then be assigned to be worked on in its place.

The developer could also provide an estimate for the time it would take to scope the new work (not implement it) and upon completion of that task, work with their superior to determine whether that work can be completed within the sprint, or started in the next sprint depending on the cost of the design and/or discovery effort.

Lastly, the developer can also break the work up into smaller tasks, with accompanying estimates for each and placed back on the backlog, allowing the team to determine which of those sub-tasks is most important and can fit within the current sprint. This must involve all parties (see #1) to take into account technical dependencies.

#5 – Changing the tasks in the current sprint during development

It’s not uncommon for a team to start a sprint, only to have an executive attend a key meeting with a vendor or a salesperson close a big deal where the feature they just envisioned or sold is now the hot item in their mind. Without a backlog, the tendency is to shift all efforts to this feature. This can mean cancelling an entire project when done in waterfall fashion. With the backlog in place however, changes in prioritization that occur after the sprint has started must be placed in the backlog and prioritized accordingly, and not replaced or added to a developer’s current workload. There are several reasons for this.

First, the effort of understanding a feature prior to starting it, and optimally communicating with people to get information about it is lost when a shift like this occurs mid sprint. It tends to result in lost information that needs to be re-communicated when that task is picked up again. Also, it lowers the morale and rhythm of the team by not allowing members to feel “safe” when in a sprint that they can finish their tasks without disruption. Executives and development managers should feel free to go wild with great ideas for their software – but if it changes the current design or adds to it, those changes must go on the backlog. Even if there is an impact on the currently designed feature, that impact is easier to absorb as a future refactoring than the disruption to understanding, rhythm, and predictability afforded by the “lock-in” that the sprint’s set of fixed tasks pulled off the backlog provides.

#6 – Waiting until just before the next sprint to re-prioritize the backlog

Once you’ve read the above “sins”, you can see that a sprint is a highly organic activity. During the sprint, tasks may carry over to the next one, or the business’ needs may change. It is important that development managers continue to communicate with stakeholders to look at the backlog and regularly review it for correct prioritization at key points of the sprint. Whether it’s once a day, once a week, or halfway through the sprint – make sure you take time to look at the backlog. As the project is developed it is normal that insight to future tasks that haven’t started yet arise out of development of current ones. Capitalize on this and keep the backlog up to date as much as possible. If you don’t, you risk having the team wait for executives and management to make decisions on what’s coming up on the next sprint while it should really be underway.

#7 – Committing to release dates based on far-off estimated sprints

One cool technique I’ve seen involves creating a list of backlogs for sprints several cycles out. Let’s say you have a backlog containing 50 task, and you are about to start sprint #2. You determine that approximately 5 units of work (tasks, features, hours etc.) can be completed by your team per sprint. So you assign 5 units worth of tasks to sprint #2, #3, #4, and #5. With a little calendar manipulation it’s easy to come up with an estimated release date. But I should caution you strongly against doing so with this many sprints. As you add more sprints with estimated scheduled tasks, your ability to predict the release goes down in relation. So if you only have 2 sprints left to go, and your team’s burn rate is pretty predictable, you should be much safer in committing releases to the business than with a larger number like 5 sprints worth of work. This is simply due to the nature of unknowns that are found during the development of each sprint. I have found in practice it is not enough to simply come up with some blanket number (like 20%) to account for unknowns and apply that to all of the sprints. A sprint 2 cycles out may have a feature that when started is determined to take 3 times as long as originally planned because its true complexity wasn’t understood at the time it was added to the backlog.

Hopefully it is obvious by now that going agile does not mean razor sharp predictability, consistently hit deadlines, and zero scope creep. Rather, it embraces the reality of software development and favors planning for reality and building a team that operates with tools at its disposal for dealing with change instead of a set of unrealistic goals that sound great in a meeting but fall apart and cost both time and money in practice. The payoff is continually delivering tested, complete features with a little practice, and a team that knows how to adapt to any situation without panic.

I’ve been on a project where this was done to a silly degree, such that there were weeks spent by several developers just doing merges and re-testing the merged changes. Martin posted a tweet this morning with a link to video where they describe the issue in detail. I won’t repeat everything they say here but encourage you to watch it, they do a fantastic job.

http://www.thoughtworks.com/perspectives/30-06-2011-continuous-delivery

The reason behind this is simply a human desire for self-preservation. Business stakeholders’ performance is measured by what features they deliver, managers are measured by their ability to deliver on time, and developers are often measured by their ability to write solid code and deliver it with minimal defects. Since most organizations are structured where developers report to managers, who in turn report to the business; this places an uneven emphasis on adding new features at the expense of consistent time to market with new features of high quality.

As a developer or architect, the list of features and desired release date is often out of our hands, even with a backlog and a fairly well followed set of agile processes. Rather than continue this trend, I’m of the belief that even though business stakeholders are supposed to be the best people at knowing the business, they are often not well versed enough in technology to understand the implications of ignoring requests for refactoring, and making smart decisions with respect to technology selection. Developers are still the core of the value chain in this aspect of the development process. Rather than argue this point, I’d like to propose a list of 4 priorities that developers can regularly consider when making technology and design decisions. If you follow this set of priorities, you’ll find yourself regularly making the best decisions for all parties.

1. Can I implement the feature?
2. Does the design allow extension of features along planned integration points?
3. Is the design flexible enough to allow unplanned changes to be made?
4. Is the design, and are the technologies, the most modern available?

Can I implement the feature?

If you don’t make the software do what the business wants it to, you’ve failed as a developer. It doesn’t matter if you’ve used to most forward thinking technologies and patterns, and written unit tests to give you 110% code coverage (chuckle). If you don’t deliver to market what your business expects, users won’t have compelling reasons to use the software, your business stakeholders won’t have much to sell, and you probably won’t be seen as having much value in the company at one point or another. This assumes that the business is choosing the right features, and designing them to be usable, for success in the marketplace. If you don’t trust the business to make the right decisions here, I’d suggest you join another company you can be passionate about where you believe in the vision and leadership there. Above all else, evaluate design decisions and technology selections by their ability to enable you to meet the requirements and make the feature work. Usability and quality are included in this priority. I’m of the opinion that one should never deliver features that are unusable or of bad quality to the market. If a feature is hard to use, users won’t use it, or worse yet use it as an example of bad design to laugh at with their peers. If a feature doesn’t work, they will say bad things to their friends about your company and kill your brand. Enough said.

Does the design allow extension of features along planned integration points?

When you build a software product, unless you want to see a competitor blow you out of the water very soon after you ship your first version of a feature, you’ve got to have a backlog of new features to add in future releases. I’m of the opinion that this list of future features should be readily available to developers to provide transparency into the direction of the business. While it’s true that an inexperienced developer may look at a backlog and be tempted to make design decisions that extend the schedule and don’t add value needed in that feature or release, a quick read of YAGNI and a revisiting of that principle during design decisions should be all it takes to avoid this. The downside to not letting developers see the backlog of future features is much more nefarious; they can make design decisions that make it difficult, if not impossible to support features planned in the short to medium term future. There is a delicate balance here, but the heading says it well. Make decisions in your design that allow extension of features along integration points you really have planned. Stakeholders should have a way to identify features on the backlog that are uncertain (nice to have) or a duration of time past the current release after which they should not be considered in design decisions. If you’re not sure, don’t do it.

Is the design flexible enough to allow unplanned changes to be made?

I often encounter developers new to OO, data driven design, and contract-first development that go crazy with decoupling and make their designs overly complicated to implement with little value. They add interfaces to classes with trivial logic to enable unit testing (thus adding un-necessary assets to maintain, test, and revisit during refactoring), use solution-specific patterns to implement logic that really belongs in one method, and create complicated multi-step ETL processes to cover up for bad database design. As a developer, you should try to select patterns and technologies that follow best practices in the industry for enabling refactoring, testing, and feature integration; but only to a level that is sufficient to support the first two priorities. This priority is closely related to the one above with a crucial difference – the 2nd priority has a business stakeholder driving the decision for flexibility while this one is driven by a developer desire to use patterns that make the code easy to maintain or rapid to extend but that will be difficult to explain to business stakeholders and management. Usually it’s easy to convince management or stakeholders that you have to design an interface to support integration with data providers they have planned integration with in their backlog. It’s not as easy to convince them that a set of your classes need interfaces for passing into a processing pipeline of some sort when the processing could be done in one method, and there are no plans to modify the pipeline’s order. Read the Tradable Quality Hypothesis from Martin Fowler to help you convince management of the importance for supporting activities that fall into this priority when you feel the need for them.

Is the design, and are the technologies, the most modern available?

Last on your set of priorities should be using new technologies. ASP.NET MVC3, JQuery Templates, OData, Ruby, and F# may offer significant advantages over past technologies or patterns; but if using these doesn’t result in more success with the first 3 priorities, it’s hard to make a logical case for it. There are times where using a technology is necessary for marketing purposes, and in this case use of that technology becomes a feature itself (thus bumping it to priority 1) but otherwise there are many times when using an older version of a database, framework, or language is more than sufficient to enable the business to consistently deliver quality value to customers. Unless your organization has a handle on the first 3 priorities, you’ve got work to do before tackling this one.

Though Razor does a great job requiring minimal characters to insert executable code logic in between the markup it generates (and is basically equivalent in that respect to HAML), it does nothing for minimizing the amount of code you have to write to express the HTML outside of those logic statements. NHaml is simply superior here when you are generating HTML for this reason: it reduces markup to the minimal information needed to identify the JQuery or CSS selectors that elements have applied to them.

It does this because with NHaml normally you specify the name of an element without the angle brackets, but if the tag you want is a DIV element with an ID attribute, you can just specify the ID prefixed by a hash symbol and drop the DIV altogether.

<div id=”blah”></div>

becomes:

#blah

This also works for CSS classes. This dramatically increases code readability because lines of code begin with the JQuery selector or CSS style name used to access them. When writing Javascript or CSS, locating these elements in markup is much easier. This is already on top of the fact that NHaml drops the requirement for closing tags.

Here’s an example that I think illustrates the point. Let’s say I have a CSS style sheet with the following styles. Don’t worry about the attributes in the styles themselves just look over the list of CSS selector names (container, banner etc.) and think of looking at this file day to day:

#container { width: 100%; }
#banner { background-color: blue; } 
.topic { font-size: 14pt; }

Now here’s some HTML markup styled with selectors in the above sheet in HAML:

#container
  #banner
    .topic Hello

Here’s how you would generate the exact same markup using Razor:

<div id=”container”>
  <div id=”banner”>
    <div class=”topic”>Hello</div>
  </div>
</div>

:css
  .topic { font-size: 14pt; }
:javascript
  alert(‘hello!’);
#container
  #banner
    .topic Hello

and here’s Razor:

<style type=”text/css”>
.topic { font-weight: bold }
</style>
<javascript type=”text/javascript”>
alert(‘hello’);
</javascript>
<div id=”container”>
  <div id=”banner”>
    <div class=”topic”>Hello</div>
  </div>
</div>

Hopefully you can see the HAML is much easier to read, and reduced in lines of code by about 15% in this example.

Here’s another great post from late last year that shows some comparisons of Razor and NHaml.

Here’s an example. Let’s say you have a site that loads a partial section of HTML from an AJAX request and you’re going to append it to the page, but it includes some scripts in it. Your script is dependent on two other publicly hosted scripts (twitter, Google maps for example) and can’t execute until those are finished loading. Rather than load them in your main page and increase startup time, LABjs handles it perfectly:

Old AJAX response HTML:

<script src=”http://publicwebservice1.com/script1.js” />
<script src=”http://publicwebservice2.com/script2.js” />
<!– This can’t execute until the first two scripts have loaded, but not all browsers load these in order in a dynamic update to the DOM! –>
<script src=”myscript.js” />

Old myscript.js contents:

<script type=”text/javascript”>
$LAB
.script(‘http://publicwebservice1.com/script1.js’)
.script(‘http://publicwebservice2.com/script2.js’).wait()
.script(‘myscript.js’).wait(function() {
var script1Object = new PublicWebService1.APIObject();
var script2Object = new PublicWebService2.APIObject();
});
</script>

After massaging Google keywords to find the right query and paging through several results, I found a post with a great solution. Basically this code parses your HTML on the client for script tags and loads them separately before returning from the function. I’m now using it anywhere I inject code into the page that has SCRIPT tags via AJAX.

However in the past several years a move towards a minimal development tool mindset has started to occur. This is made possible by the creation of more sophisticated frameworks that establish conventions and set constraints on how to go about implementing things. These constraints reduce the number of API calls to remember, and the number of front end technologies that a typical developer needs to be fluent in. As a byproduct, the required capabilities of development tools is also reduced. Rails, which led to ASP.NET MVC, and JavaScript technologies like the MVC framework being built on Coffee Script as well as mobile frameworks like Titanium Appcelerator all take this approach. They provide the framework and API, and you use the development tool of your choice. Because the framework limits what you can do, but elegantly provides 80% of what you need in most applications, you don’t need an IDE that does so much for you. Extreme minimalists use VIM, Emacs, or TextMate; and Aptana is a popular one with first class support for CSS, HTML, HAML, Rails, JavaScript and many other minimalist technologies that might be a little more approachable to a seasoned .NET developer.

Visual Designers for 20%

However, to take part in this new shift requires a different mindset. What if you had to do all of your user interface development without graphically previewing it first? A dirty little secret in many Microsoft shops is that we rarely use the UI designers anyway. Clients and customers are always asking for features that negate the productivity enhancements touted by RAD design, and force us to the code to do more sophisticated things.  I’ll argue that this is due to an inferior separation of concerns in ASP.NET, and not simply because you’re doing something more complicated. If your framework requires you to break patterns to do something complex, how good of a framework is it? When a development tool only really shines for the minority of projects, your on the losing end of the 80/20 rule. When you design tools to focus on letting developers visually design things, you are continuing to treat UI assets as single units that encapsulate their behavior, presentation, and data. Modern frameworks that separate these concerns make it difficult (if not impossible) to visually represent things as they appear at runtime, but the tradeoff is an increase in productivity due to patterns that decouple responsibilities.

Interpretation vs. Compilation

What if you don’t compile your project to test it out? There are legitimate applications that require compilation due to performance constraints. But if quality is the concern, the efficiency enhancements afforded by these frameworks coupled with a disciplined automated testing approach negate this concern.

Document what you’ve built instead of what you want

What if you don’t create requirements documents, but rather rapidly implement and write tests to serve as the documentation for what the system currently does? We already know from years of SCRUM and Agile debates that documenting a system up front more often than not results in bad designs, slipped deadlines, and stale documentation. Most customers and clients are not system analysts and as such can’t be expected to communicate all of their needs on the first try. A picture is worth 1000 words, and we’ve all been in the meeting where the customer advocate is shown what was built based on their design and they realize things missing that they didn’t communicate. Doesn’t it make sense to use a development process that encourages and adapts to this situation instead of fighting it?

Contrary to popular belief, to pull this off one needs to be a better developer, who follows patterns even more than before. Developers also need to communicate with stakeholders more, and incrementally deliver *tested* features. Increasing the ability for a developer to communicate has all kinds of other benefits as well, such as the ability to clarify requests, think outside of the box, and generally be more pleasant to work with.

If the thought of letting your tests provide your documentation sounds crazy, tell that to Sara Ford.

Get better at learning your framework instead of fighting it

We’ve all been in the code review where someone implemented an API call that’s already in the .NET framework. If we’re honest with ourselves as developers, we really don’t keep much of the .NET technology stack in our head, we just know how to use Google well. If we were able to reduce the number of patterns and APIs used in our solutions, we could retain that knowledge and know the best way to leverage the framework to do what we need to do instead of fighting it. ASP.NET MVC and Rails both exhibit this, and I’ll argue Rails does a better job. ASP.NET MVC won’t complain if you make the mistake of trying to throw a bunch of logic in your view, where in Rails you really have to fight the framework to instantiate classes here. As DHH says “constraints are liberating” (start at 3:50 in).

The challenge

If you could challenge yourself with one technical hurdle this year, would you rather learn another API? Perhaps a way to interface with a new business system? Or would you rather experience a shift in your approach to development that has long lasting, measurable effects on your ability to deliver rapid value and makes you more attractive to established companies and startups? To do so requires several things.

1. Approach these new patterns and capabilities without attempting to compare them to existing methods. As humans we love to do this, but often we get caught up in analysis paralysis or think we’ve “got it” when we grasp just one of the many innovations in these newer frameworks.
2. Do not declare competence with these frameworks until we’ve actually grasped them in their entirety. Learning Rails without understanding caching, convention based mocking of tests, or the plugin architecture is like learning C# but ignoring generics and lambda expressions.
3. Don’t try to figure out how to shim legacy .NET patterns into these frameworks. You wouldn’t expose a low level communication protocol through a web service or REST API where clients are expected to allocate byte arrays, so why would you expect to figure out how to host a third party ASP.NET control in MVC or access a database using T-SQL from an MVC view. Sure, you can do it, but you’re missing the point. And that is to embrace new patterns and learn to abstract the old way of doing things. We’ve been doing it with .NET for years, now let’s see if we can do it when legacy .NET patterns are what we’re abstracting.

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
Part VIII: Key traits of Schedule Facilitators

In Part IV (Key Players) we discussed that a role someone on projects at your organization must play is that of the champion of quality of the software for the customer or Quality Assurance (QA) Lead. People staffed in this role often have job titles such as Lead Test Engineer, or QA Manager or will be the same person running all of the tests at a startup or small company. These resources are tasked with ensuring that the software features developed in each Sprint are free of bugs to the point where they can be delivered to their respective customer.

There are four key concerns that help a QA lead shine in agile organizations.

Extract Scenarios

In most agile projects, there is just enough documentation created to implement features. In this situation, a QA lead cannot use the excuse “the docs didn’t say the software was supposed to do that!” since it should be pretty apparent that the software will do quite a bit that isn’t in the documentation. A primary challenge will be to discover through conversations, reading, and freestyle testing exactly what the software does. The result of understanding these scenarios should be to create a list of scenarios categorized by features, and be able to keep track of which of these has been tested, and what the status of those tests is (pass or fail). This extraction process includes answering questions like:

• What should the default values of controls (or parameters, in a service) be when starting the scenario?
• How does the user get to the scenario (or what methods must be called first, in a service)?
• What fields are required and what is their validation, including validation that is field-specific?
• What should the result(s) be when the scenario is completed?
• What are the other factors that could effect the outcome of this scenario (another user has locked a resource, certain fields or settings are time, user, or environment specific etc.)?

Create Reproducible Tests

Once scenarios begin to be extracted, the steps needed to test them should be recorded in a document, tool, or script that ensures it can be reproduced exactly each time. The excuse that “it’s too time intensive to write down the steps” is a common one that results in inconsistent results from one test cycle to another. The only way to have a strong feeling of conviction as to what’s passing tests is to know you are testing the same way each time. If you can’t take the time to write down the steps needed to test a scenario, you pay back that time in full through extra conversations with developers clarifying steps, bugs found in edge cases not tested in a prior run (with no guarantee you’ll find them in the future as they aren’t written down!), and completely fictional reports of stability.

Coverage at all Costs

Some tools are great at unit testing. Some do a great job at testing use cases. Others setup sophisticated scenarios that are difficult to test by developers. Regardless of the tool or approach used, the goal should be 100% coverage of user (or system) exercised features. If a tool only allows automation of 70% of scenarios, then create (and document!) manual test cases for the remaining 30%. The last words of a failed QA lead are “the tool won’t let us test that so we’re skipping it since it’s not very complicated”.

Estimate Quality with Experience

With the arrival of tools that watch the number of lines of code executed during tests, there is an unfortunate cultural shift in QA towards watching your overall code coverage statistic. Folks declare “90% coverage and all passing tests means ship it!”. When this number is quite misleading. Many of these tools do a good job, but due to the dynamic nature of code (and especially the sophisticated nature of most modern software architectures and their pluggable configuration) it is not possible to determine true code coverage with just one automated tool. A QA lead should spend time with developers understanding enough about the variances and flexibility in their implementation that requires additional testing on a case driven basis. QA leads should report their own estimate of code coverage, which should be based on both the results of automated tests, known scenarios that have not yet been tested, and personal feeling/conviction. As the final arbiter of quality, a QA lead should never report higher or lower stability of a project or feature due to political pressure. Let a manager or developer fight the truth, but never let lies be spoken from the mouth of QA.

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.

Track Dependencies

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.

Facilitate Availability

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 to 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.

Report Status

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:

1. What did you do before last time we met?
2. What are you going to do next?
3. 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:

1. Time remaining on feature (hours or days)
2. 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.