Get certified - Transform your world of work today


Implementing Agile for LEAs

18 January 2018

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.

Be specific

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.

Improve collaboration

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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.3 (8 ratings)


Tim Baffa, CSM, 1/19/2018 8:24:28 AM
Sorry Arpan, but this is an inconsistent article in my opinion that, while including some good Scrum practices, also includes some very poor ones.

Firstly, there is no Sprint 0 in Scrum. You take it a step further by labeling one of your sprints Sprint -1. That is also a very bad suggestion; however, the purpose of your first sprint follows a good Scrum approach (what can be delivered to the customer immediately for feedback). Perhaps you should simply relabel your Sprint -1 to Sprint 1, and then go from there?

Prioritization is often NOT the cause for sprint carryover. As a PO, you should feel free to offer any number of items to your team(s), even ones that do not meet a Definition of Ready (FYI - DoR is not in the Scrum Guide). It is up to the team to then make their forecast based on your offer, and their understanding of team capacity, velocity, capability, etc.

Good approach on being brief and focused in your discussions and presentations with your stakeholders (i.e. - 3 to 4 slide powerpoints).

There are many more reasons for project failure other than ones you listed. How about overestimation of capacity? Everything may go well up until the work begins, but an overaggressive (unrealistic) target date can doom a project before it begins.

You state that your article is not about applying Agile/Scrum to LEA's, but a recap of your 6 years' experience in the LEA sector. However, you title the article "Implementing Agile For LEAs", you write the article highlighting 4 best practices to follow for Agile implementation with LEA's, and you conclude by stating that following the best practices will lead to a successful Agile LEA implementation.
Arpan Rewatkar, CSPO, 1/19/2018 10:31:27 PM
Hi Tim! Thank you for your comments. Point noted.


Actually regarding 'sprint -1'(I accept there is no such thing as Sprint -1; just as we named it & followed it) I'm not pretending that we should follow this strategy every time. We were compel to adopt 'Sprint -1' in only a single project and for just 2 sprints since the requirements were immensely vague for us and reasons like unavailability of the concerned stakeholders et cetra. (We tried many times but you can't reason with country's most smartest, talented and intelligent people; since they defend our nations)

Regarding 3 to 4 slide powerpoints, what can you do if your stakeholders are preoccupied and flatly refusing for any collaboration. We have tried that way but things didn't worked for us.

I have decided to name this article 'Implementing Agile for LEAs' and I'm stating that the article is not about applying Agile/Scrum. Now I'm contradicting myself.

What I tried to share here that we would have not followed the traditional principles of Agile or so but we went the way beyond agile and at the same time delivered value to our stakeholders by being agile.

In my opinion there is a striking difference between being Agile & doing Agile.

Sometimes you need to improvise your Agile/Scrum model to suit your stakeholders. In India things are certainly different in the context of LEAs.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up