The Coming Breakup of Scrum

Introduction

Scrum, probably the most widely adopted agile software development practice, is cracking up.  The signs are evident and this article discusses the trend and what it means for agilists today.  If you practice scrum, are thinking of using it, or have used it in the past you’ll find interest in this article.

Oh yeah?  Prove it!!!

It’s a truism that rapid growth and popularity put a strain on organizations, movements, ideas…….or ,more fundamentally, the people comprising these very human vehicles.  As an idea ferments and then exponentially amplifies to encompass a wider politic of devotees and admirers there is the impending fog of dissent with the origin, the core.  From this comes splintering, debate and eventually more novelty and innovation.

Fine, but what about direct evidence for the rift in scrum?

03/05/2009 – Scrum But…Test.  Jeff Sutherland.

09/15/2009 – Ken Schwaber resigns from Scrum Alliance

06/15/2010 – Ken Schwaber establishes Scrum.org

04/20/2011 – The CSM certification wars

07/26/2011 – Forrester calls Water-Scrum-Fall the norm

08/02/2011 – Bloggers Suggesting Scrum Variations

10/06/2011 – Scrum Extensions announced – allowing modification to basic scrum.

As the agile movement hybridizes and evolves scrum is feeling the brunt of this pain. The forces of hybridization are ripping scrum into distinct camps whose views are aligned with their respective organizational needs.  Who are these camps and what will ultimately happen to scrum as this spider web is tugged from it’s anchors?

The Camps

The Enterprise – Most enterprises don’t build software as a core part of their operations.  Projects here are usually centered on delivering some base set of functionality for a fairly fixed price.  Stability and low cost of operation are prized.  The organization doesn’t usually see this as an investment…but as an expense to be managed and tracked.  The pressures enterprise software development groups face at the capital planning phase and the release phase have sculpted the Water-Scrum-Fall that’s prevalent.

The Software Companies –  In contrast to the enterprise, software companies build software as their core product.  It *IS* their operation.  Software companies see their products as an investment and it’s life cycle is fairly unlimited, or at least tied to the life-cycle of the company.  Pure scrum works in  these companies fairly well.  There’s usually still pressure to reduce the number of production releases but on the planning side managing features in a backlog fashion is workable, even preferable when you have a product that has a potentially unlimited lifespan.

The Startups – Startups face a different set of pressures from their venture capital investors.  The need to rapidly introduce new features and create value to customers and investors by gaining a competitive advantage quickly is paramount.  Startups are tearing scrum towards the Lean Startup methodology professed by Eric Ries.   The focus here is continuous delivery of new software: stability be damned.  Usually these startups don’t build software that’s mission critical or life threatening.

The Purist Methodologists – Among these are the various scrum trainers, agile coaches and general agile philosophers who profess a puritanical approach to scrum.  Their insistence on a dogmatic approach to scrum are rooted less in practice and more in theory.

What are they doing to scrum…where are they taking it?

These groups are doing what’s natural.  They’re catering scrum to their practice and profession of application life-cycle management ( ALM ).  But this tug of war for scrum’s future is changing it.  Instead of a simple, one-size fits all methodology, it’s becoming a framework of patterns & practices.

You can see this through the introduction of scrum extensions, which is a natural way of recognizing the various groups that have adopted scrum in some fashion.  With scrum becoming an umbrella concept, it’s importance is melting away.  It will devolve and eventually disappear. Instead the extensions, much like design patterns in software development, become the value added pieces that development teams will use and rally around.  Each camp will likely pool certain extensions, patterns as their ‘methodology’.   In time, these flavors of scrum will tear it completely apart.

Summary

Scrum’s popularity will likely be its undoing.  But is this something to be avoided or stopped?  Hardly.  Hybridization and evolution of scrum is a natural process that is both pragmatic and necessary.  Jeff and Ken’s baby is growing up and leaving the agile house.  The original agile manifesto signatories accomplished their mission; they broke the one size fits all ALM world down.  The new heterogeneous landscape of practices and patterns, while less clean than the bi-polar world of agile vs waterfall, is primed with greater opportunity for innovation.

