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.

Sudoku Sizing of User Stories

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:

• Gentle
• Easy
• Intermediate
• Hard
• Diabolical

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.

Usability and Fashion

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.

A bit off topic, but it is Superbowl Weekend..

Q: What do they call a group of 50 guys who watch the Superbowl on TV year after year?  

A: The Dallas Cowboys.

Individuals and Interactions Workshop

Agilists say we place more value on individuals and interactions, yet everywhere I look the emphasis seems to be on processes and tools:  Books, articles, seminars, training classes, just about everything!    As a refreshing change, Improving Enterprises has a new workshop which helps Agile project teams optimize their communication and interactions.    The workshop is fast-paced and full of innovative exercises which help a team accelerate through the ‘forming-storming-norming-performing’ stages.    It’s well worth investing one day for a project team to attend this together, and the price of the workshop is very affordable.

There are many team building workshops in the market, but this is the first one I’ve seen that was specifically developed for Agile teams.  It’s also facilitated by experts in Agile software development.

More details about this workshop can be found here.

Don’t Overlook the Adjectives in User Stories

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

One person’s Walmart is another person’s Macy’s is another person’s Neiman Marcus…

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

Don’t Forget to Sharpen the Saw

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

Will the Agile Holidays Create Discipline Debt?

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

When the Emperor Has No Skills

A commenter on my previous post made reference to Scrum’s transparency of work, workers, and productivity, noting that this causes some to dislike Scrum. 

 

Back in High School I was a trumpet player in the marching band.  When football season ended each year, our large band was split up into multiple small bands with just a few players on each instrument.    Every note played (or missed) by each and every member of the smaller band was noticed.   Those who were marginal players couldn’t hide behind the other players.   This resulted in two things: 1) Many worked harder to develop the skills needed to perform acceptably, and 2) Some left the group, or moved to a “lesser” band that had more casual goals. 

 

The transparency of productivity and results in Scrum leaves no one out.  Even if today is my most productive day ever, that will be forgotten if I’m not productive tomorrow as well.   Many are invigorated by this and will thrive in this environment.   Others may try to hide by fabricating useless tasks that burn down hours, but that don’t move the project forward.    When this happens, the Scrum Master, Product Owner, and each and every member of the team should call the bluff.   C’mon, you probably know what’s going on and you just don’t want to expose it!   When a team member tries to hide a lack of skills or a deficiency in productivity, it wastes everyone’s time and can slow down the project.