Archive for the ‘Agile’ category

Writing a Cucumber Feature

January 2nd, 2010

This is the second post about Cucumber, where we’ll be exploring the creation of a feature. Cucumber centers on testing the expected behavior of your application, rather than the expected behavior of a method. I had someone explain to me once, “unit tests/specs are the methods/implementation you wish you had, Cucumber tests are the application you wish you had.”

User Stories

When thinking about a Cucumber feature you will want to relate it to a user story. If you’re familiar with Agile development stories are nothing new.  For those who are not though it’s not too complicated. A story is simply an expression of value generally in the form of:  ”As {a role} I want/need {to do some function} so that {business value}.” Generally the business value is best expressed in terms of: revenue generation, revenue protection, operational efficiency (cost savings).

For the example we’ll be using this story:

As a workshop co-ordinator I need to manage contact information so I can easily reference individuals and start communications with them.

You’ll notice that this story doesn’t imply implementation.  You generally never want to imply implementation in a story.  Also you’ll notice that the story is simple and comprehensible by pretty much anyone (business user, developer, average Joe Public).

Starting a Feature File

In our Rails application we’ll want to go inside our /features folder.  Create a new file called manage_contact.feature.  At the top of the file type in the following:

Feature:  Manage Contact
  In order to easily reference individuals and start communications with them
  As a workshop co-ordinator
  I want to manage contact information

Now we have our first feature.  The next step is to define some scenarios.  Scenarios express various actions the user might take in relation to the feature.  Below are some of the scenarios we came up with for this feature (these go below your feature entry – indented to be even to the “In order, As a, I want” section).  You don’t need to, but I like listing the scenarios in order of priority, this way a developer working on the feature can just start on top and work downwards:

Scenario: View list of contacts

Scenario: Add a new contact

Scenario: Email a contact from the list

Scenario: Remove an existing contact

Scenario: Update an existing contact

Scenario: Start an IM conversation with a contact from the list

Your finished feature file should look something like this gist. In the next post we’ll start to look at building out our scenario’s with step definitions, that is define what behavior we expect to happen with each scenario we have defined.

No comments »

Posted in Agile, Programming

Tags:

Adding Cucumber to Your Salad

January 2nd, 2010

Cucumber has come a long way since I’ve first started to use it.  My two posts about getting started with BDD have been the most visited pages of my blog.  So it seems only fitting to address the new features and update the material.  I’ll be creating a series of blog posts (so it doesn’t end up being one giant scrolling page) addressing a real-life situation of creating a contact management feature.  We’ll build it from the ground up using Cucumber and RSpec.

Installing Cucumber / RSpec

The first step to using Cucumber (and RSpec) is to install the necessary gems.  This is very straightforward and probably familiar to most people:

sudo gem install rspec rspec-rails cucumber cucumber-rails webrat ZenTest database_cleaner

If you are using Ruby > 1.9 you will also need to install the test-unit gem (or RSpec will not load properly).

sudo gem install test-unit -v=1.2.3

Now if you run into errors installing webrat, know that it requires nokogiri (an awesome XML parser, see my blog post about nokogiri).  In order to build nokogiri though you need to have a few libraries installed ahead of time.  If you run into any errors installing webrat (likely because it couldn’t install the dependency nokogiri gem) try the following (I’m using a Debian -Kbuntu- flavor of Linux, so your specific command might vary):

sudo aptitude install libxml2-dev libxslt1-dev

Once you have installed the two developer libraries for libxml2 and libxslt you can try to reinstall webrat (sudo gem install webrat) and it should properly build.

Adding RSpec and Cucumber to a Rails Project

Having the gems installed is the first step.  To use Cucumber in your Rails project you need to run a few generation scripts which prime your application and make a few config updates. Run the following commands from inside your Rails application root:

script/generate rspec
script/generate cucumber

These scripts create new rake tasks, a spec and feature folder, as well as modify your database.yml (adding a new cucumber environment).  You’ll also notice a new cucumber environment file added to your environments folder already completed with all the necessary config.gem entries, nice.

That’s all there is to it for getting started.  Next post I will talk about outside-in development and starting your first feature!

