Custom Built Software Is a Depreciating Asset

Custom built software.  It occurred to me this week that this ‘asset’ as it’s categorized by GAAP is a depreciating asset, much like a car or piece of capital equipment ( machinery ).

Does it derive value?  Yes….indirectly.  But ultimately it’s value is underutilized, and quickly de-valued.

Imperfect as it is…there is little alternative….FOR NOW.   So what’s the best strategy for investing in this ‘asset’?

Minimize it.  The less you put in.  The less you lose.

Find the cheapest way to accomplish your custom software needs and invest in that first.  Any other investment strategy invites disappointment, and reduced expectations in the future.  This strategy, however stark, also recognizes the truth…..big things start small and simple.

Prove it out with a minimal project and then decide whether additional value could be derived.

Advertisements

Getting to Success Instead of Getting to Done

Projects are about getting things done…right?

Uh-Uh.

They’re unique, collaborative, human efforts endeavored to achieve success.  Success is can be defined with certain goals.  Success has a point, a place we reach and can say “Ah-ha!….we did it!”.   There’s a finish line.  Done, on the other hand, is never done.  Excuse the pun.  And the rhyme.

Done is an endless backlog.

Done is a never ending series of requests.

Done is code that’s never perfect.

Done is test cases that still need to be refined.

The fog of “Done” can envelop the project and the minds of our teams.  It obscures the truth.  We’re not looking to get everything “done”.  We’re looking to succeed.  Within success there is room for variation on “done”.

Stop Agilizing Everything

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.

I’m Skeptical on Agile – Sell Me

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.

Agile or Waterfall — Aren’t We Just Struggling With Requirements Understanding?

Who is this article for?

All software development professionals will find interest in this article, but those managing, crafting or analyzing requirements may find the most interest.

Introduction

Why is so much ceremony needed around software development?  Regardless of the methodology there is a great deal of meeting, clarifying, verifying, demonstrating, and checking.   If you came from another planet and watched how we develop software you’d come to the conclusion that we don’t know how to communicate complex abstract ideas into concrete reality.  And we don’t. To be sure, we’ve tried:  detailed specifications, UML diagrams, use cases, user stories, and just plain discussion.  All of these are incremental changes to a better requirements landscape, but fleshing out our software needs still takes considerable time and effort.

Process and Methodology as Requirements Risk Mitigation

BDUF ( Big Design Up Front ) was the waterfall method to define requirements.   It was a way of saying….”Let’s get everything straight BEFORE we start the expensive process of coding and testing all this.”    It’s logical, but makes the broad assumption that people will know what they want and deviation from the initial plan will be minimal.   There are some projects where this is a very safe assumption, but not always.

Agile capitalized on this fault and said “You can’t know everything up front, so just get started and course correct along the way.”   Does this mean that agile projects always succeed? No.  It means that they allow adaptation to change.  Projects where innovation is important or where the product owner is unfamiliar with developing software naturally make good candidates with Agile.  But its pricey and if you don’t need all the involvement…..then going back to waterfall might be a good option.

With both methodologies you see an attempt to address the real problem:  understanding and materializing requirements so that we get exactly what we want.   The abstract nature of software means we’re collectively imagining what it could and should be.  But we haven’t found a silver bullet for this type of collective dreaming.

Communicating and interpreting our desires is not as easy as it seems.  Some of us are good at drawing pictures…..but most of us aren’t.  To mitigate the possibility that we’re not going in the right direction we’ve invented these elaborate software processes ( Waterfall & Agile …..and the pragmatic others ) to keep our collective minds on the same path to vision creation.

Are  There Better Ways?

Even with these processes we still end up in projects where we hear these things said:

“Oh…that’s not what I meant.  It should do this…”

“No, no,no….you didn’t understand what I was saying. “

“That wasn’t the requirement.  Read it again….I built what was asked for.”

“Yes. I know she said that….but what she really meant was…”

So, software requirements are still an error prone bottle neck in producing the product.  If we hope to make software development better;  then we must get better at this.  In paraphrasing Eliyahu Goldratt in The Goal: You can only run as fast as your slowest player.  That player for software is requirements gathering, analysis, understanding and verification.

Looking outside our field, other industries, who’ve been around longer and develop complex systems too, have similar challenges.  What do they do?

Design –  My wife is a talented contract graphic designer for a local St. Louis firm called Kuhlmann-Leavitt.  They’ve won many awards and have very satisfied customers.  All this despite the nebulous, subjective nature of graphic and three dimensional design.   How do they do it?  The design field is interesting.  They don’t estimate anything.  They simply ask that you hire them for your artistic work and set a budget.  They’ll do the best design work they can for that money.  No more, no less.   So right away the budget issue is taken out of the picture.  Lastly, they don’t ask for detailed requirements,  just some idea of what you’re looking for.  You’re not hiring Kuhlmann-Leavitt to build.  You’re hiring them to create.  My bolding hints at the nuance.  Considerable authority and autonomy is given to the designers.  This is just expected.  Software development relies much more heavily on ‘domain experts’.

Manufacturing – In the manufacturing world BDUF could be rewritten to be MDUF ( Massive Design Up Front ).  Not only is the product designed way up front and in detail, but the process and mechanisms to build the product, which aren’t always the same, are designed up front too.  Before the real product even undergoes one production run…many small demo runs are carried out.  The results are stunning.  Once the product starts rolling off the assembly line its produced to exacting tolerances.  It mostly fits the requirements of marketing and can be replicated thousands of times over.

Construction – We’re talking about unique, one of kind construction here.  Not production line assembly of a subdivision.  This one-off building is, to my mind, the most similar to software.  Some requirements come from regulations and building codes.  Others come from the purchaser of the structure.  There are multiple stakeholders.  Requirements are digested, and then artifacts are created.  A series of mock-ups are assembled and based on this a cost estimate is created.  Even with all the up-front planning there are always “gotchas” and changes that are thrown into the project.

In all three of these examples the end product is visual and intuitive which helps with requirements understanding.  A picture really is worth a thousand words.  Software, as workflow, data and creative design is more abstract.  We’re trying to craft ideas and concepts into something that is somewhat tangible.  Certainly the user interface can be mocked in a similar way and there is great value that comes from the discussions around this, but a sufficiently detailed workflow and data set always serve to vex our attempts to provide clarity to requirements.

What’s next?  What can we do?

Here’s part of our problem:

1. We discuss the first iteration of requirements with our product owners.  The person leading that discussion is gifted in facilitating this.

2. From this meeting, the requirements are crafted into user stories.

See it?  We just lost all the context, emotion, body language, nuance, and reactions by everyone else by drafting something into writing.  I don’t care how good a writer you are…you can’t replicate the requirements conversation.  So why do we try?

The next problem comes when you ask each person to interpret the written user stories.  Hopefully each team member was present for the conversation so they could somewhat remember what transpired.  But, even with attendance, the human memory is frail and human perceptions, bias and concentration vary. Each person may see and read the requirements slightly different.  In short there are too many lenses.

Rather than try to abstract requirement conversations into another form ( writing ) or create even more abstract artifacts ( UML, Use Cases ) we should seek to record them via video, photographs of whiteboard drawings, and publishing all this to some kind of requirements wiki or blog.  Doing this for each iteration review, iteration planning, or project meeting would surely capture a much more complete document of the project’s scope, changes, stakeholder motives and historical background.  Further, it would exist in perpetuity for future developers to watch……just like a movie or project documentary.

Summary

I do realize that the suggestion to move towards requirements documentaries may be fraught with organizational, legal, and other challenges.  I would never suggest that change on this scale is easy.   But I do believe there is productivity savings to be found here.  As I hinted in Decline of Written Requirements  I think we’re using 20th century tools and techniques to gather and analyze requirements in a 21st century world.  To lessen the need for process mitigation of requirements risk we may need to refocus and leverage our new tools: cell phone cameras,  high quality digital video, wikis, and blogs.

To Succeed Quickly = Fail Fast and Often

Loved this article and thought I’d put in my blog/tweet it out.  My take away?  Forget about success and failure….just try stuff, have fun, and learn/grow.  You don’t control all the variables anyway.  Focusing on gaining experience, contacts, and ideas.

http://www.theatlantic.com/business/archive/2011/08/the-5-secrets-of-silicon-valley/242958/

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.