Agile adoptions are hard, in large part because they involve changes to the corporate culture, a task requiring huge effort and significant time. At the Agile Roots conference, I met Israel Gat and he shared a different approach: work with the existing culture; don’t try to change it.
Tomorrow evening I’ll be at The Bay Area Lean Software Development User Group meetup facilitating a cool simulation that I learned from Steve Bockman.
We’re going to launch a fictitious aerospace company, build and ship product, and track our financials to see how we are doing. We will apply the “Five Focusing Steps” from the Theory of Constraints, as well as other lean and agile practices to evolve and improve our operation and ultimately our
profitability. We’ll explore several approaches to optimizing multi-stage processes and engage in some team problem solving. There will be lots of paper airplanes, and a lot of fun.
The event is free, and hosted by Runa Corporation . Get all of the details at the group’s meetup page.
Cheers,
By: Chris Sims
In my research for an upcoming article, I ran across this tidbit that I just couldn’t wait to share. It’s from Challenges of migrating to agile methodologies a paper originally published in Communications of the ACM.
Agile methodologies require a shift from command-and-control management to leadership-and-collaboration. The organizational form that facilitates this shift needs the right blend of autonomy and cooperation to achieve the advantages of synergy while providing flexibility and responsiveness. The project manager’s traditional role of planner and controller must be altered to that of a facilitator who directs and coordinates the collaborative efforts of those involved in development, thus ensuring that the creative ideas of all participants are reflected in the final decision. The biggest challenge here is to get the project manager to relinquish the authority he/she previously enjoyed.
Find out what this really means, and what it feels like to do it, at our upcoming Agile Project Management learning lab, presented in cooperation with the San Francisco Bay Area Chapter of the Project Management Institute.
Cheers,
The very first exercise of our two day Agile Project Management class on Monday taught me a few things about optimization. It's a ball passing game, where the group is tasked with devising a system for passing balls around such that every ball is touched by each person, and has "air time" in between–ie, it's tossed, not passed.
Read the full article…
I've been teaching myself Ruby on Rails of late, and as such am getting a good dose, right here in the Learning Lab, of what it's like to learn something new at the ripe old age of 45. I'd say half our clientele is my age, so this is especially useful data.
Read the full article…
Since this article was first published, The Team Estimation Game, which is what this article descibes, has evolved into something even better: Easy Estimation With Story Points. If you are looking for a fast and effective way to estimate, we recommend going straight to that article. If want to know where Easy Estimation With Story Points came from, keep reading.
I’ve helped several teams adopt the practice of planning poker. It’s a good and useful practice, but it’s about as beginner-friendly as Badugi. The problem is that planning poker is a lot about numbers: “Is this feature a ‘5’ an ‘8’ or maybe a ‘13’?” New teams have no reference for what these values mean, and it leads to confusion. As they try to figure out ‘how big’ a story point is, teams frequently give in to the temptation to map a story point to some unit of time. I’ve heard: “Let’s have our ‘story points’ be the same as days!” or “How many hours should a 3 point story take to complete?”
By: Chris Sims
Agile evangelists claim that extensive written requirements can be dispensed with in favor of lighter-weight ‘stories’. It sounds easier, certainly, but can it really be as good? Won’t all of the important details get lost?
This Thursday, I’ll be staging a participatory showdown between traditional and agile requirements at the East Bay Innovation Group’s Project Management SIG Meeting. The event is free for eBig members, and $10 for guests with advanced registration.
May the best requirements win!
If I were re-writing the Agile Manifesto and I wanted to express agile values in terms that spoke positively to the project manager's realm, rather than defining agile in opposition to it, I'd state the third value ("Working Software over Comprehensive Documentation") like this: The best documentation is the product itself.
Read the full article…
By Hillary Johnson
… or, enough already! Is Agile dead, alive, stagnant, the future, the past, the ultimate, the end, the Will of God? Am I doing it right, wrong, backwards, sideways, on a boat, with a goat? Should I get certified by the Scrum Alliance, or the Scrum Horde? And should I even care?
Scott Ambler, who once wrote ‘Has Hell Frozen Over? An Agile Maturity Model?‘, has started writing about something that he is calling the Agile Process Maturity Model. The discussion around Scott’s model has uncovered another model by the same name, and renewed the debate over the usefulness of a maturity model for agile.
Frankly, I found Professor Juliano Lopes de Oliveira’s Agile Process Maturity Model more interesting than Scott’s. In particular, I like that it is proposed as a starting point for discussion.
You can read the whole article I wrote on InfoQ.
Cheers,