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!
No, no, no. Don’t say no.
Say yes! Then prioritize and assess risk. In fact, risk management is the best way to say yes while staying focused on what really matters.
Saying no will get you labeled as difficult and uncooperative. Saying yes and educating people about the realities of the situation will win respect.
Vin, 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.
This also doesn’t necessarily work when evaluating which projects should actually be done, whether a portfolio of products has the necessary ROI, etc. In those cases you run the risk of throwing good money away after you’ve already spent a bunch of money.
I may be wrong, but in my experience teams and organizations who use “no” effectively are the best performing in terms of ROI.
– Bob –
I agree with Bob. Saying yes and then not delivering is worse from all perspectives than saying no to an unreasonable request. Good risk management is important in every project, but it won’t make a “no” become a “yes” if time, cost, lack of enough information upfront, or another constraint, makes it impossible to fulfill a request without causing a negative impact in the project.
The book “NO: The only negotiating system you need for work and home”, by Jim Camp, is a good reference for people who is constantly trying to please others with a yes:
“Saying ‘no’ is not about being hard-nosed or intransigent. Rather, it stops everyone in their tracks, clears the air, and allows you to get at what the real issues are. It is a proven and an amazing effective system that avoids unwarranted assumptions, needless compromises, and wild guesses.”