My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.
I sometimes see clashes between Kanban proponents and their Scrum counterparts. Despite the disagreements, both of these approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the poster-child of iterative agile] when viewed through that lens. I also noticed that while Scrum explicitly focuses on iterations as a control mechanism, Scrum teams tend get into trouble when they ignore Work In Progress (WIP). Conversely, while Kanban explicitly focuses on WIP, Kanban teams tend to get into trouble when they ignore Cadence.
A twitter conversation I was in revolved around Cycle Time and Velocity. Since this is a topic that’s come up before, I thought it would be valuable to describe it more fully. Again, I find there to be more similarities than differences between Kanban (which uses Cycle Time) and Scrum (which uses Velocity) in terms of predicting when a given amount of work will be done, or how much work will be done by a given time. Read More
A colleague’s statement, “In fact my tip is NEVER do a MoSCoW prioritisation,” caught my eye. “The implied fixing of scope makes change very difficult. Order things instead.” That bold NEVER waves a red flag. The following exhortation to order the things to do is also troubling to me.
I don’t know what prompted the statement. I can certainly envision situations where I think the advice to order requirements or backlog items, rather than prioritize them in buckets, makes very good sense. There are other situations where MoSCoW prioritization (“Must have,” “Should have,” “Could have,” & “Won’t have) is good enough, and situations where linear ordering is inadequate. Let’s look at it more closely… Read More
A lot of people and organizations, when transitioning from a serial software development lifecycle toward an Agile one, fall into the pattern of mini-waterfalls. They start doing iterations, but each iteration resembles the development lifecycle they already know. The programmers do some design work, then they write the code to implement the design, then unit test the code, and then they pass it to the testers for testing. To many people, this is the only way it can work. Their mental model only admits to this series of phases.
And they run into typical problems. Sometimes the design doesn’t fit the problem well, and patches are needed because there isn’t time to go back to design. The testers get squeezed for time at the end of the iteration, and no one knows how to accommodate the rework when a problem is found. More patches are added, because there isn’t time to redesign. And the next iteration starts the cycle over again.
Sure, doing this in two to four week cycles beats doing it in six to twelve month cycles. But only a little. Most of the time, it starts to fall apart if the team doesn’t learn to work differently.
But it’s inevitable, they say. Read More
Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.
Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed. Read More
Seen on Twitter
“Most people doing Agile today are actually doing Waterfall with Agile terms. Agile is dead.”
There are a lot of people talking about “post-agile” now that the word Agile has been taken up by the masses, including those selling products and services with the word without ever doing what some might consider to be truly Agile. Read More
Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.
I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.
This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.
I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?
This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them. Read More
Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.
Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with
- A list of features to be built
- A release plan or timeline for those features
- Setting up development infrastructure such as version control or continuous integration servers
- Studying or practicing skills in new technologies they expect to use
- … and other management, infrastructure, and technical endeavors.
They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.
The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.
And we’ll have burned an iteration without producing any working software that tests our decisions.
My advice is to borrow an idea from Lean and look at the situation from the output point of view. Ask yourself, “what would it take to start delivering?” Read More