Posted by Robert Merrill on March 2, 2010 under Estimation, Project Set-Up, Software-Intensive Businesses | 
Q: Why were they late for the meeting?
A: They didn’t leave soon enough.
But…they got stopped by a train, and they remembered that they needed to pick up a loaf of bread, and…they have a slow car!
Details like speed limits and the police aside, what do the car, and the bread, and the train have to do with it? The trip took 25 minutes, five of it spent waiting for the train, and five of it in the convenience store, and fifteen of it driving. They left 20 minutes before the meeting, and they were five minutes late.
Well, they didn’t plan on the train or the bread.
Do they ever plan on the train or the bread?
On the train, kind of. On the bread, no.
Yet they’re nearly always late. Their software projects are, too.
But…they weren’t as productive as they thought, and Terri was ill, and they had this big interruption, and…
So they get a faster car.
Soon (if not before the first trip), they’ll factor the faster car into their decision about when to leave, they’ll still leave “at the last minute,” they’ll still make unplanned but important stops, and they’ll still be chronically late.
And, they’ll factor in the productivity gains of new languages and new tools and rockstar programmers and…
Q. Why are their software projects chronically late? (or always seem to turn into death marches—the project management equivalent of speeding, and fines, and points, and suspended licenses)
A. Their schedules are consistently too “aggressive” (or “absurd” if we want to be blunt about it).
Dude, it’s not about the car.
Posted by Robert Merrill on under Agile BA |
I finally got around to conducting a half day of training for some local colleagues who bear the title “Business Analyst,” and whose organizations (and in some cases careers) had been shaken up by the arrival of the Agile Methods (most commonly Scrum) in the Early Majority. There were only four of us all together, so it was delightfully conversational.
Here’s what the whiteboard looked like when we were done. (Click for a full-size view).
Whiteboard after a 3-h presentation about Agile methods by Robert Merrill and Q&A with three Business Analysts
We started out by describing our own encounters with various Agile practices and knowledge of Agile methods in general.
I explained my concept of the Load-Bearing Walls, and shared my opinion that the ignorance, or politically-forced disregard, of these is going to lead to the failure of many Agile initiatives in Early-Majority adopters.
This led to a discussion of the concept of technical debt, and how it presents itself to the non-technical parts of the organization. Automated testing is the key to technical debt management on an Agile project, and can be a point of resistance. On the business side, I’ve sometimes successfully countered the assertion that it’s “extra work” by likening it to double-entry bookkeeping.
I also tried to convey the “feel” of an Agile project to the non-technical people. On a Waterfall SDLC project, the turbulence starts low and rises sharply at the end. On an Agile project, the turbulence starts relatively high, rises to a peak through the first iteration, and then steadily dissipates. Being in the middle of helping two clients set up Agile projects, one for the first time, this feeling was fresh in my mind. I can understand the angst of those new to Agile. “If this project is this bumpy at the beginning, what’s it going to look like at the end!” I always explain the turbulence curve, and remind people that this is a stage we’re passing through, like the Storming of the “Forming-Storming-Norming-Performing” sequence of team formation. Many non-technical people are familiar with this model, and it seems to help them ride out the turbulence.
We then touched on some general Requirements Analysis concepts I have found useful. Even Agile projects benefit from an initial product backlog, or user story set, that isn’t full of gaps. I drew the “Requirements Merry-Go-Round” of
- User stories (functionality),
- Logical data model, and
- Wireframes (user experience),
and explained, “You jump on wherever the customer wants to start, but you have to go around at least twice” to find the gaps. Every entity in the LDM must appear in at least one user story, and must have a known source, either in another story, or from another system. The user stories should be traceable through the wireframes, and every wireframe must fit into at least one story. Finally, each entity must appear on at least one wireframe, whether for entry (a form), or viewing, or both. I explained how I had learned this technique while learning Function Point Analysis, and that if you stick to a low level of detail (whole entities and relationships on the LDM), it can be done very quickly. This follows another Agile principle I emphasized, that of diminishing returns.
We finished with a user story and functional test template, and practiced writing a few stories. We also ran an idealized version of the Agile “planning game” of
- Relative effort estimation by the implementors
- Prioritization by the users and people who write the checks
- Initial commitment based on the implementors’ subjective judgment, and
- Subsequent commitment based on extrapolation, not estimation.
I explained that the concept of variable scope was often another major point of resistance, even though it fit well with the reality of highly utilized software developers, uncertain initial requirements outside an obvious core, and the tendency of release dates to acquire a symbolic significance among senior management (and sometimes a very real business significance as well). This led us back to a Bob Martin quote from early in the talk, about “Abandoning the illusion of control at the beginning” of a project as being integral to Agile and also a stumbling block.
Throughout the presentation and conversation, I emphasized the importance and value of Business Analysts, not because of the deliverables they produce (which are fewer and less weighty on Agile projects) but because of the combination of analytical and people skills that they typically possess. On Agile projects, I usually find myself
- Analyzing initial solution concepts and finding missing stakeholders
- Facilitating requirements workshops—taking sponsors, subject matter experts, and developers through a couple of turns on the merry-go-round
- Analyzing the results and adding missed stories to the product backlog (feature list)
- Leading “estimation parties” that don’t just put points on the stories, but also help jell the business and technical people into a combined team through a story-by-story dialogue, and
- Calming everyone as the turbulence rises through project set-up and into and through the first iteration
It isn’t that these things must be done by a person with the Business Analyst title—that’s contrary to the agile principle of specializing generalists, and makes the project more brittle—it’s that these things are often done most effectively by people whose talents, skills, and experience have led them to the Business Analyst role in pre-Agile days.
Posted by Robert Merrill on December 17, 2009 under Agile Methods, Waterfall (SDLC) |
Serhiy Kharytonov published a fine summary of software methodologies for non-technical leaders at Executive Brief. He makes several excellent observations, but he also perpetuates a destructive myth. I’ve worked with all three of Waterfall, RUP, and Agile, and here’s my take.
Excellent observations
Then, stay agile in the approach to the process itself, constantly looking back, re-evaluating and revising the development process until it fits your current circumstances most successfully.
If you learn nothing else from Serhiy and I, learn this. Change from a culture of blame-fixing to a culture of continuous improvement, with no political unmentionables, and you will get a lot more value for your software-development money, and everything else besides.
Then, if you want to learn one more lesson the easy way rather than from a painful and expensive experience,read the Destructive Myth.
Here’s another excellent observation by Serhiy:
At the end of the day, the best method or blending of methods for you depends on a thorough understanding of all three processes and how they fit your software project, business culture, and development environment
Business sponsors and subject-matter experts, you’re a part of the team, too. Don’t just take the technical staff’s word for it. Waterfall, RUP, and Agile are about how the work is defined and managed, not about programming languages and other technical stuff. You can and should understand them, know which one you’re using, and why you’re using it.
RUP also defines the roles and activities of team members in depth…All team members have access to the same large knowledge base of guidelines, templates, tools, and other items to ensure that they share the same language and perspective on the project.
RUP™ stands for Rational Unified Process, a packaged set of tools and templates for running the Unified Process. The Unified Process is in turn a 1990s synthesis of several different processes designed to work well with object-oriented languages (e.g. Smalltalk, C++, Java, C#). Out-of-the-box RUP™ is all-encompassing. What often happened (and still does) is that RUP™ consultants “install” it without the buyers really understanding it. People are assigned “roles” they don’t understand and produce “artifacts” because the process says to, not because they help the team ship software and deliver value to the business.
RUP addresses many of the criticisms of Waterfall development
In particular, the UP (remember, RUP™ is a commercial brand of UP) explicitly focuses on exposing and reducing the risky parts of waterfall development, namely misunderstood requirements and failure of technologies to work as expected. It also introduces Use Cases, an easier-to-understand way of expressing requirements than “the system shall…” flavor of the old IEEE 830 standard.
Destructive myth
One dwarfs all the others, and it’s repeated throughout Kharytonov’s otherwise fine survey of methodologies. Of Waterfall, he writes,
“The goal is to gather all your detailed requirements early in the process and provide a single complete solution with results that are highly predictable.”
He then goes on to say that Agile lacks predictability and isn’t the best choice for
“Clients who want contracts with firm estimates and timetables”
The seductive, destructive myth is that , “The more detailed planning you do, the more accurate your estimates will be.” Rather than repeat myself, I’ll just refer you to my earlier post on Diminishing Returns—A Key Agile Principle and my Wisconsin Technology Network articles, Software sanity: Accurate estimates and other myths and A tale of two processes.
No matter how bad we all want it, the predictability’s just not there, and no methodology can change that. Neither can a fixed-price, fixed-scope, fixed-schedule contract. That’s just overpriced insurance for a risk you can manage yourself with a little bit of up-front learning and planning, followed by staying involved in your Agile project and managing for value within a budget and schedule you can still specify.
