LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Windows Phone 7 will not support HTML 5
Windows Phone 7 will not support HTML 5.
03/15/2010 05:51 PM EST

ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget

EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

Guest View: The half-agile path leads nowhere
While businesses are taking on agile and adopting its practices, an incomplete implementat...

Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Guest View: Fear and Embrace Tools For Agile Teams


By Ronica Roth
September 15, 2007 — 
“Tools are scary.” I heard that during a session on tools for Scrum teams at the May Scrum Gathering. The guy was referring to software tools for agile teams, and he explained that when he hears that a team, program or organization is looking for tools, he fears they will soon be abandoning agile practices.

Tools can be scary to agile developers. Not like monster scary—storming in loudly to drive developers back to their cube caves to generate huge design docs while destroying the focus on potentially shippable code. More like disease scary—an insidious cancer slowly replacing face-to-face communication just a little too often, turning focus away from working code just a little bit, tempting teams to gather one or two non-agile metrics.

Tools can also be, well, tools—helpers that foster communication, enable burning visibility throughout the organization, and enhance collaboration among team members and with customers.

What’s an agile team to do? Just three things:

1. Newly agile teams should avoid software tools at all costs.

2. Wait until you have a problem.

3. Choose tools designed to support agile principles and practices, then choose one barely sufficient to solve the problem.

New Teams Should Avoid Tools
Agile practices can feel awkward and unfamiliar. As individuals and as teams, we have habits about how we work that run counter to what agile principles recommend. For example, we may tend to avoid face-to-face conversations, preferring to stay safely within our cubes. Or we may keep progress reports vague, to avoid being held accountable for elements out of our control or for early, unfinished ideas for solutions.

Instead, team members need to develop new habits, like talking daily to the customer/product owner while implementing stories and reporting honest task updates in daily standups. When we make these changes together, as a team, we build the trust and habits that allow agile methods to succeed in improving planning and communication.

Meanwhile, building trust and habits is a part of the process of gelling as a new team with a newly expanded membership: Testers, tech writers, a product owner or customer and others now join the team of developers. That team has to go through some forming and storming on its way to norming and performing. Much of that work will happen in the interactions created by agile ceremonies: daily standup, planning sessions, story workshops, reviews, retrospectives.

In these early stages, software tools are likely to get in the way. If team members update status via a tool rather than talking to colleagues, the communication is less robust. Team members are also less likely to be diligent about tool updates, so it’s better to report via big, visible wall charts. Thus it becomes very visible when updates aren’t happening, until they become habit and the benefits become clear. Another example is using a tool during planning sessions. If the team is staring at a projected screen, then they aren’t paying attention to teammates to learn how they communicate nonverbally or how they estimate or decide priorities.

Also, agile is an umbrella term for many, many practices. Teams and organizations often take some time to determine which practices they will use, and how. Will the backlogs for the three teams building that one application be kept separately, or together? Will we estimate in points or days? What is our definition of done? What will we track and report at reviews in order to promote quality? How will we increase automated testing?

Tools can sometimes help teams answer these questions a little too quickly. A given tool might promote a certain direction, before the organization has really built its experience. Or, a tool might provide so much flexibility that the initial set-up is almost arbitrary. And then changing that set-up might be a pain, which reduces the organization’s options too soon for making agile work for them.

Wait Until You Have a Problem
Software people love software. It’s tempting to start using an app just because it’s cool. Or rationalizing the Big Solution to the little problem. My personal temptation is apps for my PDA. Like that time I bought a time-reporting app because I had a new gig as consultant (after years of being an employee). I thought it would make tracking my consulting time easier. Turned out, though, that relying on my Outlook calendar was plenty easy and provided all the detail I needed. I didn’t have a problem, but I spent hours installing and configuring the time app anyway, and then tried to devise a “process” for myself to make it useful. I inadvertently increased my pain.

A newly agile team or organization is making many changes to its processes, practices and interactions. Using retrospectives, agile teams and organizations approach process improvement using the agile principles of always delivering the highest value (prioritized backlog) and delivering incrementally. Thus, teams may develop a long backlog of potential improvements but choose to focus only on the one or two items that will bring the most value. Then, the team inspects the results before choosing the next most valuable improvements.

Based on that approach, the decision to use a tool should be the result of the inspect-and-adapt process. Only when a pain has risen to the top of the organization’s list of concerns should the group decide to seek a solution.

Barely Sufficient
Again, it is helpful to apply agile principles to the tool question. The simplicity principle of Extreme Programming leads to the practice of barely sufficient designs and architectures. By choosing a tool that is barely sufficient to solve the problem, you avoid adding unnecessary complexity into your process before you need it. You also avoid the overhead of over-designing the solution to your problem.

By choosing a tool built with agile development in mind, you also avoid introducing unexpected consequences. I find it fascinating—and sometimes cool and sometimes horrible—that software tools can encourage specific behavior, sometimes in ways we really don’t expect. For example, I adopted Gmail because I liked the more-responsive Web interface. However, that tool specifically promotes the saving of e-mails, by providing an “archive” function that is more prominent that the “delete” function and by providing robust search. I now manage e-mail differently.

Tools built with agile principles and practices in mind are more likely to encourage agile behavior. Here are some generic examples of problems and tool functionality based in agile:

• A product backlog management tool that makes it easy to rank (not just prioritize) stories, and that makes it easy to write lightweight user stories, and that makes it easy to break epics down into smaller stories.

• A test and defect tracking tool that helps teams tie story acceptance to testing.

• A project management tool that helps teams track iterations, monitoring task progress and story acceptance, and measuring team commitments and burndowns.

It takes diligence and dedication from the organization, program, team and individuals to reap the benefits of tools and keep the disease of non-agile practices out.

<em>Ronica Roth is an agile coach and consultant with Rally Software, which sells tools for agile software development.<em>


Share this link: http://www.sdtimes.com/link/31164
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading