Iterative Development: Some History
We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation].
When much of the same team was reassembled in Washington, DC in 1958 to develop ProjectMercury
Was There Process Before Agile?
the process models you mention and describe are Waterfall, Cascade, Iterative Enhancement, and Prototyping
Agile is much more than these processes, making explicit many team practices to support the iterative nature of the development
It’s not an Agile process if the customer (or surrogate) isn’t participating
Agile and the Definition of Quality
The reason for my dilemma lies in the relativity of quality
Take for example Crosby’s definition:
“Quality is meeting requirements.”
Unless your requirements come directly from heaven (as some developers seem to think), a more precise statement would be:
“Quality is meeting some person’s requirements.”
quality does not exist in a non-human vacuum, but every statement about quality is a statement about some person(s).
Recognizing the relativity of quality often resolves the semantic dilemma. This is a monumental contribution, but it still does not resolve the political dilemma:
*More quality for one person may mean less quality for another. *
Whose opinion of quality is to count when making decisions?
we see that software engineering is not a democratic business. Nor, unfortunately, is it a rational business, for these decisions about “who counts” are generally made on an emotional basis
Quality is value to some person
By “value,” I mean, “What are people willing to pay (do) to have their requirements met.”
Of course, much of the time these political/emotional decisions–like all important political/emotional decisions–are hidden from public view
- I don’t consider Agile any team with even one secret component*
As a consultant to supposedly Agile teams, I always examine whether or not they have active participation of a suitable representation of diverse views of their product’s quality
Five Questions on Agile
You may or may not stay out of trouble, but if trouble comes, you’ll see it coming in time to do something about it
challenge is to manage the human reactions to change.
I’ve been trying two new approaches
our Problem Solving Leadership workshop (PSL)
Fiction, or what I call “nerd novels.”
Manifesto for Agile Software Development
*Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. *
I can classify the major violations I see in the following categories
Paradoxically, our desire to satisfy our customer has placed us in a situation where we won’t satisfy our customer
Dennis Cadena employed The Rule of Three to come up with three things to look for
Bullying behavior • “Poor me” behavior • Flattery
“Maybe I am placating when I feel that I HAVE TO act in a certain way
For most of us, breaking these placating habits is a lot easier when we’re not face-to-face
Dwayne’s suggestion _(Write on paper what I want to say) worked well for me
The Yes-No Medallion, of course, is not just a No Medallion
Don’t say yes to a client’s first offer, but never say no
Satir’s Soft Spurn is to day something like “Thank you for thinking of us, but your idea doesn’t fit for us at this time.”)
Welcoming Changing Requirements
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
The engineers need to learn that they will never become an Anticipating organization by getting better and better at coding, even though that was the improvement process that brought them as far as they’ve come.
What Agile methods do not address directly is how those customers can know what their requirements really are. That’s the problem addressed by our books, Exploring Requirements: Quality Before Design
Deliver Working Software Frequently
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Many organizations fail to realize that this principle implies that software testing be an integral and continuous part of the development process, not something stuck onto a massive code base just before scheduled final delivery
the Edsel Edict:
If you must have something new, don’t have two.
Though newness can’t always be refused, it can always be de-fused
Engineering experience has shown that when designers use a prototype, they have a tendency to attempt too great a leap forward. Partly to justify the “extra” expense of the prototype, and partly out of the added confidence that prototyping lends to the project, they heap new features onto the product
Using Agile successfully, we must protect against the WIBINIs.
WIBINIs? What’s that? It’s an acronym for the phrase, “Wouldn’t It Be Nice IF?”.
check that everything in the code relates to a specific part of a specific story for the current iteration
the team’s customer must be made aware of the costs of added niceties
Business people and developers must work together daily throughout the project
As a consultant, when I learn that a project lacks daily contact between developers and customers, I can confidently predict failure
On the other hand, close contact between developers and customers can produce an unstable situation where the product definition changes in response to every whispered possibility
Motivated and Trusted individuals
*Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. *
Micromanagement is poison to would-be Agile projects.
if you can’t assemble a team you can trust, then you shouldn’t attempt to make it into an Agile team
If teams are consistently late and/or wrong, managers don’t really care if the developers are liars, incompetents, or simply at odds with the signs of the Zodiac. They learn that they cannot trust the teams, so soon they start taking steps to protect their own jobs.
Only after many rounds of recriminations, evaluations, and firings do managers begin to understand that they’re never going to find developers that can be trusted—mainly because programming is a particularly difficult thing for human beings to do. Then the managers start to implement systems of management—such as technical reviews—that compensate for the weaknesses that all people, even developers, have. (That’s why reviewing is a part of the Agile philosophy in the first place.)
Unfortunately, by this time the developers have plenty of reasons not to trust their managers. In such an environment of distrust, management would be suspected of evil intentions if they passed out envelopes full of cash
*We classify reviews into two main types: formal and informal. The only difference between them is whether or not the results of the reviews are written down and available to managers as an aid to managing. Informal reviews’ output is for the workers only, to help them improve their products. *
As the definition indicates, the word “trust” mixes up several different kinds of trust, including firm reliance on:
• the performance of a thing
• a person’s ability
• a person’s integrity
Properly managed, technical reviews are an effective way to build, or rebuild, trust. Wherever a system of technical reviews has been installed successfully, I seldom find the vicious cycles of mistrust between managers and technical staff members, or even between staff members, such as, programmers and testers
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
common prejudice against written communication. I see many would-be Agile teams who use this principle as an excuse for not writing anything, even when detailed written specs are the only reliable way to communicate such technical details as the exact interface between two systems.
In many IT installations today, the number one problem is program maintenance
face-to-face communication fails as a maintenance tool if the development team is no longer around. Many people have complained about this maintenance deficiency of the Agile approach, arguing that massive documents are necessary to overcome it.
the first tactic to lessen the difficulty of maintenance is this: keep teams together
Another maintenance tactic is the disposable program
But why not just keep all programs, for all time? That would be an excellent, simple solution, except for one thing: cost. A program brought out of hibernation can incur numerous costs
why, do we keep tumbling into the same trap?
the answer to the “why” question lies in our unwillingness or inability to feed-back the true costs of programming and program maintenance to our customers
service bureau clients
In internal data processing situations, especially where there is no true chargeback for programming or program maintenance, these lessons are difficult to teach
these two tactics will not eliminate all maintenance problems. If you want continuing success with Agile, you’d better face the remaining problems squarely
Except for truly disposable programs, any real system must be maintainable. Thus, maintainability is the job of the Agile team, just like any other non-functional requirement—efficiency, portability, security, and so forth. But maintainability is not something simply contained in the code. It’s a relationship involving the code, the documentation, and the environment in which the maintenance will be done
they will argue that the code says everything the maintainers need to know—but that’s a fallacious argument.
The code only tells what it does, not why it does what it does.
The conceptual problem IT managers have with this type of worker stems from their confusion between documentation and documents
There may be lots of other paper documents lying about, but what they’re lying about most of the time is the code
When a question arises that can’t be answered directly out of the maintenance programmer’s own head, the first source of information is old George who worked on this system a couple of years ago
assist the natural processes of documentation in doing programmers’ job—before trying to introduce artificial methods. For instance, since the code is the basic ground upon which all documentation is based, why not take steps to improve the quality of code as documentation?
The first step in such a code improvement program is to be sure that no code goes into the code database without having been read and understood by one or more people
improve the quality of individuals as documents. As a first step in this process, you should notice that when individuals leaves an organization, they lose most of their usefulness as documentation. Therefore, any policies that reduce employee turnover are likely to improve the quality of the living documentation
Why not have the designers on each part of the system take a few minutes to record the thought process that went into the design—the story that will be lost to view after a few months
each piece of code should contain a prologue cumulatively listing all the people who ever laid a hand on the code
meta-data for each line of code containing the name of the last person or team who submitted it
Even your regular paper documents should contain an adaptive index to the people who worked on or used them
identity of each person who read the document and at least partially understood it
Working Software is Primary
Working software is the primary measure of progress
Working software is indeed the primary measure of progress, but it’s not the only measure
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
After becoming winners, our five heroes each worked at a non-sustainable pace, largely due to the Pile-On Dynamic
When they’re overloaded, they tend to ignore any task that doesn’t contribute instantly to the primary task.
In other words, they can no longer pay continuous attention to what made them best-infomed in the first place
Continuous attention to technical excellence and good design enhances agility
Technical excellence comes not from heroics, but from continuous growth as a technical leader
what makes a team member grow into a team leader
Although good technical people are rare, their growth is at least more predictable than people who are good at working with others. That is, the spark of technical talent shows up early, and we know quite a bit about how to fan it into flame.
If a person lacks knowledge of the inner workings of a complex system, we can provide it through role assignments
Ability to work with diverse teammates is a learned skill
programmers are thrown onto “teams” with essentially no training in “people skills,” although their are many available mechanisms for improving those skills
the chief programmer approach .(see, for example, http://itinfralogistics
Because the entire success of the CPT revolves around the CP’s capabilities, the success of early CPTs actually depended mostly on who happened to be around to be chosen CP
Catching a moose is one problem, but maintaining it in the style to which it is accustomed is perhaps a problem of a higher order
Starting a Successful Team
how many people in the world meet your qualifications to be a chief programmer?” I asked.
Harlan held up both hands with his fingers spread. “Ten thousand?” I asked.
“No,” he said. “Ten
Maintaining a System of Teams
to maintain a CPT system, you need more than an initial supply of CPs. You need replacements
The principle of technical excellence means that not just anyone can qualify as an Agile team member
Congruent Interviewing by Audition
But the really interesting one-third took offense at the question and walked out of the interview. In fact, the question could be used partly for that specific purpose: as a simple way to exclude those who too readily take offense
Another mistake would be to ask for more than a ten-minute audition
It would also be a mistake if the candidate were given a deep design question and asked to give an answer in twenty-five words or less, in one minute or less
Simplicity—the art of maximizing the amount of work not done—is essential
We don’t really have a measure of simplicity of work. What I do have is a measure of bureaucracy:
The amount of work we do for which we cannot explain its purpose
Self Organizing Teams
The best architectures, requirements, and designs emerge from self-organizing teams
Yes, furniture arrangement is one aspect of self-organization, but more important aspects include the team’s working process, the role of each individual, and the acceptance and rejection of assignments.
Moreover, a self-organizing team is not permanently organized, but adaptive
Just leave them alone, and they will organize themselves.
The manager’s job with respect to an Agile team is to start it when a team is needed, leave it alone when it’s working effectively, and stop it when it’s not
To say more, many books have been published, including my book, Managing Teams Congruently (Volume 6 of my Quality Software Series
In a Self Organizing team, every member sometimes acts as a leader
PSL Workshop participants learn a number of skills critical to self-organizing team members, such as, how to:
when I’m confronted with a non-working team, I check a list of vital ingredients teams need. Nowhere on my list do I have the word “Leader.”
- a team is a system. Like any system, it won’t generally be understood by slicing it into little pieces*
We all do that sort of selective remembering when the facts don’t fit our favorite hypotheses. And what is the number one all-time favorite hypothesis of any manager?
“The appointed leader is the sacred spark.”
why is the appointed leader the one who’s most likely to break down?
Answer: because people believe in the Myth of the Appointed Leader.
- “Which would you rather have? A team that never fails, but you don’t know who’s responsible for their success? Or a team that fails regularly, but you know exactly whom to blame?*
A team with an appointed leader can be self-organizing if that leader is wise enough to lead by consensus.
Reflect and Adjust
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Rhonda’s First Revelation [see, The Secrets of Consulting] says:
It may look like a crisis, but it’s only the end of an illusion.
In other words, Agile practice of reflecting at regular intervals is a way of exposing illusions before they become crises
Remember our heroes from an earlier chapter, Frank, Iris, Barry, Ahmed, and Sue Anne? What could these heroes have done to maintain their effectiveness?
Over the years, I’ve observed two major mistakes by Agile customer surrogates. First, and most frequent, because they’re well-rooted with their customers, they fail to spend adequate time with their Agile team. Second, perhaps to prevent that first problem, they fail to spend adequate time with the customers they’re supposed to represent, so they become out of touch with their true needs
the most powerful time to think of such job alternatives is when the manager needs something from you, not after you’ve already mindlessly accepted the ill-considered job
An Overriding Principle
To make sense, each of the Agile principles must be applied with the mind fully engaged. That’s true of any derived principles, too.
Why People Don’t Instantly Buy Into Agile
evangelists often stress the strength of Agile methods at removing, and even preventing, errors. I used to stress this advantage myself, but I always wondered how people could resist this sales pitch.
If they payoff is so huge, why aren’t we raising software quality to new levels? We could ask the same question about improving auto safety
They’re so common that we’ve learned to take them with an accepting shrug
each new feature, no matter how potentially valuable, has a downside–a negative quality value because of its unfamiliarity
It’s a classic catch-22. To convince people of the value of Agile, we need to produce software that is full of wonderful features that the old software didn’t possess, at the same time the new software functions exactly the way the old software did. No wonder change is difficult
Beyond Agile Programming
whole section entitled, “Beyond Structured Programming.” As I contemplated updating that section, it dawned on me that I could almost update completely by substituting the name of any more recent “movement” (or fad) for the word “structured.
*I also knew how smart most of my readers are, so I figured they would see the same possibility without my updating a thing. Instead of changing the book, I decided to update the section and publish it on this blog. *
Much less has been done than the press would have you believe
There are rather many conceptions of what agile programming ought to look like, all of which are reasonably equivalent if followed consistently
Methods representing thoughtful adaptations of “patented” and “local” ideas on agile programming are far more likely to be followed consistently
now I must pause and relate the effect these observations have on many readers, perhaps including you
“These can’t be right, because if they were right, why would there be so much attention to agile programming?”
The answer can serve as my fourth observation:
*Agile programming has received so much attention for the following reasons: *
So actually, the whole agile programming pitch was pre-adapted for the ease of professionals, who have always believed “problems” had “solutions” which could be mechanically applied
The Final Conclusion
Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don’t buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they’re applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful
Our profession contains few, if any, easy solutions