ALM Series – Part I: Let’s Get to Know Each Other

This is the first blog post in a series about ALM. I have been a developer for many years (oh so many years), and ALM is very close to my heart. I’ve learned from experience that with good ALM, your chances of success increase considerably. Conversely, without it, you’re probably going to fail. I’m a huge fan and I want to share it with you. I’m going to tell you why you should care.

ALM, or Application Lifecycle Management, is the glue that holds your project together. Without ALM, you run the risk of your project being like a boat without a rudder. If your bright shiny new BMW has no steering wheel, you’re likely to run into a ditch before you’ve even left Munchkin Land.

If you’re leadership, you should be putting sound ALM practices in place. If you’re a developer, you should be asking for it. It doesn’t matter what role you play in the development process, ALM benefits everyone; from clients to managers to testers. Yes, we care about testers, too.

So what is ALM? We already know what it stands for, but it’s more than just 3 initials. Let me break it down for you. There are 3 main pillars of ALM: Visibility, Traceability and Automation. What does this mean and what tooling do we have at our disposal? I’m going to break it down for you.

Visibility – The Brains

Regardless of your role on a project, there are things you are going to want to know about it on a day-to-day basis. For example, if you’re the client, you might want to know what features are being worked on this week. A development manager might want to take a look at what tasks each developer is currently working on, and how much effort is left. A tester (see, I told you we cared) will probably want to see which features were marked complete yesterday so he knows what to test today.

This is all about visibility. By availing data to the team, we create a more informed, and therefore stronger, team.

Automation – The Heart

Visibility is all well and good, but without automation, it’s about as useful as a bottle of Evian to the Wicked Witch of the West. If the team is reliant on a person to publish status reports, or inform the product owner when a feature is complete, then human error and miscommunication will come into effect. In addition, manual processes will cost more than automated ones. This becomes especially evident when you consider build and deployment processes. Close your eyes and imagine for a second that the continuous integration build had to be kicked off manually. It just wouldn’t be practical. Okay, you can open your eyes now.

Traceability – The Courage

Courage isn’t really relevant here but I was enjoying the movie reference. Traceability is about being able to trace various artifacts in the project and link them together in a meaningful way. If you consider you could trace a code check-in back to the original requirement; or track a developer’s estimated effort against actual effort; you get an idea of how powerful traceability is.

Tooling

You can imagine that if your 3 ALM pillars are solid, you have laid the foundations for success. There are several tools to help you build your pillars, and it is possible to buy them a la cart and integrate them. Our favorite here at the labs of Mercury New Media is Microsoft’s offerings, with VSO (Visual Studio Online) at the center. We use the task board to track features, user stories and tasks; integrated GIT repositories to store code and apply check-in policies; TFS builds that retrieve, build and deploy code on check-in and every night; and we get all the wonderful reports and charts, such as sprint burn-downs, with no extra effort. It’s just all there, and it all works together seamlessly.

If Microsoft’s offerings are not for you, there are many viable options out there. What’s important is that it all works together, and for you and your team.

What’s next?

I don’t know what’s next for you, but for me, I’ll be diving a little deeper into how we practice good ALM here at Mercury New Media. If your passion is Disney Princesses and sleepovers, my next post might not be for you. But if you want to geek-out on sandboxes, automatic deployments and unit tests, I’ll see you next time.