Agile Methodology Understanding Agile Methodology

If you were at Agile 2009 in Chicago last year, then you already know that this conference is a great way to meet other agile practitioners, hear presentations from the industryÂ’s most respected thought leaders, and learn about all the training and tooling options out there. And one more thing: ItÂ’s a lot of fun!

Well, now itÂ’s time to begin looking forward to next yearÂ’s event. The 2010 Agile Alliance-sponsored conference will be held in Nashville, Tennessee at the Gaylord Opryland Resort, August 9 to 13. Jim Newkirk is serving as chair and leading the charge to organize this memorable conference. If youÂ’d like to be a presenter this year, the call for submissions opens on Monday, January 4, 2010. Check the Agile Alliance for more information.

Posted under Agile 20XX, Uncategorized

Over at InfoQ, Deborah Hartmann Preuss reports on the values of games for teaching the principles of Scrum. If youÂ’ve ever attended a Certified ScrumMaster or Product Owner course, chances are your instructor led the group to a deeper understanding of Scrum and agile principles by playing a game or utilizing an interactive exercise. ItÂ’s an effective strategy for communicating difficult-to-grasp ideas in a fun and memorable way and itÂ’s becoming increasingly common for agile education.

IÂ’ve played a number of games over the course of my agile and Scrum education. If youÂ’re responsible for teaching your team or others in your organization, here are a few helpful links thatÂ’ll give you some proof that games are, in fact, valuable and will provide a few ideas for games to try.

HereÂ’s CST Kane Mar on the Ball Point Game, which he learned from Boris Gloger: http://blogs.danube.com/scrum-trainers-gathering-24-the-ball-point-game

And hereÂ’s Katie Playfair of Danube Technologies arguing for the relevance of game-playing: http://blogs.danube.com/the-value-of-games-ingraining-the-intangible-in-an-audience

Posted under Uncategorized

Mike Bria recently posted a story on InfoQ discussing how a group of agilistas are arguing for the creation of a new role within agile and Scrum teams called the “agile team lead,” designed to effectively replace the ScrumMaster and Project Manager positions. For purists, it’s hard not to be skeptical, especially considering the delicate balance of authority and responsibility that marks the composition of Scrum teams. But for the sake of entertaining the idea, the following criteria summarize the group’s ideas about the duties that agile team leadership entails:

• “Continuous Leadership
  Understanding the team’s place in the organization’s goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a “safe container” for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion.
• “Continuous Planning
  Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain “big and visible”, manages metrics, making “the plan the bad guy” (as opposed to the people), and ensuring the “plan changes with demand/supply”.
• “Continuous Execution
  “Monitoring/managing team velocity/throughput”, securing resources, removing and escalating blockages. Ultimately, “keeping flow, momentum and focus in the team”.
• “Continuous Risk Reduction
  Identifying risks and making their “potential impacts big and visible to the right people”, ensuring risk reduction occurs, and quantifying risk management effectiveness.
• “Continuous Improvement (Agile Coaching)
  Driving the “improvement of the overall Definition of Done”, sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.”

Though several Scrum and agile practitioners have supported this idea, my favorite response belongs to CST Tobias Mayer, who states: “Creating a ‘role’ of team lead is the beginning of a slippery slope back to command and control, It is a cop-out, an excuse for not facing the real challenge of nurturing a leader-full team.”

I can’t help but agree. This role not only seems to disrupt the balance of power in Scrum and agile, but seems to be moving backwards—toward traditional management practices. I’m curious to know what you think. Would an agile team lead role solve problems at your organization or just create more? Let me know what you think in the comments.

Posted under Uncategorized

As I’ve discussed here before, Lean manufacturing, typified by Toyota and Honda’s production system of the 1980s, was one of the most influential precursors to agile development practices. Specifically, Lean’s emphasis on ongoing evaluation of the team’s performance, constant pursuit of process improvement, and continued waste elimination can be directly observed in agile’s tenets of incremental and iterative inspection and adaptation. Tony Baer, an analyst who covers agile, discussed how Lean has become a hot topic of discussion of late among the agile community. According to Baer’s post, this debate boils down to two arguments: “First is the contention that value stream analysis will add unnecessary bottlenecks, and second is that software development is a special case to which manufacturing metaphors do not apply.”

Baer’s take on these issues tends to align with my own thinking. Firstly, he acknowledges that it does seem a little contradictory for a development methodology that privileges a reactive approach to emerging conditions to place such an emphasis on value stream analysis. However, he still acknowledges the value of this kind of analysis. In the case of the latter argument, Baer cites a concern among developers that software development is categorically different from any other kind of construction or development process that occurs in the real world. Certainly, such criticisms are correct: Software development is not governed by a stable set of physical properties like, say, bridge building is. However, Lean’s values—as described above—are all applicable to project management, regardless of what is being produced. After all, Lean is essentially a philosophical approach, in which teams and organizations commit to continuous improvement—by reflecting on processes and taking whatever steps necessary to improve them.

Posted under Uncategorized

Even those individuals who have years of experience developing in a Scrum environment might be intimidated by the prospect of serving as a teams’s ScrumMaster. The breadth of what a ScrumMaster is asked to do for a team is very expansive—it can range from reminding a team to more closely follow the tenets of Scrum to more hands-on resolution, like replacing a fried CPU. Given how divergent the challenges a ScrumMaster face, it’s helpful to have a guide from an experienced ScrumMaster to make sure the basics are being covered. Below, I’ve included links to two very good guides that will certainly be helpful to any new ScrumMaster.

First off, check out Tirthankar Barari’s “Tips for First-time ScrumMasters” on the Scrum Alliance website.

Secondly, take a look at Certified Scrum Trainer Michael James’ blog, “A ScrumMaster’s Checklist.”

Posted under Uncategorized

Craig Larman and Bas Vodde have published a list of the top ten impediments organizations face when attempting to adopt agile management methods, based on a survey of agile experts at very large companies. Now, I know most of us donÂ’t like to be reminded about what weÂ’re doing wrong, but, frankly, thatÂ’s exactly why IÂ’d recommend taking a look at this. You might recognize some of these anti-patterns. In fact, some may be much too close to the bone. Of course, being aware of the anti-patterns we perpetuate in an agile environment is the first step toward eliminating them.

I wonÂ’t spoil the countdown for you, but I will speak to a pair of impediments that the authors mention that were not reported by the survey respondents:

1. “A culture of individual workers rather than real teams and teamwork;” and
2. “The gap between people in management roles and those doing the hands-on work.”

Both of these impediments boil down to an issue of “culture,” which I would argue is the single biggest obstacle preventing teams from successfully implementing agile practices. Why? Quite simply, if a team is unprepared for or unwilling to acknowledge the fact that agile is significantly different from traditional management paradigms, then it will continue to operate according to the status quo. For change to truly stick at an organization, all of its employees—from management to “those doing the hands-on work”—must understand the magnitude of the adoption and revise their working methods accordingly. When a culture embraces the changes precipitated by an agile adoption, those values can quickly move throughout an organization and allow process improvements to take place. But if the culture obstinately clings to old, familiar ways of working, there’s little chance of it evolving.

Posted under Agile Methodology, Uncategorized

Over at CIO.com, Paul Krill reports on an IBM-hosted agile workshop that took place recently in San Mateo, Calif. , where various thought leaders discussed the benefits and challenges of agile transformations. Although most of the information would be familiar to most agile users (or even readers of this blog), itÂ’s still a solid introduction to the concepts at stake in agile development. And though it sounds like everyone in attendance was convinced that agile development is a key strategy toward realizing a range of benefits, itÂ’s interesting to note that much of the discussion seemed to remain focused on organizational resistance to change. That is, no matter how exhaustive the list of potential gains the Scrum framework stands to deliver to an organization, there are always individuals within it who oppose change on principle.

HereÂ’s a pair of quotes from the article that illustrate that phenomenon:

Rich Mironov: “I haven’t seen [anybody] go through a transformation where everybody came out the other side happy. You’ll lose some folks because it’s not a style fit or they weren’t very good and you may not fit with agile. Expect some fallout or some people who need to move to the part of the organization that’s not going this way.”

Ryan Grisso: “My experience with agile is there’s a lot of resistance to it because it’s not the way we’ve done things before.”

As you can see, organizational resistance is a widespread impediment to almost all agile transformations. It occurs on the team-level, as individuals often refuse to try new ways of working, often assuming that the change somehow jeopardizes their standing in the company. Likewise, there is also resistance from managers who often fail to see it as an investment for the future, but, instead, an imminent headache.

If youÂ’ve lived through an agile transformation, IÂ’d love to hear about your experience. Were team members wary of change? What about managers? And what strategies did you see employed to combat this resistance to try agile? Did they work?

Posted under Uncategorized