Managing Change in your Change Control System
Software development practices have evolved considerably since I started in the early days of early PCs and mainframes.
One constant that has never ceased to astonish me however is the lack of control and management that is found around the tooling used to support the development process.
Back in the day development was pretty crude, as were the tools to be honest, but I still remember an incident with a dropped tray of punch cards which was compounded by the problem that the owner and reason for them wasn’t known so neither was the impact or recovery procedures.
Things have obviously moved forward a considerable amount since then but many organisations still suffer because they focus on short term issues instead of focusing on long term solutions.
JIRA can help, if you let it
The Atlassian suite is probably the best tooling platform I have ever come across and, when coupled with other best of breed tools, it has yet to be beaten in my opinion.
In the last few years, however, I have seen a significant adoption in the larger enterprise which has mostly come about ‘under the desk’.
To give a common example; many small team development trams will run a pilot or Proof of Concept for Atlassian JIRA. JIRA then becomes indispensable to that team and the post-pilot development. After gaining traction it is then adopted by other teams across the organisation, but the tooling infrastructure doesn’t change.
What we then find is that the tooling which suited the small team has evolved into a complex and unmanageable beast and more and more functionality and requirements get plugged in.
One of JIRA’s key strengths is that it’s wonderfully flexible, powerful and configurable, but therein lies the danger.
Fairly recently I came across an organisation which had taken almost exactly the route which I just described.
This particular instance was fairly well configured and was supporting a development department in the hundreds across multiple teams and projects. However when I asked the gentleman where JIRA server was he pointed to a PC sitting under his desk!
In another example the organisation had 50 projects tied to over 60 permission schemes and another a large user base with over 150 administrators. This resulted in almost weekly cries of pain when a field disappeared or a process changed underneath the teams trying to work on the system.
Fixing the problem
This problems arise from a lack of control and, most importantly, Change Management.
To the best of my knowledge, the teams using the systems mentioned above were applying good practice to their software development processes – of course they were, they’re using JIRA right?
What they all lacked is a focus on the tooling itself. Little time was being taken to apply the same Change Management rules, applied so assiduously to their development practices, to the tooling used on a day to day basis. The proverbial builder who never finishes their own home.
So how do we fix this?
First things first – change the culture
Does everybody need the administrator rights? No! However, the loss of power, perceived or otherwise, can give rise to friction if not handled correctly.
Removal of rights across the board after a consultative process coupled with an open review of processes and procedures is a good idea.
Why does the process change so often? Continuous Improvement of Agile processes is a given but this is not a reason to give everybody everything.
In fact Continuous Improvement should be a considered and measured process with analysis of the proposed change, and before and after metrics, to assess the benefits or otherwise.
Set up a TAB
I strongly recommend the creation of ‘Tools Advisory Board’ (TAB) within any organisation. This should be made up of the process stakeholders from business through to the development team.
The TAB is responsible for accepting, reviewing and accepting or declining process changes. They are not necessarily (and probably should not be) responsible for making any changes that might be required. Although it is advisable to have representatives of the support/administration team on the TAB.
One reason for the exclusion of development teams from the direct administrative process is regulatory.
One fundamental thing that must be avoided in regulatory affected development teams is the ability of the development team to make underlying changes to their tool configuration. Especially where the tooling is being used to affect monitoring of the development process.
Although the latest versions of JIRA have introduced an Audit facility it will be some time before larger enterprises are upgraded to these versions and this only allows you to apportion blame not manage the process up front.
Using JIRA to manage change process
Another thing to focus on is managing the change process itself.
Very simply, set up a JIRA project to allow change requests to be raised as necessary. Use Stories, Agile boards and processes if you wish but the fundamental requirement is to get the changes documented and apply a process to them.
Atlassian provide a useful guide to get started with this; learn more here or we can help as part of a JIRA training course.
Managing change with JIRA ensures the process is controllable and traceable. Tools and processes have improved a lot since the 80s and it’s high time our management of them improved too.
For help with managing change in your organisation, or with implementing any of the Atlassian tools, please get in touch. You can learn more about Clearvision’s consultancy services here
- No more secutiry or data concerns
- In depth knowledge of hosting options
- Join the 80% of enterprise organizations who will be using cloud computing by 2016