This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.
“The analysis of the principles of methods, rules, and postulates employed by a discipline”
For software companies these days it seems that it’s not a hard choice to follow Agile principles. With some practice, or hiring a consultant, you can learn Agile practices and employ them as well. It’s an entirely different animal to decide you are going to use Agile practices in a regulated environment though. If you choose this route you must understand that you are on the leading edge of the rest of the industry. Here are some questions you should know the answer to before you can get started:
What is Right for My Organization?
Most companies operating in a regulated environment are comfortable utilizing traditional software practices. This is often a waterfall approach. However, it may not be. Most Agile practices are not new – they are what good software organizations have been doing for years. Before you decree “We will be Agile” take a look at what the software organization is doing now. Do an inventory of the practices they are doing compared to something like Kanban or Extreme Programming. Before changing the process for process sake, ask yourself: Are they meeting deadlines set? Are you happy with the products they are creating? Does the overall organization seem happy with the software group?
If the software group isn’t delivering then using Agile practices can be a proven tool one can use to solve the problem. That being said, some organizations are extremely resistant to change. Being transparent, working collaboratively, and focuses on delivering software regularly can hard for somebody who has spent their career doing the exact opposite. In this case, Agile may not something everyone can embrace easily.
How fast can the organization move?
Eventually, a team that embraces Agile principles and practices is going to start moving faster than before. Make sure the rest of the organization understands clearly what is going to be expected of them. This will require open communication and transparency by your team. There is no need to have a rockstar team that can’t move forward because the backend team isn’t able to deliver dependent software within your schedule.
Do I know enough about Agile?
My experience is that the most popular Agile templates out there (Scrum, Extreme Programming, Kanban, Lean) don’t directly lend themselves to building software in a regulated environment. This meant are you going to be bending and breaking the “Agile” rules a bit. Before you can make your own path you must fully understand the “normal” path. Make sure you have significant Agile experience or hire that experience in before you start something difficult and try to expand on it.