Keep your agile promises by validating acceptance and reducing your sprint workload

Most project teams have tried some permutation of an agile or SCRUM process by now, and a consistent theme amongst those I see on consulting engagements is a failure to deliver the work done in a sprint to users before starting the next one. Continuous integration, standup meetings, and backlogs are usually present, and some will even try test-driven development. But at the end of the sprint, the work is still not ready to deliver to users.

At the end of a sprint, there is a meeting that takes place where stakeholders and the development team get together to review the work that was done. More often than not, the stakeholders like what they see to some extent, but find discrepancies between what they thought they were getting and what was actually implemented. In every case the reason this occurs is a failure to establish acceptance criteria prior to doing the work.

An agile or SCRUM process is usually sold to the business as a way to get more communication going between the development team, and an ability to shift priorities since the backlog can be prioritized; and the work assigned to development in the next sprint allows for more flexibility than a waterfall approach with typical several month to year cycles for releases. Additionally, higher quality is usually promised to the business.

Inexperienced agile teams may read extreme programming and story-driven approaches and like the fact that requirements are sold as only needing to be short statements and not detailed use cases as happens on a waterfall project. They often take this to the extreme, in that a simple description of the work is established in the backlog, and this is the only agreement that can be pointed to with certainty at any point in the process.

A user story in an agile or SCRUM development team’s backlog should be a promise for a future conversation. When a story is scheduled into the next sprint and that sprint starts, the first activity that should take place is the business stakeholder most intimate with the story has a conversation with the developer who is going to do the work, and a QA person who is responsible for validating acceptance of the work is also present.

During this conversation, the goal is to establish acceptance criteria. This focus on criteria provides several benefits. First, it allows the business more time to provide details about the story that they may not have originally communicated when it was placed on the backlog. Second, it allows the developer a chance to communicate technical challenges with the business’ vision, and gives the two parties a chance to come to a compromise in design that will sufficiently meet the needs of both. Thirdly, it enables QA to think about possible ways in which it may be tested, which often leads the business and development representatives to further clarity. The last, which is the subject of this post, is to establish what constitutes successful completion of the work.

To do so does not require a use case, or a large document. Rather, the group should be able to walk away with a description in English of ways in which the user or system will interact with the software that, if successful, validate that the work was done correctly. The level of detail you go into with your description is up to your team, but the more detailed, the more sure you can be that what will be completed at the end of the sprint will be ready for delivery to users. If you are building a calculator for example, you may establish several mathematic calculations that have to succeed to consider it acceptable. Every possible calculation does not need to be present here; but rather enough that it would be difficult to meet the acceptance criteria and still deliver a low quality feature.

Once this acceptance criteria is established, it is of great importance that the person responsible for user acceptance, typically a QA representative, works with the developer to write automated acceptance tests (highly preferred) or come up with a manual testing process that can be used to verify it. This work can be done before the code is written (test-first acceptance) or during (parallel acceptance) but do not leave this until the end. It is highly important that developers are able to execute the acceptance tests, whether automated or manually, several times during the sprint to gauge their progress towards completing it.

Because this acceptance criteria is established up front, it helps developers to focus on delivering precisely that functionality and also reduces the chatter that often happen in lieu of this as a developer attempts to get clarification from the business about details that were not there at the beginning. That being said, if the team is inexperienced with defining acceptance, the first few sprints may result in two undesirable side effects.

The first of these is that since developers are not used to having to deliver acceptance tests along with the work itself, there is a good chance that too much work will be scheduled in the sprint, and some of them may be late. It is of great importance that the entire team – the business, QA, and development accept this possibility and use it as a learning experience to discover what a reasonable amount of work to deliver in a sprint looks like when it has to be accepted and deliverable before the sprint is over. The next sprint will likely deliver less functionality in the same amount of time, but will be done in time for the end of the sprint. This is the difference between what I’ve heard others call “agilefall” or “waterscrum”. That being the cherry-picking of practices from an agile/SCRUM process and failing to deliver on the promises.

The second side effect of this process change that may be felt when first implementing it on your project is that there will still be some things missing from what was delivered and what the business expects. Let me be clear here – it is perfectly normal, and actually a great benefit to using an agile process that the business can see something every 2 weeks (or however long your sprint is) and upon doing so, provide additional detail and changes that can be scheduled for the next sprint. However the entire delivery team needs to get better at articulating what they do plan to deliver in a way that can be acceptance tested and is clear to the developer so what is agreed upon is not open to interpretation.

This subtle difference is important – it is unrealistic and illogical for the business to attempt to hold developers accountable for not delivering functionality at the end of a sprint for which acceptance criteria could not be defined. If the business wants developers to do a better job at delivering what they want, they must improve their ability to articulate it, or simply embrace the great flexibility that comes with an agile process to allow them to figure out more about what exactly they want every two weeks.

One more change needs to occur to your process to allow for the work that is done in the sprint, now backed by acceptance criteria, to be delivered to users at the end. The developer should allow for time to meet with operations personnel or whoever maintains the various environments (development, acceptance, and production for example) to ensure that they can actually deliver it to users at conclusion of the end-of-sprint meeting. The business may still decide that it is not ready for users from a functional standpoint, but the goal should be for the functionality delivered in each sprint to be of high enough quality to deliver to users immediately following conclusion of the sprint should they desire. Refer to my post about the dangers of making production an island and not optimizing your build process for quick escalation from a user acceptance environment into production for more information on how your operations team can deliver deployment scripts along with the development team.

Think for a moment about the net result of all of this. At the end of a sprint, QA can demonstrate that the functionality delivered meets the acceptance criteria not that they or a developer came up with, but the business as well. We’ve all seen the project where QA said a feature was tested but the business is upset with them and the developers for what was delivered. Developers also do not have to feel any anxiety that what they deliver will not be acceptable. They should however be comfortable with the fact that upon seeing the work, the business may want things changed or additional functionality put in. This is exactly why businesses usually agree to trying out an agile/SCRUM process in the first place.

Even though less functionality is delivered at the end of a sprint than your team may be used to due to having to include time for defining acceptance criteria, building automated or manual acceptance processes, and getting that functionality deployed into a user acceptance environment – the net result is that your business truly will be able to deliver new functionality to users every two weeks. This outcome alone is more important than any of the individual agile or SCRUM processes – that of continuously delivering real value to your users.

Foregoing assumed value in favor of rapid feedback

The goal of developing any software should be to provide functionality useful to the majority of its users.

While doing business analysis or writing user stories for a feature of a project (especially those that are an attempted re-design of an existing one), it is important (and exciting) to brainstorm, be visionary, and think up great ideas for how you can please your customer base. However when planning those features for release, it is tempting to attempt to complete all of those stories before making the feature available to users.

The reasoning behind this argument usually sounds something like “our customers have used the product for years with these features, and they will not use it if they are not all present”. Another spin on this is “our competitor has these features and we will not be competitive without them”. There are several flaws in this argument.

1. The argument assumes that users are currently using all the features. Unless you are measuring the use of the feature in the field (google analytics etc.) and have data to back up this claim, it is highly unlikely that a compelling offering could not be made available to users with a smaller subset of features.

   This applies to competitive analysis as well. Comparing your planned features to an existing product sheet will simply align you with them, which can be a disaster if many of their features are unused by their customers and you will now be spending money building them too. It also reduces your ability to differentiate yourself from them.

2. The argument assumes that users will not provide accurate feedback on their needs of the software. When you choose to implement the kitchen sink around a feature, what you’re really saying is, “I know more about the user’s needs than they do, so I will decide everything to offer them”.

   When you go this route you spend excessive time getting to market, excessive capital implementing features that may not even be used, and place release cycle pressure on yourself by having a larger workload – making it less likely that you will be in the relaxed mindset necessary to listen to your customers and be able to respond to requests for changes.

   It’s more efficient and realistic to simply release the smallest subset of those features necessary to make initial use of them available, measure usage and gather feedback, and give users exactly what they want once they’ve used the feature. While it’s true that this approach can result in designs that are different from what you originally envisioned, your vision is not as important as the successful adoption of a feature by its users.

3. The argument weights delivering assumed value over used value. What this means is that by focusing development on robust implementation of features that have not been even initially deployed to users, the backlog and priorities are being driven on assumed need. Even if your customers tell you they need a feature, unless you are measuring that they are using it in the field, and they are providing you with feedback that they like it, you are taking a risk with the effort needed to implement it. It makes sense to reduce that risk so that if you deploy a feature that turns out to not be useful, the lost capital is minimal.

Where I’m going with this is that organizations should spend serious time reviewing their backlogs of features, working with user experience experts to come up with designs that deliver the smallest, simplest design that accomplishes what you think the user needs and then get it out there. It is always more viable to bolt on a feature that you verify is needed after an initial offering than to spend money on assumptions only to find that it was a waste.

The 7 Deadly Sins of Backlog (Mis) Management

When a team or organization decides to go agile, one of the key practices to follow is letting a backlog drive the rhythm and order of development tasks. You can read my previous posts on backlog management and sprint execution to get an overview of how some typical teams I’ve worked with have used it to great effect.

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.

Why feature branching is a bad idea

I saw Martin Fowler speak in Austin a couple years ago and one part of his talk was on continuous integration. He touched on feature branching, which is essentially where a main “trunk” of source for a project is branched several times, once per feature under active development. The management purpose behind this is typically to try and allow for release into production should one or more features not get done on time.

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 Minimalist Development Movement

Over the past 11 years, .NET technology, fueled by Microsoft’s ability to deliver sophisticated development tools, has arguably ruled the enterprise business software landscape. Intellisense, drag-and-drop UI design, XML configuration, dependency injection, unit testing, IDE extensibility APIs for third party controls, continuous integration, and more attempt to ease the use of Agile and SCRUM processes as the Visual Studio IDE supports more and more of these features through wizards and templates. .NET started as a better version of Java, and as such inherited many of the powerful capabilities, but also limitations in that development and deployment approach.

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.

Organizational health for Agile Adoption: Key traits of QA leads

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

Organizational health for Agile Adoption: Key traits of Schedule Facilitators

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.

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.

Organizational health for Agile adoption: Key traits of Development Leads

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 six 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

In Part IV (Key Players) we discussed that an important role that someone on projects at your organization must play is that of a leader of the development resources, or Development Lead. People staffed in this role, whether the sole proprietor of a startup or a technical leader assigned to a project such as an architect or senior consultant, are tasked with more thought collaboration and less reliance on technical savvy in an organization.

There are five key skills that help a development lead shine in agile organizations.

Refactoring

Predictably, it’s important that people tasked with leading the development activities of projects at agile organizations be competent at refactoring. The ability to bring experience from real projects (sometimes failures bring more experience than wildly successful ones) and to apply this to a rapidly changing codebase is increasingly important, because on an agile project the design of key modules and patterns is going to change somewhat regularly. Experience with modern source control solutions; modern architectural patterns and their tradeoffs, refactoring features in IDE’s like Visual Studio, Eclipse, and Resharper; and some competency with the technologies involved are all good ingredients for refactoring success.

Mentoring

It’s also important to have a Development Lead who is aware of their shortcomings. A lead who solicits input from other team members on their own, and who offers more of their time to do reviews of design and code is the type of person we’re looking for. A person with great technical skills will produce functional code. A person with great technical collaboration skills will produce a team of producers of functional code. A goal for Development Leads should be to create a culture of “sustainable autonomy”. Developers on their team should be able to prioritize their own bugs, gather their own requirement clarifications, and assign themselves to new work as other items are finished without constant oversight by them. Though junior developers on an agile team may require more oversight, this should be the exception, and not the rule. Development Leads may take the drivers’ seat in making some of the initial process and technical decisions at the beginning of a project or sprint, but the changes that occur when the theoretical gets concrete (as most agile projects are light on up-front technical decisions, preferring decisions made at the latest responsible moment) should be team driven. Doing this diversifies some of the leadership skills across the team instead of centralizing it on one star player. It’s still important to have one technical final arbiter of decisions at which the buck stops however.

Written, presented, and oral communication

This one’s pretty self explanatory but it’s so important it really has to be worked on to be harnessed. A development lead should work to be better at conveying information, in a variety of formats, to a variety of audiences, and then gathering and interpreting feedback from that conveyance. This means good grammar, spelling, email voice/attitude consideration of audience, and even selection of media. This is a foundation upon which the other skills needed by a solid Development Lead rest.

