Relationships, Traditional vs Lean Training

(Originally posted 2003.Apr.29 Tue; links may have expired.)


Very funny web-page: "Things my girlfriend and I have argued about "http://homepage.ntlworld.com/mil.millington/things.html. This is one bit my wife and I found funny:"Just for reference; if Margret returns from having her hair cut and says, 'What do you think?' and you reply, 'I'd love you whatever your hair was like,' well, that's very much The Wrong Answer, OK?"

Rus Rufer, on the IXP mailing list, mentioned two lists comparing traditional and lean project manager training that were in a draft of Lean Software Development, but which did not make it to the final version:

Traditional Project Manager Training

Software Development Life Cycle (SDLC)

PMI Knowledge Areas

Schedule and Cost Estimating

Critical Path Analysis, PERT/Gantt Charts

Using Project Management Software

Project Scope and Change Control

Project Tracking and Schedule Control

Testing and Quality Assurance

Deployment and Support

Risk Management

Resource Management

Contract/Vendor Management

Lean Project Manager Training

Seeing Waste

Value Stream Mapping

Feedback

Iterations

Synchronization

Emergence

Options Thinking

Last Responsible Moment

Set-Based Development

Pull Systems

Queuing Theory

Cost of Delay

Self Determination

Motivation

Leadership

Expertise

Perceived Integrity

Conceptual Integrity

Testing

Refactoring

Contracts

On the XP mailing list, there has been some unhappiness at the name "Industrial XP", fearing that it will divide the XP community, and perhaps weaken attempts to "sell" XP into companies.

The IXP web page says "Industrial XP is tuned to handle the needs of large scale, mission critical and enterprise applications" which could be taken to imply that "Classic" XP (I might get some hate-mail for that name, which I didn't make up) hasn't had success in mission critical and enterprise applications (which would be wrong). I think the emphasis I heard at the BayXP presentation, that IXP is turned for "highly political organizations" is actually the correct differentiator between IXP and "Classic" XP, but that doesn't make the best advertising copy.

Ron Jeffries would like the IXP web page to say something like this:

IXP is Extreme Programming.

Extreme Programming, like any good software development method, is always adapted to the context. As a project gets more connections into the enterprise, it needs different practices, and for best results, these need to be consistent both with the enterprise needs and the principles and values of Extreme Programming.

XP and Agile software leaders, including Industrial Logic, have been applying Extreme Programming to larger scale, mission-critical, distributed, and highly-coordinated projects for some time now. We offer here a summary of the approaches and practices that we have used, and that our colleagues have used, in adapting XP to larger-scale situations.
And, Mark Simmonds wants us to know that DSDM 4.2 (not yet released), which blends DSDM and XP, is not the same as EnterpriseXP, which is supposed to be a web-portal to discuss ways to make XP more commercially appealing. Mark also says "One other point I'd like to clarify is that when using DSDM and XP together we do not advocate getting rid of the planning game, far from it. In fact I was delighted to see how closely the Planning Game matched the Timebox planning process I have used in DSDM projects for a number of years."

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

Quotes and Evolutionary Design Practices of Industrial XP

(Originally posted 2003.Apr.27 Sun; links may have expired.)

David Schmaltz said on the IXP mailing list: "Change never rests on the permission of the willing, but in the hearts of the brave and foolhardy." Let's hope we have supporting practices to not be too foolhardy. On the XP mailing list, Joshua wrote: "...most people react to change as if they are losing something. It's wired in to our human nature. I introduce XP into environments all the time. People think they're gonna lose something rather than gaining something with XP. I help them learn that they will be gaining a great deal."

On the IXP mailing list, Russ Rufer has provided the list of practices of IXP's Evolutionary Design:

Rapid Return on Investment

Risk Reduction

Backtracking

Selective Automation

Team Intelligence

Walkthrough

Spanning System

Small Iterations

Multiplicity & Selection

Dead Reckoning

I snipped quotations from this report

http://www.sdmagazine.com/documents/s=7928/sdmsdw3d/sdmsdw3d.html, onto the IXP mailinsg list, and no one contradicted me, so here are some stabs at defining what some of the practices may be:
Rapid Return on Investment - Developing only what needs to be done at the moment, leaving the rest to be filled in later, allowing early releases that can prove themselves quickly.

Risk Reduction - Striving for design simplicity is a factor for reducing risk.

Backtracking - Stepping back to find a simpler solution to a problem. "Backtracking not only helps you to consider other alternatives, it allows you to rewrite, aggressively refactor and prune any dead code."

Selective Automation - "Quantity bows to quality: It's not about writing tests; it's about writing good tests"

Team Intelligence - "Developers should devote maximum attention to improving the code."

Walkthrough - "Studying, living and breathing code is at the heart of evolutionary design"

Spanning System - "Evolving the code from a rudimentary system that, though primitive, provides end-to-end functionality. This simple working application is a thin, vertical slice of the project that offers insight into both essential and unnecessary features. Illustrated with a simple blackjack problem. To span the system, they chose just one case with two known hands and incrementally built the system to accommodate the full deck. "

Small Iterations - "To implement a hotel reservation system, you might first implement a program that reserves just one room before developing the whole system. These small iterations can be viewed as embryonic versions of the system, and can be taken to the customer for feedback...this is the antithesis of RAD—instead of throwing your code away, you evolve it."

Multiplicity & Selection - "Consider a multiplicity of design and selection, like the photographer who takes 10 rolls of film to find the perfect shot. Survival of the fittest."

Dead Reckoning - "Navigating without explicit instructions, by heading in roughly the right direction, and using feedback to make adjustments and to motivate backtracking."

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

What is Industrial Extreme Programmging?

(Originally posted 2003.Apr.24 Thu; links may have expired.)

At the BayXP meeting last night, Joshua Kerievsky, Russ Rufer, Somik Raha, and Tracy Bialik of Industrial Logic gave a presentation on their version of XP that they have developed over the last several years. They named it "Industrial Extreme Programming" (IXP). What follows here are taken from my notes. Any errors are my own.

IXP is what Industrial Logic has been doing the past few years as they work with their clients in training and coaching XP projects. Joshua said he was concerned with recent "blendings" of XP and other methods (DSDM, FDD, Scrum, Crystal) because some of those blendings were throwing away XP's planning practices (one of the most valuable aspects of XP). Many of these blendings were for the most part untried and unproven, as well, though the unblended methods have records of success.
IXP doesn't remove any of the core practices of XP (except Metaphor, and few teams have really felt like they successfully used XP's Metaphor practice). IXP builds on XP, adapting it for survival in larger companies, highly political companies, and large teams.

Kent Beck defined four values of Extreme Programming, values he felt were essential... other values were good, but he wanted to emphasis four in particular. XP's values are Communication, Courage, Feedback, and Simplicity. Agile Modeling adopted those four and added Humility.

Joshua and his team have chosen five values, which they not only want to emphasize, but insist that the absence of these values in the project or company will cause failure and unhappiness. The IXP values are: Communication, Simplicity, Learning, Quality, and Enjoyment.

The value of Enjoyment is sometimes deemed controversial. Joshua considered Fun, and probably felt Enjoyment sounded better. People who enjoy their work are more likely to want to learn I've always said that XP requires a Learning Organization). People who enjoy their work and enjoy working together are more likely to have the teamwork that XP requires.

Quality is "we know it when we see it." Quality products, quality code, a quality process, quality people.

These are the original XP practices that IXP includes (more or less), sometimes with modified names and meanings: [names in brackets are the original XP names, or the names I prefer over Kent's names.]

Sustainable Pace

Planning Game [Release Planning, Iteration Planning]

Frequent Releases [Small Releases]

Refactoring [Merciless Refactoring]

Story Test-Driven Development [Programmer Tests, Acceptance Tests, TDD]

Continuous Integration

Pairing [Pair Programming]

Collective [Code] Ownership

Coding Standard

Domain-Driven Design [replaces Metaphor]

Evolutionary Design [replaces Simple Design?]

The name changes are for clarity and to expand things beyond just coding -- people can pair on other things besides code, collective ownership can extend beyond code.

The new practices are:

Readiness Assessment

Viability Assessment

Project Community

Project Chartering

Test-Driven Management

Storytelling

Storytesting

Small Teams

Sitting Together

Continuous Learning

Iterative Usability

Retrospectives

Readiness Assessment answers the question "Are they able to transition to IXP?" Seehttp://www.industriallogic.com/xp/assessment.html.

Viability Assessment answers the question "Is the project idea viable? Profitable? Feasible? Does the project have the necessary resources?"

Project Community expands on Kent Beck's "Whole Team" concept. "People who are affected by the project and who effect it." (Hope I got that quote right.) This includes QA staff, middle and upper level managers, tech support staff, programmers, DBAs, customers, end-users, and probably marketing and sales. (Reference to David Schmaltz / True North Consulting's Project Community Forum.)

