Thursday, April 21, 2005

Automate to Reduce Variation

The power of tooling to reduce variation is often overlooked. Together is tool that significantly reduces variation in software development when used correctly. Microsoft Visual Studio 2005 Team Architect is another one, though its 2005 features address different problems such as design of distributed systems and deployment across data centers. Nevertheless, there is a common theme - right first time! The automation in the tool reduces rework and provides validation of one rendering of the knowledge captured in the product against another rendering. The chance of source code incorrectly implementing a design when Together is used correctly is greatly reduced. This reduces defects. Reduced defects reduces rework. Reduced rework improves planning accuracy and improves productivity through greater productive use of capacity constrained resources.

But Together is even more powerful when correctly used with The Coad Method and the architectural ideas that come with Peter Coad’s teachings. With The Coad Method, the domain analysis is kept is synch with the design and the source code. There is significant reduction in variation across a greater span of the lifecycle. With the resultant productivity gains. This is the paradigm shifting power of Together - a tool designed to implement The Coad Method. I’ve always been amazed at how lousy Togethersoft and more recently Borland have been at communicating that message. Perhaps the widespread adoption of J2EE and Enterprise Java Beans is what caused the problem. The J2EE simply got in the way of good Coad Method implementations. [I’ve got data that shows FDD teams practicing the Coad Method significantly outperform teams doing J2EE EJB’s. The difference in architecture wasn’t the only variable so these aren’t scientific results but anecdotal, empirical data is good enough for me as a manager to know that I’d never recommend building a J2EE based application ever again.]

I am hoping that we can drive similar ideas into Team System and Team Architect with respect to Service Oriented Architecture. The end product would be a version of MSF which was optimized for SOA and prescribed analysis and modeling techniques, implemented with domain specific languages (DSL’s) in Team Architect that significantly reduce variation throughout the lifecycle from requirements through to deployment. In other words, it would be nice if we could learn the lessons from Coad and FDD and apply them in a 21st Century SOA context.

Returning to yesterday’s post, there also exists tooling to drive variation out of user interface design and development. My old friend Brían O’Byrne founded Statesoft to solve this problem. His tool implements Ian Horrock’s method of using Statecharts for modeling the interaction design - an equivalent to the Visual Vocabulary technique I described yesterday but more rigorous, more directly mapped to the source code. Brían and I first developed this technique as a framework when we worked together in Ireland in 1999. His latest tool works for Java and .Net and allows you to draw a Statechart model of a UI screen flow and then generate the View-Control code for either GUI or web deployment. It’s a tool which reduces the variation from the designers vision to the implemented working code. [And it was developed using FDD.] The domain specific extensions that we made to Statecharts to handle exceptions and transactions also greatly reduce the possibility of defects in error handling code. Once again, tight coupling of analysis, design and code reduces defects. Reduced defects reduces rework. Reduced rework improves planning accuracy.

If your constraint, today, right now in 2005, on .Net software development, is coding productivity, then you simply have to look seriously at tools like Together and View Control as additions to Visual Studio and consider training your people in how to use them properly - model-driven design!-Analysis, design and code always in synch significantly reduces the opportunities for defects and the actual numbers of defects. Drive variation out of your software development lifecycle!

[In the interests of balance, if anyone else is producing tools which they can demonstrate significantly reduce variation across the lifecycle in a similar fashion please comment]

Wednesday, April 20, 2005

Low Variation User Experience Design

So back when I proposed a multi-project Critical Chain solution for software engineering, I wrote a paper - based on real experience - that a good shared resource to select as the synchronizing drum would be the user experience (or interface design) group. This met the first criteria for a good drum resource. It was close to the front end of the system and therefore the rope (back to the start) would be short. [For those not deeply familiar with Critical Chain, the synchronizing resource is actually operated using the Theory of Constraints Drum-Buffer-Rope solution commonly associated with manufacturing plants].

The second criteria for a good drum resource is that it have low variation. The reason for this is pretty obvious. If a drum synchronizer had high degrees of variation then there would be times when it wasn’t the constraint and the unknown and unmanaged alternative constraint would throw the system into chaos. Equally, at times when the drum was severely under performing due to wide variation, it would mean very low productivity from the whole system. Everything would be dragged down by the wide variation in the constraint.

So it was argued, the user experience group with its artsy types would not be a good choice because artists are too unreliable. Hmmm. That could be true? So, I was left with two choices, persuade the organization to invest the user experience group to relieve it of its bottleneck status or solve the problem. The answer was to introduce the use of Visual Vocabulary modeling as an analog to the domain modeling in FDD. The VV model is used to identify all the work items for the design team. For each box on the model, the team has to design a screen or web page. We then measured the design effort typically associated with this and it exhibited remarkable low variation.

So, that just leaves the modeling effort itself, which is also conducted by the same capacity constrained user experience designer resources. This has the ability to eat into their time for designing and hence is a variable of variation. The way to drive variation out of modeling is to strictly time box it, for example, one week per quarter, or no more than 7% of an iteration’s calendar time. We had remarkable success with this technique. The theory was pretty closely reflected in the operational reality.

So as a general rule, organize a process to put the bottleneck close to the beginning - this requires investment elsewhere to provide slack capacity - then optimize the chosen drum resource and reduce its variation through the introduction of better analysis techniques.

Tuesday, April 19, 2005

FDD on .Net

My friends at Borland just released Together for Visual Studio .Net. This is fantastic news. It means that IT shops across the globe can now easily practice Feature Driven Development for .Net applications. Just add Together to Visual Studio and you can do Coad Method domain modeling in color and couple that to the FDD Tracker tool and you have a full blown knowledge management system for FDD. This setup would easily rival the tooling we had in Singapore - and we had a dedicated team of 5 people providing it, along with a site license for the Beta of Together. We started with version 0.4

It never ceases to surprise me how few people actually understand the paradigm of a tool like Together. It’s a tool which requires a team to change its behavior. It’s not just a drawing tool. It’s more than a typical modeling tool. It is a tool for reducing variation in software engineering. It keeps the design and the code in synch. It allows the design to drive the development. It is the original model-driven design tool.

Sunday, April 17, 2005

Reducing Variation in FDD

So, following the previous two days posts about driving variation out of bottlenecks and the relationship between Deming and Goldratt’s approaches, let us now consider an example from an FDD project. Let’s imagine that the bottleneck is software development, i.e. design and build in FDD-speak.

Our goal is to maximize the throughput of FDD Features [Coad 95 & 97 - Object Models] and to do this we must maximize the rate of Feature completion. How could we maximize the rate of Feature completion? We must seek to reduce the time between completion of Chief Programmer Work Packages (batches of Features) and increase the average Features per day or week. There are several things we could do…

(1) Improved Feature Analysis

By getting better at The Coad Method, we can improve our ability to analyze Features. Properly analyzed Features exhibit lower variability and map better to the object model and the design of the code. With better mapping to code, there is lower variability in the size of Features and the time they take to design and build. This improves the predictability for the lead time in a chief programmer work package and allows the batch size to be set appropriately.

(2) Better Time Management

We can teach developers to better manage their time, or introduce rules to let them focus quality time on productive design and coding, such as “no email before noon”. This will reduce the lead time for chief programmer work packages and increase productivity. Better time management will lead to more reliable effort expended and reduce variability of throughput.

(3) Single Project Tasking

We can insure that developers single-task on one project and preferrably on a single chief programmer work package within that project. This helps them to optimize time management and focus on minimizing lead time for that work package.

(4) Quality Assurance Measures

We can enforce design and code reviews and unit testing techniques. In fact, 100% coverage for reviews and unit tests is mandated in the FDD presecription. By reducing rework caused by poor initial quality, this reduces variation in throughput. In addition, the prescribed design techniques using Coad Method object modeling and UML sequence diagrams for each Feature design reduce the variability in design techniques and increase the reliability of the solution.

These first four pay the highest dividends as they directly address the main variable - rate of Feature production. It’s no accident then that the Coad Method and its evolution Feature Driven Development focused on (1), (2) and (4) and that the SEI’s PSP/TSP methods focus on (2), (3) and (4).

(5) Limiting Work-In-Process Inventory

We could use a Kanban-style system to limit the size of work-in-process, preventing new Features from being started without completion of others, even if those others are blocked with issues logged. Note, this would provide the equivalent of “pulling the chain” or “stopping the line” in a Lean/Toyota-style manufacturing line. The Kanban system would limit WIP and force quick root cause analysis and resolution of issues. Limiting WIP has been shown to be directly related to lead time. My own work published in several papers last year showed that I have empirically observed that Little’s Law holds for software engineering.

The SEI has objective data that shows that lead time correlates to software quality - in terms of inserted defects. My empirical observation with FDD projects would reinforce this. Small batches with short lead times correlate to higher initial quality.

Hence, limiting WIP has a secondary effect on variation in the constraint - it reduces rework caused by poor initial quality. We can see from this that a Kanban system for software engineering has some value but is definitely secondary to improved techniques in requirements analysis, time management, initial quality assurance and pride-of-workmanship and dedicated single project resourcing. For this reason, introducing a Kanban-style system in Visual Studio Team System is not a priority for me.

Saturday, April 16, 2005

Deming and Goldratt #1

OK! So how many readers spotted the relationship with yesterday’s driving variation out of the constraint techniques and Goldratt’s 2nd step in the 5 focusing steps of TOC - exploit the constraint? Yes, driving variation out of the throughput variable in the constraint is an exploitation technique. By reducing variation, we can guarantee that we get the maximum performance from the bottleneck resource.

Notice how I carefully selected the variable I was going to focus on. I could have chosen the speed of the vehicles or the vehicles-in-process inventory (the density of traffic) on the freeway, but instead I chose to focus on the distance between traffic and the rate of cars passing the bottleneck point at the entrance to the bridge - the takt time at the output of the bottleneck. By careful selection of the variable for variation reduction I can align the techniques of Deming and Six Sigma with the five focusing steps from Goldratt’s Theory of Constraints. The flip side of this is that unfocused reduction of variation produces little productivity improvement. This is the main criticism of 6 Sigma leveled at it by the TOC community. This example shows that it doesn’t have to be an either/or choice - you can do both!