How can I influence my team to become more agile

Question

I consider myself an agile developer, I have set up CI in the last three teams I have worked with, and in my previous role worked in a style which revolved around writing failing tests before fixing bugs, extremely short feedback cycles (typically starting UAT of new features within a couple of days), and a very short release cycle.

Now I find myself the only person to write a C# unit test in the last 6 months, battling inertia to improve code quality, and supporting a system in which new features are just released with the intention of fixing them later.

What tricks can I employ to try and stabilise things? I have tried setting up CI, automated UAT deployment from a separate branch in source control, and publicising local free talks on software development, but with little success.

Answer 1

You cannot give "The Process" on people and expect they to follow blindly.

The best way I could think of is this - try to take "ownership" of some the harder parts of the project. And if you development process consistently yields better results it will not go unnoticed and people will come asking and listen.

That is how I managed to change things a bit in my current workplace.

You have to introduce the things a bit with the wow effect that comes with encountering major improvement. Like migrating from CVS to Mercurial - holy #$%@ it can do this easily?

Answer 2

Sounds like a difficult situation. A couple of more or less random thoughts:

• How much have you actually talked with your teammates about these new ideas? Changing the way other people think and do things is one of the most difficult things in life. So you need lots of communication, and time too. Who and where gave these "local free talks" you mention? If they are somewhere else in the town, it may be difficult to convince people to go there - especially in their free time. You should try to arrange talks / workshops / demos on your own workplace, or even just talk about these ideas during lunchtime with colleagues whom you find interested in learning.
• You should gather hard data to support your cause. E.g. keep statistics of bugs caught with unit tests, and bug density in code you wrote TDD style vs code written in the "traditional" manner. With hard data in your hand, it is much easier to convince both sensible team members and management.
• Yes, it sounds like you should involve management too. Talk to your managers about the problems you see, and the possible ways to improve things (but make sure to present them in ways management understands, e.g. "because we have no CI, we may notice broken builds only at the customer site, which causes customer irritation and extra expenses"). Also listen to their point of view. They may see the same problems from a different angle, or may be completely oblivious to them, due to company cultural issues. In the former case, you may make them your allies, and together you can manage to move the development team and process towards a more agile, quality oriented approach. In the latter case, without management support, alone in a team of jaded developers, you have close to nil chance of success, so it may be better to start looking for greener pastures...

Answer 3

You need to get some level of management buy in. While some people will want to write better code just because, that does not sound like the culture there. This is going to take some level of change from the top, like rewarding delivery of code that doesn't intrude 10 new bug requests, etc.

Sometimes you just have to realize that you are better off somewhere else (and maybe so are they).

Answer 4

One the problem in any new technique that the one didn't used to do is resistance to change, try do offer them something interesting as some kind of challenge, try introduce to them something that will impressed him like Dev Magic Fake on CodePlex :

http://devmagicfake.codeplex.com/team/view

This framework will save any object and retrieve it without any needed code and will give you the ability to write unit test and TDD and UI test without write the underline layers

My last advice, some people didn't believe in talks, they have to see the project success to follow you, so you may need to work harder to get them believe.

Thanks

M.Radwan