Agile and FTTM
/We are frequently asked to compare Agile and FTTM (fast-time-to-market). FTTM is the process of delivering the right-product at the right-time. It seems that people want to compare these two approaches to managing projects, as competitors to one another.
The problem is not the principles behind Agile, which you will see are very similar to FTTM, but rather the way in which Agile software vendors implement software to track Agile-based projects, more on this later.
Some History
We should step back and explore a brief history of Agile and FTTM in order to have a better understand of the context for this discussion. We will not attempt to chart the history of Agile here, as others have done this at length. See the Techbeacon article referenced below for a good overview. Agile was developed to manage software projects and was in response to cumbersome, slow phase/gate linear waterfall methodologies. The use of Agile outside of software-only projects is limited, based on our own consulting experience. We see an effort being made to expand the use of Agile tools to more than just software projects.
Agile was started in about 2001, with roots in the 1990’s and 80’s in Extreme Programming (EP) and Rapid Application Development (RAD). FTTM was developed during the 1990-1991 study conducted by lateralworks into the practices of fast teams in Silicon Valley. Since this time, FTTM has continuously been expanded through ongoing research conducted by lateralworks on thousands of client projects around the world.
FTTM and Best Practices
We wanted to know what differentiated teams that delivered products ahead of schedule and that met or exceeded customer requirements. This groundbreaking research project isolated a series of best practices concerning how teams where organized, how they defined the product, and how the executed quickly. Also, it defined the characteristics of fast organizations? In other words, the kind of infrastructure around the development team to enable it to be consistently fast.
The interesting point about the foundational principles behind FTTM is that they are similar to Agile, which came later. Both approaches where created to remove linear, bureaucratic processes and to involve the customer in iterative development.
And as in Agile, FTTM has its roots in what came before it; Concurrent Engineering in the 1970’s/80’s, Systems Engineering in the 1960’s, and maybe the fastest organizing model of all called the “Skunkworks” in the 1950’s — which developed advanced aircraft in months, and then even further back, with the the “Chief Engineer” approach used on construction projects like the Empire State Building and the Bay and Golden Gate bridges (all constructed in less than 2 years, something that has never been repeated). The predecessors to FTTM and Agile did not use software tools, but rather clever planning and good engineering to achieve fast cycle time results. The consistent theme in all these systems of management was to eliminate inefficiencies and to make the flow more Lean, wait, I forgot to mention the Japanese contribution in the 1990’s called “Lean Manufacturing.”
What is Common?
The name you give a methodology is not important. All these methods have commonalities; namely that you have to do things at the same time and not one after another in order to be fast. You must engage with the customer and really understand what they want, and continuously involve them in the process if you want to get the right-product in the end. You need to produce early prototypes so customers can test them and then you must use their feedback to refine the design. Then you must manage the hell out of the execution on a daily and hourly basis in order to make rapid course adjustments as things change, which is the only constant in a fast cycle time project.
Therefore, the type of method is really a function of who is selling you the software that was created to apply that method. The tools tend to drive the method, which is wrong and backwards thinking. Agile has a big following today because of the software vendors that promote it in order to sell their software. Around the Agile software is a larger group of consultants that will help you implement the software and apply Agile. It has become less of a methodology now and more of a “cult.” It is an ecosystem that continues to promote Agile as good, and that everything that came before it as bad. Unfortunately, the core principles of Agile have been lost in these software manifestations and how they are implemented. We know, because most of the software projects we get called into have used Agile in some form, and have failed, and then need to be rescued. They have all been late in our eperience.
It got screwed up by software…
From our experience, the problem originated when vendors started developing Agile software that adopted a particular way of working, such as having daily meetings, scrums, sprints, etc. Teams jumped on the Agile bandwagon and started to rely on Agile tools, thinking it would solve their problems and accelerate product development, like a magic pill that would make things go fast.
The fundamental problem was that there still was no integrated and linked schedule, no critical path, no ability to predict an end date — and no gap; no way to accelerate when using Agile. It lacks the integrated thread though the project that you could pull to accelerate.
Ask any of the Agile teams when they would be finished, what was the gap from target —they could not tell us. All they knew was what was happening in the next 2 weeks. If something didn’t get finished this week, then it just moved to the next sprint and scrum cycle. They lacked an ability to see the knock-on affect of today’s delay on the future end date of the project. This is the critical missing link in Agile tools.
Many times we have seen teams use Agile, only to continually miss deadlines (we know because we’re usually called in to fix the problems). One particular company we engaged with that developed a large software platform used by almost all corporations around the world had for years continually missed their deadlines by many months. When they adopted the critical path approach (FTTM) they were able to predict release dates with consistency and accuracy. We gave them a tool to predict and manage, while preserving the foundational principles of Agile. Agile and FTTM can co-exist.
How do they compare?
It is important to point out that Agile is a tool developed for managing software projects. Software development has unique characteristics that other more “physical” projects don’t enjoy; the order of tasks can be somewhat flexible, they just need to be prioritized. For example, we could specify, code, and unit test Module A. We could do this same cycle on Module B and C at the same time or decide to do Module C first, then Module A and B second and simultaniously.
The comparison chart (above) outlines some similarities and differences between Agile and FTTM
This flexibility shows up in Agile software tools. Unfortunately, this has been taken to the extreme. Many software features (being developed) are placed into buckets of time (a sprint) and done when people want to do them or have time to do them over the duration of the sprint. The ones that don’t get done inside of the defined time bucket get tossed over the wall to the next bucket. The Agile software then tracks the rate of completion, pushing the bubble of delayed features further and further to the right. The software provides nice rate-charts to show the problem, but offers no solution. At the end, a product is shipped, missing perhaps some of the most critical components which get delayed to the next release. Most new product development projects in Silicon Valley we work on would never permit this sort of outcome, so this kind of management system never works for them. The problem is that it is very hard to clearly see what this is doing to the overall schedule. How much is the delay today affecting the end date of the project and what is it doing to the schedule gap? Is the trend getting worse or improving?
Agile software vendors knew that they needed to expand their markets to beyond software projects in order to grow. So we started to see Agile being implemented in all sorts of projects that where not similar in any way to how software is developed. We saw it used in projects where there were clear precedence relationships between tasks. You have to finish A before you start B for example. The people that tried to use Agile software on these mixed projects (hardware/software/systems integration, etc.) projects failed even more than those that we rescued who had used Agile on pure software projects.
What are the core differences?
Agile does not help a team understand the schedule gap. In fact, you can’t get it out of an Agile system. You get a near term view, but not an overall macro view. The macro view tells us the schedule gap early in the planning cycle, while there is time to fix it. The problem with not knowing the schedule gap early enough, and what is driving that gap… is that you can’t make the decisions and trade-offs necessary to accelerate early.
Prioritize and Focus
The essence of the FTTM System is prioritization in order to focus a team on the things that matter today in order to affect the future. Prioritized requirements, features, and tasks. What is the most important today and which adds the greatest value to achieving the objective in the end? These are the foundations of FTTM.
This is what we see lacking in Agile tools, but not in the original Agile thinking. The problem, in our view, is that the Agile concepts as first defined by the team during the Snowbird meeting in Utah never got carried forward into the software tools people developed to implement the Agile principles. We have always said that FTTM is a better way to implement Agile.
FTTM is fully aligned with Agile concepts. Where we differ is in the implementation. The Agile principles are really those that we discovered ten years before Agile was invented and have refined over the past 30 years.
Early customer involvement and a product based on their needs (VOC)
Early delivery/releases of the product for the customer to evaluate (vs. big bang)
Continuous product improvement
Scope/requirements flexibility (not waiting and “freezing” requirements at the beginning of a project) - requirements need to change if the market changes
Informal communication (and shorter & more frequent project meetings), fewer documents, not phase/process orientated (like a Phase Life Cycle PLC), etc.
Also see: