There is a lot of excitement around moving to agile methodologies. It is definitely enticing when one hears the stories of success and of how quickly things get done.
The agile manifesto states the following four basic principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is Agile methodologies value the items on the left more than the items on the right.
Switching to Agile methodology is a challenge to any large organization accustomed to items on the right.
Making the mindset switch is imperative for a successful switch. Scott’s post “Why Agile Fails” articulates these challenges very well.
By definition a smooth operating team is producing enough software at a level that the stakeholders are happy, and the team doing so in a time frame that gives them a life while enjoying satisfied senior staff overseeing them, but not interfering with how they get their work done.
A badly implemented agile can wear down the teams pretty quick, and give an impression of failure to implement successfully. The key is bringing the mindset change slowly.
The half way switch makes to something interesting, “Wagile”. Many articles tend to project a negative connotation to this term. When I read this blog by Rebecca “Good and Bad Wagile”, it was quite enlightening. Her position is that Wagile can be done well, even may pave a way to an eventual successful “Agile”.
We started with the two-week iterations, daily scrums and co-location. Requirements were still provided up front, and the stuff we planned into our iterations was technical-task level (e.g. write stored procs for x process – 1 day), QA was back-loaded on the project, and product owners were still on the other side of the building.
Perhaps, for teams who are used to “Waterfall”, this is a more practical approach.
This may lead the switch to follow a path similar to this:
Waterfall -> Wagile -> Wagile ->…………………………..-> Truly Agile
However, there are a few key things, to avoid the teams grow weary during the process of the long switch.
- Baby steps, every team does not need to move to the agile mode - These rollouts can happen with smaller agile releases with parallel waterfall releases. This will help the slow moving business teams to align, meanwhile getting curious about “That seems like a faster route, how can we align there?” This may help the biz teams wanting to try agile, rather than it getting jostled onto agile projects by IT teams.
- Smaller teams, co-location if possible - If co-location is a challenge, limiting to 2 locations. These interactions should be carefully designed so that either team does not work during ungodly hours for longer periods. In a global world, co-location could definitely be a challenge. However, modularity of work is definitely possible.
- Dedicated resources to the project - Scott has a very valid comment about the key staff i.e., engineers, product owners, quality engineers dedicated to a single project. If not, this group may spend major portion of their time in meetings.
- Most importantly, gatekeeper(s) to these projects who protect the agility - In large organizations, the responsibility and accountability are divided. The need for multiple statuses, discussions, reviews, slow down the teams. Also, they get distracted from their main tasks. Gatekeepers protect their team and question the need for every meeting, every checkpoint that the team get invited too. They need to be strong individuals who are the voice of the team, and treat their team’s time as the most precious commodity!
As Rebecca mentions, Good Wagile is a great thing.
It’s the first step to being truly agile!