No comments »

Posted in Agile, Programming

Tags:

Writing Stories with True Value

November 5th, 2009

A lot of folks who dive into the world of Agile (be it Scrum or XP) will need to learn how to write stories.  Stories are an expression of a feature which provides value.  They typically take the format of “As a {user-role} I need/want to {some functionality} so that {value}.”  I coach people to use what I call the 3Ws:  Who is the user, what is it they want to do, and why do they want to do that?  Any well written story should be able to answer those three questions.

The following is an example story that isn’t written well:

“As a manager I want documentation produced so that the software can be understood by people.”

Who’s the user here, the manager – really?  It doesn’t sound like he’s the one using the documentation, “people” are (whomever that is).  ”Documentation produced” also is a task – not an expression of functionality.  The value statement is also dubious “so that software can be understood,” but why is that valuable for “the people?”  Reading this story leaves you with too many unanswered questions and is overly vague.  You can quickly see this story fails to answer our 3Ws.

Instead, a better approach, is to make documentation part of the done criteria (or acceptance) of the actual feature the story should be addressing.  Remember with stories we want to end with a demonstrable unit of work.  If the feature was to add the ability to send e-mail after someone comments on a blog post, for example, you might have something like this:

“As a user who’s commented on a blog post I want to receive a notification anytime additional comments are added so that I keep up with the conversation.”

This story is much better.  We know that we’re talking about people who have posted a comment on a blog post.  We know that they want to receive a notification anytime new comments are added.  They want this because it helps them keep up with the conversation.  Anyone could read this story and understand what needs to happen. What’s even better is it doesn’t imply implementation.  It doesn’t say I should receive an SMS message, and e-mail or a letter in the mail.  Those details will be discussed when this story is planned.

In order to complete this work the whole vertical slice has to be addressed:  code business logic, design e-mail template/layout, test feature, write documentation.  There isn’t a need to have a separate story for this — I’d advise against it, because your feature really isn’t done if documentation is a requirement.  When you finish a feature you want it to be done, done.

Bad Smells

  • Story not addressing a vertical slice typically have “developer” or “manager” as the user-role.
  • Story doesn’t express business value or functionality, but instead expresses a task.
  • Story has dependencies on other stories being done first.
  • Story talks about implementation.

No comments »

Posted in Agile

Tags:

LSRC 2009 – Day 3

September 27th, 2009

How Much Testing

This presentation was very interesting.  It looked at the age-old question of “how much should we test and what do we test?”  It started out going over several real-life stories of companies who had failed to properly answer the question.  One in particular had a test suite that took over 15-20 minutes to build, over 5 minutes to start the server once built, and then used “webunit” tests that took forever to run.  Also the tests only covered 21% of the system — four years later the coverage was 24%!  (As a side note: Selenium testing is hard, to do right.)

For testing it’s critical to get feed back as immediate as possible.  So if your test suite it taking hours to run then you have issues.  You also should ask yourself if your tests are actually failing from time to time, are they really catching bugs and providing value?

Tests should influence your design.  If you are not finding that tests are influencing your design, they you’re probably not doing something right.  The speaker didn’t seem to specifically push TDD or BDD, but I could understand what he meant by this.  In order to test code easily you have to have testable code to begin with.  Code that is not easily tested is probably overly complicated and not designed/abstracted well.

“How easy is it for you to write a new feature?”  This begs the answer as to why testing is a good thing.  Well designed code is easier to maintain and change, and with tests you gain confidence that your application is working as you expected despite the changes.  Martin Fowler often explains that modifiability is the more important attribute to your code (even above performance), and you gain this through understandability (code is easy to follow/read) and testability.  Writing tests helps you write well designed, understandable, and testable code.

There are a lot of reasons why folks are not writing tests.  The speaker addressed the concerns of both management and developers.  Surprisingly he explained that managers are no longer the road-block, and that most managers now want testing – but the developers are resisting.  To write tests first requires a shift in thinking, and for many developers who’ve been coding a certain way for their entire careers, find this shift sometimes uncomfortable.

Ultimately the answer to the question “How much testing,” can be answered by asking, “What’s the right level of assurance?”  If you’re a company like Twitter (for example) if you lose tweets, or a search doesn’t come back exactly right is it really a big deal?  If you’re a patient in a hospital and your heart-lung machine software fails, is it a big deal?  Obviously you wouldn’t necessarily worry if Twitter admitted to less than 70% code-coverage, but you might be concerned if your heart-lung machine was anything less than 100% code-coverage.

Be Awesome

This was a very fast-paced talked that just touched on values or principals you should adopt to “be awesome,” taken from the speaker’s personal experience:

  • Pair program (remote paring is hard, but possible)
  • Respond to change
  • Use micro-frameworks and tools
  • Creativity and craftsmanship
  • Monolithic processes are unfun
  • Are your apps a joy to maintain?

Cucumber

I got the pleasure of seeing Joseph Wilk in person!  He gave his usual presentation on Cucumber, although there were some new features thrown in there.  Tagging was one of them.  The slideshow was pretty involved and if you would like to see an example of his presentation go check out this video:

Outside-in Development with Cucumber and Rspec

View more documents from Joseph Wilk.

Herding Tigers

This was the last big talk of the conference.  It was presented by Danny Blitz, who’s a very dynamic and interesting character.  He basically talked about agile teams, which he refers to as “tiger teams.”  He didn’t really talk about Scrum or XP or the more formal Agile methodologies, but instead discussed his own take on the corporate environment.

Book suggestions:  The Passion of Command, Corpus Business

What is a Tiger Team?

Small development team where velocity and quality are the primary drivers.  The team self-improves, has no meetings (or very few and short), test-automation is taken very seriously with actual QA members on the team.

“A lot of companies fake agile, wtf is a 3 hour scrum?!”

Workplace Archetypes as Animals

  • Tiger:  calculating, cautions individuals who avoid fights they can’t win
  • Cow: herd mentality, afraid of risk, have no original thoughts
  • Bear: big, mellow, live and let live attitude, also avoid fights they can’t win
  • Leopard: unmatched in ferocity, not a good team player though (avoid these)
  • Elephant: C level execs, invincible in battle (even a tiger will not take on an elephant)
  • Hyena: scavenger, dangerous weasels, steals ideas, back-stabbing

Leadership Characteristics

  • Faith and Love
  • Hope
  • Success belongs to the team
  • Failure belongs to the leader
  • The buck stops here
  • Fearlessness (moral courage)
  • Listener and learner
  • Protector

Also good leaders should manage by intent (servant leadership), not micromanage.  They should reward failure, people will make mistakes – let them feel comfortable in making them, as long as people learn.  Demand to be questioned, if your team is afraid of you they will not question your decisions and warn you when something is wrong.  Glorify the lower levels.

Good “grunts” show politeness and professionalism.  (They got it easy.)

Agile is a buffet not a dogma.  Methodologies are wrapped around Agile, *it* isn’t a methodology itself.

1 comment »

Posted in Agile, Programming

Tags:

May 2009 Cucumber Presentation

August 2nd, 2009
Below is a presentation I gave at Austin on Rails.  You can also find the audio for it here:  nicholas-cucumber-rails-audio
View more documents from ncancelliere.

No comments »

Posted in Agile, Programming

Tags:

Wired Article: What Bugs can Teach Bosses

July 22nd, 2009

I was reading an article in the Sep 2008 issue of Wired titled “What Bugs can Teach Bosses.”  The article looks at different animal species and relates them to work patterns and behavior for humans.  It got me thinking about how similar they were Agile principals.  I love when you can find examples in Nature that can be applied to every-day work life.

Ants and Bees – Broadcast Messaging

Ants use chemical signals to transmit messages and bees dance to tell other bees where to find food. This style of communication increases group efficiency by giving everyone access to the information and then individuals can decide what to do with the new information (if anything).

People in Agile organizations benefit from this style of communication as well, commonly referred to as “whole-group communication.”  At the daily Scrum team-members sync with one another doing a sort of “bee dance,” while throughout the day they might be updating themselves through CI build notices, participate in electronic group chats, or view burn-down charts and story boards. (e.g. leaving chemical trails).

Geese – Collective Leadership

Geese fly in a V-formation because it helps conserve energy and so that they can be guided by a leader.  You see, scientists have discovered that no single goose knows the entire route alone.  The lead goose will rotate out, letting other geese take their place.  Each goose knows, or has memorized, their portion of the flight path and they lead the part they’re most familiar with.

Agile teams can learn from this concept.  XP strongly recommends the use of “specialized generalists.”  This isn’t to say that you shouldn’t have experts on your team!  Teams can consult with their subject matter experts, playing off one another’s strengths and weaknesses — which is what makes them more creative and productive than any single individual.  Just like a flock of geese, don’t be afraid to change out leadership for the portion of the flight most familiar to expert individuals.

Worms – Interconnectedness

Worm brains have a mere 300 neurons.  This might be surprising, but the 300 they have are very interconnected.  This exceptional number of connections allows the worm to do a lot, with just a few brain cells.

On a Scrum team the ScrumMaster acts as a hub.  They’re the most interconnected individual working with the PO, tracking issues within and outside the team.  They can interface with other ScrumMaster’s, on other teams, adding to their interconnectedness .  If issues arise, the ScrumMaster can help serve as a guide and help the team avoid bottle-necks.  They can also help “fine-tune” the team’s strategy, especially as new information comes in.

So look at how your own team is working.  Are you leaving “chemical trails,” have you embraced broadcast messaging?  Do you recognize the expert talents of different team members and defer to them when it’s their “time to shine?”  Are you okay with stepping down once your expert role isn’t needed, letting someone else take the lead?  Is someone on your team playing the “hub” role, using their interconnectedness to identify, track, and resolve issues and clear bottle-necks?  There is a lot we can learn from nature…

No comments »

Posted in Agile

Tags:

Working Agreements

June 14th, 2009

Tomorrow is going to be the first offical sprint planning meeting for the team I am on at Trion.  I’ve been doing Scrum since 2006, and I have facilitated a good many planning meetings.  This time I’m not the ScrumMaster, but a developer — so it’ll be interesting to be in a different role.

The first sprint planning meeting is very important because it’s where the team will receive the first glimpse at the product vision.  They also meet one another and establish a framework from which they will work with one another — a working agreement.

Working agreements help teams codify what the rules of conduct are.  They can cover any variety of concerns from “No cell phones on ring during meetings,” to things like “Code is *done* when it has been peer reviewed, signed-off by QA and checked into the development branch.”  These rules help the team manage expectations, especially through the storming phase and into the norming phase.  It should be placed in a visible location near where the team is working.

A working agreement needs to be crafted and agreed to unanimously by the team (not management).  Consensus is very important here, because people cannot claim later to not of been ‘on board’.  The team should revisit the agreement during their retrospectives and decide if they want to add, modify or remove anything.   Below is a real-life example working agreement from a highly productive Scrum team:

  • Tell the Truth!
  • Use the Impediment Backlog for blocking issues
  • Address any issues to the correct party (at the right time)
  • Meetings: be on time, end on time, have an agenda
  • Communicate individual schedule
  • Use sticky note on monitor, email, phone call, etc.
  • Update backlog before SCRUM daily stand-up
  • Be present for core hours:  10am to 5pm PST
  • Communication – to the best of our ability
  • Publish phone numbers and calendar
  • SCRUM is at 11am PST
  • If unavailable for SCRUM, communicate status
  • TDD is a requirement for the project
  • Pairing or code reviews are required for any shipped code
  • When pairing turn off distractions (email, IM etc)
  • Define and adhere to DONE criteria for stories
  • Record accurate (actual) hours
  • Define and adhere to version control rules
  • Don’t break the build!

As you can see anything is fair game.  Working agreements grow over time as the team unmasks issues and finds solutions.  Having a punch-list of rules helps keep agreements fresh in memory so there is no reverting to bad habbits.

1 comment »

Posted in Agile

Tags:

Common Agile Observations

May 7th, 2009

Heading up the AgileAustin workshops I get to meet with a lot of passionate Agile practitioners working in the real world. What I find amazing is how we all have similar experiences and common challenges.  Below are some of the common themes I’ve observed from my own career and also from talking with other ScumMasters, maybe you’ve seen the same thing:

Adoption

This is the holy grail question of anyone looking to start going Agile, “How do I get adoption at my company?”  Adoption is best started at the ground level (according to Ken Schwaber).  The reason he identifies this is because of command-and-control (what I call ‘old-school management thinking’).  Teams who are under command-and-control only act when they’re told to, and don’t take the initiative on their own.  Also managers who practice command-and-control believe it is their job to provide the team with answers (both what and how), instead of waiting for the team to figure out a solution on thier own (and that includes making mistakes).

Understanding the New Roles

So if it isn’t the role of the manager to provide answers, what is their role?  The role of a manager in an Agile organization is that of a servant leader.  Their job is less about control and more about service — you help remove impediments to the team.  A good servant leader values collaboration, trust, empathy and the ethical use of power.  Your primary objective is the enhance the grow of individuals, increase teamwork in the organization and personal involvement.

Product owners are responsible for prioritizing and organizing the backlog (a list of features to be completed).  They develop acceptance criteria so that the team understands what is required for a feature to be considered “done” and they work with the team to estimate the features (usually by size).  They own the “what” question (what should be built, what’s most important or not, etc) and define releases.

In an Agile organization the Product Owner is the “single wringable neck.”  This is to say they’re ultimately responsible for the product’s success or failure.  The are probably the most important individual on a Scrum team since they decide what features get built and thereby set the direction of the team.

Team members, other known as ‘pigs’ (because they are committed to doing the work), are responsible for selecting the work they take on.  They do so inside a time-box, meet frequently, and at the end demonstrate their work.  The team is responsible for the “how” question (they own the implementation details, design, etc).

Anyone else is a ‘chicken’, that is someone who contributes but isn’t committed.  (Mike Vizdos has a great cartoon explaining the pig and chicken metaphor).  Chickens can be anyone from an outside consultant or subject matter expert to a CEO.  They might attend the daily meetings with the scum team, but they are not participants in these meetings (because they’re not committed to the work).

Assuming it’s About Developers

These role changes are often not fully embraced or recognized.  Organizations might take some steps in the right direction:  they create a backlog, they move to 1-2 week sprints, they might even have daily stand-ups and demos/retrospectives.  Scrum is more than just an adjustment to the lifestyle of the developer.  Their needs to be a strong product vision that everyone understands and is behind.  Concensus is very important, people who are not sold on an idea are not going to put their passion into the work.

This is where leadership needs to inspire (not measure) everyone on the team to the goal set before it.   The team has to be self-directing and encouraged to self-organize to reach it.  Scum is about changing how your organization approaches problems and comes together to work as a whole team – manager, product owner, and the scrum team.  I recommend Jean Tabkia’s Collaboration Explained for some exellent inight into teams and how they work.

If there is a manager-type stomping around telling people how, what and when to get things done – you’ve missed the boat.

Individual Performance Evaluation

The last big impediement I often observe is what I call ‘team self-destructive behaviors.’  These are agile anti-patterns that primarily come from old-school management philosophies and lack of education about teamwork.  Some of these ideas are:  workers are inherinantly lazy, workers need to be told how to properly do their job, worker productivity equals hours worked, etc.  What ends up happening in some organizations is that managers task out the work for the team, will estimate it for them, and even sometimes assign tasks to specific members.  (In short, the team is deprived the ability to be self-directing and self-organizing).

Any behaviors that focus on the individual and measures individual performance, rather than the team’s performance, are counter productive to building a good team!  When you value individual performance a strange rivalry is born between team members which stops them from working as a team.  For example:  Steve and Bob are both working on different features.  The feature Bob is working on is highest in priority.  Steve finished his feature early – instead of helping Bob with his, he moves on to another story to show Bob up and make himself (Steve) look good to the management.  The sprint ends without Bob finishing the most important feature.

Ester Derby wrote an interesting article about performance and appriasial.  She suggests that the idea of ‘merit pay’ should maybe fall out of style.  We don’t want to reward people for knowing how to work within the system, we want to reward people for improving the system.

No comments »

Posted in Agile

Tags: