What is ALM and are the relevant publications too dry for the developers?
If you are expecting a lengthy discussion in ALM and/or SDLC, then you may want to skip this post, because the core theme of this post is to figure out how we can make the related content relevant and appealing to all stakeholders of software projects, especially the developers and testers.
Acronyms
Before we begin, we should resolve the acronyms SDLC and ALM, as many of us dislike horror of or are unfamiliar with TLAs (three lettered acronyms) or FLAs (four lettered acronyms). Using the Microsoft Glossary we can expand the two acronyms as follows:
- Application Lifecycle Management … A software development methodology that utilizes phases including process and project management, requirements, modeling, testing, and software change and configuration management.
- Software Development Life Cycle … A standard development methodology that details specific methods of handling milestones, deliverables, events, roles and responsibilities.
Introduction
If you are interested in more details on SDLC and ALM, you can refer to books such as .NET Enterprise Solutions – Best Practices for the Connoisseur, by BB&D for the community, the exceptional book Software Engineering with Microsoft Visual Studio Team System, by Sam Guckenheimer, the range of my related blog posts I summarized in SDLC – Software Development Lifecycle … what’s the point? (links to all posts) as well as a gazillion other books, blogs posts, websites, … the amount of information on this topic is overwhelming.
To cut a long story (blog post) short, my intention is not to talk about SDLC or ALM, but to figure out the right medium to make the topic of SDLC and ALM appealing to both the developer and tester of typical software projects. My personal finding having worked in this industry since the early 80’s is that most us us get exposure to SDLC/ALM at the college and university as a mandatory topic, often as an overwhelming theory wave, placing the books in boxes after certification. At the workplace they reappear on irregular intervals, but are often frowned upon as obstacles and unnecessary project management concepts.
This has been a huge concern to us, because the concepts of SDLC/ALM and customizing the selected methodology to suit your environment, rather than adapting your environment to match a text book is one of the most important puzzle pieces of any software project.
Past Journeys
In 2004 we released the book .NET Enterprise Solutions – Best Practices for the Connoisseur for the IT community in South-Africa, introducing the puzzle pieces such as project management, design, modeling, testing, etc. in a journey that took the reader from start to finish of a complete solution. A spice we added was a large amount of visualization (most pages contain an illustration) with the aim of breaking away from the dreaded text-only textbooks that many of us have experienced during the academic study eras in the 80’s and 90’s. While the book was well received by the community, it did not really motivate many of the readers to get excited about the SDLC and ALM theme covered by the book.
In 2006 we released the book .NET Enterprise Solutions – Interoperability for the Connoisseur for the IT community in South Africa, focusing primarily on interoperability. Some concepts we introduced in the book were simple standalone samples based on the calculator all the readers could relate to and cartoons to visualize key concepts.We initially received major flak for the latter from the sponsors, but very quickly saw readers picking up the book because it was interesting as well as “fun” to read.
In 2007 we pushed the boundaries with the book Software Engineers on their way to Pluto which reads like a Science Fiction story, has more “fun” cartoons to visualize the journey from Earth to Pluto, and most importantly introduced the concepts of SDLC/ALM. Most readers picked up the book because it looked interesting, started reading the story and only realized in chapter “call to action” on page 71 that it was actually a book discussing SDLC/ALM, in particular the Scrum. The quote from colleague Tom du Toit (core developer) summarized the success of this initiative for us and therefore made it onto the back cover of the book: “I enjoyed the book a great deal. It was interesting to read and rather addictive. There is a lot of information and food for thought that is explained in a very easy to read way. It is easy to understand and I think that even if you are totally clueless you would walk away with something from this book. I am certainly relooking the way I work, it inspired mew to go the extra mile and make sure that the products we deliver are worthy of going to Pluto and back. The storyline was pretty cool and even though I am not exactly what you would call a “space” guru, I think that it was far from over the top. Even if you have no interest in space at all you will find it a fun book to read. Good humour as well. Thank you for giving me the opportunity to read your book. ”
I must emphasize that we also got huge pushback from management and the academic community at the time we shared the early drafts for review. Their feeling was that the topic deserved a more formal approach … exactly what we tried to avoid in the first place. We persevered and based on Tom’s feedback and discussions we had with developers around the world, we believe that we made the right decision.
Question … the end of a long story :)
2 years later, working in a new environment with the VSTS Rangers, getting heavily involved with guidance and Scrum, I am wondering the right media to use to make SDLC/ALM appealing to all stakeholders, in particular the developers and testers who benefit the most from a well chosen, implemented and managed SDLC/ALM environment.
Do we need a formal approach, do we need a fun approach, do we need more visualization, what type of visualizations are valuable, … I could go on for ever with questions.
Your feedback and comments would be appreciated, so that I can find conclusion in my mind and also drive the expectations in future publications based on “your” preferences and requirements.
References to the mentioned books
Comments
Anonymous
September 05, 2009
What an excellent post! Thanks so much for raising this very important point about methodology. I believe that process and methodology should be a healthy mix of theory and practice and should always be in the service of the sponsoring organization while at the same time guided by contributions from academia. Too many times, I have seen poor project performance because the participants got religious over a particular methodology. The symptoms are obvious. Influential participants get overly excited about some newly hyped methodology (Agile anyone?) and start applying all aspects of the methodology to their project. The project starts to falter and those same participants attribute the cause to the claim that they aren't applying all aspects of the new methodology which just causes the project to sputter all the more. Don't get me wrong. I think that Agile is a great methodology. I believe in picking and choosing the most relevant parts over a one-size-fits-all approach. Your readers might be interested in a lecture that I gave at Brooklyn College on the topic of Applying Software Engineering for Business.Anonymous
September 10, 2009
The current approach you are using on the blog is right on the mark. The current style is fun enough and formal enough, visualisations are appropriate and well-crafted. I think keeping the content a priority without overwhelming it with the 'fun' stuff will keep you on track.