You are currently browsing the tag archive for the ‘agile’ tag.

brown-mmsThe 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…

Tom Bodett raises some interesting questions regarding the Wisdom ofmotel6 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

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.    Althoagile2009ugh 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.

adjectives_largeTake a look at two versions of a User Story, which are written using Mike Cohn’s popular format:

Version 1

As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.

Version 2

As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.

 There are two words added in the second version of this User Story that could potentially derail the development effort if ignored.   It’s easy to overlook adjectives and adverbs as adornments that don’t add value.    While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.

Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements.    The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes.   This also aligns with popular practices of Thomas Gilb.

Adjective/Adverb Promptly
Target Account balance calculation process
  Measured by Number of manual steps required
    Minimum acceptable 1
    Maximum acceptable 4
  Measured by Time from submit until calculation appears
    Minimum acceptable 0.5 second
    Maximum acceptable 3.0 seconds

By now, the Scrummers out there may be squirming, but hear me out.   The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes:  1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.

I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself.    This could feel like squeezing a square peg in a round hole.   A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”.    The deliverable for these tasks could potentially conform to the format I described above.

adjectives_largeTake a look at two versions of a User Story, which are written using Mike Cohn’s popular format:

Version 1

As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.

Version 2

As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.

There are two words added in the second version of this User Story that could potentially derail the development effort if ignored.   It’s easy to overlook adjectives and adverbs as adornments that don’t add value.    While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.

Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements.    The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes.   This also aligns with popular practices of Thomas Gilb.

Adjective/Adverb Promptly
Target Account balance calculation process
Measured by Number of manual steps required
Minimum acceptable 1
Maximum acceptable 4
Measured by Time from submit until calculation appears
Minimum acceptable 0.5 second
Maximum acceptable 3.0 seconds

By now, the Scrummers out there may be squirming, but hear me out.   The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes:  1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.

I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself.    This could feel like squeezing a square peg in a round hole.   A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”.    The deliverable for these tasks could potentially conform to the format I described above.

walmartWhen kick-starting a new team, it’s helpful to be empathetic to each team member’s background and experience.   Interpretation of such concepts as productivity, efficiency, and quality can differ based on an individual’s background, values, and previous experiences.   Ambiguous goals can lead to ambiguous results.

A role of the Scrum Master is to facilitate the team toward common goals.  At face value, this sounds like a “motherhood and apple pie” statement.   Under the covers, this can be more challenging than it appears.    When goals are stated in subjective’ish language, each team member’s interpretation is likely to be different.   

Tip: Know the Target of a Goal.

There’s a difference between goals for the project and goals for the thing being built.  

Project goals tend to pertain to the schedule, resources, and work.     Project goals usually contain language related to efficiency, productivity, being on time, providing good customer service, meeting budgets, etc.

Product goals pertain to attributes of the system being developed.   Non-functional requirements fall into this category: The system shall fast, efficient, comprehensive, fault tolerant, user friendly, etc.

Tip: Make Adjectives Measurable.

Adjectives are inherently subjective.   Product goals such as “User Friendly” and “Fast” have a zillion interpretations.   Rather than “System shall be fast”, try a more specific goal such as “Each screen must display within 3 seconds of request”.

Similarly, a project goal such as “Work Productively” says nothing.   This is where Scrum tactics can help.  Establishing a specific goal for the team’s velocity is measurable, reportable, and actionable.   Once the team agrees to a goal for its Velocity, it can be tracked and reported as a shared measurable goal.

 Tip: Radiate the Goals that Matter.

When goals are written in a document and filed away, they can be forgotten.   If a goal is really important, consider radiating it – perhaps post it on a wall in the team room.   If a goal is not worthy of being posted, perhaps it’s not really that important.

lumberjackI recently encountered a Product Owner who had been doing an excellent job in his role, but who pushed back on taking time to do a retrospective at the end of a sprint.    He said, “We have momentum and we’re making progress.  Why would we possibly want to stop and waste time doing this now?”

 

Steven Covey tells the following story in “Seven Habits of Highly Effective People”:

There’s a guy who stumbled into a lumberjack in the mountains. The man stops to observe the lumberjack, watching him feverishly sawing at this very large tree. He noticed that the lumberjack was working up a sweat, sawing and sawing, yet going nowhere. The bystander noticed that the saw the lumberjack was using was about as sharp as a butter knife. So, he says to the lumberjack, “Excuse me Mr. Lumberjack, but I couldn’t help noticing how hard you are working on that tree, but going nowhere.” The lumberjack replies with sweat dripping off of his brow, “Yes…I know. This tree seems to be giving me some trouble.” The bystander replies and says, “But Mr. Lumberjack, your saw is so dull that it couldn’t possibly cut through anything.” “I know”, says the lumberjack, “but I am too busy sawing to take time to sharpen my saw.”

In the spirit of continuous improvement, we don’t want to do unproductive and useless things.    Within a sprint, team members are empowered to fix tasks that aren’t working, or eliminate tasks that don’t add value.   The restrospective at the end of a sprint provides a way for the team as a whole to see things that individuals may not see by themselves.     So if you notice the saw getting dull, stop and sharpen it now, don’t wait.    And If you don’t happen to notice the saw getting dull, but knowing that saws tend do get dull with use, stop every once and a while and check for dull blades.

lumberjackI recently encountered a Product Owner who had been doing an excellent job in his role, but who pushed back on taking time to do a retrospective at the end of a sprint.    He said, “We have momentum and we’re making progress.  Why would we possibly want to stop and waste time doing this now?”

 

Steven Covey tells the following story in “Seven Habits of Highly Effective People”:

There’s a guy who stumbled into a lumberjack in the mountains. The man stops to observe the lumberjack, watching him feverishly sawing at this very large tree. He noticed that the lumberjack was working up a sweat, sawing and sawing, yet going nowhere. The bystander noticed that the saw the lumberjack was using was about as sharp as a butter knife. So, he says to the lumberjack, “Excuse me Mr. Lumberjack, but I couldn’t help noticing how hard you are working on that tree, but going nowhere.” The lumberjack replies with sweat dripping off of his brow, “Yes…I know. This tree seems to be giving me some trouble.” The bystander replies and says, “But Mr. Lumberjack, your saw is so dull that it couldn’t possibly cut through anything.” “I know”, says the lumberjack, “but I am too busy sawing to take time to sharpen my saw.”

In the spirit of continuous improvement, we don’t want to do unproductive and useless things.    Within a sprint, team members are empowered to fix tasks that aren’t working, or eliminate tasks that don’t add value.   The restrospective at the end of a sprint provides a way for the team as a whole to see things that individuals may not see by themselves.     So if you notice the saw getting dull, stop and sharpen it now, don’t wait.    And If you don’t happen to notice the saw getting dull, but knowing that saws tend do get dull with use, stop every once and a while and check for dull blades.

holiday1Although I’m usually pretty disciplined about diet and exercise, I tend to slack off quite a bit during the holidays. Some believe that a vacation from discipline is a good thing every now and then, while others feel that “discipline debt” becomes hard to pay off.    I do know that losing the 5 pounds I’ll probably gain is going to be a hassle, and completing my twice weekly bike rides is going to be more difficult when I resume.

 

Many projects (Agile or not) tend to go on vacation during the holidays.   Not necessarily a full blown stop, but work may slow to a trickle.   Many will take days off and/or participate in other non-project related activities.  When a project team is shut out of office decorating, food-fests and gift exchanges, discontent can build.   

 

When planning a sprint that will span holiday weeks, it’s important for the leadership to agree on an acceptable velocity that could be lower than previous sprints.    This strategy continues to enforce the discipline of “we set a goal and work together to meet or exceed it.”    The alternative is to miss an unrealistic goal and blame it on the holiday.   Allowing this can open the door for all sorts of other excuses down the road.

 

Another strategy is to devise a holiday sprint – one focused on cleaning up outstanding housekeeping items that would be nice to get out of the way.   Items selected for the holiday sprint are hand picked based on size, complexity, and lack of dependency on resources who will be gone.  Although this may violate the practice of driving sequence based on priority, it does allow the discipline of the process to endure.