Agile Modeling Vignettes

Start with the End in Mind, But Not Every Stop Along the Way

The Indiana Jones School of Development might advocate the approach "I'm making this up as I go, Kid."  But this could be a very risky approach for many mission-critical projects. If you don't know where you are going, then any road will do, won't it?  But if you have a clear, big-picture view of your goal then you can afford to be less precise in the tactile details of how you will achieve that goal. On a road trip, do you really need to plan for every location where you will tune-in a new radio station, or where you will stop to buy some roadside apples? Of course not: You won't know the apples are there until you get there. Agility is not ignoring goals or milestones. Agility is ignoring what needs to be ignored because you don't need it until you get there. And, as Martin Fowler has captured in his YAGNI principle: You Aren't Gonna Need It will apply more often than when you are going to need it.

One of my favorite examples of non-agile planning comes from a Project Manager on one of my consulting engagements. He spent weeks building meticulous precision into every development task he could think of. He asked me to review his Microsoft Project print-out. It covered a full page of plotter-size paper. I was awe struck. I didn't think anyone could waste so much effort. He had tasks down to 1/2 day (or less) duration for activities that were 5 months in the future. He asked a simple question, "Are you comfortable with these dates for you and your team?" My reply was just as simple: "I really don't have an interest in what your dates are. I have published the project plan that the development team has approved. It has the major review dates and delivery milestones on it. Those are the only dates I am comfortable with. If your dates don't match those, then you should change your dates."

He was speechless. I was amazed that yet another client poured a lot of money (rough estimate: $400/day at a full-burden rate of $100,000/year) into producing an artifact that was so precise that it was essentially meaningless. In long-term planning accuracy is much more important than precision. Focus on the big picture and let the developers do what they do best: solving the day-to-day tactical issues so they meet the big goals. 

Think Honeybees, Not Spiders

Programmers are often quite comfortable working in isolation. But don't model this way. Think honeybees, not spiders. Honeybees are social creatures and will die if they stay away from the hive community too long. Spiders are almost all isolated individuals. They do not thrive in communities (they tend to eat each other).

Modeling is a communal activity. Members of an agile software project must communicate continually, in multiple ways. An isolated modeler is a crippled modeler. Even if you enlist only one other person to partner with you, do it. No matter how good you think you are, you're never too good to benefit from a "second pair of eyes". If pair programming is excellent, so is pair-modeling. If you isolate yourself you are committing two sins: first, you cannot benefit from anyone else's insight, and second, no one will benefit from yours.

Listen for the "buzz" of the hive, and be concerned when you don't hear it. Establish an environment that allows the hive to flourish. Sometimes you might have to force yourself, or other team members, to maintain a closer proximity than they would choose on their own. Generate interaction, but be sensitive to everyone's different needs for privacy. <more...>

Evanetics' First Law of Modeling: Your First Model is Wrong....

...and the Second Law is: your second model is less wrong. You may never get it "right". You may have to settle for merely asymptotically approaching "good enough". So don't fall in love with your models. You don't need to keep most of them. That means you will actually discard most of them. In fact, if your models don't change over time, then you should be very concerned. No-change is a symptom that you are not letting go of your early ideas. And having a success on your last project is not much of a guarantee the same approach will succeed on your next project. Don't fall in love with you models, and don't believe your own Public Relations announcements. 

Jettison the Computer

Until you need it, that is. But you really don't need it for everything. Have you noticed that some people can't think without a mouse in one hand? On one project the manager brought in a contractor to assist in the object modeling and development. Our first meeting was in a conference room where the manager and I wanted to give the new contractor an overview of the project. As soon as he sat down he popped open his laptop with TogetherSoft's Together/J CASE tool running. He actually started to build a sequence diagram so he could generate code for the project!  But he didn't know what the project was yet--we were trying to tell him!  But he had deep convictions that code generation was what we needed. He even said he would generate all the code for the project through Together/J.

He just didn't get it. He and his laptop were gone the next day.

In another company I was teaching a Use Case development course. I told the entire class not to turn on the workstations at their seats because we would be doing all the exercises by hand. The manager of the business analysts, however, started using her computer to enter the first use case exercise. She intimidated everyone, but I strolled over and reminded her, "No computers for the exercises, please." 

"But this is so much faster and neater," she replied. She was a very retentive personality. I could tell this was going nowhere. 

So I just reached down and unplugged her monitor. Her screen went blank, the room went dead silent, and I gently told her, "But I want you and your team to concentrate on developing the use case, not entering it."  To her credit she took it in very good humor and she left the computer off the remainder of the course. 

Was I unfair? Not at all. It is neater to use a word processor, and sometimes faster. But my goal was not to have a printable use case that looked like a finished product. My goal was to get her team, and the others in the course, to interact, talk, argue and somehow grope their way to a textual description that captured a business process--a hand-written description that would actually look like the tentative effort that it was. Using the computer was a crutch for her; it served her retentive inclination to have everything NEAT AND TIDY!!!  Even if neat and tidy was a complete misrepresentation of the use case's real state.

Another session with business analysts developing use cases dragged to a stop because one of the analysts insisted on bringing his laptop to the session, and entering every idea into a Word document as the idea was presented. I let this happen just to make the session so painful that the team would throw him and his laptop out. Every other sentence he was asking, "How did y'all phrase that last sentence?" And we, of course, had to wait for him to catch up, delete words, copy and paste, and so on.  

Computers can't think, but they can be an obstacle to your thinking. Keep them under wraps until it is safe to bring them out.