Compromise

It also bears repeating from the Key Players post that communication with business resources is of the utmost importance to Development Leads. A good lead has an ability to provide the right analogies and information to convey ideas without being overly technical, and makes business people feel excited when discussing ideas with them instead of intimidated. Business resources should feel like “this is the person who’s going to turn my ideas into reality” instead of “this is the person who’s going to change all my ideas to fit technology limitations”. People on both the business and development side of the fence live day to day with the reality that at times software vision must bend to the unfortunate compromises of technical limitations, but a good development lead puts energy on what can be done instead. You want a person who sees the process of cultivating a project out of agile processes to be one who sees the cup “half full”. This doesn’t mean being a well-to-please, but rather someone who works tirelessly to find an acceptable level of functionality to solve the business problem within technical constraints.

Pragmatism

This ability to compromise also extends its benefit when a Development Lead must consider budget and schedule constraints when weighing tradeoffs of technical decisions. Every time dependency injection, testing approach, partner integration patterns, or any other aspect of the design of the software is on the table; a good lead considers the true weight of each factor (and not just their own position) for all involved and strives to make the right decision for users of the software and the business. This more often than not means accepting a difficult technical limitation in favor of meeting a requirement or a deadline. It is still important in these situations to document the limitations imposed by weighted decisions both to keep track of addressing them later and to prevent accusations of ignorance should the limitations become politically stressful for the customer or organization.

Organizational health for Agile adoption: Key traits of Customer Champions

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 five 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

In Part IV (Key Players) we discussed that an important role that someone on projects at your organization must play is that of an advocate for the customer, or a Customer Champion. People staffed in this role, whether the sole proprietor of a startup or several individuals in a hierarchically-organized corporation have some initial traits that make them effective in this role regardless of the situation, as well as a difficult set of opposing concerns to contend with.

First of all, it’s important that a Customer Champion who has experience in the market or job that the agile project is targeting realizes that once they become an advocate for the customer, they are no longer the customer. Take for instance a fictional project that is building software to make it easier to track the quality of manufacturing automotive parts. A person in this role may have had 20 years experience building cars, and consider themselves experts in the field. But for the past 6 months, they have been working behind a desk, and when they were on the job, their idea of quality concerns were those which made it hard for them to get quality to sign off on parts so they could continue building more. Someone responsible for quality metrics themselves may have had an entirely different set of problems that are more important to them. Regardless, a good Customer Champion has to realize that any experience they bring to the table in a field related to the target customer of a project is from a single blind perspective, and they will have a tendency to rely on their experience to guide their interpretation of the customer’s concerns. Instead, they should focus on gathering information about disciplines other than those that they are familiar with to make the most educated decisions on what to build. In other words, work hard learning what you don’t know and what other related job role’s problems are – you’re already well in tune with those closest to the vest.

Secondly, it’s common that a Customer Champion is helping to design a “new version” of an existing software solution, or to automate something that used to be a manual process. It’s rare that Customer Champions have a background in software user interface design, business analysis, and studying flow-of-work, but many organizations hand over the reigns for making these decisions to exactly these individuals. Instead, the Customer Champion should realize that the one chance the organization gets to truly make a significant impact on the way the target customer’s problem is solved is at the beginning – and the only way to make a radical change to existing problems is to think completely outside of the box and not use any existing program as a blueprint. This can’t happen if the only identified solutions are those that solve problems with the existing version of the solution.

The opposing concerns I mentioned before that are hard to deal with are the pull of what a customer says are their primary problems against what their primary problems really are. A good Customer Champion will setup discussion forums, make phone calls, send polls, and gather questionnaires to determine how their customer feels about the relative importance of the problems they are trying to solve. Not doing these things is a recipe for disaster as it is. But even if a mountain of data is gathered directly from the mouth of the users that will buy your product or service, the real work hasn’t really started. Next this data must be analyzed and patterns must be recognized. And even after these patterns are identified, you must dig deeper to find the root cause, which is many times not obvious.

The important thing I’m getting at here is that identifying the biggest problems of your target user is a tough job. So many people in this role I encounter at organizations spend their time driving the look and feel of the user interface, coming up with ways to cram up-and-coming industry technologies into the product line or service, and frankly, designing a clone in functionality of the existing system when all of these things are the least value they bring to the table. Top tier software developers are much better at making technology tradeoff decisions, coming up with novel solutions through technology to problems, and designing effective and usable interfaces. And graphic designers are much better at making things look pretty than customer advocates or software developers in most cases. The one thing developers absolutely cannot do however is determine with certainty what the customers’ problems are in the first place. It’s this information that really determines whether you have a chance of being successful. A project may ship fast, look good, scream quality, and have all the right market positioning – but without making the target customer base more successful in their work, it’s just a pretty solution built on an expensive, volatile foundation waiting for a more agile competitor to knock it down.

Organizational health for Agile adoption: Sprint Execution

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 four parts of this series here:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players

In Part III (Backlog Management), we talked about how features are placed on a backlog to set the vision for a project prior to starting the first sprint. Now that we know the key players that need to be represented by one or more people as described in the previous post, let’s describe the flow of executing a sprint in detail. Recall from the Backlog Management post that a sprint is a fixed period of time during which the development team works on features before “coming up for air” (review and re-prioritization by the business). Below is a diagram depicting the steps in execution of a typical sprint. I’ll describe each step below the diagram.

Agile Sprint Planning and Execution Workflow

1. Analyze market, set vision, scope and/or mockup initial features

During this step, the Customer Champions and/or Competitive Analysts, along with Visionaries and major stakeholders on the project (or maybe one guy in a startup!) collaborate to set the vision for the project. The vision may be “create the best recipe management software on the web”, “solve world hunger”, “solve the problem of sharing documents between manufacturers and suppliers”, or “create a culture for development of web 2.0 products in the pharmaceutical industry”. There are hundreds of business books out there to help you craft mission statements or culture mantras for your business or project so I’ll leave that as an exercise for the reader. At some point however, a critical decision must be made as to what level of analysis will be done prior to involving development at this step. On a very agile project with pressure to aggressively be first to market, it is easy at this step to come up with only a list of features and add these to the backlog as described in Business Backlog Prioritization in the Backlog Management post. Then the highest prioritized features are assigned to developers (as I’ll describe soon in more detail) and they collaborate with the customer representatives to come up with user interface or use case designs.

In my experience however, I find you will actually get to market faster with less refactoring churn if you make a “throwaway mockup” of the entire project/product at this point. The goal here is to select a single developer or designer (the Usability Expert from the Key Players post) and work with the Customer Champions to create mockups for every screen in the system before the first sprint begins. Doing this up front has several benefits. First, it forces the customer representatives to think through all the features they want to build in more detail than the simplified list a backlog provides. This will aid in getting a feel for the total size of the project during planning. Secondly, it gives developers a general roadmap to look at when designing features in a sprint where they can identify patterns earlier to reduce refactoring. For example, lets say that your application has a feature that allows users to attach photos to their profile through a web page. The developers implement this feature in sprint 1 and the business is happy. In sprint 5, the feature “add ingredients” is now designed and it comes to light that photos should also be attached to ingredients. The developers may have implemented the photo attachment feature in a fashion where it is “hardcoded” to only support a profile, and they now need to refactor the code from sprint 1 to handle multiple types of objects to which an image can be attached. Had these photo attachment features been available through a throwaway mockup prior to starting the project, the developers could have analyzed the throwaways to identify the pattern of photo attachments when designing the first sprint’s feature and avoided the refactoring.

The important thing to note if doing a throwaway mockup however is that it is simply that – a throwaway. The final designed screens do not need to have the same style, layout, and even navigation. Think of it as a user interface brainstorming and business analysis scoping tool. It’s purpose is to guide the design of features in a sprint without complete blindness as to opportunities for reuse between features in future sprints, without spending a ton of time doing “real” user interface mockups. In some projects this may not be feasible because the business doesn’t want to spend the time it needs to really scope out everything up front. Another common concern is how to utilize developers while this is going on. I’d suggest they spend their time researching, prototyping, and learning about the technologies that will be used regardless of the features that will be implemented. The time needed to decide on exception handling, data access, security, and other approaches at this point is well spent. A Development Lead can also analyze the throwaway mockup when available to help them make the best technology selections.

2. Reprioritize

