File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes How to run an XP workshop Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "How to run an XP workshop" Watch "How to run an XP workshop" New topic
Author

How to run an XP workshop

Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I'm going to coordinate a one-day XP workshop at work later this year and thought I should start a thread discussing the possibilities regarding the content and approaches.
A lot of questions to start with. Bear with me.
1) Group size and constituents
Is it feasible to mix developers and (non-techie) project managers? I've been thinking about 10 people because that's still manageable by a single "coach" (and can be fitted into a mid-size meeting room with laptops).
2) Writing software vs drawing pictures
This is perhaps the biggest decision of all. XP Game and Extreme Hour rely on simulating the XP planning game, iterations, etc. by swapping the keyboard into a whiteboard (mainly due to lack of time, I guess). Some bravehearts have not given up on showing the real stuff, not forgetting to remind others about the inherent increase in miscellaneous difficulties caused by this decision (see Extreme Hour With Actual Programming for example).
I'm intrigued to choose a simple webapp written in Java as we're not limited into 60-90 minutes. The application should also end up using a relational database to prevent statements like "sure it was fun but it wouldn't work with real development" and "it's easy to do TDD with simple classes but try to do it with JDBC/EJB/servlets/whatever". Or am I just too paranoid?
3) From scratch vs jump-start
If one chooses to develop software during the workshop, one has to choose where to start from. Should we start from scratch or give the team some foundation code to get them up to speed faster? If some code is given to them, how should the story cards etc. be handled? Should the coach start the exercise by briefing the team on what they supposedly did in the "previous" iteration?
4) Who's the customer
The customer is an essential role in the success/demise of an XP workshop, I believe, which leads me to wondering whether the coach should act as the customer? It would give the benefit of not having to worry about inventing suitable stories (as they can be written beforehand). The team would not have to idle while the guys acting as customers are trying to make up features. This could also give a better sense of how the planning game should proceed. Ofcourse the drawbacks are the same. The team would miss a lot of details that will become obstacles in the real world.
5) Rotation
How should the group members be rotated during the workshop? If the group consists only of developers it's easy to just switch pairs. However, if some of the group members are acting as the customer, how should the customer role be rotated--if at all? What pace for rotation would be optimal?
6) Iterations
How many iterations? How long iterations? How much "interference" should the customer generate by changing direction and dropping already built stories?
7) What's in, what's out
Which XP coding practices should we practice and which to leave out? This one has also puzzled me a lot. I suppose a large part of the audience is not too proficient with JUnit, HttpUnit etc. so I'm afraid throwing in TDD would prove to drag the development effort into double-digit load factor... Then again, XP isn't really XP without TDD (and thus, without refactoring) and TDD is in general the one thing I would choose if I had to.
I'd be interested in hearing opinions about these (and related) issues.
[ August 22, 2003: Message edited by: Lasse Koskela ]

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
XP ADOPTION - ACTIVITY CATALOG

Would this link help with ideas ?
regards
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Thanks HS, I had not checked whether Joshua & Co would've had any tips. Well, they did have something... I'd love to hear more details, however.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
1) Group size and constituents
Is it feasible to mix developers and (non-techie) project managers?

I'd think so. I know that the XP Immersions held by Object Mentor do this (IIRC, they add the non-developers at the third day of a one-week training).
After all, XP is about bringing people together to form One Team...

2) Writing software vs drawing pictures
I'm intrigued to choose a simple webapp written in Java as we're not limited into 60-90 minutes. The application should also end up using a relational database to prevent statements like "sure it was fun but it wouldn't work with real development" and "it's easy to do TDD with simple classes but try to do it with JDBC/EJB/servlets/whatever". Or am I just too paranoid?

Well, I would be more paranoid in the other direction: What if you do too much, so that you won't be able to handle it accurately. I would rather make them curious ("Yes, you really should try it with JDBC!") than let them fail because of a too high initial complexity.

3) From scratch vs jump-start
If one chooses to develop software during the workshop, one has to choose where to start from. Should we start from scratch or give the team some foundation code to get them up to speed faster? If some code is given to them, how should the story cards etc. be handled? Should the coach start the exercise by briefing the team on what they supposedly did in the "previous" iteration?

I would let them start from scratch. Otherwise they will spend too much time learning about the already existing code base.

4) Who's the customer
The customer is an essential role in the success/demise of an XP workshop, I believe, which leads me to wondering whether the coach should act as the customer? It would give the benefit of not having to worry about inventing suitable stories (as they can be written beforehand). The team would not have to idle while the guys acting as customers are trying to make up features.

Shouldn't the "developers" help the "customers" come up with stories? I think this is an important process in XP which shouldn't be skipped.

5) Rotation
How should the group members be rotated during the workshop? If the group consists only of developers it's easy to just switch pairs. However, if some of the group members are acting as the customer, how should the customer role be rotated--if at all? What pace for rotation would be optimal?

I don't think rotation would be a good idea on a one day workshop. I could be wrong...
7) What's in, what's out
Which XP coding practices should we practice and which to leave out? This one has also puzzled me a lot. I suppose a large part of the audience is not too proficient with JUnit, HttpUnit etc. so I'm afraid throwing in TDD would prove to drag the development effort into double-digit load factor... Then again, XP isn't really XP without TDD (and thus, without refactoring) and TDD is in general the one thing I would choose if I had to.

I agree with you that TDD is an important part of XP. Without the tests, it could easily become a disaster...


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
they add the non-developers at the third day of a one-week training).

I was actually considering having the workshop day split into two halfs -- of which the latter would be for both techs and suits. I subconsciously dropped this idea because I feel that the non-techies should get as much transparent a picture of the real deal as possible. Inviting them only for the afternoon would maybe seem somewhat suspicious and stand in the way of openness. I'll revisit this question later (many times, I'm afraid)...
What if you do too much, so that you won't be able to handle it accurately. I would rather make them curious ("Yes, you really should try it with JDBC!") than let them fail because of a too high initial complexity.

True. Perhaps I should let JDBC go and concentrate more on promoting simple design (serialize to disk if that's all you need) and maybe keep a couple of aces (example code for MockObjects) in the sleeve in case someone pops out the question...
I would let them start from scratch.

I think I agree, especially if I'm not planning anything about the chosen problem/solution beforehand.
Shouldn't the "developers" help the "customers" come up with stories? I think this is an important process in XP which shouldn't be skipped.

You got me there (again). I'm still worried about how will this work out as we probably won't have an experienced coach to keep the train on track. I guess the coach should be able to think of something to suggest if the team doesn't seem to come up with anything... Then again, if the nature of the software resulting from the workshop has no significance, why not let them go with the flow, right?
I don't think rotation would be a good idea on a one day workshop. I could be wrong...

Why? Do you think it'll confuse the group or are you worried about the cost of context switching in general?
I agree with you that TDD is an important part of XP. Without the tests, it could easily become a disaster...

Yep, TDD is definitely in. Maybe I'll just put a pre-requirement for knowing how JUnit works and hope that the stories don't involve networking (i.e. need to write tests using HttpUnit/Cactus). The thing is, testing servlets, EJBs, GUI code, etc. is exactly what get's the same kind of reaction as JDBC code -- "You can't write unit tests for X, at least not cost-effectively." That's a taboo I'd like to break if possible.
Another question: functional tests
How should I approach functional/acceptance testing. Should the whole team write acceptance tests together or let a couple of people concentrate on those (and be blissfully ignorant of what else is happening...)? Which framework would be easy to learn? I have to say FitNesse doesn't look attractive enough and JUnit isn't really made for writing functional tests...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to run an XP workshop