#92-Agile Teams in Waterfall Organizations

If your team is using an agile project management approach, and your overall organization is not, then how can you overcome the mismatch of processes, expectations, and how your team's work is being evaluated.  This episode will introduce a series of podcasts on addressing this problem.

Transcript

Agile Teams in Waterfall Organizations

If your team is managed with an agile process but the organization that you operate within is conducted in a waterfall fashion, how can you integrate these two disparate mindsets effectively? 

The waterfall states that product development should be conducted in discrete phases. Typically, the first phase is analysis which, when completed, is meticulously documented and handed off to the design process. 

The design phase creates a detailed plan for the way the product will be made, which is also carefully laid out in extensively detailed diagrams, procedures, materials, and milestones. 

The construction process is meant to be compliant to the insights brought forward in analysis, and adherent to the plans locked down by the designers. The team operates like a construction crew building a skyscraper. Their two requirements are: to keep the quality of the work high, but follow the plan without changing it in any way.  When the construction team changes a decision made by designers, the result can be disastrous and dangerous.

Once construction is complete then the testing or inspection phase is engaged, where defects are identified and a punch list is returned back to the construction phase for correction. 

The waterfall is: analysis, design, construction, inspection/correction, and then finally the deployment or release of the product. 

Agile projects work completely differently. They are conducted in increments within which each of the waterfall activities is included on a single small part of the overall product.  The “release” in this case is the submission of a partially-completed product for validation by the stakeholders.

Because of this incremental approach there will not be an upfront analysis artifact, nor will there be a fixed design plan, and testing will not happen when the product is theoretically complete, but rather in a constant fashion.  In other words many of the required elements of the waterfall will not be made available by a team operating in an agile fashion, and so they will not be able to pass through the process gates. This may violate the policies of the organization and impede the ability of the team to be effective.

As a consultant, this is one of the reasons I have been asked to provide assistance, typically by the leads of the agile team. They are usually in a state of frustration because the agile mindset is not prevalent in the way that they are being managed and measured. 

I find  that the place to start in resolving these issues is to inquire as to why this particular team is being allowed to operate in an agile fashion. Is there an agile champion on the executive management team? Has the organization decided that this one product will be a pilot experiment to prove or disprove the effectiveness of agile? Has this team been part of a merger or acquisition, and therefore has become a rogue element in the current organization? 

In my experience it has always been one of these three things. Each requires a different approach.

The next three episodes of this podcast will each take on one of these scenarios.

Empowering the agile champion

Proving the agile experiment 

Protecting the subversive agile team 

I hope this will be a useful journey for all those who find themselves in this situation.