Wednesday, February 04, 2004

Class Ownership #5 - Feature Team Areas

My former colleague and fellow founding FDD team member, Stephen Palmer, has a nice solution for the problems of class ownership and continuous integration that I mentioned last week. He calls them Feature Team Areas.

The idea is simple. A Feature Team does not check-out code to their individual machines but instead to a communal network drive reserved for the Feature Team to use. They check-out all the classes involved in the Chief Programmer Work Package and modify them in the shared location. The classes can be tested in the shared location. Later, all the classes are checked-in together. This means that the build is never broken. The use of Feature Team areas facilitates continuous integration with FDD.

Tuesday, February 03, 2004

Slack!

Slack! or “room for maneuver”. You simply cannot work without it. If you want to mature, if you want to improve, if you want to perform better or out-perform a competitor, you simply must leave slack in your organizational loading. If you load your organization 100% you will never improve. More likely, things will gradually get worse. If you overload it, by say 150% then things will get worse, never better. Don’t fool yourself by pretending that to get 100%, you have to ask for 150%. [Amazingly, a senior VP of a large company I used to work for, believed in this 150% rule. He actually ran the company that way. Somewhat unexplainably, I actually liked and respected him - but I never agreed with his policy for strategic planning].

Monday, February 02, 2004

Class Ownership #4 - Sequence Diagrams

I started this thread on the FDD website to discuss the problematic nature of class owenrship and the requirement to draw a sequence diagram as part of Step 4 - Design By Feature, whilst using the Together Control Center product in its code-diagram synchronous mode, i.e. the code is the model and the model is the code - there are no model files, just .java files.

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.

Sunday, February 01, 2004

Chapter 4 at Inform-IT

Chapter 4 - Dealing with Uncertainty appears in full as an article at Inform-IT this month.

Goldratt’s first truly astute assertion about project management [Goldratt 1997] is that in an accurately planned project consisting of many tasks, approximately half the tasks will be slightly late, assuming the planning was accurate. This is very counterintuitive, but it is a fact. If a project is accurately planned and delivered on time, statistically approximately half the tasks should be early and half should be late. Accepting this notion is hard, but once accepted, it is possible to consider the solution.

[Typographic correction, the final equation reads as “~= 50”. This should be “~= 14” as is stated in the text. The same error appears in the first print run of the book on page 46]

Compensate Uncertainty with Leadership

There has been some considerable debate in the agile community about the percentage of good people required to make agile methods work. Most recently this thread at the FDD site. The topic was also a common running theme in Boehm and Turner’s Balancing Agility and Discipline where on page 185 (for example) they postulate that FDD requires a lot of good people in order to scale. Schwaber and Beedle’s Agile Software Development with Scrum claims on page 121 that it needs 50% experienced people to work. As I state in the thread at the FDD site, my experience with FDD is that 1 in 6 is about sufficient. Why?

Simply put, I believe that this endeavor to define how many good people or how many experienced people are required for any given method, is a red herring. The real issue is one of leadership versus uncertainty. Uncertainty comes in many forms - change (see Satir’s change model, see also Peopleware 2nd ed page 199), scope ambiguity, domain ambiguity, schedule uncertainty, job description and positional ambiguity, fear, difficulty, novelty of process, technique, tools and lack of experience therein, then there is variance both common and special cause. The greater the uncertainty in any project, the more leadership is needed (at all levels) in order to compensate for it. By loading too much uncertainty into a project, without sufficient leadership, there will be the chaos that Satir identifies but rather than recovering from the slump to show an improvement - the J-Curve effect - there is simply a slump and things remain worse than they were before.

FDD gets its leadership at many levels - the Chief Programmer (the shop floor foreman) is the first level of leadership, then there is the Development Manager and Chief Architect. All these roles must provide leadership on a day-to-day basis in order to overcome the uncertainty. When a project is happening in a new domain, with uncertain scope and schedule, and FDD is being introduced for the first time, along with color modeling and perhaps new middleware tools or development tools such as a JDO implementation and the Togethersoft Control Center, then everything is in flux. In such a situation, a team needs every CP, the Dev Man and the Chief Architect all to be great leaders, mentors and teachers. In simpler situations, where there is less ambiguity then less leadership is required.

In order to be a leader, an individual must be both good at software development and experienced in the software lifecycle (with a particular method). Hence, “good” and “experienced” are actually emergent properties of “leadership”.

The amount of leadership required on a project is situational. Trying to measure it by method and define a scale of agile methods versus percentage required is futile!