New to agile? Remember how to say “No”

No.  Only two letters.  Very simple word.  Yet for some reason, with the exception of when we are at “the terrible 2’s” stage of life we tend to forget how to say it!  Agile teams and organizations need to remember how to say no!  Too often agile organizations don’t get the full benefit of an agile environment because they are too busy trying to do things the old way,while using a new process which doesn’t support the old way.

In my opinion the “no” word should be used much more often at every level of the organization where agile is being embraced.  For example:

• Programs, portfolios and projects – most organizations are running too many programs, portfolios and/or projects simultaneously.  Say NO to some of them!  Concentrate on what the organization can do well, and profitably.  Monitor status and shut down underperforming projects so other projects can have additional help.  Do not throw good money after bad!
• Scope of projects – scope creep is very real under a traditional development methodology.  Why?  Because it is the only way to make sure you have any chance of hitting true market needs at release.  With agile the organization needs to be very clear about the choice between adding scope and changing the date.  If the date is flexible, add scope at will (but this is not usually the case).  If the date is important then adding scope is not possible and instead there needs to be a trade of scope (if you want X, you’ll need to drop Y).  In other words someone has to have enough courage to say NO to scope creep.
• Multi-tasking teams – too many agile organizations are matrixed or have “shared resources” (people!) which work on more than one project at a time.  This is usually done with testing teams which I think is the worst possible multi-tasking under agile.  This causes churn, which is waste.  It also means the organization has decided not to make the hard decisions about which projects are more important than others.  Again, someone needs to have the courage to say NO and create dedicated teams of PEOPLE (not resources) to complete projects rather than spinning between multiple projects.  If 3 projects each will take 1 month to complete, do them serially and get value at the end of each of months 1, 2 and 3.  Do them in parallel and get all of the value only some time after month 3 (because of churn all 3 projects will take longer than the time to do each of them serially).
• Assigning work to individuals – this is a holdover from the traditional way of developing software.  In agile the team should self-organize and self-direct which usually means pulling work in a way which is most efficient for the team, not what is nicest to put on a Gantt chart.  Say NO to assigning work and YES to pulling work when necessary!
• Creating detailed estimates – everyone should scream NO to this one.  If you want to go back to waterfall, do it.  Don’t fall into the trap of trying to do all of  the analysis up front and then believe everything is predictable.  If this worked then waterfall would be successful.  We know it isn’t, yet we keep going back to old habits trying to make things more predictable.  Please remember that PLANNING is important, but the PLAN is going to change frequently!  Don’t waste time and effort doing work which will be incorrect after an iteration or two.
• Micromanagement – if you want to kill an agile team’s productivity then try to micromanage them.  So NO to this, but YES to allowing the team to solve their own problems.

Until organizations start learning to say NO much more often there will always be too much work in progress and too many projects which won’t generate the desired returns.  We need to get out of the mindset which says stopping a project is a bad thing.  Stopping a project for the right reasons is a good thing.  It means the agile process has worked.  The failure was fast and limited and we learned from it.  We can change our approach and work on something with more potential.  Use the power of NO to stay focused and you will see significant improvement over time.

Until next time I’m going to be Making Agile a Reality™ for more organizations by helping them say NO much more often!