More on Self-Organizing Teams
Bob and I received some questions and comments by email, so we returned to the topic of self-organizing teams. Catch the new podcast on The Agile Toolkit.
Time Boxes
Bob and I tackle the topic of time boxes on our latest Agile Toolkit Tips & Advice podcast.
Self-Organizing Teams
Live and unrehearsed, Bob Payne and I talk about Self-Oranizing Teams on the Agile Toolkit podcast. This podcast is a lot shorter than our last one. Give it a listen and let us know what you think.
They could not be helped.
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? Read More
Bringing the Agile Manifesto to Life
Bob Payne has posted a new podcast, Tips and Advice – Manifesto for Agile Software Development, where we talk about the principles and values of the Agile Manifesto. I’m still a bit unused to hearing myself talk, and I’ve got a ways to go at getting the “um” monster under control.
If you’ve got the time, give it a listen and give us some comments.
Fixing the Agile Engineering Problem
A lot of people are talking, recently, about the fact that organizations that adopt Agile practices don’t always achieve the results they desire. See Martin Fowler’s Flaccid Scrum, Ron Jeffries’ Context, My Foot!, and Jim Shore’s The Decline and Fall of Agile for examples.
In my experience, most organizations have much room to improve both their project management and their technical engineering practice. Those that start with Scrum seem to improve their project management practice enough that the deficiencies in their technical engineering practice become more painfully obvious.
The answer is simple and obvious–improve the technical engineering practice. The way to do that is not so easy, however. Read More
Agility and Predictability
I was reading the latest post on Johanna Rothman’s Managing Product Development blog. In it she says,
Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by”“the first possible, optimistic date.
I like that characterization of the predicted date. Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip. I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble. Read More
Should it really take that long?
In my previous post, Working Hard, or Hardly Working?, I mentioned how it was possible to tell the wheat from the chaff by observing. Alistair Cockburn rightly suggested that the manner of observing that I suggested was more appropriate for a team leader than for upper management. Yes, he’s quite right about that. He had in mind a Vice President who, when told that the development team had estimated something would take two weeks, asked him,
How can I tell if it really should take that long, or they’re just padding to make their life easier?
How would you answer that question? Read More
Working Hard, or Hardly Working?
I first heard this joke way back when, at my first real job–I was a TV repairman when I was 14. It may generate a polite chuckle when asked between peers, but it’s serious business when the boss asks the worker. It’s also been a topic of conversation over on the Scrumdevelopment yahoogroup, where Graeme Matthew described the difficulty of determining this using velocity.
The unknown in all of this is that if a team have a velocity of 6 how do you tell if they should have a velocity of 8 i.e. they are underperforming. It gets complex. If they have a velocity of 16 are they doing well or have they estimated at the higher scale of story points.
I agree with Graeme that this is one of the difficulties with using velocity to measure performance. I agree with Alistair Cockburn when he says
There is NO good measure of “programmer productivity”.
earlier in the same thread. Yet when you work with people, you generally know who’s working hard and who isn’t. It’s an interesting conundrum, isn’t it? Read More
More on Agile Usability
I recently wrote about Agile Usability. Now I find an article on StickyMinds, “Getting Agile With User-Centered Design,” by Jon Dickinson and Darius Kumana. They talk about a number of issues that can come up. My favorite bit is this:
We must actively challenge the mindset of divided responsibility–” You spec and design it; we’ll build what you spec.” Everyone should work toward the shared vision of a successful experience.
That says so elegantly what I tried to say in my article.