Wednesday, May 11, 2011
Everything should be made as simple as possible, but no simpler. — Albert Einstein
Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup. It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work. From there it spawned a long discussion about various ways to estimate the work and commit to it.
To me, most of these approaches to estimation are more complicated than is necessary. Some go into detailed calculations that are far more complicated than what most teams do. I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. (Continued)
Monday, March 14, 2011
How long does it take to take a team from where they are to becoming an Agile team? Of course, that depends on many things, including where they are and how badly they want to succeed at Agile. It’s reasonable to think they can make a transition in six short months.
If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer. If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.
Wednesday, October 13, 2010
When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.
Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.
Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? (Continued)
Thursday, May 13, 2010
I recently wrote on The Importance of Precise Estimates. This is a related topic.
Mark Levison called my attention to an article by Michael Hugos subtitled ‘Agile projects require more planning and coordinating than waterfall projects‘ on CIO.com. In this article he advocates answering the question, “Has the scope of any project task changed?” at every daily standup. He uses this information to update a detailed Gantt chart to provide to senior management. In Michael’s words,
It also gives senior managers who are not on the project (but who are still ultimately responsible for what happens) the information they need to feel comfortable. And that saves project team members from being distracted by endless management questions and misplaced advice (and nothing kills agility faster than endless management questions and misplaced advice…).
Michael, in LOLspeak, “Ur doin it wrong.” (Continued)
Wednesday, May 12, 2010
A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started. Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization. At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.” The earlier post was a description what an Agile project needs. This one is a recipe for creating what an Agile project needs. (Continued)
Thursday, February 18, 2010
Maybe you’re starting your first Agile project. You’ve read books and blogs. You’ve had training. You think you’re ready, but it’s still a daunting prospect. There’s just so much to remember—so many details.
Here’s a little cheat sheet. Forget all the details and the various ways you can implement Agile for the moment. Let’s simplify the picture. There are just three essential legs that your Agile project needs to stand. Get those in place, and you’ll do OK. Keep improving all three, and you’ll do fantastically! (Continued)
Sunday, August 30, 2009
My good friend, Steven M Smith, tweeted
AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.
I completely disagree with this statement. I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives. I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them. I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing. Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements. I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. (Continued)
Tuesday, August 18, 2009
From time to time, a discussion rattles around the internet about “how can you tell how Agile you are?” Over and over, I see people tout some variant of the Nokia Test as a way to tell if you’re Agile enough. For the most part, I think this is hogwash.
Don’t get me wrong. I’m all in favor of an Agile Team using something like the Nokia Test (or, better, Nationwide’s “Agile Tea Leaves”) as part of a self-examination and retrospection. But any sort of discussion of conformance to practices is way too low-level for the executive team, or even middle management, of an organization. Agile is the tool, not the goal. The goal is to accomplish the things the organization wants to do. Agile is a tool to allow the organization to accomplish its goals more reliably and in a more timely fashion.
With this in mind, I thought about what a high-level manager wants from the organization’s projects and the process used to develop them. How can this manager tell if the development staff is doing a good job, or could be doing better? I came up with this Do-It-Yourself Project and Process Evaluation Kit that such a manager can use, no matter what process the organization uses for development. I think it will also be useful for Project Managers who need to report upwards. Report in these terms, not in the details of the development process.
And here it is: (Continued)
Thursday, April 23, 2009
Smaller organizations have an easier time adopting Agile development practices than do larger ones. Once you get beyond a handful of teams, things start to get much more complicated. Not only that, but no “cookie-cutter” approach seems to work very well. Context always matters, and even more so in the large.
Bob Payne and I recently had a conversation with Sanjiv Augustine about the issues, and some ways of dealing with them.
Sunday, March 15, 2009
I just got around to watching Josh Kerievsky’s talk, 10 Tips for Successful Agile Transitions. He starts this talk with the tip, “You’ve got to do a readiness assessment,” and I think that’s incredibly good advice. He also says,
They should never, in a million years, have been doing Agile. They were not ready for it… They could not be helped.
Ouch! Are there really organizations that must be written off as hopeless? (Continued)