Managing Stakeholder Expectations in Agile

When starting any new significant change in your life, its easy (and natural) to have high expectations. Whether it's starting a workout program, a new job or even a marriage, human beings tend to get caught up in the euphoria of the newness and all that the change can seemingly promise. Unrealistic expectations of (somewhat) effortless success can pervade and sometimes sabotage the effort. Transitioning from traditional Waterfall-based methodologies to Agile is no different. The promise of the "silver bullet" of Agile and common misconceptions about what Agile even is (or isn't), if allowed to persist, will make the move far more difficult than it needs to be. Let's look at some of the challenges related to stakeholder expectations in Agile and how to address them. 


Battling Misconceptions
There are some common misconceptions out there about what Agile is or is not, and you need to address these before they manifest on your adoption. Here are a few of the biggest ones:

1. "Agile=Rapid Development" – I'm not exactly sure where this notion started, but it is even perpetuated by some Agilists in the community. This, in my opinion, is potentially the most dangerous misconception that stakeholders could have. It's the notion that because you're "doing Agile," you'll just get done faster. I argue that while this will likely end up happening in the long run, I wouldn't characterize it as "rapid development." "More efficient development" is the term I would use. Agile should end up giving the development team more value-added time by stripping away unnecessary processes and lost time from miscommunication that comes from relying on the written word. It should also give the business quicker ROI by delivering release-ready product sooner in the business cycle. But stakeholders shouldn't expect that all else can stay the same, the development team starts "doing Agile," and code will just be cranked out sooner. 
2. 
   
   "Agile=No more Documentation" – Looking at the Agile Manifesto, and the valuing of "Working Software over comprehensive documentation," stakeholders will often expect this will mean they will get NO documentation. This should not be the case. As I tell my teams, "I want you to do as much documentation as is absolutely necessary." And how/when/if you should create the document depends on the type of document it is. To look at this a little more closely, I'll divide documentation into three subgroups:
   1. Compliance – Documents required by governing bodies external to the team, be they industry regulatory governance or even internal project management office requirements. Either way, those types of documents are necessary to release the product, even if they are not part of building the product. Creating these documents should be tasked out on the Sprint backlog, even if those tasks are all taken by a B.A. or technical writer. These tasks will likely be ongoing during a sprint so as to avoid a mad rush to document at the end.
      
   2. Users – User guides, help documentation, etc. These types of documents also are not directly related to building the product, but necessary for release. The key to developing these documents is to generate them as late as possible in the process, so as to capture the end state of the product, rather than expending effort throughout the development cycle to continually try to capture the change. Since they aren't published until release time, all that time spent changing them is waste.
      
   3. 
      
      Team – These documents are used by the team to document the development of the product and the technical aspects of the design. These will likely include logical and physical database models, class diagrams, design guidelines…anything you can picture would be used by designers and coders to understand how the product was/is designed and functioning under the surface. There are two keys to these documents:
      1. Have the conversation first, then document – We shouldn't assume we need all the documents we're used to generating. Teams should first talk about an issue, or approach. If they arrive at an agreement and no documentation is needed, then don't produce it. If they decide they need documentation at that point, then they've proven its validity and should task it out.
         
      2. Generate the documents, don't author them – Especially when we're talking system and database documentation, there are plenty of tools out there that can reverse engineer code or databases and document the end state. Spend your time collaborating and designing, then use one of these tools one the design is stable and let it do the work for you to optimize your time.
         

Radiating Information
Another key way to manage expectations is to give stakeholders the transparency that Agile promises. Use "information radiators" to do this. Beyond the typical burndown chart used primarily by the team to track progress towards sprint completion, consider using a burnup chart, showing the additional metric of scope change. In this way, stakeholders can clearly see the effect that adding or removing scope will have on the team's progress towards reaching their goal.

Burnup Chart



Consider also adding the information radiators of a release burndown and velocity charts. A release burndown will simply show the amount of work remaining from the product backlog after each sprint. Used in conjunction with a velocity measurement chart of the amount of work the team completes in each sprint, simple math will give you and stakeholders the best case, worst case, and probable average for how long it will take the team to complete the work for the release.

Velocity Chart

No "Silver Bullet"

You must coach stakeholders that Agile is not a "silver bullet" that will solve all the organizational development challenges overnight. Transitioning to Agile will actually surface organizational impediments, likely starting with the most significant and painful. What the organization decides to do about the impediments is the question. As Ken Schwaber says "Bringing Agile into your organization is like inviting your mother-in-law to come live with you. She won't solve all your problems, but she will sure point them out to you." Stakeholders should expect that following the initial euphoria that often accompanies new efforts, there will likely be a time when those involved find it very difficult, and it will seem easier to go back to the old ways. It's at this time that their commitment and support will be most vital to the team, to help them push through the "valley of despair."

Expect to Communicate

Finally, stakeholders should expect to be engaged throughout the process. Collaboration is critically important to successfully adopting Agile. If stakeholders expect to be disengaged, development will be far less likely to match the needs of the business. Ultimately, Dialogue + Transparency + Collaboration = Trust…and trust between stakeholders and the team will breed the most success.

Working without a Net: Making the Move from Traditional Requirements to User Stories

Walking across a tightrope 30 feet in the air would frighten most of us, but having a safety net might make you feel safe enough to try it. The reality is you can get hurt pretty badly in a fall even with a net, so the feeling of safety is more perception than reality.

For teams happy with the perceived security provided by highly detailed, prescriptive requirements, moving to user stories will probably feel like removing that safety net…more detail is seen as more security. But when practicing Agile, making that move is essential to shortening your timelines to release, eliminating waste in your development processes, and having more assurance that what is actually developed will more closely align with business needs and wants.

What's Your Story?
So why do Agile practitioners favor user stories? A user story is a starting point for a conversation between a Product Owner and the Development Team. It's a vehicle to express the business needs to the Team, in language that a user of the application should understand. A classic user story template has the following format:

As a [user role],
I want to [accomplish a goal],
so that [reason].

Let's examine that story template a little bit. Why is it so effective? We find an answer by looking to journalism and police investigations, to the "Five W's." In those arenas, these are essential elements of gathering or telling any complete story. You likely learned them in high school composition class, too. (The documented origins go back at least 2,000 years to the Roman orator Cicero, so it's safe to say they're time-tested.) They are the questions:

1. Who
   
2. What
   
3. When
   
4. Where
   
5. Why
   

The questions are designed to bring out the expositional details in a story, effectively "the essentials." Mapping to the user story template above, the [user role] tells us "Who," [accomplish a goal] answers "What", and the [reason] addresses a key element for understanding, the "Why." The "When" and "Where" often crop up in context throughout the elements. Consider a mobile application for users to get information about your local city. As an example:

"As a city visitor,
I want to get a list of festivals during my vacation week
so I can plan my itinerary."

Who=a city visitor, (not a resident)
What=get a list of festivals for the week they'll be in town
When=(presumably) some time before their vacation week? How much before? Good question…
Where=on their mobile device (we're building a mobile app)
Why=to plan their vacation itinerary
How=??? Yes, the "How" is missing, and that is on purpose.

The story clarifies the essential elements of the goal. Notice that the "When" answer generated a question for discussion and clarification. Notice too, that no implementation details are present…there's nothing in there about buttons, links, grids, etc. The answer to the question "How do we get there?" is left up to the development team. The Product Owner owns the 5 W's, but the development team owns the "How." And in the conversations around the user story, you also end up tapping the creative minds of the developers to help shape the requirement. That input might otherwise be missed by just relying on the one-way communication of handing them the finished requirement.

"But I want my detail!"
A car salesman can show you a brochure, review all the technical specs on a car, and tell you how great it is, but only when you test drive it do you get the real feel of whether it's right for you. I tell my teams that "at some point, you will have all the detail." That's at the end of the iteration, when the feature is delivered. Only then are all the unknowns eliminated. Both Agile and traditional requirements get you to all the detail, they just go about it in different ways. Traditional requirements are most often developed completely before development begins. Detail is arrived at by people speculating, projecting, maybe wire framing, and likely guessing at what the end state of the feature will be. The challenge there is that change is a constant, so everything that changes in the end makes the upfront effort to project the end state of what ended up changing into wasted effort. In Agile, beginning with user stories, the details are arrived at collaboratively between the Product Owner and the team, building something and putting it in front of the Product Owner for a test drive, and iterating and incorporating his/her feedback until the feature reflects what the Product Owner wants.

Not All Truths are Self-Evident
To some (both business and development), moving from generating and following detailed, prescriptive requirements to using user stories and face-to-face collaboration will be liberating… "Finally!...free from all the overhead!" But for others, it will like being made to walk that tightrope without the net, and their reaction can be visceral. Some Product Owners will feel that if they don't put all the detail in the requirements, they won't get what they want, or something will be missed. Some developers actually prefer the prescriptive development model of "just tell me what you want me to build and I'll build it." If you've embraced user stories and the benefits they and collaboration offer, that way of thinking will likely make little sense to you. You may even have a deep desire to stand up in a team meeting and proclaim "We hold these truths to be self-evident, that ALL Agile tenets are created good!" But you have to understand that some people are just not wired that way. Agile is a culture and a mindset, based on the Principles and Values of the Agile Manifesto. If your Product Owner or team members don't share those principles and values, you'll have a difficult time debating the merits. Remember, all the logical arguments in the world about how user stories are better won't matter to them. We're talking about perception of security here, and possibly even emotion, so it becomes subjective rather than objective.

So how do I make the move?
It's far more difficult to get people to remove detail from requirements than to add it. When faced with stiff opposition on this front, try putting the requirements through the same processes and rigor you would use to declare a user story to be "sprint ready":

• Engage the team in backlog grooming on those requirements. This will get the conversation between the team and business started sooner, and can open their eyes to the magic of collaboration in discovering that they need less detail spelled out in advance than they previously thought.
  
• Ensure that the 5 W's are present and clear in every requirement, and that the "How to" is not.
  
• Require every requirement to pass the INVEST acronym test: Independent, Negotiable, Valuable, Estimable, Sized appropriately, and Testable.
  
• Make sure also that each requirement has well formed "acceptance criteria" – just a few (maybe 2-5) clearly stated criteria, expressed again in language any user can understand – that tell us when the requirement is met. It gives you a clear script to demo against in the demo at the end of the iteration.
  
• The other extensive details can be covered in test cases, and their pass/fail can be reported succinctly in the final demo rather than walking through each flow in an all-day meeting.
  

Taking these steps to start with can start you down the path of transformation, give you some essential benefits of user stories, and overcome the objection of "working without a net." As always, I welcome your comments.

Sometimes, It's the Little Things...

Sometimes, it's the little things that make all the difference in the world for people...like the person that buys a $30k car just because they like where the cup holders are placed. Yes, I laughed at that too, but I've actually seen that happen.

Clients are people too, and I like to look for opportunities to provide a "better than expected value" for them. By that I mean, not just confining ourselves to what the SOW says we're to deliver, but other opportunities to deliver added value...whether it be handling little ancillary issues for them from a project management standpoint, or some helpful little documentation, or just a quick interpersonal check-in.

One way I go about this is I routinely (maybe daily) ask the stakeholder(s) "How can I help you? Is there anything I can do for you?" But you have to really mean it...come at it from a personal approach. The way I look at it, if it's something that lies outside of my realm of job duties, but isn't anything much to do, and helps them...it's worth a lot more in client relations in the long run than the few minutes it may take me to do. Maybe it's scheduling a meeting for them that they were going to schedule, but we're both attending, so I’ll do it. Sometimes, a client may be just overwhelmed with their workload and really flustered, and while there may not be anything I can do for them at the moment to lessen it, they appreciate just being asked. They like to know that someone just cares as a person. (NOTE: If you’re just not that kind of person, don’t attempt this. Being disingenuous with this is worse than not doing it at all)

Another way I've been doing this, as I alluded to, is supporting documentation. I’m talking about little “extras” that help the client, and might be something we would find useful ourselves anyway. By that I mean, we're not burning cycles producing some frivolous document just to provide that "added value" (i.e. make work), but something that they can actually use, but aren’t expecting...think Lean, and the categories of Value-Added, not Value-Added but Necessary, and Waste. Avoid the Waste.

Recently, I worked on a solo project for a client. There was a basic process logic flow that was an early deliverable, but there was one extra request from the client to annotate it. The annotation wasn't in the strict SOW, but I did it and in addition, color-coded the map by processing module to make it even easier to follow. As a result, It proved to be a valuable tool to for the client to easily communicate the logic of the application to both business stakeholders and technical staff. And while a lightweight technical manual was in the deliverable, I added details that weren't defined...such as including that diagram, writing detailed install instructions, etc. Again, these weren't strictly required, but were just something I wanted to include to make things a little easier, a little nicer for my client. And they appreciated it, which is what really made it all worthwhile.

Like I said, sometimes it can be those little details that really make the difference.

Microsoft’s new SDL Perpetuates Some Misconceptions of Agile

Recently, Microsoft published its updated Security Development Lifecycle (SDL), version 4.1a. It includes provisions for incorporating security tasks into Agile development, so naturally I was interested to read it. While on balance I understand what Microsoft is trying to do with this effort, I found a few misconceptions and knocks on Agile that I felt were unfair and disconcerting.
The chief misconception of Agile that I see perpetuated in this document is that Agile releases after every sprint (iteration). While this is possible, it is not necessarily the case and certainly not required by the framework.

On p. 47, in the section on “Melding the Agile and SDL Worlds,” the authors make the statement:

“With Agile release cycles taking as little as one week, there simply isn’t enough time for teams to complete all of the SDL requirements for every release.”

There are two issues with this statement, and similar statements throughout the document. First, the statement assumes a release after each sprint. Agile focuses on producing potentially releasable product in every sprint – and this is an important distinction. As you use Agile in your organization, if you don’t need to release after a one-week sprint, then don’t release. There’s no rule that says you must. Second, the statement seemingly knocks Agile for having sprints (they say “release cycles”) that are ‘too short’ to accomplish all the necessary tasks for SDL requirements. Again, there is no hard and fast rule here for Agile, other than the strong suggestion (call it a rule if you want) that sprints should be time-boxed to 30 calendar days maximum and that sprints stay the same length for consistency. But a team and Product Owner can choose a sprint length that is appropriate for their development model and business needs…if a team is choosing one-week sprints but can’t fit in security tasks deemed necessary, then the sprint timeframe needs to be lengthened.

There were also a few statements with respect to Agile and security in general with which I took exception. In the Introduction on p. 47, the authors make these statements:

“Historically, security has not been given the attention it needs when developing software with Agile methods.”

“There is a perception today that Agile methods do not create secure code, and, on further analysis, the perception is reality. There is very little “secure Agile” expertise available in the market today.”

The problem here is that the authors blame Agile methods for this shortcoming (real or perceived), and not the implementation of those methods, or rather the prioritization of the requirements or user stories undertaken in those Agile methods. If security requirements aren’t being given the attention they need, that’s flat out a failure of prioritization of the requirements by the Product Owner, not a failure of the methodology. You could conduct a sprint consisting entirely of security-related requirements, if those are the top priority, and that would be perfectly valid. Also, the very notion that there is little “secure Agile” expertise in the market is a logical fallacy called a “Complex Question”: unrelated points conjoined as a single proposition. In other words, there’s no such animal as “secure Agile.” There’s Agile. Security is but one consideration among others that can, and should, drive the prioritization of a product backlog.

I then came across this little gem of a paragraph on p. 50 of the document:

“Although SDL-Agile was designed for teams with short release cycles, teams with longer release cycles are still eligible to use the SDL-Agile process. However, they may find that they are actually performing more security work (emphasis added) than if they had used the classic, waterfall-based SDL. Requirements that a team only needs to complete once in classic SDL may need to be met five or six (or more) times in SDL-Agile over the course of a long project. However, this is not necessarily a bad thing and may help the team to create a more secure product.”

This smells to me like the framers of Microsoft SDL-Agile decided that there were certain security requirements that needed to be performed every sprint without consideration of the release schedule of the product. And, in fact, they seem to admit to as much in the preceding paragraph. This is all well and good, I suppose, if you’re OK with doing five or six times the required work for a release as you could otherwise do. But if that’s so, why would one ever choose to do that?

I’d like to offer a couple of options for the SDL-Agile folks to consider. First, remember that Agile doesn’t require you to release after each sprint, only that you produce potentially releasable product.  Second, consider using a “Release Sprint”: a sprint of those activities required before a release that may not be required in each development sprint. This could contain security-based stories as well as other typical release-related activities like, perhaps, user acceptance testing or compliance reviews. But my overarching advice to them, and to you, is to not let misconceptions of Agile hamper your implementation of it. Instead, just understand and respect the basic framework, and look for opportunities to apply the framework, principles, and culture of Agile within your organization. Do those things and I suspect that you’ll be pleased with the results.

As always, I welcome your comments.

Running Agile With Manual Testing Part 2: Feeding the Queue

A few weeks ago, I told you about how to practice Agile with an all-manual test harness. Now I'd like to give you some additional principles to keep in mind that will help you in this challenging scenario (and come in handy as good practices even with test automation).

A key notion to focus on in this situation is keeping a flow going at a steady pace, and getting stories through to QA testing early on in the process.

(Note: I'm adapting some of these principles from research work done on the construction of the Empire State Building by Mary and Tom Poppendieck for their new book, Leading Lean Software Development: Results Are Not the Point):

1.   Get ONE to Done:
Focus the team on one user story at a time and moving it to QA testing as soon as possible. So if you have four developers on your team, instead of having them work on four separate stories and moving all four towards QA testing at a relatively equal pace (which could get you four stories ready for QA testing at the same time and create a logjam), have them team pair up, split up tasks and get two stories, or even better just one, moving to QA. Think of automotive assembly lines, but instead of each developer building their own car, the team works on one car at a time, together, to get it complete before moving on to the next car.

2.   Feed the Queue Logically:
Be sure to consult the QA testers regarding the logic of testing order for the stories in the sprint. In Sprint Planning and in the daily Standup, be sure to ask the question “which of these stories make sense to test together, or in a certain order?” It sounds like an obvious point, but if you don’t ask the question, it could be missed. Then take this into consideration in prioritizing the stories in-sprint.

3.   Prioritize by Size:
We always want to work first on the stories with the highest priority per the Product Backlog. But within a sprint, IF the relative priorities of two stories are close and there's little danger of being stopped mid-sprint, and all else being equal, focus on the largest story first. There's generally (though not always) a direct relationship between the amount of development work for a story and the amount of testing required. There's usually also more unknowns, more issues, that can crop up on a larger story than a smaller one. By putting these stories into your testers' hands sooner, you give them more time to test and uncover these issues, and therefore give your developers more time to address the issues, during the sprint.

Just to illustrate the point, let's say you have five user stories in a sprint, A - E (by priority), as illustrated in the first graph below. I've applied a rule of thumb of 25% of development time required for QA. IF all else is equal, and you have the leeway to do so, prioritizing the stories by size (as illustrated in the second graph) results in a cycle of steadily decreasing testing time required for each story flowed to testers by developers:

(click to enlarge)

Also, by leaving the smaller stories to the end (the ones requiring less testing as well, per the rule of thumb), you accomplish several things. First, you lessen the lag time between when your developers complete their work and the end of the sprint. This keeps the developers from potentially “sitting around” at the end of a sprint. Also, you make it easier for QA testers to turn around testing successfully in the limited time at the end of a sprint because the testing required on those final stories should be less.

Keeping these simple guidelines in mind should help keep your sprint queue humming along like an assembly line, and make it that much easier to practice Agile with manual testing.

As always, I welcome your comments.

Common Sense Guidelines to Creating Speedy Mobile Web Applications

In the current story line on the HBO series "Curb Your Enthusiasm", "Seinfeld" creator Larry David is producing a "Seinfeld" reunion show. In the story line, George Costanza has a brilliant idea for the "iToilet," an iPhone app that directs you to the closest acceptable public toilet anywhere in the world. In preparing to write this blog, I could think of no better example for a mobile application in which speed would be critical.

OK, so it's a fictional humorous example, but the fact of the matter is that mobile web content has grown far beyond simple text messaging. Looking around the train on my daily commute, it's odd to look at the people using laptops for web surfing, instead of mobile devices, and think of them as "old school." But mobile devices have made the leap to the primary information channel for millions of people worldwide. With the level of reliance that there is on all that rich content, it's critically important that your mobile applications focus on speed. And to do that, it helps to think lean.

Here are some basic, common sense guidelines to consider in designing mobile applications for speed:

1. Limit white space: It sounds simple enough, and it can be. Content files that are smaller in size will transmit faster, and removing extra white space in content is a quick way to slim down the content.
   
2. Watch out for the Cookie Monster: Cookies are a standard method for storing identifying data on the client to personalize the user experience on a site. Cookies present a dual problem in mobile web applications, however. For one, every server request contains the cookie information and thus results in extra overhead in the traffic, reducing performance. Also, many mobile devices don't accept cookies, so you can't rely on support for them across mobile devices. One answer for this is the new HTML5 and its support for DOM storage. (NOTE: the acronym here does not stand for "Document Object Model"). DOM storage offers some key advantages over cookies for mobile web applications; chief among them in terms of speed is that DOM data is not transmitted to the web server with every request. This reduces the additional traffic and increases speed. In addition, you can store much more data in DOM storage (5MB-10MB depending on the browser) than in a cookie. And unlike cookies, servers cannot access DOM storage at will; traffic flow and access in both directions is controlled by the client.
3. Minimize the detours: Redirects (sending a user to another server to pull in additional information) can be flat-out brutal in mobile web applications. When rendering a page, having a redirect between the client and the HTML file will cause delays in downloading the page and rendering elements until the HTML document has arrived. Some redirects may be necessary, for example, in account authentication, but other redirects can happen unintentionally and you should be vigilantly watching for these cases. Some examples to avoid:
   
   1. Missing Trailing Slash – Failing to have a trailing slash in a URL will cause an unintentional redirect to the directory, assuming the URL ends with a directory name. For instance, http://mywebsite.com/somedir will cause a redirect to http://mywebsite.com/somedir/.
      
   2. Conditional Redirects – This is redirecting a user based on certain conditions (browser used, etc.) to a different section of a website, or a different site altogether. It's easier to develop in this manner, but again, it adds overhead and time for the user to wait. 
4. Pack before you move: This is a general guideline to minimize network traffic by reducing round trips, and includes practices such as:
   
   1. Batching data requests to send in a single batch
      
   2. Combining static images into a single image by utilizing sprites. This is useful for images that don't often change.
      
   3. Cache Ajax data – caching this data wherever possible will reduce the response time a user might have to otherwise endure waiting for that asynchronous data request to roundtrip over the mobile network.
      

The above are just a couple of examples of common sense approaches to optimizing your mobile web applications for speed. Just keep focusing on the notion that leaner is faster.


As always, I welcome your comments.

How to Run Agile with Manual Testing

Contrary to popular belief, you can run Agile with an all-manual testing harness. I’m doing it now, and I’ll tell you how it works.

In Scrum (my particular flavor of Agile), we promise to deliver releasable product at the end of every Sprint (iteration). The software is considered potentially releasable based on the Team and Product Owner’s definition of “Done.” Definitions of “Done” vary greatly from team to team and project to project. At a high level, however, “Done” typically includes similar basic elements. 


Here is a typical basic definition of “Done”:

1.       Code completed

2.       Peer code review completed

3.       Unit tests completed

4.       System tests completed

5.       Requirements documentation updated

6.       Integration tested

7.       Regression tested

Agile devotees like me will tell you that automated testing at all stages is a true key to high throughput, or velocity, on a team. When a team is developing in a four week Sprint utilizing unit tests written into the code, scriptable QA testing tools that automate regression testing, and a Continuous Integration Server that runs a build (and thus runs the unit tests) on each check-in, the amount of releasable product that can be built in a Sprint can be really impressive. Some people advise that some or most of these elements are required in an Agile adoption. However, when your team has few or even none of these automated test harness components, and procurement details put the acquiring of the necessary software and hardware beyond the foreseeable horizon, why let that stop you from adopting Agile?

The key time crunch in the cycle, as is always the case with testing, comes at the end. You want developers to be fully engaged and working, but if they were to develop through the entire four week Sprint, there would be no time left for QA to do manual Integration and Regression testing, which has to wait until all the code is completed. If you want to give the testers a full week, let’s say, to complete these tests, you might have your developers stop developing three weeks into the Sprint to give QA that fourth week. But having idle developers will rightfully cause issues with management in short order.

In Scrum, you have additional set meetings every Sprint. The Sprint review (final demo of product developed during the Sprint) can run several hours. The same is true for the Sprint Retrospective (a process retrospective around what went well, what didn’t, and what processes we want to change for the next Sprint). Sprint Planning for the next Sprint (choosing items from the Product Backlog for the next Sprint, and breaking them into development tasks) can take up an entire day. Throw in a Product Backlog Grooming meeting (fleshing out requirements further down the Product Backlog, slated for a future Sprint, and put preliminary estimates to them), and you have most of a week taken up in necessary meetings for the development team. Try to run a Sprint every four weeks, with the last day of one Sprint butted right up against the first day of the next Sprint, and you’ll find yourself cutting significantly into development time to have these meetings, or shorting the meetings themselves. Either way, you’re headed for disaster.

One way that I use to overcome these constraints is running a five week QA Sprint overlapping a four week development Sprint plus a planning week. That planning week between development Sprints is the time for QA to complete Integration and Regression testing while the development team participates in the planning meetings and conducts analysis to flesh out the Product Backlog. The developers are available to address issues encountered in QA’s testing if need be, without taking away from their development for the next Sprint. A typical schedule with duties might look like this:

(click the image to enlarge)

Week 1 (Sprint 1): Developers begin coding/unit testing, QA begins developing system test scripts
Week 2 (Sprint 1): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 3 (Sprint 1): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 4 (Sprint 1): Developers release code to system testing/code/unit test, QA system testing/complete Integration/Regression scripts
Week 5: PLANNING WEEK. Sprint Review/Retrospective meetings, Product Backlog Grooming meeting, Sprint 2 Planning; QA Regression/Integration testing
Week 6 (Sprint 2): Developers begin coding/unit testing, QA begins developing system test scripts
Week 7 (Sprint 2): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 8 (Sprint 2): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 9 (Sprint 2): Developers release code to system testing/code/unit test, QA system testing/complete Integration/Regression scripts
Week 10: PLANNING WEEK. Sprint Review/Retrospective meetings, Product Backlog Grooming meeting, Sprint 3 Planning; QA Regression/Integration testing

Combine this strategy with a “Release Sprint”, where you’ll conduct those activities more appropriate to a production release, such as User Acceptance Testing, a full end-to-end regression test, and any other reviews or activities more appropriate to a release cycle than a development Sprint. Overlay the release iteration on top of another development Sprint, if appropriate, to keep your team developing new features. Plan a lighter workload for that Sprint so that you have bandwidth available to address issues found in, say, UAT, as a top priority. If release testing goes well and the team finds itself with available bandwidth towards the end of that Sprint, pull in additional items off the Product Backlog to fill the Sprint.

As I say, this is one way to implement Agile in an all-manual testing universe. I’d be interested to hear your experiences with similar challenges. As always, I welcome your comments.