admin
I am an avid agile fan and hands on agile program manager. I started my journey almost two years ago, and my team and I have learned some valuable lessons along the way. Currently we have doubled our velocity and increased our skills as a well oiled agile machine. Have we have issues? You bet. I am hoping you can learn some valuable lessons from my experience. Here is a list of Top 5 Agile Pitfalls:
Top 5 Agile Pitfall #1: Lack of Integrated Software Testing
Lack of integrated software testing is especially dangerous when companies have multiple products and are running multiple agile teams. The agile teams are often heads down and focused on their product only, and don’t have the time, energy or effort to understand how the systems interact with each other and what potential pitfalls are downstream. Most systems have dependencies with each other in terms of data or interfaces. Product teams today have subject matter development and testing experience, but may not understand other systems and how those interactions. If there are understood impacts, the responsibility usually is handed over to the team who is responsible for that product. It usually occurs with little to no planning, and typically little warning is done in advance. Something to the effect of: “hey can you perform some regression test this feature real quick and make sure it works, and provide me a sign-off before the end of the day since we are releasing into production tomorrow?” If you are in testing and a part of an agile team you understand that agile has a lack of integrated software testing.
Agile software development works great for the most part, but there are some pitfalls that will happen. Agile works well with a single product because there is essentially no integration points, however, most enterprise systems are going to have integrations with either other internal applications or third party applications. It is not sufficient enough to assume that is it is the responsibility of another product or team to ensure the quality is going to work from an end to end perspective. You certainly don’t want to have your business partners or end customers find out that something does not work properly.
I currently manage an agile team and my direction to them is to get the necessary access to all the interfacing systems and run the test to make sure it works properly. Our application is the upstream system, so if something goes wrong, we will be the group that will be held accountable, regardless if it is our system. Sure, it takes additional time and effort to perform that testing, but as long as we account for the work in the sprint, we are covered. I would much prefer to test it ourselves and be sure rather than suffer the consequences.
I encourage you to eliminate agile pitfall #1: agile has a lack of integrated software testing. If you can avoid this pitfall, you and your agile team will be successful!
Top 5 Agile Pitfall #2: Too Much Technical Debt
Using the agile methodology, software can be developed very quickly, in fact, business needs demand it is produced as quick as possible. While there is nothing inherently wrong with that, it is important to develop it efficiently. Agile teams want to build the best designed and highest quality product possible. However, that isn’t always what happens. My team has recently been involved in leveraging a COTS product called Globalscape to consolidate all our B2B file transfer systems into a single solution. In fact, our company was acquired, so between both legacy companies we had four solutions which were being used. We selected Globalscape, but the product was brand new to our team. We didn’t have extensive experience but were driven to move off the other systems. We made the best decisions that we knew at the time, but looking back, there were some things that if we had better information and experience with the product, we would have certainly done differently. Naturally, we accumulated technical debt, and we created stories in our backlog to handle those. In certain sprints, we had to put more technical stories in place to implement the necessary changes. While our business partners weren’t thrilled, they understood those needed to be done.
In some situations, you can address technical debt issues as you are addressing stories in the backlog. For example, with our file transfer product, we created a generic function to address how email notifications were delivered, which was much more efficient. While we were moving other B2B files into the new platform, we would go ahead and make those changes, so that we would not have to revert and make those technical debt changes later.
It is also a good idea to keep 5 to 10 percent of your sprint capacity available to handle technical debt issues. If you have one story per sprint handling technical debt, then it will make it a lot easier in not having to deal with too much technical debt later.
Hopefully this real world example will help you avoid Agile Pitfall #2: Too Much Technical Debt!
Top 5 Agile Pitfall #3: Agile Team Silos
Let’s face it, in most enterprise level software organizations, if you are practicing agile, the agile team that is developing a specific product is going to be focused on one thing: the outcome of the product they are developing. While there is nothing inherently wrong with that, there is a dangerous pitfall that can affect the whole organization. The agile team can become a single silo. I have seen it first hand, and I know it happens more often that agile experts would like to admit it. Each agile team has pride in the product they are developing. They want to be the best team that produces the highest software product. Sometimes the team can put on blinders and be so focused on meeting their sprint milestones, that they will completely forget about how their product integrates with other products and what the downstream impacts are. Some teams can even become selfish and demanding toward other product teams and expect teams to do things which are not inherently their responsibility. Agile software development at the enterprise level often creates these silos. Contests between teams such as awards given out for the best team, can arbitrarily create silos, and thus driving perception that agile teams can be self sufficient and they don’t require collaboration between teams. This is really dangerous. It is important to have an enterprise level view, and keep the big picture in mind. Agile teams work for one company, so that always needs to be the focal point so that the company will be successful. The companies that avoid pitfall #3: agile team silos and keep the company in mind, will be the most successful.
Top 5 Agile Pitfall #4: Too Focused on Agile Team Roles
Agile teams do a really great job of focusing on delivery. Each agile team typically has a Scrum Master, BA, Developers, and QA resources. There could be some variances to those depending on how your organization uses agile, but those are the most common. Each role typically has tasks and duties that are consistently carried out during the sprint. Here are how we currently use the agile team roles:
Scrum Master: The role is responsible for helping to keep things moving and helps to overcome obstacles
BA: The glue of the team. This role helps to keep things defined and assists providing knowledge to the team
Developer: This role helps to build the product and provide technical design and solutions
QA: This role helps to ensure the product is working properly and works to identify product defects
Inherently in the agile process, these roles help to get things done on the team. Sometimes, this can cause issues and the scrum master will need to step in and remove blockers. Most agile teams are fairly small, usually from 6-8 team members. During a sprint there might be some resources who need to take an unplanned absence or vacation. This often will require that other team members step in and perform other roles. My team does a great job in jumping into other roles when the person who normally performs the role is either busy or not available. You will typically see a BA jumping in to help with testing, a QA resource jumping in to help with BA work, and a Developer jumping in to either help the BA or QA resource. This helps to keep things running smoothly and keep the agile goals on track for a given sprint. I have also seen the other way, where a QA resource may take off during the first and second week of the sprint, and the team waits until the person returns to get everything completed in the last week. That is simply asking for trouble and it usually results in stories not getting completed on time.
Avoiding Agile Pitfall #4: Too Focused on Agile Team Roles will help set your agile team up for success!
Top 5 Agile Pitfall #5: Folks, It Isn’t All About Velocity!
Perhaps one of the most valuable lessons for me personally was to understand it isn’t all about agile velocity. There are other items that are more important, with one of those being quality. Now, my agile team has successfully doubled their sprint velocity over the past year, which is a tremendous accomplishment. We have some very aggressive targets because we were consolidating systems into a single platform and those were date dependent based upon some licensing renewals.
Our organization was acquired by a smaller company and they were determined to put an agile product model in place. I viewed this as a tremendous opportunity, and I was responsible for managing one of those teams. There were certain measurements the agile teams were rated on and one of those was agile velocity. Agile velocity is important because it helps you be able to predict how much work you can consistently implement within a given sprint. Our initial targets weren’t too aggressive, so we were able to consistent deliver on what was planned sprint over sprint. The agile team began to experiment and I really challenged the team to go above and beyond and it was too much for the team to handle at that point, so we ended up dialing back to a more realistic target.
While Agile Velocity was an important metric, we failed to ensure that one of our stories was working in production before we started the next sprint. This resulted in a pretty major quality issue which we eventually recovered from, but the agile team’s reputation was tarnished at that point. It took several months for us to regain our confidence and move past this issue. My most humble recommendation is that your team focuses on all the different elements, especially quality so that you won’t have issues down the road so that you can avoid: Agile Pitfall #5: Folks, It Isn’t All About Velocity!
I hope this information has been helpful and I believe you can gain some valuable knowledge about how you can avoid my Top 5 Agile Pitfalls.
Ron Wilson