trusting

10 Agile Project Management Mistakes to Avoid [#AgileProject #AgileProjects #AgileProjectManagement]

1. Trying to boil the ocean
2. Resistance to culture change
3. Not enough team planning
4. Too little flexibility
5. Lack of support from the top
6. Incomplete user stories
7. Too much testing
8. Shortchanging security
9. Barriers between teams
10. Not knowing when you’re done

1. Trying to boil the ocean
“It’s a mistake to try to turn everything into an agile sprint or micromanage every sprint. The idea of agile sprints is to empower small groups to ideate and develop while the PM checks in and ensures everyone is on task. Trust in them. Have PMs certified if you have the time. Don’t try to boil the ocean. Trust in your highly qualified and experienced people. Another roadblock might be trusting too much in the process and not having enough touchpoints or end product quality review in place.”
– Shayne Sherman, CEO of TechLoris

2. Resistance to culture change
“The greatest challenge or roadblock for the data team is culture. For too long, the data teams have not had to consult with others. They viewed themselves and were treated by management as insular, not subject to the demands of the enterprise. This is no longer the case. Changing the culture around data service teams will be the biggest challenge. Feedback loops and blameless postmortems would benefit the data services teams, but they are very different from how they do their jobs today.

One of the hallmarks of agile is focusing more on the process and less on the tools. That’s a difficult idea for database professionals. Moreover, flexibility and nimbleness are not exactly words one would use to describe most database teams. But that needs to change now. When other parts of the organization adopt agile, it puts an immense amount of pressure on database teams. The data team needs to respond, or risks becoming irrelevant and slowing down the rest of the enterprise.”
– Robert Reeves, CTO of Datical

3. Not enough team planning
“A roadblock to implementing agile at the team level is underestimating the level of effort and planning needed to get an agile project off the ground. Too many organizations plan their agile strategy but miss the nitty-gritty tactical planning.

The scrum master and product owner are critical roles and should be filled with experienced resources.

First, it is important to field a cross-functional team with all of the skills needed to deliver something of value. Agile teams are expected to work independently, without the handoffs that cost time and quality on traditional projects.

“Second, the scrum master and product owner are critical roles and should be filled with experienced resources. A two-day class does not provide someone with the skills and experience to fill these roles. The scrum master needs the experience to help the team build and mature their practices. They also need the gravitas to influence leadership and resolved systemic blockers. The product owner should have the ability to build the vision, prioritize work to deliver on it, the political skills to defend it, along with a good working knowledge of the product.

Finally, you must work through the logistics to help the team be successful from the beginning. Does the team have a good workspace? Does the infrastructure support the continuous delivery of value every two weeks? Without this essential planning, agile teams will fall short.”
– Alan Zucker, founding principal of Project Management Essentials

4. Too little flexibility
“Agile projects often fall down because of rigid procurement practices. A large organization will appoint a supplier to deliver an agile project, but with a contract that ties them to fixed deliverables. This is at odds with agile, which relies on the team being able to adapt and respond to change, whether in client requirements or in available technologies. More flexible contracts lead to better results, with a fixed outcome to provide a clear direction of travel but with a provision to review progress on an ad hoc basis.”
– Jim Berrisford, chief operating officer for Step5

5. Lack of support from the top
“Too often management either doesn’t understand or doesn’t care about the constraints required of agile. An urgent problem or request crops up and everyone is forced to scatter like ants to redirect their focus before coming back hours or even days later. Management is killing the project flow and undercutting the importance of the project. If unexpected work is a necessary evil, budget a reasonable block into the capacity to deal with the unforeseen.”
– Mark Runyon, principal consultant at Improving

6. Incomplete user stories
“Often when teams sit down to complete estimates for the upcoming sprints, user stories are incomplete. This results in the inability to properly estimate, the likelihood of scope creep, and an inability to deliver what was originally planned for the sprint. Incomplete requirements require lengthy back and forth between the engineering and product teams, thus slowing down the delivery process. Prior to estimating sessions and committing work to a sprint, having complete requirements is essential.”
– Holly Knoll, business coach and creator of The Consultant Code

7. Too much testing
“When developing software in an agile manner, it’s critical to do test-driven development and test every feature before it’s merged into the main codebase. Unit testing and CI/CD allow you to reach maximum velocity in a project and make sure that your agile development moves like a well-oiled machine. With that in mind, it’s incredibly important to find the right balance when it comes to QA/QC and acceptance testing.

We’ve seen, despite the best of intentions, that the gears get gummed up when you start testing against too many edge-cases and imaginable configurations. It is possible to do too much testing!

Especially with greenfield application development, you want to make sure you are doing a healthy amount of testing, but you also want to keep the engineers pushing forward on features. The last thing you want is to reach the end of a project and have a huge backlog of bugs to fix, but you also need to get to the finish line. It’s very likely, if you have a rolling launch strategy and rollout plan where you are only starting with a few users or groups, that you’ll have time then to make the minor tweaks for all your edge cases. Keep your development on track by putting a healthy test plan in place – not too little, but not too much.”
– Ben Wald, co-founder, Very

8. Shortchanging security
“When you’re spending as little time and effort as possible on security, it feels pretty easy. When you’re really good at it and it’s fully integrated, it’s sophisticated and smooth. In the middle stages, though, where you’ve identified improvements to make, found gaps, but haven’t yet created solutions or reworked processes to accommodate security practices, there may be a lot of friction and even a feeling that things are getting worse. It’s a classic Dunning-Kruger effect, and it shows up with security evolution as well.

When making investments in security, recognize progress over perfection. It’s often the simple things that have a large impact. Once those are handled, move to collaborative work across security and delivery teams. In the end, it should be more difficult to bypass security practice and flow than to continuously do the right thing. Security in your delivery system builds confidence and helps you move quickly, and that’s what everybody’s after.”
– Michael Stahnke, VP of platform engineering at CircleCI, overseeing SRE, security, and tooling

9. Barriers between teams
“Ideally, teams should be in the same room when they can be, with plenty of space to break away for formal and informal communication. There should be plenty of whiteboards to work through problems and architect out solutions.

Team members should be focused on their slice of the project. If they are providing support to past projects and juggling other projects, it rarely leads to a successful agile team. The focus, communication, and coordination all suffer when team members are stretched thin across different projects. Basically, all barriers that are sitting between your teammates and their success must be removed.”
– Mark Runyon, principal consultant at Improving

10. Not knowing when you’re done
“In our daily work lives, we work towards the first definition of ‘done,’ but how do we know we have reached the end? An engineer will tell you there are always more enhancements that can be made, and a product owner will tell you there will always be more features that could be added. For a project to be successful, the end – this elusive ‘done’ – is something that everyone on the team must define, communicate, and agree to.

Because it was built to adapt to changing requirements, agile makes it easy to adjust your approach to high-priority issues. This is especially important in fast-paced businesses where requirements and industry climates change quickly. Working with agility gives you more flexibility for change and directs teams to focus on building the most essential features – but it’s also important to recognize when to move onto the next project.”
– Ben Wald, co-founder, Very

Adapted from
Agile project management: 10 mistakes to avoid:
The Enterprisers Project