One of my favorite tricks around changing how a team does something is to get other people to drive the change for you.

This especially applies if you’re coming into an organization as an outsider. Most people are initially somewhat skeptical of outsiders and you need to earn their trust. This sometimes takes a long time, and you might want to change some things before you’ve built up the political capital to drive it yourself.

When I started on my current project, all of the QA testing was done manually, and QA people weren’t involved in the process at all until after the code had been written. As a result, they would get features to test and not have any idea of what they had to test, and many times they couldn’t trust that the requirements were even up to date.

The solution that I was hoping for was to get QA people to meet with developers and BAs before the code was written so that they could come up with a test strategy and acceptance criteria. That way they would have input up front, and developers could automate all or most of the acceptance tests, which would save QA a lot of time. But I didn’t want to bring it up myself.

So I would ask questions in meetings. We all agreed there was a problem, so I would ask everyone what ideas they had to fix it. Eventually someone would give the answer I was looking for. “That’s a great idea!”, I’d say, “How do you think we should do that?” Now it wasn’t my solution, it was someone else’s. That person feels good because they came up with a good idea (that eventually ended up working), and since that person is actually on the team and doing the work, they might have more credibility than an outsider like me.

I would much rather have someone else get the credit for coming up with the ideas, because I think that it gives the idea a better chance of success, and when it works, it encourages people to try and think of more ways to improve things. If one person comes in and tries to drive and enforce all of the change, it’s very easy for people to discredit that person (maybe even just in their mind) and try and fight the change. But when the ideas are coming from multiple different people on the team, now you have more and more people buying in because they’re the ones coming up with the ideas!

When I think of a “coach”, I think of someone who helps other people find the path to success. You can try to push them in that direction and they might turn around and fight you instead. Or you can help them use their own ideas and expertise that they already have to find their own way.

If you’re a developer, you probably aren’t extensively involved with requirements gathering, but they affect you dramatically because you have to read requirements and turn them into code. So how would you like to have requirements written so that you have all the details that you need to implement the feature and easily write acceptance tests (hopefully automated)?

I have ideas but only some answers, which is why we’re talking about this on Thursday at the Columbus ATDD Developers Group. We’ll be talking about questions like these, among other things:

• How can we structure our requirements to help us come up with our acceptance criteria?
• What requirements should we have other than our acceptance criteria?
• What can we do to help BAs make sure that they have all of the details that we need to write tests and write the code?

It’s a fishbowl discussion so we all get to figure it out together. I think it will be fun. I feel like there are some dots that I’m having trouble connecting when it comes to requirements gathering so hopefully we’ll turn on some light bulbs.

The meeting will be Thursday, August 2 from 11:30-12:30 at the Quick Solutions office, 440 Polaris Pkwy., Suite 500 in Westerville. Please RSVP so that we know how many people are coming.

If you want to change something in your organization, that must mean that there is some problem that needs to be fixed and a solution to fix the problem. That’s obvious, right?

Maybe it’s obvious to you. But is it obvious to others?

If other people on the team don’t see that there’s a problem or if they’re OK with the status quo, it’s going to be very difficult to get them to change. For example, let’s say that your team does not do automated testing and you want to get developers to start writing unit tests. The problem is that you have lots of bugs and it’s scary when you have to refactor the code.

But wait a minute, do other people think it’s a problem? More than that, do they think that your solution will be better than the status quo? That’s a completely different question! Maybe the developers on the team have all been getting good reviews from their manager. They might not like the bugs and the scary refactoring, but they might not think that introducing TDD will fix the problem, or they might think that it’ll be more work to learn TDD than just deal with the code without tests.

You need them to both see the problem and buy into the solution (man, this is getting hard). So maybe you go and write unit tests around some part of the system. Then later when another developer needs to change the code, you show them how easy it is to run the tests and see that the code is still working. Now maybe they’re more open to your solution because they can see the benefits of it and see that maybe it won’t be as hard to implement as they previously thought.

Until you can get people to see that there is a problem and that your solution is viable, you’re probably not going to have a lot of success getting them to change.

If you want someone to change, you have to not only give them time to change, but you need to show them that you will be there to support them when they need help. They might be worried that they’ll starting learning the new way and then you’ll leave them out to dry without any help to get them the rest of the way.

The other day I was making a change to a part of an application that I don’t deal with much using a framework that I’m not an expert in. It wasn’t very hard to figure out, but I didn’t really enjoy it. I hate feeling like something is taking me way longer than it’s supposed to just because I’m not the expert in the application or technology. I’m sure you all can relate to this.

Now think about having to do something completely foreign to you, like a new language, platform, or technique that you’re really not good at. Or maybe you’re trying to change the way that your business analysts write requirements or your QA people test software. We can criticize people for being fearful of change, but we’ve all been there are some time.

If you’re the one who knows what they’re doing when it comes to the new whatever you’re doing, look really hard for opportunities to help people. Most people are reluctant to ask for help (maybe they have egos, they think you’re too busy, or they just don’t want to get up out of their chair). Instead, ask people how they’re doing today. When they mention that they’re struggling with something, go help them with it, and then offer to help them again if they need it.

Some people are definitely more adverse to change. If you’re the one proposing the change, chances are you are not as adverse to change as others. You have to try and put yourself in their shoes. They have good, logical reasons in their mind to not do what you want them to do. If you can empathize with them (or at least attempt to), you’ll be more in tune with their fears and what you can do to help them through it.

There are many people on software development teams that are trying to change the way that their team works, whether it’s a new process, a new technique, or new way of development software. Yet so many of them never see lasting change come about.

You can try to drive change or encourage people to change, but the people on your team have to feel like they have some room in order to try and make the change. If they feel that there is a risk of failure because changing the way they work will lead to poor results, then they won’t take the chance.

Stop the fire fighting

I’ve seen many teams that feel like they’re in endless fire drill mode. When you’re in these situations, you have very short term thinking because you feel like you’re always solving short term problems. Sometimes there are fires, but ultimately what we want is more long term thinking. But in order to get that long term thinking, you have to give people some stability and peace in their day to consciously think about doing things the right way instead of doing whatever it takes in order to fix the problem at hand.

This is easier said than done. It takes someone awhile to switch from short term fire fighting mode to a long term mindset. For me, someone may say that the fire fighting is over, but until I can go a week or so with some stability, I’m not really going to believe that I’m going to have space in order to think differently.

This requires you to rethink how you plan your capacity. It probably means that you need to either do less work and get more people to help get the work done. Either way, you need to stop lying to yourself and saying that you can do as much as you’re doing with the team that you have.

This is where making the workload visible is important. Put everything, and I mean everything, up on a board. People should see what you’re working on now, what’s next, and what’s in the backlog. Put technical debt and refactoring tickets on the board too. When someone asks why those are there, explain how doing those tasks will allow you to provide more value and be more productive. If someone asks why you’re not getting as much done as they would like, you can show them exactly why.

It may take discipline, but if you slow down just a little bit to think about what you’re doing and how you can best do it, you can turn things around.

If you’re a developer, why do you do the work that you do? What’s the goal of all of the frameworks, databases, code, and tests that we swim in every day? I’ve been doing this professionally for ten years now, and I’ve noticed an interesting progression, and it wasn’t one that I had pursued originally.

Early on, I wanted to work with new technology. The goal was to do cool stuff with the latest technology and find new, better ways to do what used to be harder in the previous year’s hotness. Working at a consulting company was great for this. I got to do new projects every 6 months that often were greenfield and we usually got to pick the technology. Now we were smart about it and we weren’t just doing “resume builder” projects where to tried to use some new framework for the wrong purpose. We were delivering value. Everyone would always hope that they would land on that cool project using the latest stuff, and whoever wasn’t on said project would want to talk to everyone on the project and see what they were doing.

Two years ago I joined a Ruby on Rails project and spent a year in the Rails world. This was the pinnacle of hot technology (at least at the time). I loved how elegant the Ruby language was, the Ruby gem ecosystem, and the Ruby community’s focus on quality and testing.

Eventually my time on that team came to an end and I came back to .NET. I have nothing against .NET, but in terms of geek cred, many people would consider .NET a step back from Ruby (but that’s not the point).

What I noticed from my transition to Ruby and back is that no matter what the technology, the code isn’t what’s important. What is really important is how we interact with users and how we can structure our process and teams to best deliver quality software in less time. We need to value people over the tools that we’re using.

The longer I’m in this business, the more I realize that software development is all about people. It’s about using technology to help improve the lives of the people who use our software, that somehow we can use our coding skills to help them be more successful at their job. It’s about the people that we work with on our team, it’s about helping them feel everything that comes along with working alongside others to help the team achieve a common goal. It’s about looking out for those team members who are feeling overwhelmed by their workload and struggling to hold on to their confidence.

I still geek out on code, and I’m still glad that I get to spend most of my workday writing code. The means may be the same, but the ends have changed.