My first experience with Extreme Programming (XP) was in 2000 after reading the "Extreme Programming Explained" book by Kent Beck, and it got me pretty excited about building software in a new, collaborative way. After taking "The Art of Agile" course* by James Shore and Diana Larsen last year, I felt a sense of excitement similar to when I learned about XP over 10 years ago. The course refreshed me on the principles, values, and practices followed by high-performing Agile teams, and re-energized my pursuit of building great teams that deliver valuable software. But the course wasn't just a refresher, it also contained new material that I felt made it relevant for today's market:
Building products using techniques from The Lean Startup (including material and exercises about identifying Minimum Marketable Features)
Starting off new projects on the right foot by building team trust, consensus on the project's purpose, and clear team working agreements. (Diana is the co-author of a new book about this very topic - Liftoff)
How teams can facilitate change in their workplace
How to make XP's On-Site Customer role work on teams without an on-site customer
I took this course with my entire company -- yes, that means all forty-some people at Cyrus Innovation, from software developers to operations and sales folks, with experience levels ranging from new to Agile and Extreme Programming to seasoned practitioners. We gave the course excellent reviews across the board; everyone walked away with something they could use immediately on their teams. As a team member, it felt great to have a shared group experience and consensus about the fundamental way we work.
So here's the "Hair Club for Men" moment -- we at Cyrus Innovation like this course so much, and felt it was so valuable to us as a company, that we decided to partner with James and Diana to offer this course again to the public in New York. It was a fun course, memorable, and interactive - including a fully immersive series of four iterations building a real software product. I think this course could be valuable to people who are just learning about Agile software development and to folks with experience looking to get reinvigorated about Agile and XP. And taken as a team, I think there are huge benefits in the form of shared context, vision, and momentum that can translate immediately to new or long-lived teams and projects.
If you're like me, you might be looking for more ways to get feedback about your software's continuous integration build process. Here's one of my favorites: the BuildBunny plug-in for TeamCity will send build status announcements to a Nabaztag rabbit.
Version 0.3 has just been posted (look for it on the Downloads page). This release include several little enhancements to the plug-in, including a patch I contributed that enables you to specify a different Text-To-Speech voice to use for the announcements. To me, the U.S. voices are the lowest fidelity, while some of the U.K. voices are much easier to understand. I like "UK-Leonard" and "UK-Penelope".
If you want to find a list of all the voices supported by your rabbit, you can send it a message using its API. Check for action 9 - "Get a list of all supported languages/voices".
A few months ago I read that Violet, the Nabaztag creator, had filed for bankruptcy. Anyone know what's going on with them?
There’s a lot of Spinal Tap activity these days, which is no
surprise given that the rock “mockumentary” This
is Spinal Tap celebrates its 25th anniversary this year.The recent “Unwigged and Unplugged”
tour featuring Michael McKean, Christopher Guest, and Harry Shearer playing Spinal
Tap and other songs has just been released on DVD.Spinal Tap re-recorded several of their songs with several
celebrity guests and released the “Back from the Dead” album.
While listening to the Keith
Emerson-featured “Heavy Duty”, I started thinking about some lessons we can
learn from Tap in the software world:
1. What the customer
asks for isn’t always what they want. (a.k.a. “the Stonehenge principle”) As famously demonstrated when the band provided
the specifications to the stage prop for their epic Stonehenge, the customer wasn’t happy when they got exactly what
they asked for.When building
software, we need to listen to the customer describe what they want, then
deliver frequently and get feedback to make sure they get what they need.
2. Experiment, but avoid
the Jazz Odyssey.Experimentation is a good thing; it
leads to innovation, productivity improvements, and insight into difficult
experimentation without focus is counterproductive.Here I’m thinking of technical design and refactoring experiments/spikes
– make sure you have an objective so you’ll finish having learned something.
3. The performance is
best when the band is together.Nigel Tufnel and David St. Hubbins fought frequently, but productively
resolving the conflict and channeling that energy led the band to write and
perform at their best.Derek
Smalls acted as the facilitator (“lukewarm water” to Nigel’s fire and David’s
ice), a role that is needed to help software teams stay together.As Esther Derby and Diana Larsen taught
me at the Secrets of Agile Teamwork workshop, this facilitator role doesn’t
always have to be one person – it can rotate, as can many of the other roles of
4. Good tools go to
eleven.Spinal Tap required special
amplifiers to create their distinctive sound that gave them the title of
“England’s Loudest Band”.While
the movie example is a gag, I can identify with the reverence that Nigel
displays when describing his favorite amp.For me, I get that same feeling when using IntelliJ IDEA –
it continues to delight me after all these years of day-to-day use.The lesson is simple – good tools make
us more productive.
5. “Have a good time,
all the time”.This rock &
roll philosophy offered by keyboardist Viv Savage is important to
remember.Many of us got into
software development because it was fun, but it’s easy to forget when we get
stressed out by some deadline or difficult bug.Brian Marick mentions joy as one of the key values of great teams, and I agree – I’ve done my best work when I was having
a good time.
What about you?Have you got any favorite Spinal Tap-isms that apply to software
I've started a blog on the StickyMinds website; I'll try to post a new entry every week on topics which include software development, process, and testing.
This brings up the question: "How do I decide which site to use for any given blog post?" My current strategy is to post the more code and tool-specific items here (such as GWT, Scala, etc.) and post the rest at the StickyMinds blog site. I'm sure this will change, so watch this space.
Thanks to Joey McAllister and the folks at StickyMinds for this great opportunity.
Brian Marick recently gave a keynote at the Agile Development Practices conference; he's posted the text of the speech on his blog. It's called "Seven Years Later: What the Agile Manifesto Left Out", and is a good read about the start of Agile and where teams need to improve.
James Shore posted an entry on his blog entitled "The Decline and Fall of Agile" which gives a similar description of some of the problems many teams trying to adopt Agile have experienced. Scrum in particular gets a heavy knock, and I've seen similar results in my experience -- a team starts with Scrum and makes significant improvements in their process and planning, but the vast amount of technical debt and bad code drags the project down like a boat anchor.
Both are excellent posts and well worth reading if you're interested in Agile.