The idea of an agile team toiling away trying to be agile in the face of a waterfall organization evokes a huge amount of passion.  (more…)

Blackwater Falls

A waterfall precedes and follows rapids

In Agile Teams In A Waterfall Environment: Fixed Budget, Fixed Scope, Fixed Date, I talked about a panel discussion that I participated in that was asked: 

“We have been presented with a project with a fixed budget, fixed scope, and fixed date — can we use agile to deliver this project?” 

Interpreting the question as can we “be” agile, the answer is no (heck no if you want to be emphatic).  However, does that mean we need to take our ball and march off the field — never to be or do agile? Again, the answer is also heck no. There are several strategies that a team or even an organization can take to make progress toward a better way of working.  (more…)

Blackwater Falls

A waterfall precedes and follows rapids

I recently participated in a panel discussion that was presented with the question: 

“We have been presented with a project with a fixed budget, fixed scope, and fixed date — can we use agile to deliver this project?” 

A bit of context, the work was not a simple request that had been done many times and the software team had not had access to the ultimate customers that requested the work before the scope, date, and budget were set. Unfortunately, this is not the first time I have heard this question this year. The simple answer is that the team can’t be agile in this scenario although they may use specific agile techniques. Just using techniques doesn’t make you agile. One of the reasons the ‘you can’t be agile’ answer is so easy in this scenario is that this type of project explicitly clashes with two of the values in the Agile Manifesto. They are:  (more…)

Play Now!
Listen and Subscribe on Apple Podcast and Subscribe on Google Podcasts

The Software Process and Measurement Cast 610 features our essay, An Agile Team In a Waterfall Company – Organizing Around The Product Flow. Focusing on getting features and support for a product to market changes how teams and groups organize to solve business problems.  This is a standalone essay that can be read as part of a larger theme covering the trials faced by an agile team in a waterfall company.  The four separate essays can be found at: 

  1. An Agile Team In A Waterfall Company – 
  2. Postponing Commitment – 
  3. Values, Principles, and Behaviours – 
  4. Organizing Around The Product Flow – 

We also have a visit from Susan Parente with a discussion that I have named, Agile or Traditional, Pick One!  Many organizations have to make accommodations for mandated classic project management approaches. Susan provides excellent advice for making these types of scenarios work.  (more…)

Focus On Flow

Helping an individual agile team interface with a waterfall organization is only a stopgap measure.  At some point, the level of noise and frustration generated between the team and the organization will wear everyone down. This will end up in a lose-lose outcome. Taking the three-steps outlined before today will reduce the conflict and pave the way for change. The steps suggested are:

  1. Prioritizing Work Entry (discussed in An Agile Team In A Waterfall World)
  2. Postponing Commitment (discussed in An Agile Team In A Waterfall Company – Postponing Commitment)
  3. Addressing Values, Principles, And Behaviors (discussed in Values, Principles, And Behaviors

To affect the direction of change and to deliver maximum value requires organizing people and teams around the flow of value in your organization. Modifying Steve Tendon and Daniel Doiron’s definition of flow a bit (from their new book Tame Your Work Flow which is being discussed on Re-read Saturday, “flow is the amount of work or value delivered per unit of time while speed is how fast work moves through the value chain.” The definition provides a framework to consider throughput using a systems thinking perspective (think big picture).  Steve and Daniel define 4 types of flow: (more…)


Much has been written on the distinction of being agile versus doing agile. The crux of being agile is embracing the values and principles that underpin agile. Those values and principles are compiled in the Agile Manifesto and have been tweaked and restated many times, but they boil down to the same basic ideas. Organizations that cherry-pick or decide that culture that is inferred by the values and principles are only for parts of the organization will not get the value they are looking for. That is a failure in adoption not a failure of agile culture. Helping an agile team interface with a waterfall organization is the same as asking can we be agile when everyone around us is doing something different. The answer is sort of.  So far in this theme, we have explored two potential changes within the team’s span of control that can “help.” (more…)

Blackwater Falls

A waterfall precedes and follows rapids

Agile teams living in a waterfall organization can have a tough road to travel. The degree of difficulty is often a reflection of the team’s sphere of control.  As noted in An Agile Team In A Waterfall World,  there are four areas that need to be addressed if an Agile team is going to thrive in a waterfall environment.  They are:

  1. Prioritizing Work Entry (discussed in An Agile Team In A Waterfall World)
  2. Postponing Commitment
  3. Engaging Executives On Agile Values
  4. Value Chain Analysis


Blackwater Falls in WV

Falls or rapids?

I was recently asked about interfacing an agile team with the rest of a “waterfall” company. This is not an uncommon theme in the questions that I receive.  A synopsis of the scenario I was given at the start of the conversation follows: (more…)


Once you get to the point that you know you are going to have to interface a SAFe release train(s), with a waterfall program run outside your organization, success generally turns on three very related topics.  The three topics are transparency, synchronization, and code.  The timing of when the code from all parties is available and managing when the code can be integrated and tested is critical. Even if both programs produce the right code and the code works as it is expected, each program will produce functional code at very different times.  By definition waterfall projects create code after they have done a large part of the analysis and design while teams in a SAFe release train will have functional, demonstrable code earlier. By the time the waterfall project is ready to write code the agile project will have a significant investment in a code base.   Three suggested approaches (in addition to transparency and synchronization) for addressing the risk generated by the differential in code timing are: (more…)

millaa millaa falls

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall?, we identified three major areas that had to be addressed so that a multiple inter-related programs with different management approaches didn’t turn into a train wreck.  Keeping related programs moving in the same direction is important, and synchronization is critical. In a recent interview for a future SPaMCAST Alan Shalloway, CEO of NetDynamics, reminded me that the more complicated we make work, the more we reduce flow and increase the probability of making mistakes. Staking the organization’s success to integrating two programs moving at different speeds is complicated. Synchronizing successfully requires spending time and money to keep the programs synchronized. Three effective techniques used to implement synchronization are: (more…)