Category Archives: xtreme programming

The Agile Dictionary: E is for Extreme Programming

This is a sneak preview of an entry from Agile Learning Labs' newest publishing project, The Agile Dictionary.  Our mission: to craft succinct, state-of-practice definitions for common Agile terms, complete with origins and links to the most authoritative primary sources we can find for further information. We plan to beta test the definitions here on our blog, prior to publishing The Agile Dictionary 1.0 in print and online.

Many thanks to volunteers Angeline Tan and Tami Blake for their hard work as contributing editors, and to Jeff McKenna, who has bravely volunteered to serve as our first editorial advisor.
Read the full article…

Share it!

This week on InfoQ – Information radiators: Is low-tech really better?

Information Radiator In this week's InfoQ article, Chris covers the debate over high tech vs.low tech toolsets (what Alistair Cockburn refers to as information radiators) for managing agile projects: eg, which is the lesser evil, killing a tree and taping its carcass to the wall one notecard at a time, or clicking through an annoying heirarchical menu every time you want to see your data?

The focus of the article is a discussion thread on the Xtreme Programming Yahoo Group, where topic is being contested with a great deal of heat.

There is a natural tendency among technologists to prefer technological solutions, but many of the debaters claim that experience has shown the low tech solutions to be best. Ron Jeffries says:

Display important project information not in some formal way, not on
the web, not in PowerPoint, but in charts on the wall that no one can
miss….A web site doesn't push information at us; we have to go look.
A slide show always comes with a meeting and a lecture. A wall chart is
there when we are, in our face, always visible.

This makes intuitive sense to me. I think there's something important about making the whole visible at a glance. Imagine how hard it would be to read a novel if there were one word printed per page–we read words in context, not in isolation. I think we experience projects much the same way, and it's important to always have a view of the gestalt.

The Agile Tools blog has an archival post that features pictures of several examples (as pictured) of both virtual and physical task boards. It's interesting to look at them and see which ones make you want to be on that project.

Share it!

What exactly is agile design? Or better yet, what could it be?

Chris just published an article on InfoQ called Refactoring is Not A Substitute for Design about the debate over what role design plays in agile development. The worry is that agile processes shortchange the very principles of good design, because so much of agile happens at the granular level while design is seen as a macro-level activity. But is that the case? Here is the bit that I consider Chris' main point: Big Design Up Front is not design; it is just one way to accomplish design.

Agile practitioners tend to prefer a different approach, in which the current design emerges in response to the actual functionality being supported. The design reacts and adapts to the needs of the system, which itself is constantly evolving and adapting to the needs of the customers.

Chris addresses a common misconception, that foregoing up front design in favor of an agile process is tantamount to no design at all. Yes, yes, agile is anarchistic, the sky is falling, and kids these days listen to the darnedest music, we know, we know.

It strikes me that this type of sea-change has all happened before:

When the first impressionist painters broke the rules by dispensing with classical rendering and embracing naturalistic forms and gestures, a great many people refused to call it "art." But in hindsight, we now recognize the equal level of artistry involved in making art that departed from classical norms. Just because Van Gogh didn't block and draw on the canvas with charcoal before he took up his palette knife didn't mean he lacked an eye for shape, perspective and line: in fact, art students now are taught that "You must know the rules by heart in order to break them."  The expectation now is that artists will be able to break the rules, and thus they are now expected to know these things at the cellular level.

I predict that we'll look back on this change in our attitudes toward design and software in much the same way–we'll think of the curious olden days when developers were seen as code monkeys wrenching on software that someone else designed. By engaging developers in all aspects of coding, and including design and test, agile actually seeks to elevate design and function to a higher level of importance, to where it's part of everyday practice for everyone who writes code.

Share it!

Story-Focused Standups

A widely accepted agile practice is the daily standup meeting, in which each team member shares:

  • What they have done since the previous standup
  • What they expect to achieve by the next
  • Anything that is getting in their way

Mike Cohn recently examined variations that shed additional light on the progress being made toward completing each user story. I wrote about it for InfoQ, and you can find the story here.



Share it!

The Great Agile Spec Showdown!

Agile evangelists claim that extensive written requirements and specifications can be dispensed with in favor of lighter-weight ‘stories’. It sounds easier, certainly, but can it really be as good? Won’t all of the important details get lost? Join the Engineering Managers Support Group as we stage a participatory showdown between traditional and agile specs. May the best specs win! Of course, we will also feature our usual round-table discussion of your pressing engineering and leadership issues.

This month, our new host is ILOG, makers of market leading business rules management systems. They are providing us with meeting space and pizza!

We also are proud to announce that JetBrains, makers of IntelliJ, ReSharper, and TeamCity will be raffling off a copy of any one of these products.

6:30 – 7:00
Networking and food

7:00 – 8:00
The Great Spec Showdown

8:00 – 9:00
Round-table discussion of your engineering management issues
Bring your questions and get ideas and feedback from your fellow engineering managers.

Our Sponsors:
The Technical Management Institute

Get all the details here.



Share it!

What Makes Distributed Agile Teams Succeed – At Agile2008

Greetings from Agile2008 in Toronto!

To say that I have been overwhelmed by the conference would be an understatement. With 1600+ agile folks here, I am constantly running into old friends, people that I met at previous conferences, and my agile heros. The sheer volume of knowledge and expertise that is being shared is beyond my ability to describe. Wow!

Tuesday, I facilitated a session titled:
What Makes Distributed Agile Teams Succeed (or Fail)?

The session drew about 15 people, almost all who have significant experience on distributed agile teams. As was the case at Agile Coach Camp, the level of experience in the room led to some rich discussions. In 90 minutes, we generated and ranked 25 success/failure factors for distributed agile teams. We used the Group Wisdom Without Groupthink process, which was fitting, as the keynote speaker at the conference was James Surowiecki, author of The Wisdom of Crowds.

Here is the ranked list of success factors for a distributed agile team, as determined by the group.

Tier One – The definition of “done”
This was brought up as the number one thing that derailed projects, or kept them on track. Having a well-defined, well-understood, and well-enforced definition of what it means to be ‘done’ with a story, can keep a team from getting mired in unexpected work near the end of the development cycle, and prevent the accumulation of technical debt.

Tier Two
Demos early and often
Onsite training
Executable requirements
Pride, ownership, and initiative from team members

Tier Three
Avoid “West vs. The Rest”
Daily standups – Doing whatever is needed to make them work for the team
Remote pair programming
Design for Conway’s Law
Everyone is present at iteration planning

Tier Four
Cultural training, including on your own culture
Determination to be remotely visible
Team task selection, just in time instead of ‘assigned’ at beginning of sprint
Video conferencing
Mixed experience levels on all teams
Awareness of cultural norms
(Hmmm, perhaps this and cultural training could have been combined. Perhaps they could have even been grouped with ‘West vs. Rest’)

Tier Five
Avoid time-zone blocks
(e.g. the Pune team can’t move forward because they need something from the Chicago team)
Some co-location, especially at the beginning of a project
Have the right team (hire people who will fit into the distributed environment)
Time-boxed stand-ups
Attention to iteration length
Daily, time-boxed design discussions
Don’t pretend the distance isn’t there
Give the ‘remote’ end of the conference call priotity in all discussions
(The idea is to pause all ‘local’ conversation whenever the folks on the conference call speak. It sounds simple, but it can have a powerful effect on how included they feel)
The “Buddy Concept”, each person has a remote ‘buddy’

You may find it interesting to compare these results with those for groups who have considered the question: “What makes agile teams succeed (or fail)?”
Dr. Dobb’s Architecture and Design World
Agile Coach Camp
The 2008 Chicago Scrum Gathering
P-Camp, a gather of Agile Product Managers
Silicon Valley Code Camp 2007
Agile Open California 2007



Share it!

What Makes Agile Projects Succeed at Dr. Dobb’s

Monday evening more that 40 people turned up at a ‘Birds of a Feather’ gathering to consider “What makes agile projects succeed (or Fail)?” as part of Dr. Dobb’s Architecture and Design World in Chicago. In 90 minutes the group generated, discussed, and ranked about 40 different answers to this question, while enjoying some pizza and beverages.

Below, I’m listing all of the ideas as ranked by the group. I’ll elaborate on a few of the ideas that the group focused on. I’ll also provide links to the results from other groups who have considered the same question.

Tier One
* Discipline and leadership
A successful team will take a disciplined approach to implementing agile practices. The group felt that a key to this actually happening was the presence of leadership.

* Good communication
The group felt that this was vital to the success of any project, and that agile methods fostered better communication. Even so, a key differentiator between agile projects that succeeded and those that didn’t, was how easily and honestly information flowed between people on the project.

* The right people
There was a fair amount of discussion about what ‘right’ meant. Ultimately, the group felt that it includes: technical skills, communication skills, interest in doing agile, motivation, and ‘fit’. After the workshop I noticed that there is overlap with the item ‘Team-oriented team members’. If these items had been combined, this would certainly have been the top item.

Tier Two
* Stakeholder buy-in
* Team-oriented team members
* Dedicated resources

Tier Three
* Experienced agile champion on the team
The group talked about the advantages of having an experienced agile practitioner on the team full-time, as well as available to do evangelizing and coaching within the organization.

* Customer participation
* Test Driven Development
* Lack of design (-)
* The right tools
* Good use cases
* Good relationship with customer
* Rapid Prototyping
* Small team size
* Vertical stories

Tier Four
* Planning for refactoring
* Small project size
* Requirements-based testing
* Not needing lots of documentation
* Realizing that agile is no silver bullet
* Open work environment
* Adaptable requirement
* Inexperience (-)
* Data planning
* Flexible customer
* Know your data
* Flexible project size
* Compact stories
* Good product owner
* Appropriate contract

Tier Five
* Avoiding schedule slip-n-slide
* Story completion
* Good interface between agile team and rest of organization
* Short timeline
* Agile stakeholder experience
* Excessive changing requirements (-)
* Embedded architect on the team

You may also be interested in seeing the results from groups that have considered (essentially) the same question:
P-Camp 2008
Code Camp 2007
Agile Open California 2007



Share it!

The Power of Self-Organizing Teams


A lot of attention has been focused on the power of self-organizing agile teams. This power is the foundation upon which Scrum, the most widely adopted agile methodology, is built. Is it hype or is there something there? This month, the Bay Area Engineering Managers Suport Group will experience how a group can self-organize into a team, and how such a team can evolve ever-better ways of working together. Come out and join the fun, now in Santa Clara.

6:30 – 7:00
Networking and food
Judy and Angie will be greeting people. If you need assistance finding us you can call them at 408.733.2374.

7:00 – 8:00
The Power of a Self-Organizing Team

8:00 – 9:00
Round-table discussion of your engineering management issues
Bring your questions and get ideas and feedback from your fellow engineering managers.

Our Sponsors:
The Technical Management Institute
Albin Engineering Services

Get all the details here.



Share it!