I wanted to draw your attention to a section in Lean Thinking by Womack & Jones, which describes a Toyota technique which they call "visual control" - I see this as the car industry equivalent of the FDD Wall Chart. There is a fascinating anecdote about the Toyota US distribution warehouses and how they use such a technique. The key point is that a wall chart similar to the FDD Feature List is already considered a best practice in other industries.
I have been reading a lot of material on efficient methods from other industriues and I am finding that a lot of techniques in FDD can be mapped against techniques in lean production and distribution systems.
I really feel that FDD should be considered a "Lean Development" method.
Background
==========
"Lean" is a term coined by Womack & Jones to describe a method of management used primarily at Toyota and known in Japan as "The Toyota Way" (sometimes referred to as "Toyota Production System"). Bob Charette is best known for trying to apply these techniques to software with what he calls "Lean Development". Mary Poppendieck has also published work on "Lean Programming" at Software Development Magazine and has a book call "Lean Development - a toolkit for software development managers" being published next spring.
 | Lean Thinking : Banish Waste and Create Wealth in Your Corporation, Revised and Updated author: James P. Womack,Daniel T. Jones,James Womack,Daniel Jones asin: 0743249275 |
I agree and...
...and I think it is a more general concept.
Also Ken Schwaber wrote about how many ideas in Scrum come from other industries.
But I would be prudent to directly map engineering techniques from others industries to software industry. A lot of things may seem to match but there are deeper differences, the ones heavy methodologies often don't understand/face, that kind of differences that make an Agile Approach better than a heavy one.
IMHO, of course
Marco Abis
http://agilemovement.it
Italian Agile Movement
re: the Wall chart and visualisations
There's many more visualisations that we use internally. The vision for this whole thing is "Information Mining for Project Managers". It has many different visibility aspects. Textual - e.g. weekly summary report. Graphical - e.g. parking lot chart, plan view wall chart, etc. Scorecard/KPIs - e.g. trend report. Visualisation - 3D treemap program chart, snapshot diffing, and many others. It's important, but it's still just one piece of what is a much bigger whole.
Visual Control is about self-organization
I want to be very clear about this point. You seem to be talking about reporting and management information extraction - which I believe is how we've always seen the visual aspects of FDD. I'm really suggesting that there is a 2nd side to it that we were inadvertantly unaware of. The "visual control" idea is more about worker information and direction - and can be self-organizing. The reporting stuff is still part of it but wouldn't be called "visual control".
The idea with visual control is that the workers can tell at a glance what has been done, what is still to be done and who is doing what - they don't have to confer, hold a meeting or ask a coordinator. In the Toyota warehouse example, the workers have a magnetic board - kind of an FDD wall chart with coloured magnets rather than a print out. They place magnets on the board (of different colours) to show what they are working on and what they have completed. The board serves as a tool to inform their 21 colleagues of the current status and allows colleagues to pick their own work, or choose to help someone else. The magnetic board has all the jobs for the day.
In FDD the wall chart has all the Features for the Release or Project. However, one view is not sufficient - you need the CPW view, the Features Set View, the Subject Area View - but you get the idea.
In FDD the website is serving two purposes, an up-management function and an across/down-control function. FDD is slightly less self-organizing than Scrum (for example) because FDD involves leadership and delegation (at the CP level). However, I believe that it is wholely self-organizing at the CP level. I (as Dev Man) have never ever needed to get involved in ordering or controlling work. I have coached to get the process going but that is all.
The Toyota example is wholely self-organizing at the picker level and there is no hierarchy of pickers (from what I discern from the anecdote). In other examples of Lean assembly lines in the earlier Womack and Jones book, many other Toyota practices appear to be self-organizing at the team lead level on the assembly line. This would be right in the FDD CP space.
Specifically, to what you write above...
You are clearly using a lot more visualization and information mining tools than me. I would be glad to learn more about these. FWIW, in my current job, I use a wall chart in 2 views - the Dev View, classic 6-milestone Feature List - and the PM View, Feature List but with a percentage complete for each Feature and other space used with FS, SA and sizing estimates. I also use a full-blown FDD website which has multi-product, multi-release per product capability. It has an unassigned Features by Product category and then assignment to a Release, SA, FS and ultimately CPW. The site reports progress/completeness for each Feature, CPW, FS, SA, and Release. Use of color is fairly typical of FDD websites. We also have integrated Issue Log with Issue assignment against multiple Features or single CPWs or whole Releases. We don't have a parking lot diagram yet.
I also use graphs and I put them on the wall. This was hugely successful at my previous job too. I map Features complete, Production Rate (of Features Complete per week), Overall Percentage Complete, Production Rate (of Percentage Complete) as well as Issues Open, trend in open issues, Features blocked and trend in Features blocked.
One thing I'm interested in analyzing is CPW size against variance in Production Rate (of Features complete). I can see empirically that smaller CPWs reduces variance in Production Rate, this is because you get steady completion rather than pregnant pauses followed by the birth of a large number of Features - you will recall that one of the leads we worked with was bad for this. My current team is bad for this too - CPWs as big as whole Feature Sets. Getting the small batch size idea across is very very difficult - it goes against everything that people have learned or done in the past.
Being able to compare variance in Production Rate against CPW size, should prove statistically that the 2-week CPW limit is correct and optimal.
One technique being used by another part of my current team is larger CPWs for DBF. They take (often) a whole FS and do the DBF stage (stage 4), then they break the CPW into as many as 4 and mothball 3 of them. They then BBF (stage 5) one CPW and move onto the next. They consider this an improvement because the whole FS could be conveniently designed as a single batch but building the code is better done in smaller batches.
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers
Yes, self-organisation is key
Agreed. I'm talking about both. Very definitely both. (although I've no idea who "we" is in your post)
Oh yes. Our internal software has had all this (and more) for some time now.
100% correct. Not many see this. Go to the top of the class. FDD workflow is one of the big "missing links". It has never been published (yet). I will be working up to this topic (there's a bit of ground work to cover first) in the De Luca on FDD newsletters. I call this aspect of FDD a "self-organising system, but within planned assembly."
Good. Very good!
Probably. I use different ones at different times. They each are useful in their own way. I probably use the KPI scorecards and the features completed KPI plot most often to assess at the project level.
We use all that plus the parking lot of course and other visualisations I've mentioned. Depending on the definition of "release" I usually have that as a separate project under a program, or it could just be a major milestone I manage to (which I think fits in with your usage). Issues log is critical, so is discussion boards, IM, meeting minutes, etc. Right now we call them "knowledge applications" but I'm looking for a word like "infolets" or "knowledgelets" or "knowlets" or something like that. Haven't found a word I like enough yet.
That is Great!
I don't see that need, but then I haven't described FDD workflow yet (it's extensively covered in our workshops though). It *might* have an impact here. When I publish that, it should start an interesting commenting thread at this site.
That fits within the FDD workflow. Paul Szego is the master in this area. He's done a LOT of FDD projects with me.
Jeff
Optimal CPW size is important for agility
My interest in this is financial and based on my recent studies of manufacturing theory.
Simply put, the amount of money a manufacturer has to invest in working capital is directly proportional to the inventory level in the factory. In addition, the lead time, (or cycle time) through the factory is proportional to the inventory level.
Inventory levels are kept low by reducing the batch size. However, the degenerate case of a 1 unit batch is sub-optimal because of the cost of setups.
If you treat Features as Inventory and the DBF(stage 4) as the setup for a batch of Features - a CPW - then it becomes of significant financial interest to optimize the batch size - the size of the CPW.
Put another way, finding the optimal size for CPWs should minimize the required labor for DBF-BBF, minimize the inventory and minimize the lead time. This would result in the most financially optimal DBF-BBF stages, and result in the shortest possible lead time for DBF-BBF of an entire release. As Agile is all about fast cycle times and ability to cope with change then there is a mutual interest in optimizing the batch size - it creates maximum agility and minimum financial outlay in both investment in inventory (Feature defintions - requirements) and operational expense (cost of staffing the DBF-BBF stages).
Hence, I am very interested in the optimal size for a CPW!
David
--David J. Andersonhttp://www.uidesign.net/The Webzine for Interaction Designers
It's non-deterministic
It self-manages. It has to. That's the whole point. There's a series of of things abstracted up (and out) in FDD as things you must do. Then, beneath them it is detail. In this specific case (to do with workflow) there are several levels of determinism and non-determinism at play.
When you say "the size of CPWP (chief programmer workpackage)" I take that to mean you need size as some sort of absolute measure. What FDD is saying is that you don't seek this. You don't care. It self-manages - in this case by the CPs.
It is important. It does affect the pipeline and throughput and if the CPWPs are not being composed correctly this will very quickly show up. It's sort-of the reverse measure you're looking for. It gives you the visibility, very very quickly, to know if there's a problem with the pipeline or with throughput or with any discrete "batch" (CPWP) but you're uninterested in the low-level details (i.e. the "size") of each CPWP. Each of the key Roles in the workflow works at a level of abstraction (for planing and tracking) that makes the most sense for that specific Role and that Role's knowledge of the project.
The comment by Paul Szego in this thread titled "Subject: How many features in a CP Work Package?" covers a good part of this.
Jeff
It's the feedback loop which is more important
Jeff,
You are both correct and incorrect. Let's deal with the incorrect very briefly and then move on to your very astute and correct observation.
It is deterministic! You can prove this with mathematics. The proof for manufacturing is in the book, "Factory Physics". As long as you understand the rules of the system, then a mathematical proof is possible. (It's only non-deterministic if the rules of the system are unknown or the system is unstable and tends towards a strange attractor i.e. it is chaotic). In the case where a system converges on a value - even if that value is unknown before hand - then the system is both convergent and deterministic.
However, what you are saying is probably better. You are saying that it is the effect of the feedback loop which causes the system to converge on the ideal size.
Hence, rather than try to teach CPs the "ideal size" which is the converged answer I am looking for, it is better to teach the CPs the rules of the system and how to interpret the feedback and react to it.
I agree with you - this is a better and simpler solution.
Using Feedback
--------------
If you examine the Features Complete graph in a system where the CPW size is too large (for whatever reason) the effect is one of "stop-gp", "stop-go" i.e. the graph has flat spots and then jumps up, flat spots and jumps up.
If you train the CPs to modify their behaviour based on this visual pattern, then they would make the CPW size smaller, and the result will be a smoother graph.
So you are correct - it would be better to teach the CPs how to react to feedback and let the system settle down to the naturally ideal level.
What's the point of all this
----------------------------
In Lean Production they refer to this as "flow". When they use the term "flow of value" this is the equivalent of a smoothly rising plot of Features Completed. A jerky "stop-go" plot with flat spots wouldn't be "flow".
Achieving "flow" is a key tenet in Just-in-time (JIT) and in minimizing the inventory in the system. Less inventory means less investment. Less investment means less cost, which means more profit. Less investment and more profit means significantly greater ROI.
In software, the inventory level or "software in process" (SIP) as Kent Beck is calling it, IS the key driver to profitability. Less inventory means fewer people working on the project. Fewer people less cost. BUT (and this is important) you still get the same amount of output.
Hence, being able to monitor the batch size (of SIP) is the fundamental variable in calculating the profitability of rival methods.
In fact, this is so important, that I've written a whole book on the topic! (to be published in June 2003)
David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers
Of course it's the feedback loop
And there are several levels of this in FDD and from the perspective of the level above, it is self-organising below that level. It is self-organising with respect to the feedback loop (or visual control as you've also called it) at that level. I've also described this as "self-organising but within planned assembly."
Here's why I used nondeterministic in response to your seeking to determine a "batch size".
"The Free On-line Dictionary of Computing (09 FEB 02)
nondeterminism
<algorithm> A property of a computation which may have more than one result.
One way to implement a nondeterministic algorithm is using backtracking, another is to explore (all) possible solutions in parallel. (1995-04-13)"
Yes, the answer can be determined. That wasn't what I said or meant at all. I said it was nondeterministic (has more than one result) and I don't want to determine it as it self-manages (self-organises).
re: mapping against other techniques - levels of abstraction
Regarding mapping against other techniques, etc. Sure, FDD can be seen as all of that. I certainly often think of it that way.
A simple example is the parking lot chart - something I first created (adapted from a similar concept actually) on the Singapore Lending project. So, at one level of detail we can say that we have Subject Areas that contain Business Activities that contain features. We draw a large box for a Subject Area and then draw boxes for each Business Activity in that Subject Area inside its box. The boxes (parking lots) express percentage complete, number of features and so on.
Ok, fine. That's one piece of advice that is good. The chart is a very useful chart, and so on and so forth. So we could stop there and simply express the method as "graphically report progress by drawing a parking lot chart. A parking lot chart looks like this..."
The next level up from this would be a strategy that says something like "find a graphical way to communicate progress in terms the client can understand i.e. that the client can put in context, put a weight on, etc." There's more to the parking lot chart than just this aspect, but I'm only saying enough here to communicate the levels of abstraction point I want to make.
Now, on that particular project the history was of a lengthy, expensive failure. Some of the environmental characteristics were of a large corporate with mainframe/midrange computer systems and associated experience. i.e. a COBOL, RPG, SQL shop. This project was doing OO, client/server, Java, etc., all for the first time. None of that experience or skill existed in the client.
So, one of the management strategies was revolution - not evolution. Initially I setup an enclave inside the I.T. shop. While the rest of the corporate shared an Internet connection, my project had its own high-speed Internet connection (we had to have access to newsgroups, be able to download JDK levels, and so on). (for the casual reader the era is 1997). We used our own tools and processes. We ran our own servers, including mail servers. I setup our own "glasshouse." i.e. We had our own system administrator for the Sun and Netscape servers, our own PC support person, etc. All these things had to be done to move quickly. To setup the environment necessary to create a very large OO, Java, client/server system and have all that done efficiently and effectively without delaying the real project work. The existing "glasshouse" simply couldn't cope - and not just with the performing of the tasks we needed (for which they didn't have the skills) but with all the endless discussions of why we couldn't do this or that... (i.e. they couldn't evolve their exsting standards, process, policies, etc. to what we needed in any kind of reasonable timeframe)
Ok, so that was fine to get started and that's what I did. Now, as the project moved forward I had to start re-integrating my enclave back into the mainstream at this corporate. What's one the the very first things you look at in this regard? The interface to/from my project. One of the very first things was to get my project reporting and communicating just like, or as similarly as practical, the other major projects at this corporate.
Now, at the same time there was another massive project running which was to downsize from the mainframe to a midrange platform. So, I met with them to see how they reported to the steering committees and corporate execs, etc. Theirs was a waterfall project. They use coloured boxes signifying huge functional areas. Underneath the coloured box they had two rows of four little boxes. The top row was the start of a waterfall phase and the bottom row was the completion of it. The columns (think of a 2x4 table) were the waterfall phases - Requirements, Design, Code and Test.
I wanted to report just like they did (for the purpose of starting the re-integration process for the project as a whole), but of course this waterfall approach was completely incompatible with how FDD projects work. After several attempts I came up with the boxes being Business Activities and using the percentage complete as a progress bar (plus text) to show progress. The percentage complete came from the feature level tracking by milestones.
That's a whole lot of words, but it is a real-life example to show the next level of abstraction in action. At this level the strategy would be something like "report to overseers be they users, steering committees, or top management, in as close a way as possible as the other major projects at the client..."
I actually discussed this general abstraction with Jim Highsmith over a quick lunch in Melbourne earlier in the year. In my mind, there's a Successful Project Framework that many of the methods can be mapped against. A lot of this comes down to what level of abstraction you're comfortable with and see value in.
Keeping reporting the same
In a recent post on the Scrum list Ken Schwaber reports/gives the same advice - keep reporting to upper-management as similar as possible to what they are used to. This helps to disguise and soften the impact (on them) of process changes down in the trenches.
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers