Scott is Practice Leader Agile Development with IBM Rational. He is the (co)-author of 19 books on software development topics ranging from very traditional to very agile approaches. In recent years his focus has been on techniques to scale agile software development, in particular how modeling, documentation, and database issues can be addressed agilely. He works with customers around the world to improve their software processes in a manner which reflects their unique situation. He is a senior contributing editor with Dr. Dobb's Journal and a keynote speaker at software conferences internationally.

Agile Myth:High Quality Costs Less than Low Quality - Busted! (at scale)

Yesterday I was involved with a workshop around agile development at scale. At one point in the conversation we started talking about the relationship between cost and quality. Some of the people in the workshop were relatively new to agile and still believed the traditional theory that to build in high quality it costs more, sometimes substantially more. This does appear to be true on traditional waterfall projects, but some people were making the mistake that this was an "natural law of IT" which also must apply to agile project teams. I naturally jumped on that idea and described how agile developers have found that writing high quality code leads to lower development costs and shorter time to value, in direct contradiction to traditional theory. A few people struggled with the idea for a bit, and one was pretty adamant that in some cases the need for very high quality does in fact lead to greater cost and time. He talked about his experiences on large-scale Rational Unified Process(RUP) projects and in particular how some URPS (usability, reliability, performance, and supportability) requirements can increase your cost. At this point Per Kroll, co-author of Agility and Discipline Made Easy: Practices from OpenUP and RUP, jumped into the conversation and pointed out although higher quality does lead to lower cost in most cases, using Toyota's lean approach to manufacturing as an example, that the agile community didn't completely have the relationship between quality and cost completely correct. My spidey sense told me that a learning opportunity was coming my way.

Per and I had an offline discussion about this to explore what he'd been observing in practice. I've found that a good way to cut through some of the mainstream agile rhetoric is to apply the Agile Process Maturity Model (APMM) to put the rhetoric into context. In APMM level 1 (core agile development) and APMM level 2 (disciplined agile delivery) it appears to be the case that higher quality does in fact lead to lower costs and shorter time for delivery, something that Per and I had observed numerous times. This happens because high quality code is much easier to understand and evolve than low quality code -- the agile community has found that it is very inexpensive to write high quality code by following practices such as continuous integration, developer regression testing [or better yet test-driven development(TDD)], static code analysis, following common development conventions, and agile modeling strategies. When you "bake in" quality from the start through applying these techniques, instead of apply traditional techniques such as reviews and end-of-lifecycle testing (which is still valid for agile projects, but should not be your primary approach to testing) which have long feedback cycles and therefore prove costly in practice. But, as we've learned time and again, when you find yourself in more complex situations of Agility@Scale (APMM level 3) sometimes the mainstream agile rhetoric falls down. For example, in situations where the regulatory compliance scaling factor is applicable, particularly regulations around protecting human life (i.e. the FDA's CFR 21 Part 11), you find that some of the URPS requirements require a greater investment in quality which can increase overall development cost and time. This is particularly true when you need to start meeting 4-nines requirements (i.e. the system needs to be available 99.99% of the time) let alone 5-nines requirements or more. The cost of thorough testing and inspection can rise substantially in these sorts of situations.

Agility at Scale: Become as Agile as You Can Be

I recently wrote an "e-book" for Internet Evolution overviewing agile software development at scale. The goal of the Agility at Scale: Become as Agile as You Can Be ebook is to get people thinking outside of the box a bit when it comes to agile development strategies and see that they really are ready for primetime.

The e-book is fairly short, I suspect that you could read it in ten minutes, and it covers the following topics (many of which I've blogged about over the past year or so):

• Introduction to Agile Process Maturity Model (APMM). The APMM puts agile processes, practices, and rhetoric into context.
  
• APMM Level 1: Core Agile Development. Overviews partial methods -- such as Scrum, XP, and Agile Modeling -- arguing that they provide the foundation from which to build a full delivery life cycle.
  
• APMM Level 2: Disciplined Agile Delivery. Overviews full delivery processes -- such as OpenUP and DSDM -- and more importantly what a full agile life cycle actually looks like in practice.
  
• Are You really agile? Overviews the agile criteria.
  
• APMM Level 3: Agility at Scale. Overviews the agile scaling factors which add complexity to software delivery projects, agile or not.
  
• Case Study: Online Bartering system developed in an agile manner. A quick overview of how to apply agile delivery strategies to develop an e-commerce system Although e-commerce is used as an example, the host site for this ebook focuses on Internet-based development afterall, the reality is that agile is being applied in a very wide range of domains.
  
• Become as agile as you can be. Some strategies for how to adopt agile techniques effectively.
  

Mapping Scrum Terms to Standard Terms

The Scrum community has adopted a different set of terms than the other agile methodologies. This is done on purpose to help people realize that Agile approaches are different than traditional approaches, which can help in their adoption, but it can also hinder people's understanding because some of the terminology is not only non-standard it really doesn't make much sense. Because of this I'm often asked by people that I'm coaching to convert back and forth between terms, and recently wrote a detailed article on the subject. The following summarizes the mapping:

• Daily Scrum Meeting ==> Daily Stand-up Meeting
  
• Product Backlog ==> Work Item List
  
• Scrum Master ==> Team Lead or Team Coach
  
• Sprint ==> Iteration or Time Box
  

For more details read my article Translating Scrum Terminology which includes explanations of a wider range of Scrum terms and discussions of why some of them really are questionable.

Further reading:

• Translating Scrum Terminology
  
• Implementing Scrum Site
  
• Scaling Scrum
  
• Roles on Agile Teams
  

APMM Recording

Last week I recorded a webcast entitled Be As Agile As You Can Be: Introducing IBM's Agile Process Maturity Model (APMM). The webcast is a little less than 30 minutes long and it goes into the following topics:

• Overview of levels 1 through 3 of the Agile Process Maturity Model (APMM)
  
• The goal of the APMM is to help categorize and understand agile processes, not to rate your adoption level (the CMMI Defined approach can address that need)
  
• The values of the Agile Manifesto
  
• The values of the Manifesto for Software Craftsmanship
  
• A definition for disciplined agile software development
  
• The agile construction lifecycle (level 1)
  
• The agile delivery lifecycle (level 2)
  
• Scaling factors for agile development (level 3)
  
• Agile tooling for IT teams
  
• Agile tooling for system engineering (SE) teams
  
• Agile adoption via Measured Capability Improvement Framework (MCIF)
  
• What results can you reasonably expect from adopting agile across your organization?
  

Agile Process Maturity Model (APMM) in Practice

The primary goal of the Agile Process Maturity Model (APMM) is to help you to put various agile strategies and practices into context, to help you to work your way through some of the mainstream agile rhetoric so that you can tailor agile techniques to meet your unique situation effectively. To better understand this, let’s work through an example. Recently I visited a customer who had adopted Scrum. They were a few sprints, what Scrum calls iterations, into the project and were running into some difficulties. Although I was primarily brought in to educate senior management on disciplined agile software development, I was also asked to sit in on the team’s daily stand-up meeting so that I could hopefully provide some suggestions as to how to address the problems they were running into.

Their work area was fairly typical. They had some whiteboards which they were using for project planning and tracking, with sticky notes to indicate what work had been taken on by each team member. The current status of the task (not yet started, in progress, and completed) was indicated by putting each sticky note in a corresponding column for the status and corresponding column for the team member. This allowed everyone on the team to easily share their status and to see the status of everyone else. On the sides were sketches of the architecture as well as some business oriented models. In addition to Scrum the team had adopted several practices from Agile Modeling, in this case they had done some initial requirements envisioning and architecture envisioning, as well as practices from Extreme Programming (XP) for construction. In short, they had followed a fairly common strategy of combining practices from APMM level 1 core agile methods to put together what they hoped to be a full, APMM level 2 lifecycle.

This would have worked perfectly fine if they had actually been in a level 2 situation, but that wasn’t the case. First, the team was distributed, with most of the team in the location that I was visiting but some people located in two other distant cities. Therein was the source of most of their problems. The people at the other two locations weren’t getting much value out of the daily stand-up meetings, even though they would dial in, because they couldn’t see the project status information. Although people at this location were trying their best to represent these distant people in the daily stand-ups it wasn’t working well – their status information wasn’t being kept up to date and for some people it was a bit of mystery as to what they were actually working on at all.

This team also had 30 people in it, which isn’t a big deal although it can stretch the limits of the simple modeling and planning tools (in this case paper and whiteboards) that they were using. Because the team was larger they were investing a fair bit of time creating burn down charts at both the iteration/sprint and project levels. One of the unfortunate implications of using manual tools for project management is that any associated metric/status reporting in turn becomes manual as well. Considering how the agile community is so concerned with working efficiently, I find it comical that we have a tendency to overlook our own potentially unnecessary bureaucracy such as this.

The problem was that the team was applying level 1/2 techniques, in this case using sticky notes and whiteboards to capture the detailed iteration plan, applying similar strategies to capture key models, and were verbally relaying of status information between sub-teams. There are perfectly fine strategies for smaller co-located teams, but not so good for large or distributed teams. The solution was to apply APMM level 3 strategies, in this case forgoing some of the manual tools and instead use electronic tooling such as Rational Team Concert (RTC) to share information across disparate locations, in particular the work assignment and corresponding status information. RTC also creates common agile reports such as burn-down charts based on the activities of the developers, providing accurate (nearly) real-time information while removing the burden of status reporting. The RTC project dashboard does more than just this, to see an actual example of one visit www.jazz.net to see the dashboard for the RTC development team itself. You can also see their actual work item list too (a level 2 strategy), a more advanced version of Scrum’s product and sprint backlogs (level 1 strategies).

This example illuminates one of the benefits of APMM – it provides guidance to help agile teams understand the context of the situation that they find themselves in and thereby provide opportunity to find strategies which reflect that context. In this case the team had been mislead by the mainstream agile rhetoric and had blinded themselves to a fairly obvious solution. They were in an APMM level 3 situation, in this case two scaling factors (team size and distribution) were applicable and therefore they needed level 3 strategies to address the risks associated with those scaling factors. Had these scaling factors not been applicable the solution that they had crafted, in this case an APMM level 2 lifecycle (they hadn’t gotten to release yet, so arguably they hadn’t yet crafted such a solution although were well on their way) based on Scrum, Agile Modeling, and XP. As an aside their strategy was beginning to look suspiciously like OpenUP, more on that in a future column, unbeknownst to them.

Agile Scaling Factors

Level 3 of the Agile Process Maturity Model (APMM) is loosely defined as disciplined agile system delivery (level 2) where one or more scaling factors are prevalent. These agile scaling factors are:

The Agile Process Maturity Model (APMM)

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today. The APMM defines three levels, each of which build upon each other, for agile processes and practices. At IBM we’ve found that many customers find the agile message confusing, in part because of the multitude of voices within the agile community but moreso because the agile rhetoric often seems to ignore or gloss over many important issues which our customers face on a daily basis. Hence the need for something like APMM to provide badly needed context for agile methods and practices


APMM Level 1: Core Agile Development
Level 1 agile processes address a portion of the system life cycle (SDLC). Examples of Level 1 agile processes include:

• Scrum. The focus of Scrum is project leadership and requirements management. Scrum proponents claim that it is a process framework, but if so then it is a sparse and incomplete one at best and very clearly every other process in existence could also make this marketing claim. A more accurate description is that it is a high-level lifecycle for construction iterations (what Scrum calls “sprints”) and several practices such as daily stand-up “Scrum” meeting, product owner, product backlog, iteration/sprint planning, and potentially shippable software.
  
• Extreme Programming (XP). XP is a collection of practices for software construction, include refactoring, test-first design, pair programming, on-site-customer, continuous integration, whole team, and collective ownership. XP is very close to being a APMM Level 2 process but it is unfortunately missing (currently at least) explicit practices for project initiation and release the system into production.
  
• Agile Modeling (AM). AM is a collection of practices for light-weight modeling and documentation, including requirements envisioning, executable specifications, active stakeholder participation, prioritized requirements, and prove it with code.
  
• Agile Data (AD). AD is a collection of practices for database development, including agile data modeling, database testing, database refactoring, and continuous database integration.
  

APMM Level 2: Disciplined Agile Delivery
Level 2 agile processes extend Level 1 to address the full system delivery life cycle (SDLC). As the criteria for disciplined agile development suggests they also tend to “dial up” certain aspects of agile development, such as testing, measurement, and process improvement. Furthermore, they include explicit mechanisms to support effective (ideally lean) governance. Examples of Level 2 agile processes include:

• Hybrid Processes. A common strategy is for organizations to cobble together a Level 2 process on their own, often around the Scrum "process framework" and XP with ideas either brought in or reinvented from AM and sometimes AD. This strategy is perfectly fine in theory, although in practice a lot of project teams seem to spend a lot of time in trial-and-error experimentation to figure it out for themselves. They invariably have some "learning experiences" which could have been avoided if they'd only started with a Level 2 process to begin with.
  
• Rational Unified Process (RUP). RUP is a comprehensive process framework for iterative software delivery which can be instantiated anywhere from a very agile form to a very traditional form as your situation warrants. RUP practices include risk-value lifecycle, whole team, test-driven development (TDD), business process sketching, and continuous integration.
  
• Open Unified Process (OpenUP). OpenUP, the definition of which is available via open source, which combines and extends practices from Scrum, XP, AM and RUP for co-located agile teams which are building business applications. OpenUP practices include whole team, daily standup meeting, prioritized work items, risk-driven lifecycle, TDD, active stakeholder participation, and continuous integration.
  
• Harmony ESW. Harmony ESW is an agile software process for embedded software (ESW) systems.
  
• Dynamic System Development Method (DSDM). DSDM is an agile delivery process originally based on Rapid Application Development (RAD) which is often used to developer user interface intensive application. DSDM practices include prototyping, test throughout the lifecycle, reversible changes, and feasibility study.
  

APMM Level 3: Agility at Scale
In the early days of agile, the applications where agile development was applied were smaller in scope and relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile development to a broader set of projects. Agile hence needs to adapt to deal with the many business, organization, and technical complexities today’s software development organizations are facing. This is what Level 3 of the APMM is all about – explicitly addressing the complexities which disciplined agile delivery teams face in the real world.

The scaling factors which an agile team may face to a lesser or greater extent includes team size, physical distribution, organizational distribution, regulatory compliance, cultural or organizational entrenchment, system complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management). Each factor has a range of complexities, and each team will have a different combination and therefore will need a process, team structure, and tooling environment tailored to meet their unique situation.

Unfortunately, the term “maturity” is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integrated (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another, and in future blog postings I’ll discuss how CMMI and APMM fit together.

Further reading:

• Capability Maturity Model Integrated Home Page
  
• CMMI® or Agile: Why Not Embrace Both!
  
• The Agile System Development Lifecycle (SDLC)
  
• Agile Criteria
  
• The Open Unified Process (OpenUP) Download Page
  
• Agile Manifesto
  
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
  

Manifesto for Software Craftsmanship

I just wanted to share with you the Manifesto for Software Craftsmanship which extends the Agile Manifesto. The Manifesto for Software Craftsmanship states:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
  
• Not only responding to change, but also steadily adding value
  
• Not only individuals and interactions, but also a community of professionals
  
• Not only customer collaboration, but also productive partnerships
  

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.


I view this manifesto as an important step in the maturation of software development. We're moving away from the rhetoric of the Level 1 agile software processes to the more disciplined mindset that we see with Level 2 processes in the Agile Process Maturity Model (APMM). More on this in a future blog posting.

Agility at Scale at Rational Software Conference

And now, a brief message from our sponsor. ;-)

Just wanted to let you know that Agility@Scale will be a major theme at this year's IBM Rational Software Conference being held in Orlando May 31 through to June 4. I'll be giving two presentations, Agility at Scale: Mitigating the Percieved Risks of Agile Adoption and Distributed Agile Software Development: Best Practices, facilitating a panel entitled Experience Reports from the Agile Trenches: What's Really Working, What's Not Working, and Why, and running a half-day workshop entitled Become as Agile as You Need to Be: Scaling Agile Software Development to Meet Your Real-World Situation. As usual, it will be a busy conference for me. ;-)

There are of course other sessions and workshops specific to agile topics. Some highlights include:

• Agility at Scale: Scrum and Rational Team Concert (a half-day workshop)
  
• Achieving Business Agility with Enterprise Architecture by Chris Armstrong
  
• Agile Enterprise Development with Groovy and Grails by Bjorn Beskow
  
• A Scalable "Just Enough" Approach to Requirements by Kurt Bittner
  
• Collaboration Strategies for Agile Quality Management by Anne Burke
  
• Agility at Scale: Agile Planning and Best Practices with IBM Rational Team Concert by Erich Gamma
  
• Agile Model-Driven Development for Embedded Systems by Bruce Douglass
  
• What they don''t teach you about software at school: Be Smart! by Ivar Jacobson
  
• Social Networking for Agile Developers by Anthony Kesterton
  
• Agile Modeling: No, It's Not an Oxymoron by Terry Quatrani
  
• Collaboration Technologies for Globally Distributed Agile Development Teams by Brad Sandler
  
• Long Distance Running - Sprints and Iterations for Large Projects by Ian Spence
  
• IBM(R) Rational(R) Quality Manager in a Globally Distributed World by Peter Sun
  
• Can Agility and IBM(R) Rational(R) Unified Process(R) Coexist in the Workplace? Yes! by Kim Werner
  
• Agile Requirements at Scale: Putting User Stories in Context by Tina Zhuo, Cherifa Mansoura, and myself.
  

Of course there's a lot more going on at the conference when it comes to scaling agile software development than just these sessions, but I thought I'd give you a feel for what's going on. Hope to see you at the conference. There's a "March Madness" sale going on right now at the registration page where if you purchase one pass you get the second for half price.

Further reading:

• IBM Rational Software Conference 2009
  
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
  

Requirements Envisioning on Agile Projects at Scale

Contrary to popular belief, agile development teams do in fact model and yes, they even do some up front requirements and architecture modeling. Two of the best practices of Agile Modeling are Requirements Envisioning and Architecture Envisioning where you spend a bit of time at the beginning of the project doing enough initial modeling to get you going in the right direction. The strategy is to take advantage of modeling, which is to communicate and think things through without taking on the risks associated with detailed specifications written early in the lifecycle. In this blog posting I will focus on requirements envisioning, in a future posting I'll cover architecture envisioning.

The goal of initial requirements envisioning is to identify the scope of your effort. You need to do just enough modeling early in the project to come to stakeholder concurrence and answer questions such as what you're going to build, roughly how long it's going to take (give a range), and roughly how much it's likely to cost (once again, give a range). If you can get the right people together in the room, which can sometimes be a logistics challenge but not one that you couldn't choose to overcome, there are very few systems (I suspect less than 5%) that you couldn't initially scope out in a few days or a week. I also suspect that most of the remaining systems could be scoped out with less than 2 weeks of modeling, and if not then I'd take that as an indication that you're taking on too large of a project. I'm not saying that you'll be able to create big detailed specifications during this period, and quite frankly given the problems associated with " Big Requirements Up Front (BRUF)" you really don't want to, but I am saying that you could gain a pretty good understanding of what you need to do. The details, which you'll eventually need, can be elicited throughout the lifecycle when you actually need the information. A common saying in the agile community is that requirements analysis is so important for us that we do it every single day, not just during an initial phase. I'll discuss just in time (JIT) approaches to requirements modeling in a future posting.

To envision the requirements for a business application, you might want to consider creating the following models:

• High-level use cases (or user stories). The most detail that I would capture right now would be point form notes for some of the more complex use cases, but the majority just might have a name. The details are best captured on a just-in-time (JIT) basis during construction.
  
• User interface flow diagram. This provides an overview of screens and reports and how they're inter-related. You just need the major screens and reports for now.
  
• User interface sketches. You'll likely want to sketch out a few of the critical screens and reports to give your stakeholders a good gut feeling that you understand what they need. Sketches, not detailed screen specifications, are what's needed at this point in time.
  
• Domain model. A high-level domain model, perhaps using UML or a data modeling notation, which shows major business entities and the relationships between them, can also be incredibly valuable. Listing responsibilities, both data attributes and behaviors, can be left until later iterations.
  
• Process diagrams. A high-level process diagram, plus a few diagrams overviewing some of the critical processes, are likely needed to understand the business flow.
  
• Use-case diagram. Instead of a high-level process diagram you might want to do a high-level use case diagram instead. This is a matter of preference, I likely wouldn't do both.
  
• Glossary definitions. You might want to start identify key business terms now, although I wouldn't put much effort into settling on exact definitions. I've seen too many teams run aground on "analysis paralysis" because they try to define exact terminology before moving forward. Don't fall into this trap.
  

For small teams simple tools such as whiteboards and paper are usually sufficient for requirements envisioning. But what happens at scale? What if you're working on a large agile team, say of 50 people, 200 people (IBM has delivered software into the marketplace with agile teams of this size), or even 500 people (IBM currently has teams of this size applying agile techniques)? What if your team is distributed? Even if you have people working on different floors of the same building, let alone working from home or working in different cities or countries, then you're distributed (see my postings about distributed agile development). Suddenly whiteboards and paper-based tools (index cards, sticky notes, ...) aren't sufficient. You're still likely to use these sorts of tools in modeling sessions with stakeholders, but because of one or more scaling factors you need to capture your requirements models electronically.

In January Theresa Kratschmer and I gave a webcast entitled Agile Requirements: Collaborative, Contextual, and Correct which overviewed agile approaches to requirements elicitation and management, including requirements envisioning. We also showed how Rational Requirements Composer (RRC) can be used to electronically capture critical requirements information, enabling you to address the needs of large and/or distributed agile teams, while still remaining lightweight and flexible. I suspect that you'll find the webcast to be very illuminating and RRC something that you want to take a look at (the link leads to a trial version). Of course RRC can be used in other situations as well, but that's not what I'm focused on right now.

Teams which find themselves in regulatory environments will likely need to do more than just use RRC, as might very large teams. Regulatory compliance often requires more complex requirements documentation, which in turn requires more sophisticated tools such as DOORS or Requisite Pro, and I would consider using those tools in the types of situations that warrant it. One of the things that people often struggle to understand about agile approaches is that you need to tailor your strategy to reflect the situation at handle. One process size does not fit all, so you will end up using different tools and creating different artifacts to different extents in different situations. Repeatable results, not repeatable processes, is the rule of the day.

Further reading:

• Agile Requirements: Collaborative, Contextual, and Correct Webcast
  
• Rational Requirements Composer
  
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
  
• Agile Requirements Modeling
  
• Requirements Envisioning: An Agile Best Practice
  
• Examining the Big Requirements Up Front (BRUF) Approach
  
• DDJ's 2008 Modeling and Documentation Survey, which found that agile teams are more likely to model than traditional teams
  

Defining Disciplined Agile Software Development

When adopting agile software development techniques across a large number of teams within your organization it is important to provide a definition for what agile software development is, in addition to criteria for what it means to be agile. Many people will point to the four values of the Agile Manifesto and claim that's a good definition. Well... it might be a good definition for the visionaries and early adopters among us, but for people on the right-hand side of the technology adoption chasm (the early majority, late majority and the laggards) this isn't enough. Don't get me wrong, I'm a firm believer in the agile values but I like to cast them as philosophies instead of as a definition.

At IBM Software Group, the definition of disciplined agile software delivery ( APMM Level 2 ) which we have been sharing with our customers is:
Disciplined agile software delivery is an evolutionary (iterative and incremental) approach to delivery which regularly produces high quality software in a cost effective and timely manner. It is performed in a highly collaborative and self-organizing manner, with active stakeholder participation to ensure that the team understand and addresses the changing needs of its stakeholders. Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.

I think that this is a pretty good definition, although I have no doubt that we'll evolve it over time.

I also suspect that the agile community will never settle on a common definition for what agile is and more than likely are smart enough not to even try. ;-)


Further reading:

• Agile Criteria
  
• Agile Manifesto
  
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
  

Examining Acceleration

I've been getting a lot of questions lately about applying the acceleration metric in practice. So, here's some answers to frequently asked questions:

1. How do I monetize acceleration? This is fairly straightforward to do. For example, assume your acceleration is 0.007 (0.7%), there are five people on the team, your annual burdened cost per person is $150,000, and you have two week iterations. All these numbers are made up, but you know how to calculate acceleration now and IT management had darn well better know the average burdened cost (salary plus overhead) of their staff. So, per iteration the average burdened cost per person must be $150,000/26 = $5,770. Productivity improvement per iteration for this team must be $5,770 * 5 * .007 = $202. If the acceleration stayed constant at 0.7% the overall productivity improvement for the year would be (1.007)^26 (assuming the team works all 52 weeks of the year) which would be 1.198 or 19.8%. This would be a savings of $148,500 (pretty much the equivalent of one new person). Of course a 20% productivity increase over an entire year is a really aggressive improvement, regardless of some of the claims made by the agile snake oil salesman out there, although at 10-15% increase is a reasonable expectation. What I'd really want to do is calculate the acceleration for the year by comparing the velocity from the beginning of the year to the end of the year (in Western cultures I'd want to avoid comparing iterations near to the holidays). So, if the team velocity the first week of February 2008 was 20 points, now the same team's velocity the first week of February 2009 was 23 points, that's an acceleration of (23-20)/20 = 15% over a one year period, for a savings of $112,500.

2. Is acceleration really unitless? For the sake of comparison it is. The "units" are % change in points per iteration, or % change in points per time period depending on the way that you want to look at it. Because it's a percentage I can easily monetize it, as you see above, and use it as a basis of comparison.

3. How do I convince teams to share their data? This can be difficult. Because acceleration is easy to calculate for agile teams, and because it's easy to use to compare teams (my team has .7% acceleration whereas other teams down the hall from mine have accelerations of .3% and -.2% of teams), people are concerned that this metric will be used against them. OK, to be fair, my team might be OK with this. ;-) Seriously though, this is a valid fear that will only be addressed by an effective governance program based on enablement, collaboration, and trust instead of the traditional command-and-control approach. Management's track record regarding how they've used measurements in the past, and how they've governed in general, have a great effect on people's willingness to trust them with new metrics such as acceleration. The implication is that you need to build up trust, something that could take years if it's possible at all.

4. Why does this work for agile teams? Agile teams are self organizing, and an implication of that is that they will be held accountable for their estimates. Because of this accountability, and because velocity is a vital input into their planning and estimation efforts, agile teams are motivated to calculate their velocity accurately and to track it over time. Because they're eager to get their velocity right, and because acceleration is based on velocity, there's an exceptionally good chance that it's accurate.

5. What about function points or similar productivity measures? Function points can be calculated for projects being developed via an agile approach, or other approaches for that matter, but it's a very expensive endeavor compared to calculating acceleration (which is essentially free) and likely will be seen as a bureaucratic overhead by the development team. My rule of thumb is that if you're not being explicitly paid to count function points (for example the US DoD will often pay contracting companies to create estimates based on function point counts) then I wouldn't bother with them.

6. What about calculating acceleration for iterative project teams? Iterative project teams, perhaps following Rational Unified Process (RUP), can choose to calculate and track their velocity and thereby their acceleration. The key is to allow the team to be self organizing and accountable for their estimates, which in turn motivates them to get their velocity right just like agile teams (RUP can be as agile as you want to make it, don't let anyone tell you differently).

7. What about calculating acceleration for traditional project teams? In theory this should work, in practice it is incredibly unlikely. Traditional teams don't work in iterations where working software is produced on a regular basis, they're typically not self organizing, and therefore there really isn't any motivate to calculate velocity (even if they do, there is little motivation to get it right). Without knowing the velocity you can't calculate acceleration. If you can't trust the velocity estimate, and I certainly wouldn't trust a traditional team's velocity estimate, then you can't trust your acceleration calculation. So, my fall back position to calculate productivity improvement would be to do something like function point counting (which is expensive and difficult to compare between teams due to different fudge factors used by different FP counters) and then looking at change in FPs delivered over time.

8. How can I apply this across a department? It is fairly straightforward to roll up the acceleration of project teams into an overall acceleration measure for a portfolio of teams simply by taking a weighted average based on team size. However, this is only applicable to teams that are in a position to report an accurate acceleration (the agile and iterative teams) and of course are willing to do so.

9. What does a negative acceleration tell me? If the acceleration is negative then productivity on the team is going down, likely an indicator of quality and/or team work problems. However, you don't want to manage by the numbers so you should talk to the team to see what's actually going on.

10. What does a zero acceleration tell me? This is an indication that the team's productivity is not increasing, and that perhaps they should consider doing retrospectives at the end of each iteration and then acting on the results from those retrospectives. Better yet they can "dial up" their process improvement efforts by adopting something along the lines of IBM Rational Self Check.


Further reading:

• Acceleration: An Agile Productivity Measure
  
• Lean Development Governance
  
• Agile and Rational Unified Process (RUP)
  
• Introducing IBM Rational Self Check for Software Teams

Free Agile/Jazz Seminar in Milwaukee on January 29, 2009

As part of the Agile/Jazz event In Milwaukee on the 29th I'll be giving a talk about the realities of agile software development. The URL for the event is http://www.iconatg.com/lp/events/jazz/jazz_milwaukee.html and I hope to see you there.

- Scott

Criteria for a Disciplined Agile Team

Although it might not be obvious, and important success factor in adopting agile techniques is to be able to determine whether a team is agile or not. The challenge that many organizations face is that many teams will claim to be agile, yet management, who often has little or no experience with agile approaches, cannot tell which claims are true and which are over zealous (I'm being polite). The following are the criteria that I suggest you look for in a disciplined agile team:
1. Produce working software on a regular basis. This is one of the 12 principles behind the Agile Manifesto, and in my experience is a critical differentiator between the teams that are agile and those that are merely claiming it. Ideally the team should produce potentially shippable software each iteration. That doesn't mean that they'll deploy the system into production, or the marketplace, each iteration but they could if required to do so. Typically the team will deploy into a pre-production testing environment or a demo enviroment at the end of each iteration (or more often for that matter).
2. Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach. Agile developers test their work to the best of their ability, minimally doing developer regression testing via a continuous integration (CI) strategy and better yet do developer-level TDD. This approach enables development teams to find defects early, thereby reducing the average cost of addressing the defects, it also helps them to deliver higher quality code and to move forward safely when adding or changing functionality.
3. Work closely with their stakeholders, ideally on a daily basis. A common practice of agile teams is to have an on-site customer or product owner who prioritizes requirements and provides information on a timely manner to the team. Disciplined agile teams take it one step further and follow the practice active stakeholder participation where the stakeholders get actively involved with modeling and sometimes even development.
4. Are self-organizing within a governance framework. Agile teams are self-organizing, which means that the people doing the work determines how the work will be done, they're not told by a manager who may not even be directly involved with the work how it will be done. In other words the team does its own planning, including scheduling and estimation. Disciplined agile teams are self governing within an effective governance framework.
5. Regularly reflect on how they work together and then act to improve on their findings. Most agile teams hold a short meeting at the end of each iteration to reflect upon how well things are working and how they could potentially improve the way that they are working together. Sometimes this is done in a more formalized manner in the form of a retrospective, but often it's done informally. The team then acts on one or more of their suggested improvements the next iteration. Disciplined agile teams take this one step further and measure their software process improvement (SPI) progress over time: the act of taking these measures, perhaps via a product such as Rational Self Check, helps to keep the team on track in their SPI efforts.

I have yet to discover an ad-hoc development team which met all five criteria, and most of them rarely meet two or three.

Further reading:

• Lean Development Governance
  
• Examining the Agile Manifesto
  
• Norm Kerth's Retrospectives Home Page
  
• Measured Capability Improvement Framework (MCIF)
  

Rational Agile Page

And now for some blatant advertising. ;-)

I just wanted to point out our agile development page to you as it contains links to a lot of interesting agile resources produced by the folks here at Rational. There's links to white paper, recorded web casts, and Rational's Agility@Scale poster. Short story is that the page is worth checking out.

- Scott