The Agile Diet Plan

Keith Shakib Agile, Dev Methodologies Leave a Comment

Attention: The following article was published over 9 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

Many organizations over the last few years have been “trying on” the Agile development process. A few have achieved a superior level of agility and benefits, many have failed and written off Agile as yet another process methodology that’s full of promises but doesn’t work, and many others have adopted principles of Agile and Scrum and gotten some improvement. So why is there such a variable success rate for getting to that “golden chalice” of agility?

The answer lies in a simple comparison: having success with a new software development process can be very much like an individual having success with a new Diet Plan.

The main similarities are as follows:

  1. Understand up front what you want to accomplish. Set realistic short term and long term goals.
  2. No improvement is possible without change. Making major improvement usually takes major change.
  3. You can’t do it alone. Those around you will be impacted and most change takes cooperation from others who may or may not share your goals.
  4. Sacrifice is inevitable for success. You cannot stay in your comfort zone and expect improvement.
  5. Real improvement takes time and commitment.
  6. Play Pick-and-Choose with caution. Choosing what parts of the plan you want to do and leaving out the rest may result in partial success, but, more often than not, you will see the plan as a failure.

Let’s take a look at each one individually:


Seems simple, doesn’t it?  Using our analogy, for a diet plan your goal is to simply lose weight.  But if you think about it more, you realize there are other important goals, such as, keeping the weight off, having reasonable time and cost requirements, and not effecting long-term health in a negative fashion.  When it comes to selecting an Agile development process, you should think in detail about what you are really interested in accomplishing.  Here are some common goals, which may or may not match up with what you are setting out to do:

  • Improve time to market
  • Reduce bugs and maintenance cost
  • Avoid waste
  • Increase effective communication
  • Improve team morale

In general, each goal you add makes the overall success harder to achieve.  Many of the reasons Agile Development is so effective is that the goals above do not increase the difficulty exponentially.  Instead, effectively implementing prescribed practices can make these goals happen at the same time.


This may seem obvious at first, but the biggest hurdle I see to true adoption of an Agile Development process is the hesitation to change. Many times I hear, “We do want to be agile as long as we can keep doing what we’ve been doing.” If what you have been doing works and achieves your goal, then you don’t really need to change. One helpful approach is to identify what parts of your current process are hindering you from achieving your goals. For instance you may be taking 20% of your development cycle time to produce documentation that hardly anyone ever reads. Good documentation is essential to project success, but often times it is produced in a way that makes it too costly to maintain and out-of-date documentation is a negative not a positive. Taking a close look at whether a seemingly wasteful part of your process can be improved or removed takes time and effort, but you must be willing to make changes to improve.


Who in your organization wants to adopt Agile?  Is it top-down where a VP is astute enough to know that it is best for the organization and therefore they dictate that you will be Agile? Is it a grass roots effort where a few developers really want to try it out and to show proof that it is the answer? Is there an outside influence like a consultant who is trying to provide value to their client organization?  (This is, of course, my favorite scenario). Regardless of where it starts, the most difficult challenge will be trying to implement an Agile approach in just one part of your organization.

If you are trying to use sprints to produce demonstrable units of functionality every two to three weeks, that can be called DONE, and that is ready-for-release, you will find success hard to find if your DBAs, testers, architects, usability engineers,  and especially a Product Owner (who can make the really hard decisions on behalf of the company and the customer) are not a part of your Scrum team. Ideally, you want full representation at your scrums, as well as full buy in to short, quick, fully-tested increments of work.  In reality, getting everyone on board from the start is unfortunately rare and therefore the place where a lot of work will stall.


What is your comfort zone? Some managers do not want to give up control. They want constant status reports and meetings and reviews and more meetings. Some developers often time have nice little hiding places and techniques for staying low and avoiding attention. Some testers like to save up test cases until the very end and then pounce on the developers to show them who is really in charge. Many of these bad habits slow down the process, cause waste, and have a negative affect on morale.

Using a Scrum process allows the team (not only agile, but empowered team) to synchronize their work and allows managers to know status without taking away noticeable time from the team. All the work is visible; no one can hide out. Everyone must participate. Most importantly, the team must share the same goal of achieving finished increments of work. If the developer doesn’t give the tester ample time to find bugs or the tester doesn’t find and report bugs in time for the developer to fix them, then the team fails. To achieve this team synergy, every one has to sacrifice their own tendencies to cover their own backside and become true team players.


How often have you heard someone say, “That diet sucks. I was on it for three weeks and only lost a few pounds.”  This is a sign of someone looking for the quick fix. There are diets out there that claim you can drop loads of pounds really quick, but there is usually a catch and rarely if ever are they maintainable. The Agile Diet Plan does not make this claim. Sure, I’ve seen signs of improvement around several of the goals sited above in just a few short weeks, but that shouldn’t really count. What matters is if you can maintain the success. Don’t be surprised, though, if you see setbacks in the beginning.  Some situations don’t show marked improved until after 5 or 6 sprints in to the process.  In fact, some teams don’t take credit for success until a release is put into production.

Expect success to come slowly and to take time. Look for small successes and improvements along the way but don’t get too over-confident for early victories and, especially, don’t give up before you give Agile a real chance. If you make the commitment to start it, make and keep your commitment to finish it.


Usually diet plans have a basic premise; low carbs, high fiber, starvation (my favorite, NOT). The problem with many of these diets is that they are impractical or too difficult to stick with. So, most people “tune” the diet to their needs using their own unscientific reasoning. “Bananas are fruits and they have to be healthy” (even though the sugar content is high).

With development methodologies, many organizations do this same rationalization. “We’ll just go ahead and size our backlog using hours from the start; that’ll save us time.” Using sizing techniques like Planning Poker, purposely avoids applying hours to user stories that have had no elaboration. One of my pet peeves with other methodologies is the “BIG LIE.”  Months into my very first job as a developer, on the way out of the office, my boss asked how long the project we discussed earlier in the day would take.  I tried to avoid answering, but my boss pressed and I said, “I don’t know, maybe 6 months.” Sure enough, the next day that was the number booked in the plan. My BIG LIE was not based on facts or experience, nor did it take into account who would be working on it or what technologies we would use.  But because older processes required an hourly sizing to plan projects, BIG LIEs were accepted whole-heartedly and were very useful in the blame game that followed when inevitably the project did not come in on time.

There are many best practices in Scrum and Agile and most organizations cannot change quickly enough to adopt them all from the start. If you start to play the pick-and-choose game, be sure to fully understand the purpose of the practice and what you will be losing. In the case of story points: you are replacing the simple practice of depending on relative sizings as a way to pick stories for a sprint, and replacing that with numbers that will be confused with how long the story will take to implement, even though those numbers are not based on a proven track record for a team. Another popular rule to bend is to have the development’s team manager be the scrum master. This is usually not a good idea as the dynamics of the otherwise empowered teams leans more toward a management-driven, only-do-what-I’m-told model.


So now that you’ve been given food (diet food) for thought, you can hopefully more effectively evaluate how to approach the idea of getting started with Agile development. If you’re the lead advocate for introducing Agile into an existing waterfall or iterative development environment, slowly digest these concepts and consider the facts. Some organizations can jump in and try out Agile practices and keep an open mind. Other organizations need to prepare both mentally and organizationally to know when is the best time to start and how committed they need to be. Hopefully, the Agile Diet Plan will be for you.

— Keith Shakib, [email protected]

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments