You might think that implementing Agile for law enforcement agencies (LEAs) is easy, but let me challenge that thinking. It’s not easy for a product owner (PO) implementing Agile for an organization that deals with LEAs. I am a lead business analyst for an IT firm, and we have a variety of products for India’s LEAs.
Because law enforcement agents are the smartest and most talented in our country, they are also the most difficult to tackle. In most cases, the released working software after a sprint does not meet their demands. Though we have the three pillars of Scrum, namely Transparency, Inspection, and Adaptation, a fourth pillar — Communication — is a must for LEAs.
This article is not about the principles of Agile/Scrum and how to apply them to LEAs; rather, it’s about my six years’ experience working in this industry sector. To implement Agile for LEAs, you must focus on four common best practices, which I believe are also the most important ones.
Agile best practices for LEA customers
Follow these best practices to facilitate your Agile implementation for LEAs.
Being too vocal could skew stakeholders’ perspectives. However, a PO can’t be “too specific,” as it can avoid consuming more of the stakeholders’ time than necessary to illicit critical information. These stakeholders are brief in everything they tackle and are very precise too. A PO or a business analyst should be smart enough to capture the most important user stories and quickly but carefully prioritize them. And believe me, they won’t tell you everything, since they strongly believe in being self-taught.
Prioritize the prioritized
In Scrum, we prioritize user stories for the sprint that we believe are sprint-ready
. However, the prioritized user stories should again be prioritized if you want your sprints to end without any user stories rolling into the next sprint. It sounds obvious, but you need to be one step ahead than your stakeholders. For instance, we have developed a method we termed as “Sprint -1” before Sprint 0, in which we release a small feature that the stakeholders have requested. This may seem uncommon compared to the cadence that we usually follow in Scrum, but Sprint -1 helped us significantly in a few of our projects.
Avoid detailed documentation
Avoiding detailed documentation probably applies more to a business analyst, because this individual is the one who typically creates lengthy documents. But if you have stakeholders for whom national security is their first priority, avoid detailed documentation. They will not risk their time to read those documents because the effort would add no value for them, even if your document is worth reading. We used a simple technique to counter this. We created PowerPoint presentations of not more than 3–4 slides, and we used bullet points for items that needed emphasis or attention. It saved us time and increased our efficiency.
Collaborating with stakeholders might be the most challenging task for a PO, as these stakeholders will rarely be available. You need to get to the right person, at the right time, for the right reason. We all accept the fact that this is the worst part for us. Following are the reasons for project failure:
- Improper/incomplete requirements gathering
- Insufficient budget
- Unavailability of stakeholders
Collaboration will help overcome these issues. We have done the root cause analysis and discovered that some stakeholders were not interested in participating in meetings because either the project was not a concern or they were not willing to give any information. The key here is to generate interest for them, which is, again, one of the biggest challenge for a PO.
You can successfully implement Agile for LEAs if you can follow the aforementioned best practices. Scrum is best suited for all types of projects, as you release features every two to four weeks. However, avoid four-week sprints when possible, because they can introduce delays and change requests.