Why is your team doing Scrum? Check the appropriate box below.

Somebody's boss someplace said we have to do Agile now.
Agile sounded like a good thing to have on my resume.
Our software has problems and Agile is the magic bullet solution.
Our team wants to get better at quality software delivery and estimation.

Those of you who chose the last option, keep reading. Everyone else, please click HERE.

We do Scrum because the process yields better results. We do it because we want people to think and be empowered as a team, rather than just being told what to do. We want our software to please our customers. We want to please our customers regularly and often. We want to be able to respond to changes in direction, changes in requirements, or just change in general - in a positive way and continue to deliver useful software. We like the notion of teamwork and collective ownership. We like collaboration. We like to get feedback often, and integrate it into our process so we get better, faster. We measure our success and progress only in terms of delivered, working software.

Scrum is more than a process for managing projects, it is a change in mindset. Just deciding to do mini-waterfalls in 4-week cycles isn't Scrum. And it isn't very useful or productive either. [BTW just so we're clear: A mini-waterfall looks like a 4-week "sprint" where the first week is design and specification generation, two weeks are coding, and the last week is testing and bug fixing.]

It takes a mind shift to a willingness to be a TEAM rather than just a bunch of people working on the same project. There IS a difference. Without an attitude of cooperation and collaboration, Scrum will not succeed (nor will any approach really), and Scrum will just seem to be an additional burden to those forced into it.

Don't mandate that your team adopt Scrum. Explain to them why it's better. (At this point I should probably mention that YOU should understand why it's better...) Convince them. If they aren't convinced, keep at it until they are. If they are skeptical, that's OK but they need to be open-minded enough to actually try it for a while. If they aren't truly open-minded, or can't be convinced - DON'T DO SCRUM. This kind of a process needs to have WILLING participants that are cooperative. It's not for everyone. Be prepared for the fact that some people just don't get it, or WON'T get it. They really need to find a different team to work on. Don't burden those on a Scrum team with members who don't want to be there.

Scrum is not a silver bullet. It's not always the answer, but it is ONE answer. Educate your team. Be supportive, and explain why the tenets of the Agile Manifesto and the twelve principles behind it are a good idea and that they can really work in your organization.

More advice. Have a Scrum master. This person should be trained in the role and understand it. Have a true Product Owner (NOT the Scrum master by the way) who represents [ALL] of the stakeholders. Make sure they really do identify and represent the real stakeholders, and have the authority to prioritize. Hire a Scrum consultant, or bring in an experienced person who has helped teams get up to speed on Scrum - and LISTEN TO THEM. Don't pick and choose which pieces of Scrum you like at first, just do them all "by the book." You can fine-tune your process in response to sprint retrospectives later.

Scrum can be a great way to develop software, or it can feel like a horrible burden. It all depends on the attitude and openness of the team doing the process. Make sure you make your experience the former instead of the latter.

The UW Extension for Professional Development and Continuing Education now has a Certificate Program in Agile Development. It's being taught by some guys I used to work with first-hand, so I happen to know they are all pretty good at Agile Development. They are certainly highly qualified, and this certification course is a good opportunity for those folks who may not be as familiar with Agile principles to get some good instruction on how to do it well. Be sure to apply now, as this course is likely to fill fast.

Our scrum master on the team I am working with has advocated a mid-sprint checkpoint meeting, to see how things are going, and take a progress pulse. I said this sounded a bit like  to me, but that didn't go over very well. I left it at that, but was just thinking about it some more. Why would we need a mid-sprint checkpoint meeting? The burn down chart clearly shows our progress on the sprint, trend lines are good, and everyone is reporting progress and no impediments in stand-up every day. Another meeting? Sounds counter-productive to me, just to see where we are - when we should all know where we are. There are now even have a couple new wide screen monitors displaying 4 rotating web pages, used as information radiators for the team. Everything seems to be good, and going by the book for scrum, so just little things like this that remind me of my Microsoft days cause me to take pause and say hmmm.....

Perhaps a 3 week sprint is too long if we need a mid-sprint review. See the prior article for more information on sprint lengths...

Ask a question like this, and you're likely to get a numberline as an answer...

"two weeks"
"three weeks"
"four weeks"
"one week"
"15 calendar days"
or, in general, n+1 answers for every n people asked.

Which is the correct answer for my team?

Turns out that it's all. Or none. Or one of these. Or sometimes two.. There are a variety of factors that can help determine what the "right" length of a sprint is for your team. And, it does vary by team. Some organizations have one team on a two-week cycle, and another team on a 4-week cycle. They coincide, so deliverables can be coordinated, and intra-team dependencies can be predicted. Other teams swear that the original proposed Scrum cycle should be 4 weeks, and that's that. Most teams are open to doing what works. However I have seen organizations prescribe to the team how long their delivery cycle should be, for one reason or another. This dictated timeframe seems to be a bit less effective than getting the team to decide. Also, larger teams tend to have more problems with estimation, as do very small teams. More than 7 or less than 4 on a Scrum team seem to be the limits for most effective delivery, in my experience.

Now then, there are certainly pro's and con's for each of the cycle lengths. A longer cycle means more stories can be included, but that the feedback cycle of estimation vs. delivery is longer and thus not as able to hone in on velocity. Too short a cycle sometimes feels like thrashing, and that not enough complete, thin slices of end-to-end functionality can be accomplished. Remember at all times, that a completed "done done done" story is "potentially shippable."

The truly completed "done done done" story is rare in my experience as an actual shippable unit, but that's an article of its own on how to pick and adhere to DONE criteria.

Let me discuss the merits and drawbacks of each of the cycle lengths above. For the sake of discussion, I will assume a Scrum team of 7, 4 developers, 2 testers, and a project manager. I personally have tried each and every one of these iteration lengths, so I do have the perspective of experience (on a small team). Your mileage of course may vary...

Two Week Cycle
This cycle length has been in my experience the sweet spot for a small, experienced Scrum team. It is just big enough to get "real work" done each iteration, and small enough that the feedback on estimation is frequent enough to get closer on story estimation and velocity determination. I have also found that this relatively short cycle is good for preventing "hijacking" of a sprint by one or more stakeholders, management, or others that work outside the Scrum framework. Almost always, a sprint in progress can be completed even in the face of changing requirements, or stakeholder directions. "We can start that the end of this week" or at the latest "the end of next week" is almost always a fine response to these winds of change. The time spent planning and demonstrating (meetings in general) is a good middle ground, and payback for this time spent is usually pretty good. The typical planning meeting is 4 hours, first thing Monday, and the demo is 1 hour, and the retrospective 1 hour, at the end of the day the second Friday. I am a big fan of sprints that start on Monday and end on Friday, rather than the middle of the week. Mid-week sprint endings sometimes allow for "between sprints" time which I don't tend to like, as the things getting done aren't accounted for in the velocity of either the prior or following sprint.

Three Week Cycle
Three weeks is a good compromise between those who want faster, and those who want bigger chunks of work done. However, I am still of the opinion that for most teams, there is too much wiggle room in 15 business days. Sometimes estimates are padded. Sometimes people end up working on things not on the backlog. Estimates tend to be farther off, because there is a perception that there is more time available to get things done. For a disciplined, experienced Scrum team that has worked at least 4 sprints together, this might be a very workable option. Provided that the organization plays by the Scrum rules, that the team keeps estimates to realistic values, and that the team is truly able to break down stories into small tasks.

Four Week Cycle
Most of the 4-week teams I have seen have ended up going back to a mini-waterfall approach. The first week tends to be design and investigation stories and tasks, a couple weeks of cranking out code, and the last week of testing, finding and fixing bugs. Not that it has to be that way, but that has been what I have most commonly seen. I think the reasoning was that the teams perhaps were not as experienced with Scrum, and the number of days left a perception that there was a lot of time to do things "the old way." Also, I have seen sprints hijacked by various issues and people, and totally taken sideways due to the length of the time. Feedback loop is much more difficult to perceive for most of the team, and as such, estimation may not just stay the same, it may get worse. Tasks tend to be lumped into large blocks of 15 hours, 20 hours, or more. A typical task on an experienced team with good estimation is not often over 4 hours, and never over 10 hours. These teams tend to be able to peg the stories for story points more accurately, and are able to deliver the stories as complete. This iteration length doesn't seem to work well, in my experience.

One Week Cycle
"How can you expect us to get anything of business value done in just one week? Especially given the Done criteria for potentially shippable?"
I think that's what I said anyway. My team was on a 2 week cycle, but we didn't have much experience with Scrum at the time. We were having lots of issues trying to break stories down into tasks. I recall several 40, 30, and other double-digit task estimates. They were just too big. We couldn't figure out how to break them down further. Planning sessions were a nightmare, lots of arguments about task breakdowns, and estimates. Fortunately we had an agile coach who suggested that we ratchet the iteration down to a 1-week period. At first, this seemed totally counter-intuitive to us. Shorter iterations? Wouldn't that make it even harder to break down tasks? As it turned out, that wasn't the case. We had to break our stories up from the epic stories we were using to actual user stories that delivered an increment of functionality that had business value. That was just the thing we needed to figure out what we couldn't do in the 2 week cycle. We tried one-week iterations for several weeks, and got a lot better at breaking stories and tasks down into smaller pieces. We as a team decided then that it was too much overhead to have a planning meeting, a retrospective, and a demo every single week. The stakeholders didn't really understand, and what we were demonstrating was such a small increment that they were starting to think that the project was just dragging out in delivering small pieces. The two week cycle was a good return on the time spent planning and demonstrating, vs. the time spent actually delivering work.

In the end, it should be up to the team to figure out what works best for them - given some input from the corporate culture and stakeholders. New teams just starting out with Scrum should perhaps plan to try first two sprints each of 2 weeks, then two for 3 weeks, and compare results. By the end of the 4th sprint, the team should have some reasonable idea of what would yield the greatest velocity. If there isn't a choice for iteration length and it's prescribed, you'll probably have to just make it work. In any case, try to avoid the con's above and see if you can get your scrum master to push back a bit on the powers that be and let the team have a bit of freedom to see what works best for all. Scrum should be a collaboration, so if at all possible, do the best you can at making sure everyone has their input represented and just hold the team accountable and let the team manage their own delivery.

Definition: Technical Debt is a term that we in the Agile world use to describe things in the code that perhaps aren't engineered as well as they could (should) be. It can refer to many things, like areas in the code that we should probably refactor to make them more readable, poorly performing code, obsolete or clunky architecture, encapsulation abstraction, or other class problems, or the like. It's debt because we know about it, we "owe" it to be done, but are focusing on other things instead.

Technical debt is the avoidance of doing work that we would otherwise do in the course of doing our best practices in engineering. It's a fact of life that most every Agile team has to deal with, in my experience. I find that there are various means of "dealing with" technical debt, some of which I will discuss below as a matter of practicality. However, I see it really as a symptom of a deeper problem. The team isn't finding good engineering as valuable as completing stories could be the underlying problem.

Teams can be pressured to deliver more than they should (this is common), and as such, could be focused on delivering the current sprint's stories rather than fixing things they find that are not as they should be. The team also could be creating more technical debt for itself by not focusing on good engineering in the first place. When junior people design things, sometimes they don't address all the points of performance and code maintainability. Trade-offs are made that can end up causing lots of rework later.

The concept of Agile software development, is heavily based on refactoring. Sometimes I find that teams use refactoring with a little "r" when they should be Refactoring. They make small internal changes, but are reluctant to change overall design, even when it is truly warranted. When we add a new feature, sometimes the design needs to change to accommodate it. THIS IS EXPECTED behavior in an Agile development process. Yet, time after time I hear developers say "well, I don't want to change all that NOW..." when that's really exactly what they should be doing. The concept of iterative development should be allowing us to ship software at the end of every cycle, and we really can't consider the software shippable if it has these poor designs still left over from earlier days.

Refactoring the design shouldn't be catastrophic though. But, there is always some impact that is almost always fundamentally left out when planning. Imagine we have an apple, and we need to add some cherries to it in this sprint. We might just smash the cherries on the outside of it, and call it good. But that would leave us a lumpy ugly mess... Rather, we might take another approach, and put the apple and the cherries all in a blender, and pour the mix into a new shape mold and freeze it. The new shape will be smooth and round, yet it will encompass the new features of having both apple and cherry flavors. It's a dumb example, but you get the idea. Refactoring can take many forms.

Handling Technical Debt
Now, I have been on a few Agile teams and I am a realist. Technical debt is most certainly here to stay. We just aren't in an ideal world, and we can't always take the time we really need to make sure that the iteration's deliverable is as pristine as it should be. So, now how can we handle this debt in a practical way?

Here are some ways I have seen teams deal with Technical Debt:

1. Ignore it.
   1. This don't work so good, in my opinion, but yes I have actually seen it done. It works, so we'll use it as-is.
2. TODO it.
   1. //TODO in the code is a flag that there is something more that needs attention. Also, //FIXFIX and //BUGBUG are others I have seen. Some of the tools give us mechanisms to flag these as work items, but in my practical experience this is just about the same as #1. Nobody ever gets back to these things to fix them. They just lose visibility and get buried. Not very effective in my book.
      
3. Backlog it.
   1. Create a backlog item called Technical Debt. Each instance where something needs attention is recorded as a task for this story. They can be estimated, and prioritized. Backlog items have visibility, so they don't get lost. Here is the problem - Technical debt now CAN be prioritized. And, it usually is - right to the bottom of the list. This really doesn't solve the issue either, unless you have a product owner who is savvy enough to know that good engineering means happier customers, developer, and management in the long run.
      
4. Bug it.
   1. Log a bug for each Technical Debt item discovered. This is probably the most effective means I have yet seen for the actual reduction or elimination of technical debt. In reality, I think this is the most appropriate. The new story requires changes that just haven't been made. It's not really "done" until this is taken care of. Ongoing maintenance of code should have an appropriate stakeholder with a voice in the Product Owner's scope of attention.
      
5. Job-Jar it.
   1. Put it into the bucket of things that need to be done but aren't on either the sprint or product backlogs. I think this is marginally effective, because nobody should technically ever have time to get to this stuff, they really should be pulling things off the product backlog onto the sprint backlog. But, I thought I'd mention this concept since someone brought it up.

Are there other ways to deal with Technical Debt? What ways have you had success? Please leave me a comment and let me know.

How do you handle bugs? There are many ways organizations handle bugs in software. I have what I think is a very workable approach, see if you agree.

The environment: The team is a dozen software developers and testers (total) and the project is run as a Scrum project. Iterations are 3 weeks.

Scenario 1:
QA is testing the build, and there is a bug discovered. The date/time field data that's entered in local time is stored in UTC, but the data comes back as UTC (not local) when retrieved.

1. QA logs a bug. Priority 2 Severity 2
2. Bug is assigned to the Product Owner for the team.
3. PO looks at the bug, and makes the call that the currently signed-off stories are more important than this bug.
4. The bug is estimated in story points by the team as 2 points.
   
5. The bug is put on the product backlog, prioritized along with the other bugs and stories.
6. The team can't "ship" the sprint's release with this bug outstanding, but the PO knows that they aren't planning a release for another two sprints anyway.

Scenario 2:
QA is testing the build and discovers that if a name is entered that is longer than 50 characters, the site crashes with an unhandled exception.

1. QA logs a bug, Priority 1 Severity 1
2. Bug is assigned to the Product Owner for the team.
3. PO knows that this bug is serious enough to warrant being fixed right away.
4. PO meets with the team, and the bug is estimated at 5 story points.
5. The team's velocity last sprint was 80, and they have committed to 78 points for this sprint. The team left only 2 points "spare" and didn't allocate time for bug fixes.
   
6. PO suggests that the bug be fixed this sprint, but the team does not feel they will have time enough to do that along with the other stories.
7. PO removes the lowest priority story from the sprint backlog, and replaces it with the bug instead.
8. The story goes back on the product backlog as the top story in priority.

There are also other permutations that may work in different organizations:

1. Abort the sprint, and replan a new sprint including the bug fix.
2. Allocate some time and time-box it just like a spike. The team may not be interested in working overtime, but try to negotiate it anyway. Most teams will want to fix bugs like this even if it means they work a few extra hours. Buy pizza.

The current team I am on doesn't follow these guidelines, and they insist that every single bug be fixed for every sprint, or the story can't be accepted as done. While I think this is a lofty goal, in my experience it just isn't practical. Maybe it's my old school days at Microsoft where "done" meant it was "code complete" but not "bug free." I think that Scrum gives us the ability to continue the current sprint and continue to develop the features as committed, and delay bug fixes until the next sprint. The only time when this doesn't work is the case where this sprint's story delivery is scheduled to be the release. And even in that case, most organizations allow a small window for last-minute fixes which could be used to take care of the bug.

If the developers are doing TDD, they won't be writing bugs in the first place... I see more than a handful of bugs per sprint at a clear process smell. In that case, the process should be evaluated to see why the bugs are being created in the first place. Is it unclear story descriptions? or more likely, is it a lack of testing in the functional, integration, and acceptance areas? Any way it goes, bugs seem to be a symptom, not the actual problem. Every bug I have written myself was due to a lack of a test for that area. Find a bug, write a test! Please make sure that your developers realize that when they estimate fixing bugs, that it should always include writing tests that first fail when the bug is present, then pass when the bug is corrected. Bugs should not be able to be resolved without at least a unit test to illustrate that they are really fixed.

Handling bugs can complicate a project manager's life, so if they are cropping up, be sure to address the root cause, and all will be happier.

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word "but" when answering the question "Do you do SCRUM?"


You wouldn't want your surgeon to follow just *SOME* of the steps in that procedure you're getting, would you?

SCRUM works great, if you can just follow the (whole) program. It's not surprising how many organizations say they have failed using SCRUM, when they have only picked and choosen a few of the aspects to implement.
For those of you who need a 12-step program... and you know who you are...


1. Use a 2-week or 4-week sprint. 2-week preferred
2. Appoint a scrummaster who will hold the team accountable, AND also keep the wolves at bay.
3. Make sure the entire team is jointly accountable for the success of the project.
4. Have a prioritized product backlog ready before the sprint. This can include both bugs and features
5. Have a REAL planning meeting where the team commits to stories and they are thoughtfully tasked out and estimated.
6. Team members commit to stories, and then break them down into tiny pieces (tasks). If any estimates are over 4 hours, break them down further.
7. Do a daily stand-up. What did you do, what are you going to do, and what's blocking.
8. Don't do anything that's not estimated and in the sprint backlog.
9. Establish, post, and meet DONE criteria. It's only real if it's posted and visible to everyone.
10. Post a sprint backlog task burn-down chart and update it daily.
11. Keep the product owner in the loop at all times.
12. Hold a stakeholder review a the end of the sprint - this is the fun part!
(13) Then, have a retrospective meeting to discus what went well, what could use improvement, and action items.

That's SCRUM!
Now, you'll never have to be a SCRUMBUT again!

Once upon a time, there was an Agile team that was working on stories in a sprint. The team was going on fine, until the product owner decided it was time for him to go on a month long vacation (and then leave the company).

Life Goes On
So, being a good scrum master, the SM appoints a new PO to make decisions on the specifics of the stories that were already in progress (and some finished). The new PO was a pretty sharp fellow, but he didn't have any background for the feature, so he was a might confused. But, the team had fairly good direction on the feature, so they persevered and completed the tasks as they understood them.

The Shadows
Now then, from lurking in the dark shadows, there emerged the original PO's Boss. The Boss of course looks at the feature nearly complete, and decides that there were a couple minor tweaks here or there - hey, he's the boss - he can do that. No worries, the changes were slight, and easy. Done deal. All the stories were completed, as well as the automated acceptance tests that verified the now-completed tweaks, as well as the remaining story criteria. All the words had been blessed by the Documentation folk, the UI had been blessed by the User Experience folk (this was the Second iteration of the UI design also BTW).

Demo Day
At the end of the sprint, we all get together with the interested stakeholders in a room, and review the stories, the functionality that was delivered. The managers, the development director, the project team, scrum master, and QA were all represented. Keep in mind now, that everyone has actually seen the feature at least once... "We can't have it do that..." says the boss. Well, apparently a modal dialog with OK and Cancel doesn't work the same in Boss-World as it does everywhere else. So, he fires up his argumentation engine and proceeds to corner the entire meeting with a redesign of not only the UI but also the functionality of a standard modal dialog. Nothing was up to par for the Boss, and - remember - he had seen it all demonstrated for him before...

The Outcome
None of the stories in the sprint were accepted. Sprint velocity: ZERO points. Bad day. Alcohol was required.

The Moral
The moral of this story is this: Have a Product Owner who knows what the feature does. Make sure the product owner has input from ALL the stakeholders - oh yes - in a TIMELY manner as well. Make sure your scrum master has the ability to keep lurking skeletons at bay. They can have their say in the next sprint. But at the end of the planning meeting, the stories should be pretty much fixed and everyone should understand the acceptance criteria for them. Stories shouldn't just have arbitrary criteria appended, grafted, attached, pasted, or otherwise affixed to them after the planning meeting, even by skulking lurkers.