Development Shop Productivity – Should You Outsource?

Introduction

CIOs, executives and development managers will find the most interest in this article.  We’ll focus on a productivity measure for custom software development and how it may help you justify outsourcing your software development shop.

The Problem

How do you justify outsourcing your development shop when you know the immediate cost savings may not be there?  The trend toward mega-software development outsourcing shops isn’t slowing down.  But the gains to Fortune 500 enterprises are not always immediate.  You’re gut says it to you every day:  “It’s better to let someone else do this.  We just aren’t good at developing our own systems.  The bugs, the time, the bad requirements…”  But, how do you justify your gut?

A Formula to Measure Your Progress

I’ll skip past all the BS on the benefits and costs of outsourcing.  You can look these up with Gartner, About.com or some independent analyst’s site.  What I will present is a new formula for measuring your custom development shop value and tracking it relative to an outsourced effort.

Here’s the formula:

Custom Development Value Added = CDVA
Capital Dollars Invested = C
Operating Dollars Invested = O
Return on Investment from any completed projects  = NPV
Hours spent gathering & defining requirments = ReqH
Hours spent fixing bugs = BugH
Hours spent addressing help desk tickets = TickH
Hours invested in training = TrainH
Hours of Time Off = OffH

CDVA = ((C + O) - NPV ) / (( ReqH + BugH + TickH ) - ( TrainH + OffH ))

Let’s talk through it.  CDVA is your development shop’s productivity. The first thing you’ll want to do is baseline this for your current shop over a year and then determine how it compares to any outsourcer’s proposal.

The numerator in the equation represents your financial investment in custom development.  The denominator represents labor expended relative to this investment.

So over time you want to see your CDVA increase regardless of your outsourcing decision.  If the trend goes down or stays stagnant then it’s time to seek improvement.  There are some diminishing returns here, and you may need to make periodic investments to see greater value added later on.  But the point should be clear; we’re measuring the return on our development shop’s productivity overall….rather than on a project by project basis ( which can be very misleading ).

You determine the periodicity, but measuring this at every fiscal month makes sense to my inner accountant.

You might ask why I chose measuring hours around bugs, requirements, and trouble tickets and not the overall development effort? Well….experience tells me these are the areas with the greatest variability and also the areas where expertise and experience shine.  Those who are good at software and application development can do so with minimal bugs, less requirements analysis and their end product typically needs very little support ( I can see some CIOs smiling right now ).

Summary

Outsourcing is like any business venture and may require some upfront investment to see returns over time.  But, while this is intuitive it isn’t always measured in a consistent way that takes account of key development metrics like bug counts, support tickets, and requirements time.  Hopefully this article presents a way to do just that.  Enterprise IT is under increasing cost pressures and given the historical waste and loss associated with custom application development it only makes sense to look at outsourcing vendors who have the focus, experience, expertise, and clout to deliver.  Now IT executives may have a measure to justify and track that or at least show their shop is improving.  😉

How Will Tablets Impact Your IT Strategy?

Introduction

Gartner recently unveiled the top trends that enterprise IT should be strategically focused on.  One of those is the growing use of tablets in the work environment.   This post will take a look at the implications of increased tablet and smart phone use in the enterprise and hopefully deliver some insight into this trend beyond just a capacity replacement strategy for PCs and laptops.

Implications of Tablets and Smart Phones in the Enterprise

Let’s skip the obvious background and trend information and launch straight into the implications.

1. Printer exit strategy – Think of tablets as electronic paper.  That’s one of their utilities. Plenty of technology gurus have struggled to manifest using technology in lieu of paper only to be vexed by the utility, versatility and permanence of the 8.5 X 11 parchment of industry. So what’s different this time?  Portability, usability and eventually….sharing.  Right now it’s a little cumbersome to share notes, reports, and other virtual-papyrus artifacts with everyone in a room.  It’d be nice if my tablet recognized all those other tablets in the meeting auto-magic-ally and allowed me to share documents with them with little more than a button click.  A kind of permanent “LiveMeeting” or “WebEx” with RFID/GPS type sensory to recognize my location relative to the meeting schedule for that room.  It’s not there yet, but you can see it coming.

