Agile Zone is brought to you in partnership with:

Bob Hartman has spent 30+ years in software development. His logic-based approach to development and quality was honed early in his career when he obtained Bachelors and Masters degrees in Computer Science from Rensselaer Polytechnic Institute. Over the past 10 years he has grown from being an early adopter of agile to his current status as a Certified Scrum Trainer (CST) and Certified Scrum Coach (CSC). He also remembers the pain of long waterfall development cycles and understands the human and business interactions necessary to achieve success regardless of development methodology. Bob is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

New to agile? Remember how to say “No”

  • submit to reddit

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!

Published at DZone with permission of Bob Hartman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Muhammad Faiz replied on Fri, 2012/04/13 - 8:47am

I’m going to disagree with you on this. There are many times when teams need to say no because saying yes implies it will get done, when in truth something will fall out (which is something you said yes to previously). I think it is dangerous for the team to say yes and then just prioritize their way out of the mess.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.