Stuck on Velocity...

Okay... so it seems I am a little stuck on velocity this week. Maybe with one more post I can get this out of my system and move on to other topics. Let's talk a little more about what velocity is, what it is not, and how it should best be used by a project team.

Traditional Estimating

Most projects I worked on prior to discovering agile would start with a long list of requirements. The project manager would reach out to each of the resource managers for an estimate. These estimates would be done in real hours and used to calculate how many people were needed for the project, and by extension, how much the project would cost. In my experience, the business almost never liked the estimate, and would always ask us to do something to lower the cost.

As a project manager, I would go back to the resource managers and start the negotiation process. The most extreme example of this I ever participated in lasted almost four months. We negotiated scope, tried to do a bunch of up front design work, made assumptions about the project, and were finally able to cut the estimate down by about 50%. The funny thing was, I had been largely negotiating with each manager individually, and none of them really had much understanding about how the other managers were thinking about solving the problem. Their estimates were fundamentally out of sync.

We literally spent four months, and a bunch of valuable time from critical resources, haggling over a number (that at the end of day) turned out to be total fiction. The reality was that we had no idea how big the project would actually be. Furthermore, we had no idea which team members would actually be doing the work, so coming up with a reliable end date was nearly impossible. The only thing we could do was create a project plan, with the estimates we had available, and hope for the best.

Agile Estimating

Agile teams do estimate projects but use mechanisms that reflect the uncertainty inherent in the process. You have probably heard about the idea of story points and planning poker. This is one of the most common methods of agile estimating but not the only method. The general idea behind agile estimating is that you start by identifying a small, relatively understood requirement and assign it an arbitrary value of one (1). Each feature in your product backlog is evaluated against the well understood requirement. We ask ourselves, as a team, do we think the new requirement is 2x, 3x, or 5x more complicated than the one we are comparing it against?

The first requirement gets a point value of 1, the next requirement might get a point value of 3, while a third requirement might get a point value of 5; all based on the team's understanding of the relative complexity of each feature.

At this point, we have the size of the backlog in points, but it doesn't really tell us anything. Since points do not equate to hours, we still don't know how long the project is going to take. Some teams will do detailed estimating on the first few features to get a general idea of the size of each backlog item, but we really won't know how many points we are able to build each iteration until we start building them.

This is where velocity comes in.

The product owner prioritizes the features based on business value, the team gets to weigh in based on technical complexity and risk. Collectively, the team sets the build order of the features and gets busy writing software. Each iteration, the team will deliver some number of features, and keep track of the point values assigned to each item. The sum total of all the point values, associated will all completed features, is the team's velocity. It is fundamentally a measure of the team's throughput iteration over iteration.

Because we know the overall size of the backlog (in story points) and how many of the features the team can build each iteration (in story points), we are able to calculate when the project will be completed:

Iterations to Complete = Backlog Size/Points per Iteration

The key concept here is that traditional estimating almost never results in a reliable project cost indicator. Only by building working software in short cycles, and measuring our progress, will we have the necessary information to know how long the project is going to take. If you didn't read my last post on progressive estimating, this might be a good time to go back and take a look. Because we won't know how much we can do, until we actually start doing it, we might have to insert a few checkpoints where the business gets to recalibrate the project or decide to pull the plug.

The traditional view of velocity is that it is specific to the team that is doing the estimate. One team might give a feature three (3) points while the next team might estimate the same feature at a five (5). As long as the team doing the estimate is the one doing the work, this is not a problem. Remember, points are estimates of relative complexity... of relative size. The actual value does not matter. The only thing I care about is the team's throughput against the overall size of their backlog. It is the only thing I need to know to determine if my project is progressing according to plan.

Normalizing Velocity

That said... what happens if I have many teams that are working together to deliver a large, complex project. If one team calls a feature a three (3), and the next team calls a similar feature a ten (10), it might get difficult to communicate performance on the overall initiative. The team that uses the larger point values would obscure the performance of the team with the smaller point values.

To answer this question, I have seen many teams normalize a point to a common unit of measure. For example, my team will often think of a point as a single person day. We are still using lightweight estimating techniques, we just use the normalization value as a starting point for conversation. This approach can level the playing field and enhance communication between teams that are working on various parts of the same initiative.

While this normalization can have benefit on large scale agile implementations, there is some risk.

As soon as we start equating a point to a standard unit of time, we start trying to do math on velocity. The discussion usually starts by asking how we can improve the velocity of the team. Well... if the team has four people that can deliver 20 points per iteration, we could add a fifth person and increase velocity to 25. Or maybe... we find that the same team of four is only delivering 17 points per iteration. We want to know what those deadbeats were doing with my missing three points of capacity.

My personal opinion is that it is perfectly okay to normalize velocity across teams. As managers, we need to recognize what velocity is measuring... and what it is not measuring. Velocity is measuring throughput against an abstract estimate, it is not measuring productivity... and certainly not time spent on task. It is very common to see situations where the point estimate was 20, the detailed estimate was 25, the actual hours spent was 30, and the features delivered was 15. The team can use these numbers to get more consistent estimates, but again... all I care about as a manager is throughput and how I can help the team improve over time.

Even in an environment where we are normalizing velocity, there are many factors that can contribute to velocity variations between teams. Team size is an obvious consideration, but what about skillset and experience? We should consider team chemistry... we should ask if the team dependent on other organizations to get their stuff done. Maybe they've encountered impediments that have slowed their progress. This is all stuff that contributes to team velocity.

I coach teams to measure velocity so we can measure what is... to get honest information about how the project is progressing... then look to the other factors to determine how to make it better. The last thing we want to do is to inadvertently incent the team to manipulate the numbers to make the data look good.

Subscribe to this blog Subscribe to Leading Agile

Progressive Estimation and Tollgates

Kelly Waters from All About Agile picked up on my post yesterday about project velocity. Kelly made a great point about how we can use a toll-gate approach for estimation and project funding.

Here is Kelly's comment:

In some methodologies - for example RUP - there is an initial stage of the project ("inception") to do some high level scoping before seeking approval for full funding. It's also quite common in waterfall projects to complete the reuirements analysis before going on to request full funding. In these cases, only the initial stages need to be funded and then the team knows more by the time they ask for the rest of the money.

This is an essential concept for large scale agile development, and here is why.... coherent software architecture, UX and UI design, and requirements are not going to just emerge from multiple small teams working independently on a significant, enterprise level initiative. Without some degree of lightweight, up-front planning (to integrate the activities of several teams working together) it is unlikely that we will converge on a well integrated product.

Schwaber talks about this when he talks about iteration 0. Leffingwell talks about this when he refers to an architectural runway. In my opinion, these guys are dancing around the idea of Inception and Elaboration. This almost has to be done because RUP is such an unpopular topic in the agile community... otherwise people tune out. Ambler is more direct explaining these concepts when he talks about the Agile Unified Process.

By introducing these higher order agile concepts, we can help teams learn to effectively structure large scale agile implementations, and furthermore, help teams understand what decisions need to made and when... from both a busines and a technical perspective. A year or so ago I did a post called the Agile Heart of the Unified Process (back when this blog had no subscribers whatsoever).

Rather than reinvent the wheel, I am going to grab some text from that article and update with some commentary to tie back to Kelly's original comments... the text in bold was added today.

Inception

The goal of Inception is to minimize business risk. This means that you have to understand the vision for what you are trying to create, have a high level understanding of the requirements, and have defined the characteristics of the systems architecture you intend to build.

Begin Inception with a single Scrum team. The team should at a minimum have a ScrumMaster, a Product Owner, an Analyst, a Quality expert, and an Architect. The product backlog will include the features necessary to create the Vision, Use Case Inventory, and Candidate Architecture. It may be necessary to include features in the Inception backlog that prove key aspects of the business vision.

Inception is the least code focused of all the RUP phases. This is due to the requirement to have an idea of where you are going before you begin the project. Since Inception is the least focused on creating working software, and without working software the team is not mitigating risk, it is in the team's best interest to make decisions quickly and get on with the business of delivering working software.

At the end of Inception, there is a business decision that must be made. Do we have a strong enough product vision, and a strong enough architectural vision, to fund the next increment of product development. This is a good time to reestimate the backlog and decide if the value proposition of the project still holds.

Elaboration

The goal of Elaboration is to minimize technical risk. This involves choosing the smallest subset of features that will prove out the significant technical assumptions made during Inception. At the end of Elaboration, the system should be fully functional with the subset of features you have chosen to build. The system should be fully tested and the team should be confident that the architecture is stable.

During Elaboration, you may still have a single Scrum team. It is likely that you will add several more senior level technical folks to help begin building the system. The product backlog includes the features necessary to prove the application architecture and to deliver any non-functional components required to build out the system. It is important that the Elaboration backlog contain features the team will need to collaborate at scale. Source control, build environments, automated testing infrastructure, instant messaging, and collaboration software should not be overlooked when preparing to scale an Agile team.

At the end of Elaboration, we have another business decision. Have we built enough of the application to validate our technical assumptions. Can we move forward with the project, scale into multiple agile teams, and move forward with confidence we have a workable and proven solution? This is the next point where you need to reestimate the backlog. After proving the solution, updating the backlog, reestimating based in what we have learned, do we have a business case for moving forward?

Construction

The goal of Construction is to mitigate logistical risk. This is where the bulk of the software is created and where the Agile team really begins to scale. The core team that helped build the foundation of the system during Elaboration is broken up to seed the newly created Scrums. Each team is organized around a major component of the architecture or a significant feature set within the overall scope. Each team is a complete cross-functional entity that is responsible for delivering its part of the system. These teams are coordinated by a master team that includes a more senior ScrumMaster, Architect, its own technical staff, and the Technical Leads and/or ScrumMasters from the component teams.

At this stage, the backlog is completely feature driven, progress is extremely measureable, and the teams are focused on delivering the bulk of the business value to the customer. As is true during every phase, the code delivered at the end of each Construction iteration is fully tested and integrated with the rest of the system.

Construction is the most like the prototypical agile project as described in most of the common literature. We have several independent feature teams working in concert. Each is tracking velocity and burndown and making product adjustments as necessary to converge into a solution that delivers the most business value possible. The business is involved actively assessing progress iteration over iteration deciding when enough of the product has been built to take the solution to market.

Transition

This phase deals with training and hand-off to the customer, final user testing, and resolving any issues that were not caught earlier in the process.

During this phase, the team should be able to scale back down to a single cross-functional team or two. The backlog is related to the remaining documentation, training, and defect resolution features remaining to get the product in the hands of the customers.

I think of transition like many talk about hardening iterations. This is the place where we clean up anything leftover. If we need any final user acceptance, doc work... whatever, this is where it goes. We are asking our customers if they are ready to accept the project deliverables.

Subscribe to this blog Subscribe to Leading Agile

Some Thoughts on Project Velocity

Companies I work with desperately want reliable estimates.

In reality, they need them so they can run their business. Businesses really want a crystal ball to look out into the future... to know pretty much what they are going to get, when they are going to get it, and some idea of what it is going to cost. The problem is that they need this information when approving projects... when making commitments to the market... and this is when we have the least reliable information about what we are building.

This need can result in pretty bad behavior on the part of both management and teams. To gain some sense of certainty, management does things like ask teams to provide estimates in real hours... and then hold the team accountable for delivering exactly according to that estimate. Faced with an impossible situation, teams are incented to game the numbers. They overestimate the project (to provide some necessary buffer) thus resulting in overinflated budgets. All this leads to a total lack of trust on both sides.

Velocity is intended to bridge the gap between management and the team. Teams get to measure project scope in relative units such as story points. Point estimates are specific to the team and measure how big one feature is relative to another in the backlog. Teams then begin building the features and measure how much of the backlog they are able to complete every iteration. After a few iterations, the team should have a pretty good idea how long it will take to complete the project.

Iterations to Complete = Backlog Size/Points per Iteration

For this equation to work, for velocity to be a meaningful metric, it has to be predictable... past performance must at some point become indicator of future performance.

Furthermore, velocity is only relevant to the business if we have a decent understanding of the overall scope of the project. That means we have to have a meaningful view into the backlog... for at least the upcoming release... sometimes the entire project. Measuring velocity against a constantly changing backlog doesn't give me a whole lot of information. If we are going to have any idea of what done looks like at the project level, we need to understand both backlog size and velocity... and understand how these metrics might change over time.

Velocity is fundamentally a measure of team throughput. How fast are we able to go... iteration over iteration... against a relatively stable queue of product features. These two metrics are the only thing standing between an agile team and total choas... at least when it comes to overall project performance.

To make all this work... both sides have to do their part. Ask not what your agile project can do for you... ask what you can do for your agile project. Here are a few thoughts on what managers and teams can keep in mind to keep velocity a reliable indicator of project performance... and maybe build a little trust while we are at it.

Responsibilities of Management

Realize that estimates are just that, estimates. As management, we can expect that estimate should get better over time, but what we get early... even in story points... is likely to change. We need to be prepared to deal with change.

Management should only use metrics like velocity as an indicator of project health and to help guide the project into a successful outcome. If management uses velocity as a lever or a performance metric, people will game the system to make the numbers look right. You'll get the numbers you want, you might just not get the product you want.

The size of the backlog has to be stable or the project is out of control. We can't just keep changing our minds indefinitely. We want to defer as many decisions, as long as possible, but we need to have a fundamental understanding of the product we are building and why. Constant churn will slow the team down and make everybody frustrated.

Responsibilities of the Team

Estimates are just that estimates. That said, we are accountable for making them better over time. At some point we have to be able to tell the business what they are going to get and when they are going to get it.

As team members we have to realize that our velocity must stabilize. Stable velocity is the life-blood of a predicable agile team. If we can't stabilize our velocity, the business will always see our project as out of control... because it is. We cannot expect the business to continue to invest never knowing what they can expect to be delivered.

We have to be honest with ourselves and our customers about what it really means to be done at the end of an iteration. Gaming the system to make the numbers look right will kill a project... hiding undone work in future iterations doesn't help either.

For Further Reading:

A little more on the idea of uncertainty and the reality of progressive estimating:
http://blog.softwarearchitecture.com/2008/03/progressive-refinement-of-estimates-aka.html

Some of my thoughts on team accountability and the need to accommodate change:
http://www.leadingagile.com/2009/01/what-about-accountability.html
http://www.leadingagile.com/2008/07/delivering-value.html

Subscribe to this blog Subscribe to Leading Agile

Meet me in Las Vegas

My Agile PMP talk got picked up by SQE's Better Software conference so it looks like I am heading to Las Vegas this summer. If you are going to be in town for the conference, look me up and come see my talk. Everything gets kicked off on June 8th so start making your plans now, this should be a great event! If you need more information on the conference, click here to visit the Better Software conference website.

The Abstract:

The Agile PMP®: Teaching an Old Dog New Tricks

Agile methods emphasize trust, empowerment, and collaboration—moving us away from command and control project management to harness the passion, creativity, and enthusiasm of the team. In established organizations, success with agile practices hinges on how well traditional project managers adopt new ways of thinking about project structure and control. Building on the principles of the Project Management Body of Knowledge (PMBOK®), Mike explores how PMPs with experience in traditional development can adapt their styles and practices to become effective agile project leaders. Mike tackles the hidden assumptions behind the PMBOK and explores agile approaches for managing time, cost, and scope. Taking an in-depth look at PMI Processes and Knowledge areas, he also explores ways to adapt them to agile projects. Project managers, business analysts, and other stakeholders will leave with a new way of thinking about project management practices within the agile context and new tools for delivering value in the face of uncertainty.

PMP® and PMBOK® are registered trademarks of the Project Management Institute

Mike's Bio:

Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining VersionOne, Mike was a senior project manager for CheckFree Corporation where he managed a portfolio of projects for their online banking and bill payment business unit. He has a background in traditional project management but has worked primarily with agile methodologies for the past four years. A certified PMP Project Manager and a Certified ScrumMaster, Mike co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. He was recently named an honorary member of the DSDM consortium.

Subscribe to this blog Subscribe to Leading Agile

Agile Doesn't Fix Anything

Hey... are you any of you guys out there contemplating going agile? Be warned. Agile doesn't fix anything. Seriously... if you have problems with your development organization, making the switch to agile WILL NOT fix anything.

Agile will actually do the opposite of fixing things... it will make them more broken. Teams with poor communication will communicate poorly more often. Developers that don't code well will break the build more often. Defects will be injected more frequently and quality issues will be everywhere.

While waterfall lets these problems hide, agile has them smack you right in the face.

Waterfall teams get a period of quiet because most everything early on is documentware. We don't actually have to deliver any working software. Even once we start building code, the heat doesn't really turn up until we are ready to integrate, and that could take months. Not until we hand everything over to QA, and find out the product doesn't work, does the crap really hit the fan.

We get to pretend nothing is wrong until it is too late to do anything about it.

Agile on the other hand is noisy and chaotic... it will bring all our problems to the surface early. It will seem like agile is causing the problems when it is merely pointing them out. Agile will force our reality upon us in a way that is going to get pretty uncomfortable. As project leaders, development managers, and especially team members... we have to be prepared to do the hard work ahead of us.

The easy part of agile is holding a sprint planning meeting and doing a daily scrum. Writing requirements as user stories is fine, but what happens at the end of our first sprint when none of them are actually done? What about when we get to the end of sprint three and our automated builds are still not working? What happens a few sprints later when QA still can't test anything?

These might have been some of the same problems that you thought agile was going to fix. Guess what, those problems are still there. The value is not that agile fixes your problems, but that you get to find out about them early... while you still have time to do something about them. It is still up to you to fix them.

So the title of this post... while provocative (sorry about that... two in one month) is true. Agile isn't going to fix anything. Agile WILL put you in a great position to identity those things that needed to be fixed anyway. Agile doesn't let anything hide, it forces us to get real about where we are vs. where we want to be. If you want to be successful, your organization will still have to deal with the broken stuff.

Our goal is to build great product... better, faster, and more reliably than our competition. To do that, we have to relentlessly pursue excellence and we must understand the gap between our current reality and where we need to be. While agile isn't going to fix anything for us, it can provide a way to see that gap and position us to do something about it.

Subscribe to this blog Subscribe to Leading Agile

What About Accountability?

One of my favorite lines ever was delivered to me by a pretty senior guy I was working with a few years back. I was pretty new to this whole agile thing and was struggling to understand how I could ever run a predictable project without my Gaant chart and a weekly status report. He said to me... look Mike, agile is about uncertainty... you just get what you get when you get it.

That was a far cry from how my teams had been operating in the past. I was more in favor of the line... you do what I tell you to do when I tell you to do it. That had always worked in the past and I really couldn't figure out why this situation was any different. In no way was I prepared to leave my project in the hands of a team that was unable to commit.

It's been a few years since that conversation, but I hear that sentiment echoed by many of the teams I've worked with since. Somehow, some of us in the agile community think that agile is about getting started and coding until you are done... with little planning in between. What happened to commitment? What happened to accountability?

Like most things in life, the truth lies in between these two perspectives. Agile is designed to deal with uncertainty. When uncertainty is part of the equation, no amount of up front planning is going to give us a plan impervious to change. On the other hand, moving forward with no planning is irresponsible. The business is entitled to have some idea of what they are going to get... and when they are going to get it.

After all, they are the ones paying the bills.. right?

The bridge between chaos and predictability is velocity. Velocity measures the throughput of the team. In other words, how much work they are able to get done iteration over iteration. I should probably go into more detail on velocity here but I am assuming you probably have been introduced to the concept. Click here if you need more info.

As an agile project manager, I don't really care about the units of velocity or even the actual number. That is specific to the team. What I do care about is that the number is useful. The team must be able to use that number to determine how much work they can do during the upcoming iteration. I also care about trends. Is the velocity increasing or decreasing. Have we centered around a specific number or is the metric varying widely iteration over iteration?

While ever increasing velocity is ideal... at a minimum I just need to be able to use past performance as an reliable indicator of future performance. It gives me insight into the health of the project.

Things brings me to my point about accountability.

An agile team is an empowered team. The team is empowered to do the estimate. The team can decide how much to bring into the iteration. The team can decide how the software is built. The team can decide how they organize themselves. The team can decide to break the work into tasks... they can decide not to. The team can decide who works on what.

The trade-off for all this empowerment is accountability. For agile to work, we need teams that can make and meet commitments. We need teams that are striving toward a stable velocity iteration over iteration. We need teams that value predictability. I am not going to tell the team what to do or how to do it, but they need to be able to deliver what they say they are going to deliver.

Period.

The team is accountable for knowing what they can do two weeks out... if we can't commit two weeks out, we are screwed.

Subscribe to this blog Subscribe to Leading Agile

Feelings, Thoughts, and Actions

Have you ever had to sit someone down and talk with them about their behavior. As a Dad I find myself having these conversations all the time. Son... I told you not to hit your brother. But Dad, he made me really angry.

To my kid, his feelings totally justify his behavior.

How about when you have to confront a team member about that heated altercation during the last retrospective? Bob... slamming your fist on the table was totally unacceptable behavior. But Mike, if I hear one more time that the build is late I am going to scream.

While there is clearly a relationship between how we feel, how we think, and how we respond... it is my opinion that our feelings NEVER actually justify our actions. Think about it, are we EVER entitled to get angry and punch someone? Are we EVER entitled to get our feelings hurt and lash out with a personal attack? Are we EVER entitled to treat others disrespectfully when we have been treated with disrespect? Even when it comes to positive emotions like love, affection, or friendship; our feelings must be tempered by our values and principles before we respond.

By understanding the right relationship between our feelings, thoughts, and actions we give ourselves the opportunity to choose how we want to behave. Knowing we have that choice gives us the opportunity to change. By understanding there is not an immutable link between our feelings and our actions, can work to decouple them. We can work to capture our feelings and break them down... we can understand them. We can become intentional about how we think and how we see the world around us. We can make a conscious decision to act in accordance with what is most important to us.

Validate Feelings

Feelings come from the deepest parts of ourselves... they are an integral part of who we are. While we may change how we feel over time, it is unlikely that anyone is going to coach them out of us. It is how we are wired. When coaching either my kids or my team members, I usually start by validating feelings. I know your brother made you mad, I would be mad too if he did that to me. By validating feelings you validate the individual and create the opportunity to learn in a non-threatening environment. It creates the opportunity to change how people think.

Guide Thinking

How we think can be influenced more directly... it is somehow less personal. We can learn about our environment and the people that are a part of our lives. We can gather more information about what motivates those around us and learn something about their intentions and circumstances. With new information, we can learn to think differently about what is happening to us. Why do you think your brother was annoying you? Maybe he felt lonely and wanted you to play with him. By guiding thinking, we are able to broaden the perspective of our team and create the opportunity to coach behavior.

Coach Action

We cannot be held accountable for how we feel... we cannot be held accountable for how we think. We can and will be held accountable for what we do. Our actions are governed by social and societal norms. Our behavior... our performance... can be measured and will form the basis for how others will evaluate us.

By thinking about problems differently, we open up a whole new range of possible options. Son, it is never acceptable to hit your brother. Maybe you could gently explain to your brother that you will play with him in a few minutes, or maybe you could include him in your game? Having more options available to us gives us more opportunities to behave in accordance with our values and principles.

When we decouple our feelings from our actions, we open up a broader palette of possible outcomes... outcomes not predicated by our emotions but based who we choose to be as human beings.

Photo Credit: http://happinessblog.com/wp-content/uploads/2007/11/slinky.jpg

Subscribe to this blog Subscribe to Leading Agile

Why Agile will Fail

It has taken a little time for me to get back in the swing of writing this year. While 2008 was great (seriously, would not have changed a thing), I just didn't realize how tired I was until I had some time off over the holidays. The past few months my life had accumulated the mental equivalent of technical debt. It was important for me to do some refactoring before I could start building out any new features ;-)

What do you think, quite a provocative title for my first post of the new year, huh? I had a few other ideas swirling around, and even started outlining a few over the past few weeks, but none seemed to materialize into a solid article. Sometimes you have to follow the muse and today's inspiration comes from a friend of mine here in the Atlanta area.

Yesterday, I read a great post by Dennis Stevens called "Business Technology is not about Technology". If you are not subscribed to Dennis' blog, I highly recommend that you do so. Dennis brings a great perspective on IT and business and how we can use agile as a means of delivering value in our organizations. The article yesterday made the case that businesses should not invest in technology, they should invest in solutions. That business technology is not the end game, but a means to achieve business goals, a means to profitably deliver value to customers.

Dennis talks about all the failed technologies that never quite lived up to their promise: ERP, CRM, SOA, and MDM. He makes the case that businesses invested in these technologies without first identifying their value creating work streams and how they needed to perform them differently in order to achieve their strategy. Their investments were more about implementing the technology than improving their core capabilities.

The article concludes by stating that responsible business technology discussions start with strategy and flow into operating objectives and finally into improvement projects. Technology can enable those objectives and help improve the processes, but the hard work to identify value generating work streams needs to be done first. The technology is never the silver bullet.

My takeaway from Dennis' article was that anytime you deploy a technology you better have a clear understanding of how that technology is going to enable your value generating business processes. If you don't... you have doomed the initiative to failure. Why? The technology by itself does not solve your problem. The proper application of the technology to optimize your most critical value streams is what will solve your problems.

So... what does this have to do with agile software development.

As I was reading Dennis' article, I couldn't help letting my mind drift to development and project management methodology. Dennis' point about understanding value streams and technology could be equally applied to our discussion here of agile development practices... just replace the challenges with ERP and SOA with a discussion of Waterfall, RUP, and Agile.

Just like SOA, Agile will fail because most companies don't first identify those value streams that are critical for profitably generating value for our businesses. We focus more on deploying agile when we should be focused on the problems that agile is trying to solve. We look at agile as a silver bullet rather than an enabler of a well defined business strategy to optimize our critical improvement projects.

Does your business really care if your team is transitioning to agile or continues to do waterfall?

What your business really wants is to deliver value to market faster than their competitors. They want more responsiveness to market conditions and the ability to change their minds when they get new information. They want lower project costs and more predictability in their project portfolios. Unless your agile transition is delivering on these key business drivers, what does this mean for your agile change initiative?

What it means is that just like with SOA and ERP or any of the others, the marketing initiative called Agile will fail. It will fail because it never lived up to the promise and was never able to deliver the value the business hoped to achieve.

That said... with or without a marketing initiative called SOA, good software architects will continue to build systems around services. Likewise, with or without a marketing initiative called Agile, good project teams will continue to deliver software iteratively and incrementally. Good project teams will continue to respect people and give them what they need to be successful. When faced with the need to change, good teams will continue to leverage lightweight processes that allow for inspection and adaptation.

While Agile might fail, and we might not call what we do Agile or Scrum or XP, the ability to be agile will remain a key differentiating factor of high performing teams!

Subscribe to this blog Subscribe to Leading Agile