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
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.
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.
If I had time, I would re-read Tom DeMarco’s book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, because I have precious little slack in my own life, these days. So it is that I just now got around to reading Jakob Nielsen’s article, Agile Development Projects and Usability, which William Pietri noted on the Agile Usability list on November 17.
The statement
“For a project to take interaction design and usability seriously, it must assign them ‘story points’ (i.e., resources) on an equal footing with the coding”
jumped out at me. Alistair Cockburn wrote a thoughtful reply where he noted the same statement. I agree with Alistair’s comments, but I’d like to comment on this statement from a slightly different perspective. Read More
Esther Schindler quoted me in her article, Getting Clueful: 7 Things CIOs Should Know About Agile Development, on CIO.com. Unfortunately, my advice got altered a little in the editing process. She says,
Consultant George Dinwiddie from iDIA Computing suggests using a burn-down chart to track project progress.
I actually recommend a burn-up chart to track project progress, and a burn-down chart to track iteration progress. There are specific reasons that I think a burn-up chart is superior to a burn-down for tracking over the course of a project or release. I’ve been meaning to write a long post about this, but haven’t found the time. I just wanted to correct the record, in the mean time.
The full comments of my note to Esther: Read More
There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.
So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.
The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.
I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. Read More
… and fruit flies like a banana. It’s amazing to me that it’s been three weeks since my last post. Sometimes real life has a way of consuming the time, leaving little left for philosophizing.
During this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a little. Brian’s turned over a lot of stones at once, and it takes me awhile to examine all the things that have been living under them. Being a Myers-Briggs introvert, I tend to discuss these things in my own head before displaying them to the world. Here, though, I’m just thinking out loud and I haven’t come to any conclusion. Read More
A Steering manager uses the Law of Diminishing Response as a guide to successful control interventions. When you consider adding some pressure, the key variable to monitor is not people’s performance, but their responsiveness. How are they responding to the existing pressures? When they hear of a new “challenge,” do they drop their head a quarter of an inch and mumble an acceptance under their breath? Do they become annoyed and give a hundred reasons why it can’t be done? Do they show external signs of panic? These are all signs that they’ve reached the point where responsiveness has gone negative, yet they are unable to control their own response.
On the other hand, are people alert and genuinely enthusiastic, able to ask penetrating questions that need answering before accepting the extra work? Can they consciously trade off less important work for high-priority assignments? These are signs that their responsiveness is still above zero, so it’s okay to pile a little more fuel on the fire; but don’t make any assumptions about next time.
Jerry Weinberg, Quality Software Management: Systems Thinking
Last month, Dmitri Zimine posted a small rant against context switching. Read More
It’s stabilizing feedback that keeps a simple amplifier working as an amplifier, rather than pegging the output at the maximum positive or negative voltage. The feedback mechanism observes the output and applies a small correction to the input to counteract overreactions. Because the feedback is swift, only a small correction is needed. In fact, if the feedback were delayed, the output would tend to swing back and forth, oscillating around the desired value.
In iterative software development, we use feedback to keep the project on task. Feedback from our unit tests lets us know if our code does what we intend. Feedback from our acceptance tests lets us know if our code does what the Customer wants. What could possibly go wrong? Read More