I would consider myself a fan of the Agile approach to software development. In fact, I would even say I am mostly a fan of the Scrum framework.

I appreciate the ceremonies that transpire as part of an Agile team utilizing Scrum. I enjoy releasing software often, with incremental features being delivered to customers to utilize. I like to see my team's velocity be tracked and analyzed over time — comparing ourselves to other teams contributing on a given initiative. The end-of-sprint demos are something to look forward to as well — with customers and all teams in attendance — seeing the fine work completed by all the feature teams.

As organizations have bought into adopting an Agile approach to software development, I've noticed that one corporation's identification with terms like Agile or Scrum may differ from another's. Almost as if they are deciding how they wish to utilize Agile concepts to best meet the needs of their teams. I am really okay with this approach, as I noted in the article, "Agile For the Sake of Being Agile."

But, what if Agile or Scrum is not the right answer at all?

An Example

Consider this example.

The project was a conversion project — driven initially out of a desire to do a technology replacement. As the project struggled to gain traction and encountered issues with connecting with the right service provider to assist with the project, the desire to finish the project migrated from being a desire to a necessity. When I became involved in the project, a "line in the sand" deadline had been established — due to customers no longer able to support the original technology used to run the legacy system. In this case, it was a combination of licensing and technology concerns.

The corporation funding the project indicated the project should be ran as a Scrum project. Their directive was part of an effort to demonstrate progress and provide confidence that this conversion attempt was producing successful results. The corporation had been burned in the past by promises from vendors that never yielded a functional product. As a result, grooming sessions were scheduled to review the tickets in the backlog, planning sessions were created to determine what stories would be part of the ensuing sprint, daily stand-ups would be scheduled and there would always be a retrospective. These sessions consuming a modest amount of time during the team's standard sprint cycle.

When I noticed the amount of working that was being completed, compared to the amount of work that was left to do — and a deadline approaching fast — I started to wonder if this project really should have been utilizing the Scrum framework.

Why Not Scrum?

There were a few different aspects that made me think something other than Scrum should be considered.

Deadline Is Set

As I noted above, due to limitations imposed by the customer, a "line in the sand" deadline was established. This translated into the fact that there would not be any releases prior to the initial release and the date established could not be changed. At the same time, the budget for the project was locked in and not subject to change.

While these facts did not necessarily eliminate the need to work in small iterations, it did make it clear that those completed items would sit idle until the initial version was released.

As one might imagine, the deadline being set was somewhat aggressive — which was understood by everyone on the project. As a result, I began to wonder if team members should become stingy with their time in an effort to maximize their heads-down productivity.

Agile Not Really Adopted

This corporation mandated an Agile approach, because they wanted to see results. However, there wasn't really any true adoption of agility employed at this location. Each team's velocity after a given sprint was talked about in the retrospective, but senior management really was not in tune with any metrics being captured. At the same time, when improvement opportunities were noted during the retrospective, there was little that was able to be changed with the project. Ultimately, the improvement opportunities captured became focused on a micro level, without much tension if something was not resolved.

There were demos, but even with other teams invited, they rarely attended the sessions. Aside from the product owner, there wasn't any attendance from customers or business users who would ultimately work with the system being developed. We were told that they were too busy to participate at this point in the project.

If I Had A Re-Do

With the challenges noted above, I began to explore how I would have changed things. If I were to have the opportunity to work on that project again, I would definitely voice taking a different approach than what was attempted during my time on the project.

Realizing time was the biggest challenge to the project, with budget being a close second place, I would formulate a plan of attack that centered around the following tactics:

Build stories — to define functionality and rules

Assign a degree of complexity to each story — to set delivery expectations

Organize and prioritize the work

Setup a board that is more Kanban style to house the tickets

Utilize subject matter experts for any outstanding questions

The board would contain the following swim lanes:

TO-DO | DEV | REVIEW | TEST | COMPLETE

From there, I would recommend the following flow:

Developer pulls the next ticket at the top of the to-do column

When finished, updates are peer-reviewed and merged

Ticket is then validated by QA team member

If issues exist, ticket is pushed back to to-do column, otherwise the ticket is marked complete

While the flow is certainly more Kanban than anything else, the goal is to keep the flow of work moving forward. Tickets pushed back to the to-do column would not need to go back to the original developer, but could be handled by any other developer, since the code has since been merged. An alternate flow could be that the REVIEW and TEST columns are swapped, delaying the merge until after testing has completed — but that was not suggested initially, since in order to keep the flow of working moving as quickly as possible. After all, the key is to meet the aggressive deadline.

Conclusion

As one might imagine, the project noted above was deployed on the target date. However, the level of functionality delivered included a subset of the functionality and features that were planned when the date was set. In fact, some of the "must haves" just did not make it to the original release.

There were repercussions faced by the organization to handle the fallout from a product being delivered in that v1 state. However, the organization felt like they did the best that they could do, following a longer-than-expected journey to reach the delivery date. I felt good about my contributions on the project — knowing I gave everything I had to help reach the aggressive goal.

I believe that this project provided an example of when Agile adoption is not the best answer. My solution is Agile in nature, but without all the ceremonies and incremental deliveries that are typically associated with the Scrum methodology. While I am not sure if this would have saved that project, I do feel like the feature teams would have made at least 25-35% more progress, simply by keeping focused and staying productive throughout the very tight schedule.