That alone won’t shut down your printers and get rid of the reams of stock in your office closet. Nor will it stop “Ed” at IKON solutions from frequenting your micro printing press to unclog the jam of a decade.  It will take you, the CIO, pushing, selling and implementing a bold strategy:  get rid of them.  All of them.  I’m talking about your printers.  People won’t stop using printers unless they’re gone.  Once they’re out of reach….they’ll find, and use the alternatives.

If you’re Hewlett Packard or Lexmark,  yesterday would have be a very good time to rethink your business model.  Kodak is foreshadowing you.  Tablets will get thinner, more collaborative, increasingly better at power utilization, and super cheap.

2. Embrace video/audio recording – Does anyone else see the paradox in someone with a tablet typing or writing meeting notes on his device when it’s fully capable of recording the visual/audio representation of that discussion?  Tablets and other devices can transform how your organization captures information and knowledge and shares that with others.  Written/readable documents don’t go away, but moving an organization toward a video/audio strategy should improve the quality of your work.  So much context is lost in written notes, documents, requirements, and emails.  How much does that quality cost?

Go with this strategy and here’s what changes:

  • A premium on presentation and verbal communication skills becomes essential.
  • This strategy augments your move to paperless ( number one above )
  • You need more storage and network bandwidth to capture all the videos / photos / audios:  think cloud here.
  • A tool to version, track and search this knowledge will be essential.  A wiki makes an ideal candidate.
  • Digital video and editing skills are now a key requisite on resumes.
  • Corporate policies need to be rewritten.
  • You might want to invest in pico projectors for everyone, but I think eventually tablet and laptop makers will make this a standard feature.

3. From office to work lounge –  Look at your desk/cubicle.  If you’re mobile and paperless…why do you need this space?   Work places are still relevant.  Collaboration and communication happen best in a common physical environment.  Working from home is like working in a really thick cubicle.  But to encourage the freedom and interaction that mobility and paperless bring to the office, the furniture and interior should be living, playful and open.  Many employers have already made this move:  mobile whiteboards, open touch down areas, couches, plants, and open space with lots of natural air are some of the interior elements that seem to work well for a work lounge.

The implication of work lounges and the increased interaction is that work is not work anymore.  People aren’t laborers, they’re….well….people.   Work, fun,  friends, co-workers, ideas, and profits will begin to blend.  This poses some challenges to stodgy HR policies and Tayloristic views of management.  Those who’ll succeed in this environment will be leaders, not managers and the org chart will flow around them in an organic way.   Corporate empire builders beware.

4. Office supplies / telecommunication equipment reduction –  In addition to dropping your printers and paper supplies you can now chuck your sticky notes, paper clips,  desk phones, and almost everything else in that closet.   Again, if you keep it around people will use it.  If you dump it, then they’ll get creative and use the tools they have.  Force the change.  Be the leader and save the company money.

Office Depot, Staples and others should plan their exit strategy.  Maybe they begin selling the work lounge concept and the supplies for that.  To date, I see little evidence they *get* this.

5. Killer App Coming……Plan for it -> Intersection of Identity / NFC – An earthquake is coming to the landscape of identity and access management.  Check out my earlier articles on this for background.  Your mobile device is an abstraction of you.  People will come into your employment with their credentials and data already digitized and ready to be transferred and used in your environment.  You’ll pull this data from LinkedIn, Facebook or Google+…….and using those same tools you can give them rights/permissions to systems on your cloud.    Kaboom!

In time this destroys internal LDAP systems, multiple id and password issues,  corporate HR systems and physical security access control.  These will be thrown into a social mobile nfc blender and become the domain of mega vendors.   The tech war to control the identity market will have no comparison to previous epic battles.  Those who scale this out will capture the lucrative enterprise IT market.

The implications are vast and will touch every corner of the enterprise IT market.  Plan for this NFC hurricane to shake out vendors through 2012-2013.   You’ll want to embrace those software vendors that do NFC, cloud and social identities for access.  My prediction?  Microsoft’s collapse is right around the corner.

6. Build vs Buy vs…….Download for Free.  The implication of app markets is that you now have a third generic system strategy:  download for free.   Any options analysis for system planning should consider this.   While it hasn’t happened yet, that i know of, we could well see a big vendor crash as a freely available mobile app does the approximate functionality for none of the cost.

The download for free option should also be used as a development strategy.  Maybe you find something that ‘kind of meets’ your needs.  Download, play, experiment, trial and get a feel for it.   Then, approach the developers of that app and say you have some ideas to improve it.  They might do it for free.

App markets are consumerization of IT writ large.  Our work force will be our IT department, and our IT department will turn into technology strategists, gurus, enterprise architects.  High caliber, well paid business technology talent will replace the ‘system analysts’ of today and IT departments will shrink.  Invest in your best.

7. Email’s days are numbered – Email gave us a huge productivity boost in the 90s.  Indeed it was the killer app of the first internet explosion.  But as we’ve moved through time its weaknesses are costing us.  The loss of context in email, as apposed to physical presence undermines quality of work.   Mis-understandings, multiple interpretation, cultural differences and poor writing lead to *email threads* that are a semiphore of poor quality.  Think ,just for a second, how many issues you deal with daily that revolve around clarifying what someone meant in a cetain email?   It’s astounding and it’s holding us all back.

There’s a better way, but it hasn’t been built yet.  Google’s Wave initiative is a bold attempt at remaking communications tools.   It’s close, but the email replacement will incorporate the cameras, microphones, and NFC chips that are built into tablets and smart devices.

Any CIO will want to watch this space and price out the latent, untapped potential cost savings in boosting communications quality across the enterprise.  Combine this vision with implication #5 above, and you can see the scale of change coming towards us.

8. POS industry: look out you’re about to be remade –  Tablets can be turned into POS terminals.  Enough said.  If you’re a POS vendor and you don’t realize this: what in the name of clam chowder have you been doing the last 2 years?  With NFC in 2012 an avalanche of slim, mobile terminals will usher in tap-pay while still accepting swipe pay.

Cash and checks will be digitized too and while the exact shakeout is still fuzzy to me; private digital currencies ( Ven, BitCoins ) are going to play a role here.  As I professed in my article about the externet ( internet of things ), the combination of an amorphous, unaccountable virtual world and the ability to pay with a tap lower and free the barriers to entry for those enterprising enough to believe they can challenge the global fiat currency oligarchy.  Nation states, banks, and the overlords of international finance will surely capitalize on this opportunity in some way.  Watch my blog for future posts on this….I’m still noodling on it.

9. Healthcare – Goodbye clipboard, hello iPad.  It’s all over the place, and doctors and nurses are demanding that all their software tools run on tablets.  FINALLY technology understands healthcare’s unique needs.  God bless Steve Jobs and the Apple-neers.  Steve, this was truly your greatest gift to the world…..not the iPhone.   You’ve given doctors a tool that will help them treat and solve the very problem that took you from us too early.  Rest in peace.

Taking this further, digitizing medical records and sharing that with patients is the bonfire lit by the meaningful use regulations passed in 2009.  NFC, smart devices and tablets will make the sharing part real time and collaborative.  People will really know and understand their health.

Summary

Surfing the waves of enterprise tablet integration has great possibility for the visionary C-level executive.  Will you be one of them?   My consultation to you:  tear up your current IT strategy document and vest your talent with the authority and energy to make these nine implications happen.   If you don’t…your competitors will.  You can be sure that some of the finest minds in IT are reading and following this blog.  Numbers don’t lie.  Be part of the revolution rather than a victim of it.

Agile Finance – Story Point Cost

Who is this article is for?

This article is written for those with management and budgetary responsibilities for a software development project or team. Others, including developers, quality assurance personnel, and CEOs/CIOs may find interest.

Why would we need to estimate story point cost?

Story points are used to estimate work. Investment in that work is expected to derive some benefit. If that benefit is expected to be financial then understanding the cost of that work is essential to deriving any meaningful ROI. Even if no ROI is expected and the intended benefit is regulatory compliance ( as an example ) then company leadership usually wants to understand what how much of their limited financial resources is going towards any specific feature, iteration, or release.

How do we do it?

The technique presented here is a historical parametric approach. It relies on past data from previous projects. So, one has to have some of this data saved up before a reliable figure can be derived.

RC = Total dollar cost for a historical releases in a product

RSP = Total story points that contributed to that release.

RSPC = Release Story Point Cost

RSPC = RC/RSP

Once you have this for one release you should calculate it for all historical releases. The next calculation is an average:

Average RSPC per product = ∑ RSPC¹, RSPC²……..RSPCⁿ / N

If you want the story point cost across all products then average it again. Although, for most planning purposes it’s useful to plan by product line and this higher level of abstraction of cost might be too watered down.

What questions does this help answer?

  1. How much will it cost to add this feature?
  2. How much will it cost to deliver release 2.1.0 ?
  3. What is the cost of an average iteration?

How often should it be updated?

The astute among you will notice that we’re using historical data. Historical data is only accurate as long as change doesn’t take place. To counteract the shift and change in time size, capability, and mix one needs to do these calculations at regular intervals. How often? This is a judgement call. I do it monthly as I’m in rapidly growing team with many new products popping up. I constantly need to reassess my cost driver.

A more stable team and product might require only 6 month intervals. The relevant point here is; keep it accurate.

Summary

Story point cost ties a rather abstract and developer centered concept to the real world of business. This is necessary. If we intend to use story points in a meaningful fashion in our development environments than they must have some corollary to the spreadsheets, and ledgers that the world’s businesses run on.

Why Does Agile Adoption Fail In Some Organizations?

Introduction

How often do you hear that a company attempting to adopt agile practices fails?  This article attempts to examine and explain the often overlooked key organizational reasons that agile fails, why it isn’t obvious to most of us and some potential strategies for coping with organizational impediments.  The article’s target audience is managers with budgetary responsibility although technical groups might also find interest.

Historical Perspective on Agile

Where did agile practices originate and why? The Agile Manifesto was originated by a group of software developers.  Their main pupose in creating a new software development methodology was to address some of the core problems with traditional waterfall techniques, specifically: risk around changing requirements, late feedback from quality assurance, and accountability of the development staff.  Their focus was not on how this methodology worked with the budgeting and financial aspects of a funded development effort.  In the information technology world there are two types of funding models.  One is a large  company that sees the software product as its bread and butter or at least a key differentiator for its business model ( think Oracle, or Scotttrade ). We’ll call this company X.  The other model is a company whose development effort it not critical for their overall business model and  the resulting funding is a fixed bid.  This is company Y.

Why is this important?

The answer lies in how the development effort is viewed by company X and Y financially.  In company X the software development effort is viewed as an investment, indeed the primary investment, in the company’s future.  In company Y the development effort is a small application and is viewed as an expense to be time bound and tracked.  In company X the team is funded.  In company Y the project is funded.  Read those last two sentences again.

In company X agile will succeed.  In company Y agile will fail.

In a fixed bid development effort the software development is intended to end at some point. Securing funding for the project requires that you define it up front, estimate it, resource it, develop it, test it, implement it, and then turn it over to support.  This is company Y.

In a time and materials funding scenario the company determines it has need for a software development team as there are many projects that require development well into the future.  An estimate of how big a development team they can afford is created for the budgetary time frame (1 year, 2 years), it is resourced, and then project scoping and scheduling are done.  This is company X.

See the difference?  In company X there will always be software development.  There is no end and the team is funded with that intention.  So putting that work in a backlog, prioritizing it, and estimating and reviewing it in time boxed iterations makes sense.

In company Y the effort can only afford to be funded for some subset of the budgetary period (say 3 months).  After that there is no more money or the company is unwilling to allocate additional money.  They don’t want a long term development team because they can’t afford it and besides there wouldn’t be enough development work to keep them busy anyway.  So deep controls and strong project management is required to ensure that something is delivered in that 3 month period.

Viewed this way…..financially, agile is a luxury.  It assumes that you’ll always have a software team and there will always be development work.  It assumes you’re team is funded year after year and you, as a manager, don’t have to worry about funding individual projects.  As an agile manager you’re primarily concerned with schedule, scope and capacity.  Budgets are an annual or bi-annual thing.  You flex up or down depending on the economic realities facing the company.  The criteria for success are largely centered on functionality delivered over time.

In company Y you might have $50,000.00 that is set aside to complete you’re project in 3 months.  Budgeting and expense tracking are critical and will determine whether the project is a success or not.  A manager here gets funding on a project level at various times throughout the capital cycle.  You may deliver all functionality on time and over budget, but that won’t be seen as a successful project.  As a manager in this company you are concerned with all 3 legs of the iron triangle.  Your team is likely temporary and staffed by contractor labor. Adoption of agile in this situation is a mistake…..even superficially. Why?

Estimation

The key lies in estimation.

In an agile software team you don’t estimate your work till right before you begin.  And you only estimate, in the case of scrum, the next iterations work. So how do you know how long it will take?  You don’t.  Furthermore, you really don’t care.  You’ll continue to deliver functionality every iteration.  As soon as product management and QA say you have a good enough product; it’ll be released as a production version.   You might have a guess, but until the team estimates it….you really don’t know long it will take.

In a fixed bid situation….your estimation needs to take place up front.  The company is asking you how much it will cost to build the application because they are unwilling to fund it forever.  They want it to end…….preferably sooner rather than later.  Funds are limited and your project, although perhaps necessary, is not viewed as critical to the company’s future.  Its ROI may even be negative.  Returning to the leadership of this company with the answer; “I’m not sure how long it will take….just fund the team for a year and we’ll see how it goes every iteration”  would be a mistake that would likely result in your dismissal.

In the 2nd scenario, if I told the team, after securing funding and hiring them, “we’re using scrum”: they’d estimate the work the next iteration. They would assume their estimates would be taken seriously and you’d give them time to complete the work as it unfolds regardless of whether their estimates fit your original project funding or not.  That’s only fair.  Unfortunately, that puts you as the manager in the uncomfortable position of submitting budget/schedule variances and/or cutting scope when you’re original estimate is proven to be inaccurate.  Hence, you’ve failed at managing the project and therefore…….”this agile thing doesn’t work”.

The mistake was to assume the company’s leadership understood and was organizationally committed to scrum and agile principles.  The mere fact that they are asking you to estimate the funding you’ll need to complete the project tells us otherwise.  If they had asked us, “How much does it cost to fund a software development team for the next 3 years?”  Then we’d be wise to approach it from an agile perspective.

The Real Problem

So, what is the real problem with agile adoption in organizations?  It can be boiled down to these points:

  • Agile assumes that the company wants a long term software development effort not a short term project.
  • Agile is often assumed by company leadership to be a development process with no impact on budgeting.  This is not the case.
  • Development teams assume leadership understands the implications of adopting agile at the budgetary level.

The complexity of these points can’t be underweighted.  Developers and development teams often have zero visibility into budgeting so they are unaware of how their agile efforts are being accounted for in monetary terms.  This is evident in so many agile articles on the web.  Likewise, management is often ignorant of development and specifically agile development practices.  Agile adoption requires education to ease the clash and misunderstanding of these two worlds.

So what are some of the consequences of attempting to adopt agile practices on a fixed bid project…essentially laying an agile façade over the waterfall project?

Story Points

Story points are often used on agile teams to determine the complexity of the work being done.  The number of points completed each iteration determines their velocity ( points per iteration ) and gives management an approximation on how much work can be completed in a given iteration.

If you come from a fixed bid shop like company Y your immediate question is, “How does this relate to hours?  How do I project costs and ROI?”  Truthfully, it doesn’t.  It isn’t intended to.  Again, the agilist is assuming you’re funding a software development team not a software development project.

In company X you could estimate things by hamburgers or cigarettes in each iteration.  It doesn’t matter.  You’re going to get the product done at some point ( +/-  functionality requested ).  The only real question is at what point to do we call it complete and release it to production.  Funding for the team is not contingent on estimation of effort.

In company Y project funding is directly related to estimation of effort.  It is critical that we tie this to time because our cost driver is often an hourly rate. Story points have no meaning here.

Scrum master vs PM

“Agile does away with the need for a project manager.”  Ever heard this before?  It’s scary for traditional PMs and unintentionally threatening.  However, it is correct.  If you assume that a team is funded year after year regardless of projected effort then the needs for organizing and managing the development effort are more centered on technical leadership, task and risk management.  Timelines and budgets go out the door. A scrum master is sufficient, preferable for getting the job done.

However, if you’re in a non-agile situation, like company Y….then traditional PM practices are not only valid, but essential to making sure the effort is kept within budgetary and schedule tolerances.  In this situation the leader of the development effort is being entrusted with precious company resources that can’t be wasted and needs to have the skills of a CEO-Lite.

A funded development team does change the project manager role.  A fixed bid project does not.

Daily Stand Up Meetings

Agile uses daily stand up meetings for a variety of reasons: motivation, risk mitigation, status, accountability, team building, etc.  It’s a good idea that is equally at home on a fixed bid waterfall project.  There is no reason this practice can’t continue to be used, but the team on that fixed bid effort has to realize that you’re not really doing agile and there is a deadline looming.  You also might want to weigh the time needs.  The daily stand ups should be short, but 15 minutes a day adds up when you only have 3 months of funding.

Iteration Reviews

With fully funded software teams that use agile the question of when something is done is answered incrementally.  Functionality is reviewed at the end of each iteration ( say 30 days ) and evaluated for readiness for production release.  Again, this is a good idea that could still be used in a fixed bid situation, but the business owners need to be coached to understand the iteration review as a risk mitigation and accountability technique and not a demonstration of the completed product.

Iteration Planning

Iteration planning really does assume you’re using agile in a team funded scenario.  It necessitates your costs are known and fixed for the budgetary cycle and that any estimates the team comes up with won’t play havoc with your budget.  Doing iteration planning in a fixed bid situation will almost certainly result in confusion, budget variances, and/or loss of functionality.

Burn Down Charts

Burn down charts show the progress of completing functionality in a given iteration.  They are a measure of team performance over time.  They do not illustrate how close the project is to completion.  If we were to sum all of them up…..they might show this, but given that they are usually used strictly for the development effort of a project; this won’t always be the case.

In fixed bid scenarios the question is not usually one of how much functionality the team is doing per time period.  It really doesn’t matter.  They need to get all the functionality done within the time frame that the money allows.

So using burn down charts and iterations in a fixed bid project sends the wrong signal to the team and your customers.

Summary

Firstly I would suggest that trying to adopt agile in a fixed bid scenario/project funded situation is not recommended.  Instead, as a manager, you should make the assessment of whether the company can support an agile practice/fully staffed development team through time.  If the company can; then you should use agile…it works well.  If the company can’t….then you’d be wise to stick with traditional project management practices.

If you determine that your company has the resources and the workload to support a software development effort but isn’t using agile then it comes down to convincing the leadership that agile makes sense for this effort.  Put on your change management and sales hats….you’ll need them.

Secondly, project manager and scrum master are not static roles and titles.  In one company a PM/SM may have budgetary responsibilities. In another they may not.  In some they may have direct reports in a traditional organizational structure.  In another the structure may be more matrixed and the PM/SM might have no direct reports.  I mention these differences because agile articles, like all writing, is written from the viewpoint of the author.  Too often what worked in one situation is attributed to being a superior process or technique…….when in actuality the organization and roles fit the process and technique.  Change the roles and organization and it might not work as well.  Context is often missing in the agile vs waterfall blogosphere.

Lastly, the agile debate is often likened to a philosophical war.  But from my experience and vantage the confusion is largely an outgrowth of misunderstanding.  Too often a technical manager hasn’t thought through the business implications of adopting agile.  Likewise business folks frequently misunderstand agile as being ‘some development thing’ with no relevance to how they just funded the effort.  I’ve been fortunate in my career to walk across the bridge of misunderstanding and see both sides.  Doing this has given me insight into the background budgetary assumptions that so frequently go unrecognized as the cause for agile adoption failure.