Tag: Agile 2008

We do Agile, but Where is the Quality?

This post is an assemble of notes from sessions at Agile 2008, including Paving the Way for Agile Testing, Expanding Agile Horizons, The Five Dimensions of Systems by Mary Poppendieck, Natural Laws of Software Development – Deriving Agile Practices by Ron Jeffries & Chet Hendrickson plus keynotes from Uncle Bob Martin (Quintessence) and Alan Cooper (The Wisdom of Experience).

There is plenty more to consider than what is written here to on the topic of quality, of course, but these stood out for me in the sessions I attended.

Do the Engineering Fundamentals

Of all the things I heard at the conference, these were repeated again and again, in varying contexts. Why? They are proven to work. Bob Martin argued that these should be embodied in the Agile Manifesto by adding a 5th Value: Craftmanship over Execution. He argued that those who work in software development need to take more pride in their work, and insist on doing the things that must be done produce quality work.

Refactoring

  • Allocate time in advance for refactoring
  • Need to ensure customer understands need to to increase technical debt, even though refactoring may not have “business value”. You either make small ongoing payments to keep debt manageable or face huge debt later. May want to have customer sign off on this.

Test-Driven Development

  • Kent Beck’s definition: First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find.

Continous Integration

  • Without CI, small releases are difficult to do, integration problems aren’t found until much later.

Acceptance Tests

  • These describe what the stories should do, with real examples that can be executed in code.
  • Need to be automated, becomes more critical after each successive iteration.
  • Acceptance TDD – acceptance scripts written ahead of the code, written by testers and devs, FIT / Fitnesse recommended tool

Need Technical Leadership

From Lean thinking: have a development manager, someone who is a technical leader who is responsible for successful engineering practices. I see this person overseeing the use of the engineering fundamentals listed above. There needs to be leadership in our teams, from both a technical and management perspectives.

Definition of Done is Foundational

Everyone on the team, as well as the client, needs to agree on when a story is considered complete.

  • Define your Definition of Done (DoD) before the first iteration
  • A definition might include:
    • Unit / integration tested
    • All acceptance tests pass
    • No increase in technical debt
  • Example definition at Menlo Innovations:
    • Developer asks the QA/HTA pair for a “green dot”, but before asking, all unit tests must pass, code must work on machine other than developer’s own
  • Keep the definition visible for the entire team
  • Only a strong DoD (with many automated tests) will be maintainable
  • Maintaining a definition of done begins by first building trust. Trust might be demonstrated by granting full access to modify docs and code, providing the tools and support the team says they need. “The first thing to build is trust” – Brad Appleton

Specialized Testers Can Ask Questions that Need to be Asked

  1. Actively seek out defects
  2. Provide feedback, saves time
  3. Test-specific knowledge and techniques, can help others to test better.
  4. Good at asking questions during iteration planning
  5. Can offer feedback on documents and unit tests
  6. Can assist customer in translating requirements into acceptance criteria, writing acceptance scripts

At Menlo Innovations, QAs spend their time (in order of time spent):

  1. Asking questions
  2. Understanding user needs
  3. Understanding development implications
  4. Do some testing

Interaction Designers Can Turn Raw Data Into Useful Requirements

Alan Cooper argued that interaction designers (ID) bring an essential element to the team’s success:

  • Interaction designers can make sense of human behavior in the same way that a programmer can make sense of a computer’s behavior.
  • Their key contribution is translating research into actionable sketches and narratives that programmers can use. Their work frees programmers from communications failures, management misunderstandings, and wasted work. Those sketches and narratives are like user stories except that they are more accurate, more precise, more detailed, more correct, more complete, more readable, and more understandable by managers as well as by programmers.
  • Research shows that users don’t really know what they want or need. Where interaction designers can deliver significant, unique value is in their ability to distill useful answers from the distorted, raw data extracted from, or contributed by, humans. Interaction designers use ethnographic research, user models, scenario construction, role-playing, and other specialized tools for the distillation process.
  • “The operation was a success, but the patient died”. It is not uncommon to have a successful, Agile development project that still fails to satisfy the user.

Other Tidbits

  • A method to prioritize bugs: place bugs in one of 4 quadrants: likelihood of occurrence vs. importance to client.
  • To verify a build:
    • Generate a list of questions, like “Can a user log in?”
    • Answers not provided, as they may change
    • Questions generate conversation

Effective Pairing: Good, Bad and the Ugly

These are notes and video taken from the highly entertaining Agile 2008 session Effective Pairing: Good, Bad and the Ugly. Thanks to Ryan Hoegg, Lasse Koskela, Dave Nicolette, Brett Schuchert for letting me capture them on video. These four guys acted out personalities, scenarios and pitfalls that can occur with pair programming, each skit followed by a room discussion on how to address the issue(s).

I did manage to write down a few of the tips mentioned:

  • Problem: experienced dev takes over pairing work to meet deadline. Keep track of the number of times that one developer takes control of pairing situation to meet a deadline.
  • Promote code team ownership, skill team ownership. Anyone can change (and hopefully improve) any code in the project. The team must take responsibility for improving each other’s skills. Find the time to help someone get better, otherwise one dev becomes an island of knowledge. Tomorrow never comes!
  • Isolated problem or ongoing? Observe if the situation is part of a pattern or a one-time event.

Part One (12 min)

Part Two (26 min)

Part Three (26 min)

Money For Nothing: Deliver More Value For Your Client (And You)

These are notes from Jeff Sutherland‘s Agile 2008 presentation “Money For Nothing and Your Change For Free: Agile Contracts“. Jeff summarized his talk in this way:

“The “Money for Nothing” strategy works when customers want fixed price estimates for the entire contract up front. The Agile contract allows termination of the contract early when the value of features drops below an ROI criteria. The contract allows the customer to save 80% of their remaining funds by giving the Agile vendor 20% of the remaining contract value in return driving the margins of an Agile contractor from 15-20% up to 50-80%.”

From Scrum Butt to High Performing Team

Jeff began his presentation by talking about the Nokia Test For Scrum Certification, which Nokia uses to measure their team’s level of agility (see questions and scoring method in slide show below). Jeff had everyone in the room score their own team. I rated ifPeople in general at a 5 out of 10, which is just above the starting average. Anything 8 and under is in the ScrumButt category.

Why is this important? Teams that score high tend to be the high performing teams. They also generate much higher revenues, based on Jeff’s analysis:

  • Great Scrum: 400% revenue increase
  • Good Scrum: 300%
  • Pretty good Scrum: 150% – 200%
  • ScrumButt: 0 – 35%

Jeff also compared agile to waterfall teams, suggesting high performing agile teams can outperform waterfall teams by a 5-6x margin. The problem is, contracts that are time and materials don’t reward high performance. T&M is low risk and low margin, you only get paid for the hours you put in, even when you take far less time than your competitors. Fixed price contracts aren’t any better, with vendors trying to out-discount each other. Many vendors only making money if the project is late and over budget due to change requests and building functionality that users do not want.

Money For Nothing

What if there was incentive for projects to end early? The Money For Nothing clause does this. Here is how it works:

  1. Use standard fixed price contract, with time and materials for changes.
  2. Insert Money For Nothing clause
    1. Only operational if customer follows Scrum rules
    2. Mutually agreed estimates for all work items, otherwise contract reverts to time and materials (thus incentive to agree)
  3. Customer decides when value of continuing project higher than cost to do so.
  4. Supplier allows termination of contract at any time for 20% of remaining contract value.
  5. Supplier assumes risk of late delivery of mutually agreed work.

Change For Free

Next, add incentive for the customer to follow Scrum process, and to be aware of impacts of changes to the release plan by adding a Change For Free clause:

  1. The customer must execute this option by working with the Scrum Team every Sprint.
  2. Failure to do this voids this clause and the contract reverts to time and materials.
  3. Changes are included with these rules
    1. Changes in priorities are free if total contract work is not changed
    2. New features may be added for free at Sprint boundaries if low priority items of equal work are removed from contract
  4. Requirements of customer:
    1. Features are prioritized by business value and implemented in order of maximum value
    2. Users follows project closely and work with the Product Owner to produce a quality Product Backlog

Embedding Scrum Incentive Into Contract: I Like (A Lot)

One of the reasons I went to Jeff’s session is we’ve struggled with some clients to get them engaged with the Scrum process. Yes, we do need to do a better job of explaining the process up front and what is expected of them. Defining roles and responsibilities right into the contract gives them proper visibility. Having incentives for the client to *want* to work in Scrum style increases the likelihood that they happen.

Extreme Data Point: Abandon Projects

Jeff ended the session by proposing that “projects are bad”. You know, the way most of us organize our work around teams. Apparently, this is a feeling shared by some other agilistas and companies, and more information will be published on this topic, hopefully later this year for further discussion.

Why are projects bad? Mostly because of tremendous start up / tear down costs. The new idea is to keep teams together, and have them all working on a continuous stream of work from a shared backlog. Work is then packaged up somehow into deliverables to clients. One way to do this approach is to productize architecture.

Challenges Distributed Agile Teams Face, and Ways to Overcome Them

Notes taken from Agile 2008 sessions on distributed Agile: “What Makes Distributed Agile Projects Succeed (or Fail)?” workshop by Chris Sims and Panel discussion on troubleshooting distributed agile team projects

Things panel found most surprising about distributed Agile (DA)

  • There are people at the other side!
  • DA can work well once the proper process and tools are in place
  • We can learn from teams in other places
  • Agile helps to ease cultural, time burdens through increased communication

What makes DA harder than co-located teams

  • Planning overhead is higher for distributed teams. May need to stretch out length of iterations, to adjust for the additional overhead needed for distributed communication
  • Standup and meetings in general take more time
  • Don’t act like your project is co-located – pay the tax for distribution
    • Executable requirements may help a lot – Fitness tests
    • Mini-specs for user stories – need to communicate more in writing with remote people
    • Use acceptance tests to drive story clarity
    • Have developers review tasks ahead of time to prevent blocking
    • Involve everyone iteration planning

What is most important to succeeding with DA

  • Unanimous: Need to get people together to build relationships, get more collaboration. Plan for at least 2-3 times / year. This also helps to understand cultural differences. Build in the cost of these trips into rates.
  • Leverage technology to bring people closer together – video top choice for people on panel. Use video to see each other, point to documents being discussed
  • Strong engineering practices – continuous integration, TDD, pairing, refactoring – on some teams, you can’t go home with anything that doesn’t build
  • Invest in coaching. You can improve scrm abilities by going down and training, spending time. Identify leadership within teams, and work with leaders to be a local proxy scrum master
  • Take time to understand cultural differences – inward (your own), outward (other cultures)
  • Need a well defined definition of done for team to follow.
  • The best way to build teams is through work. Succeeding (or failing) together at something draws everyone closer.

Other tips and observations

  • Time box discussions after standup if they tend to run too long.
  • Decide if people are suited to agile. Do they take pride in and ownership of their work? Do they show initiative? Are they technically strong?
  • A local proxy product owner is helpful
  • Take time to share about culture. Do things like share recipes, talk about movies, etc.
  • Get pictures of team members and look at them when collaborating.
  • Use remote pairing – avoid isolation
    • VNC and Skype are one option
    • When pairing isn’t possible then use code reviews to ensure *some* kind of review happens.
  • Ade Miller in his session notes observes that distributed teams are more dysfunctional than co-located teams. The act of distributing a team simply adds to any existing problems it might have.
    • Be prepared to do additional work to negate the impact of team distribution.
    • Articulate this work and cost to the business. It’s all about delivering maximum value to the customer not about hourly rates of individuals. Overall is the team delivering more value?

Agile 2008: Thursday & Friday Session Picks

Okay, round 3 of the Agile 2008 session picks. Agile 2008 is the premier conference of the Agile world. There are about 400 different sessions to attend, which is why I’ve taken about 2 days to wade through all the options. Earlier I posted my faves for Tuesday and Wednesday.

Thursday

Early Morning

Tough choices. Leaning towards Eric and the panel in the next session, otherwise user story mapping.

Before Lunch

  • From High-performing to Hyper-performing Agile teams, panel discussion. Presentation of 3 unique case studies, by 3 top notch agile guys, each showcasing how to crank up the agile performance.I want to hear “techniques for working with many and varied clients simultaneously: how to maintain consistent and predictable velocity, how to scale teams without losing efficiency,and how to move developers fluidly between multiple teams and multiple products.”

After Lunch

  • From Concept to Product Backlog – What Happens Before Iteration 0? by Gerard Meszaros, Janice Aston. “This tutorial provides an overview of what needs to go on “behind the scenes” between when a project is conceived and when development can start in earnest. It identifies the artifacts that may need to be produced, whether and when they should be produced, which activities can be used to produce them and who should be involved in those activities.” ‘Nuff said.

Late Afternoon

Friday

Agile 2008: Wednesday Sessions I’d Like To Attend

My last post covered sessions I’d like to attend at the Agile 2008 conference on Tuesday, the opening day. Here is the short list for Wednesday:

Early Morning

Before Lunch

After Lunch

Late Afternoon

Agile 2008: Tuesday sessions I want to attend

Following Mark’s lead, I am posting sessions I would like to attend at the Agile 2008 conference. There are so many good ones to choose from, it’s hard to decide! If you are planning to go to any of these sessions, post a comment and let’s get in touch. Also check out the Agile 2008 Friendfeed room for others attending.

Tuesday

Morning

  • Expanding Agile Horizons: The Five Dimensions of Systems by Mary Poppendick. I’ve read from a few people she is an amazing speaker worth listening to, regardless of topic. I’m interested in learning where Agile may be heading next.
  • Agile Distributed Teams by Douglas Shimp. At ifPeople, all developers work for partner companies in South America, mostly Argentina. I’m based in Canada and the rest are in Atlanta. So yeah, distributed is a big topic for us. 🙂
  • Leadership Success Recipes for Agile in the 21st Century by Jean Tabaka, Chris Louvion. Jean is another amazing speaker. I’m particularly interested in leadership as a project manager trying to become a scrum master. Only down side is talk seems focused on large organizational issues, though not 100% sure about that.

After Lunch

Late Afternoon