We recently conducted our twice a year release planning, and while reviewing our process improvement items from the last planning session, I began to question some old practices.

Due to feedback from a recent retrospective, we decided to conduct these reviews every 4 weeks instead of every 2 weeks.  Most of the team has been following a Scrum-based Agile process for nearly 2 years; consequently, a healthy flow has resulted, which decreased our need to meet as often.  In addition to periodic retrospectives, we used to conduct a release retrospective that covered what happened during the release.  At the end of this last release, we made a change to the process and did not conduct a release retrospective.  (I say “we”, but in reality, it just never got scheduled.)  In hindsight, this seems like a good approach because we shouldn’t wait for the end of a release to make changes.

It seems that others have been questioning the timing and format of these retrospective meetings as well.  We currently use a modified version of De Bono's 6 Thinking Hats; however, some of these other methods are a good way to changeup the flow of the meeting.  One additional idea I’ve recently had was to set a non-iteration based topic to discuss and brainstorm on improvements.  An example of this might be taking an issue from the last retrospective, like code reviews or upgrading 3^rd party libraries, and conducting a deeper discussion on that particular top.   In any case, we are quickly approaching the need for Retrospective Surgery.

We are considering supplementing our engineering lab via the use of cloud services such Amazon’s EC2 or Rackspace’s Cloud Servers.  Currently, we use a large set of VMWare servers to host our QA testing environment, where we perform installations of Zenoss servers as well as setup target systems (Windows, Linux, etc.) to monitor.  In addition, these VMWare servers are connected to the same private network as various routers, storage devices, and other types of OS’s, such as HP-UX, Solaris, etc.  All of this is done to simulate what Zenoss users have in their IT environments, and for the most part, the setup works quite well except that there’s never enough.  The QA engineers are constantly finding new combinations of OS’s, applications, etc. that require more VM guests to be created.  Here is a quick brain dump of the comparisons thus far.

Obviously, VM sprawl is something that many IT organizations are dealing with, so our situation is far from unique.  While some of these comparisons may be generic to lots of development organizations, the systems management aspect brings many additional requirements due to the variety of targets to be monitored.  Even though this analysis is in its infancy, having the thought process published will generate ideas from others.  Look for further posts as we get closer to making a decision.

With our new community site, we now have the ability publish individual content without creating too much message confusion with our main blog feed.  This means more engineering interactions beyond the corporate confines, so look for more to come on this.

My role is to balance the needs of our commercial and community users with continually evolving software.  My hope is to improve this evolution by sharing some of the thoughts from within the engineering team and by listening to others.  The listening is the key to this blog having meaningful impact, so please feel free to share opinionated comments and make suggestions for future posts.