Home | Login | Recent Changes | Search | All Pages | Help

NewbieIntroducingAgile

I've got an Exciting (aka "scary") challenge at work, and I was wondering if anyone had ideas they'd like to share.

Here's the situation:

My company, a small ISV, makes software for network administrators. I've been with the company for about nine years now, and over that time we've grown from releases that required one developer 6-8 months to releases that require three to five developers for twelve months (nominally twelve, but in practice about 14-16, when all is said and done). Product quality has been trending downward, release schedules have been trending upward, and things generally just Aren't Where They Should Be.

Most of the developers in the company (including me) started development careers in the company, and have worked there ever since, so we don't have a lot of other experience to draw on. We use a sort-of waterfall development "methodology," wherein we have come up with a set of desired features and bugfixes for the next product release, drawn from customer requests, internally-generated ideas, and our bug database, at the beginning of a development cycle, and we work to implement those (with some changes along the way). We've been tending to get close to the target release date, finding _way_ too many quality issues, and end up slipping several months addressing bugs, fixing performance, sliding in last-minute features, and so on.

I've been getting steadily more dissatisfied with how this is all affecting the product, and from talking with others in development and (hideously-overworked) QA/tech support I know that I'm not the only one. So I have been doing a lot of reading and research on various agile development techniques, looking for things that we can incorporate into our development to help fix our many issues. I've also been carrying on a "guerilla campaign," talking to the development manager, product manager, QA manager, company president, and various developers and QA staff about doing something "Scrum-like" -- shortening iterations to one month, using a product backlog and a sprint backlog, focusing on implementing features that are customer-oriented (and can be implemented in a single sprint), delivery of running tested features at the end of each iteration, incorporating much more unit testing (I prefer TDD, but it's a hard sell), and daily stand-up meetings.

Well, it turns out that my campaign is meeting with some success, and as Herbert V. Prochnow said, "The trouble with opportunity is that it always comes disguised as hard work." I met with the company president, and he's interested in trying out some sort of Scrum-like process on our next+1 product release. He doesn't want to mandate it (wisely), so he's basically leaving the next steps to me. I am going to be giving a presentation to development, QA, and product managers (with the company president and executive officer sitting in, but not officially mandating the meeting) on what exactly I'm proposing we do. If I can convince people to buy in, then we're off to the races.

So, some of my questions are:

• What would be most effective for a presentation to this fairly diverse group? I was thinking of a basic "what is it" overview, a "day in the life" walkthrough, and a questions / discussion period. I'd like to keep it to (ideally) an hour, but 1.5-2 hours is not out of the question. I'd worry that I wouldn't be keeping people's attention, though. I have trouble sitting through meetings over an hour long myself.
• How can I best convince the development manager (who is quite good at what she does, but has no agile experience) that this is a good path? (Assuming, of course, that it _is_ a good path for us....)
• Which pieces is it feasible for us to adopt? What things can we ignore for a first attempt?
• Should we bring in a consultant/coach to help with this first attempt? I mentioned it in my meeting with the company president, and he seemed somewhat resistant to the idea, so I don't know how effectively I could suggest this. If there are any hard data on success rates at such a transition with and without assistance, that would probably help one way or the other.
• What else am I missing?

BTW, in case I didn't make it clear above, I'm "just" a developer. Movement to a project management role has been offered to me, but I'm really not interested in giving up coding at this point, and frankly I don't think the company can spare me from the coding front lines at the moment anyway.

I appreciate any advice y'all can offer me!

DavidPickett 2006.02.09

David, excellent job summarizing the situation. In particular your assessment that you and your peers "don't have a lot of other experience to draw on" seems a very important observation. (As a consultant and trainer doing a fair bit of this "introducing" stuff, that tends to be a big deal for me.)

Your response to it also seems effective: importing new ideas and additional experience from "outside". My first and main advice is that you keep focused on that, rather than try too hard to "sell" one particular solution to your managers and peers.

Keep in mind that you will be dealing with a process. It goes like this: you find a good idea "outside". You make an assessment of the idea - what you like about it, what you fear or dislike about it, what's in it for you. You try to integrate the idea in your ordinary practice - often that brings a little discomfort or even hurt, like a new pair of shoes. Then (if you don't reject the idea altogether) you find yourself getting used to it. After a while, it becomes as familiar and comfortable as a pair of loved and well-worn shoes.

Each of your colleagues will go through this process individually with each new idea. Don't "convince" people - support them through that process. Things that can ease the process are the sense of working as a team (getting support from each other in the periods of discomfort) and introducing the new ideas at a reasonable rate. (What "reasonable" is depends on the team. I've worked with teams able to absorb one new idea a year, others one a week.)

Start with things that make sense from a business and management point of view. Timeboxed iterations make sense because they provide regular feedback: use timeboxes to generate useful data, not for the sake of timeboxing. Automated testing makes sense because it provides information about product quality; what's important is the timeliness, relevance and accuracy of that information, more than its precision. Therefore, keep your automation investments light at the start; don't spend months building the "ideal testing framework". Do focus on functional or "user's point of view" testing as well as unit testing.

Do bring in people from "outside". Not necessarily an expensive consultant, trainer or coach - getting involved with a local user group can be a good idea, or just locating and talking to people in other companies in your area that have the same concerns. At some point you may have gained a very clear idea of what expertise you need and how much it's worth to you - then it will be appropriate to retain an expert.

One presentation will not make or break the whole dynamic. It may signal the start of something. Keep it simple, humble and informal. Reconvene often to discuss results so far and consider next steps. Do the same inside the team: have regular meetings to reflect on things that worked well, lessons learned, new things to try.

Also... you have effectively been moved to a new role. "Internal consultant" perhaps rather than "manager". You might want to reinforce those of your skills that apply to that role, perhaps make an effort to learn new skills explicitly. (AYE being an excellent place to acquire that training.)

LaurentBossavit 2006.02.09

Well, Laurent said what was going to be my first round of advice. So, I'll have to be "organizational change guy" and talk about that. Drat him. (Not. And when are we going to manage to go play together?)

Every technique or way of organizing development uses a model of how software development works, and a model of what's important in the system(s) you provide. Lots of arguments about how to do development come down to competing models. Grossly over-simplifying:

• The archetypal "agile" argument: analysis up front saves pain and cost later vs. you can't know sooner, so projection is a fantasy. From the agile folks there are actually at least four distinct "requirements agility is better" arguments, along with at least a dozen others that tie to other things. The point is, there are models behind the conclusions.
• The testing "schools" argument: testing is verification of fully determined behavior within a closed, formal domain vs. if we were smart enough (or had big enough tools) to fully determine behavior, or what mattered we wouldn't have errors and won't need testing. Testing is about the stuff we can't, won't or haven't specified.
• The scaling development argument: development in the large is like development in the small vs. no it's not.
• etc.

In case it doesn't show, I occaionally teach the models behind various approaches to software development, and some ways for teams to uncover their own models. Fascinating, really.

But, so what? This: However you have been doing development is based on your ideas about how development works, and what is important about your product - models. As you learn more about how development is working for you, you'll be changing your models about how development works. One of your organization's implicit models was something like: "Development will work more or less the same, and what's important about our system(s) will remain more or less the same, as we are in the market longer, and scale our system(s)." You've already noticed that something isn't tracking to your implicit assumptions, so congratulations. Lots of folks don't have that clue until it's too late, or close to too late.

Actually your company has done at least four quite wonderful things:

• You've been growing and shipping. Congratulations. This means your models of how development works, and what's important are pretty good. and you've been executing well.
• You've recognized that you'd like some of your results to be different. Getting feedback like that is uncommon. So congratulations again.
• You are willing to consider changing how you do the work as a way to change the results you are getting. Congratulations again. The all too common disease is "more, faster" and out come the flogging devices.
• You have had conversations which have created the opportunity to try things. From the description above, you, David, are playing internal consultant with some flair. Your organization is listening. Congratulations to all on that.

Laurent's comments about helping people through the change process are bang-on. One of the most important ways to help them is to frame what's going on. Maybe frame it just like I just did above, and invite people to be part of this learning process. "We're going to learn how to get more of what we want from our development efforts. We're smart. We can do this. Look what we got done so far." That does four things:

• Has people participating from some strength and confidence. "Hey, we did good. These so-called problems are the rewards of success."
• Recognizes that you're learning about how development works for you. So, anyone else's formula is a catalog of things to try, vs. a panacea.
• Treats each change as an experiment.
• Enlists into the change process anyone who is interested in the delivery of the system(s) that you guys ship.

You don't want to be in the position of "uber-guru" proposing the one true magical set of techniques. Some techniques just don't take in some organizations, or don't take for a while. Guru-dom also sets up a competition between the "knows" and the "know nothings." It's bad for change a whole bunch of different ways.

The last trick is to handle practice changes one at a time, from a backlog, exactly the same way you handle iterative additions to the product(s). Most people can handle changing at most one thing at a time. Multiple changes mask each other in their results as well - almost impossible to track. Pick something you can do now, that will generate clear benefit in a hurry - builds credibility and confidence. Some heuristics for knowing when you can introduce the next change:

• When the previous change - er - changes from a novelty to "simply the way we do things around here."
• It's very difficult for a team to absorb practice changes faster than one per month or so.
• You want three or four rounds of doing the new thing before you introduce the next new thing.
• When the way you talk about development together lines up with a slightly different model of how development works, or of what's important, you have learned something. Now you can build on that to learn the next thing.

For yourself, keep doing what you are doing. Have some resources and reference points outside of the system that is changing, to help keep yourself steady. Several of us here will obviously give you all the support you can stand. Still, "One hand for the ship, one hand for yourself." is good advice.

-- JimBullock 2006.02.08 (Not that I do this much . . . )

DavidPickett 2006.02.10

Best of luck.

JbRainsberger 2006-02-13

1. Share some of this thread with interested people around the organization.
   
   
2. Pay special attention to Laurent's advice: "My first and main advice is that you keep focused on that, rather than try too hard to "sell" one particular solution to your managers and peers." You don't want to be seen as a salesman, and in order to achieve that, you have to learn a lot of sales techniques. (paradox?)

For example, tell people up front that Agile doesn't always work, that some organizations aren't ready, and here's some warnings to watch for as we experiment with this. That will show them that you aren't pushing.

Another example: Listen to them, what really troubles them, then see if that relates to Agile and try to show them that in some simple experiment in which you also participate and risk. If it's nothing Agile that will help, come up with something else that will help. It's much more important to be seen as Helpful Guy than as Agile Guy. - JerryWeinberg 2006.02.13

DavidPickett 2006.04.17