There has been on-going discussion privately between Jeff, Paul (and others) and I over the issue of how small does FDD scale. In fact, Jim Highsmith in his book quoted Paul questioning this?
In my experience most FDD steps and processes work just fine on smaller projects with smaller numbers of people but a few are problematic. I would like to start this thread to discuss them.
I want to make clear that Paul and Jeff may have solved these problems (or they may not) but that the real problem is that solutions are not written down or communicated in a public way. With the books on FDD there is ambiguity about what to do in smaller projects and that is what causes the problems I have observed.
For the example, I imagine a system with 4 developers and less than 3 months of total development.
Ambiguity #1 Feature Teams of One
When we assign class ownership and divide the model into 4 areas for each developer, this means that many Features will only require one developer to complete. What to do? Form a Feature Team of one? or involve all 4 or some subset of the team in the DBF step?
If indeed a Feature Team of 1 is acceptable then how do you do the design inspection and code inspection? If others are to be involved in the inspections of design and code then what is the prescription?
I can think of an elegant answer to this which involves assigning class ownership in a way which means no two agacent classes in the model have the same owner. However, this is not in my experience the norm for division of ownership.
Ambiguity #2 One Chief Programmer or 4?
Let's imagine that we divide the domain model into 4 quarters and assign class ownership. There exists the possibility that many Features will only involve one
With such a small team is everyone there own Chief Programmer with their own inbox or is there only one? If class ownership is such that many Features only involve one developer, doesn't that mean that each developer needs their own workflow inbox?
more ambiguities another day as I am on the road this week and have limited time to post and reply
FDD in the small
The private discussion I've had with you consisted of you saying it doesn't scale well under 10 people and it really breaks down at 4 people. Me saying that I could not disagree more as most of the projects we do are under 10 people and FDD works beautifully at those sizes. You saying you didn't mean it wouldn't work under 10 but that it doesn't work as effectively due to a lack of critical mass. And then me saying I still disagree and it's okay to disagree - thus ending the discussion. That was 3 e-mails ending Oct 3 2003. But I get an awful lot of e-mails, and maybe we've discussed this previously and I don't recall it. Whatever the case, I don't think you've characterised this private discussion well in your opening sentence. That aside...
re: #1. You could do it either way. There are implications, of course, but there's no rocket science here. Just basic management. If I interpret your example correctly, you have four programmers. That's a good size team actually and I don't need to do anything really special for that size team, so let's consider the case you mentioned that assumes you are going to partition 4 ways and thus have a feature team of one.
That's ok. On smaller teams than 4 that's what we end up with (Paul and I work often as a two person FDD team - 1 domain expert, 1 Programmer). So, what do you do about inspecting that one persons work then? Um, you invite others to the inspection
That's how inspections work anyway - they're not always or only within the feature team. In your 4 programmer example, one or more of the others would inspect programmer number 1's work.
I've never needed to think about no two adjacent classes or anything like that. Sounds way too literal and scientific to me.
re: #2. I don't quite get the question. It looks like part of the question got chopped off (?) In a 4 person team there could be more than one CP but it's not necessary. One is enough. He coaches the rest on the scheduling, planning etc. and mentoring their work. All as per normal. Each programmer has features to work on - sure they do - just like in any other application of FDD. I don't see what's different here and thus what the question is?
Jeff
Shortage of CP material
I want to talk about the - under 10 people and critical mass thing -
First, your experience differs from mine. You work as a consultant and are brought in to situations at a high dollar fee. There must be enabling circumstances which made this possible and it gives you both a position power and influence and the ability to make changes. You wouldn't be there if there wasn't a change being enabled. In addition to this you have access to people like Paul and Gavin - some of the best CP material available.
OTOH, I work as a manager in a Fortune 100 company with all that goes with that since the bubble burst - severe budget restrictions, enterprise wide bans on "consultants", limited headcount, and a "make do with what you have got" attitude. If we use my previous position as an example - also in a Fortune 100 company - I had around 30 staff and typically 4 or 5 programs running in the shop at any given time. Of those 30 staff about 22 were developers and of them 3 were CP material.
Hence, if there were two projects with 10 people involved the CPs were tied up. What to do with the others? Reject them because no CP resources available? or make do with people who haven't yet developed the CP skills? There is no doubt about it that running projects without leadership skills is problematic - this is not an FDD thing and its not news.
However, FDD introduces a lot of new ideas to developers and without adequate leadership and experience the amount of change is too much. Sadly, but this us true, many developers I come across in the USA have years of experience but have never worked on a project where a design existed. Many have never worked on a project where there was a domain model. Some report having never worked in an organization that had such things.
Lack of CPs is a real problem and managers in real situations with the real constraints imposed by their corporate bosses have little room for maneuver. By definition, a project which has hired an expensive consultant / published author, is just a whole different culture and opportunity. By definition it is setup for success (unless it is a recovery operation) and there is the ability to do things which you (and others) have recommended in the books - such as hire more and better CPs.
I've got more to say about critical mass in another post but I want to keep this part of the thread focused.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Flow
Another thread about critical mass...
With larger projects there is more opportunity to gain a steady flow and maintain a momentum and higher production rate. Larger projects are easier to estimate as a result. The statistical effect of amortizing variance over a larger number of Features provides this.
One of FDDs great strengths is that you can select the Features for a CPWP from anywhere on the list - they don't need to come from the same Feature Set. Hence, momentum can be maintained by avoiding Features which block due to requirements ambiguity or other dependencies. Blocking Features cause variance in the production rate and schedule. If blocked Features can be kept off the critical path then the schedule can be maintained. On larger projects, project managers have more time to run down issues and resolve them before developers are blocked by them.
Note this problem can be exacerbated by poor use of Plan-by-Feature through poor identification of dependencies.
With larger projects there are just far more options - more options to run different numbers of teams to parallelize things - more options to select work which is possible and maintain velocity. More chance to absorb variance and maintain the schedule.
Of course, this effect could be resolved by saying that larger buffers should be used for smaller projects, or more time spent assessing the smaller project for likely variance - both common and special cause - and buffering it accordingly. But FDD as currently documented says nothing about project buffers nor does it say anything about variability. Planning for variability and building common cause variance into the schedule is something I have added in recent years.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
People, Process, Technology
I'm going to depart from the basis of this post because this seems to raise an issue that comes up time and time again in this site, in particular in the post - Agile Manifesto and the Post Software Engineering Era. That issue is about people.
Whether FDD scales up or down is not much of an issue as Jeff as clearly stated (my experiences also verify). The point you raise David, doesn't seem to be related to process but rather politics, which when you boil it down is about people. The issue doesn't seem to revolve around whether FDD can scale down but rather what do you do when you don't have enough good GP's.
This comes back to the basic premise that it doesn't matter how good the process or fantastic the technology, if you don't have the right people it doesn't matter.
Martin Bauer
Technical Director
http://www.designit.com.au
People, Change and Personal Risk (politics)
Martin,
I can't agree more with this. And for clarity - I am not disputing that FDD can scale up or down. I have introduced FDD to two very large organizations and help to build a 350 person business unit with an immensely complex program management problem across 4 development groups with typically 5 projects in each department at any given time. I have also managed, i.e. had the people doing the real work reporting to me, FDD projects down to 3 or 4 people. However, over 5 years and a lot of people and around 20 projects (that I've directly managed), I have had mixed results.
Thinking about this more, FDD introduces a lot of change. Doing all of FDD straight off is too much for many people. This can be compensated for with leadership - good quality CPs, Chief Architect, Development Manager. Without that leadership, the amount of change needs to be scaled back.
This leads me to the conclusion that an FDD maturity model is needed.
One of the reasons that Scrum is successful and gains a fast adoption is its simplicity. But Scrum is little more than FDDs Step 2 Feature List, Step 3 Plan By Feature, then treat Steps 4 and 5 as a big month long cloud - no modeling, no inspections, no detailed processes, no class ownership etc etc.
Scrum has a lower barrier to entry. It introduces less change.
To get back to the small team without sufficient skill or experience to absorb all the change...
The answer might be training, mentoring, hiring consultants - like Jeff - it might be stronger management, hiring and firing some people. All of this carries political risk for a manager or an upline management chain. My experience in 2 American Fortune 100 companies is that middle managers are risk averse and get punished for making decisions whilst being rewarded for not making decisions. Hence, it is easier to let people in the trenches suffer. Often line and 2nd line managers don't have authority to make training and consultant decisions because it bubbles the process in use up to some corporate ivory tower level where a decision was made eons ago to use RUP (or insert your favorite SDLC method).
Hence, I think the way to scale FDD in a greater number of situations is to introduce the idea of a maturity model which introduces it gradually over time and builds a culture of continuous improvement which ultimately leads to a full implementation.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
One step at a time
David,
I totally agree. I have been in a similar position as a middle manager trying to institute change with little support. It wasn't until I was willing to put my own money on the line to pay for Jeff to provide a week's training that I was able to make any headway. And that was one of many many battles I faced in trying to institute change. It wouldn't have mattered much whether I was trying to introduce RUP, SCRUM, XP or any other process, it was that I was trying to change things and people really don't like change. This problem is not new.
"There is nothing more difficult to take in hand, more perilous to conduct or more uncertain in its success than to take the lead in the introduction of a new order of things.
Machiavelli - 1532
Change is hard, damn hard and takes a great deal of faith, courage and determination. It also helps to take it one step at a time. After the one week's training with Jeff, I got together everyone and we workshopped what we could take from the training and actually implement. There was no way we were going from our current approach to full FDD without some trial projects and a gradual introduction of aspects of FDD into our way of doing things.
So, I totally agree, a staged approach - or maturity model as you put it - makes great sense.
Martin Bauer
Technical Director
http://www.designit.com.au
A Generalized Agile Maturity Model
In my book, I talk about a generalized agile maturity model. I haven't written a specific FDD version. Most of the model is based on theory from Edwards Deming and Peter Senge.
1. Analysis - learn how to identify what you are going to measure and train your people in how to do it. Get them comfortable with the technique before going any further.
In FDD terms this would be the ability to write Feature Lists - the client-valued functionality is what you are going to measure. I much prefer to write Features based on the specific domain language and to use the modeling sessions as a way of flushing this out. Hence, I would say that FDD's first step of maturity is modeling and Feature Listing analysis ability.
2. End-to-End measurement
Once you know what to measure and are identifying, the next step is for the manger to start measuring and to get the organization aligned to measure it end-to-end.
This means that you need to be able to track Features the whole way through until they pop out of QA.
3. Stabilize the system
This is classic Edwards Deming. However, others have written about it and it appears in the CMM. Basically, you have to be able to show repeatability. If you can meaasure and trace then you should be able to predict. You should be able to maintain "control" in the Shewhart sense (the fundamental work that Deming used as the basis for his method).
Being able to say - "this is 550 Features and that will take us 13 weeks" and then to be able to deliver within a few percentage points of that, is the type of thing I mean by repeatability.
4. Continuous Improvement
Senge called this a "learning organization". Goldratt calls it the Theory of Constraints. Regardless of how you think of it, the basic premise is the same. Know what you can achieve now, ask what is hindering achieving more, identify the root cause of the "limit to growth", and then make a plan to elevate or eliminate it. The production rate (velocity) should increase and this should be both predictable and under control.
In FDD terms, this means looking at the S-Curve graph for Features Complete and using the other KMS metrics - Jeff has written about this and so have I - and identifying where the problems are. Then the manager needs to go and sniff out the root cause of the problem and get a consensus around making a change. This should happen one at a time - under control.
The bottom line is - managers have to be patient.
I actually have a 5th level in the book but getting to and sustaining level 4 is such an awesome achievement for any manager that I'll leave it at that in this thread.
To Jeff's eternal credit, I have to say that I have never seen it done better than on the original FDD project.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
FDD in the small
That's ok. On smaller teams than 4 that's what we end up with (Paul and I work often as a two person FDD team - 1 domain expert, 1 Programmer). So, what do you do about inspecting that one persons work then? Um, you invite others to the inspection Shocked That's how inspections work anyway - they're not always or only within the feature team. In your 4 programmer example, one or more of the others would inspect programmer number 1's work.
Yes of course! But this needed to be said.
re: #2. I don't quite get the question. It looks like part of the question got chopped off (?)
It does look this way doesn't it. Sorry, I don't know. I can't remember what I tried to type in. I was working with my laptop which I know does some funky stuff with the cursor - so yes, maybe something didn't get typed in correctly.
In a 4 person team there could be more than one CP but it's not necessary. One is enough. He coaches the rest on the scheduling, planning etc. and mentoring their work. All as per normal. Each programmer has features to work on - sure they do - just like in any other application of FDD. I don't see what's different here and thus what the question is?
I see this as a far more important question than I think you appreciate. It relates to flow and parallelism. With one CP, we are saying that there is only one CPWP at any given time and all 4 developers are working on it. That means only one batch of Features flowing through the system at any given time. It also means that all 4 developers are synchronized at the start and end of each CPWP and that they all work together on the DBF stage of the new batch.
I tend to agree with this view but again - it needed to be said!
Something more needs to be said about why not have 4 independent developers each working on their own sets of Features (or any other combination). Why not try to parallelize the flow on such a small team? The parallel flow would appear to be more efficient and may feel "busier" (more efficient) to the developers themselves.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
The Missing Link (perhaps)
David, how about you just ask simple questions and I'll provide simple answers where I can. Don't make assumptions. It's setting an unnecessary tone for the entire thread. If we keep it to just q&a then everyone can learn much more effectively. ok?
Absolutely NOT! Here perhaps is the missing link for you. There will be multiple CPWPs (to get technical - there doesn't have to be but it is the norm). There is no constraint that says a CP can only be in one CPWP at a time. Not at any scale in FDD - big, small or medium
Nor would all 4 developers necessarily be in the same CPWP - the norm is that they would not be. These points invalidate the other statements regarding only one batch of features at a time and etc.
It is parallelised - always (operational reality). That is how FDD works. Even for a single CP project. There's no difference. CP#1 can be CPing multiple CPWPs at the same time and a CPWP does not have to contain all other programmers - even on small teams.
Hopefully this reply moves things forward a bit.
Jeff
More than one CPWP running simultaneously?
I have certainly used the idea that CPs have more than one CPWP but not running simultaneously. One (or more) in the pipe - one in production - maybe one in bug fixing (though this would be unusual).
Certainly, the idea that a CP has more than one CPWP provides a lot more flexibility. However, it sounds awfully like multi-tasking to me.
Surely, it is better from a risk management perspective to have only a single CPWP in production at a given time and to complete it at maximum speed. The CPWP having been selected based on some desired risk optimization strategy for the project, e.g. if the Features were sorted by value and Features in a CPWP were selected for some optimization of value over cost - or complexity (or riskiness) over cost.
It was an absense of such strategies in the FDD literature which led Boehm and Turner to conclude that "FDD has no risk strategy". I tend to disagree with this. Features were always supposed to be ranked. From when we first met Peter Coad, he was ranking Features. A ranked Feature List is a "risk managed" Feature List.
Anyway, to step back to the issue. I can see that it makes some sense to have a CP with multiple CPWP in a larger project - particularly if there are fewer CPs than is ideal. I'm still struggling to see a justification for it on smaller projects. Can you explain the reasoning in more detail?
David
Yes! Multiple work packages. All the time.
That's how it happens. It always has. Even in Singapore.
Certainly, the idea that a CP has more than one CPWP provides a lot more flexibility.
No - it's fundamental.
However, it sounds awfully like multi-tasking to me.
Yes, of course it is. Remember I said I spend about 50% of my time in the role of a CP doing what I called "administrivia". This is where I'm planning the pipeline at least a couple of weeks ahead, and making sure that everyone's going to have work to do, and we hit our targets.
That's why we talk so much about the degree to which you can safely overlap work packages, and why juggling all the factors like class ownership and what features to put into a WP and when to kick them off is so important.
To do this I have a whole bunch of work packages in various states of completion. Frm my CP inbox I usually identify "candidate" WP's based purely on sensible feature groupings that haven't been formally planned or kicked off yet. There are others that I've planned out, and are ready to be kicked off. I may have some that are kicked off, and people are working on them. Or they're done, I just haven't had the weekly release meeting and reported on them. Once I have they go into the filing cabinet. All this adds up to quite a few things going on at once, even more than would normally be visible to the rest of the team as they only see the ones in progress.
I simply cannot imagine how you'd do it any other way - there would be far too much downtime, and you'd end up needing more CP's. Remember that between some of the steps in the process there's a gap when you cannot proceed - for example after code has been distributed for a review, there's nothing much to do until the review happens (unless you're a reviewer). We always specify a minimum time here, at least a day, so that reviewers aren't expected to drop everything and can plan when it best fits into their schedule and daily routine. Also remember that the effort for each team member required for a WP may be considerably different. Given this I can't see how you could possibly keep people busy if you didn't have multiple WP's running at once.
I think I'm starting to see why there's been such a huge disconnect on soooo many posts in the past.
PaulS.
More on multiple WP's
Surely, it is better from a risk management perspective to have only a single CPWP in production at a given time and to complete it at maximum speed.
Why? The CP doesn't "do the work". At least not while wearing their CP hat. If they happen to also be a class owner then they will have something to do, but that makes no difference to the big picture. They're still just a class owner who's availability needs to be taken into account just like all other class owners.
Now think aboout the "real work" in a work package. Look at the milestones we use - only two of those have significant chunks of work in them, i.e. in the order of days rather than hours or even minutes. Those are the design and coding steps. The rest (walkthrough, 2 inspections, and promote to build) are a few short meetings and a few minutes in front of the version control tool.
What I've found from experience is that you base the scheduling around the estimates of how much design and code efforts is required, to the nearest half a day. I ensure that my team members will have plenty of design and code work in the pipeline, and just fit the meetings in around that. This is the key to ensuring people can stay busy.
So given that the class owners are going to be doing the most time consuming tasks in a work package, I don't understand your assertion that the CP only doing one of these at a time makes anything go faster.
I would claim the opposite is true - that if you had only one WP in progress per CP then everything would slow down, dramatically. A CP having multiple WP's in progress makes no difference to the speed at which each of them can complete - that's purely a scheduling issue. But having only one in progress will almost certainly ensure that developers are idle, and that the overall progress of the team will certainly be reduced.
Ignoring the fact that we've always done it that way, I also don't quite understand what your "multitasking" concerns are. On one post you seem happy with the idea:
Why not try to parallelize the flow on such a small team? The parallel flow would appear to be more efficient and may feel "busier" (more efficient) to the developers themselves.
... but now you seem to have changed your mind?
Paul.
Circles
Is that your opinion or the result of you asking them?
No, features in FDD were not always supposed to be ranked. Also, a ranked features list is not necessarily a risk managed features list (not without a lot of assumptions).
Working alone
This is an interesting topic from where I sit.
I have for some time been developing a product, initially as a hobby but more recently as a business. Since learning of FDD and being impressed by it I have tried to apply it to my work, so I have some experience now of applying FDD ideas to what has been basically a one-man project with ocassional input from others.
The first point to note is that the gross structures do not change. For each release there is the overall model, the features list, and the plan. The plan breaks the major release into feature sets which get developed, tested and deployed as units. The entry and exit criteria for each step remain largely unchanged.
The devil }:), as ever, is in the detail.
First: as a very small team the roles identified in the process all get assigned to one or two people. The project manager, modelling team, chief architect, chief programmer and even domain expert might all be one person.
This has the effect of telescoping many of the tasks. What does it mean to form a modelling team, do a domain walk-through, form a features team, assign class ownership, etc. if there is only one person covering so many roles?
The exit criteria from each step still apply however, so even one person working alone will have features matched to business activities, a class diagram, a plan with milestone dates for feature sets, design notes, etc.
So what gets dropped?
Many of the reporting features for a start. My reporting in a one or two man team tends to be a spreadsheet with a list of features. Each feature has recorded beside it a target date, actual start date and actual finish date.
The concept of a feature team and CPWP also largely disappears. The plan groups features into feature sets with a common finish date. When working alone I will start and finish a feature set before moving on to the next. When working with another I will make a call as to whether the other is capable of managing a feature set alone. If they can do the DBF and BBF alone then they get their own feature set after a walkthrough of the domain and overall design. If not I'll assign features and classes and act as CP in a feature team of two.
Also, unfortunately, inspections suffer. Without a team it is simply not possible to inspections properly. The only way I know to handle that is simple discipline. I have a checklist and force myself to examine each modified class against the checklist after each BBF step. This is obviously far from ideal but it is the best available. Where a second person is available we will review each other's work. Whenever one of us finishes a DBF or BBF we will interrupt the other to request a review.
So after that to answer some of David's points directly:
Feature teams of 1: Interrupt another CP to participate in the inspection.
A fistful of CPs: If each feature team involves just one developer then yes, each developer has their own inbox. This will put some extra pressure on the project manager to ensure the load is properly divided (and to ensure each developer can take time off their own features to do inspections).
A shortage of CP-quality staff: I'd have to agree with Martin on this one. If you have a team of 22 with only three capable of playing the CP role then you just don't have the people. As ever, software development is a human activity. Where the team lacks the experience the process cannot work miracles. I have no idea how to work around that problem, though I expect it will have to involve firing, hiring, training and setting the expectation above you that ten experienced staff will give a better result than your 22 inexperienced. All of which I lump under the heading of 'politics' and hand to the project manager. ;)
Devilish Detail
Brian,
Thanks for the thoughtful and detailed post.
You wrote:
Feature teams of 1: Interrupt another CP to participate in the inspection.
This is what I've been doing but ... It sounds awfully like a multi-tasking problem which has both the classic multi-tasking "everything takes longer" and the context switching issue (from Peopleware).
My gut feeling says that it looks busy and feels busy but it could be more productive. That is, it will be more productive to coordinate people more closely than to let it all run asynchronously.
A fistful of CPs: If each feature team involves just one developer then yes, each developer has their own inbox. This will put some extra pressure on the project manager to ensure the load is properly divided (and to ensure each developer can take time off their own features to do inspections).
Yes! And I think that the necessary coordination is probably a good thing although it feels counter-intuitive. This model drives out multi-tasking - assuming that the "time off" to do inspections is synchronized. Synchronizing involves somebody in waiting and waiting feels inefficient. However, I think it would be informative to have some metrics from the two models - everyone running at full speed interrupting others for reviews, or everyone running on a synchronized drum beat and pausing to do reviews even though it means some waiting time.
David
Re: Devilish Detail
David,
When I said 'interrupt another CP to participate in inspection' I was overstating the urgency of the inspection.
In practice every demand on the CPs time goes into their inbox and gets prioritised, no-one is expected to down tools in the middle of a coding session to participate in a review.
Brian.
Re: Devilish Detail
Ah yes! That's good. Everything has to be prioritized - particularly with a focus to the team goals rather than those of the individual.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Tiny Teams
Hi,
I've also done several projects with team sizes of 6, 3, 2 and even 1! I agree the process is the same, and it's really the nature of the planning and work division that you tweak.
First: as a very small team the roles identified in the process all get assigned to one or two people. The project manager, modelling team, chief architect, chief programmer and even domain expert might all be one person. This has the effect of telescoping many of the tasks. What does it mean to form a modelling team, do a domain walk-through, form a features team, assign class ownership, etc. if there is only one person covering so many roles?
Absolutely. For one person it's pretty trivial. One notable exception I've found with 2 or 3 people is the domain expert role. A few times we've noticed that it's hard for someone who's involved in the development to play that role - when doing a domain walkthrough for example you have to really concentrate on describing the domain, and not fall into the trap of thinking and talking about the solution. On more than one occasion we've had to get the domain expert to very conciously do a context switch out of developer mode and focus on being the domain expert for a short time.
Not having enough eyes as you want to do inspections is a pain - there's just not a lot you can do if the people don't exist. One thing I have found is that I get much better results by reviewing the code from a printout rather than doing it online. Whenever possible I force the entire team to print out (in colour if available) the code in a particular format and work from that. Even when reviewing my own code, I seem to be better at working off paper. So for reviewing my own code I always make a point of printing it out, and then sitting down with a fresh cup of coffee and a red pen with the printouts. For me it just seems to work better.
When working with another I will make a call as to whether the other is capable of managing a feature set alone. If they can do the DBF and BBF alone then they get their own feature set after a walkthrough of the domain and overall design. If not I'll assign features and classes and act as CP in a feature team of two.
This is interesting - I do similar things even with large teams. With tiny teams I do the same: I'll almost hand over the "work package" to a developer and let them run with it. We still have the reviews, but if they need help along the way they can always ask.
I've also found this to be a good technique for training up new CP's. I start out walking through the first few with them, then slowly let them work up to where they are comfortable running their own. In the meantime I can just "look over their shoulder" as much as is needed. Even with large teams this is a useful technique, remembering that in a lot of cases these are experienced developers who are just new to FDD.
The concept of a feature team and CPWP also largely disappears.
Yep - feature "teams" most of the time are one person. I'm not sure about work packages though. You do seem to end up knocking over business activities one at a time, but I view the work packages as a lot more than just the set of features that it's made up from. We have a worksheet and a whole bunch of artifacts that we collect along the way that get stapled to it (or at least put into its manilla folder). Things like the model fragment and printed code and review feedback and walkthrough notes etc. even on 1 and 2 person projects. Maybe it's just terminology - when you roughly get a BA == WP you could call it either I guess. Maybe a trivial distinction in this case, as it sound like we both still do all of the steps, but I like the idea of a consistent description regardless of the size of the project.
The best part I've find on smaller teams is that as CP I seem to spend considerably less than the usual 50% of my time doing CP stuff. I guess that's to be expected - if there's only 2 of you and 1/4 of the entire manpower is going into planning what 2 people have to do you've got some serious issues. On FDD projects there's a lot of interaction that happens within the team regardless of the team size, but with smaller numbers it seems that we end up with everyone "just knowing" what the situation is. Since there are so few other people, and given that they most likely participate in every design and code review, everyone ends up not just with a good knowlege of the entire system but also what the plan is. They can see ahead, and know what everyone else is doing, and most of the time can pick the next bit of work as well as the "designated CP". Being the CP in this situation is becomes more of an administrative role that would normally be the case.
Very interesting to know that someones else has had similar experiences working with small teams!
Paul.
Re: Tiny Teams
Paul,
It is always nice to know someone else has come up with similar responses to similar problems.
when doing a domain walkthrough for example you have to really concentrate on describing the domain, and not fall into the trap of thinking and talking about the solution. On more than one occasion we've had to get the domain expert to very conciously do a context switch out of developer mode and focus on being the domain expert for a short time.
True enough, and I am noticing that more and more as the project moves from being a hobby to being a business. It is becoming more important all the time to take a step back from the design and re-examine the requirements.
Even when reviewing my own code, I seem to be better at working off paper. So for reviewing my own code I always make a point of printing it out, and then sitting down with a fresh cup of coffee and a red pen with the printouts. For me it just seems to work better.
Again: snap!
In a recent job it was not practical to print all the code that passed my desk for review, but I would still print any classes or fragments that contained interesting or recurring flaws. Passing bits of paper with the annotated code around the review meeting proved a very effective training technique. Some individuals would even clip the paper to their cube wall for a week to remind themselves not to make that mistake again.
Brian.
Dynamic Inspection Checklists
Excellent Brian!
I do inspections as a system and one of the feedback loops in that system is the dynamic inspection checklist. The checklist contains flaws such as you mention. The checklist modifies itself over the life of the project as experience grows and different kinds of defects become evident. This is just one of the things in the inspection system.
Finally, this has been measured to be an even more effective way to do inspections.
Jeff