Adoption of the Agile methodology is among the most significant shifts in project management and software development over the last decade. And for good reason. Agile's iterative nature and repeatable cycle of design, test, deploy, delivers new products, tools, and features in end users' hands faster than conventional methods like waterfall.
But like other radical shifts in business operations and mentality, adopting Agile isn't just something you do willy nilly. It requires extensive planning and strategy to implement it properly, which is why many organizations turn to third-party agile experts to make sure they're covering all the bases before making the leap.
But what happens when the advice around Agile isn't solid? What if it's incomplete or, worse, wrong?
Here's how bad technical advice can derail your Agile plans and make like more difficult for your team rather than making it easier:
Overly Complex Workflows
Workflows with a ton of statuses may seem like a good idea, as it gives you a more granular and detailed look at where everything sits at the moment. But doing so makes your Agile board look messy, confuses users, negatively affects application performance and requires a lot more administrative steps to ensure everything is in the right status — which totally defeats the purpose of Agile in the first place.
Sound advice:
Workflow statuses should clearly represent the stage of the work and not be confused with work ownership changes. Many teams fall into the trap of designing their workflows with excessive statuses for the reason that there are many participants (e.g. teams) partaking work within the process flow.
Try to limit your workflows to just 5 statuses, and use broad terms to define a status versus granular terms.
Just Display Everything on the Board
In some instances, bad advice leads to boards that display virtually all issues within the project. And while this may be OK at the start of the project when the number of issues are low, it can be a problem as a project progresses.
For many teams, the user experience of their agile boards is directly impacted by performance. Many don't realize that the volume of issues returned by the filter query that serves the board can grow significantly over time, leading to longer load times —up to 75 seconds! — and in extreme circumstances, may even impact the performance of Jira overall. A board sub-filter may mask this behavior by reducing what is displayed on the board, but won't reduce the amount of data returned by the original filter query.
Sound advice:
Quick filters used in conjunction with well defined workflow statuses can be a powerful combination to segment data based on key attributes like priority and ownership. This is a good approach to maintaining a tidy board.
Just Move it to the Last Column
Another common mistake teams make is misunderstanding how releases work in Kanban boards. It's quite common to see Kanban boards with over 500 closed issues in the last column without any being formally "released". Releasing an issue is critical to maintaining project clarity and board simplicity, but failing to properly do it will degrade the board's performance (speed and availability, mostly) and creates clutter.
Sound advice:
Clean up your boards regularly and release the resolved tickets to keep the focus on ongoing tasks.
Overly-Long Sprint Length
An optimal sprint length is about 2 weeks, but there are cases where they could be shorter, some as short as 1 day depending on use case. There are no one-size-fits-all setting, so this needs to be carefully discussed with the team to understand the team's release and retrospective cycles. But definitely, no sprint should ever be a year long!
Too Many Custom Fields
Having a lot of custom fields in your issues will negatively impact your overall performance. A messy issue view and lack of entry from users — these fields will be intentionally left blank by users — results in less robust reporting, limiting visibility and making decision making more of a guessing game than a certainty.
Sound advice:
The Jira create issue screen isn't meant to be a data entry form. Focus on fields that you absolutely need. Miscellaneous information can be ignored, or handled by a separate form, like the Proforma Forms for Jira.
Also, considering what information is important at which part of the process flow can inform what data elements you should capture, and by whom, at different stages in the workflow. This avoids the common problem of a create screen attempting to capture excessive data beyond what is required at a minimum by allowing data to be captured at a later stage where it is actually needed.
Using Scrum on Kanban Projects or Vice Versa
Despite the common misconception, Scrum and Kanban aren't actually interchangeable. Each has its own traits that can be applied only to a select few projects based on use case and
Sound advice:
Master the differences between Scrum and Kanban and determine which will fit better in a given use case: https://www.atlassian.com/agile/kanban/kanban-vs-scrum.
Good Advice is Key to Getting Agile Right
The rush to reap the benefits of Agile is understandable. Greater efficiency, faster time to market, and superior features in the hands of end users faster can help virtually every business remain relevant and competitive in a rapidly evolving business landscape. But adopting Agile hastily — without proper planning or strategy — and on less-than-solid advice is a surefire way to derail even the best laid plans.
