Thursday, November 13, 2003

more Pokayoke

Keith Ray gives a fine example of test-driven development (TDD) today. He argues that TDD represents “software pokayoke” (mistake proofing of the development process). However, I fail to be convinced. [Sorry to disagree here Keith ]. I see TDD as quality assurance. There is a subtle difference between mistake proofing a process and failure proofing a product or service. I think the real “pokayoke” in Keith’s example is in this quote…<!—StartFragment—>

So how do we know the test is a valid one for the requirements? Well, it looks good to me. I ask my pair partner; he thinks it looks good, too. Since we’re doing Extreme Programming, we ask our on-site customer what the log should look like. She looks at our test and says “This displayed text should have an exclamation mark at the end.” So we add “!” to the end of the strings in our tests.

The inspection process on the test to validate that it assures the match of output against the requirement is the real “mistake proofing”. The inspection step of asking both the pair programmer and the on-site customer if the test is accurate is the vital piece of mistake proofing. That step must be part of the process and it must be conducted or there is a risk that a test will run but be testing the wrong thing. That is Pokayoke!

Wednesday, November 12, 2003

Highsmith: Agile Project Management

Jeff De Luca is offering early access to Jim Highsmith’s new manuscript, “Agile Project Management” from the Feature Driven Development website.

Tuesday, November 11, 2003

Business Rules in Aspects

I’ve been wondering about how to separately encapsulate business rules. If you’ve been following my posts on this topic, then you’ll know about The Business Rules Approach and how it separates out domain model from business rules from (user) tasks. The Nicola & Mayfield book Streamlined Object Modeling shows how to map business rules onto a domain model.

However, I find this Nicola/Mayfield approach unsatisfactory. It does not separate out the concerns of domain versus business rules. There is no separate encapsulation of the rules. Rules have a far higher uncertainty and variability than the domain. Hence, separate encapsulation would reduce the regression effect when rules are changed without impact to the domain model. The value of architecturally separating variability is explained Donald Reinertsen’s Managing the Design Factory. The purpose is two fold - it reduces regression effects from change, but it also reduces the overall variability in design effort which ultimately reduces schedules.

This paper, http://ssel.vub.ac.be/Members/Maja/papers/Cibran-BIS03.pdf”>Aspect Oriented Programming for Connecting Business Rules [PDF], given this year at Business Information Systems 2003 shows how to implement business rules using aspect oriented programming - cleanly separating out the rules into aspects. This provides the architectural separation of variability.

Hence, in a world where we capture requirements in a domain model, feature set, business rules and task flow (Visual Vocabulary or Statechart model), we will get the most ideal mapping of code to requirements by implementing the system using an aspect oriented language. This allows a much more accurate tracking of the flow of value. Aspect Oriented technology may lend itself to Lean Software Development and may contribute to pokayoke (designing out the possibility of failure). Encapsulation of business rules in aspects, automatically reduces variation and reduces the chance of failure.

Monday, November 10, 2003

Why Agile is not Lean?

Business Week examines the power train of Toyota and wonders if anyone can stop them? The article provides good insight to the advantage that comes from 50 years of developing just-in-time inventory systems, Deming quality assurance, designing out the possibility of failure and a process of continuous improvement.

There are 4* main aspects to Lean Production: Kanban (the notion of self-organizing flow regulation); Kaizen (the process of continuous improvement); Quality Assurance (Edwards Deming’s teachings on Statistical Process Control); and Pokayoke (the notion of designing out failure). [* As Hal Macomber points out , in the comments, this list should have included Muda (waste) as the 5th key element]. So far agile software methods have really only developed in two of these areas - self-organization and quality assurance. Despite the feedback loops in agile methods, they are primarily quality assurance loops not learning organization loops. And there is really no equivalent of Pokayoke in agile methods. In fact, early writings on agile methods suggested that tools were not important. There was an almost Luddite tendency to ignore tools and focus only on people.

The closest thing to Pokayoke in agile is the design and code inspections in FDD. However, these don’t go far enough. Proper Pokayoke would be using architecture and tools which design out the possibility of failure. Tools such as Statesoft’s JStateMachine represent “pokayoke for user interface”. A fully Lean software development method will include architecture, modeling and supporting tools.

My final word on this Toyota article is the observation that Toyota is a “failure tolerant” company which has transcended beyond a mere “learning organization”. Those familiar with Chapter 11 and 12 of Agile Management for Software Engineering will understand this. My proposal for an agile maturity model calls for a learning organization as level 4 and a failure tolerant organization as level 5. Toyota is clearly a level 5 organization on that scale.

Sunday, November 09, 2003

Chapter 3 - TOC in Software Production

Chapter 3 introduces the Theory of Constraints 5 focusing steps: identify the system constraint; decide how best to exploit that constraint; subordinate everything else to that decision; elevate the constraint; repeat for the next constraint. Using the systems thinking approach from Chapter 2, it then shows how to identify and exploit a constraint in software development. This is done using the production solution for TOC known as Drum-Buffer-Rope. The idea, introduced in Chapter 2, that inventory is defined as ideas for small pieces of client-valued functionality defined in the requirements, is used, and tracked end-to-end throughout the system. Where there is a bottleneck, inventory will not flow - it will stockpile at that point in the system. This can be identified through tracking.

The notion that requirements in software are “perishable” is introduced. Hence, the inventory is depreciating every day it is bottlenecked and not flowing. Depreciation in requirements implies change and this costs money. Hence, elimination of bottlenecks to ease the flow of inventory is essential for financial performance.

Chapter 3 then turns attention to the essence of TOC - focus. It shows how to focus management attention, time and money on the capacity constrained resource (CCR) in order to elevate and ease the flow of inventory through the system.