Project Chartering provides the Vision and Mission, as well as the definition of who is in the Project Community. A light-weight exercise that seems to be necessary for clarifying the project's goals.

Test-Driven Management requires objective measures be defined for the success of the project. External results like "support 100 users by December 2003." The Whole Team cooperates to achieve this goal. Also defines return on investment.

Sustainable Pace. They considered renaming this to "Slack" (see the book by Tom DeMarco). An example of the value of slack is that it can provide the time for someone to write the tool needed to increase development speed -- too much focus on getting stories implemented quickly can be sub-optimal.

Storytelling. I think Joshua separated this out from Planning Game in order to emphasize that story-telling is a natural way to get requirements (sometimes after a bit of coaxing). IXP stories are not necessarily "user-centered" stories, since they may address concerns of administrators, maintainers, etc. "A story is an excuse to have a conversation." Conversation is required to understand some stories -- a story that can't be understood can't be implemented. Five words for a story title was also mentioned.

Storytesting. One word, to parallel Storytelling. This is defining the acceptance tests, but not writing them. IXP coaches help their clients in both Storytelling and Storytesting. Ideally, you do want "executable documentation" and they talked up Fit by Ward Cunningham - a framework that allows anyone using any editor capable of creating HTML tables to be able to specify acceptance tests. (Programmer help is still required to plug an application into Fit's acceptance test framework.)

Planning Game. Joshua says that it is very weird that some of the hybrid methods are throwing away the planning game. This practice is so useful that many of Industrial Logic's clients, who did not adopt all of XP, did adopt the Planning Game. Still, the concept of "velocity" (work done per iteration) seems to elude some clients

Frequent Releases - frequent end-user releases -- same as XP's practice. Enables rapid return on investment. Releasing to end-users provides opportunity for feedback, to find issues in deployment, issues raised by real live users. "Without learning, feedback does no good".

Small Teams -- for large projects, set up networks of small teams, with their own code-bases and coding rooms. A 30-person project might consist of teams as large as ten people and as small as three. Sometimes there might be a testing team and/or refactoring team that join the each of other teams at various times and then move on. Industrial Logic practices Pair Coaching, which does not require that both coaches be together at all times. Pair Coaching does enable coaching larger projects than a single coach could cope with.

Sitting Together -- Joshua says that the term "Open Workspace" turns some people off, but it is the same concept. He has seen a 40-person XP team in one very large room, but that's unusual. He has also seen one or more people give up the office they worked hard to get, because pairing in the same room as other people let them focus better and learn more. Sitting together / pair-programming can be done via internet collaboration, so it isn't limited to open workspaces. The gave an example of a team split in two time-zones, who decided to synchronize their hours to allow more "virtual pairing".

Continuous Learning. I've always said that XP requires a Learning Organization, and this practice make it explicit. Examples... Study groups who are not just allowed, but encouraged to get together for three hours a week, during office hours, because they know this helps them advance in their careers. XP Coaches who assign practice drills to the programmers or QA testers. "Lunch Break" learning groups show that management doesn't care enough about their employees learning. An XP coach in Italy spends an hour a day teaching his junior programmers -- whose skills are rapidly advancing. I think an member of the audience said "If everybody isn't learning, then learning becomes a subversive activity." Joshua also said that "resume-driven-design" tends to happen because programmers are starving to learn, but not given opportunities to do so.

Iterative Usability. The UI must be usable and tested regularly. Management-Tests should be tied into Iterative Usability. Redesign the UI as soon as feedback shows its flaws. Paper-based GUI design was also mentioned.

Time was running out, so the remaining practices were discussed quickly...

Evolutionary Design. Drives all design. Their tutorial has ten practices for this. (http://www.sdmagazine.com/documents/s=7928/sdmsdw3d/sdmsdw3d.html.)

Coding Standard. Have one.

Pairing. As per XP, but not just programmers.

Collective Ownership. As per XP, supported by tests, pairing, etc.

Retrospectives are a critical practice. Some clients are reluctant to get 40 people together for 2 or 3 days for a full project retrospect, but they should do it for the unexpected learnings that come from it. Also do mini-retrospectives each iteration.

Refactoring. Early and often as per XP. Don't let "refactoring debt" accumulate.

Domain Driven Design. Even though never officially a part of XP, it has been done by every good XP programmer that Joshua knows. The Model objects are kept separate from the rest of the code (GUI, etc.) The acceptance tests normally operate on the model objects, skipping the GUI. See the book on this subject at http://domainlanguage.com/. See also Erik Evan's "Ubiquitous Language".

Story-Test-Driven-Development. First write a failing acceptance tests. Then use the TDD cycle (failing programmer test, code to make programmer test pass, refactor) until the acceptance test passes. This is "top-down" TDD, and it best avoids writing unnecessary code.

Continuous Integration. As per XP.

See http://www.industrialxp.org/ for more information. Check out these papers, too: http://industriallogic.com/papers/index.html

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

Against Command And Control

(Originally posted 2003.Apr.23 Wed; links may have expired.)

Dale writes in "Dale Emery, Bureaucrat" that his department was being changed from serving others to ruling others.

I think this increase in command and control is a recent trend in the industry, a fear reaction to the current economic climate. But remember: "The more you tighten your grasp, the more star systems will slip through your fingers." -- Princess Leia, Star Wars.

Hmm. I suppose a quote from a fictional character isn't the most effective. How about this: "If you are distressed by anything external, the pain is not due to the thing itself but to your own estimate of it; and this you have the power to revoke at any moment." -- Marcus Aelius Aurelius (121-180 AD), Roman emperor. And this: "An intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction" -- Hoshang N. Akhtar

I'm going to have to read more about Deming. These are his "14 points":

1. Create constancy toward improvement

2. Adopt new philosophy

3. Cease dependence on inspection for quality

4. Minimize cost

5. Improve constantly

6. Institute job training

7. Institute leadership

8. Drive out fear

9. Break down barriers

10. Eliminate slogans

11. Eliminate management by objective

12. Right to pride of workmanship

13. Institute self improvement program

14. Accomplish transformation

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

More on Reset, Encapsulation, Value and Immutable Objects

(Originally posted 2003.Apr.19 Sat; links may have expired.)


A reader suggests that I could use reference counted smart pointers to avoid problems I described previously.

That would not fix the problem of violating encapsulation -- retaining one object's member data in multiple other objects. In fact, in this application, if we were using boost::shared_ptr or our own reference counted smart pointer, and did the 'delete'/'new' approach, the result would be multiple "platform independent document objects" in a program designed to have only one document object. The various distinct views of the document would get out of synch. (I do use boost::shared_ptr in my application, to enable passing around large image objects among image processing functions as if they were Value objects -- I don't have to worry about premature deallocation.)

The same reader suggests that a Reset method isn't that bad... He writes "Functional requirements for cleaning self up logically belong in the object, not in delete/new."

I would say that in C++, the requirement for an object cleaning self up belongs in the destructor, by definition of "destructor". Whether the coder does the same cleaning up in Reset is up to the coder.
Probably the real reason for my dislike of Reset is that some coders using it seem to have confused "variables" with "objects". You reset a variable. You create and delete objects. In the application I was talking about, the object has effectively become a global variable, with all the problems that globals have, even though only member variables are being used.

In some ways it is even worse, because these variables are actually pointers to a global object: those pointers can become dangling pointers if the object is deleted by what is supposed to be its sole owner. Using Reset hides the fact that this is a global... better to make it a real global variable, to avoid the dangling pointer problem, or not pass it around at all (which is what LoD recommends). The application I was describing is a single-document application, so the MFC document object is effectively a global variable/global object.

My other point about Reset is that Value objects don't need it, and Immutable objects can't have it.
Imagine a Dimension object. In Java or Smalltalk, you might want to make it immutable, so you can safely return Dimension member values without making copies. This assumes that you don't do lots of math on Dimension objects -- because that would require making copies. It is a choice of which is more efficient, and/or safer.

In C++, I would implement Dimension as a Value object - one that implements the copy constructor and the assignment operator (and default constructor for STL compatibility). Returning this kind of object "by value" automatically makes a copy. If you want to reset a Dimension variable, just assign Dimension(0,0) to that variable. You minimize the number of methods to write, and you make it very clear what you're doing.

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

Law of Demeter and Encapsulation

(Originally posted 2003.Apr.18 Fri; links may have expired.)

The Law of Demeter (LoD) is a heuristic for good object encapsulation. Ignore the Law of Demeter (and other advice on encapsulation), and you'll find yourself in a debugging and refactoring hell. Applied too strictly, LoD forbids container objects and external iterators (there may be a loop-hole for that, which I'll get back to later).

