You may have not heard of a formal mixed standard yet and me neither. However, chances are we both are using it, at least to a certain degree.
In our industry, I see it is rather uncommon to acquire a methodology and adopt it without any alteration. Every business has its specific goals, own culture and necessities. What is good and fits well in one group, may not work well for others.
I believe the key word when preparing your technology standards is “awareness” and together with it, the word “flexibility”. Our goal, I think, should include a solid awareness of the values of the organization and the IT leaders should be flexible enough to create a standard that supports and facilitates the IT operation and that, at the same time matches the organization values and goals.
While working for a financial group for five years, we adopted what I named “condensed” development life cycle. We borrowed ideas from the Agile methodology, the Microsoft framework, and also observed and integrate the corporation needs in our own IT standards. The standards were written and revised on teams of two or three senior developers and each team focused on a specific phase of the development.
I realized the “mixed” standard was also “condensed” because we knew we need to apply the Rapid Application Development (RAD) and do not write a lot of documentation. On the other hand, we were sure that we need the essential documents to facilitate present and future maintenance and acknowledgement of what and how the systems were done.
In general terms, we used the Microsoft Framework terminology and created a basic set of standards documents that included:
- The Envision document
- The Planning Document
- The Development Document
- The Stabilization Document
From the Agile world, we adopted the concept of developing our projects in phases (mini/short phases) with deliverables in between 4 to 10 weeks.
From the SCRUM, we adopted the “stand up” meetings with quick review meetings and actions to remove barriers and difficulties developers may face, on a weekly basis (SCRUM recommends daily stand-up meetings and that seems even better).
We did not test before developing (Agile World), but we embedded “use cases” on the design phase and that served QA in preparation for the stabilization phase.
We did some extreme program, but only when time permitted. We accepted that Agile suggestion in a flexible manner.
We introduced meetings outside of the office. Most of them actually happened in my house and that helped in keeping the team together and raised the friendship in the group.
As you may imagine, the results of these decisions were very positive and to summarize, I categorized the development standard as “Mixed” since that was what it appears to be.
* TechSlope is a side web project dedicated to IT technology and for technology people. Feel free to drop me some ideas and suggestions. We are all learning in this world of fast changes and abundant knowledge. My email is firstname.lastname@example.org.