Agile Impressions

Book about Agile Software Development by Jerry Weinberg https://leanpub.com/jerrysblog

Mostly structured as ponderings of each piece of Agile Manifesto, plus a nice history intro (doing Iterative development in the 1960s).

Excerpts

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

Satisfying Customers

*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

Placating Paradox

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.”)

SATISFY WITH SOFTWARE NOT WITH PROMISES OF SOFTWARE

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.

Volkswagen Verity:

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

Working Together

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

Face-to-Face Conversation

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

Sustainable Development

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

Technical Excellence

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

Early Training

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

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.

WRONG!

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

Be reasonable

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. *

First Conclusion

Much less has been done than the press would have you believe

Second Conclusion

There are rather many conceptions of what agile programming ought to look like, all of which are reasonably equivalent if followed consistently

Third Conclusion

Methods representing thoughtful adaptations of “patented” and “local” ideas on agile programming are far more likely to be followed consistently

Fourth Conclusion

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