Agile

Agile

New Article: Counting Function Points for Agile / Iterative Software Development

Counting Function Points for Agile

Function points are proven to be effective and efficient units of measure for both agile/iterative and waterfall software deliveries. However, inconsistencies come to light when comparing function points counted in agile/iterative development with those counted in waterfall or combination development . These inconsistencies can create confusion for cost, productivity, and schedule evaluations that span multiple software delivery methods. This paper, recently published on IFPUG's Beyond MetricViews by QSM Consultant Carol Dekkers, seeks to marry International Function Point Users Group (IFPUG) definitions with equivalent concepts in agile/iterative processes in order to create a basis for consistent comparison. 

Read the full article!

Blog Post Categories 
Agile Articles Function Points

New Article - Big Agile: Enterprise Savior or Oxymoron?

We know agile works well for small teams and small projects, but monster enterprise projects often require greater capabilities than a small team can provide. So why not scale up agile teams to maintain the cost and efficiency benefits of the agile process while accessing the necessary manpower to pursue complex global projects? On the surface, it makes sense, but what if agile only works when teams and projects stay relatively small? That's the question most CIOs want answered before investing scarce time, energy, or resources chasing the big agile paradigm. In this article recently published on Agile Connection, QSM's Larry Putnam, Jr. turns to cold hard data from completed projects in the QSM database to determine whether big agile is "enterprise savior or oxymoron."

Read the full article!

Blog Post Categories 
Agile Articles

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