Agile Software Development - Better ways of developing software

Agile 2008 Guide - Wednesday Early Morning

Artem — Thu, 03 Jul 2008 22:59:57 -0700

Agile 2008 is the premier conference of the Agile world. There are going to be almost 2000 participants and about 400 different sessions to attend. It means plenty of interesting conversations and a lot of activities to choose from. However, it also means that you have to make a choice between many different options. During the main part of the conference you have to choose between 40 to 50 different sessions.

This part of the guide covers Wednesday August 6, 8:30 - 10:00 time slot. In the table below you can find links to the full description, author bio and the answer to the all important question "Why would you want to go there?" All the sessions with white background take 90 minutes, all the sessions with orange background take 180 minutes (and therefore are occupying the next time slot as well), all the sessions with the light blue or light green background take less, than 90 minutes.

If you feel that some summaries are inaccurate, please, comment - I will correct the mistakes.

You can find more information about the conference at http://AgileSoftwareDevelopment.com/Agile2008

Topic

Speakers

Why you would want to go there

Resistance as a Resource

Dale Emery

Come to this talk if you are going to change your organization and are not sure how to deal with the inevitable resistance.

Natural Laws of Software Development - Deriving Agile Practices

Ron Jeffries
Chet Hendrickson

Come to this talk if you are interested in deep understanding of the Agile principles. XP gurus promise the highly dynamic and interactive session.

Embrace Uncertainty, why in Agile development knowing what you want may be an impediment to getting it

Jeff Patton

Come to this talk if your teams are delivering what was asked on time, but it is not what customers actually values most.

Stop Thinking So Small with Agile

Ryan Martens
Jean Tabaka

Come to this talk if you are interested in understanding the underlying principles of the Agile concepts evolution.

Driving Agile Transformation from the Top Down

Peter Morowski

Come to this talk if you are a top manager going to transform your large organization into an Agile one. You’ll see what Borland experienced in the beginning of their way (they are not done yet).

Open jam: create your own session at the conference

A chance to discuss what interests you most.

Constituencies and Concerns, Reactions and Aspirations in Developing a Software System - Rev 0.5

James Bullock

Come to this “talk with exercises” if you are trying to transform your organization into an Agile one and cannot understand the reasons for resistance.

Boosting your testing productivity with Groovy

Andres Almiray
Ixchel Ruiz

Come to this tutorial if you are programming in Java, use automated testing and are unhappy with the flexibility of your testing tools.

TDD Clinic: incremental design with Mock Objects

Steve Freeman

Come to this clinic if you are a Java developer willing to learn how to drive effectively the design with the help of test-driven development.

Clean Code Clinic: Dealing with CRRAP - Microtesting Legacy Code

Michael Hill

Come to this clinic if you are a developer having to deal much with the legacy code.

Architecture in an Agile Organization

Chris Sterling
Michael Phoenix

Come to this talk if you want to transform your large organization into an Agile one, but wonder who will care about the right architecture and common quality level.

Live aid: Participate in a real agile project at the conference

Come there if you want to feel the real agile team working. Note, that you might participate fully or drop for 10 minutes if you have a free time slot.

Agile at Scale: What it Takes on the Right-Hand Side of the Chasm

Scott Ambler

Come to this talk if you theorizing about the future of Agile.

XUnit Test Patterns and Smells; Improving Test Code and Testability Through Refactoring

Gerard Meszaros

Come to this tutorial if you are a developer working or going to work in a test-driven way. You will learn ways for improving your approaches to testing.

Evolving Guidelines for Implementing Pair Programming in the Classroom

Laurie Williams
D. Scott McCrickard, Lucas Layman, Khaled Hussein

Come to this experience report if you are involved in teaching pair programming.

The Learning Circle: an evolution of Agile for learning environments

Garry Berteig

I am sorry, but I failed to understand what this experience report is about except for that it is about the experience of a former video production director who discovered the Agile methods.

Coding Dojo: an environment for learning and sharing Agile practices

Danilo Sato
Mariana Bravo

Come to this experience report if you would like to arrange coding dojos, but are not quite sure how to do it well.

Coaching Agile Teams

Rachel Davies
Liz Sedley

Come to this workshop if you are an Agile coach or Scrum Master. You’ll be able to learn on-site coaching techniques and will be able to compare different coaching styles.

Real Options in a Nutshell - Bottled Common Sense

Olav Maassen
Chris Matts

Come to this tutorial if you would like to get deeper understanding of Agile principles and foundations. You will learn how a particular rational framework can be used as for understanding the decision making process.

Starfish are agile!

Vinayak Joglekar

Come to this talk if you like reiterating that bureaucracy is bad and distributed self-organization is good.

Value Stream Mapping - Extending Our View to the Enterprise

Alan Shalloway

Come to this tutorial if you are applying Agile methods in your team and your biggest constraints are out of the team, or if you want to understand better what is the most important optimization point for your team.

Jeu de Direction

Yves Hanoulle
Bernard Notarianni

Come to this workshop if you speak French and understand the description.

Fashion Cycle

Tobias Mayer

Come to this funny session if you are familiar with Scrum and/or XP and would like to practice it in a funny way. Come if you like fashion clothing.

Overcoming Resistance to Change

Dave Nicolette
Lasse Koskela

Come to this workshop if you are involved or going to be involved in the organizational change. You will learn what kind of resistance to expect and how to cope with it.

Lessons from Agility meets an eCommerce SaaS Product

Bob Galen

Come to this talk if you are involved into SaaS business, have some positive experience with Agile and would like to build on top of it.

"It’s not the pants, it’s the people in the pants": Learnings from The Gap Agile Transformation

Michael Elbaz
David Goodman

Come to this experience report if you like learning from other people success. It’s a typical mostly successful transformation story.

Crawl, Walk, Run: 4 years of Agile Adoption at BabyCenter.com

Keith Nottonson
Kenneth DeLong

Come to this experience report if you like learning from other people success. It’s a typical mostly successful story of going into Scrum.

Moving from Waterfall to Agile

Kalpana Sureshchandra
Jagadish Shrinivasavadhani

Come to this experience report if you like listening to the reports on transition to Agile. Quite a typical one.

Tidal Wave: The Game Changing Transformation

Mun-Wai Chung
Sofyan Nugroho, & JF Unson

Come to this experience report if you want to hear about a long term transformation (it took two years for these guys).

Transitioning Large Scale Project into Agile and Beyond: issues encountered and better practices

Eric Lee

Come to this experience report if you want to hear about a large project transformation analyzed with a formal framework.

7 years of agile management

Rene Barto

Come to this experience report if you are thinking about moving a research intensive team to Agile.

New Car Development in Toyota

Kenji Hiranabe

Come to this talk if you wonder how Lean works for Toyota. This is a translation of a session give earlier by the Toyota’s Chief Engineer of Lexus/Sc and IS.

Scaling Up - pushing Scrum out of its comfort zone

Richard Lyon
Marcus Evans

Come to this experience report if you already apply Scrum successfully on the single team project and are thinking about expanding it to the multi-team projects.

Functional roles, managers and individual growth in Agile contexts

Rachel Weston

Come to this panel if you care about the career path and compensation in the Agile world.

Building Your Coaching Skills

Johanna Rothman

Come to this tutorial if you are a technical leader who is not exactly a coach, but from time to time needs to coach your team members. You will learn when to do it and how.

Toward Enterprise Agile Scalability: A New Way to Look at Accounting for Agile Software Development Costs

Pat Reed

Come to this tutorial if you know what FASB accounting standard is and have problems integrating it with Agile.

The product owner team

Alan de Ste Croix
Alan Easton

Come to this experience report if in your organization it is difficult to assign a single product owner for the project.

The Intermediate Customer Anti-Pattern

Tom Perry

Come to this experience report if your customer is not the actual user of your products.

Successful Customer Collaboration Resulting in the Right Product for the End User

Sean Cohan

Come to this experience report if you have to work on short projects (such as 6 week long ones).

Barely Sufficient Portfolio Management

Todd Little
Kent McDonald

Come to this tutorial if you struggle to integrate your product into a bigger picture. You will earn about product, project, and portfolio management issues in order to optimize overall return.

Mental Models: Sparking Creativity Through Empathy

Indi Young

Come to this workshop if you want to improve your understanding of your users’ motivations and reasons.

The Design Studio: Interface Design for Agile Teams

Jim Ungar

Come to this experience report if you need to improve the UI design done by the Agile development teams.

An Agile Approach to Proposition Assessment

Luke Barrett

Come to this experience report if your organization is flooded with the ideas that somebody has to choose from.

Distributed Retrospectives

Jutta Eckstein

Come to this workshop if you are a coach who needs to facilitate the work of several distributed Agile teams (or one of these teams). You will learn the ways for organizing the good distributed retrospectives.

Panel discussion on troubleshooting distributed agile team projects

Monica Yap

Come to this panel if your distributed teams aren’t working as well as you’d like. You can get answers to your own burning questions.

Code coverage: a tool against unused and untested code

pbielicki — Wed, 02 Jul 2008 23:00:15 -0700

I'm an agile developer because I write my code incrementally i.e. only what I need today. I usually start writing the code by writing Unit Test - it really works and it really helps me understand what should be implemented and how system should behave (I will leave the subject of convincing people, who are new to unit testing, to do "write-test-first" for a separate post). OK - I usually do this but sometimes it's difficult or I'm just too impatient to see the result and start with the implementation and write unit test later. How do I know which packages/classes/methods are tested and which are "not touched" by any single unit test? How do I know that my code is really used somewhere by other parts of the developed system? This is the work for code coverage tool.

What is code coverage
According to Wikipedia article code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing. For me as an agile developer code that is not tested is not used and not needed. I mean it! If the code is not tested and not used it is the code that "will be needed in the future". I don't accept such code - if I need something in the future I will simply add it - if I don't need something at this moment I have to remove it (because not used/tested code may contain bugs).
If some part of my code is not tested it means that I don't need it - that is true in almost 100% of cases. This way code coverage tool shows me not only which parts of the software are tested but also which parts of the system are not used and can be removed.

Example
I use Cobertura code coverage tool that calculates the percentage of code accessed by tests. Let's take a look at this simple project containing 19 classes:

This report does not tell many things - useful information is that line coverage of the whole project is 70% and the branch coverage is 25%. The only conclusion you should get looking at this report is that the project is not well tested (or contain some unnecessary code).

If you navigate deeper and take a look at some classes you could see something like this:

This report tells me as a developer that e.g. getDocs() and setDocs(String) methods are not visited during unit testing. I assume that these methods are not needed thus I remove them (!). You should consider doing the same.
If it occurs that you need those methods write unit test that covers this class and those methods immediately.

Bad example from the past
I have very good example how not to write code and how code coverage tool can help you catching such problems. In the past when I had to write some exception hierarchy I started writing exception class with implementing all constructors from the superclass i.e. java.lang.Exception - just in case ;) Here it is:

This means that I had 4 constructors in each exception class but was using usually only one... Why to write the constructor that nobody wants? There is no need to do it!

Consider following Cobertura report:

This is how I write code now :) I start with the unit test and add the code incrementally only when needed. And Cobertura (code coverage tool) helps me assuring myself I'm using my code.
This way I'm sure at least two things:
1. My code is well tested (maybe not well tested but at least I know to what extent it is tested)
2. I've written only the code that is needed - there is no "dead" code

Conclusion
The best way to write code is to start with unit test and to write it incrementally - implement ONLY what you need today. If you are not feeling good with test-first principle and you prefer write an implementation first (you shouldn't) make sure you use your code. One way to do this is to employ code coverage tool (open-source, or commercial ones like Clover). Such tool will show you which parts of your system need testing or simply which parts of your system are not used and can be removed. After each build I check code coverage report to see how much work I have and I really don't like red color (I love green instead :)

What do you think about usefulness of code coverage tools? How do you write your code - are you really writing your code incrementally? How do you ensure that?

World wide collaboration

marioale — Mon, 30 Jun 2008 23:14:24 -0700

These days, many large scattered development teams work in medium to very large projects all over the world. This is what's going on for most open source project teams and with companies with geographically distributed teams.

This is the world wide collaboration development era. There's the need for a suitable collaboration software that provides the tools, ease of use and scalability that those teams demand.

At my university, we used GForge open source version ( http://gforge.org ), so I looked at GForge AS from GForge Group ( http://gforgegroup.com ) when I joined my current company in Argentina. They have the older open source version and two newer versions, the free Express Edition and the full Advanced Server. This is an enterprise-grade collaborative development management software, brought by the same people that created SourceForge and GForge open source.

I'd like to point out some features we like and helped alot on our daily work:

Full-blown Tracker/Code Integration

It provides a powerful tracker with Subversion/CVS integration. It does all that the basics, but also offers some advanced features that, in my case, have found very useful: you can define rules on when commits can be made, or define re-assignments or changes when commits are made, etc.

Workflow, well beyond the basics

Workflow features let you change or reassign tracker items when source code commits are made, and have these changes cascade to other workflow rules that can, in turn change other fields or reassign the item again.

Eclipse, MS project and Visual Studio plugins

Those who work with Eclipse or VS will benefit with the plugins. You can do a lot of the usual management stuff without leaving your environment.

Permission Management

There's an easy interface for the project administrator to set up roles and who is assigned those roles in the project. Each role can have unique permissions in individual trackers, forums, source code trees, etc.

If you want to try it and see if it works for you, you can download a VM from their site and start playing with it right away.

Oh My God, They Fixed the Bug!

JurgenAppelo — Mon, 30 Jun 2008 23:00:58 -0700

A year ago, when I bought my new car, I noticed that the knob on the gear stick was loose. I was able to rotate it 360 degrees. I assumed that it was not supposed to be delivered that way, but I didn't care. In fact, while driving my car for a year, I got used to this bug and it turned out that I actually liked it. The knob rotated with the movement of my hand while shifting gears, and I kind of thought that was cool. And I liked fumbling with it while waiting for traffic lights to turn green. (Which, in my country, amounts to a lot of fumbling.)

Well, last week I turned in my car for its first scheduled maintenance. And after I got it back, while driving home happily in my serviced car, I suddenly noticed something was wrong... I was feeling resistance to my fumbling. I was unable to rotate the knob on the gear stick. It appeared that the service guy had fastened it! A jolt of anger shot through my system.

Oh my god, they killed the bug. (You bastards!)

That same day my blogging friend Max Pool posted a video in which he claimed that companies should communicate benefits to customers, not features. Max said a company should not communicate that a styrofoam cup weighs 60% less than a paper cup (a feature) but that the cup is better for drinking (or some other benefit).

I don't agree.

The Only One to Decide What the Benefits Are, Is Me
I really don't care that some company thinks that the styrofoam cup I'm holding is good for drinking. I can decide for myself what its benefits are, thank-you-very-much. I might use the cup to hold the pencils on my desk, or my little bonsai tree, or I could cut it into rings to decorate my X-mas tree. And yes, I might be interested in its weight to see if the cup is able to hold down the insect that is trying to eat my donut.

Learn the Benefits from Your Customers
There was an article in New Scientist recently on the strange things that people do with their mobile phones. Some people use their cellphones as proof of identity (as an alternative to an identity card) or as a money transfer system. Making phone calls is just one of the many interesting things you can do with a cellphone, and Nokia is actively trying to learn from the innovative activities that their customers come up with. Nokia doesn't tell their customers what the supposed benefits are. Nokia tries to learn them!

When you create a product, it is often necessary to anticipate what your customers want. You have to imagine needs and benefits, and design your product accordingly. But once your product is out in the open, being used by your customer, you must stop acting on imagined needs and benefits. You must accept whatever it is the customer is doing with your product. Don't tell your customer how many suitcases the trunk in a car can hold. Just tell the customer what its dimensions and volume are. Whether your customers want to translate that to "number of suitcases", "number of sheep" or "number of dead bodies", is up to them.

The "problems" you fix might be "benefits" for your customer. And the "benefits" you communicate might be seen by the customer as irrelevant marketing chatter. People decide for themselves how to use your product, and you are better off trying to learn from them. You should never assume to know.

Problems or Benefits
I really liked the little problem in my car. The rotating knob on the gear stick was a benefit to me. I possibly had the only car in the world with that feature. But not anymore. Because somebody assumed to understand what my problems and benefits are. And that's a problem, not a benefit.