The Real Project Management Triangle

Posted on April 24, 2012 by Christopher R Goldsbury

As a project manager you’ve heard and seen this diagram too often in your career. It’s often said that project managers are responsible for delivering on scope, budget and schedule. In turn they are asked to ‘manage’ this.

But how does one do this? Answer: you don’t.

Scope, schedule, and budget are not managed. They are tracked to ascertain proximity to targeted objectives. What’s managed are the things that affect scope, schedule and budget. What are those?

1. Risks – Or the things that could go wrong or right. Threats and opportunities. A project manager that manages these well avoids trouble before it happens.

2. Issues – No one can see everything. In time issues will come up, and part of how well a project is managed is how quickly and completely issues can be addressed.

3. Expectations – grounding stakeholders in reality and guiding them to a course that makes business sense rounds off the rough edges of a project. It keeps everyone in alignment and makes issue resolution and risk mitigation easier.

So, while the PM is accountable for budget, scope and schedule; he/she makes a mistake by trying to ‘manage’ these. Seeking out the handles behind these indicators and using them to affect the outcome is what good project delivery is rooted upon.

A Caboodle of Pragilematic Posts

Posted on April 17, 2012 by Christopher R Goldsbury

I’ve been hanging out and posting at the ASPE SDLC blog. Yes…I have their permission to do that. Geesh. Check em out Gilbert:

Six Things To Avoid When Reporting Project Status – Project status is about the facts and your strategy to address and manage those facts.

This Daily Standup Is a Joke – This article details some challenges associated with daily stand-ups and some potential strategies for dealing with these.

An Axiom of Project Success – What’s the common thread to project success? We’ve seen projects that should have died. We’ve also seen projects fall apart that seemed like they were in the bag. This post attempts to nail the overriding factor.

That’s Great…But How Does Agile Benefit Our Shareholders? – Selling agile to key leaders in your organization takes more than just a thorough understanding of story points, and time-boxing. This post brings it home for those wanting a bigger bang for their agile swang. Whatever that means.

Stoos – Some Thoughts

Posted on January 24, 2012 by Christopher R Goldsbury

Much of what has been written about Stoos is nebulous. For those of us looking to latch onto something concrete….we’re left befuddled. Rather than a deliberate bullet list of actions; the Stoos group posted a wishy-washy communiqué that seems more like a summary of their meeting and a regurgitation of their personal feelings and war stories.

So what’s the point? Is there one?

References to the agile manifesto abound with Stoos. And like the agile group….they were meaningfully vague. In this lap dance of ideas it appears their point was just to get us all thinking again about how organizations work. Fair enough. Things start with questions and wonder-ings. Nothing wrong with that.

Perhaps the only shrivel of ideological meat that provided some sustenance for us definitive types was this from Jurgen Appelo:

For me the most concrete outcome is the core idea of seeing organizations as “learning networks of diverse individuals creating value”

This gets the wheels rolling a bit. Maybe he’s onto something here. Perhaps, with social media, mobility, and agile thinking its time for a new type of organization. A virtual one where human ingenuity is rewarded handsomely and it’s not about doing a job….but seeking, driving and growing value and profiting from it. Meaningfully.

Those of us who work on the virtual cube-o-sphere today know that it’s not about showing up 9-5 and pleasing a boss. If you’re a freelancer, 1099, contractor, inventor or entrepreneur you know it’s about finding your passion, networking and growing your value/brand. Traditional organizations define what you should do for a salary. Perhaps in the new Stoosian organization you define what you’ll do and share in the value it creates for the organization. We dump stability for growth and a life’s mission.

Is There a Better Way to Estimate Capital Projects?

Posted on January 23, 2012 by Christopher R Goldsbury

Introduction

“I don’t understand why you keep asking us to estimate the work. With all the time we’ve spent estimating we probably could have completed the first few requirements already. This is a waste of time!!” Ever heard something like this before? It comes across a little naive with regard to capital budgeting. But there’s a good point in the vehemence…. Waste.

In this article we’ll rethink estimation. We’re going to look at the machinery above estimation that catalyzes the need to predict effort and then propose a different way to target capital funding for projects.

Backgrounder

I don’t want to lose anyone here so I’m going to go over some basics of capital budgeting for internal use software projects and how that relates to estimating. If you know SOP98-1 already then skip to the next section. Estimating can seem like a game. At best it’s an educated attempt to predict the future using formulas and experience. At worst its a W.A.G. So why do we do it? It all starts with how we account for the expense of developing internal use software. Internally used software is classified, for accounting purposes, as a fixed, long term asset. In accounting speak: a capital expense. That means it can be purchased for a set price and has a useful life greater than 2 years. Capital expenses, like internally used software, can have their cost depreciated ( amortized ) over the useful life of the asset. What does that mean? It means that instead of realizing the entire cost of the custom software effort in one year…..you realize it over the useful life of the asset. So if we intended some custom built workflow system to last 5 years and the entire cost of the initial development effort was $312,333.04 then we’d ( in a simplistic amortization schedule ) realize, report $62,466.61 in expenses per year for 5 years on each annual income statement. Further the software’s depreciated cost would be listed as an asset on the corporate balance sheet each year until the full value had be amortized. The ying to the capital expenditure yang is the operating expenditure. Operating expenditures are incurred, realized as they are spent. There is no depreciation of cost. If I have $125,000.00 in operating expenditures this year then $125,000 in expenses shows up in the income statement. Operating expenditures are not considered assets and companies routinely seek to minimize their cost and flatten their growth. How do they do this? Well….one way is by investing in capital assets that can help increase productivity. So if I invest in some custom workflow system that will reduce the number of FTEs ( full time employees ) I need by 10% then that’s a potential long term realized gain in operating expense reduction: a.k.a. more profit for shareholders. Capital expense accounting can seem like magic if you’ve never heard of it before. But there’s a very real justification behind it. What is that? Simply put: if you’re capital asset increases profits each year after it’s implemented then those profits should be offset each year by the cost to develop that asset. Fundamentally, capitalization of IT expenses is an immense part of why companies invest so much in new technology. The accounting allows us to derive value from capital investments. Yes, technology is wonderful, but if internally used software expenses weren’t capitalized you’d see IT budgets shrink drastically.

Estimating

Awesome. So how does this relate to estimating the effort on a software project. Remember this line from above: That means it can be purchased for a set price and has a useful life greater than 2 years? A capital project is an investment or a series of investments. Knowing the price up front each year creates two things:

The funds needed to purchase that investment.
The cost basis to use in constructing a model of investment return.

Each of these capital investments are compared against each other using a % return ( IRR ) or more commonly using NPV ( Net Present Value ). Some are required and ‘must be done’. But the rest are optional. So leadership uses the projected investment return to determine which ones will benefit the company most. That becomes a short list of capital projects to fund for the fiscal year. Now, when these projects are initially compared developers may have been involved in the estimation process or they may not have been. But regardless the estimate is usually classified as a ROM ( Rough Order of Magnitude ). Once the project is funded another round of more detailed estimating occurs with the development team for the strict purpose of validating the ROM. If our detailed estimation shows we have inadequate funds then we need to make a decision: cancel the project or increase the investment. But if we increase the investment…how does that affect our return? Should we do a different project instead? You see where it’s going. Estimation is a fundamental part of determining the capital project landscape. It’s the basis for determining the initial and subsequent investment to achieve an estimated return. Software is just a means to the real end: increasing organizational productivity.

Capital Budgeting Hasn’t Kept up With Agile Practices

The astute among you will recognize how this financial model of capital budgeting doesn’t fit what you’re actually doing in agile software development. Big shock…right? Agile techniques are operational practices. They aren’t financial, business practices. Estimating each iteration using planning poker or whatever method has no applicability or affect on the overall investment. Just because the development team boosted the number of story points in the release…doesn’t mean someone magically added more money. Capital budgeting doesn’t take place every 2 weeks. It’s usually an annual event in corporations, although some companies will extend their capital planning for longer horizons ( 2 or 3 years ). Accounting is the architectural tool that builds business models. It runs in annual and quarterly cycles.

But It’s Wasteful

Ok, so back to the top. It may be fundamental to determining the annual capital project garden for XYZ Inc., but the estimates are usually inaccurate and they waste precious time in construction. Regardless of method…capital projects rarely hit their exact mark. This pushes many companies to see IT as a money pit to minimize. Isn’t there a better way for determining our cost basis for capital projects? Maybe one that doesn’t require us to estimate anything? Everything about capital budgeting is hard to change because it isn’t up to the company. It’s regulated by FASB. They define all these rules, and help to police them. The government recognizes FASB’s standards in lawsuits and for that reason they have the affect of law. Creative experimentation with accounting standards inside companies is something that people go to jail for. So change in accounting practices and standards is slow and carefully considered. After all you’re monkeying with the monetary machinery of global industry. There had better be a good reason for any change. So the next section proposes an idea for change to FASB’s capital budgeting rules. Do NOT exercise this idea in your company. There is no provision for this idea in FASB’s standards to my knowledge. I offer it up simply for conversation and debate….not actual practice.

Relative Targets

When we’re looking at capital projects we need to know the expected revenue ( or savings ) generated by the project after completion and the expenses ( investment ). Estimating, at least in IT land, deals mostly with the expense side. This is usually done in a very detailed fashion, but with relative targets I’m proposing we skip the estimation and just come up with a tolerance level. How does it work?

1. Determine your expected revenues ( or savings ) if the project is implemented.

2. Determine your return thresholds. There should be three. You could do this with NPV or IRR.

The return you’d ideally like to get.
The worst return you’d tolerate ( yes it can be negative ).
The middle ground between these.

3. Once you have these 3 thresholds you can then back calculate the capital requirements necessary to fulfill these return levels. We’ll work through an example in a moment. But here is the formula we’d use:

Formula to calculate investment for targeted NPV

C = NPV – ∑ R / ( 1 + r )

where

NPV = Targeted NPV
C = Investment required to reach targeted NPV
R = Revenue realized in each period
r = discount rate

4. Next you’d do a gut check. Can we really do this project for anyone of the calculated capital thresholds identified? If we can’t…then we shelve the project. If we can then we would setup 3 tranches of capital per project correlating to the thresholds. You’d start off by shooting for the ideal return scenario. If that didn’t work…you’d make a decision to move on to the middle ground threshold or cancel the project and expense the loss. The same would occur for the worst case return.

Example

So let’s say we have a project that we know will generate the following savings in years 1, 2 and 3. Year 0 is our capital investment and what we’re trying to solve for.

Year             Cash Flow
0 $???,???
1                  $200,000
2                  $300,000
3                  $200,000

Ok, so we know our estimated benefits from doing this project. Now we need to figure our our three thresholds for year 0 capital funding. Ideally we want to maximize our benefit. So let’s say in consultation with the business we determine that these are our NPV thresholds:

The return you’d ideally like to get: The most ideal return would be one that requires no investment at all and we receive the present value of the expected benefits – $580,015.02. But this is unrealistic. It does, however, give us an upper boundary to our ideal return. So we’ll say that a more realistic ideal scenario is $400,000.00 in NPV.
The worst return you’d tolerate: This could be negative. Maybe you’re willing to lose money to get this software project completed. Good examples would be where there is a regulatory requirement associated with completing the project. In this example we’ll say that the worst return we’re willing to tolerate is $100.000.00. This is above zero, but shows that we’re looking for some monetary benefit.
The middle ground between these: I’ll just take the average between these two…..$250,000.00.

Great…now we just plug these values back into our formula to derive the initial maximum investment allowed to hit each threshold. We’ll use 10% as our discount rate.

Ideal Investment:

$400,000 – ($200,000/(1.10 ) + $300,000/(1.10²) + $200,000/(1.10³)) = -$180,015.02

This says that the most ideal return would require for our investment to not exceed $180,015.02.

Worst Case

$100,000 – ($200,000/(1.10 ) + $300,000/(1.10²) + $200,000/(1.10³)) = -$480,015.02.

This says that to achieve the worst investment return tolerable the investment must not exceed $480,015.02.

Middle Ground:

$250,000 – ($200,000/(1.10 ) + $300,000/(1.10²) + $200,000/(1.10³)) = -$330,015.02

Here we believe that to get a return of $250,000 we’ll need to make sure our investment does not exceed $330,015.02.

Now that we have our tolerances we can do a gut check and see how realistic it is to complete the project based on each level of funding: $180,015.02, $330,015.02, and $480,015.02….or anywhere between them.

If our gut check tells us we can complete this project then we’d fund the tranches and start on the project. If not then we’d drop this project altogether.

Summary

Relative targets take us out of the game of detailed estimating and instead push us to delivery within some tolerances. This is a more natural way to manage a risky endeavour and affords us some built in cushion that everyone agrees is acceptable to the business’ needs. We also pre-build fault tolerances, trigger points that force us to reflect on the project’s viability. Here I suggest that there should be three of these tolerances, but there’s nothing preventing a company from setting up 4,5, or 10.

What Techniques Do You Use Most To Deliver?

Posted on December 20, 2011 by Christopher R Goldsbury

The poll is multiple choice, and you can add your own too.

2012 Predictions

Posted on December 19, 2011 by Christopher R Goldsbury

Here’s some of my 2012 predictions, ok…. guesses:

1. Real Options will become a bigger part of planning software and application development projects. Unlike other projects we’re not discounting a straight stream of cash flows. We’re discounting a complicated tree of decisions.

2. Scrum Will Breakup – The forces that made it popular will rip it apart.

3. Agile’s Luster Becomes Rustier – The torrent of zealous marketing and hype will take its toll on agile. There will be increased backlash and doubt through 2012.

4. The Kanban Rock Will be Turned Over – Executives will look into Kanban for software development and ask “Where’s the value here?”

5. Managed Service Providers Will Enter Software Development – Utilizing contingent labor available through sites like Guru.com they’re finding ways to drive down the costs of software development for cheap, simple, fixed bid projects.

6. Agile 2.0 Bandwagon – The agile 2.0 proponents will attempt to reboot life into the “movement”.

7. Startups get faster, leaner – Driving towards continuous, high quality delivery…some startups will take Eric Ries Lean Startup philosophy further and push tool vendors, or even create their own tools.

8. Tools Start To Takeover – We may have stretched the limits of new practices and patterns. Time for the tools crowd to take over? NoSQL and the rejection of OOD&D as too complex for most development efforts may yield simpler higher quality tools.

I never can seem to round out my lists to 10. How do other writers do that? Oh well. See you in the new year. 🙂

Santa’s Workshop Goes Agile!

Posted on December 9, 2011 by Christopher R Goldsbury

Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production. Santa sighted a number of reasons for the change, among them:

Increasing need to be first to market against growing competition.
Better collaboration between kids’ toy lists and toy developers.
Reducing the risk that kids don’t get what they want.
Increasing quality and accountability in toy development and delivery.

According to Santa, “We’ve analyzed this decision for some time and it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year. Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”

The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.

When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum. It’s well known, proven, and being used in some isolated corners of our workshop today.” Some muted ‘boos’ could be heard from the audience.

Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later. That development confirmed for some that Rudolph was next in line to take over The North Pole. Rudolph was on hand to comment to reporters after the announcement:

“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players. Look, what’s important here is that we get to done. I have a nose for this kind of thing. I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away. But, one step at a time. I expect we’ll have a more detailed plan in May or April. Talk to me then.”

Reactions among the North Pole elves was varied. One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision. He wasn’t on board at all. Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it. When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies. Then the Yeti put his foot down. I think Santa knew what that meant.”

Others, like a younger elf woman, had a different opinion on the switch to agile: “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum? I mean….from what I read XP is way better and more applicable to our environment. I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”

Still another view was held by Donner, “What about Kanban? No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there. I think there’s going to be a power play here between Santa and Rudolph. It’s a battle that’s been brewing for centuries.”

“Give me a break. Agile? Really, let’s knock off the buzz and hype. So we goof up on a few thousand toys out of the billions we make a year. How’s agile gonna solve that? I don’t get it. I guess I’ll ride it out and see where this goes. But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands. I don’t think that’s what Santa wants.” said Blitzen.

Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.

Mrs. Claus had this to say: “Rudolph is very bright. I know he’ll make this work. He knows where he’s going.”

Strangely, the Yeti, was not present. But his footprint could be found in the comments that others made.

Outsiders also came to hear the announcement. The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow. He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others. His competitors have real advantages in local sourcing, customer relationship management, and technology. Santa just hasn’t kept up and now it’s time for a radical change. I don’t think anything he’s doing is going to change our approach. We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”

The Easter Goose has the other 1.8% of the Easter market.

Merry Christmas agile community. Enjoy your holidays, stay safe, and as always….take care. 😉

Stop Agilizing Everything

Posted on November 4, 2011 by Christopher R Goldsbury

Introduction

Agile universities, certifications, agile consulting, traveling coaches, planning poker card sets, agile software products, agile modeling, agile arm bands, countless agile books and the crazed cycle of agile conferences.

WTF????

The buzz cycle is in overdrive and it’s electrocuted the business world with the promise of faster, better and cheaper. This article is a plea to stop. Stop all the hype, the opportunistic profiting, and the marketing.

Good Intentions Turned Ugly

What started out as a challenge to the software development community to think outside the box ( invent, create ), abandon a one size fits all model to approaching software development and execute your projects in a pragmatic fashion that takes account of the context you’re working in….has turned into a marketing machine of horrible dimensions.

There was a time when people talked agile and you knew they were on the vanguard; trying to solve the real problems. They cared. They were passionate, deliberate, and informed. Now, when you hear a colleague professing agile…they’re most likely drinking the kool-aid poured by the snake-oil agile coach from Denver or San Fran. The formulaic response to the core problems is all too familiar and draining:

Poor Requirements – You need user stories and iterations.
Defects in Software – Continuous integration and TDD will solve that.
Bad estimation – Use planning poker. It always works.
Change Management – Break it up into iterations and embrace the changes given in iteration reviews.

I’m not knocking these techniques. Many are novel inventions that do have their place in SD/AD. But instead of being offered as potential options, patterns, techniques to solving a problem among many other potential solutions; they have become a sales pitch by the opportunist preying on desperate CIOs. Buyer beware. Bubbles pop and my gut says the needle to prick this balloon is getting very sharp and close.

Let’s stop agilizing everything. Good ideas, tools, and techniques don’t need the word ‘agile’ pre or post fixed to be worthwhile.

Come Back Home

So turn off the scrum-o-matic. Wipe the agile makeup from your face, and put the kanban sequin dress away. There are still problems to solve. We haven’t unraveled this thing called software development. It’s devilishly vexing and we need good minds focused on it. Become neo-software-amish, come back home to the forest of software trolls and invent/create again.

Software Feature Dilution

Posted on October 16, 2011 by Christopher R Goldsbury

Introduction

Business analysts, requirements managers, and project managers will find the greatest interest in this article.

Software Product Planning

It occurred to me last week during one of our weekly iteration planning sessions that one of the most esoteric methods around product planning is deciding which requirements to turn into software features. The more rigorous approaches look at the cost of the feature, the potential impact to ROI ( assuming there is one ), and the demand.

What’s wrong with this approach is that it considers the features and resulting requirements in isolation from one another. By not considering how each new feature affects the existing product as a whole teams can and do end up with products in which the original feature set, that made the software successful, become diluted. Those of you who’ve worked with me know my favorite example is CA’s Remedy product, but I think one could find other examples: the Microsoft Office suite of products may be in this camp.

Feature Dilution: A Formula

So how would one go about constructing a measurement for feature dilution? First – some assumptions:

You know or can retrieve the cost associated with the original marketable software release.
You know or can calculate the benefit ( ROI ) for the original marketable software release.
You have an estimated cost and benefit associated with any potential new software features.

Ok, so knowing these let’s construct a model for software feature dilution. We’ll adapt a formula from the world of finance.

V – Value of sofware after Feature dilution =

((O x OP) +(N x (∑ IP1, IP2….IPn))) / (O + N)

where…….

O = original number of features

OP = Current NPV of product ( could use ROI too )

N = number of new features to be added

IP1, IP2, IPn = NPV of each new feature.

If you run this formula through some examples in time what you’ll find is that as a product matures new features need to continually generate greater returns to justify value to the original product and ultimately diluting the existing feature set.

This is exactly what should happen if we want to avoid the fate of an overly complex and unmanageable software product. Just like stock market share dilution the product management team needs to justify that further feature dilution will grow the value of the product in terms of existing functionality…..not just that it will add to revenue.

Summary

Simplicity in software design has always been something great software architects knew yielded great products. With this formula I hope I have provided at least a start to measuring simplicity in software.

I’m Skeptical on Agile – Sell Me

Posted on October 16, 2011 by Christopher R Goldsbury

Introduction

This article will address a common reaction to those presented with the possibility of adopting agile in their enterprise: skepticism. CIOs, application development managers, directors, and senior architects will glean the greatest insight from this but development professionals and project managers will find interest too.

On Being Skeptical

As a software professional your skepticism is not necessarily misplaced. There are plenty of agile coaches in the market today professing to deliver faster, better, and cheaper on a regular basis. Their message is honey in the ears of the right executive. It becomes even sweeter when you consider the economic climate that many businesses are facing today. There is opportunism here and it would be well advised to vet any agile coach.

How do I know an agile coach is worth the money?

I’ve devised a simple matrix ( below ) to help guide one in validating an agile coach.

	Weight	Coach 1	Coach 2	Coach 3	Coach 1 Score	Coach 2 Score	Coach 3 Score
Number of Projects Managed	3	2	17	3	6	51	9
Years of experience in SD/AD	2	5	24	7	10	48	14
Highest Budget Management Experience ( 1 = true, 0 = false )	1	1	1	0	1	1	0
Number of References Validated	3	3	8	1	9	24	3
CSM Certification ( 1 = true , 0 = false )	1	1	1	1	1	1	1
PMP Certification ( 1 = true , 0 = false )	1	0	1	1	0	1	1

FINAL SCORE					27	126	28

So let’s talk through this matrix a bit. First, I give pretty heavy weighting to experience here. In truth we’re not just looking for an agile coach we’re looking for someone with the battle scars of being in the AD/SD world and knowing when and where agile works vs more predictive methods.

We also want to know that they’ve actually implemented agile methods in other places hence the need for validating references. The key word here is “implemented”. There are plenty of folks who can regurgitate the agile manifesto and paraphrase the thinking of leading agile theorists, but agile coaches should show a track record of making it happen.

Budgetary management experience, in my opinion, is essential. If they haven’t managed the dollars/euros/yen around a capital project ( or operating costs ) then they may have a very misguided notion of why projects succeed or fail. The CSM or PMP who was merely accountable for a timeline with only a misty concept of how it related to money is ill-equipped to profess a transformation of your SDLC process. Why? Agile techniques profess delivering software in iterative cycles ( every 2 weeks ). If some level of requirements aren’t complete by the end of each iteration you have two options on a fixed bid capital effort:

Don’t do that functionality.
Postpone it until you do have the capital available.

This sounds fine in theory, but the truth is that every system has some minimal set of requirements that must be completed for the software to be functionally usable. If the money runs about before the agile projects succeeds in delivering this minimal functionality then your project will be seen as a failure.

Certifications show learning of theory. I weight them low, but still think its practical to have these ( Certified Scrum Master and Project Management Professional ) if an agile coach is selling himself as a professional in software development delivery. They should understand and know agile as well as more traditional management concepts and techniques.

Lastly, you should realize that agile adoption is not just a function of the agile coach. The organization needs to be willing and able to accept the changes agility will introduce.

But my current process works, so why should I switch to agile?

If you have a working process and there is no immediate need to push you to agile then you should take the time to map out a strategy for your development shop. Agile can be beneficial and Ryan Martens at RallySoft does a decent job of articulating when agile methods can benefit a development project. His rendition of the Uncertainty vs Complexity diagram proposed in Stand Back and Deliver gives an AD manager a basic tool for plotting his/her projects along these two broad metrics.

project-types

What are the benefits if agile is applied to the right type of projects?

Better Risk Mitigation – Agile methods emphasize iterative delivery of software. A standard cadence and check point to the project sponsors allows for defects, requirements misunderstanding, and general issues surrounding the effort to be mitigated on a timely basis. Couple this with a daily stand up meeting where team members determine how to resolve issues and coordinate work and risks to the development effort are generally better managed.

Testing starts earlier – Agile development emphasizes vertically slicing your application and developing functionality incrementally. This is a technical challenge, but assuming the development team can tier the system architecture this way, then your testers can usually start functional testing much earlier in the development cycle.

Increased Sponsor Satisfaction – Project sponsors are involved routinely through agile. The developers have a direct line to the customers. This continuous feedback loop usually leads to better communication and understanding between the team and customer.

Stronger Team Accountability – It takes time, but as the team culture shifts from command and control to a collaborative effort where developers take responsibility, collectively, for their work; the team begins to see how their efforts help/hinder the project. An adjunct to this is an increased sense of pride in their work and kinship with each other.

What do I need to watch out for when adopting agile?

Cultural Shift – This can’t be under weighted. Agile places greater emphasis on the team managing itself and its day to day activities. Subtly, agile preaches two things:

1. Development team and customer working together. Meaning other managers and IT leadership have a de-emphasized role. Your risking attrition by some of your better players if you ignore this. Proper coaching and preparation for this change and its effect on roles and responsibilities is essential.

2. Team stepping up and coordinating activities among it’s members. This is normally done by a PM or Dev manager or even a senior technical leader. Some methodologies, like Scrum, emphasize a new role ( scrum master ) to take on the facilitation aspects. For developers unaccustomed or uncomfortable with organizing and planning this may be difficult.

“Documentation is not needed” – You may hear this from some agile coaches and theorists. The original agile manifesto emphasizes working code over documentation, but as a development professional you’ll need to decide if this really makes sense for your project. Some of us have regulatory and legal reasons for documentation.

Dogmatic Views – I wrote about some of this in Bad Attitudes of Agile, but some team members will see agile as a very strict set of practices and may twist the theories and methodologies to suit their own ends. By its very description agile is meant to be a flexible approach to software and application development not a rigid set of rules that cannot be altered. There are the pragmatic agilists and then there are the agile zealots. Watch out for the latter.

Summary

Benefits can accrue from agile methods. These benefits, for the right projects, should result in better quality, reduced cost and schedule variance associated with requirements misunderstanding and defect management, and a more complimentary relationship with your customers. As mentioned earlier skepticism is not misplaced, but by looking for an opportune experimental project to introduce agile a development manager can assess its applicability for his/her shop.