This is going to sound like a terribly simplistic question but I'd like the community's opinion on the use of Together Control Center running in synchronous code and diagram mode and the Step 4 milestones of Design and Design Review.
The problem as I perceive it is that classes are "owned" by their owners but in order to draw a sequence diagram, a single developer has to check-out all of those classes in order to create the methods on the classes and complete the diagram. This breaks the class ownership constraint. In an ideal world, all the developers involved in the classes of a single sequence diagram would all be involved in the same CPWP at the same time and hence all working on the same sequence diagrams for the same batch of Features. However, in reality I find this problematic on a day-to-day basis - for example, a class owner may be involved in bug fixing whilst also participating in a new Feature Team.
This is how I have solved it for the time being... (I am interested to hear how others have done it)
First I ask the Feature Team to draw the sequence diagram for a Feature on a white board. I then ask the diagram creator to make the method signatures in all the classes - breaking the class owner constraint for a few brief minutes. I then have the classes checked-in. The diagram creator then draws the diagram with all the method signatures in place. This allows Together to prompt for the method call between classes on the diagram which makes drawing the diagram easier and faster.
In the event that a class in a sequence is currently checked-out by its owner due to work-in-progress, I ask the diagram creator to comment the method arrow on the sequence diagram rather than designate an "operation". This looks the same on the diagram but makes no changes to the code. This means that the diagram creator did not have to check-out the class but that the code and diagram are not synchronized.
Then the design review occurs. The diagram is checked-in.
In the original FDD project, Together did not keep sequence diagrams and code synchronized so that the act of drawing a sequence diagram did not create a need to lock class files. I would like to hear how others are dealing with this now and what is considered to be best practice.
Regards,
David
Feature Team Areas etc
With a dev. manager hat on I would say that my CP's should do what is most appropriate for their dbf/bbf iterations. With my CP hat on...
I like my feature-teams to work on whiteboards/flipcharts initially; it is faster than trying to work together around a PC. Once the team are agreed on what the sequence diagrams look like, I think there are a number of workable options. However, for each option, I would use feature team areas.
Unless you are using a sophisticated version control system with this sort of capability, a feature team area is a shared directory on a server. Any classes from the last build that need to be modified by the feature team are checked out to that area.
If the vcs is configured for exclusive locking and the class is already locked because it is being modified by another feature team or because the class owner is fixing an important defect, then we have a branching situation i.e. two or more copies of a class with work in progress. Note: this should not be the norm but neither is it an unusual situation either. Personally, I do not tend to use the VCS branching mechanisms here because I find them too cumbersome. Ultimately the class owner is responsible for any merging required as features complete and defects are fixed. I see class owners as a far more important and effective source code change control mechanism than vcs file locking. I actually see no real need for exclusive locking in the vcs when using class ownership properly.
Having agreed on the sequence diagrams the class owners have already agreed on any operations need to be added to their classes. Therefore, I have no big problem with a single member of a feature team or a pair entering the sequence diagrams into Together and, in doing, so creating any new operation signatures in the classes involved or vice versa. The same person/pair can also add the comment prologs at the same time or leave this to the individual class owners. On some occasions, I have volunteered members of a feature team that are the least loaded at the time to do this work while the others cleared work on defects or another feature teams that they are currently involved with. In all these cases, it is still the responsibility of the class owners to check the work has been done as agreed in the design session.
Alternatively, work in Together's sequence diagram sketch mode during DBF and use Together to generate code-synchronised versions of the sequence diagrams as part of the code inspection step in BBF.
Alternatively, if you can get away with the level of informality, a feature team could work off the whiteboard/flipchart sequence diagrams during dbf and use Together to generate sequence diagrams towards the end of BBF for formal documentation purposes.
What I would be much less comfortable with is class owners repeatedly not being present during the DBF process. I could see this eventually resulting in DBF design inspections becoming a walkthrough of the Chief Programmer's design presented as a fait accompli; IMHO not as good a way of working for many communication and pyschological reasons. For example, I could see a designer/coder split happening. With class owners not being able to contribute early to a design, any contribution at the design inspection time becomes a criticism of the CP's work. If the CP pushes back on that criticism I could see the class owners eventually relinquishing responsibility for design and coding blindly whatever their CP's tell them. Not good!
Steve
Never attribute to malice what can adequately be ascribed to incompetence
Team work is essential
Steve wrote:
What I would be much less comfortable with is class owners repeatedly not being present during the DBF process. I could see this eventually resulting in DBF design inspections becoming a walkthrough of the Chief Programmer's design presented as a fait accompli; IMHO not as good a way of working for many communication and pyschological reasons. For example, I could see a designer/coder split happening. With class owners not being able to contribute early to a design, any contribution at the design inspection time becomes a criticism of the CP's work. If the CP pushes back on that criticism I could see the class owners eventually relinquishing responsibility for design and coding blindly whatever their CP's tell them. Not good!
I think this is critical. The idea that CPs become designers is very bad. Not only does it create division but it fails to transfer knowledge. This can become a real problem because egos and payscales can be tied to it. I see a natural tendency for "architects" to want to own Steps 1 through 3, i.e. only architects model, and CPs owning step 4, i.e. only CPs design, and that leaves step 5 for coders. This is very bad practice but it seems to give individuals a comfort that there is a differentiation (a demarkation line) between them, their pay and level and others in the same group. A good manager has to work hard to break down these demarkation lines. Agile is all about generalism and a lack of demarkation. Grade, pay and authority should come with experience, leadership ability and graduation up a journeyman scale, e.g. masters - those who teach apprentices, should be graded higher than journeymen or practitioners.
It is really important - to the point that I would tie bonuses to it - that senior people share knowledge and develop the skills of more junior ones.
On a more partical note - I have found that it isn't always possible for every class owner to be present at every DBF session. Often the missing class owner, is someone who's classes only message between classes doing the real work, i.e. there is little information to be gained by having the class owner present and little information lost from not having them present.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Not Recommended
What are they doing that they can't attend a design? I don't agree with this. For the expert project manager - at times, for others it is a very slippery slope. I do not recommend this at all. Your CP s are coordinating the programmers. Something is wrong if the programmers are not available for required tasks.
Variance in attendance is inevitable in the real world
First off! I know! I know!
Secondly, multi-tasking has not been eliminated from my environment, i.e. senior management still assigns developers to more than one project at a time.
Thirdly, illness, and other personal and family issues keep people out-of-the-office.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Management
That's not what you said. You said a programmer might be doing bug fixing.
The issues you now raise above are business as usual for any manager. They don't corrupt the process.
Jeff
Way Too Literal
This is not a problem and never has been. You are being way too pedantic regarding class ownership.
Steve is quite right to apply common sense and say from the management point of view it is whatever works for the CPs and their teams. The details he listed are fine for implementations.
I'm not sure what you mean here. For the design meeting this is the case - it's not an ideal world (?) it's the way it happens. There can be overlap after that of course. But all of this is what a CP does - coordinating the teams. And bug fixes are the same as everything else - they get scheduled. When the CP asks a programmer what he is doing the programmer knows this (that he's working on a bug fix).
When the design happens it's because it was planned to happen at that point in time because thats when the programmers had finished other work. You plan it that way. That's why we have class ownership and thats why the CPs spend time keeping track of who is doing what.
The design activity is planned and it happens at that point in time because the CP has determined that the class owners will not be doing other things at that point in time that would stop them doing design.
Time, Slack and Critical Mass
Jeff,
I can't argue with your comments but they are based on some assumptions. You and I have disagreed on this privately before - the necessary critical mass to do all the FDD processes properly.
When you have a small enough (initial iteration) project with a crazy deadline and a team which is barely more than a single CP team i.e. 6 people, it isn't always possible to have the slack to wait for class owners to become available.
On the iteration just past, the team I'm leading achieved 5.5 Features per week per team member with almost perfect quality but we had to break a few rules.
If we had waited to do everything properly we would have missed our date.
The bottom line is that you need a big enough project with a long enough delivery date to get the slack in the schedule (i.e. resources are not 100% loaded - basic queuing theory - absorbing variance yadda yadda) otherwise you are scrambling and taking a few shortcuts. Now I wouldn't advise novices in FDD to try anything out of process.
Now why was the date crazy? That's a whole separate question.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Applying FDD Correctly
No assumptions David, just an explanation of how FDD actually works.
We've run many projects like you describe, 1 CP and a smaller team than your example. There is no problem scaling down to about 4. Smaller than that requires only a simple change to feature team formation. My use of CP team structures long predates your opportunity to observe on the lending project. They scale down to the small.
I totally reject your assertion about only a big enough project with a long enough delivery date mumble mumble mumble. We do what you say can't be done day-in, day-out.
Nor would I...
FDD works fine with small teams
David,
I totally disagree that there's some kind of minimum size requirement for FDD to work.
I have done at least 2 projects in the last couple of years that applied FDD with teams the same size and makeup that you mention. They were all large scale commercial projects - millions of dollars.
We successfully used FDD on all of these, with no changes.
I can't see this as simply a difference of opinion: you assert that it can't work, but myself and others have been doing it successfully for years.
Your assertion seems to be based around the idea that you cannot possibly load up developers 100% of the time. I don't know why - it's never been a problem for me to achieve this. Neither on small projects or large ones. Perhaps you could elaborate?
Paul.
I've been giving this more thought
I've been giving this more thought today. I'm trying to get to the bottom of where the disconnect is. Here is one thought - though this relates only to the current project and hence doesn't fully explain why I have seen issues elsewhere...
Let me provide some background without revealing any commercial secrets. This new project will get very big. It is a new domain for everyone concerned - that means my immediate group and other groups in the same program across the F100 company where I work. There is a nascent industry standard involved. The final system will be deployed for world-wide use and may service up to and indeed over 1 billion clients. It will be doing this asynchronously over a wireless link - with all the problems that can introduce. A typical piece of business logic in this system might ask "when one of these 4 million clients is next switched on a network, please do the following thing to it". It's a truly world class problem and the modeling has been hellish. Add to this that the team assigned is probably not quite as world class as the problem. Throw in every possible ambiguity you can imagine and then crank up the non-functional requirements so that this system has more <<plug-in point>>s than you would normally see on 10 models. Then throw-in that none of the team - apart from me is really comfortable with color modeling and no-one has ever coded a blue class with a plug-in point. Add the fact that the blue classes implement some immensely complex algorithms which in themselves have copious pages of specification - often written in poor English by someone on an industry standard body. Then imagine that you have to modularize the system into three layers on a stack and insure that each layer might be interoperable with other implementations of a nascent industry standard and that consequently the domain model lives across all three layers of that stack but that no one on the team has ever seen a domain model - which looks flat - carved into a hierarchy. Now add to that a schedule which was born in fantasia. To mitigate risk, the initial phases of the project are delilverable in 4 week intervals.
Can you spell F.E.A.R!
So I decide to break the analysis paralysis - deer in the headlights of this project - by leading by example and week one 2 CPs (I'm one) pair program the basics of one piece of the domain and build a blue class with plug-in and a few examples to use as a pattern to teach others. Week two, the project is scaled to 6 people. I found myself doing something that Kent Beck has talked a lot about this past year with XP - using a very small batch size. In XP, Beck talks about 1 day iterations, growing to 1 week. In this case, it was 1 Feature CPWPs (batches). So we ran 4 CPWPs simultaneously. The purpose of this was to keep design sessions to a single Sequence Diagram and minimize the uncertainty. Giving the developers a very short milestone to hit - a win after only a day or so. This was to build confidence.
The effect of 1 Feature batches is that a class owner who is needed in say Feature 6 is already coding on Feature 3. This meant that class owners were not always available for design sessions. It would have involved interrupting them and breaking their flow. I used judgement to decide when to do this and when not to. When not doing so, it caused the version control resource conflict which made entering sequence diagrams in Together difficult - without the work-around I mentioned on the first post.
So, it is easy to see the answer - increase the batch size - do FDD like it says in the book. This clearly resolves the conflict.
However, even now after 4 weeks, 100 plus Features complete and a very low defect count of about 0.2 bugs per Feature, almost no refactoring to the original color model, and the first iteration delivered, the team is still unsure of themselves. I find that even a CPWP size of 2 Features is streching them to the limit. Many of these Features are complex. Diagrams often have more than 10 classes involved and are complex enough as to take a team over 2 hours to devise - somtimes not fitting on a large whiteboard. Increasing the batch size would simply overload the team members and cause productivity to grind to a halt.
All that said, in-process 1 to 2 week CPWP sizes with standard FDD processes would work just fine with this team at its current size and would resolve the problems I mentioned at the start of this thread. Nonetheless, the production rate achieved and the quality achieved using 1 Features CPWPs cannot be ignored. Even though it was a startup phase on a clean sheet of paper, I have never seen a production rate of 5.5 Features per week per developer achieved with such high quality and with very few shortcuts being taken. I wonder if the small batch size had something to do with this.
So I don't feel that the issue I first raised was caused by project size or team size but uncertainty and change (note the Satir change model is just a degenerate case of a more general uncertainty J-curve effect - any uncertainty whether it be change or some other form of ambiguity will do just as well to create the same effect).
What prompted me to start this thread was clearly an effect I was seeing, without fully thinking through to the root cause. I will put this down to "being down in the weeds".
Paul made a point about - not having a problem keeping developers 100% percent loaded. I hope that this post made it clear that I was cheeting by achieving greater than 100% loading, i.e. when a developer should have been in a design session, they were actually writing code on another Feature. I wonder that this result is possibly fool making - in that, as a project grows in time and size, it is not sustainable. I also wonder, if the same productivity cannot be achieved with a larger batch size and no need to cheet the 100% loading by not having developers in design sessions when they ought to be. Hence, I wouldn't recommend it.
The key take away from this is that the team hit the deadline, delivered a first iteration that few thought possible and did it with FDD at a speed and quality never seen before in the organization. The reward for this is that they have to keep doing it for months to come.
Now I need to go think about why I have had concerns on other projects - about the possible downward scalability of FDD. Of course, I didn't have the luxury of being right in the thick of the action on these others but instead in a more remote 2nd line manager position with little visibility beyond the KMS Feature Complete graph report.
I hope this clears up any ambiguity in the earlier part of the thread.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Class Ownership assumptions
The problem as I perceive it is that classes are "owned" by their owners but in order to draw a sequence diagram, a single developer has to check-out all of those classes in order to create the methods on the classes and complete the diagram. This breaks the class ownership constraint.
Why? How did you arrive at this assumption?
Sounds like you're taking class ownership waaaaay too literally. The class owner is responsible for that class. That doesn't mean that if anyone else makes changes to it that will sky will fall on their heads.
The sequence diagram thing is common sense. Ignore the contention issue for a minute (I'll get to that in another post). All the class owners must attend the design meeting. If you're having problems with that you've got planning issues (another topic).
So we have all the class owners at the design meeting. I don't care if you use whiteboards and markers, or butchers paper and post-it notes, or throw fuzzy animals at each other. I've used all approaches sucessfully on large projects. The goal of the design meeting is to come up with a design. That's the outcome you're after. All class owners must be comfortable with the design, in particular how their class(es) will participate in the design.
Sequence diagrams are usually how we do this. So given that we have a concensus on the design, each class owner walks away knowing (since they agreed to it) what the changes are going to be. Now it's down to the details of how we get those changes into the model. You could ask each class owner to go away and put the new methods and attributes into their classes. That works. Or... if you have a tool that makes that easier, great! Oh, and only one person has to do it, rather than everyone. Even better!
How does this "break" class ownbership? The class owner participated in the design process, and at the very least agreed to the changes. They are still responsible for what changes are made. Someone else happens to plug in stubs for the new methods. The class owner still has to document these, and get them ready for the design review.
No uncontrolled changes. No suprises for the class owners. Nothing goes in without them participating in the design of those changes. No code is checked in (except perhaps to a "feature team area") that they didn't produce.
All sounds good to me. I can't see where the problem is.
PaulS.
Adding Method Signatures doesn't break class ownership
Paul,
I think we are in agreement - as that is what I had done - one person makes the method signature changes in classes owned by others because the class owner was in the design meeting.
I started this thread to validate that this approach was a consensus.
And yes, we do have planning issues but I'll post another thread or another reply on that.
Thanks.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Fuzzy animal technique
Reading through some older material and ran across this.
Paul, do you think you can provide some more insight into the fuzzy animal technique? I'm interested in adding this to my toolbox.
Using a soft toy to run a sequence diagram
Paul, do you think you can provide some more insight into the fuzzy animal technique? I'm interested in adding this to my toolbox.
It has several different purposes. The technique (from Peter Coad) is to run a sequence diagram interactively with people as class owners and the passing of a soft toy from one person to another representing a method call (object interaction).
This can be done to
A person that is a class owner takes on that class. i.e. what they know is their attributes, their methods and their links to adjacent classes. You view the model from the perspective of your class. Hence, if you get asked to do something (calcTotal) and you can't then we need to change the model in some way (add an attribute, make another method call, etc.)
We've used a Java Duke soft toy for years. But anything can do.
Cool!
I love hands-on learning techniques. I'll have to try this sometime. Thanks for sharing!
Planning
In an ideal world, all the developers involved in the classes of a single sequence diagram would all be involved in the same CPWP at the same time and hence all working on the same sequence diagrams for the same batch of Features.
No! This happens on every iteration on an FDD project. All feature team members ARE working on the work package at the same time, because the CP planned it to happen that way.
This is why we have class ownership and feature teams and CP inboxes and we force ourselves to plan at least a few weeks into the future. This is what the workflow is all about. See the many other posts on this site about how it all works.
When doing their planning this is what CP's are looking at. They can change a few things: the makup of the feature teams (by looking at the class owners of affected classes), or the sequencing and planned dates of each work package.
For a planned work package to make sense the developers must be available. All the classes must be available. With a lot of CP's they also have to balance out individual progress (i.e. clearing their inbox in a timely fashion) with overall project progress (i.e. all CP's get stuff done on time, and at a reasonable pace). There's a lot of factors to consider. But it's all business as usual planning stuff.
However, in reality I find this problematic on a day-to-day basis - for example, a class owner may be involved in bug fixing whilst also participating in a new Feature Team.
This should not happen. Sounds like the planning isn't being done properly. What should happen on a day-to-day basis was planned weeks ahead of time.
Paul.
Workflow requires a critical mass and slack
Paul,
I couldn't agree more.
In this particular instance, we had a perfect storm - total uncertainty - ambiguity in the domain, in the requirements, in the schedule, in the technology - and to some extent with the FDD process being new to some team members.
We also had only 4 weeks total development time - for reasons I can't go into. Hence, there was no real slack for workflow as you know it.
More another time, as I'm too busy to get into this in detail.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
This is exactly where you should use the workflow
David, the environment you describe is even more reason to use the workflow. There must be some fundamental disconnect here or difference in application of FDD. I'm happy to leave it as-is, I just don't want the FDD community thinking that with a small team or a short and tight schedule that the solution is to corrupt the process.
Ok? Maybe there's stuff that is unique to your situation and I understand that coorporate considerations often mean a full disclosure is not possible.
Jeff
Lack of leadership rather than size or scale
Jeff,
Actually, this application of FDD is closer to the real thing than I have been involved with for a long time - because I'm hands-on doing it.
I posted a lot more on another reply which I hope helps. I want to say a lot more about uncertainty - in all its forms and the need to compensate for it with leadership. I wrote a blog entry about this the other day.
I feel that FDD requires more or less strong leadership (in the form of CPs mostly) depending on how much ambiguity there is.
In this situation - as you describe - more use of workflow would help and as I suggest in the other thread, it probably would. However, I think that workflow, i.e. communicating in advance what is coming next, can only work when fear has been driven out totally. That requires CPs who do not flinch in the face of advsersity. And that requires experience.
FDD introduces a lot of change and a lot of new stuff. I am only just recently discovering that a whole lot of 5 year Java developers are amazed that "business logic goes in the DOs! Really!" The domain modeling part of FDD alone can cause almost utter chaos in a team that does not compute basic object oriented principles.
Nevertheless, I remain convinced that production rates with FDD (or other methods) are higher when good OO principles are used and maximum re-use, encapsulation, isolation and polymorphism is achieved, i.e. wrapping a procedure in a class called <Insertname>Manager does not hack it.
When introducing FDD - all 5 processes - and adding to it all the domain ambiguity - it can be too much - even in an organization that thought it was doing FDD 18 months ago.
I would agree with you that the solution is not to corrupt the process as a first resort. I will often coach that it is only as a last resort that any changes should be made. And I agree that FDD can be made to work with smaller projects, shorter deadlines and smaller teams. However, as I have stated before (privately) I see it strain at 4 or less people - and possibly at larger sizes but with novice CPs. All the basics still apply in these smaller projects, e.g. the domain model, the Feature List, the PBF, its the DBF and BBF in teams that seems to get problematic in small numbers, all the milestones still apply, all the tracking, all the reporting, the inspections and so forth but in smaller numbers people seem to get confused - maybe it is psychological. But that's a theme for another day...
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
production rates and OO principles?
Nevertheless, I remain convinced that production rates with FDD (or other methods) are higher when good OO principles are used and maximum re-use, encapsulation, isolation and polymorphism is achieved, i.e. wrapping a procedure in a class called <Insertname>Manager does not hack it.
I don't get it - what do OO principles have to do with production rates?
I've never heard of islolation described as an OO principle before. Encapsulation, polymorhpism or inheritance for sure, but not that one - can you point me to a reference?
Re-use was certainly touted as one of the benefits of OO in the early days, until we learned that inheritance wasn't all that it's cracked up to be. But I guess in the beginning it was the new hammer on the block, so we all ran around looking for nails to pound. The bottom line is that the OO world got that bit wrong in the beginning. I beleived it too, back in the 80's, but I'd be very wary of anyone who claimed re-use was a major benefit or goal of OO techniques today.
Paul.
hoo
This is going to sound like a terribly simplistic question
Most of yours are but you always end up reasserting your putative expert status by the end of any discussion
Cowardly
It's always interesting that flame baiting trolls prefer to post anonymously.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/