The Flop

When Manu Ginobli of the San Antonio Spurs flops backward onto the basketball court,  it may or may not have been the result of getting shoved by an opposing player.   Most likely not.   Ginobli is the king of the flop…a pejorative term describing a technique used to trick the referee into calling a foul on another player.   In the past, the referee played an impartial role of “observer” and “decider”.    When flopping occurs, the referee actually becomes one of the participants in the game itself.   Deceiving the ref is practiced by some players, while recognizing and avoiding deception is part of the role of the referee.

This practice isn’t unique to basketball.   When Derek Jeter of the New York Yankees complained of being hit by a pitch when playing Tampa Bay a couple weeks ago, the umpire let him take his base.    Jeter later admitted that he knew he hadn’t been it.  The slow motion high def instant replay had already confirmed this.  However, since Jeter knew that the umpire couldn’t know for sure, he took advantage of the opportunity to get  a free walk.   Jeter didn’t break any rules, he just cleverly took advantage of an opportunity to take a free base by deceiving the umpire.

…and don’t get me started on pro soccer…same song, third verse…

In business, politics is often a factor that can interfere with the progress of a project.   When a software developer builds what was requested during iteration planning, it can be frustrating if the resulting component is rejected by the product owner at the end of the iteration.   The rules of the game state that the product owner should have been engaged throughout the process, and that a last minute rejection could be avoided.   When rejection happens, finger pointing, blaming, complaining, and even name calling cold also occur…the software developer blaming the product owner for lack of participation, the product owner blaming the software developer for doing a poor job of understanding the requirement, etc..

Either side could choose to “flop” and draw attention to the other as the cause of the wrong or missed requirement.  If that happens, it just delays what’s needed: high bandwidth communication and collaboration.   Reconciliation of the problem won’t happen by assigning blame.  The best resolution is to do what could have been done to avoid the problem in the first place.   Hopefully through realization of the results of the resolution process, the parties will learn to play nicely together in future iterations.

Pardon me, but we are about to crash…

The polite female voice came on the plane’s loudspeaker: “This is an emergency announcement. We may shortly need to make an emergency landing on water.”

Panic ensued on the British Airway’s flight headed from London to Hong Kong two weeks ago. They were, in fact, not descending into the sea. They were headed into turbulence, and the pilot pressed the wrong announcement button. The “We are crashing!!!” button was situated right next to the “Please ensure your seatbelt is fastened; we are entering turbulence.” button. Oops!

User Experience experts must consider a multitude of scenarios when designing a user interface. We take vehicle dashboards, GUI screens, and microwave oven control panels for granted. Many require training and practice. My microwave oven has poorly labeled buttons and the sequence of button presses required to heat my oatmeal for a minute and a half took a lot of disciplined practice to get down pat. Ease of use by me, the consumer, was clearly not a priority for the GE engineer who designed the control panel.

Improving Enterprises has launched an exciting new practice that is making a positive impact on users of the software we develop. Our User Experience (UEX) team has a knack for empathetic design – designing interfaces that optimize the experience of the user of a system. This is a skill often lacking in even the best software engineers. Attention to quality and detail from the inside out is certainly important, but attention to detail from the outside in can amplify an excellent system into one that knocks your socks off.

A sign that slaps you in the face…

 

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…

Forget Rugby…instead…Football!

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.

Handling Non Functional Requirements on an Agile Project

Handling Non Functional Requirements on an Agile Project

Here are the slides from one of my presentations at Agile 2009.   I’m not a fan of wordy slideware, and the slides may not necessarily “speak” to you as they do to me.   Nevertheless, let me know if you find any of this helpful.

Contact me if you’d like to learn more about how to handle non-functional requirements on an Agile project.   It can be tricky, but there are some very effective ways of handling them.

Link:

Handling Non Functional Requirements on an Agile Project

View more presentations from kenhoward01.

No Brown M&M's!!!

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…

Better, Stronger, Faster…

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.

The Wisdom of Small Groups

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.

Alice in Objectland

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.

Agile Trifecta

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.    Although 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:

• It Takes Two to Tango; Four to Square Dance:   Colleague Barry Rogers and I are presenting a session on the often overlooked “Individuals and Interactions” element of the Agile Manifesto.   Learn how psychology, sociology, behavior, attitudes and other soft’ish elements can make or break a project.   We present tips on how to capitalize on and leverage the human side of projects.
• Handling Non Functional Requirements on an Agile Project: For those of you who remember my post on building a better mousetrap (here)  you’ll recall the discussion about how to craft the best solution from the 4400 possibilities.    Non Functional requirements are often overlooked on Agile projects, yet they often determine true success or failure.   In this session I lay out strategies for handling non functional requirements without deviating from core Agile objectives.
• The Covert Agilist: Not everyone is jumping up and down waving the Agile flag.  In this session I’ll describe one of my engagements where I was told “No Agile!” on day one.   I’ll show how, despite this mantra, our team successfully introduced and used Agile right in front of the watchful eyes of our client.   No, they didn’t complain.  Why?  How could they complain about progress and success!   Nevertheless, this story doesn’t have a happy ending.  Come to this session to find out what happened.

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.