EppsNet

For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done.

Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?”

Ummm, I could, but it wouldn’t contain any additional information than what’s on the board.

That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task.

It never occurred to me that if you record information on Post-Its and stick them on a wall, rather than recording the same information in an “official” format like Excel or Project, there will be people who assume that you’re just screwing around.

NB: It’s not their fault for not getting it; it’s a communication failure by me because I didn’t anticipate the situation.

Thus spoke The Programmer.

If each player has chosen a strategy and no player can benefit by changing his or her strategy while the other players keep theirs unchanged, then the current set of strategy choices and the corresponding payoffs constitute a Nash equilibrium.

A system may have many possible Nash equilibriums. There is no guarantee that a Nash equilibrium is optimal for the system as a whole. Most are not. However, it is often very difficult to move from one Nash equilibrium to another. To do it successfully, all players must be made aware that a better state is attainable and they must trust each other to change.

— Kallokain: Are Nash Equilibriums Killing Agile Initiatives?

Nash equilibriums are named after John F. Nash Jr., whose life was depicted in the movie A Beautiful Mind.

I’m not wholeheartedly endorsing the Ultra Lean Planning approach but it does lead you to question how much of the overhead of traditional software development is really necessary. It may be important to know that the author is one of the top guys in the industry and not a random flake.

More of my customers have been asking me how to use agile processes, particularly Scrum, to help them manage offshore development. Since offshore development undercuts many of the practices that promote agile productivity, I ask them why they don’t just increase the productivity of their teams by thoroughly introducing agility? It seems that offshore development, with its potential for lower unit costs (dollars per programmer day), offers management hope that their losses can be reduced. Since the project is probably going to fail anyway, let’s minimize our losses by lowering our investment by using lower priced resources. A more optimistic, agile, way of looking at this problem is to fix the problem at home and increase the probability of success.

— Ken Schwaber

From Alan Shalloway:

Essence of Lean for People Doing Scrum

• Lots of concurrent tasks cause waste
• Focusing on removing delays will remove waste
• Adding value and getting feedback quickly is important
• If you make a mistake and don’t attend to why you made the mistake, it will likely repeat itself
• Minimizing work in process (WIP) is a way of improving efficiency and minimizing risk

Managers will often demand proof that questing for quality will have some measurable “return on investment.” That’s an easy one. Just agree to provide ROI numbers using the same system they currently use. No such system exists.

When a manager demands that you justify your efforts, simply ask her the same in reverse. How does she justify her current methods?

— Alan Cooper

In the end it doesn’t matter what names you use for your processes, good people will do good work and continuously improve what they do. So much of the discussion around Lean versus Scrum (etc.) is about marketing hype, selling consulting and training services, and cornering the market with new name-brands. . . .

Scrum is not a methodology, it is not a process. It is a simple framework underpinned by some common sense principles. Scrum offers individuals and organizations the opportunity to continuously improve the way they work. It provides a space for people to behave like human beings, with trust, respect and passion. That’s about it. But that is huge.

— Tobias Mayer

Agile development isn’t a thing you do, it’s an attitude, it’s a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.

— Kent Beck

You begin by stating that agile is basically three things: a set of engineering best practices that allow for rapid delivery of high-quality software, a project management process that encourages frequent inspection and adaptation, and a leadership philosophy that encourages team work and accountability.

You go on to say that success in today’s economy requires us to respond quickly to changing market conditions. Agile processes allow our teams to meet the changing demands of their customers while creating environments where top developers want to work.

— Agile Chronicles: “The Agile Elevator Speech”

Instead of “managing” the process in the traditional sense, management can help a lot more by:

• realizing that it is the teams that will discover and make the improvements, not management,
• giving teams the responsibility to manage and improve their own process as well as the freedom and authority to do so,
• establishing an environment that actively encourages teams to be totally honest about their problems and impediments,
• listening to what the teams say they need and respond to those needs,
• observing teams in action instead of just collecting numbers,
• providing useful feedback to teams instead of instructions or pressure.

— Steven Gordon

You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . .

Who has built something that their customer will certify is part of what they want? That’s interesting.

Who has shipped something to their customer and the customer is using it? That’s very interesting.

— Ron Jeffries

We have an executive customer who can’t decide what he wants to do. We have no one in IT management with any clue on how to collect a minimal set of information from a customer (see, for example, “Tool 4: Chartering” in The Agile Customer’s Toolkit) in order to initiate a project intelligently.

And so we prepare presentations and prototypes at a level of detail far beyond the vague notions that we’re given to work from, and each one gets violently rejected.

This customer is like one of those bozos who pretends to throw a ball to a dog — a big exaggerated windup and follow-through, but he never lets go of the ball and laughs when the dog tries to chase it anyway.

HA HA HA!

And we’re like the dog.

Thus spoke The Programmer.

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.

— Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering”

We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . .

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development.”

— Gerald M. Weinberg

In his book, Agile and Iterative Development, [Craig] Larman has well documented the history of the many disasters introduced by accident when the Department of Defense standardized on a non-iterative method that was unproven on large projects. It was essentially a blunder by a consultant who had little experience with real software development.

The DOD has long since abandoned the waterfall method, and the consultant has recanted, but the waterfall approach persists as an urban myth in many software development organizations.

— Jeff Sutherland