I ask people to think about the question, “What is the simplest thing that could possibly work?” I’m not asking you to think about what is too simple to work, just to bias your thinking toward eliminating wasted complexity. — Kent Beck, Extreme Programming Explained Read more →
EppsNet Archive: Agile
Change Isn’t the Problem
Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change. — Kent Beck, Extreme Programming Explained Read more →
Visibility and Feedback
Forgive my ignorance. How do increased visibility and tighter feedback loops manage and reduce risk? Get in your car. Drive to a winding road. Get up to a decent speed. Close your eyes for two minutes. Then come back and ask your question again. — Ron Jeffries, Yahoo Groups (kanbandev) Read more →
Making Work Visible
Great post on Kanban. The balloon idea is genius! http://blog.flowkaizen.com/why-physical-card-walls-are-important Read more →
Agile Manifesto 2.0
I’ll share with you what I do in one of my standard presentations — I play with the class or with the audience a game called “Rewrite the Agile Manifesto (link) with your thoughts and feelings now.” Here is one of the outcomes: Beyond individuals and interactions to hyper-productive swarming jelled teams and communities of practice. Beyond working software to high-quality, well architected and well-tested user-centered software services. Beyond customer collaboration to user collaboration and user involvement. Beyond responding to change to prioritizing and optimizing for change. — Mike Beedle Read more →
Kanban and Scrum: Making the Most of Both
Free download courtesy of Henrik Kniberg, Mattias Skarin and InfoQ.com. The book includes: Kanban and Scrum in a nutshell Comparison of Kanban and Scrum and other Agile methods Practical examples and pitfalls Cartoons and diagrams illustrating day-to-day work Detailed case study of a Kanban implementation within a Scrum organization Read more →
Customer Engagement
You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it. — James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development Read more →
Flexibility
The customer’s needs must dictate the project’s objectives, and in a dynamic environment, invariably one of these objectives is flexibility. — “Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects” Read more →
Adventures in Agile: The Scrum Board
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… Read more →
Are Nash Equilibriums Killing Agile Initiatives?
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. Read more →
Ultra Lean Planning
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. Read more →
Why Would You Use Agile for Offshore Development?
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 Read more →
Essence of Lean
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 Read more →
Turn the Demands Around
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 Read more →
Scrum Doesn’t Do Anything
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 Read more →
It Isn’t a Thing You Do
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 Read more →
The Agile Elevator Speech
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” Read more →
Managing Teams
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 Read more →
Requirements are Boring
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 Read more →
The Waterfall Approach Persists as an Urban Myth
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… Read more →