Here the Customer Champions shuffle the backlog as described in the Backlog Management post and put the most important features to them on top.

3. Highest Priority Features

Next the Development Lead and Customer Champions agree on the features that will be done next and select a number based on the available developers in the team (I suggest one per developer) and take them off the Product Backlog, adding them to the current Sprint Backlog. At this point, the items in the product backlog are “free” so to speak, and available for the Customer Champions to reprioritize, add to, and remove from while the sprint backlog is being worked on by the development team. I’d suggest managing the sprint backlog in a tool or spreadsheet that can be filled out with the following information about each feature being worked on in the sprint as it progresses:

• Feature name
• Assigned developer
• Status (“Designing, Implementing, Testing, Complete” at a minimum – more if you need to track at a finer granularity)
• Estimate

4. Collaborate to Produce Mockups, Business Rules & Ubiquitous Language AND 5. Assign and Estimate Features

During this step the goal is to have collaboration occur between developers and Customer Champions resulting in agreement on terminology that describes the domain of the problems the software is trying to solve. This happens through discussions, meetings, and online collaboration as necessary. The resulting terminology is the Ubiquitous Language as described in Domain Driven Design.

the Development Lead and other developers meet to assign one feature from the sprint backlog to each developer. At this point, there are two approaches I’ve seen taken when doing the design and each have their positives and negatives.

The first approach to agile design executes step 5 before step 4 and involves each developer taking ownership for the entire process of building that feature from analysis all the way until it is handed off to QA. This requires developers who are very talented, self starters, have solid experience in usability, object oriented design, and an ability to identify opportunities for reuse. Be realistic about your confidence in the equal talents of all of your resources before taking this route. In this approach, each single developer collaborates with the Customer Champions to come up with user interface mockups (in a system with a UI) or system use descriptions (in a service or headless system) for the feature they are responsible for. These collaborations can result in mockups, napkin drawings, use case documents, prototype APIs, eXtreme Programming story cards, or any other method of tracking. It’s important however that no matter what approach is used, the following artifacts of each case are at initially captured as part of the design:

1. How does the user (or system) get to this feature – this only has to describe what’s known in this sprint, and not all possible navigation opportunities at this point. Use the throwaway mockup as a guide if you made one. At least think about it!
2. What validation is performed when the user (or system) interacts with this feature – Take a crack at this before coding, even if you will (inevitably) uncover more during implementation.
3. What are the “default values” that fields or API parameters are set to when the user (or system) interacts with this feature
4. What job role (or system role) do the people (or systems) who interact with this feature belong to – Again, take a crack at this up front, it’s many times easier to design for security permissions at the beginning than later.
5. What actions that the user (or system) can take when using this feature change the state of other aspects of the feature – For example, “when you select this combo box, it filters this other one” or “if you pass true to this parameter, the data returned is filtered in this way”.

Remember that even though most agile books will tell you that use cases are outdated, much of the same information captured by them is still important to identify at this step when using other methods. If you choose to use another methodology to gather the needed requirements, great – the better job you do of capturing details, the better estimate you will have.

The benefit to this first approach (letting each developer own the entire design process for their assigned features) is that there is a potential for increased productivity if multiple Customer Champions are available. The downside is that developers may not identify opportunities for reuse and learn each other’s subset of the Ubiquitous Language at the same time.

The second approach to agile design executes step 4 before step 5 and involves the best developers on the team being the primary analysts and designers of every feature. This has the benefit of letting the most talented developers shine in creating the user interface and primary models of the software. In most teams, you’ll find a higher quality of code and increased consistency from feature to feature if you go this route. The downside to this approach is that the junior developers not involved in design of the features have to find something else to do. In reality this is rarely an issue unless your developers write 100% bug-free code as they will be fixing bugs from their prior features while the next highest priority features on the backlog are being designed. Businesses can get paranoid about having these junior developers in “feature limbo” during this period, however the pain incurred by having a junior developer take on the design of a feature that is over their head (and in isolation from more senior developers) and resulting in a bad design is enough to eradicate this after a couple occurrences.

