Category Archives: Viva Agilista
Organizational transitions are hard. It really requires a lot of items to be put in place before any real change can happen. All of them are people related. 1) Risk-taking culture, 2) Leadership, 3) Coaching, 4) Team structure.
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.
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.
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.
I’m the middle of a Scrummerfall (http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.aspx)
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.
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.
Even if they won’t admit it, it seems like some teams like the test & fix cycle of a project
- 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.
- 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.
- 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.
After a sprint review meeting today I asked a few engineers, “From 0-10 how stable is the product?”
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: