Why Agile?

Source: Tim Ottinger, Jeff Langr
Font: Erwin

We've talked about what agile development is, how to do it, and why people object to it, but the big question that remains is "Why Go Agile At All?" If you or your employer are considering a conversion to agile, you should know what to expect from the change.

Agile is a work system, not just a style of writing code or a set of tracking tools. It is a very disciplined and orderly way to work, and it is also a lot of fun. It is intense, requiring a high degree of personal involvement (which is why Agile teams cap their work weeks at roughly 40 hours).

• Improve Customer Involvement
Agile methods put the customer in the drivers' seat. Customers choose which bit of functionality comes next, and when a feature is complete enough for their needs. Agile is intentionally customer-intimate, so customers and developers (including testers, tech writing, and customers) are on the same team. It is a strong alternative to an adversarial relationship
• Increase Quality
Agile depends heavily on testing, both at the acceptance test level and at the unit test level. Tests are written constantly and run constantly. The legacy code you have lying about in piles may not be amenable to testing, so expect some early delays as the team converts it. These delays are more than offset by the lack of bugs (and days lost to bug-finding research) a few months down the road. Improved quality results in fewer customer complaints, reducing support costs.
• Simplify Releases
Agile teams release early and often, and try to maintain their code base in a perpetually-releasable state. Tests and Continuous Integration ensure you don't have long dark times when the code does not run. Periodic integration hell and mad release rush are reduced, even eliminated.
• Increase Operational Awareness
Agile teams keep their work-in-progress to a minimum, and track their progress on visible charts and the kanban wall. One can walk into the group work area and tell what tasks are in progress and how close they are to being completed. You can glance at a burn-down or burn-up and tell how close the team is to completing some critical functionality. It is an orderly and visible work system.
• Drive Down Risk
  Agile teams work in tiny increments of functionality, not huge end-all features. This allows them to have working software ready early on. They do not necessarily produce software faster than non-agile shops, but it is in a usable state earlier. This means that the software can be used while it is being developed. It might even pay for itself.
Because software is usable so soon, features are assessed sooner. The Customer can see immediately if they are really as useful as he expected. Corrective steering is possible. There is a greatly reduced risk of building the wrong thing, or a gold-plated excess of the right thing.
• Reconnect With Geek Joy
Boy, did I ever detest sitting through all-day meetings debating use cases or refining requirements documents in the name of JAD or RAD or RUP or whatever. Agile focuses on getting things done well and often, which according to studies is the primary factor that drives job satisfaction. Having working code nearly at all times is empowering. Having tests to rely upon is comforting. Having steady progress is refreshing. It is great to be making real progress (learning and coding) all of the time. It's why many of us chose this vocation.

The most common reason does not appear on the list above, "What we were doing was not working." That is a reason to change from what you were doing, but not necessarily a reason to change to anything in particular. If you are considering a change, consider whether you want the qualities listed here enough to give Scrum and/or XP a shot.

The Only Agile Tools You'll Ever Need

Source: Tim Ottinger and Jeff Langr
Font: BrownBagLunch

Perhaps you were expecting a list of software products?

Agile's raison_d'être stems from backlash against "heavyweight" methodologies that insisted upon voluminous documentation, never-ending and never-useful meetings, and vendor-lovin' high end tools. Yet in 2010, there are at least three major high-price, high-profile agile project management tools and dozens of lower-end ones.

We contend that using one of these expensive software tools says, "you don't get it, and maybe shouldn't bother, because agile may not work well for you." No doubt this will perturb those of you who have found some value in agile management tools, so let's step back and talk through the issues.

Agile is primarily about team communication and collaboration. It is predicated on continual face-to-face interaction. Every step in the opposite direction decreases the chance of success. Kent Beck had it right: The best opportunity for success, still, is having all project members sit in a single room and work as a team, instead letting a bunch of self-interested individuals retreat to the isolated comfort of their cube.

There is no room in agile development for "avoidance technology." If you can't find a way to meet its demand for close-contact, continuous communication, then you are not ready. If you don't want your programmers sitting together, talking through problems, writing code socially, then try something else.  Attempting to bolt avoidance technology onto agile methods is like castrating a stud horse.

Once you diminish teamwork,  you have to compromise other agile principles. If we're not in the same room, we need more meetings to talk to one another. We need to write more things down and produce more centrally-stored documentation. We need to have more contractually-oriented agreements between people who really work on the same team, because we can't trust one another, because we're can't see each other face-to-face every day. The agile practices topple like dominoes.

There is always questionable rationale about why things must be that way. "Every project has to be split evenly between low-cost [read: offshore] labor and high-cost [local] labor." That's not a definition of project success, just a broad-brush attempt at cost control. Having some remote team members should never force all team members to work as if they were remote.

Perhaps the executives could use their hard-won corporate smarts to organize the teams differently. "Half our projects must be low-cost" should appease the bean-counters, and could just work. Here come the excuses: "But we don't have business experts who can act as customers in Bangalore." Really, that's a problem you can't solve? Having two truly agile teams producing quality code should be better than having two teams pretending to be, and failing at, agile.

If you want to succeed at agile, find a way to put each team in its own room. Give them the tools we list on the card, and they'll rarely ask for more. We guarantee they won't ask for a high-end agile tool, because they don't need one and don't want to be bothered with one. Executives of various stripes might ask for one, but all they really want is a simple way to view and present status across significant numbers of projects. You don't need a high-end, specialized, complex tool to do that, and you definitely don't need to waste the time of everyone across every agile team to do that (hint: see Tracker and Coordinator on Agile Roles card. This is what you pay project managers to do).

Agile Roles

Some of you might be surprised that there are no farm animals on this card. We'll talk about that later.

You'll also note that each role definition is preceded with the word "helps." Everyone on an agile team can act as any role at any given time, helping the team toward its ultimate goal of producing quality product.

In agile, roles are just that, roles. We don't look to protect our role from being usurped. While we are most comfortable playing in our primary role, we have no qualms about stepping into other roles as needed or appropriate. A tester might act as a tracker to gather useful team metrics; a programmer might assist the customer and testers in defining acceptance criteria for a story; a manager might help execute any remaining manual acceptance tests; and so on.

Extreme Programming (XP) originally designated two roles, programmer and customer (for whom XP described little--it is extreme programming after all). Each camp had specific rights, to protect each camp's interests against likely infringements by the other. A bit divisive? Indeed. You will be hard-pressed to find much remaining literature that mentions "XP Rights."

Within the programmer camp, XP eschewed specialists and hierarchies, fostering instead experts and team collaboration. But things other than programming and steering as a customer still needed to be done. Various adjunct needs, such as coaching and tracking, emerged. Who would do these things? These part-time needs were fulfilled by XP team members (customers or programmers) shifting in and out of secondary roles.

Proponents of Scrum (which predates XP a bit) were never so trusting in a teams' ability to self-manage, so they introduced the Scrum master, whose job is to keep the team on track. As for XP, the reality of human behavior brought its lofty goals down a peg, more so as Agile took off. Organizational interests and self-preservation took over. The concept of a self-organizing, title-ignoring team threatened HR, project managers, managers,  and others who had vested interests in promoting and maintaining specific titles. In an attempt to keep us from falling back into isolationist and divisive behavior, Kent Beck began referring to the collection of all team members as "the whole team," instead of discussing specific roles.

Today, the agile organization doesn't usually look terribly different than the pre-agile organization, except within some programming teams. You'll still hear long-standing, specific names for specific customer roles, such as "business analyst," "product manager," "UI design specialist," "subject matter expert (SME)," and "stakeholder." But on the programming side of the fence, a team working within an open workspace and pairing usually has lost any real concern over titles and artificial divisions such as "front end programmer vs. back-end programmer."  Since these roles are temporary, it is futile and undesirable to to tie hierarchical positions or increased benefits to them.

It is best for us to concentrate more on putting out quality product, and least on relative positions. We understand that it may not be realistic in your organization to shed your title, but you should still consider the ego-less organization a general direction to move toward. Sometimes simply thinking that there are no titles can help you find an answer to your problems.

Astute readers will note that "manager," "project manager," and "Scrum Master" do not appear on this list. We have instead substituted "team coordinator," someone who buffers the day-to-day development team from outside interference and distraction. A team coordinator can communicate scheduling issues,  handle incoming requests, and smooth interpersonal problems. Within Scrum, this team coordinator also takes on the responsibility of enforcing the rules, something that a team is certainly capable of doing on their own. We suggest that the best Scrum Masters plan their own obsolescence: Their primary job should be to help us mature to the point where the team no longer needs a Scrum Master.

The lack of official leaders and managers in agile is off-putting to some. We've noted that most software teams do not suffer from a shortage of management, but a drastic overage as different departments try to exert control over the isolated "programmers" and "testers."  In an agile team we come together as a team, and the work has us busy enough that little traditional management is necessary.

As far as the chicken and pig roles that some of you might have expected to see on this card: Everyone we've met on a well-functioning agile team has been unsurprisingly human. We don't believe people who might have something important to say should be stifled. If someone says inappropriate things at inappropriate times, we muster the courage to ask them to take it elsewhere. "Chicken" was deliberately chosen as a derisive moniker, the spirit of which has no place on a real team. (We quote Jeff Sutherland here, because his original blog post has been archived and may soon rightfully be buried entirely: "People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk. They are excess overhead for the meeting. ... Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others. Sorry to be political [sic] incorrect but others should come up with a euphemism that conveys the right balance between being "nice" and communicating clearly that eavesdroppers must minimize their impact on the productivity of the team."  Perhaps the goal is laudable, but the sentiment is so wrong as to be repulsive.)