This also means it’s my last week in Bangalore. I’ll be leaving Saturday morning to head back to San Francisco. Please ping me if you want to meet up before then. I’ve made so many great friends during my stay in India so I’m leaving with a heavy heart. Please keep in touch and let me know if you ever make it out to the bay area.

I’m looking forward to getting back home with friends, family and colleagues. See you all when I get back!

-Joe Arnold

Armed with blue painter’s tape (imported) and post-it’s (imported too) I worked with the lead developer & producer to set it up. I briefly discussed the principals that makes the system work: reduce WIP to increase throughput, use the post-it’s as a signal to begin work.

Time for team indoctrination. The lead engineer explained the system to the folks on the team.

1. The producer/product manager will queue up ‘things to do’, limited to 5
2. The developers will take the top items from the top of the queue
3. When the developers are done, they will be placed in the ‘dev done’ slot
4. Then the testers will pick up items from the ‘dev done’ slot and test them
5. When the ‘thing to do’ is done to the tester’s and producer’s/product manger’s satisfaction, it’s ready to release.

I sat back and just watched it unfold. Every few weeks I would go by and I’d stop in to see how things were going. The system was just like a machine; it was systematically pushing features & bug fixes through the team in a very transparent way. The tech lead moved to another project and the kanban system kept working. A new product manager came in and the kanban system kept working.

Ron Popeil sells a Rotisserie & BBQ Oven with the tag line, ‘Just set it and forget it!’ My Aunt ordered the machine. The first thing that you see when you open the box is (I’m paraphrasing from memory) “WARNING! While the slogan may be ‘Just set it and forget it!’ it doesn’t mean you can leave the machine unattended at any time. As with any kitchen appliance involving high temperatures, you must take caution.”

This team, did not literally ’set it and forget it’. But it was a system that worked very for them with few modifications. They were largely in maintenance mode and were tasked with fixing bugs, making performance improvements, fixing production issues and making incremental improvements.

Daniel Burka - FOWD London 2008 from Future of Web Design on Vimeo.

| View | Upload your own

Velocity is a way compute how much real time it takes to complete estimated time.

So if I say something will take me 4 hours to build and it takes me two days to complete, my velocity would be 2h/day. That’s useful for future planning because the team knows my capacity (2hr x 5days = 10 estimated hours / week).

A velocity measurement doesn’t say how hard I worked or how much time I spent on the task. It’s merely a calibration tool for effective planning.

My 4 hour estimate (that took two days) from the above example might of seemed awfully optimistic. But that’s not how to see it. I could of ran into an unforeseen complexity, faced an unusually large meeting load, or could have been bogged down with operational issues. Or it might be true, I might just be an optimistic estimator, but with velocity that’s okay. It all averages out.

Teams will also come together to estimate entire features this way. They might estimate how long the feature will take in days. But again, estimated time never equals actual calendar time. So if it takes the team estimates a feature to take 1 day, and it ends up taking 2 days to complete, their velocity would be 2.5 estimated days / week.

Here’s where it gets tricky and controversial…

To get better at estimating when using velocity means getting more precise rather than accurate.

Teams who are good at estimating with velocity will normalize on an inaccurate, but precise value, rather than try to get more accurate. The consequence is that each team (or person) will have their own, unique velocity. Some teams will estimate conservatively and others will estimate optimistically. It is meaningless to compare from team to team or location to location. It just doesn’t make sense. In fact, the moment you start judging teams on ‘improving’ their velocity, their estimates just become more conservative. (Thereby increasing their velocity.)

Some teams have a difficult time using velocity. This is because when a team settles down on a velocity, they question themselves (or get questioned) if it’s not 8 hours of estimated work a day. “How come you’re only planning for 5 hours of work a day! What’s wrong?” (One of the most productive teams I’ve worked with averaged 2hr estimated / person / day!)

Use velocity, but keep in mind that a team’s velocity can’t be compared with other teams. So keep the velocity numbers within the team. If you must report your estimates externally, either take the time to explain velocity or normalize your estimates into real time. Better yet, translate your estimates into dollar (or rupee) values (talk with your finance person to work out some numbers).

Me: So tell me about the continuous integration system.

Ben: We fought it for so long… and we’ve finally given in. And it’s the greatest thing ever.

Henri: We originally thought: “We build our stuff, it works. Why do we need something so complicated?” But it’s actually really really nice. We miss it a lot when we don’t have it. When we have check-ins that don’t get built right away, we don’t know if it’s working or not… it kind of hurts.

Mark: What’s really amazing is that every time the build machine process breaks for a day, it’s always the cause of trauma. A bug gets in! You would think it was coincidence if it wasn’t so regular. [laughs]

It’s unbelievable… The one day that the build machine breaks (and say there has been five check-ins) — now we don’t know which one broke this feature! “Ahhggg! if only the build machine were here, that way we would know if it was my check in, or your check in.” Every time [the continuous build system breaks] something like that happens!

It’s just proof that, without it, we would be constantly be saying, “how the hell did this bug show up? Whose fault is this? Is this my fault? I don’t even know?”

Ben: It has saved us an incredible amount of time — much more time than we have ever put in.

Mark: It [the continuous integration system] is a lot of heartache. We will say that. It’s great. We’ll agree. Anyone should know that they have to believe that there will be this big payoff because it consumes time every week to keep it going.

Jon: We had this bizarre bug where the emoticons were appearing off to the side. They were right on the contact list after you scroll. Nobody had this except Stephanie (a product manager). So we talked about it and I looked at it. And she was able to track it down through the build machine — where it did start to happen and where it didn’t start to happen. [She narrowed it down to] between two builds. And we had this one minor check-in where we added a drop shadow to the conversation list. We were like, there is no way that this could be the problem. But, low and behold, we removed the drop shadow and the problem was completely fixed. Because we had the [build] machine, we were able to track down where this bug was.

Mark: Here’s another big thing that people don’t appreciate until you get it: It means that everyone is always using the latest build — and the latest build changes. So Stephanie goes to lunch and logs back in. She’s using the latest build. And bugs are caught really fast. And features are checked in really fast. We knew the last part (features checked in fast), but we didn’t think of the first part (using the latest build).

Stephanie might say: “Oh! I’ve got icons now!” (Or later when getting a new build) “oh… the icons are not in the right spot.” [I would follow up] “Can you go back a build?” [Therefore,] I might find out that day that I broke something.

There isn’t such thing as a broken build. Because of the automatic continuous build integration system with email announcements, no build stays broken. That’s really a big deal. There isn’t such thing as a broken build. Other than the build broke for a moment, so [therefore] somebody is going to fix it. We all know something has happened because we all get the email. We can usually see from the change list who is responsible.

Word.

In order to achieve this goal, tests demonstrate a working system and the team frequently communicates changes.

When a team starts out on CI, the first step is usually to install a tool. Usually someone is really excited about the prospect of working software all the time. He or she installs or writes a tool to help make it happen. Once it’s all up and running this happens:

All failing…

Honestly, it’s a great first step. But the kernel of a healthy continuous integration system is establishing a team protocol and discipline. The difficult part of CI isn’t the tool, it’s the practice.

An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a little bit bigger. Often, there is a release after each MMF is complete.

An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to launch on its own.

A MMF can be represented as a User Story — a short, one-sentence description.

The format of a user story is:

As a [some user],
I want [to do something],
so that [I can achieve some goal]

But in contrast to how a User Story is typically used, the team would not break down the User Story into smaller User Stories when using MMFs. Think of it this way: *Gather up all the stories that share the same so that clause — that’s your MMF*.

So does Kanban development have no planning meetings? No! The team self-organizes meetings around a single feature rather than a specific period of time.

Following Users over Directing Users
Community Ownership over Company Goals
Version 0.1 over Version 1.0
Responsive Team over Efficient Team

A reflection on how to work while developing products that are built upon user-generated content or social networks.

Following Users over Directing Users
Don’t tell users what to do. If you ever find yourself thinking, “Well, we want direct them towards , so let’s…” Remember that user’s will use the product however they’re going to use it. Follow them. Make their lives easier.

Community Ownership over Company Goals
I was once told that the myspace founders told Fox Interactive Media to f-off when they were told to put in a bunch of ads. If the community owns the site, the community will grow. Don’t kick off content because it doesn’t align with the companies immediate goals. Another way to put it is company goals follow community goals.

Version 0.1 over Version 1.0
Increment and iterate. It takes a long time to build a product that will be used. Get out fast and get feedback. Don’t hold back and wait for the product to be perfect.

Responsive Team over Efficient Team
Favor getting changes out quickly. Even for the sake of efficiency. Always keep the system in a state that can where new versions that can be launched quickly. If the team can’t launch anything but small patches because they’re slogging through a 6-month project, that’s a problem.

Agree? Disagree?

“The last thing I’d describe my work as is ‘process support,’” says Joe who at any given time, looks after seven to ten teams across multiple locations of his company. “I feel more like a camp counselor.”

StickyMinds Iterations: Keystone People

I had the opportunity to be a guest lecturer at the National Institute of Design in Bangalore, India today. I taught a session titled ‘Idea to Implementation’.

My goal was to have the students conceive, build a prototype and test a product – in essence go through the entire product ideation lifecycle.

Here was the challenge: Invent and Build an Alarm Clock

• Brainstorm
• Create a Scenario
• Build Prototype
• Test Prototype

This was an experiment for me as well. I wanted to see if we could achieve all these things in such a short period of time. How fast can you get to a nonfunctional prototype?

Brainstorming:
I introduced the rules of brainstorming and the class split into teams to get to work.

I haven’t been satisfied with the post-brainstorming activities like multi-voting, so I asked them to do more explicit sorting with a technique called ‘funneling’.

When you pour a bucket of water into a funnel, what happens? You get a single stream of water. Funneling as applied to brainstorming is used to clarify ideas at various levels of abstraction. The levels we used were ‘users’, ‘needs’ and ‘features’. At the end of the brainstorming session each team had a prioritized list of users, their needs and the features that would serve those needs.

Who are our users:
One group came up with a lot of non-auditory methods of waking someone up. They were going back and forth between building an alarm clock for a deaf person or an elderly person who was hard of hearing. They made a decision to go for the elderly. When they started thinking about their needs in this context, it led to ‘remembering’ over ‘waking up’. As a result, the features were focused around creating a mechanism for reminders throughout the day. (If you’re retired, you don’t need an alarm to wake up and go to work!)

Create a Scenario:
I asked each team to tell a story about their alarm clock in action, because a list of features isn’t sufficient to understand how this product will be used. I didn’t really care how they did this (storyboard, written narrative, acted-out skit, video, etc). Each team decided to ‘act-out’ their alarm clock in the form of a skit and the results were hilarious. Afterwards the product ideas were opened up for critique. For example, one group used water as a startling mechanism and classmates challenged the practicality of that idea.

Prototyping & Testing:
Each team built a low-fidelity prototype of their product using ‘found’ materials in the design lab. Using objects like water bottles, tape, string and paper, each team constructed their prototype. To test their newly-invented product, members of another team poked and prodded the prototype to see if they could make sense of it.

The process for testing was simple. First the team came up with a list of tasks they would ask of the user, then each member of the team picked a role to play during the usability testing. There was one person would be the ‘guide’ to set the stage, ask the user to perform tasks with their device and ask questions to understand what the user was thinking. Another person played the role of note taker. A third person manipulated the non-functioning prototype to make it come alive.

Thoughts:
From an Agile / UX / UCD perspective, I was impressed that each team was able to go from idea to prototype in such a short period of time. It makes me wonder if we shouldn’t be creating more prototypes. Teams could utilize lower-cost methods of documentation: skits vs storyboards, paper prototypes vs ‘clickable’ prototypes. Rather than doing a high-quality job with fewer ideas, what if a cross-functional team could churn out many low-quality prototype concepts? Would that shallow effort yield more knowledge than a deep-focus in one area?

Special thanks to Mamata Rao, a faculty member at the National Institute of Design for the opportunity to work with her students. What a fantastic group!

I designed a class borrowing ideas from other folks at Yahoo like Todd Hausmann, Gale Curtis, Matt Fukuda and Dan Wascovich, Kevin Cheng, Anand Nair and Anupama Kamath. I also incorporated techniques like prototype testing from Marty Cagan, and paper prototyping from Jeff Patton.

Hello Joe:
Got to your blog and an interesting first article to read.

Is it by coincidence or design that most of leading product development companies like Yahoo, Google, MSN and others like Thoughtworks etc in recent years have been Agile driven and almost none are CMMi. Is there some significant difference in the way management perceives their role, environment and market-organization dynamics?

Another factor is to have a champion for change and belief in change of his/ her so strong that it comes around.

If you had a memo to write to management thats going towards deterministic processes like company wide formal estimation methods and evaluations - what would you write?

Thanks

Product organizations (such as Yahoo, Google, MSN and others) do not concern themselves with certifying themselves at a CMMI level. Here’s why:

Certainty and traceability associated with CMMI has cost (in terms of being able to predict scope, cost and time of a project). A high CMMI-level rating, while it decreases risk, also has overhead that adds to costs. The higher the level of certainty, the higher the cost.

Product organizations manage risk differently than an internal IT shop or a IT outsourcing firm. These companies plan for failure by executing multiple options - build internally or acquire. Competition from startups and other internet companies is fierce. Time to market is critical. Persuing a CMMI level that would add any costs to product development isn’t acceptable. For example, it wouldn’t be possible for messenger.yahoo.com to catch up to meebo.com if we had CMMI controls in place. Because, guess what, meebo doesn’t either. We have to go as fast, or faster then them.

For an IT outsourcing firm it makes perfect sense to invest in a high CMMI-level rating. After all, they’re selling more than just software. They’re selling a service. And part of that service is certainty. Their customers do not want to take risks, and are willing to pay for certainty. An IT outsourcing firm passes on the costs of the overhead associated with the risk reduction. Unlike a product organization, failure carries punitive damages associated with a failed contract.

It’s also important to note that Agile & CMMI aren’t incompatible. There are many firms that use Agile development methods who certify themselves. Their customers are willing to carry the costs of certainty and tractability and still get benefit from Agile methods. Check out Jeff Sutherland’s work on the topic.

The concept of company-wide process definition is quite different then the pursuit of CMMI certification. CMMI doesn’t tell you how to reach a level of certification, it just tells you what you need to achieve the desired level. Management can do the same, articulate what the organization values and let the individual teams figure out how they can be achieved. There is a lot management can do to articulate organization needs — like minimum performance criteria, security standards or legal compliance.

In the memo to the company that was asking for standards on formal estimation methods and evaluations, I’d ask them to articulate the needs of the organization and challenge teams to find ways to meet those needs. Specifying how each team will operate may be comforting for the management team, but will just be an illusion of control. Management should set goals not dictate how to reach them.

1) Risk-taking Culture
The company has to have a environment where people are free to take risks. If people who take risks are punished, the risk takers leave. You’re left with people who do not want to take risks. People who don’t take risks won’t stick their necks out. They’ll be on the far-end of the adoption curve.

2) Leadership
This is tightly coupled with the ‘Risk-taking Culture’. The leadership must at least be willing to sponsor time and training for new methods to be used with the product development teams. They need to adopt the change themselves, but they can _even_ play a wait-and-see role by experimenting with a few teams and see how it goes.

3) Coaching
Coaching and training. Learning new product development techniques is a really big mind shift. In an Agile context everyone’s world changes. Product managers need to be communicating features a lot differently than they had before, programmers need to be accustomed to requirements changing more frequently, QA needs to create more flexible testing infrastructure, user experience experts need to adopt their methods to teams working in iterations.

4) Team structure
There are two environments where introduction of Agile methods are difficult. a) A very large team (split up into multiple, smaller teams) working on a single large product that’s under the gun to deliver on time. Change is hard to manage when a deadline is looming. b) An organization which views their people as resources to get shuffled around every other month to work on new projects. When there are not stable teams, it’s hard for any change to take root.

Wi-Fi Planet:

I—and most of our customers—believe that Airwave is simply the best solution for managing multi-vendor networks. … What customers and prospects are requesting is true multi-vendor support … It is in the context of addressing market demand that Aruba is choosing to acquire Airwave

–Dominic Orr, President and CEO of Aruba Networks

Professionally, this is a proud moment. Congratulations to business development, sales, customer support and engineering.

There is a method to Agile methods. Years of listening to customers, testing and coding works to add real value to a business.

While searching for news, I noticed a recent job posting for AirWave Wireless.

We believe that running code and short feedback loops speak louder than excessive documentation and month-long design meetings. We practice test-driven development and have a comprehensive suite of tests — over 31,000 at last count. We pair program, so you’ll learn the system quickly and have a great time doing it. We have short release cycles, which means your talents won’t sit idle working on projects that never see the light of day. Software you write today will be managing enterprise networks in just a couple of weeks. We’ve been cited as the longest running continuous XP project in the industry (six years and counting) so we have gotten quite good at embracing advantages while avoiding its pitfalls.

Personally, I enjoy working at Airwave more than any job I’ve ever had. I am excited to come into work every day, I work hard for eight hours solving challenging problems, and then go home to lead a well balanced life outside of work. When I’m at work I get to interact closely with a group that is brilliant, funny, motivated, and inspiring. I spend most of the day smiling, laughing, and learning. The team we’ve built is truly a special group, and I’m proud and honored to be a part of it.

Humm… a group of people that truly enjoy and take pride in their work. Does that reflect in the product they build? Does that impact the value they add to the company? You bet.

Hack Day is an event where programmers (and even those who can’t) come together to build cool stuff over 24 hours. Yahoo! supplies the venue, food, entertainment and the all important WiFi connection. After 24 hours every hacker gets to be in the spotlight and show off what they built.

Putting together the event was a whirlwind. So many people from Yahoo! mobilized to put the event together and we got a lot of help from the Taj Residency and Karpe Diem Entertainment.

Starting the night before, our IT staff got to work, setting up the networking gear to transform the 1st floor of the Taj Residency into a super-wifi, 20Mbs hotspot. Rock. The setup continued through the night and by morning we were ready to go.

The hackers were greeted to a huge open-space scattered with Hack Day India beanbags that they got to take home at the end of the event. Everyone was excited about that. Christian Hielmann and Shivku Ganesan from Yahoo! along with Ragu Rau from Adobe gave a few talks before the hacking started. Bradley Horowitz kicked-off the hacking.

With that, the hacking began! People quickly formed into teams and got to work. Hacking lasted through the night. Sid DJ-ed through the night, people took breaks to play the Xbox and the Wii. Caffeine spurred us on. Some of us couldn’t hang on and managed to grab a few zzs.

One thing that amazed me was the willingness that everyone had to help each other out. The people really made the event. Cheers to that!

Bradley Horowitz kicks off the Juding. I announce the judges. The first few hacks.

“The 9″, Maria Sansone, _hacks_ up the winners.

A few other posts on Hack Day India:
http://shouryalive.com/blog/winners-at-yahoo-hackday-india/
http://d.hatena.ne.jp/i_ogi/20071006/1191685755
http://srinix.wordpress.com/2007/10/09/yahoo-open-hackday-awesome-event/
http://www.infoworld.com/article/07/10/08/Yahoo-holds-Open-Hack-Day-in-India_1.html
http://www.businessweek.com/globalbiz/content/oct2007/gb20071011_261426.htm?chan=search
http://www.livemint.com/2007/10/15234610/Tuesday-Post–Hack-marathon.html
http://yodel.yahoo.com/2007/10/11/usa-hacked-europe-hacked-asia-hacked/

I got the opportunity to speak at d:Camp (Which you do by just showing up) in September.

I finally took an evening to put together a talk I had been working on with Orion Auld. We started on the talk about a year ago after I saw a Nova episode about how the Wright brothers invented flight. There were a lot of lessons to be learned! They had a very incremental, pragmatic approach to developing their planes.

Apparently people liked the talk!

dcamp unplugged, rajab

DCamp Bangalore…..Yes I was there

Sufistically Speaking

Victor said that newspapers always ship on time. He said it was a two pronged process.

#1: Everyone must be willing to do anything to get the paper out.
When there is a hurricane in Miami, everyone pitches in.

“The writer must become the editor, who must become the assistant, who must also go out on the street in an emergency situation to get the paper out. The writer versatile, the publisher versatile, everyone is versatile at every level including the executive editor to get the paper out.”

In a hurricane situation, if you’re a writer, you become a truck-driver to deliver the paper to the street corner. If the printing press is hit by the storm, you have pre-arranged mutual agreements with other printers outside of the area to do your publishing. Even in day-to-day operations, editors and writers are encouraged to visit the printing press and learn as much as they can about how it works. They encourage end-to-end knowledge about the entire system.

“Everyone has a measured responsibility when it comes to seeing the product through.” Victor said.

“They may not know exactly how the printing press works, but it’s encouraged. Every reporter, every writer, every editor will go into the press room and have the guy who is dirty with ink show them how the paper runs. When there is an emergency and the printer who is trying to get the paper out has a problem, because there is a basic understanding of the work, it augments the responsibility.”

He used an example of when the print press broke down, and an editor jumped into a car to a neighboring press to get a piece of equipment. That was only possible because the editor could understand the printer’s explanation of what was wrong and what the printer needed to fix the press.

#2: There is always more production than what gets out in the day
Every day there is a brief 15-30 minute morning meeting at 10:00 AM to plan the production for the day. That way everyone is on the same page.

There are several vetting points. Each writer has a budget (or capacity) of what the individual reporter can do. The first month that you join the paper your budget would be low. It goes up with your capacity.

There is daily, weekly and monthly planning to make sure there is enough budget to fill a paper. If there are not enough people to write enough “column inches”, they know they can’t fill the paper. Therefore, they over commit column inches as well. If Victor was writing a column, he would get a few more quotes or details to expand the article if they needed to fill space.

As applied to software:
#1: System knowledge and a willingness to do anything
We could learn a lesson. We don’t handle emergencies like a newspaper handles emergencies. If a server goes out, you can’t send in a product manager to go fix it. (Or most software engineers for that matter.) As a result we are less flexible and our capacity is reduced. Cross training is essential. Look for individuals with a wide range of talents. Train a front-end engineer on how to do usability testing. That product manager you’re hiring should have hacked up an underground mp3 exchange while in college.

I’m not suggesting that anyone can pick up each other’s tools and get to work. But there should be an understanding of what it takes to get each other’s job done. That way when a developer explains that they need to spend a couple of weeks to improve the build process, the product manager understands why.

Do whatever it takes. I hate hearing, “but I’m not a tester” or “I can’t do visual design.” Developers should become testers. Testers should become developers. Product managers should cut html.

I’ve worked with a team that builds a UI-intensive flash application. The designers, testers, developers, product managers all sit together in the same space. Developers are constantly adding functionality to the product that affects user interaction. A developer is encouraged to think about and to improve the user experience as much the underlying software that makes it run.

Even within functional groups, knowledge should be distributed. There was a team who had a developer, Li, who knew everything. Here is how a sprint planning meeting would work: Li would volunteer for every task because she was the best person for the job. As she became full, important features in the product backlog had to be skipped until something was found that another person on the team could work on. After three or so sprints of this happening, the team came to the conclusion that Li had to stop signing up for tasks. That way, she could help other team members get up to speed.

#2: Cut features to fit
Deliver value every day. Set deadlines for the team.

I was working with a team who did what outsiders thought was an absolutely unbelievable achievement within the organization.

Get this, they delivered on time.

I asked one of the developers, Daniel, how they did it. His response was nonchalant:
“They gave us 3 months, so we built a product to fit that time interval.”
Me: “If the team had 4 months?”
Daniel: “Then we would have had more features.”
Me: “And two months?”
Daniel: “There would have been less features.”

Arrange your work so that you can trim down features to deliver in regular intervals. When working with a full-bore XP team, every time someone checked in code the system had to function. Every check-in was “potentially shippable.” Not that we would, but we could.

Our constraints are time and people. A newspaper’s constraint is time, people and column inches. By trimming features down, we can build software products with the time and people we have.

Names have changed in this article to protect the innocent

Euphamisticlly defined by Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Perhaps this:
Scrummerfall. n. The practice of combining the meetings of Scrum with a Waterfall process. This ensures that the team doesn’t have to change the way they work while adopting Scrum.

Right now I’m at the tail-end of a project with a first-time Scrum team. Here is where we’re at.

100% Code Complete!

I still have no idea what the phrase “code complete” means (other than the title of a great book by Steve McConnell). Making this declaration with 35 bugs open is meaningless. The team front-loaded all feature development, postponed testing and deferred bug fixing. We’re still finding bugs.

Here are some symptoms to this approach

• Broken window syndrome: Developers come across bugs (while doing other bug fixing) which they dismiss. “yea, it’s not supposed to work in FireFox yet.”
• Increased project risk: The team explicitly scheduled 6 weeks of bug fixing time. No portion of the system is in a working state when “Code Complete” was declared. It’s unclear how much work is remaining to gauge if the system will be in a shippable state by the deadline.
• Time wasted on integration. To hit the “Code Complete” deadline, merging with other branches was deferred for two months. Several days have been spent just doing the merge. Bugs related to the merge continue to fall out.
• Other teams have to use our buggy system for full end-to-end testing.
  People actually like the bug triage process. For some strange reason, folks are finding comfort in seeing a big number get chipped away at over the course of several weeks. It’s not seen as wasted time.

• Low Quality, Little Automation

I believe a core Agile principle is to deliver a high-quality system at frequent intervals. When a team is doing the Scrummerfall there is no pressure on keeping a system healthy. Why invest in automated tests and automated deployments when there are two (or three) Sprints at the end dedicated to testing and bug fixing?
If a team is delivering a high-quality product at frequent intervals, it’s because some investment has been made to ensure that the quality always remains high. Usually, that means testing the system all the time. Testing is painful. When all the features in the system are verified by hand each iteration (”yup it still works”) someone eventually says “enough is enough” and begins automating tests. In the Scrummerfall there is no pressure to have a high-quality system at frequent intervals. Deployment, testing and bug fixing are deferred to the end. The pain doesn’t happen frequently enough for someone to try to fix it.
Mike Cohn likes to say, “The deadline [of the Sprint] is sacred.” I like to say, potentially shippable is sacred.

On truly excellent teams, I haven’t felt compelled to pursue outside programming activities. And now that I think about it, those folks haven’t felt that pull either.

When they did feel the pull, they would build something for the team. Sometimes someone would work on making the development environment better. Everyone was grateful for making their work lives better. Other times, some sub-system was slow, but not slow enough to justify the effort improving it. Someone would tackle that tricky problem - for fun - in their spare time.

When I am involved with difficult teams, my level of outside work increases. I’ll start hacking, writing, or get obsessive about something else. I need a ‘fix’ of getting something accomplished.

Programmers:

• They like the immediate positive feedback that they get from the team when they fix a bug.
• For some programmers these tricky obscure problems are fun. They love tracing through the code, poking at the database to find the problem.
• It gives them the sense of accomplishment when they can find and fix issues. They get a pat on the back when they crank-out 20 bug fixes in a day. They don’t get a pat on the back when the feature was implemented.

Project Managers:

• There are finally concrete numbers on the project. (87% test coverage, 62% pass, 38 bugs…) Those numbers can be tracked, charted and a prediction can be made on when the project will be ready to launch.

QA:

• This is their show. They get a chance to drive development efforts. There have been pent up frustrations over the past few months, with
• They are proud of the number of bugs they find.

“two”
“three”
<nods>

The team has been working on the product for 11 sprints over six months. And I’ve been blown away by the amount of functionality the team has been able to add in such a short time. But the product hasn’t settled into a groove. There are a lot of features that almost work.

A couple of things are effecting the team: