Notes from a Tool User

Agile 2008 Thursday and Friday Sessions to attend

...ok I'm running out of steam here, this one will have little in the of extra notes sorry.

8:30 - 10:00

Using Agile engineering tools and practices to achieve Organizational Change: Christian Gruber "Christian will examine these practices, their effects, and provide examples where such a grass-roots approach helped convince management to support or pilot fully agile approaches. He will also provide counter-examples and anti-patterns which can often lead to such an effort being blocked. Attendees should leave better armed to start practising “stealth agile” but with a mind to ultimately demonstrating its value and shifting the organization." Been there, tried that.

Creating Cultures Where Agile Emerges: Pollyanna Pixton - "Agile practices emerge in a collaborative environment. As the leader on several projects, I saw the emergence of iterative development, test first, evolving functional specs, pair programming, minimal documentation, and customer involvement at every step of the way. Successful tools to create this environment cover creating an open environment, bringing the right experience, skills, and thinkers together, how to stimulate and foster the free flow of ideas, and letting people to decide what they want to do and by when (self-accountability). Tools to lead collaboration will also be introduced." Its three hours.

Refactoring of Cultural Smells: Orit Hazzan and Yael Dubinsky - "The participants become familiar with patterns of cultural smells and appropriate refactoring activities, and are guided to check their fitness for their organizations as well as to develop new ones." As many will know this is right up my Alley.

Agile 2008 Wednesday Conference Sessions to attend...

...The good news my choices seem a little easier I only seem to need one or two clones.

8:30 - 10:00

Stop Thinking So Small with Agile: Ryan Martens and Jean Tabaka + Driving Agile Transformation from the Top Down: Peter Morowski. A pair of talks that fill one slot. Ryan and Jean will ask the question is the original Manifesto holding us back? "Are we stagnating and unnaturally suffocating the transformations that must naturally occur in order for a system to sustain itself? Are we thinking too small with Agile and are we afraid to allow and support the natural progression Agile’s usefulness and sustainability?". Peter follows on with a talk about the ongoing Agile transition at Borland: "What does an agile transition look like when it comes as a mandate from the top? How do the “rules” of agile apply to a large, established development organization? How do you scale agile principles from a single team to an enterprise with multiple teams working on multiple projects?"

Resistance as a Resource: Dale Emery "how to turn resistance from a frustration into a resource. Whatever else it may be, resistance is information — about the people we are asking to change, about the environment in which the change will happen, about the changes we recommend, and about ourselves." I expect that this an expanded version of Dave's paper Resistance as a Resource (Originally published in Cutter IT Journal Vol. 14 No. 10, October 2001).

Agile 2008 Tuesday Conference Sessions I want to attend or...

...help I need three clones at the conference with me. Join me on what promises to be a truly insane and busy week.

Tuesday, Aug 4. 10:45 - 12:15

Expanding Agile Horizons: The Five Dimensions of Systems: Mary Poppendieck - "What does Agile want to be when it grows up". Mary is always an amazing speaker. Worth listening to even when you're not interested in her topic.

Tangible Bug Tracking using LEGO bricks: Takeshi Kakeda - Dammit I've always wanted an excuse to play with Lego. Benefits: Intuitive visualization of the quantity of software bugs for everyone.

Continuous Testing: TDD Turned Up To 12: Ben Rady - "is a developer practice that involves automatically running tests after every change, even so much as a single statement. ... This session will cover the history, theory, practice, and daily application of CT to real-world projects." I'm really hoping to read a summary of this online.

Systemic Coaching Techniques for Agile Coaches: Michael Spayd and Doug Rosenberg - Coaching for the entire team: "By cleanly standing outside the team, we help reveal the system to itself, leading to greater team self awareness, higher cohesion and more conscious self-organization. Moving beyond the right and wrong of individual issues, we facilitate long-term persistent changes which benefit the whole system. We will demonstrate three techniques with the audience as participants to demonstrate this exciting new approach."

Minimalist Coding Style

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away” - Antoine de Saint  Exupéry. If you’ve ever invited me do some pair programming with you, you probably have a good idea what this quote is all about. I often wind up asking questions like:

• Why do you need this boolean named retVal? Could it be eliminated the use of early return statements?
• Is the else clause in this if statement necessary? Could it be avoided with a return statement? Or break/continue in a loop?
• I noticed that this method has parts that are nested five levels of braces deep. Is there anything we can do to reduce that?

Two recent posts Spartan Programming (Jeff Atwood Coding Horror) taken from the Spartan Programming page on the Technion Wiki and Life After If, For and Switch (Scott Hansleman Computerzen), have reminded me of this subject.

Journal of Agile/Scrum Failure

On a topic related to my recent efforts on Scrum Smells, I've started a page on the Scrum Alliance wiki to document Agile/Scrum Failures. The failures are not of the process itself but of the humans associated with the project. This all happened in response to a thread on Scrum Development that Robin Dymond started  (Blog entry: The Scrum Project that Failed). In this thread Robin suggested, that we need a Journal of Agile/Scrum Failure much like his experience in the climbing world:

When I was a member of the Alpine Club of Canada there was an annual journal called "The Journal of Alpine Accidents." Initially I thought this was odd. Once I started reading it the value instantly became clear. Climbing accidents make for gripping reading because lives are at stake. The real value is to other climbers who can read about what went wrong, what they did to correct, and how the events unfolded. This concept is not new, civil and mechanical engineering failures are studied, and we are all familiar with the painstaking work of the FAA when a plane crash happens.

With billions of dollars on the line every day, and a spectacularly high rate of project failure compared to other engineering disciplines, shouldn't we be formally logging and analyzing failures?

After reading this I decided to start the journal, but there is a small catch I don't know alot of good stories on Agile/Scrum failures so this is where my readers come in. If you know of a good failure story: i.e. an Agile/Scrum team that failed to deliver something of value to the customer then I would like to know about it. These can be stories that are already documented and you send me the link or stories that need documenting - in which case I can help.

BTW In most cases I expect that these failures will be related to the people and more importantly communications. As Jerry Weinberg says "Its always a people problem".

Update: There has been some confusion: Its not that I think that an Agile or Scrum project can fail - but the people can fail to execute the methodologies well. Perhaps they don't listen when the team raises issues, perhaps team members don't want cooperate - "Its always a people problem". Yet when we are caught up in the thick of things we often don't see the early warning signs or recognize the fact that all these small problems point to something much bigger. In my mind the stories are a useful way to remind us of how things can go wrong and what it looks like when they do. As format there is none. Write your story any way that you and post wherever you want - your blog, the scrum community wiki etc.

Articles on Failure

Don't worry I'm not about to turn this into a link blog. I stumbled across these articles while looking for more Scrum Smells.

How to Fail with Agile (the link isn't date specific and will probably rot by Septmember) - by Clinton Keith and Mike Cohn. They cover four classes of issues (20 in all) that might cause problems:

1. Management - Don't trust the team or agile. Micromanage both your team members and the process...
2. Team - Continually fail to deliver what you committed to deliver during iteration planning...
3. Product Owner - Don't pay attention to the progress of each iteration and objectively evaluate the value of that progress...
4. Process - Drop and customize important agile practices before fully understanding them...

11 Ways Agile Adoptions Fail by Jean Tabaka covers items like: Ineffective use of the retrospective, Product Owner is Consistently Unavailable or There are Too Many Owners Who Disagree and Teams Lacking Authority and Decision-Making Ability.

10 ways to screw up with Scrum and XP by Henrik Kniberg (author of Scrum and XP from the trenches): Team is pressured, Technical Debt ...

Next post will contain some more original content.

If you enjoyed this post, subscribe now to get free updates.