• Home
• Articles
• Newswire
• Tools
• Training
• Resource Directory

Subscribe

Recent Posts

• Writing Great User Stories
• Measuring Business Value
• Pomodoro
• ScrumWorks Pro 4 and Epics
• Scrum Comes to South America in October

Categories

• Agile 20XX
• Agile Project Management
• Scrum
• Uncategorized

Links

• Agile ALM - Agile ALM
• Agile Development
• Agile Methodology
• Agile Programming
• Free Project Management Software
• Scrum Methodology

Podcasts

Writing Great User Stories

There’s an interesting article on the Scrum Alliance about writing good user stories, requirements and use cases. According to the writer, user stories are actually narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system. A true user story is a metaphor for the work being done. A good user story uses the “INVEST” model:
• Independent. Reduced dependencies = easier to plan.
• Negotiable. Details added via collaboration
• Valuable. Provides value to the customer.
• Estimable. Too big or too vague – not estimable.
• Small. Can be done in less than a week by the team.
• Testable. Good acceptance criteria.

The writer draws interesting comparisons between “traditional requirements”, “use cases” and “user stories” – and the benefits and pitfalls of each. Are user stories better than other types of requirements specifications? Well it depends. It’s essentially the team that determines whether a particular technique will work or fail. For most scrum teams, the intent of good user stories, however, is to help foster collaboration. If you already have a collaborative team environment and/or are looking to enhance it – read this article for learning more about techniques for writing good user stories.

Measuring Business Value

For stakeholders and managers, the single most appealing aspect about project management with Scrum is almost always the fact that all development efforts are driven by Business Value. That means that work is prioritized based on the amount of value it will generate for the organization. In an article called “Estimating Business Value,” InfoQ’s Chris Sims considers how teams can determine which user stories represent the highest Business Value. What ensues is a comprehensive discussion of how organizations do just that. Perhaps most interesting is Pascal Van Cauwenberghe’s assertion that Product Owners should not select user stories they believe to contain the most business value, but should first consider what generates business value and then work backwards to write the user story accordingly. He offers a step-by-step process to guide Product Owners through that process for the first time:

• “We first decide what values (or benefits) we want to achieve before launching a project or product
• “Then we find and improve the business processes that deliver that value
• “Then we find and improve the supporting business processes that make the value-delivering processes possible
• “When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.”

The article continues with additional approaches for teams to weigh, including suggestions from Brandon Carlson, Mike Cohn, James Shore, and Kelly Waters. It’s a valuable post for providing so many perspectives to this one problem. To their advice, I’d also recommend consulting Michael James’ whitepaper “An Agile Approach to ‘Metrics’: Applied Macromeasurements to Ensure On-time Delivery” and Dr. Dan Rawsthorne’s whitepaper “Monitoring Scrum Projects with AgileEVM and Earned Business Value (EBV) Metrics.”

ScrumWorks Pro 4 and Epics

If you work at a large organization where products are developed as constituent parts of over-arching programs, then you know how tricky it can be to track these “shared components.” Well, there’s good news: Danube just published ScrumWorks Pro 4 and its biggest new functionality addresses that very issue. More specifically, the latest release of ScrumWorks includes a feature called “epics” that allows organizations to manage the release of complex projects that include multiple components. This means that the days of brainstorming creative workarounds to achieve similar results are over. Now, users can apply “themes” (a tagging feature for quick searching and filtering) to identify all the PBIs within a given Epic. This gives developers a more intuitive approach to organizing work, while also providing Product Owners and stakeholders with a view of progress that cuts across multiple products. I think you’ll be surprised by how powerful this new feature is. You can watch a screencast here or read more about this release here.

Scrum Comes to South America in October

It seems that excitement over agile processes and engineering techniques has finally migrated southward. Well, not “finally.” Last fall, Buenos Aires played host to Ágiles 2008, the inaugural South American conference on all things agile. But last month, the official website for Ágiles 2009 went live. This year, the conference moves to Florianopolis, Brazil for four days of “agilidad” in October.

With retrospectives guru Diana Larsen and Agile Manifesto signatory Brian Marick slated to deliver the keynote presentations, it looks like a great program, whether for South American software developers or North American coders looking for an excuse to mix business with pleasure.

Check out the full program here.

Only You Can Prevent “Teamicide”

If the goal of implementing agile project management is to boost productivity and yield highly performing teams, then the last thing a manager or Product Owner should do in that environment is stand in the way. And yet, this article on InfoQ describes how managers—out of intimidation, confusion, or both—have a tendency to undermine their best teams. Authors Tom DeMarco and Tim Lister have dubbed this phenomenon “teamicide” and Steven Denning, who has been writing on high-performance teams for InfoQ of late, offers two common management attitudes that can kill a great team:

“Sometimes it’s murder—death by intent to kill: high-performance teams often achieve what they achieve by breaking the rules of the prevailing corporate culture. Managers can feel threatened and so they disband them, in order to preserve the status quo.”

“Sometimes it’s manslaughter—death by negligence: the management doesn’t understand the high-performance team or its mode of operation and so it does things that unintentionally eliminate high-performance, e.g. moving members of a high-performance team to other teams, ostensibly with the goal of creating more high performance teams but typically with the result of eliminating any high performance.”

Have any of you experienced the scenarios described above? I’d be curious to hear if many of you readers have experienced “teamicide” at your organization. And, lest we end on such a negative note, be sure to check out the end of the InfoQ article, which concludes with some great tips from Ominlab Media’s Stefan Gillard for finding individuals who will likely contribute to a high-performance team.

Agile Dogma

One of the biggest criticisms against Scrum and agile evangelists is that their all-or-nothing attitude undermines the very improvements Scrum and agile promise. Of course, those of us who do practice by-the-book Scrum and agile understand why it’s so important to hold fast to those principles and processes: because they’re the key to unlocking increased productivity, accelerated cycle time, and reduced overall costs. But in his article “Agile Development: Dogma Vs. Degree,” which recently appeared in the online edition of SD Times, David Rubinstein makes an important distinction that often gets lost in the midst of so much evangelist noise. He writes:

“On one side of the argument are those who believe that adopting any of the steps is a move toward agility; that the important thing is not adherence to the steps but instead an improvement in the organization’s software development.”

What I think is important in this quote is Rubinstein’s articulation that the end goal of adopting agile or Scrum is measurable improvement within the organization, not perfectly complying with every aspect of the methodology’s processes. Again, the “rules” of Scrum and agile are there for a reason: They give teams guiderails to lean on during the difficult process of wide-spread organizational change. But an organization does not win if it adopts every aspect of an agile method. They win when they realize change within the organization and begin to work in ways that lets them do things they never could before.

One note: I found it interesting that Rubinstein decided to interview a representative from every major agile tool vendor except the one that we use! In case you’ve missed it in previous posts, we use Danube’s ScrumWorks Pro to manage our projects and it’s really great—mostly for being so easy to use and aligned with the Scrum framework. If you’re using Scrum and find yourself in the market for a tool, you should definitely look into this one.

Agile 2009: Conference Program Announced!

If you haven’t seen it yet, the full conference program for Agile 2009 has been announced. You can take a look at what’s planned for those five days in August: http://agile2009.agilealliance.org/programOverview

Is Five the Magic Number?

Over at InfoQ, Vikas Hazrati has aggregated some interesting thoughts on the ideal size of a Scrum team. While Scrum literature advocates teams of seven plus or minus two, Hazrati’s evidence suggests that, in fact, it’s groups of five that perform the best.

Now, we already know that as the number of team members increases, the channels of communication go up exponentially. So it’s hardly surprising to hear that a team should not be larger than nine. But why five? Hazrati offers some interesting reasons.

According to a blog post on Cognitive Edge, five—and increments of five—play an unusual role in creating natural limits for human groupings. The author suggests that this phenomenon is directly linked to how the human brain has evolved in relation to social conditions.

So what’s the big deal with five? As the blogger points out, “five is linked to the natural limits on the short term memory.” That is, the number is applied to time, rather than objects or persons. Five minutes of instruction might lead a team to complete a task with astounding focus, but if the same team receives its direction stretched out over an hour, it’s unlikely that the team will respond in the same way. Likewise, activities that require five or fewer steps are easy to remember, but if they require more, the user will need a cheat sheet. (The blogger goes on to explain how 15 is related to the number of individuals one can trust deeply, while 150 relates to the total number of individuals or acquaintances a person can hold in his mind. Though fascinating, these points seem much less relevant to a discussion to the ideal size of a Scrum team.)

Certainly, five hits the sweet spot for short-term memory and few communication channels, but can the ideal size of a Scrum team ever really be absolute? Well, Jurgen Apello, who also believes that five is the ideal Scrum team size, backs down a little in the end, explaining, “When you need to structure a big project, don’t impose a “preferred” team size on people just because it is written in a book. Try to allow self-organization to do its job and let the people (within their real environment) figure out what their optimum is.”

Tips for Agile Success from the Experts

Forrester just published a new report called “Ensure Success for Agile Using Four Simple Steps,” which discusses how organizations can maximize the impact of their agile adoptions. With input from both companies using Scrum to manage projects as well as Scrum vendors such as Danube Technologies, the report captures a wide cross-section of perspectives and compiles the practices and strategies they kept hearing. It’s a very useful document for any organization weighing the pros and cons of an agile transformation and just as helpful for organizations that have started to transition to agile, but are experiencing some snags. If you’d like to read an excerpt or purchase the entire report, visit this link: http://www.forrester.com/Research/Document/Excerpt/0,7211,54037,00.html

As is often the case, the report focuses on how agile can succeed at an organization if everyone follows a handful of simple rules, from focusing on organizational change (not just agile adoption) to including business stakeholders on the team. In fact, these two rules struck me as critical for teams who are implementing agile without the help of an experienced coach—especially, since these issues are not always addressed in entry level discussions of agile adoption.

Adopting agile for its own sake, for instance, misses the point of what it can do. It should be implemented to change your organization. If agile is not surfacing previously hidden organizational dysfunction, helping teams meet previously missed deadlines, or improving the company’s culture, then the organization is likely using a new set of processes to do the same old thing. Thus, the end goal should always be the demonstrable improvement of processes and results, not adoption alone.

Likewise, business stakeholders should be educated about agile processes, values, and benefits, in order to fully understand its potential returns. If management remains aloof or reluctant to take a peek behind the curtain, so to speak, then it will be easier to dismiss agile as ineffective. However, when the business is actively involved in the pilot project and understands how agile methods are enabling its success, management will become agile advocates who support the transformation, even if it’s disruptive or painful at first.

Is Agile a Process or a Culture?

InfoQ editor Amr Elssamadisy posted an interesting article recently, which wonders whether agile is a process or a culture (http://www.infoq.com/news/2009/02/agile-is-culture). For the most part, we tend to think of agile as a process, but, as blogger Jeff Patton points out, culture is the process.

When I think about it, agile can often seem more like a culture than a process. When organizations begin to transform to agile ways of working, it doesn’t just require that they shake up how they work. It also requires how they think about work. In other words, agile requires team members to reorient themselves philosophically. Really, agile can be a big enough change from traditional development methods that it can seem on the order of a very big life change. (Think switching religions or political parties, or moving to another country.) For example, it asks that managers trust their teams to self-organize and, conversely, that teams trust their managers not to micro-manage them. Most agile paradigms entail processes that reinforce these values, so, as Patton suggests, culture and process are inextricably entwined.

However, if we were to indulge a chicken vs. egg kind of debate, would you agree that culture has to change before processes can? Or do you think an organization can implement process changes without addressing the overall culture that informs them? This problem’s a little recursive, but I think there’s something to it. Feel free to weigh in with comments!

Next Page »

Collabnet is a project success company specializing in the improvement of management and engineering practices for software development organizations.
Continue reading »

Agile Tools

The next generation of agile project management.
Continue reading »

Agile Training

Offering several training options on software process improvement. Our agile project management courses are designed to provide your organization with a foundation in the principles and skills necessary to benefit from Agile methods. Classes are offered both as public and private in-house sessions.
Continue reading »

Copyright © 2008 Agile Project Management  Free Project Management Tools   Project Management Classes