*
The moose likes Agile and Other Processes and the fly likes Opinions about suitable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Opinions about suitable "transition" processes" Watch "Opinions about suitable "transition" processes" New topic
Author

Opinions about suitable "transition" processes

Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Hi folks,
I recently happened to see a book about Scrum on my colleagues desk and started wondering about the variety of agile processes existing to date.
Say we have a software development company with a technical staff of 50 developers/designers/architects currently using a waterfall-like, relatively strict process. What would be the easiest agile process to adopt?
Digging into the minds of the staff, they'd probably be somewhat lost with just XP--I mean that there's no more a nice "official" agenda for a project and you're left with only a nice set of practices. However good those practices may be, I think the move is quite drastic for many companies missing a knowledgeable champion.
So, to (re)format the question to you guys out there, which agile process would you consider providing the best combination of agility and execution guidelines to support the hypothetical organizations transition to agile software development?
[ May 09, 2003: Message edited by: Lasse Koskela ]

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
I recently happened to see a book about Scrum on my colleagues desk and started wondering about the variety of agile processes existing to date.

Well, Scrum isn't that different from XPs planning practices, in fact.

Say we have a software development company with a technical staff of 50 developers/designers/architects currently using a waterfall-like, relatively strict process. What would be the easiest agile process to adopt?

Please define "easy"...
Digging into the minds of the staff, they'd probably be somewhat lost with just XP--I mean that there's no more a nice "official" agenda for a project and you're left with only a nice set of practices.

What kind of agenda are you looking for?
However good those practices may be, I think the move is quite drastic for many companies missing a knowledgeable champion.

Well, often also when not missing a knowledgeable champion. Fortunately, you don't have to introduce the XP practices all at once, though it probably would give you the most benefit. After all, you probably aren't looking into agile processes because you are pleased by the current state.
So, to (re)format the question to you guys out there, which agile process would you consider providing the best combination of agility and execution guidelines to support the hypothetical organizations transition to agile software development?

I would go with XP, not only because I know it best, but also because I think its set of practices really provides a good starting point. In fact, I don't know of an agile "process" which is more detailed than XP.
[ May 09, 2003: Message edited by: Lasse Koskela ][/QB]


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
Well, Scrum isn't that different from XPs planning practices, in fact.

Well, I wasn't trying to imply that it would be. It just happened to be the subject of the book that triggered the thought...
Originally posted by Ilja Preuss:
Please define "easy"...
...
What kind of agenda are you looking for?

What I meant with "easy" was that the project damag... project manager, would still have The Bible, which lists all the documents that should be produced in a particular phase of the project. Naturally, with an agile point of view.
Originally posted by Ilja Preuss:
In fact, I don't know of an agile "process" which is more detailed than XP.

Neither do I. That's kind of the reason why I am wondering whether there is one. However, the "details" of XP are not that straight-forward to translate to a sequence of actions.
Thanks for your input, Ilja. (keep it coming)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
What I meant with "easy" was that the project damag... project manager, would still have The Bible, which lists all the documents that should be produced in a particular phase of the project. Naturally, with an agile point of view.

One point of an Agile process *is* to make this list small. Remember, Agile software development puts "individuals and interactions over processes and tools".
XP, for example, recommends the following "documents" and their creation time:
- a release plan for the next three to six months, at the start of the project and updated regularly
- a system metaphor, at the start of the project, updated regularly
- an iteration plan at the start of every iteration
- automated customer tests, in the iteration a story is scheduled, preferably at the start or even to the planning meeting
- automated developer tests, parallel to the production code
Everything else is project dependend, so it doesn't make much sense to require it from an agile standpoint. The team is supposed to add as necessary, educated from its experience.
Neither do I. That's kind of the reason why I am wondering whether there is one. However, the "details" of XP are not that straight-forward to translate to a sequence of actions.

I think they are:
1) Gather user stories.
2) Do first Release Planning Game.
2.1) Do Architectural Spikes as necessary.
3) Do weekly Iteration Planning Game
3.1) Update Release Plan, if necessary
4) Do daily Stand Up Meeting
5) Work on story scheduled for the Iteration
5.1) Grab pairing partner
5.2) Do quick design session, if necessary
5.3) Develop code
5.3.1) Write failing test
5.3.2) Write production code to make test pass
5.3.3) Refactor to simple design
5.3.4) Repeat until stuck or usefull chunk developed
5.4) Commit or throw away changes
etc.
See also http://www.extremeprogramming.org/map/project.html
What do you feel is missing?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
One point of an Agile process *is* to make this list small.

Yes, and this is a big reason why the jump from <exaggeration>a well-defined process to a chaotic no-process</exaggeration> is so big. With respect to my original post, I am not looking for the best agile process but a safe compromise which sounds/looks/feels acceptable by a person previously involved in a strict, inflexible process.

XP, for example, recommends the following "documents" and their creation time: ...

True. My bad.

I think they are:
1) Gather user stories.
2) Do first Release Planning Game.
2.1) Do Architectural Spikes as necessary.
3) Do weekly Iteration Planning Game
3.1) Update Release Plan, if necessary
4) Do daily Stand Up Meeting
5) Work on story scheduled for the Iteration
5.1) Grab pairing partner
5.2) Do quick design session, if necessary
5.3) Develop code
5.3.1) Write failing test
5.3.2) Write production code to make test pass
5.3.3) Refactor to simple design
5.3.4) Repeat until stuck or usefull chunk developed
5.4) Commit or throw away changes
etc.

You know what? I think you just created the sequence I was looking for. I hadn't managed to get that clear a vision of the big picture. I had read about stories, the planning game, et al, but hadn't pulled them together.
Maybe I should buy some book(s) about XP to really get XP. Would you (anyone) have any suggestions? Actually, I think I'll start another thread for the book suggestions.
Maybe the problem isn't really about XP but the fact that XP represents itself to many (including me) as "a bunch of best practices".
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
I'm going to side track the discussion a little.
I've taken a couple groups through process changes (I do consulting in this area). They key point is that project managers who know how to many using a process are not necessarily competent at transitioning between processes. As you seem to be aware, you cannot simply institute new practices (even if everyone is familiar with them on paper). What you propose is a cultural change which effects not only the software group but all those who interact with them; e.g. the way marketing communicates requirements to software is different under RUP then under XP. In short, a good process can be bad if not transitioned to correctly.
I recommend the following steps:
1) Have someone or some group of people competent with multiple processes design and develop a new target process. This isn't necessarily something right out of a book, but a hybrid that is suited for your company.
2) Provide training in the new process and techniques. The schedule on which to provide training depends on the third point.
3) Create a transition schedule. The change needs to happen gradually over many months, so people can slowly acclimate to the new methods. The change may also occur staggered spatially as well as temporally.
--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Now for the actual question...
I think blind adoption of any process is a bad idea. Every book on software processes says the same thing, "don't simply follow everything in here because its written, figure out which techniques are right for your group."
You shouldn't change processes unless there is some advantage to doing so. Once you know what the advantage is, you can figure out what the new process should look like.
--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Mark, thanks for your input as well.
I completely agree that out-of-the-box isn't the way to go about changing processes. Assuming you have options.
<metaphor type="bad">However, neither is customizing a process "from scratch" if there is a suitable process readily available. Think "process reuse" versus software reuse...</metaphor type="bad">
So, although I agree that the best quality would be reached by a real process engineering project with the help of professionals, I believe there is a middle path where the costs and process quality meet. Ideally, a given process might present a suggested framework good enough for the organization in question, and as time progresses, to develop/customize it.
As a professional process consultant, what do you think about this kind of hypothetical approach? Does it (out-of-the-box) ever work?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Regulars pardon me for being repetitive, but I always recommend Alistair Cockburn to people who are comparing agile methods with each other and with less agile stuff. His Agile Software Development book has a very balanced comparison, and he has his own family of methods called Crystal.
I documented some of our team's journey from waterfall to iterative Here. We've done pretty well adopting story-sized work and XP-like planning games, though we still value some less agile stuff like use cases and a requirements database. The 80 page MS Project plan seems to be a thing of the past. "Hail Dorothy!" or something like that.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Lasse Koskela:
<metaphor type="bad">However, neither is customizing a process "from scratch" if there is a suitable process readily available. Think "process reuse" versus software reuse...</metaphor type="bad">

I guess I wasn't clear. When I suggested to have a group develop a new process I didn't mean that it should be developed from scratch. They would pick one or more that are along the right path and modify them as necessary.

Originally posted by Lasse Koskela:
As a professional process consultant, what do you think about this kind of hypothetical approach? Does it (out-of-the-box) ever work?

I'm not sure what you mean by hypothetical approach. In some sense, you can view a process as a series of actions used to create something. We cannot fully specify the actions, so we write down approximations which are our process descriptions. We know they are only approximations. In that sense, we know the "theory" is imperfect. The reality is, there are thousands of things that effect the implemntation of the process, so that you never know for certain if it will work until you try it.

BTW, wrt Alistar Cockburn's book, I read it at the recommendation of another bartender. I didn't find it particularly useful for describing agile processes. However, I did find it one of the best (although arguably few) books out there on methodology development.
--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
I think blind adoption of any process is a bad idea. Every book on software processes says the same thing, "don't simply follow everything in here because its written, figure out which techniques are right for your group."

I fully agree.
But the reverse is true, too: "don't simply change something written in here just because you think it can't work for you; try the techniques in concert for a reasonable time before judging them."
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
I recommend the following steps:
1) Have someone or some group of people competent with multiple processes design and develop a new target process. This isn't necessarily something right out of a book, but a hybrid that is suited for your company.
2) Provide training in the new process and techniques. The schedule on which to provide training depends on the third point.
3) Create a transition schedule. The change needs to happen gradually over many months, so people can slowly acclimate to the new methods. The change may also occur staggered spatially as well as temporally.

In my opinion, there is a very important step missing:
4) Regularly reflect on the process and adapt it to new experiences and needs.
I also think that a team needs "to own its process". In fact I think that the best teams don't let a process being imposed on them.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:
4) Regularly reflect on the process and adapt it to new experiences and needs.

This may be splitting hairs but I specifically excluded it because it is not part of a transition process (although the transition does involve evaluation and modification in step 3). This is, however, a step which should be done regularly whether the process is brand new, or 20 years old. I recommend a review every 6-18 months.
Originally posted by Ilja Preuss:
I also think that a team needs "to own its process". In fact I think that the best teams don't let a process being imposed on them.

Again, to be clear in case there was some confusion, I never said otherwise. The individual or group would solicit input from the entire team, and in the case of a group, many members would come from the team. For all but the biggest companies, most people aren't familiar with process design, and may not even really know more then one or two processes, so they would likely need an outsider (wrt to the team if not the company) to help guide them, as opposed to dictating to them.
--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
This may be splitting hairs but I specifically excluded it because it is not part of a transition process (although the transition does involve evaluation and modification in step 3). This is, however, a step which should be done regularly whether the process is brand new, or 20 years old. I recommend a review every 6-18 months.

Yes, of course. One good time is the end of a project. "Project Retrospectives: A Handbook for Team Reviews" by Norman L. Kerth is a very good book on the subject.
Personally, I like a much tighter feedback loop, along the lines of iteration retrospectives.
Again, to be clear in case there was some confusion, I never said otherwise. The individual or group would solicit input from the entire team, and in the case of a group, many members would come from the team. For all but the biggest companies, most people aren't familiar with process design, and may not even really know more then one or two processes, so they would likely need an outsider (wrt to the team if not the company) to help guide them, as opposed to dictating to them.

It wasn't totally clear to me from your previous post, and I am delighted to see that we are on the same page here!
BTW, how is your book doing?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Mark Herschberg:
I guess I wasn't clear. When I suggested to have a group develop a new process I didn't mean that it should be developed from scratch. They would pick one or more that are along the right path and modify them as necessary.

You were clear enough, don't worry, and I didn't assume you were talking about a complete "rewrite" of the process. The thing I intended to focus on was exactly what you said, "they would pick one or more that are along the right path," but drop the latter part, "and modify them as necessary."
In other words, have you witnessed the successful adoption of an agile process "along the right path" without modification? With modification I mean changing something that has been explicitly suggested by the process (filling in the blanks doesn't count as modification in this scenario).
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:
It wasn't totally clear to me from your previous post, and I am delighted to see that we are on the same page here!

Yeah, we tend to think alike and agree on most things--except XP, where I am still highly skeptical.

Originally posted by Ilja Preuss:
BTW, how is your book doing?

The delays have been considerbale between my current job and computer issues (I'm still fighting with IBM about my laptop, currently they're double billing me and the laptop isn't even fully working!) My plan is to take 2 week off before the end of June to finish the editing based on feedback from round 1.

Originally posted by Lasse Koskela:
In other words, have you witnessed the successful adoption of an agile process "along the right path" without modification?

I suppose not, because no company ever says, "we'll take it as is." Most of the time its taking the process, ignoring things which don't make sense, and then implicitly including things from the existing culture.
--Mark
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Ilja Preuss:
Yes, of course. One good time is the end of a project. "Project Retrospectives: A Handbook for Team Reviews" by Norman L. Kerth is a very good book on the subject.

I just bought this, primarily based on your recommendation (although I've got about 4 books ahead of it). We should really compare reading lists sometime. :-)
--Mark
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Herschberg:
I just bought this, primarily based on your recommendation (although I've got about 4 books ahead of it).

Uh oh - I hope you'll like it...

We should really compare reading lists sometime. :-)

Yeah!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Opinions about suitable "transition" processes
 
Similar Threads
XP book recommendations?
Agile Testing: A Practical Guide for Testers and Agile Teams
Agility and Discipline Made Easy: Only a RUP book?
PMP for software development, is that all?
Agile Software Development in the Large: Diving Into the Deep by Jutta Eckstein