Agile Experience Reports From Development Managers
Yesterday I got to hear two experience reports on our Agile/Scrum pilot projects from two peer managers who aren’t exactly strong proponents of Agile. I assume this is happening more places now that Agile is moving beyond the early adopters. Anway onto the experience reports. From a web development manager:
- The idea of less useless documentation was really appealing, and he found it to work well in practice.
- Collocation worked really well as the team all gained a sense of camaraderie.
- Refactoring can get out of control. On this project they went from iBATIS to Hibernate to SDO to Hibernate in the course of three Sprints. Partially this was because they got bad advice from some consultants on using SDO for all projects.
- It seemed like even though it was an Agile project you still ended up with a lot of slack. Developers would have to wait at times for business requirements. QA would be waiting for things to test as the developers were coding. (We haven’t used something like Fitnesse for acceptence testing yet, and we’re still adopting from very siloed team roles.)
- As a resource manager sometimes it’s hard to juggle your resources when some of them are on an Agile project.
From a mainframe manager: (Yes, we are crazy enough to try something like Scrum on a traditional mainframe project.)
- Starting off he admitted he is heavily biased against all methodologies Agile or not because he doesn’t believe they work. He came out into the workplace when James Martin was selling his Information Engineering Methodology as the way to do perfect projects.
- His developers hated collocation at first since they didn’t want to move out of their cubes. Within a few weeks though they all agreed that collocation had worked really well and they actually really liked it.
- From the manager’s perspective since the product owners are more involved they’re not constantly dropping into his office to talk over things which has been a relief.
- He hates the 30 day iterations. He thought that iterations should just be planned around how long it took to completely code something. Say a three week iteration followed by a two week iteration and then a five week iteration to deliver a project. (Sort of blows the rhythm idea out of the water, but could work in something like Crystal if everyone agreed to the try the flucuating iteration lengths.)
Ed Gibbs @ September 29, 2006
It’s very interesting to hear about the problems people are having as they try to adopt agile methods. As you know, until recently I was working at a company that introduced agile very much as you are doing, and now I’m working at a consulting firm that helps companies adopt agile and lean methods. It seems as if every situation is different - not only every company, but every team and every project. Adapting agile practices to those unique realities is an important success factor, but we have to be careful not to adapt our way all the way back to the old ways of working.
You write that refactoring can get out of control, and that one team “went from iBATIS to Hibernate to SDO to Hibernate in the course of three Sprints. Partially this was because they got bad advice..” This doesn’t sound like refactoring to me. It sounds like a team that’s trying to find the appropriate ORM tool for their needs. I don’t think that’s “wrong”. It’s pretty normal for an agile team. (Of course, I don’t know the whole story, either.)
You also write, “It seemed like even though it was an Agile project you still ended up with a lot of slack. Developers would have to wait at times for business requirements. QA would be waiting for things to test as the developers were coding.”
Are you sure it was an agile project? That sounds like a process anti-pattern known as the “staggered iterative waterfall.” Team members are subdivided according to professional discipline - requirements analysts, developers, testers - and they are working in a quasi-waterfall fashion. Does this sound familiar?
You write, “As a resource manager sometimes it’s hard to juggle your resources when some of them are on an Agile project.” I realize you can’t always control this, but one of the key agile principles is “dedicated team.” It means individuals are assigned to exactly one project at a time.”
And you write, “He hates the 30 day iterations. He thought that iterations should just be planned around how long it took to completely code something. Say a three week iteration followed by a two week iteration and then a five week iteration to deliver a project. (Sort of blows the rhythm idea out of the water…” Yeah, sort of. Sort of just blows, if you know what I mean.
The “rhythm idea” is a fundamental principle. The manager in question doesn’t have a clear understanding of agile principles. Obviously he doesn’t grok the “rhythm idea,” and one can extrapolate from there that he probably doesn’t grok the “timeboxing idea” either. That’s okay - no one is born knowing everything, and at least he’s open to trying new things - but maybe you should mentor him rather than trying to adapt Crystal or other agile methods to conform with the very practices they are meant to correct. When you vary the iteration length you’re also varying the period of time between incremental delivery of features, and from there it’s a short step to totally random and unpredictable delivery. Customers don’t relate very well to that.
Thirty days is not an arbitrary iteration length. Scrum uses 30 days as the default iteration length because in most cases businesses operate on a monthly cycle. (It’s not literally 30 days, it’s a business month.) Most everything else in the company happens on a monthly basis, so incremental delivery and customer demos and all that stuff can happen with the same pulse as the business itself. “If it’s the second Tuesday of the month, it must be IPM day!” That’s the basic idea, anyway. When a different iteration length is deemed appropriate, most people would agree that each iteration on a project should be the same length. It helps people keep the work timeboxed and moving along, and helps with estimation. Your peer may find it easier to get this if you can help him understand that “completely code something” doesn’t necessarily have to mean a complete feature or a complete branch of a product’s functional decomposition tree. It’s perfectly fine to demonstrate partially-complete user features at an IPM. The more important thing is that the customer sees something that actually runs clean at each IPM.
All in all it sounds like you’re making huge strides in bring agility to your organization. I think that’s great!