Yesterday, I wanted to eliminate a "reset" function in one object, and instead have its owning object delete and re-create that object. That should be straightforward, but it didn't work because encapsulation and the Law of Demeter were being violated.

The problem here was that a pointer to member variable of this "reset-able" object was being passed around and retained by other objects, whose lifetimes are longer-lived than that member variable would be if I implemented the delete and re-create strategy.

I've trained myself to never give out a member variable's address, just like a TV network never gives out a TV star's address. It's dangerous. It causes the program to be more brittle. It violates encapsulation. You never know what those obsessive fans or programmers might do. Other objects become too dependent on the internal state of another object -- changing the internals of an object becomes difficult. Polymorphism is overly restricted because any "replacement" class must also give out a member variable's address, and that variable's type must be compatible. As I said, I trained myself, but sometimes I forget, and I'm working with other people who sometimes also forget about this danger.

In C++, an alternative to returning a pointer to a member object is returning a reference to a member object, but that turns out to be just as bad. I'll illustrate with some code.

Pointer* ptr = obj.GetMemberAddress();
delete obj;
// ptr is now "dangling" - pointing to deleted memory.

Reference& ref = obj.GetMemberReference();
delete obj;
// ref is now "dangling" - it also points to deleted memory.

No one would write code that obviously bad, but put in an event-loop, lots of intervening functions and other objects, and maybe some threading, and the same thing can happen without anyone realizing it until the crash occurs.

You could make a rule to never retain such a pointer or reference... that is an improvement (as long as no one breaks the rule), but it is awkward. It also requires that you never pass the pointer or reference into functions. It's too easy forget where the pointer came from, and create a persistent object holding that pointer. And that dangerous "persistence" include multi-threading as well as objects - a thread's lifetime is even less predictable than an object's, and it becomes much harder to diagnose dangling pointer problems in multi-threading programs.

So LoD forbids this:

memberPtr = obj.GetMemberAddress();
memberPtr->DoSomething(); // potentially changing obj's member state.

It also forbids this:

obj.GetMemberAddress()->DoSomething();

What you should do, is either return a copy of the member, and the copy's lifetime is no longer under the control of "obj", or incorporate DoSomething() into the API of "obj".

So we can write:

memberValue = obj.GetMemberValue(); // returns copy
memberValue.DoSomething(); // doesn't affect obj's original member state.

We can even write:

obj.GetMemberValue().DoSomething();

because DoSomething is operating on a copy. NOTE: if you write this sequence of calls more than once, XP requires that you remove this duplication, most likely by incorporating DoSomething into the API of "obj".

Returning a copy is particularly useful for 'basic' types like String, Date, and so on. The safe programmer will return a copy of a string or date member variable, so that callers can not change the state of the member variable "behind the owner's back'".

Some of the more rabid fans of the Law of Demeter say that even this operating on a copy is too fragile, and you really should do this:

obj.DoSomething();

The danger of over-applying this idea is that your object interfaces get really fat. You really don't want to re-implement all of the member functions of String for each of the String members in your EmployeeData class just because you think LoD tells you to. Because of this, I think of the "Law" as more of a "Recommendation".

I assert that immutable objects are an exception to the Law of Demeter.

Java's String class is immutable (once the object is created, it can't be changed), so Java programmers don't have to make copies of String member variables in their accessor functions.

Some people have recommended declaring mutable and immutable interfaces, declaring the mutable object to implement both of those interfaces, and declaring this "accessor" function's return type be just the immutable interface, so that you can return a mutable object through that immutable interface. Of course, a programmer could "down-cast" back to the mutable type, but then all sorts of bad things can be done if you work at it. Probably better to create a copy of the object to avoid the down-casting trick. And, in languages like Smalltalk and Python, you don't have variable and function type declarations to make this immutable interface idea work (though you could create and return an Immutable Adapter to enclose your mutable member.

And what about that loophole for containers and external iterators?

LoD says you can't return references or pointer to your object's own member data, but containers are given data to hold, and so they can return that data.

External Iterators are new objects, not member objects, created when you call the a function that returns the iterator.

So what am I going to do about my hard-to-modify program?

Well, changing it to conform to LoD is going to be at least a day's worth of work. And we violated LoD on purpose, though now I regret that decision. We have a MFC Document object that owns a platform-independent "document" object. We pass the MFC Document object to other MFC classes, and pass the platform-independent "document" object around to the rest of our code. But we're not consistent about that.

To make this conform to LoD, the platform-independent object must never be passed around to other objects at all -- everywhere we currently do this, we should be passing around that MFC Document object instead. That means that the complete interface of platform-independent "document" object must be implemented in the MFC Document object, delegating to the member object. However, the "type" we pass into various part of our program doesn't have to always be the MFC Document type, it can be a base-class type -- the platform-independent "document" interface -- we just have to declare the MFC Document type to subclass from that interface.

Then, and only then, could I have the MFC Document object have full control over the lifetime of its member objects (and even then, I have to be careful about threads - I can't delete an object if another thread is still using it.)

And why would I want to eliminate a "reset" member function and instead delete/re-create the object? Because it's too easy for a reset member function to forget to clean up all of its state. I object to "reset" functions generally, for both small objects and large objects like documents. For small objects, I prefer immutable objects that I can easily recreate on demand, because then copies don't have to made in accessor methods, and immutable objects are more easily made multi-thread safe.

For future thinking: how can LoD work with threads? Can we think of the thread as an object? Some platforms do.

Here's a "formal" version of LoD: A method "M" of an object "O" should invoke only the the methods of the following kinds of objects:

itself

its direct member objects

its parameters

any objects it creates/instantiates

[my extension] any objects created but not retained by a member object or parameter

Here's the informal version attributed to Peter Van Rooijen:

You can play with yourself.

You can play with your own toys (but you can't take them apart).

You can play with toys that were given to you.

And you can play with toys you've made yourself.

See http://c2.com/cgi/wiki?LawOfDemeter for more discussion on this topic.

See http://www.ccs.neu.edu/home/lieber/LoD.html for a list of LoD links.

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

Frequent Releases to End User

(Originally posted 2003.Apr.14 Mon; links may have expired.)


One of the best books on Extreme Programming is Planning Extreme Programming by Kent Beck and Martin Fowler. It doesn't tell the customer how to gather requirements, but it gives lots of advice on how to do XP from the customer side... particularly Release Planning and Iteration Planning, and why, of four variables (Time, Scope, Resources, and Quality), he suggests only letting Scope vary.


Kent Beck's prose is highly factored -- he tends to say things once and only once -- so you have to read carefully. He doesn't explicitly define what a "release" is, but there are clues that he really does mean releasing to the end-user... when he talks about releasing to internal testing, or to the Customer (standing in for the end-user), he uses the phrase "interim, internal release". Here are few quotes from the book about how often to release:

Often the dates for a project come from outside the company: 

* The date on the contract. * COMDEX * When the vc money runs out. 

Even if the date is of the next release is internally generated, it will be set for business reasons. You want to release often to stay ahead of your competition, but if you release too often, you won't ever had enough new functionality to merit a press release, a new round of sales calls, or champagne for the programmers. (page 40) 

Short Releases 

Sometimes you can release much more often, maybe every iteration[....] However there is danger to never having "a release". The customer may lose strategic vision of where the software needs to go. (page 79) 

Long Releases 

What happens if you can only release once a year? [...] Another case is shrink-wrap software [...] look for a way to send intermediate releases to those customers that may be more interested in these versions. Call them service packs or something[....] Frequent releases are good, but if you can't release frequently you don't have to abandon XP completely. You may need to create interim releases that are only available internally. (page 80) [Bold emphasis is mine.]

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

Proposal: an Information Radiator for Feature Requests

(Originally posted 2003.Apr.13 Sun)


Consider tracking feature requests using a cork board... (one cork board per product) each time a feature request comes in, compare it to what's already on the cork board. If it's not there, find a place on the cork board for it, write it on a sticky note or index card, and post it. If it's already there, add a hashmark to indicate multiple requests for that feature.

At some point, start grouping the feature requests that are on the cork board... this set of 9 feature requests can be grouped under "scriptability", this set can be grouped under "import/export", this group can be grouped under XX or YY.

Imagine this cork board visible to everyone at the company... other people could add cards to the cork board, because they see a missing area. The VP could add a comment to the XX grouping, saying that these features are not valuable to the more profitable customer base they want to target, only those laggards that haven't upgraded to the latest product version. Customer Support representatives could add to the cork board those off-hand comments said by end-users that they didn't think important enough to file as a formal feature requests.

Imagine being able to see patterns and order emerge out of the chaos of individual feature requests... someone sees this and says "I have an idea for a new product line!"

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.

Bits and Pieces

(Originally posted 2003.Apr.12 Sat; links may have expired.)


Yesterday afternoon, the Bay Area weather was so nice that I dragged myself to work with some effort. I had previously signed up and worked on a story that I knew I could finish off by the end of the day, and I didn't want to not finish it and loose the three story points from my team's velocity. So I do the hard thing and get the work done. And today, Saturday, it is raining. Bleh.

I'm sure that the weekly traffic patterns affect the weather -- all that automobile pollution keeps the area warmer than normal, and then on Saturday the cold and rain comes in because there's little traffic. Or something like that. I've read that California gets some of the pollution generated by China, so maybe Beijing's weekly traffic/pollution patterns are at fault.

Another bit on agile requirements... XP doesn't say how to gather requirements. RUP does. I attended one of the presentations by Dan Rawsthorne of Net Objectives, a presentation called Comparing RUP, XP, and Scrum: Mixing a Process Cocktail for Your Team (Check that link for their slides in PDF form). Dan recommends combining RUP's Use Case creation techniques, with Net Objective's own "Ever Unfolding Story" technique, to create stories for XP's release plan/iteration plan. He says that a typical Use Case can create up to forty XP stories. Maybe ten of the stories are the "core" of the Use Case and can be delivered in one or two iterations. Another ten may be important for the final release but of lower priority. The other twenty stories may not need to be implemented at all -- but a typical heavyweight RUP project probably would have implemented them. If you have question about this or the "Ever Unfolding Story", please talk to Dan at www.netobjectives.com... I'm just reporting here.
I do want Dan to correct one of the slides... the one about XP and the "business levels". The slide about RUP shows RUP "touching" the business level at "kickoff", "delivery 1.0", "delivery 2.0", and so on... Dan asserted that XP doesn't "touch" the business level, and drew the slide on page 22 of the PDF file that way. That's WRONG. XP's "Small Releases" correspond exactly to the RUP process slide's "delivery 1.0" and "delivery 2.0". Those releases every three or six months are at the business level, to get feedback from actual users.

I also attended a one-day class on Project Management recently. The simulated project was waterfall, but the word "waterfall" was never mentioned. There was no mention of the possibilities for iteration, incremental development, or even feedback. I don't think any of those terms were in the vocabulary taught as part of class. The instructor had never even heard of Rational Unified Process ("Rational Who?"), much less Extreme Programming, Scrum, Feature Driven Development, etc. That's scary.

So what did I learn in this project management class? Well, the project process has Initiating, Planning, Executing, Controlling, and Closing. No mention of maintenance. Not much about people issues.

Planning included the "Work Breakdown Structure" (a rather unfortunately overly task-oriented breakdown of features that does have some resemblance to XP's "Release Plan", sorta.) We saw a "Responsibility Matrix" correlating tasks with "do, review, and approve" columns. We learned about finding the Critical Path on a Gantt Chart. A little bit of Risk Management and mitigation planning. And of course, "resource" allocation and management. [I'm having a vision ala Solyent Green: "Resources are people!"]

The "trade-off triangle" of Time, Cost, and Scope/Requirements was mentioned. No mention of the zeroth law of software engineering: "If you do not care about quality, you can meet any other requirement."

We learned a lot of vocabulary, with emphasis on "crashing" (adding resources to decrease the project schedule -- hmm -- like getting nine women to have have a baby in one month? No mention of Brook's law.) and "fast-tracking" (defined as "compressing the schedule by overlapping activities normally performed in sequence").

My hand-out from this one-day class says "the PMBOK is the standard knowledge source for project management," and lists a bunch of books. Some of the books I've heard of -- Critical Chain by Goldratt, some of them I've read -- The Deadline by DeMarco (I wish he could go back and write an "agile" second edition or sequel), some of them sound good Customer-Driven Project Management by Barkley & Saylor, and some of them are just scary -- The Complete Idiot's Guide to Project Management.

---

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.