You may have read about YAGNI – “don’t build it until you need it” is the mantra here. And while I both love this article and agree with it’s premise completely, don’t mistake YAGNI for something you are going to need, but is just coming in a future sprint. If it’s on the backlog but just not assigned to the current sprint, there’s still a good chance “you’re gonna need it”. If it’s not, don’t spend time at all on it. When in doubt, work with the business to determine the rank of a future feature that may have an impact on your design of the current one – sometimes it may be determined that it’s a “nice to have” feature that is far off in the distance and won’t even be implemented in the current release.

As soon as developers have had initial collaborations with the business and have a scope for the feature, they should update the estimate in the sprint backlog with a rough estimate. In a future post I’ll describe the sprint planning and management process by which a Development Lead or Schedule Facilitator (described in the Backlog Management post) can shift features to future sprints to have things line up more easily. As soon as the developer designing the feature has produced all artifacts other than the code (mockups, story cards, use cases etc.) they should update the estimate with a more detailed (and more accurate) value. This estimate should include the time they think will be needed to write unit tests to the level of coverage agreed upon by the team but not include the time needed for any additional testing by QA personnel. I’ll talk more about agile estimation in a future post.

6. Implement Features

During this step, developers do what they do best – design and write code. The activities that take place here are outside of the scope of this discussion, but an important aspect of managing the sprint is to track the status of each feature as it progresses through being built. As the sprint progresses, developers can update the estimate or provide a “time remaining” on regular intervals, but this is up to your organization to decide. Remember that a big part of the agile process is to eliminate waste. If status is being gathered just to put pressure on developers, you probably don’t have the right people to do agile development in the first place. If you are going to enable agile development at an organization, you should be using professional resources that do not need to be told what to do.

7. Test and Validate Implemented Features

Whenever a feature is done being coded and unit tested by a developer, it’s status should be set to “Testing” and QA personnel should be notified that this feature is ready to test. At this point the developer who implemented the feature should organize a collaboration with QA to communicate what’s been implemented in detail, as there is a good chance that what was designed going into the sprint has had some changes since the beginning. Don’t bother updating the design documents – the tests written here are your documentation for what is currently implemented. Once this feature handoff occurs, that developer picks the next highest item off the product backlog to work on. The goal is for each developer to finish at least one feature per sprint to have something to show at the end, but depending on the length of sprints and complexity of features, there may be several features implemented per developer per sprint.

The QA testing process is very much specific to your technologies and organization. Regardless, developers should be prepared to have to balance fixing bugs found in previously completed features with developing newly assigned ones. This underlines the importance of developers not handing features off to QA until they are really well unit tested and complete.

8. Mark Features as Accepted for Sprint Review

When features have been tested by QA, and no bugs that must be fixed before that feature can be shipped exist, the sprint backlog’s status for that feature should be updated to “Accepted”.

9. Present and Gather Feedback on Tested Features

Near the end of a sprint, developers should coordinate with one another to try to make sure that any new features being worked on do not break the functionality that was already “Accepted” in prior features for that sprint.  There will be cases where to move forward existing features must be broken, but if these changes cannot be made in a way that allows the original features to still be presented to the business, that feature’s status should be rolled back from “Accepted” to “Implementing”.

After developers have coordinated their efforts and the last day of the sprint concludes, a meeting should occur in which developers demonstrate the implemented features to the business. At this meeting any changes or enhancements that are requested should be added to the product backlog and prioritized along with whatever else exists at the top of the backlog.

10. Combine Sprint Feedback with Customer Feedback and Market Evaluation

Here is where the agile process really shines. At this point, we should have some shippable features, a list of changes or enhancements (potentially) to those features gathered in the sprint presentation meeting, and an updated evaluation of the market (our competitors and users’ needs). The business can then decide again what’s most important. Has the market or users’ needs changed such that existing planned features are lower priority or no longer necessary? Is there a new market need that is more important? Are changes found during the sprint meeting the most important ones to build next? Whatever the answer, the business is armed now with assets and options for re-aligning the efforts of the development team, perhaps radically if needed, without disruption to the quality of their work or the schedule. When the Customer Representatives arrive at their updated prioritization of the backlog, the process continues again at “scope and/or mockup initial features” from step 1. In future posts I’ll discuss planning, estimation, important traits to look for in the key roles to execute this process smoothly, tools to use, and tips to successful sprint execution.