We’ve had a particularly busy month here at Agile Learning Labs–the phone is ringing off the hook, so to speak, and our sales and biz dev team has been very, um, agile. As in light on their feet. We thought they might need a good laugh, so this is a thank you to Steve and Laura! Party on, peeps!
I have been spending a fair amount of my time these days editing Jeff McKenna’s new book, Conscious Software Development, coming soon from our publishing venture, Dymaxicon. Jeff’s voice is unique: irrascible, personal, anecdotal, and oddly zen-like. He has a knack for cutting to the quick of any issue. Case in point, this passage about software bugs:
People in the software industry are always talking about bugs. We have bug tracking systems, we have bug triage, we have all these things around bugs–but do we ever really think about what bugs are? How they got there? How we can avoid ending up with more of them?
It is my belief that we as an industry have been so complacent about bugs that we believe all software has to be full of them. The mythology of computer software holds that all software systems have to have their bugs. I don’t think it’s true.
Imagine a world without bugs. Or at least imagine a world with an order of magnitude fewer bugs. I would suggest this goal isn’t really difficult to attain.
So how do we go about it?
First, we want to be conscious about bugs, to really think about them: What are they there for? What do we mean when we say there is a bug?
What’s unique about Jeff’s approach to software development is that he asks questions like, bugs: What are they there for? He isn’t just worried about eliminating them; he wants to know what purpose they might serve, functionally, systemically, practically or, yes, even existentially.
One of the things I love about Jeff’s voice is that everything he says comes off as both incisive and laconic: he’s writing what amounts to a contemplative manifesto. If you want to hear Jeff talk about bugs on video, here you go:
Who knew Innovation Games could be a competitive sport? Our own Director of Biz Dev, Laura Powers, is in a class with Deb Colden called “Innovation Games for Customer Understanding” today, and sent us this pic of her winning entry for “best design and product pitch.” She calls it Scrum Master in a Box:
We never thought of ourselves as a product company before, but that may have to change!
On the bright side, you definitely can’t call him/her a stuffed shirt…
We learned earlier what it is a scrum master does. Now it’s time to see what makes a product owner tick:
If this makes you want to become a scrum product owner (and we’re certain it does!), you can take one of our product owner certification classes. The next one is February 25-26, and includes a free Kindle.
Inspired by Lesbians and Lawyers. Click the image to see at full size:
If this makes you want to become a scrum master, you can take one of our certification classes. The next one is February 27-28, and includes a free Kindle.
A scrum team has many decisions to make, all the time. Should we focus on usability or new features? Should we fix the bugs that are driving our current customers crazy or develop the new features that will help us land the next big customer? Should we use PHP or Ruby on Rails? There is a lot of pressure to make the best decision, the choice that results in the most valuable result. Something many people miss, is that when we make the decision will often impact the value of the result. Should we make the decision now? Or wait a bit and keep our options open? One of the sessions I led at Agile Open Northwest was titled “When Should We Decide?” and it examined this very question.
We explored the idea, using a simple casino game. Each player places a single $2 bet on the outcome of two coin flips. The choices are: heads-heads, heads-tails, tails-heads, and tails-tails. If the player guesses right, the house pays $8, otherwise the player is paid nothing.
We had 20 people playing the game. Each player started with $20, and played 10 rounds. At the end of this we totaled up how much money each player had left. Some were winners, some were losers–one poor soul actually managed to lose all 10 rounds—but the average result was almost exactly $20. On average, the players broke even.
Then we changed the rules of the game. The player was still betting on the final outcome of two coin tosses, but now they only made a $1 bet before the first coin was tossed. Once they knew the outcome of the first coin toss, they placed another one dollar bet, selecting any one of the four possible outcomes. The payout was the same as before: for each dollar bet on the correct outcome, the player received four dollars. After 10 rounds under the new rules, the players did much better. The average stack of money in front of a player at the end of this round was $33.
What ensued was a great discussion about why the players did so much better the second time. By delaying the decision of how to bet the second dollar, the player made that decision with more information: they already knew the result of the first flip. With this additional information, the player is able to make a better decision. As it turns out, our casino game has a lot in common with the Monty Hall Problem.
By definition, plans and decisions that we make early are made with less information than those we make later. If we can delay those decisions, then we can make better-informed choices. Think about release planning in waterfall. We planned a whole release, perhaps 12 – 18 months of work, up front. Those plans rarely worked out well; we were making all our bets before the first coin was tossed.
A scrum team, on the other hand, spreads their planning out over the course of the release. Every week or two, they plan a sprint, and revise their release plan. They also revise their product plans and their technical designs. By delaying decisions, the scrum team gets the benefit of all that has been learned since the start of the project, and can incorporate this knowledge into their decision-making. The result is better schedules, architectures, and products.
An interesting topic that came up in our discussion was the myth of indecision: the idea that it shows character to commit early and then stick to your guns no matter what. We see this in politics all the time, if a candidate changes their mind about an issue they are often accused of being wishy-washy, or a weak leader. Perhaps all they are doing is revising their position to reflect the latest information and learning.
We also talked about the fact that many decisions can’t be delayed indefinitely without losing value or increasing risk or penalty. My friend Llewellyn Falco had a great example: He wanted to attend Agile Open Northwest, but he waited too long to register; the conference had sold out. In this case, the longer he delayed the decision to register, the greater the risk that he wouldn’t be able to register at all. Another example of this is the pricing for the Certified Scrum Master and Certified Scrum Product Owner workshops that Agile Learning Labs puts on. We offer early bird discounts. If a student waits too long to signup, they lose the opportunity to get the discount. Llewellyn’s story has a happy ending, as he got in when someone else canceled.
Funny how it all seems to come back to a classic agile idea: It is best to make decisions at the last responsible moment.
Cheers,
We hear that the traditional year-one anniversary gift is paper. Does e-ink count? We think so! The Elements of Scrum is a year old, and to celebrate, Agile Learning Labs is giving a Kindle to every student in our Certified ScrumMaster and Certified Scrum Product Owner classes this month.
And what a year it has been: The Elements of Scrum has become a runaway bestseller on Amazon and is being taught in the hallowed halls of academia and by scrum trainers around the world.
Your free Kindle will come pre-loaded with The Elements of Scrum as well as the complete catalog of 2011 titles from our publisher, Dymaxicon. Whether you’re a fan of mysteries or an avid gardener, there will be something extra for every reader. Here’s everything you’ll get:
So sign up for a class, and all this bounty will be yours. Details and registration links below:
Certified Scrum Product Owner Earlybird pricing through Feb 11th
February 25-26 in Redwood City
Certified ScrumMaster Earlybird pricing through Feb 13th
February 27-28 in Redwood City
Last Sunday, several Agile Learning Labs team members became actors for a few hours, turning out to help our brilliant colleague Adam Weisbart film the epic drama saga, Sh*t Bad Scrum Masters Say.
This small cinematic wonder (it ain’t no video, shot professionally in HD and edited by a master in the real sense of the word) is a compendium of the boneheaded, misguided and just plain stupid things you will hear during your company’s effort to transition from waterfall to scrum. Feel free to recognize yourself, your stupid boss, your ignorant colleague, or all of the above.
Adam was our Robert Altman, and we scripted the video collectively, based on things we’d all either said or heard. (If you’re looking for the takeaway meme, it’s: “That’s not an impediment.”)
Adam is the author of Agile Antipatterns, a book coming in early 2012 from our publishing imprint, Dymaxicon. If you haven’t heard of Dymaxicon yet, it’s hot stuff, with several bestsellers to its credit, including The Elements of Scrum, A Detailed Man, and Nancy Rommelmann’s memoir, The Queens of Montague Street, which is excerpted in this week’s New York Times Magazine.
Impediments? We don’t need no stinkin’ impediments!
And if you’ve read all this and are still left wondering, “Who was that handsome man who played the Product Owner?” you want Bernie Maloney.
On Languages: An Excerpt from Jeff McKenna’s Conscious Software Development
Jeff McKenna has some interesting things to say about when it’s important to generalize, and when to specialize as a computer linguist–and how many language problems are actually design problems in disguise. From his forthcoming Dymaxicon book Conscious Software Development: