Embracing Change (management) in an Agile way
M_Kevin_McHugh 270001CDK4 Visits (10527)
....and then there was this time I deployed Rational ClearQuest across
<Names and places are changed to protect the innocent and guilty alike>
I spent my first week reading the contract between the government entity and the prime contractor. That was pretty mind numbing (but turned out to be critical later on...) :-D
Then one of my three managers walked into my cube and said .... "we have to have an electronic defect tracking tool on project X. We have to have it in place and working asap or our customer will reduce our award fees. You are hereby empowered to make this happen. Report back to me when you are done. Or, when someone tries to stop you."
"ok", I replied.
So, I went to see what I had to work with.
First roadblock -- I need time and budget for the ClearQuest administrator. II begged, cajoled, and weaseled budget from something like 10 different project managers to cobble together a half time budget.
I took the out-of-the-box Defect record and went to find a Six Sigma black belt candidate in the QA department. I gained agreement that this would be his project.
I had the CQ administrator create a new record type called a "Tool Management Record". The TMRs were a list of all the new or changed features needed by the organization.
### Sounds an awful lot like a backlog ###
I set our iteration lengths to 2 weeks. This turned out to have several benefits.
I prioritized features in the backlog based on stakeholder needs and agreement -- backlog grooming
I allocated TMRs into the sprint based on priority and complexity -- Sprint planning
I promised demonstrations to the stakeholders for the given process at the end of each sprint -- Sprint Review
No retrospective -- there were just two of us. :-)
Turns out we saved over $50 / defect. And, the defects were numerous. The cost avoidance ran into the millions of dollars over the four years I was there.
But, how is this agile you might ask. Well, we didn't stop with one project and one process. Here are some examples...
There were 70+ projects and 50+ processes related to change management.
I built a backlog of all the teams, processes, and projects. I learned the hard way about Mr Kotter's rules for leading change.
Every two weeks, I assigned the goals for the next sprint side by side with my admin. Every two weeks, we produced a new, tested, deployment for our stakeholders. Every two weeks I demonstrated it and took feedback.
This went on for four years. In the end, I directly converted 60% of the processes, all the projects, and most of the teams to electronic change management. The effort gained enough momentum that the IT subcontractor finally got on board, albeit with their own solution. I built and delivered training materials. I must have taught over 500 people. Every time a new process adopted onto ClearQuest, a set of materials was delivered to the Greenbelt teams or change teams to help the team members adjust to the new tool. Every time a new group joined (project, or organization), I delivered the basic CQ DCM course to orient them.
I would spend time in their Change Control Boards over weeks to stabilize their new behavior. I knew my job was done when they started to contradict me and tell me the way it really worked. :-) Always a good sign. Then, they owned it.
The CM organization had to "fast learn". I could not afford to take the time to let them absorb the concepts. They simply had to adopt. The maintenance organization, however, did not need to adopt as quickly. In the end, I converted all the processes "around" them. They eventually came to ask me to help them adapt their processes.
Every two weeks turned out to be a very powerful approach. The backlog was public. The results were visible. The team was responsive. We were on average only one week away from fixing any problem.
Over four years, we reschedule the duration of about four sprints due to holidays, and illness.
The stakeholders were comforted by the "heartbeat". That's the term I used. While initially skeptical, they came to trust and rely on that tempo.
That trust translated in to an ability to have conversations about changing the way people had done business for 20 years. In most cases, with remarkably little 'heat'. :-)
Eventually, champions emerged who took over this work and released me to other improvement tasks (SCM, Requirements, Test Management, Design in UML tools)
Eventually, I moved on to another job.
The change to Agile stuck
The change to electronic change management stuck
Something to be proud of.... Agile before I even heard the term.
M Kevin McHugh