The Agilist Network

Tales and Tips from Agile Software Projects

Usability and Fashion

Posted by kenhoward on February 28, 2009

guerilla_usabilityI’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.


Posted in Uncategorized | Tagged: , , , | Leave a Comment »

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

Posted by kenhoward on January 31, 2009

Q: What do they call a group of 5football-tv-screen0 guys who watch the Superbowl on TV year after year?

A: The Dallas Cowboys.

Posted in Uncategorized | 1 Comment »

Individuals and Interactions Workshop

Posted by kenhoward on January 28, 2009

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

Posted in Uncategorized | Leave a Comment »

Don't Overlook the Adjectives in User Stories

Posted by kenhoward on December 19, 2008

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.

Posted in Uncategorized | Tagged: , , , , , | 2 Comments »

Hello world!

Posted by kenhoward on December 18, 2008

Welcome to This is your first post. Edit or delete it and start blogging!

Posted in Uncategorized | 1 Comment »

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

Posted by kenhoward on December 18, 2008

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.

Posted in Uncategorized | Tagged: , , , , , , , , | 2 Comments »

Don't Forget to Sharpen the Saw

Posted by kenhoward on December 17, 2008

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.

Posted in Uncategorized | Tagged: , , , , , , | 2 Comments »

Will the Agile Holidays Create Discipline Debt?

Posted by kenhoward on December 16, 2008

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.

Posted in Uncategorized | Tagged: , , , , | 3 Comments »

When the Emperor Has No Skills

Posted by kenhoward on December 15, 2008

emperor-new-clothes-13A 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.


Posted in Uncategorized | Tagged: , , , , , | Leave a Comment »

When Coaching an Underdog Team

Posted by kenhoward on December 12, 2008

In a perfect world, members of a newly formed Agile team are highly skilled, and the role of the coach is to overlay Agile so the skills are employed in the right way, in the right place, and at the right time. But many of us don’t live in a perfect world.

As a coach, I have often been challenged with team members who lack fundamental software development skills. This can distract efforts to be successful with Agile…and when core skills are missing, there is risk that the organization will peg Agile as the culprit for poor results.

I have met a number of people who told me that Agile was abandoned at their company and dubbed a failure. Agile cannot ‘heal’ poor software development skills, rather, it helps teams that possess skills experience an order of magnitude improvement in results.

When tasked with coaching a team of underdogs, the first order of business is to assess the presence (or lack) of core software skills. If an underdog team is what it is, a successful coach recognizes the obligation to clearly separate Agile coaching efforts from those of teaching/mentoring fundamental skills. This will help a company balance it’s needs: To emphasize skills development, or to place more emphasis on successful delivery. If the latter is the emphasis, it may not choose to pursue that particular project with a team of underdogs.

Posted in Uncategorized | Tagged: , , , , , , , | 2 Comments »