Agile

Agile

New Article: Constant Velocity Is a Myth

Constant Velocity Is a Myth

Is your agile team’s velocity constant from sprint to sprint? No? That’s not a surprise. Many teams assume that their velocity will be constant. In this article, the third in a series recently published on Projectmanagement.com, QSM's Andy Berner explains why that’s not the right expectation--and how that affects how you use this metric.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article!

Blog Post Categories 
Agile Articles

New Article: Ready, Set, Go...and Ready Again: Planning to Groom the Backlog

Planning to Groom the Agile Backlog

In an agile project, the backlog (the prioritized set of requirements) is the main input to iteration planning. For an agile project to progress smoothly, the backlog must be groomed and ready for each sprint. That work must be included in your project plan. In this article, the second in a series recently published on Projectmanagement.com, QSM's Andy Berner gives you five points to consider when planning that work.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article!

Blog Post Categories 
Agile Articles

New Article: Is It Bigger Than a Breadbox? Getting Started with Release Estimation

It’s becoming clear to organizations adopting Agile methods that one still needs to estimate how long a project or a release of a product will take. It won’t suffice for businesses to simply take guesses or accept unreasonable constraints. We must be able to derive credible estimates, based on a history of similar projects. How can we estimate a project in advance while still maintaining the ability to manage the backlog in an agile manner?

In this article, recently published on Projectmanagement.com, QSM's Andy Berner answers that question, compares release-level estimation to the techniques used for iteration estimation, and gives some pointers on getting started with release estimation in an agile environment.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article here!

Blog Post Categories 
Estimation Agile Articles

New Article: Does Agile Scale?

Agile is all the rage these days, but what happens to Agile projects when they're forced to scale to the size of major government enterprise initiatives? In this article, originally published in the May-June 2013 issue of Modern Government, Larry Putnam, Jr. looks at 93 Agile projects completed between 2002-2012 to see how these projects fared as their sizes increased. The study examines Early Adopters (2002-2008) vs. Later Adopters (2009-2012), as well as analyzing Agile vs. Non-Agile projects. The results may surprise you!

Read the full article here.

Blog Post Categories 
Agile Articles

Velocity: What Is It?

It’s easy to get confused or overly concerned about measuring velocity. Actually, the concept is almost embarrassingly simple. Velocity in Agile is simply the number of units of work completed in a certain interval. Like in many fields, Agile proponents appropriated existing terminology.

Here is one typical definition, from agilesoftwaredevelopment.com:

In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint… This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.

Velocity as a capacity planning tool used in Agile software development is calculated from the results of several completed sprints. This velocity is then used in planning future sprints.

The concept of velocity comes from physics. In physics, velocity is speed and direction, in other words, the rate of change of position of an object. Speed can be measured in many different ways.

In software, speed is frequently measured as size per unit of time (sometimes this has been called delivery rate). The measure of size could be any of the common size measures: lines of code, function points, requirements, changes, use cases, story points. The measure of time could be calendar time (month, week, day) or it could be specific to a project (sprint, release). As to direction, in software hopefully the direction is positive, but sometimes projects go backwards (for example, backing functionality out of a system).

Blog Post Categories 
Sizing Agile

Agile's Focus on Disciplined Discovery Aligns with SLIM Suite

As more of our clients adopt Agile methods, they often wonder how SLIM-Estimate fits into the Agile planning process? It’s not uncommon for teams to claim that Agile makes estimation obsolete. But regardless of which features end up in a particular release, businesses still need to know how much functionality can be delivered within a given schedule and budget. Because I have been working with more customers to estimate Agile projects, the first Agile planning and analysis practice suggested by Ellen Gottesdiener & Mary Gorman got my attention ‒ Use Three Planning Horizons: Now-View, Pre-View, and Big-View. Simply stated, each level of the view hierarchy represents more fine-grained planning and analysis:

  • Big-View – general idea; how the product will fit in with other products
  • Pre-View – enough detail to start planning the next release
  • Now-View – delivery team analyzes and estimate activities needed

Their statement, "we don’t think of agile as a methodology per se. Rather, it’s a disciplined discovery and delivery framework (emphasis added)" is consistent with QSM's approach to estimating Agile projects. Macro estimation techniques allow the business to allocate resources to product development efforts by identifying the number of releases to be built during the next budget cycle, which corresponds to the Big-View horizon. More detailed release planning is performed later in the process, using the prioritized product backlog to determine delivery goals for each iteration.

Blog Post Categories 
Agile SLIM Suite

Agile Series Part 4: How Software is like a Marshmallow

It’s tempting to do things that you shouldn’t.  In software development, unrealistic deadlines and changing requirements often lead teams to make counterproductive decisions, such as adding additional staff in order to achieve a deadline.  This not only creates more defects on the current project but also takes resources away from other projects.  

I recently faced a similar dilemma when deciding whether or not to indulge in the holiday treats in the office breakroom.  Should I consume the sugary snacks that taste delicious but have the potential to cause obesity (among other health consequences) or should I eat the banana I brought with me?  Perhaps to me, this internal debate became exaggerated after reading Kidd et al.’s (2013) study and watching the accompanying video on environmental stability and satisfaction.  However, after some thinking, and more indecision on my snack choice, I came to the conclusion that software is like a marshmallow.

Blog Post Categories 
Agile SLIM-MasterPlan

Agile Series Part 3: Embrace Change

“The only thing that is constant is change” ~Heraclitus

This proverb is often told to individuals (like me) who love to see a project follow a plan from start to finish.  I’ll be honest, I’m a planner. I’m thrilled when the plans I put in motion actually work out the way I intended.  These are the moments when I retort, “the only people who like change are wet babies.” However, more often than not, something changes, which throws off my entire plan and forces me to not only revisit Heraclitus’s proverb but also rethink my plan entirely.

Building software, particularly in Agile development, is no exception. In fact, the second principle of the Agile Manifesto states that developers should: “Welcom[e] changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

It would seem, then, that this principle would disappoint any planner working on an Agile team. Why bother creating a development plan if you know the stakeholders are going to change their minds about their desired features at the last minute? While we’re on this subject, if the requirements are going to change from one iteration to the next, why bother estimating the project at all?

Blog Post Categories 
SLIM-Control Agile

Agile Series Part 2: Stakeholder Satisfaction

When learning something new, people often try to relate the new information back to something they already know in order to help make sense of the new concept or idea.  As a psychology major now working in the software world, I’ve found myself relating a lot of what I’m learning back to the psychological theories and concepts I learned in college.  Therefore, it is no surprise that upon reading The Twelve Principles of Agile Software, I’ve discovered that many of their principles map to organizational psych concepts.

Agile development theory approaches software development holistically.  I believe this is one of the reasons Agile projects have become so successful.  Rather than merely focusing on skill development, Agile methods foster leadership skills and teamwork among members of the development team itself, as well as between the development team, the project owner, and the stakeholders.  One avenue for this is to unify the development team and project owner with the common goal of achieving stakeholder satisfaction.

The first principle states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  The question I had upon reading this was what do the authors mean by the term satisfaction?  When thinking about satisfaction, most people think of outcome satisfaction, or the ultimate outcome of something, in this case the functionality of the delivered software project.  Process satisfaction on the other hand, refers to the level of satisfaction associated with the method of developing the software, or how much the stakeholders enjoy the software development process.

Agile Series Part 1: The "Typical" Agile Project

After spending the past few weeks working with the Agile projects in QSM’s historical database, I’ve become interested in Agile Development Theory, particularly due to its popularity. While spending days at a time examining our database, I’m left with numerous data-driven questions. Therefore, I thought I would take this opportunity to write a series of Agile-related blog posts.

QSM’s database contains over 100 Agile projects from the U.S. and abroad. The projects include a variety of application types and their top three programming languages were JAVA, C++, and VB.NET.  Seeing this, I thought it might be interesting to examine the “typical” Agile project according to our data.

So what does the “typical” Agile project look like? For consistency purposes, I limited the sample to IT systems projects completed in the last six years. I measured the Duration, Effort, Average Staff, and MTTD at various project sizes to see how they compare.

Below are two figures that give demographic information about our “typical” Agile projects: 

Typical Agile Project

This scatter plot shows the individual Agile projects compared against QSM’s Business Agile trends.

Size (SLOC)

Duration (Months)

Effort (PHR)

Average Staff

Blog Post Categories 
Agile QSM Database