Tales of an Agile Evangelist
Often, traditional communication approaches are overlooked. Over time, signage and other messaging becomes part of the noise that is intentionally ignored. Innovators find new ways to slap you in the face and take notice. Check out this approach to “Go Green” posted in a dorm in Claremont McKenna college. Thanks to Jason Soll and Daniel Pink from TED…
Scrum
and Rugby as an analogy for project work has been around since Nonaka and Tekeuchi introduced them in a Harvard Business Review article in 1986. Since that time, Scrum has become part of the defacto vocabulary of Agile project teams.
In his blog “Pagan Tuna”, Herb Bowie offers a brilliant updated analogy that addresses the combined invidual and team behaviors on a project. It doesn’t hurt that his football analogy coincides with the feverish enthusiasm at the beginning of a new football season. Check it out here.
The rock band Van Halen got some bad PR years ago when word spread that they demanded M&M’s in their dressing room, and that the brown M&M’s must be removed. A concert could be cancelled or delayed if the M&M requirement was not satisfied.
What a bunch of spoiled brats! But hold on…the terms of the contract rider were NOT actually demanded by the band members. David Lee Roth explained that Van Halen concerts had extensive technical and engineering requirements that must be followed explicitly for safety reasons as well as to ensure that the show could go on with no surprises. All of the site preparation details were meticulously laid out in a contract rider. The rider spelled out everything that must be done to prepare the stage, sound equipment, lighting, etc.
Hidden way down in the nooks and crannies of all these instructions was the “No Brown M&M’s” requirement. When the band showed up for a performance, if there were no M&M’s, or if they were there and the brown ones weren’t removed, it set off a red flag that the contract had not been read carefully. The show would be delayed until every detail of a site preparation could be verified. When telling this story on This American Life, Ira Glass referred to this as a “Canary in the Coal Mine”.
This story illustrates the great challenge with written requirements. When requirements are written down, the burden of fulfillment then lies in the hands of the person reading the requirements, and it’s highly probable that requirements will be missed. The “Canary in the Coal Mine” is a clever trick to ensure that written requirements are carefully handled, but it’s not attacking the heart of the problem.
Effective, real time communication is the key to quality requirements handling. This is why most Agile practices emphasize high bandwidth communication over writing things down. It’s possible that the use of passive communication techniques such as filling out business requirements documents may not be avoidable, but when these techniques are used, you may want to embed a canary…
My company, Improving Enterprises, was just listed in the Inc 500 as the 120th fastest growing
private company in the country! We are also the second fastest growing company in Dallas/Fort Worth, and the #1 fastest growing IT services company in the state of Texas! It has been a terrific three years, and we are still going strong! Click here to see the list.
Tom Bodett raises some interesting questions regarding the Wisdom of
Crowds, yada,yada. You see, at the core of the value of Agile is the concept that two heads are better than one, three are better than two, and so on.
Tom observes that if five people guess the weight of someone, the average of the five will be spot on. He goes on to question why a massive body such as U.S. Congress doesn’t tend to do so well with the group think thing. Perhaps there’s a magical size where the benefit of a group wears off.
Check out Tom’s blog here, where you may also enjoy his always dry sense of humor.
An ever so slight diversion from Agile – Good quality programming is still the key to a successful software project. Sure, we need process, testing, stories, etc. At the end of the day, though, we still need code – the stuff that does the stuff we need.
Despite all we’ve learned about abstraction, objects, coupling, cohesion, etc. over the past many years, I am still surprisingly disappointed at the lack of engineering that goes into software that many people develop every day. Meanwhile, interest in Computer Science as a college major and a profession continues to be below levels of a few years ago. This generation of kids are computer savvy, yet few show interest in developing software. Old school teaching techniques may not be capturing the creative interest of today’s youth.
A professor from Southeast Oklahoma State University recently introduced me to Alice – a computer science learning environment developed collaboratively by Carnegie Mellon University with Electronic Arts. Students learn object oriented programming through a visual world. They select objects from a library, drop them into their world, and execute methods to cause them to behave. Clicking “Play” brings their program to life, as the objects in their world interact with one another in accordance with the student’s programmed instructions.
The user interface is pretty and user friendly, and programming is done predominantly through drag-and-drop, rather than typing. The characters and objects in this world are provided by Electronic Arts, which users of the Sims games may find familiar. This environment is perfect for visual learners, which many of us are.
Best of all, Alice is free, and there are versions for both Mac and Windows. The current release of Alice (version 2.2) uses a pseudo object oriented language. The next release (3.0) provides support for Java. Check it out at www.alice.org.
I was thrilled to get notified this week that all three of my talks were accepted for the Agile 2009 conference in Chicago on August 24-28. Altho
ugh I’ve spoken at many conferences in the past, this will be my first opportunity to speak at this popular conference.
I will be presenting:
Registration for this popular conference is underway. August will be here before you know it, so you may want to book your travel early. The conference webpage is here.
I look forward to the opportunity to meet up with old clients and colleagues, and to meet some of you who have been kind enough to post comments and/or send emails about my blog.
A common practice in sizing up User Stories is to assign shirt sizes: xs, s, m l, xl, xxl. This practice allows you to quickly assign an instinctive gut feel of the size of a User Story, which helps when performing a fit check of candidate stories for a Sprint.
I’m working with a client that found an approach I like better: Sudoku Sizing. They tag each User Story with one of the following labels:
The difference in verbiage may seem discrete, however, there can be a big difference in how the label is perceived. While shirt sizes can be interpreted as depicting a quanity of requirements embedded within the User Story, the Sukoku label is often clearly understood as the size of the effort required, which is what you’re really after.
By assigning Sudoku labels to user stories, team members may find it easier to all get on the same page with regard to what each label translates to in terms of effort.
I’ve developed a renewed fascination with usability conventions lately. I’m working with a customer whose core systems are on the ole green screen, and many of the users are quite content with that. My gut tells me that they need to modernize, but when I see users zip through transactions at the speed of light, what benefit could they possibly get from a GUI?
When developing user interfaces with an eye toward usability, I need to remember that it’s not all about beauty. For many software users, efficiency and speed are the most important criteria. I look forward to the next generation of usability that decreases the emphasis on appearance and increases emphasis on usage.
It’s funny to look back at old photographs and mock clothing that we once thought was fashionable. It’s interesting how we can see dramatic changes in fashion when we look back a decade at a time, but we hardly notice changes from year to year. When looking back at old software, however, I don’t see many revolutionary changes in today’s interfaces from those developed a decade ago. There are a few exceptions out there, but for the most part we don’t seem to be evolving.
