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

Subscribe

Recent Posts

• An Assessment of Agility
• Interactive Tutorial on Scrum
• Poor coders = poor testers?
• PMI and Scrum
• Strategic Vision & Agile

Categories

• Agile 20XX
• Agile Assessment
• Agile HR
• Agile Methodology
• Agile Project Management
• HR and Scrum
• Scrum
• Scrum and HR
• Uncategorized

Links

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

Podcasts

The Myth of Velocity?

I just ran across an article on InfoQ discussing the phenomenon of hyper-productivity—one that tends to come up a lot in relation to agile practices and Scrum, in particular. Apparently, the Scrum Development Group has seen some lively debate erupt around the topic, as trainers such as Tobias Mayer suggest that any attempts to measure hyper-productivity is “a waste of time.” Certainly, I understand his suspicions over Jeff Sutherland’s claim in a recent presentation that to be hyper-productivity is constituted by a rate of 300 percent improvement over three two-week sprints. As Mayer points out, it’s all relative. If a team accomplished nothing in a given sprint, then realizing a 300 percent improvement would be a snap. But it hardly means the team’s hyper-productive.

I suppose my take is that yes, the notion of “hyper-productivity” is somewhat beside the point, but measuring rates of improvement over time is absolutely essential to push a team to grow and increase its capacity. However, it’s essential for the team, not to be compared to some gold standard of hyper-productivity.

One reason cited for the relative uselessness of such a metric is that, in Scrum and other agile environments, work is estimated in terms of story points—an abstracted unit of difficulty that is agreed upon by the team. Because these units possess no direct correspondence to the amount of time required to complete work, they remain, at best, estimations. However, team members who work together over time typically develop a common of understanding of their estimating system and do, in fact, begin to assess work in a consistent manner. Thus a team’s rate of improvement is reliably measurable—just not in the sense that Sutherland suggests. While identifying an absolute measure of hyper-productivity misses the point, having a trend line to refer to as an indication of improvement over time is still valuable for teams.

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 Experts on the Backlog

Based on an earlier discussion of the vitality of the product backlog (according to Dave West, the author of the original article, it’s important, really important), numerous conversations have popped up on user groups and beyond. Best of all, it seems everyone who has chimed in has a slightly different opinion. In the face of so little consensus, InfoQ decided to back up and go straight to the experts with a set of questions about the backlog. After assembling a “virtual panel” that included such agile heavyweights as Mary Poppendieck, Ron Jeffries, Jeff Patton, David West, Steve Freeman, and Jason Yip, InfoQ threw the following five questions at them:

1. What is the purpose of a backlog in your opinion?
2. How would you define a backlog?
3. When/where should a backlog be considered waste?
4. When/where should a backlog be considered essential?
5. Is there a question or questions that I should have asked and I haven’t? If so, please ask and answer.

There’s a still a healthy amount of differing ideas even among this group, but some commonalities do emerge. You can take a look at all the responses here: http://www.infoq.com/articles/backlog-panel

Does Size Make Standups Fall Apart?

I just saw this post up at InfoQ (http://www.infoq.com/news/2009/04/large-team-standups) which discusses how well Scrum’s daily standup meeting functions when teams grow increasingly large. For the Scrum users cited in the article, there’s no mystery as to how useful they are for large teams: not very. According to them, as team size increases, these meetings drag on, fail to hold team members’ interest, and, consequently, individual reports are delivered out of sequence. Those who have tried to use Scrum-of-Scrums to address this problem have found that it doesn’t improve things much, either, explaining that the level of overhead increases exponentially with the depth of the Scrum-of-Scrums (i.e. the number of layers).

As I read through all of this, I couldn’t help but think, “Well, of course, standups break down when you try to use them with really big teams!” Scrum is designed to succeed under the recommended conditions. That is, all Scrum literature advises that teams should be cross-functional and composed of seven team members, plus or minus two. That’s a range of five to nine—pretty small, really. So it’s a no-brainer that these teams aren’t getting the advertised results. Would you stuff 30 people into a five-passenger sedan and expect a comfortable ride? Of course not! The same principles apply here.

One valuable point of inquiry in the article was the problem of scaling. I work for a small company that has never had to implement a Scrum-of-Scrums hierarchy, so I’m hardly an authority on the subject. But if you are, I’d be curious to hear some of your strategies for making that configuration work.

Free Educational Resource for Scrum Teams

I don’t know about you, but I’m always searching for great materials—articles, books, blogs, and so on—that explain agile project management methods and techniques in a clear and concise way. I’m trying to amass an archive of materials, so that when a new member joins my team or another team at my organization decides to pursue agile methods, I can offer some literature to help them find their bearings. One place I look for these (and I highly recommend you look there, too) is Dzone (www.dzone.com), which publishes “Refcardz,” a.k.a. educational resources for developers. In the past, most of DZone’s Refcardz have been deeply technical, but its newest one focuses on the popular agile project management framework, Scrum.

Authored by Danube Certified Scrum Trainer Michael James, this new Refcard is exactly the kind of document I’d want to give to someone who had just joined a Scrum team and needs to learn the basics fast. It is very readable and doesn’t get caught up in tangential conversations that would distract or confuse a newbie. Instead, it simply defines Scrum’s most foundational, non-negotiable elements: its roles, meetings, and artifacts. Scrum is a very skeletal framework and James does an excellent job of explaining them in a linear fashion that’s easy to follow, even for the uninitiated. Elsewhere, he provides his insight on related practices and the challenges of scaling Scrum teams across very large organizations. In all, it’s a comprehensive introduction to Scrum’s fundamental tenets and a few of the most relevant topics for practitioners.

Download the pdf of Michael James’ Scrum Refcard below and use it to train new members of your Scrum team.

Scrum_Refcard.pdf

The Jolt Product Excellence Awards

For companies in the tech sector, the Jolt Product Excellence Awards are the Academy Awards of innovation and efficiency. The finalists in the thirteen categories are online now: http://www.joltawards.com/finalists.html

You’ll have to wait until the SD West conference in March to find out who takes home the trophies, but there’s one category in particular I’m invested in: Project Management. For those of you who follow the site, you know that my team uses ScrumWorks Pro and that we’ve found it just blows away all the other agile tools we’ve used. Danube’s product is a finalist in that category, along with CASE Spec, Pivotal Tracker, Rally Enterprise, and TargetProcess. May the best tool win…

Cross-functional Teams

One of the ways that agile methods help boost efficiency is through its mandate for cross-functional teams. When approaching an agile adoption, many developers hear this and mistakenly assume that it means each individual should be able to perform every function in the development lifecycle. In fact, that’s the opposite of what cross-functionality means. Instead of populating a team with individuals who share redundant skill sets, agile methods prefer teams to be composed of individuals with a wide range of skills, so that all the necessary job functions are distributed across team members. After all, they’re cross-functional teams.

So how does cross-functionality help teams improve efficiency? First of all, because team members each have distinct specialties (UI design, Testing, business analysis, etc.), specialists can take the lead within their area of expertise. While it might be helpful if team members share overlapping skill sets, remember that a jack-of-all-trades is usually a master of none. So, in this case, having a dedicated specialist allows the team to move forward quickly and confidently. From a big picture standpoint, the fact that teams are made up of individuals with diverse backgrounds and expertise is also a good thing. Because everyone has their own experience and perspective, everyone approaches business problems from a slightly different vantage point. Taken together, the team can then form a clearer picture of the problem and then work to collectively solve it. Compared to the phenomenon of “group think,” in which individuals with the same areas of expertise all tend to agree on the first solution, divergent perspectives can help teams arrive at the right solution.

Timeboxing

One of the characteristics of all agile methods of project management is timeboxing — the practice of limiting activities to a particular amount of time. As I’ve mentioned, my team uses Scrum and its processes employ timeboxing to great effect. Of course, the basic idea is that timeboxing prevents teams from getting too hung up on requirements gathering (“analysis paralysis”) and forces them to get to work. If you’ve never worked in an agile environment, then this might sound a little chaotic. I can imagine a traditional project manager wondering how a team is supposed to proceed without first creating a detailed plan. Scrum — or any other agile method, for that matter — doesn’t endorse moving forward without a plan. Frankly, that would be impossible. But it does tell developers not to worry about identifying every possible requirement for a project before getting started. In Scrum, you develop incrementally, so the requirements scope can be defined as development progresses. Again, the value of timeboxing is to simply force a development team to commit to a starting point — usually, just some basic functionality. As they continue to develop, the rest of the requirements will begin to surface.

How does Scrum use timeboxing? On a macro level, the Scrum work cycle is made up of sprints, which are repeatable increments of time. For my team, sprints last two weeks. When each work cadence is capped at a particular time (such as two weeks), the team (in conjunction with the Product Owner) is forced to make decisions about what it can accomplish in that time. Of course, that means that some functionality will have to be developed in future sprints; not everything can be done at once. But again, the idea is to get the team moving toward sprint goals as quickly as possible.

Probably the best example of timeboxing in Scrum is the daily standup meeting, in which team members come together for a quick check-in. Each team member has one minute to report on what they accomplished since the last meeting, what they’ll be focusing on until the next one, and what impediments stand in their way. Even if a team member hasn’t delivered a full report, at the one-minute mark, he or she must stop speaking to allow the next team member to deliver an update. To enforce the timebox, many teams use a timer or a talking stick. But, again, the goal is to help the team maximize its time by curtailing superfluous speculation and spurring action.

Under the Umbrella of Agile

More and more, the term “agile” is being used by organizations to describe “the way they work.” But what does that actually mean? Agile is an umbrella term for various frameworks and methods that use adaptive planning and iterative, incremental development to manage projects. In that sense, agile methods all originate from a reaction to waterfall (i.e. traditional, sequential development), which assumed that all of a project’s requirements can be staked out immediately and will require no scope or tactical revision once development begins. Some of the most popular agile methods include Extreme Programming, DSDM, and Scrum, which I’ll discuss in this post.

Because the waterfall process is rigid to the point of inflexibility, it is termed a “heavyweight” process. Scrum, conversely, attempts to be, as the term suggests, agile. That is, Scrum removes unnecessary processes, opting instead for a “lightweight” framework that empowers teams with the flexibility to react nimbly to emerging business conditions. In fact, Scrum actually has very few rules. It whittles development down to a few roles, meetings, and artifacts and an abbreviated, repeatable work cycle, called a Sprint. Whereas a waterfall project management is linear, stretching infinitely forward until release, Scrum is more like a continuous feedback loop. The entirety of the development cycle is condensed into a single increment with Scrum, which is then repeated until the release is ready to ship.

Scrum challenges team to create a potentially shippable increment of work each Sprint. Early on in development, that might amount to some very, very basic coding, but the important thing is that the team produces some functionality. This mandate is especially helpful in ensuring that teams are continually making demonstrable progress. Even if a team heads in the wrong direction, the brevity of the Sprint cadence means that when teams fail, they fail fast. This is a good thing. Since the team meets with the Product Owner to assess the project’s direction at the end of each Sprint, the team can never get too far off-track. In a waterfall project, where requirements are fixed, there is no process for this kind of ongoing inspection of goals. Thus Scrum’s iterative nature not only helps organizations save time and money, but it also helps them create products that their customers truly want.

posted by: agile project management

Summer of Scrum

« Previous 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