Blog

Blog

June 28, 2016
Technology Solution Delivery

Agile Flexibility

Does the term Agile Flexibility sound redundant to you? To those familiar with Agile Development, it is implied that Agile practices will allow for flexibility… in theory. In practice, this is often not the case. Have you ever heard these comments?

  • “We can’t extend the sprint, that’s not how we run Agile here.”
  • “All team members, regardless of their IT division, need to be involved in this sprint.”
  • “Where is my project owner? Why aren’t any business people in this Scrum?”
  • “You can’t run multiple sprints at the same time.”
  • “We don’t do Agile; we only use the Waterfall Model.”
  • “This project is all or nothing, Agile just doesn’t make sense.”

I have personally heard all of these even though the projects that I’m managing are cosmetically using Agile methodology. In actuality, a Hybrid Agile Methodology is being put in place.

Hybrid Agile or Agile Flexibility

What is the difference between Hybrid Agile and Agile Flexibility? Agile is, by definition, flexible. An organizational move from traditional Waterfall to Agile is a transformative experience and with that often comes resistance from impacted parties. Often the most experienced resources are hesitant to try this new approach due to its new tools and frequent meetings. Deviating from tried and true methods in the eyes of the seasoned veteran presents a cavalcade of risks. A Hybrid Agile approach allows for teams that are currently using Agile to continue using Agile and gradually blends the traditional Waterfall teams into the mix in the latter stages of the project. I like to think of it as a fairly simple, transformative process to introduce Agile to Waterfall champions. For example, I often use multiple longer duration, concurrent sprints at the onset of a project. This works well with the Waterfall experienced teams. Eventually, these sprints merge into combined sprints as the project progresses, molding into a more traditional Agile structure. With large projects, I also like to leverage “Scrums of Scrums” in the early stages of the project, to keep teams aligned. A “Scrum of Scrums” brings together representatives from the various sprints under one roof, allowing for information sharing, collaboration, and innovation.

Agile Transformation

Now that we’ve covered what Hybrid Agile is, let’s look into how you can use it for Agile Transformation—the methods used to adopt Agile Development. I would like to share with you a recent Hybrid Agile approach that was extremely successful in Agile Transformation. The approach was applied on an eight month (32 week) project that involved five independent IT teams; two that used traditional Waterfall methodology and three that used Agile Development. The initial sprint structure for the first fourteen sprints was set up using concurrent sprints where the three Agile teams combined in traditional, two-week sprints, and the Waterfall teams were allowed to run individual, concurrent sprints with longer lengths of 4 to 6 weeks. This lasted for about six months, and gave the teams new to the process (i.e. the two Waterfall teams) time to learn Agile tools, become familiar with daily Scrum and stand-up meetings, and the stakeholder reviews of requirements, retrospectives, plans, and backlogs. By extending sprints to four to six weeks, the learning curve around Agile meetings and tools was much easier to handle. Over the final nine weeks, the last three sprints were positioned as a final merge or blend of all of the teams. Amazingly, the traditional Waterfall teams embraced the Agile methodology about two months into the project (roughly midway through the second sprint), and by the time the sprints were merged, several of the traditional Waterfall team members became such strong supporters that I considered them “Agile Evangelists.” That is, instead of taking the expected six months to adopt Agile, the traditional Waterfall resources embraced it within two! By allowing extra time and presenting Agile in small steps, the traditional Waterfall teams not only had the time to learn the tools and the methodology, but were also able to experience the value of Agile Development—concise design documentation tools and processes, more rapid QA cycles, immediate feedback, and regular interaction with business teams. Once directly experienced, the walls of resistance to Agile quickly . You can see the timeline of the project below:

Putting Flexible Agile to Work

So how do you get going with Agile Development? One way to build organizational momentum is to communicate a core concept of Agile Development–the Minimum Viable Product (MVP). The MVP is a concept that uses continuous software releases at the feature level, releasing products as soon as it fulfills foundational requirements. This puts the product into end-users’ hands sooner than traditional Waterfall projects would, allowing their feedback to drive subsequent development. It is the most compelling reason for traditional programmers to adopt Agile methodologies. To see your work moving into production using timely software releases following manageable blocks of effort is measurably rewarding. Employee morale and motivation often increase in Agile, because this reward of production-ready code is frequent (monthly or even weekly) as opposed to the longer traditional Waterfall cycles. Furthermore, communication between technical and business teams, often a challenge at first, becomes rewarding and enjoyable. Agile breaks down the communication barriers that often exist between business and IT teams. Agile groups quickly realize that the two organizations are working together toward a common objective. Face-to-face scrum and stand-up meetings, as well as the backlog grooming, retrospective analysis, collaborative planning, and regular stakeholder meetings allow personalities to shine and bonds to form that may not have previously occurred. On many occasions, I have witnessed programmers and business managers that had been sitting on the same floor for years without speaking become trusted work partners, even fostering friendships and socialization outside of the work place! Agile breaks down social barriers as well as business and technical barriers. Yes, cats are playing with dogs, and now white coats and blue coats can eat lunch together!

To discuss Agile development concepts and Agile transformations, contact us at info@kenwayconsulting.com.

How Can We Help?

REQUEST A CONSULTATION