Posts Tagged ‘Agile’

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:

LSRC 2009 – Day 2

August 30th, 2009

Dave Thomas Keynote

Always a great speaker, Dave came down from Dallas to help kick off the conference.  Dave has been using for over 10 years, and he’s still using it.  He shares his reflections with us as to why he still enjoys programming in Ruby.

Ruby is an interesting language.  It can be described as a multi-paradaim language: object oriented, procedural, prototype-based, and functional (all at the same time).  He also points out that Ruby thinks the way he does, which also means – like Dave (or anyone of us) – it’s imperfect.

We shouldn’t worry about perfection though and instead should be pragmatic.  There isn’t only one way to do anything in Ruby, there is no “right way.”  It’s this ambiguity that helps encourage participation.  If Ruby were perfect there’d be no room for creativity, growth or adaptation.  Ruby is adding stuff – not taking away.

Dave also talked about his experience with being publicly “slammed” by Zed Shaw. He said he realized at that point in time that Ruby is not a community.  Ruby is a tool around which communities form.

Passionate people are messy, Ruby is messy.

Programming Intuition

A lot of people are programmers, very few are great programmers.  The difference in productivity between a good programmer and a great programmer can be a factor of 10.  Ruby rejects the idea that the world is simply two buckets of good and great.

  • Do one thing
  • DRY (Don’t Repeat Yourself)
  • SLAP (Single Level of Abstraction Principle)

How do good programmers think?  Does a good programmer simply boil down to command of the language and ability to recognize/use patterns?  NO!  Programming deals in abstractions and great programmers talk about code as if it were not abstract, but in tangible terms.  Good programmers can “feel” code, there is an emotional reaction.

Our brains are made to adapt to our environment (which we perceive through our senses).  Humans are wired to want physical attachments.  What senses do programmers use?

  • vision (why OO is “easier”)
  • hearing
  • kinesthesia (perception of movement, weight and position)

Code is not 2D, it’s not even 3D, it’s multi-dimensional.  So diagrams are not always useful.  Code sometimes has a “viscosity” and can be felt to push back or resist you.

What do we perceive as beauty?  Elegance?

Cultivate a Sense of Code

  • No specifications / think about it
  • Use tools that help you
  • Practice, use methods that provide immediate feedback

Experts operate on intuition, not on recipes or rules.

  • Master Ruby’s method lookup (it’s worth knowing)
  • Useful to limit scope of magic
  • Can modify individual objects with modules
  • Tr to replace inheritance with extends

Succeeding with Ruby on Rails

This talk was about the owner of Thoughtbot and how they got to where they are today.  Below are some of the notes from the talk:

  • Started in 2003 with 4 people
  • Not everyone wants to run a company
    • wanted to go into business to work the way they wanted to
    • happiness is very important
  • Perl was their “happy language” from Java, but Ruby and Rails ruined it
  • Decided to only do Ruby on Rails, revenue skyrocketed afterwards
  • Hiring is very important and hard
    • hire only people who want to learn and teach (passionate)
    • skilled
    • right attitude
    • salary (the best you can afford, not necessarily that money can buy)
  • Don’t compromise on core principals
  • Be nice

Identify what’s really important for you, don’t compromise on that decision, and be nice.

Hiring Process

When hiring people Thoughtbot first reviews a resume and code of the applicant, before they even do a phone interview.  Then an initial phone call is done, followed by a second interview if there is interest.  The 2nd interview is more technical in nature.  If an application is considered, they have to participate in a week-long immersive pair-programming situation with a developer on staff.  After this last step is then someone considered to be on the team permanently.

Core Principals

  • sustainable development (40 hrs a week)
  • all are technicians (even html/designers)
  • no contracts or outsourcing

Clients

When it comes to client relationships the approach Thoughtbot takes is to “do the best you can.”  This doesn’t always mean you succeed at every project, but you know that you did your best in trying.  Set expectations, be proactive and above all nice.

Thoughtbot does not believe in subcontracting and they insist you should work on the way you want to work.  If a client doesn’t want to work with you then you should ask them to find another team.  In the long run it isn’t worth being unhappy and you’ll just be frustrated (as will likely the client), all around bad.

Client Management

  • project planning form
  • Highrise
  • master services agreement
  • project lead (SM/PM rolled into one)

Design and Development

Like 37Signals, Thoughtbot is a big believer in design first.  They will figure out how a UI looks and works before coding.  This helps flesh out details you might not realize until later, when it’s more expensive to fix.  They practice pair-programming with an iterative, TDD development approach.  Pivotal Tracker is used to manage their backlog.

They also believe strongly that people should do what they enjoy.  Folks are encouraged to work on projects that interest them, there are not set roles or boundaries.  If a designer wants to get more into Rails, he’s allowed to take on some Rail work in a project.  There is always at least two developers per project.  If one becomes bored or wants to work on a different project it makes it possible to swap people out without affecting the project to terribly.

Open Source

Part of the culture at Thoughtbot, they’ve made many open-source contributions to the Rails space.  Abstractions don’t stay internal to the company.  By releasing open-source software they get their ideas validated and legitimized.  Payback includes recognition in the market space.  They also have to support the software less, because the community itself supports the software (crowd-sourced support).

The one suggestion for other companies looking to do open-source contributions:  keep quality high, incubate internally for a while before releasing, make sure it’s something you enjoy using yourself.

Products

The talk ended with the question about why and how do you keep Ruby relevant?

  • consulting scales w/ people
  • but we want a small company
  • products can scale without people
  • make products you use yourself
  • make products you enjoy using

How long will Rails be around for (be popular)?  How long will Ruby be around for?  We have to take responsibility for Ruby and Ruby on Rails so it remains popular.

No comments »

Posted in 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: