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.

Advertisements

Software Feature Dilution

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

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.

Requirements Documentaries – A Recipe

Introduction

In previous posts I’ve talked about how written requirements are on the decline and how our development methodologies and practices, at least in part, are constructed to hedge the risk of misunderstanding requirements.   As an outgrowth of those posts I’ll talk here about my vision for Requirements Documentaries as an alternative to written requirements and user stories.  I hope by the end of this post a formula will emerge for crafting video based user stories into a persistable set of requirements documentation that captures much of the context around a project.

Preparation and Coaching

How do you prepare the team for video recording?  While the discussion should be as open and natural as possible:  some coaching should be required here.  Meetings of all stripes tend to deviate from their course and sometimes into topics that are not appropriate for the organizational culture.  While these things can and should be edited out for the purpose of requirements documentaries; the team and customers should receive coaching ahead of time on how best to present their views and what topics/situations to avoid.

Other good tips should be included like: speaking clearly and loud enough for everyone to hear, avoid bad behaviors ( picking nose, tapping on the table, etc ).   We want it to be natural, but we also want it to be professional.

Tools

I believe this is a simple, cost effective set of tools that would serve as a basis for delivering requirements documentaries.

  • Whiteboard(s)
  • Wiki or requirements gathering tool ( Jira for example ).  A tool that can track versions.
  • High quality video camera(s) with sufficient battery life and backup batteries.
  • Digital camera to capture whiteboard sessions.

The Role: From Requirements Manager to Producer/Orchestrator

The role to facilitate requirements documentaries requires some new skills.  I’m calling this role “Producer” or “Orchestrator”.   But I don’t want everyone getting caught up in the title here.  It’s the skills and abilities of this role that are important.  Those are:

-Video production:  a solid understanding of digital video technologies ( hardware & software ) is important.  But additionally the person should have some training/understanding of how to make a documentary.  This would include how to edit the videos for applicability, ease of understanding, and dissemination to a heterogeneous audience.   Furthermore, this role would understand lighting, how to stage a scene, and related concepts in film/video production today.

-Facilitation & Coordination:  any good requirements manager today has to have some level of facilitation and coordination skills.  This will be instrumental when discussing the requirements, but also important in getting the right folks together to produce the documentary.  Discussions could veer off course, and it will be important for the orchestrator to guide the group back to the topic so as to make the video relevant.

-Detail Oriented:  goes without saying, but with the video medium, details may need to be clarified through, what I’ll call, adjunct clips and whiteboard captures.  So attention to detail doesn’t change, but the mediums of collection and dissemination may pose challenges for a traditional requirement’s managers.

-Organized:  just like today’s requirements the videos will need to be stitched together in some kind of wiki and organized in a manner that coincides with the software release.  Any adjunct items ( whiteboard captures, additional videos ) will need to be issued as modifiers to the original video.  In addition the orchestrator will need to keep his meetings, resources, and notes well organized.  More preparation may be needed to gather requirements in this fashion, but the benefit will be the greater context it brings to the developer’s work.

-Creative:  a little creativity to make the videos more enticing and “watchable” would be valuable.  However, we need to be careful here.  Too much creativity and the videos become more of a movie than a documentary.

-Provacateur:  a good requirements manager today thinks through the questions and challenges those in the room on their assumptions.   We still need this skill and it becomes even more important with video production.   Unless we want to issue continuous sets of adjuncts after each requirement documentary; we’ll need to flesh out as much as we can up front.   Please note, that I’m not suggesting BDUF here.  We can have 5,6, or however many requirements documentaries we need to form a release, but each of those main documentaries may have many adjuncts that clarify or modify anything missing in the main video.b

Method & Utilization

The process below could be done in an iterative or waterfall fashion.  It should be methodology agnostic.  My recommendation would be to start using this on a small, non-critical project in your enterprise.  See how it works and decide how to scale it from there.  I see this as a technique pattern for situations where your requirements may change frequently, have a complex and intricate data domain, or your team is global.  Lastly, I do realize this process is fairly basic……my intention is to start high level and as we see what works/doesn’t work we iterate back through and add more details or changes.

Potential Issues

Fear of the Camera – This is probably one of the most difficult issues.  Some folks have trouble speaking up in meetings…let alone in front of a camera.  So a sufficiently skilled orchestrator should recognize when this is occurring and attempt to bring that person into the conversation or, if completely unwilling to talk up, the orchestrator should pull that person aside, after the meeting, and have a candid discussion about whether they would like to continue participating.  It may be necessary to get a proxy to stand in for him/her.

Change – Using requirements documentaries is a big change in format.  It won’t go smoothly at first and that’s why I recommend approaching it on a small non-critical project at first.   Work out the kinks, and the issues with a group that sees the potential benefit.   Use all your change management skills and recognize the loss cycle associated with any big change.  Some may see it as opportunity, and yet others will see it as a threat.

Equipment problems – one of the reasons I stress using 2 cameras ( video and still ) for recording the requirements events:  Murphy’s Law.

Legal, Organizational Policy Issues – in some countries and companies recording by video is against the laws or corporate rules.  Check with your counsel before embarking on a project using a requirements documentary.   Legal representatives and corporate leaders who see value in this method may need to sit down and amend rules to allow this form of requirements gathering.

Politics – Recording things on video is a way of preserving the context around the requirements in addition to the actual meat, logic of the system.  It’s intended benefit it to preserve for future team members and current team members the mood, background, motivations, and reasoning behind what they are building.   This is the ideal side, but there is a less rosy edge to this.   Politics arise in almost any company, and documenting decisions on video could open the door to misuse for devious ends.   A company’s leadership embracing requirements documentaries should recognize this and put controls in place for those seeking political gain from manipulating the format.

Summary

Requirements risk exists on all projects to a greater or lesser degree.  The intention of this technique is to help mitigate that risk and provide continuity through time for a system’s definition.  I don’t suspect this will alleviate all requirements issues.  I’m too jaded by experience to think there are panaceas to every problem.  But there is some good evidence in the world of psychology and Hollywood that motion pictures are more memorable and understood more easily/rapidly.  You can see this for yourself.  When you left the theatre after seeing “The Green Lantern”  did you not understand it?   Was it totally lost on you?  Now what if I drafted that movie into a requirements document?  Logic aside…my hope is that we can catch our requirements gathering process up with the technologies that we have today for gathering that information.   If you try this technique….feel free to comment and let me know your experiences.  I’ll be anxious to hear them.


Agile vs Waterfall vs Lean Startup : Who Cares About the Labels?

Labels

After reading Shane Hastie’s latest InfoQ article:  Lean Startup or Agile or Lean Startup and Agile?  it became clear how much we’re all getting caught up in labels and methodologies.  My thought:  let’s drop the flag waving, become pragmatic in our approach and recognize that context plays a crucial role here.   What works for Eric Ries and his start-up may not work for the company you work for and the project you’re currently executing.

The Real Value – Techniques & Tools

The value in methodologies like Agile, Scrum,  Lean Startup,  Waterfall and others is in the techniques and tools they bring to the table.  While they are each packaged with a neat title and some intelligent proponents; we don’t need to use these in a take it or leave it fashion.  Be pragmatic and assemble your own toolkit.  I’ll reference Scott Ambler and say “context matters“.  We all need to move towards a collection, library of project and product management patterns that can be adopted within certain contexts.

Innovate 

Lastly, what’s invigorating about these debates is that we’re growing as a field.  We’re rethinking our ideas, and not settling.  This can only be good for software development and those affected, infected by it.  Yes, I meant to say “infected”.  🙂

Who Should Be the Scrum Master?

Who is this article for?

All software development professionals will find interest in this article, but those hoping to adopt agile, and scrum in particular, will find the greatest interest.

Project Manager or Technical Lead

Who should the scrum master be?  There’s at least two schools of thought that find gravity with this question.   One position is to employ the project manager in this role.  Another position is to have your technical leader tackle the position of scrum master.

Justifications for both can be made.  The project manager naturally has the people and process management skills required to successfully unblock nettlesome issues vexing the development team’s path to productivity.   But on a deeply technical project, unless the PM is fairly technical, he/she could end up at a disadvantage to a more traditional technical lead.  Hence, the argument to have your key development lead be the scrum master is born on the wings of a sufficiently technical project. Of course, this later position has the down side of potentially drawing the Peter Principle forward in all its majesty.  You hired Sam for his technical ability and now your taking him out of his strong suite.   Rarely a good move.

What about a CSM?

With the emergence of the Certified Scrum Master ( CSM ) credential software development directors are asked whether it makes more sense to get a professional scrum master to do the job.  This seems logical, and in some cases may present the right option.  But for those with experience and discernment, a certified anything is only a guarantee that the individual has at least passed some training and testing.

CSM’s may come to the role with the theory locked down, but it would be advisable to ensure they’ve ‘done it’ and can ‘prove it’.  A heterogeneous grouping of experiences and project types would be a good background for any CSM.  Awareness of any subject matter is important, but knowledge gained a priori has its limitations in the field of software development, indeed most worldly pursuits.  Experience counts deeply, and those who’ve been salted through the mine fields of time and circumstance can and do turn tricks the books don’t tell.

Rotate the Scrum Master Role Among Developers?

This seems like an interesting idea.  Seems is the optimal word here.  Rotate the role among developers and give them a chance to self organize.  After all, this is one of the scrum principles.

Boldly, we did this in my shop.  I can tell you first hand…it doesn’t work very well.  The results were not disastrous, but mixed and inconsistent.  The scrum master is there to facilitate and unblock key issues and risks.  By nature, most developers are not wired for these skills.  In most cases their preference is to solve deep, but abstract problems and/or utilize their creativity to bring their imagination into the world.  The scrum master’s world is never abstract and the problems rarely have a logical conclusion.

Here’s some examples of what occurred during our rotation experiment:

Developer 1 would take all blockers to the development manager and ask him to unblock them.  Dump and run.

Developer 2 saw the scrum master role as a break from developing software.   He was increasingly sick of writing code.  He’d often take over the other developer’s turns as scrum master and before long became the defacto scrum master….just because everyone else didn’t want to do it.  But he wasn’t good at it.

Developer 3 just wouldn’t do it.  When asked why…he gave the perfectly logical answer: “I wasn’t hired to do that job.  I won’t be good at it.”

Developer 4 was great at staying on top of all the details, and orchestrating/facilitating the scrum process, but his natural timidity meant he found it difficult to press upon others for project needs.

Qualities Not Titles and Credentials

So what are we left with?  If job titles, credentialing, and current software development roles offer no guarantee of a successful scrum master than what does?

Here, I would contend, from experience, that the qualities below are essential for a successful scrum master.  These may differ from more traditional scrum teachings, but I offer them up as opinion and reflection to the agile community.

A Driver – First and foremost the scrum master should be a bulldozer.  The person filling this seat should feel comfortable pushing issues forward and untangling gray, often ambiguous problems unaided by higher-ups.  I do believe this differs from the views of Scott Ambler, Ken Schwaber and other scrum proponents.  When they speak of a ‘coach’ one gets the sense the ideal candidate would be equally comfortable leading a Little League Baseball team.  But organizations with size and high market caps are serious and very adult places requiring thick skin and persistence forged in steel.

Detailed and Organized –  This really goes without saying.  A scrum master that is uncomfortable with the details of the software architecture he/she is helping to birth into the world is headed for trouble.  One doesn’t need to be reading the code, but it would be beneficial to have the skills to speak with developers on their level and translate those into business speak.   Being organized is also a natural quality for a scrum master.  As orchestrator of the scrum process he won’t gain any points from the team if he forgets that today is iteration planning or can’t recall which stories are resolved.

Honest With Himself/Herself – No one likes a liar.  It’s easy to be honest in the face of fair winds and successful deliveries.  But, when the rice pudding hits the fan and the scrum master and team are to blame:  a solid scrum master will set the example, take responsibility for the mess, apologize, and find a corrective course of action.  In a nutshell: lead.

Politically Astute – The nuances of human behavior and relationships inside organizations that scale to 3M and GE proportions are not to be trifled with.  A bulldozer needs to know when and where to stop plowing and let a more suitable piece of machinery take over.  Further,  the scrum master should have a bag of tricks.  He should be comfortable in the art of persuasion, know the hooks and hot buttons that pull and push his key stakeholders, and see the organizational hierarchy as a tool rather than an impediment.

It’s Personal and I’m Fully Invested – In my experience, aloof scrum masters don’t do well.  They should see their role, project, and career as intertwined.  Their reputation should be at stake and success to them should be more than just a good stand up meeting, or a well orchestrated iteration review.  None of that matters should the product miss its goals. They should take this personal, and invest themselves fully in the project.  Again, this is leadership. Projects rarely fail because money, time or ideas are lacking.  Their usual course to being shipwrecked starts with….belief.  People need to believe the project will be successful and the scrum master should be its evangelist.

Humility – Lastly, I agree with most other scrum theorists that the scrum master should be humble.  I think this is called ‘servant leadership’ by them, but I’d chalk it up as just good leadership skills.  A good SM won’t boast or take credit for other’s work, but place credit where it is most surely due.  Let me be clear, I’m saying ‘humble’ not ‘without backbone’.

Summary

The picture that emerges for a good scrum master candidate is a leader; not a secretary or a bureaucrat.  My view on this differs from traditional scrum thinking.  Where they see a helper of the development team, I see the scrum master as an active, engaging and dynamic person with a big stake in the game. He or she could have certain titles or credentials to his or her credit or not.  Like so many other leadership roles the core of  what that person accomplishes will be manifested through who they are….rather than what hard skills they may possess.  When interviewing and reviewing potential candidates I would keep this question in your mind: Will the development team and stakeholders believe in this person?  Your project may rest on the answer.

Can Agile Work in Big Organizations?

Who is this article for?

All software development professionals will find interest in this article, but managers, CIOs and software architects will find the greatest interest.

Can Big Organizations Rapidly Change?

Think about the last big company you worked for.  Did it move fast?  Change overnight?  Did anything get done ‘quickly’?  Weren’t there gobs of jokes about the ‘bureacracy’.  Big companies run slow.  When they need to move fast they put people outside the organization or buy smaller companies.  Change is just not a priority inside a company like this unless it is facing financial issues and agile presents a significant challenge to the orthodoxy and bureacracy of such a beast. But is that a reason to not attempt agile in a large corporation?  No.  But it is a reason to have a different strategy for a change adoption.


Hybridization of Agile:  Pragmagile

Yes….but you have to be pragmatic.  What I mean is that you’ll need to realize that this bureacracy and the people in it were bequeathed their titles for a reason.  They’re successful, to a certain extent, because they know how to get things done despite all the red tape and foot dragging.  As an agilist, these people are not your enemies despite their gantt charts and stakeholder evaluation matrices.  They’re your allies, your tools to be upwardly managed.

So considering this I’ve compiled a list of tactics that I think may be helpful for any agilist hoping to succeed in a large professionally heterogeneous company.   Here they are….let me know if you agree?

1. Follow the principles of The Pragmatic Manifesto.   Key among these… is embracing everyone…not just the software development team.  See everyone as having value and being able to participate and contribute to your software development process.  Be pragmagile.

2.  Walk it, don’t talk it.  Show your company agile works.   Don’t go around preaching it and extoling its virtues when you haven’t even delivered one project yet.  You might even want to avoid the word ‘agile’ altogether and just say this is how I like to work:  meet every two weeks, go over any changes, hedge the risk that we don’t understand, and adjust project course as needed.

3.  Help your project sponsor help you.   Your project sponsor in a large corporation is likely a veteran of the company.  Don’t discount this as ‘stuck in the old  ways’.  They know stuff you don’t and they can help you stay in good graces with all the red tape barrons.   Keep a solid, open and agreeable relationship with your project sponsor.

4.  Give a little, get a little.  Another way of saying this…….don’t be dogmatic.  If someone doesn’t like some aspect of your agile approach don’t automatically write them off.  They may have good reasons for their objection, and by showing your concern and willingness to adjust…..you’re demonstrating a core tenant of agility.    If stand-ups are hard for people with back issues, then try a 15 minute conf call.   If the customer just can’t meet every two weeks, then try every month or on a more lucid schedule.  But above all…….be flexible.

5.  Focus on the goal.  Delivery of your project/product is what you’re after.  Not agile adoption by your company.  Maybe you’ll get this as a side effect, but honestly…….you probably weren’t hired to evangelize the enterprise. Furthermore…you can’t do it on your own.  Put your accounting hat on and think hard-ball.  Git-her-done.

6.  Seek to understand the culture and the history behind it.   Maybe your company doesn’t move fast on this software project because your building something that its enormously complex and could kill someone if not done right.  There may be very good reasons for stifling rules and countless reviews/approvals.  Work with the grain of the wood…not against it.

7.  Stop assuming everyone wants to be agile.   Worse yet, stop assuming everyone knows what it is.  They may have heard about it and chalked it up to no  more than a new process.  But those of us who’ve lived it know that the real change is cultural.  It’s a tough shift and it won’t happen overnight.  Be patient with those around you.  They’re trying to learn and you’re there to help them along.  Be prepared for the guy who says “Agile sucks and here’s why…”.  He may have valid reasons for his opinion and discounting him will only deepen his view.

8.  Figure out the commitment level up front.  I wrote about this in another article:  Are You Committed?   But, essentially the team is supposed to commit to the iteration at hand.  But….what does that really mean?  Commitment is one word with many different interpretations.  Don’t assume you know how much the team is willing to commit and don’t assume that the companies HR policies and benefits jive with the agile philosophy.

Summary

That’s it.  I know I probably should have run it up to 10 ( don’t all good lists round up to 10? ), but I’m not going to throw down fluff just to reach a number.   It’s been my experience that if you make agile work in an organization people will just naturally ask you:  what’s your secret?  Why do your projects work out while other projects fail?  If you get to this point then I guess it’s ok to preach a little bit, but step off the soap-box when you feel your head getting bigger.   😉