If you’ve been practicing agile for years now, you’ve probably hit a few roadblocks along the way. Here are a few red flags to recognize before you get slowed down:
Problem 1: Not understanding your customers and not knowing your impact.
Our software creates real impact for our customers. If you aren’t able to articulate who your customers are and what impact means to them, or you don’t have a way of measuring impact, that’s a huge red flag!
Problem 2: Having the struggle to launch at a faster pace.
The overall confidence in our team’s capability to deliver high-quality software faster increases every quarter. The absolute purpose of agile is to respond to market faster. If after years of practicing agile you are not able to release faster but just plan faster, you will run into a few problems.
Problem 3: Drowning in technical debt.
At the beginning of every quarter, the quality and integrity of the code has improved and technical debt has gone down. You may have inherited a legacy platform or you may have other valid reasons. However, if you are not able to pay back technical debt your ability to be really agile is going diminish fast and that is a problem!
Problem 4: Your Product, UX, and QA teams are reactive vs. proactive.
This is a frequent problem. For QA, it is the lack of automation and for Product & UX, it is the lack of time and preparation. Your Product, UX, and QA teams should be thinking and acting ahead of your engineering teams by at least two sprints – if this isn’t happening you might want to take a closer look and address it!
Problem 5: Not having time to focus on coding
Except for planning or demo days, programmers should be spending a minimum of 4-5 uninterrupted hours coding on what really matters. It may not seem like a lot to ask, but if you can create the time and space for this kind of focus for your programmers, then you’ll be a lot better off! On average I see programmers coding 2–3 hours max per day, which just simply isn’t enough. Collaboration can turn into annoyance if programmers aren’t able to focus on developing amazing code.
Problem 6: Not looking at sprints as a high impact priority.
Sprints are so much more than completing a backlog of tasks – they’re about execution and having a direct impact. Many of the teams we see get into a boring routine of just finishing tasks and stories – this is the definition of busy work. If you don’t keep the impact in mind, you’ll fall prey to this, too!
Problem 7: Not making sprint demos a priority in your agile teams.
Sprint demos sometimes don’t get the attention they deserve – they should be well-attended and feel like celebrations! I can’t stress this enough. If you are in for the long haul on whatever it is you’re developing, making a big deal of demos is key for boosting morale and energy. If leadership teams and stakeholders don’t make demos a priority, oftentimes teams don’t get the feedback they need, and they can begin to feel deflated and under-appreciated. Big problem!
At InRhythm, we focus on creating high performance agile teams – effectively, efficiently, and strategically. It has become a key component in what we aim to provide, high velocity product development.