Agile vs Waterfall – Transition Challenges

If your department or company moved from waterfall to agile software development, you know all too well that the transition comes with a fair amount of struggle.

At a recent meetup I attended*, professionals from around the MD-DC-VA area came together to discuss the challenges they currently face to seek advice and support from the group.

Based on these roundtable discussions, here are some of the challenges agile development teams face and possible solutions for combating them.

Challenge #1 – PMO Is Still Trying to Translate Everything Into Hours Spent

One of the biggest struggles new Agile teams face is that some people still think in the Waterfall mindset. A cultural shift is truly necessary when making the transition and a need for increased patience while working towards this new thought process will be required for not only this challenge, but really most Waterfall to Agile transition challenges.

All that being said, the desire to mark each task in hours spent is a hard habit to shake. Waterfall is all about assigning a specific time, budget and scope (Triple Constraint) to every project which then trickles down to every task, because if you only allot, say 40 hours start to finish, then every little task that involved in this project needs to equal 40 hours.

Agile prefers to timebox projects and iterations or sprints. While it seems similar (hence the struggle) it really isn’t the same. A project can be timeboxed to a year with various sprints involved each averaging a 2-week timebox.

Now while you are told you need to produce a fully-functioning deliverable at the end of the sprint, there is no specification on whether your team spends 10 or 80 hours collectively to ship to the customer at the end of the sprint.

So now that we understand the challenge a little bit better, how do you respond to the request for hours spent? One panelist said always start with ‘Why.’ Ask your PMO why do you want to know the specific hours per task. Often times it will be for budgeting purposes. As long as you have a broad understanding of how many iterations it will take to deliver the final product you can offer a budget based on the calculation below:

Annual loaded cost of an individual team member / # of estimated iterations in a year = fixed burn rate per iteration per employee

Find out the burn rate for each member of your team and then add all of those numbers together and you get your team’s fixed burn rate per iteration. Then multiply by how many iterations you think it will take.

These calculations also help when team members report obstacles during a stand up that need to be added to additional iterations or if a customer asks for additional features that require iterations. Budgets can be roughly assigned to each of these situations quickly based on your team’s fixed burn rate calculations.

Solution Review: Ask why hours are being requested and be prepared to respond to questions regarding budget. As a Scrum Master or Agile Team Lead, you need to be able to effectively calculate the cost of your team’s time even if you are not tracking each individual hour spent on a sprint’s tasks.

Challenge #2 – How to Effectively Manage Distributed Agile Teams

Communication, communication, communication. The resounding theme of this answer really hinged on the fact that Agile teams need to be able to work just as the name implies. If you cannot easily communicate with a team member it throws the whole project off track.

When the agile approach first came into existence, the thought of having your primary agile team distributed across various locations seemed very much against the method’s creed. However, in today’s society having a team that is all together, all the time is virtually impossible.

When managing a distributed team the first thing that needs to be established are the available communication methods. Communication can be facilitated through:

• Live chats
• Videoconferencing (Google Hangouts, Facetime, etc)
•  Collaboration tools such as SharePoint, Trello or ]project-open[

Then team members must agree on a time frame (a four-hour block usually works best) that they are all available and institute that time period as the opportunity for instant collaboration.

While some people do not feel comfortable having a camera on them for four hours every day, I do suggest leveraging Google Hangouts for the daily standup. The reason is simple, you can limit the people who can view it only to your team and it automatically creates a private or unlisted video on YouTube so you have a complete and detailed archive of every minute to refer to with questions. Additionally, keeping detailed task notes through the collaboration tools you use will also help keep everyone connected and moving forward on a sprint.

Since the mechanics of when and how you will communicate should be determined by now, the next part of using communication focuses on generating trust among your team. Agile teams are close-knit communities that need to constantly be working together and like any group of people, if you have even one individuals who does not trust the rest of the team, then inevitable major problems can develop.

Take time during your collaboration hours to address the team in a lighthearted and personal way. Conversations shouldn’t just circle around business, but that is often the case with dispersed team communication and the biggest factor inhibiting relationships of trust being built.

Additionally, when a new team member needs to be incorporated, focus more on how that person meshes with the existing team versus relying solely on a resume or recommendations. So long as the person meets your skill requirements, the real focus needs to be on how quickly can your existing team accept this person and build the trust necessary to get back up to speed.

Solution Review: Communication is key. Find the combination of software, tools and hours in the day that work best for your team in terms of facilitating conversations. Remember, well functioning agile teams are a huge part of project success, but the lack of trust among dispersed teams can inhibit that. Leverage personal communication throughout the day to lay a foundation for a deeper and more trusting work relationship for your team.

Challenge #3 – Agile Thinking is Not Present in Other Areas of the Organization

This problem comes into play when it is time to review an agile team member’s work. Agile is meant to be team-based and, as such, successes and failures are absorbed as a team. However, when HR or upper management is ready for annual reviews they often stress an evaluation system that ends up ranking individuals and not the whole team. This is the problem.

Reviews stress a “me” mentality that shows how great or terrible an individual is while agile fights to preserve a “we” outlook. In order to combat this problem, the need for converting the waterfall method of thinking in challenge #1 holds true.

It is up to the team’s leader to really stress the success of the team as a reflection of individual strengths. Historical data is very helpful here as it can show a team’s progression from when they first start to the present and how their work evolved to display improved iterations in terms of effectiveness and efficiency.

This data is also good when management divides up a successful agile team. Showing this improvement and understanding the positive changes that arsse from a well-compatible agile team helpfs in pitching a case as to why a team should remain together. Anyone who works with a functioning agile team understands that the trust and bond of fellow team members has a positive effect on how an iteration flows and achieves the stories it outlines.

Solution Review: Educate others on the methodology of agile and don’t be afraid to back up your arguments with data points that your team has achieved together and predictions for a decrease in iteration efficiency should management mix up your group.