The agile development revolution is certainly catching on. According to the 7th Annual State of Agile Dev Survey, of the approximately 4,000 companies surveyed, 83% planned to implement agile in at least some way within the next year, up from 59% the previous year. It sounds great on the surface, but there are some choppy waters to navigate on the path to success. It is no secret that agile has its own group of skeptics and those who attempt to discredit the movement. It is time to face those fears and realize it’s not always the process that failed, but often how it was executed and what could have been done to avoid it. Learning the lessons of the past will ease the path to success.
Why Agile?
If you are still on the fence with the agile process, there are several excellent resources that cover the topic. Credera’s own Kevin King and Brad Buhl have addressed the subject. In addition, a survey by Dr. Dobbs of over 500 developers and managers after successfully adopting an agile environment indicates that productivity, quality and customer satisfaction all increased in most cases, with either an improved cost or no change.
When successfully adopted, agile can be a great way to do business. It addresses many of the challenges of an organization with changing priorities, makes the design process more collaborative, and focuses team members on the end goal.
Pitfalls When Switching to Agile
What issues are you likely to face when implementing an agile approach?
Not Educating Stakeholders Outside of the Core Team
So the developer team has the mechanics of the scrum down. Great! But have the sponsors, upper management, and customers been educated on the process? If not, their expectations and efforts will be closely aligned to traditional methodologies. By involving key leadership from the start, it will be easier to remove any corporate “barriers” and ensure leadership members partner with engineering to succeed.
Not Educating the Core Team
Do not assume that all developers understand agile. Many may be used to an older model where they are handed a spec and then just code. If a team does not believe this approach can work, their chance of success is very limited. By playing off early successes the team can begin to build stronger confidence in the method.
Fear of Failure
A failed sprint is not the end of the world. It frankly gives clarity for the future and should not be frowned upon unless it is consistent and unjustifiable. This can be a difficult concept for corporate cultures to accept, as it is common for failures to be hidden, not openly exposed. Not to mention, what developer would ever want to admit their code wasn’t perfect the first time around? Ensure that all the parties involved value transparency, not just the core team. Failures will almost always contain more lessons than successes. Be sure to capture those lessons and improve for future iterations.
Assuming That Agile = Faster
One of the first things people assume is that agile means quick. That is certainly one aspect of agile, but it comes from not having the extreme cycle back and realignment associated with traditional waterfall. Consider agile to be the nimble gazelle darting towards the correct prize.
Estimating/Design Pitfalls
Assuming That Velocity is Equal Across Teams
Not every team can match the pace of your all-star team. If your top performing team is averaging 60 story points per sprint, assuming another team will have the same pace is going to create problems.
Planning Every Iteration for the Project In Advance
This is just slapping agile names on traditional practices. The whole point of agile is to expect and allow for change throughout the process. While this plan can be a loose guide, be ready for things to realign along the way.
Estimate Anchoring
Without using a system such as Planning Poker, groupthink and other problems tend to skew estimates and make them biased.
Overcommitting Velocity
Most people are optimistic about their abilities. The problem is that an overly hopeful plan is likely to fail. Team members must account for testing and cycle back when looking at sprint velocity.
Trying to Estimate Velocity Perfectly
Is the team spending more time estimating and planning than actually developing? These overbearing support functions are searching for precision when failure can shed light faster.
Planning for Longer Iterations so “More” Work Can Get Done
One of the main reasons for keeping sprints tight is that you want to be able to reassess priorities and values often. This allows a project to realign before it drifts too far off track.
Forgetting Artifacts
While most people associate agile with having zero artifacts, the realities of business are that there are probably a few items that must be produced. Is there a need for training materials? Are there any guides that need to be produced? Maybe the team can actually complete that lessons learned document for once.
Development Pitfalls
Seeing the Tree but Not the Forest
The scrum master and product owner need to ensure that the team keeps their eyes on the end goal. While creating a ridiculously awesome function that validates user entry real time is challenging and fun, the customer still needs to be able to complete an order on the ecommerce website.
Completing Sprints While Leaving Behind Technical Debt
In an effort to complete a successful sprint the team takes shortcuts that they know are going to bite them in the future. Quality applies to the product as a whole and needs to be focused on during each task.
Problem Solving in the Daily Scrum
The daily scrum has a wonderful purpose. Many others have delved into the art of conducting a productive meeting. This meeting though is by definition short so that people can start getting things done. Traditional meetings are often counter-productive and most likely do not require all people in the room.
Scrum Master as a Contributor
The scrum master’s job is to maximize the potential of the team while communicating effectively with the product owner and other stakeholders. While it is tempting to jump in and take over tasks, this hinders their ability to give proper attention to the team.
Assigning Tasks
“Jack is the database guy and Jane is the JavaScript girl.” Specialization is tempting and sometimes very helpful, but a sprint is not planned with balancing task distribution in mind. If Jane finishes her three one-story-point tasks and Jack is toiling away at his first 13-story-point task, she should be free to jump in on database task two. Earmarking items for certain resources reduces throughput.
Product Owner Mismatch
The product owner is key to the overall success of an agile initiative. The right product owner is:
Highly available –They must be available to the team throughout the entire project
Knowledgeable – They will ultimately steer the direction of the project, and thus you must trust their guidance to build the correct software
Empowered – They not only need the information to make accurate decisions, but must also be able to make them for the organization
Adding Stretch Goals to Sprints
These are the “nice to haves” that are not planned but at the same time are planned. If the team thinks they can do it, add it to the list. If they can’t get to it, then it goes back on the backlog. Consistently missing stretch goals can be demoralizing to the team while having no bearing on the project. Stretch goals can also be misconstrued as they filter up the hierarchy and turn into hard requirements.
Individual Heroics to “Save” the Sprint
Temporary heroics, while noble, can incorrectly add to future expectations. This faux-velocity turns into unrealistic demands in the future.
Development Team Organizes Product Backlog
While they may have some valuable input such as one needs to come before two, they do not determine value to the business or customer. And even if they are preset, those values can change over time and need to be reexamined.
Product Owner Specifies Solutions
While the product owner in an important stakeholder, they need to allow the engineering team complete freedom to come up with solutions they believe are best suited for the problem at hand.
Not Allocating Enough Time for the Demo
Presentations seem easy compared to reengineering a complex solution, but they are more difficult than most people realize. The team has to prepare and test the path that will be visited in the software.
Using Metrics to Measure Productivity
Metrics such as velocity or number of story points completed in a given sprint are not a good measure of productivity and using them as such could lead to the team “hacking” the system by overestimating stories.
“Duck-Taping” the Demo
Building a demo of this sort misrepresents the true state of the work. This gives people higher up a false sense of security and does not allow them to plan properly. Additionally, people can often see through these efforts as any deviation from the script produces undesirable results.
Giving up on Quality Because of Imposed Deadlines, Scopes, and Resources
Everyone can agree that this is a bad practice, but it still occurs far too often. “We can fix the quality later” is indicative of a project that has gone off the rails.
UAT & Release Pitfalls
UAT Scripts are Developed at the End of the Last Sprint
This issue is a manifestation of the earlier idea of not seeing the forest. If you do not know what your goal is, how can you achieve it successfully?
Giving up on Test Coverage Because of Imposed Deadlines, Scopes, and Resources
The first two words of this pitfall say it all. “Give up” should not be part of the team’s vocabulary. This is often a problem associated with initial estimates. Do not add unnecessary risk by deciding not to do this step.
Product Owner is not Engaged in Reviewing All Test Scripts
If team members are going to invest time to create test scripts, make sure they test how the users will actually use the product.
Looking Ahead
It is up to developers to continue to help carve the way for future agile projects and developers. Remember, there is always someone who is more experienced with agile and more than likely they will be glad to help point a colleague in the right direction. Training is also fundamental to a successful team so ensure all members have the proper foundation before beginning.
Don’t get discouraged, it takes practice to make perfect, and agile is certainly no exception.
Be sure to follow us on Twitter or LinkedIn for more great tips. Have a question related to agile? Use the comments section below to join the conversation.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
