It has
been six years since the authoring of the Agile Manifesto, and the technology
and tooling landscape has changed since then. This conversation between Ron Jeffries
and Ryan Martens debates the merits
and weaknesses of tooling Agile.
Ryan:
Ron, I'm
very proud of the planning and tracking tool that my company builds and
markets, and there's something I've been wondering. You're always pushing for
simple tools like cards and paper charts. Do you have something against tools?
Are you still coding in binary out there in Michigan?
Ron:
Well, Ryan, I do trust some tools ... and not others.
As one of the authors of the
Agile Manifesto, I do value individuals and their interactions more than I
value their processes and tools. The right individuals, interacting well, will
find or create whatever processes and tools will serve them best. The best
processes and tools, on the other hand, can't bring effectiveness to the wrong
individuals, interacting poorly.
In development tools, I would favor having the strongest and best you can get.
Today those might include Eclipse and Java, or C# and Visual Studio.
Advertisement
Or perhaps
Ruby on Rails. There are lots of excellent platforms for development, and any
team should use the best one they can get.
Agile projects are inherently iterative, and therefore the design evolves over
time. To do that well requires refactoring, and it's therefore valuable to have
the strongest refactoring tools possible. I might even favor a development
platform a bit more if it had better refactoring. To support refactoring and
make it safe, we need tests. Almost every platform we might use has its own
JUnit or NUnit or xUnit, and I consider that tool to be on the mandatory list.
Most of the above are individual developer tools. There are also development
tools that support team interactions, and I'd favor using some of those as well.
I'd like to see a good code manager, supporting frequent check-ins and making it
easy to keep all the developers' code synched up. I'd like to see a solid
automated build system to keep the code integrated all the time.
Ryan:
I like to think of development tools as the "go fast" tools. By keeping the
cost of iterating down, the business and technical teams are not forced into a
typical mode of trying to get things right up front. In contrast, teams that
employ "go fast" tools can work in small, maybe even parallel, chunks to find
the simplest design to do first.
For me, the critical signaling for these technical teams is to have the
visibility to "stop-the-line" when there is a problem that is urgent, like a
broken build or customer-facing defect. The team has to be presented with these
signals in a way that forces them to stop and keep from building on a house of
cards. This type of signaling is a fine art; it needs to be big and bold, yet
not generate too many notices that people will ignore it. I like physical lava
lamps, orbs, but I also like them combined with virtual counterparts too. Teams
that practice "stop-the-line" discipline clearly illustrate that they get the
notion of flow and iterating on small increments quickly.
Beyond technical tools, the business needs to have simple and effective tools in
place for soliciting, engaging, and managing feedback from stakeholders on these
rapid designs, increments, alternatives and market dynamics.
We know from the simple physics of Agile and Agile tooling surveys that
customers want tools to help them adopt and mature their Agile disciplines.[i]
They want help working in small batches, bringing testing forward, getting clear
visibility, and reducing wasteful inventories to enable a smooth flow of value.
This is the genesis of Agile Project Management (APM) or Agile Application
Lifecycle Management (AALM) solutions.
Ron:
As we move beyond technical practices into the more team-oriented aspects of
software development, my concerns about tools generally increase. In particular,
new Agile teams commonly ask what time-tracking, task-tracking, or bug-tracking
tools are recommended. I generally respond with the suggestion that white
boards, cork boards, and cards are the best planning and tracking tools I know
of for within the team. The primary reason for this is that these tools are more
collaborative than the typical computer-based tools.
I have watched many teams plan or track their iterations using the available
tools. The process seems almost always to go like this:
Some person in the room, often the ScrumMaster or equivalent, brings the tool's
screen up on a projector. Then they go around the room one person at a time,
asking that person what they worked on, what they're going to do next, and so
on.
At base, this is a reporting process not a conversational process. As such, it
is a weak form of communication compared to, say, a discussion. The team is
taking turns being asked questions by some leader and answering them.
Compare this to a meeting around a table with cards on it, or around a white
board where anyone can grab the marker. A meeting like that becomes much more
dynamic, with the center of the meeting flowing around more freely as people
have things to contribute. It is less controlled and more interactive -- and
that's a good thing in my book when it comes to teamwork.
Ryan:
Since our early days, we have been following your lead and others' by teaching
teams to form co-located and dedicated teams to enable this type of
collaboration. You clearly articulate why there is no better tooling answer than
white boards and cards for individual teams and bottom-up team adoption of
Agile. However, white boards and cards are not enough to support Agile
development on larger programs, teams of teams, or distributed teams. In these
environments, people need tools and techniques to bring the benefits of Agile to
medium and large teams.
I find that multiple-team Agile starts when your team has more than 10 or 12
people. At that point, you need to break into multiple teams of seven people,
plus or minus two. However, once you create two Agile teams, the issues of
coordination, synchronization, prioritization, and commitment tracking across
teams start to increase. Scrum works to address this with Scrum of Scrum
meetings, but in my experience that meeting and release readiness needs to be
supported with some form of artifact management for distributing the backlog and
coordinating multi-project dependencies.
Here's where APM and AALM solutions make a big difference over earlier
predecessors. Waterfall processes and plan-driven approaches drove suites of
highly specialized tools for individuals and inventory/workflow tools for
groups. These first-generation tools were part of the problem -- they helped
reinforce the walls between roles and encouraged the management of large
inventories of requirements, bugs and enhancement requests that built up during
the process. Managing all this work-in-process was a huge waste on the delivery
process. It helped reinforce the high cost of change and the need to get things
"right" up-front.
With the guiding ideas from Agile and innovations in the collaborative
infrastructure of Web 2.0, the industry has spawned a new breed of tools. These
new tools leverage the messaging, signaling, and lightweight machine interfaces
that make coordinating and collaborating among distributed teams, roles, and
players easier. Today's tools don't need to do many of the things
first-generation tools did, including compile perfect documents, load-level
resources, and drive hand-off workflows. Although second-generation tools have
fewer features, they instead obsess on the usage, quality, and user enthusiasm
for each feature.
AALM tools are beginning to be integrated with "go faster" tools, but primarily
they help growing teams expand and help larger incumbent teams manage
synchronization. To enable this coordination, the iteration teams use these
tools to reflect status and enable roll-up of task, story, test, and defect
status. To reduce the collaboration burden on iteration teams, AALM tools work
to make it easy to round trip from white boards and cards to tool and back
again. These products serve a critical visibility role that is almost impossible
to achieve when you try to roll-up white boards.
Ron:
I do agree that larger teams need the kind of tools you describe. In addition,
there is always a need to communicate upward and outward, and those external
communications often need to be more fancy, better formatted, more "corporate."
However, even though in a sufficiently large situation I might well use such a
tool myself, I still don't feel comfortable recommending that an organization
start out by using such a tool. The reason is that I fear that they will never
get back down to putting their hands in the soil and working the garden. They
won't have the opportunity to develop the kind of intimate teamwork that is
possible, and as such they'll never really get the benefits that we spoke of
when we wrote about "individuals and interactions."
You begin to see the pattern, I hope. I think that people and how they interact
on a project are the most important thing, and I think that they need to create
a way of working -- a process -- that works best for them. Because their
interactions are critical to project success, I suggest that teams begin the
work with an approach that will bring them together as people, not one that will
let them remain apart, communicating electronically.
Ryan: I live by and teach your perspective. I know it to be the best way to adopt
Agile and run iteration teams. For me, the debate is around the value and
alignment of AALM tools for bringing the benefits of Agile to medium and large
teams.
Ron:
I'm with you on that. Agile-focused tools are far more appropriate than the
previous generation of tools. They understand the Agile cycle and support the
Agile ideas. While I would like everyone to start with cards, pens, and white
boards, many teams are going to wind up using tools. When they do that, they
should use the best tools out there, and today, those are the ones that are
focused on Agile.
About the Authors
Ron Jeffries was the on-site coach on the very first Extreme Programming
project, starting in 1996. He is the senior author of /Extreme Programming
Installed/, the second XP book after Beck's white one, the author of /Extreme
Programming Adventures in C#/, and the proprietor of
www.XProgramming.com, one of the longest-running and certainly the largest
one-person site on XP, comprising over 200 articles at this time. Ron is perhaps
the most prolific web author in the Agile software space, on news groups and
mailing lists. He is a frequent speaker and trainer at Agile software
development conferences, including attending and speaking all of those
conferences in the US and some of the ones in Europe. Ron is also one of the 17
original authors and signatories of the
Agile Manifesto.
Ron holds Masters degrees in Mathematics and Computer and Communication Science,
and he wrote his first computer program in FORTRAN for the IBM 704 at Strategic
Air Command Headquarters (Omaha) in 1961. He and his teams have produced
software products bringing in over a half a billion dollars in revenue, and he
wonders why he didn't get any of it.
Ryan Martens is founder and CTO of
Rally
Software and is an expert in assisting organizations transition from
traditional development processes to more Agile techniques. Before founding
Rally - his fourth software start-up - Ryan directed the corporate adoption of
Internet technologies within Qwest Communications, and then moved on to co-found
Avitek, a Boulder-based custom software development firm where he served as Vice
President of Marketing & Business Development. Ryan's successful efforts at
Avitek culminated in an acquisition by BEA Systems in 1999. At BEA, Ryan served
as Director of Product Management for the eCommerce applications division and he
was instrumental in growing that division to more than $50 million in revenue
within its first twelve months.
Ryan received his Masters in Business Administration and his Bachelors of
Science in Civil Engineering from the University of Colorado at Boulder. Ryan is
an alumnus of the Colorado Chapter of Young Entrepreneur's Organization (YEO).
Ryan is also involved in a variety of community boards including Colorado
Conservation Trust, Entrepreneurs' Foundation of Colorado and the Agile
Alliance.
[i] Agile Project Management Tooling Survey, Pete Behrens, Trail Ridge
Consulting, December 2006.
Comments (6)
bromeijn: ...
I think I am one of the people who cannoy see this agile thing working. When you have sufficient capable resources regular methodologies will work also. I use a Bug Tracking Tool and that means that I assign resources, follow up with them on progress etc. add additional info to the tool. That works. cards on the wall.....what if a card falls from the wall and the cleaning lady comes by? what if the handwriting sucks..... anyway I can say that I am still a person who has actually worked in projects with woaterfall, with all the ways of testing and had succes!! With this agile thing.... provide me with 10 large companies who were successfull and saved time and money
1
May 18, 2007
Ryan: ...
I think the big new addition from these comments is the note around multiple "tools" especially including a mix of electronic and paper. There is no question, physical "kanbans" of 3X5 cards is the best answer for project managing the collocated, agile component team. But the question still rests, what mix of tools is the best solution for you and your team?
Given the large amounts of ad-hoc substitutes and the relatively "young" (3 years) status of Agile Project Management tools, it is not surprising that we have not "sold" everyone yet. With evolution in web 2.0 technologies, increased adoption of agile methods on large scale teams, and the increasing need to share the real-time and accurate agile project management data with multiple stakeholders (customers, partners, dependent teams, the marketing/operations release team, support) the need for these products is increasing. The result of this visibility and transparency is a more agile enterprise. That is good for agile teams, but it will pull these rapidly advancing on-line tools into the process. Be sure we are working actively on all your objections. It is a great challenge, but it makes this space fun. Keep pushing us!
2
May 03, 2007
Paul Ellarby: ...
I think there might be one element we are forgetting in this debate - our customers. In the large organizations I consult with, the user community tends ot be mired in "the old way" - Gantt charts, timelines, spreadsheets, e-mail, and every other type of traditional project management tool you can imagine. Getting them to think in an Agile manner is hard enough without making them give-up their Gantt charts and task information (yes, in MS Project...) on day one!
I have had good success combining tools (spreadsheets, Version One software, and lately Microsoft's Team Foundation Server) with good old paper / whiteboard / index card technology, especially with distributed teams. At the start of every week, I make sure there is a large paper version of the backlog items being worked on in this iteration, and we use this for our stand-up meetings the following week, keeping the electronic records up-to-date as we go. And there are some things - test results, bug reporting, new features, even time reporting - that can only be reported electronically, due to distance (physical and time) constraints on our teams.
I guess I am trying to say this is not an "either / or" debate - there are some tools that are better in electronic form, and some that are better in manual form. The trick - no, the REQUIREMENT - is to choose the tools wisely, and focus on the process. After all, we espouse the "inspect and adapt" approach, don't we?
3
May 01, 2007
tottinge: ...
It's a tough game. Always there is someone waiting to automate a process or a step, and there are a number of other voices pointing out that automating seems to imply that we know what this thing is. There is a fear that the term "agile" will ultimately mean "whatever it is that these tools automate". Sometimes, the means become the ends. This is happening in agile practice. It's deucedly hard to automate "continually eliminate collateral effort" or "constantly go faster, more certainly, and with minimal ceremony".
And of course, content "on a web page somewhere" or "in an app" doesn't have the coercive immediacy of the same data staring you in the face whenever you walk into or out of your work area, especially when your daily workflow includes walking up to that board a few times a day.
Overall, I don't think that the rules will change with distributed teams. I think that "in a tool" and "on a webpage" will be insufficient. Immediacy is such a component of agile, I don't know that you will be able to substitute wikis and web pages and checkin comments for bullpens, corkboards, and cards.
If you make the move to all-electronic tools, you will have to create ceremony to cause the tools and sites to be visited with the same frequency and immediacy of the cork board, or you will not have the same result. It remains to be seen whether this is possible.
4
April 30, 2007
Mike S.: ...
I would also prefer to use cards, pens and whiteboards but how does that work for globally distributed teams?
5
April 18, 2007
Wayne M.: ...
I tend to agree with Ron that "Communications" tools often require much more effort than the manual equivalent and reduce the scope of the communications.
I have found the bug tracking tools diminish communications because the information gets hidden in the tool and the developers begin talking about bug #123. Once data is entered into the system, it is largely left to the development team to review and prioritize. The number of items in the database jsut tends to grow until someone makes a slash and burn decision and administratively closes a bunch based entirely on personal preferences. A growing stack of cards is an obvious problem signal and I can't imgaine a team with hundreds of 3x5 cards, but I have found it common to see databases with hundreds of change requests.
As for tracking information, I have found using tools, even rudimentary ones like Excel spreadsheets for Scrum burndowns to be time consuming and a source of duplicate data. People will either keep the paper copies up to date or the electronic copies up to date, but rarely both. It then creates just a lot of busy work for the manager to keep them in synch. For any one who desires real-time status, a simple walk by of the development team war room will provide it with far less effort than a manager continuously enter data into a tool.
Just because something could be put on a computer does not mean that it should.
It has
been six years since the authoring of the Agile Manifesto, and the technology
and tooling landscape has changed since then. This conversation between Ron Jeffries
and Ryan Martens debates the merits
and weaknesses of tooling Agile.
