Hi people. I am a long time listener of Manager Tools and I love the podcast.
I am experiencing friction on the subject of Change Management that I am hoping someone could offer some insights or suggestions to help me through it.
My Situation:
I am a lead software engineer on a 75+ person development team comprised of managers and engineers. I have been with the company for 10+ years and have seen the team grown from a handful of people. Organizationally I am one of 8 leaders on the team (4 managers & 4 technical leads). I have been helping the team move towards using Agile Software Development, and good design practices over the past year with limited success.
To avoid forcing solutions and allowing others to discover insights, my technique has been to ask questions rather than stating what I feel is wrong. Like "What would happen if we need to change system X", or "Why did this take so long and do you think there is anything we could change to shorten it"? Sometimes I am successful in swaying people and generating insights, sometimes I am not.
We all have different experiences building software, which also means we all have varying principles and practices we follow. I actively seek out, learn, and practice what I learn. Many on the team do not, which is the crux of my problem.
Software development is very much an intellectual activity. The pain of bad designs or poor approaches to developing software are often felt very late, if not years later. In many cases it is not the author of the software that experiences the pain. They have often moved on to other projects or left the company. Yet everyone who has ever developed software has looked at code at one time and said that it was poorly created or have asked why changes to a product take so long. Few take the steps to learn about why, how to avoid it, and apply what they learned, which is what I am trying to do. How I learn is done through internal investigations or learning through remote sources like blogs, podcasts, books, etc.
My Question:
Since people rarely feel the pain of what they create, and that there are known methods for creating better products which produce better results, how do I get people to recognize the pain and how to avoid it without appearing to preach theory?
I look forward to hearing your critiques, ideas and experiences on the subject. Thank-you in advance for your insights.
Put them on maintenance...
I've found that what teaches software engineers the most about proper design is to have them maintain and fix problems in existing code. They eventually learn from the pain of other people's mistakes!
I know that at my workplace you can tell who has worked in what source by what they warn others about.
--
Chris Arguin
Basics of getting people to change
I've been in software development for 20+ years. My experience is that most people don't come to work and say "I want to create bad software that will be someone elses problem later on". Given that...start thinking about what could be causing this.
Even though the problem is in software development, this is still the basic problem of getting people to change. For some reference, a useful book for me on this topic has been the "Influencer" but there are lots of books talking about this.
The experts tell me that people need the following to change. (The Influencer breaks it down into 6 more tuned.)
You could think about those 3 things. From your statements, it seems like all three things could use help.
The above ideas are just some quick ideas. I'm a collaborator by nature, so I'd probably start by #3 and work together to make things better. But there are lots of ways you can attack this.
Drucker
You can't manage what you can't measure.
Agile relies on a well-groomed backlog, continuous integration and testing, and careful attention to velocity.
A lean inventory of untested code is essential. Likewise, bugs should be fixed before any new code is written. Code isn't "done" until it passes test.
You can measure the volume of untested code (measured in story points) and you can track bug volume. You can measure backlog volume and velocity.
With those four metrics, you can have frank discussions with teams about how they can improve their performance. In the spirit of Agile, they can problem solve during the retrospective.
These metrics are very persuasive.
John Hack
Thank-you
You have all provided me with great feedback. Thank-you.
Numbers and Cross-training
I would echo what John and Chris offered. In my experience, the first thing I do after determining the problem is get some kind of meaningful quantitative data around it. That alone often convinces the skeptics. I think that the the KPIs that John suggested are all good in an Agile type of environment.
Once you've obtained the data and made the case, it is also easier to ask those people to go on to maintenence and support duty, as Chris mentioned. In most of the organizations I've been with (I am a trainer - so please recognize my bias here), having developers and other tech types spend 1 -2 weeks a year in tech suppoort has always been the standard. In addition to making for better inter-departmental relationships and breaking down knowledge silos, it also gives the developers firsthand knowledge of the clients' pain points. One bonus: it makes the support folk a bit stronger, too. It's not an easy sell to the managers involved, but man...it's worth it.
Cheers,
Dave Gibson
Persuading people to change
Excellent advice so far. On a slightly different tack, though, maybe I could just recommend a book that I've found invaluable, when it comes to touching people's hearts and making them WANT to change. (By the way... I'm not on commission!) It's called "The Secret Language of Leadership" and is subtitled "How Leaders Inspire Action Through Narrative". It's by Stephen Denning and was published by Wiley in 2007. It teaches how to use storytelling as a powerful way of inspiring people - particularly in a business setting - and I think that's where you might find some permanent answers to the challenges you have described. If you do get hold of a copy and put it to the test I'd be very interested to hear how you get on.
Malcolm.
Infopreneur - www.malcolmcdragon.com
(incorporating MemoryWork and Sirius Communications)