Most of the time, developers want to deliver useful software. They want their business partners and end users to be happy, even delighted to use their software. They struggle with this. Sometimes forget this. I haven’t worked with everyone, but for every developer I have worked with and gotten to know, this is true.
Given this, a desire to make customer happy with useful and delightful software, what would I do if I went back into IT management? If the desire was right and the software development practices were not effective, then I think I would introduce 2 ideas. I would not send everyone to agile training. I would not introduce stand-ups, paired programming, or burn-down charts. I would not change the language. All of that is too difficult. Too heavy.
What 2 ideas would I introduce to my team? I would insist on just 2 things. Here’s what I might say . . .
First I want us to develop a new review & feedback system. On a regular basis, we need to review what we’re doing and figure out how to do it better. Sometimes this would cover the last hour, when we where in a meeting. Sometimes it would cover the day, so tomorrow will be more effective. Sometimes it will cover a week or one month, so we make sure we capture the big and important issues. And to make sure we are on the right track we will also hold an annual review to check our overall direction and strategy, too.
Second I want us to start integrating code into the trunk multiple times a day. Anything less than twice a day means you’re in too many meetings! The reason for doing this is to reduce risk, because if you’re spending time working in a silo then you are adding or ignoring risk.
So, why these 2 ideas? Why did I ignore the rest of the principles surrounding the agile manifesto? Because everything the agile manifesto wants is covered in these two ideas. I am both forcing change and giving them a means to talk about the problems and incorporate the differences into their processes.
The first idea I will introduce is all about giving them the foremost thing a team or company, an individual or company needs is the ability to review it’s process and work, to honestly assess the output and performance, and be able to improve upon what they’ve done.
The second idea I will introduce is all about forcing fast feedback. Jez Humble has said, “If it hurts, do it more frequently and bring the pain forward.” It was counter-intuitive for me, but I finally learned he is right. We need to stop avoiding the painful parts of the process because we are making it worse. For example, if integration is difficult, waiting makes it more so. Do it so often the issue becomes irrelevant.
By requiring continuous integration as my second idea, I force the team to look at their environments, their tools, their permission structures, their process, their tests, their requirements, and more. Each change will cascade other changes, and in so doing, push the group to accommodate the greater needs. We may never call what we do “agile” even though I expect, with some time, we will be living the agile dream!
Okay, this is my dream. What do you think? What’s missing? Can you convince me even these 2 steps are too heavyweight?