When launching a new business or a new initiative, I see lots of teams make the mistake of obsessing over what process they are going to use to manage the software production efforts.

They start, typically, with some ‘textbook’ example of SCRUM©… this quickly leads to obsessive debate over what ticketing tools to use… which then devolves into silly discussions over what ‘states’ the ticketing process should have (‘waiting for tests’, ‘testing in progress’, ‘testing failed’, etc)… Add in some arguments about what roles would be on the team and the delicate parsing of the responsibilities that do, and do not, belong to each… it doesn’t take long before I’m wondering: ‘When did we stop being software engineers and become process engineers?’

The problem is that we’ve forgotten the FIRST principle of the agile software movement:

Individuals and interactions over processes and tools

Oh yeah… forgot about that.

Now, I’m not dogmatic about anything, let alone trying to follow a ‘manifesto’, but look… this is some solid advice. True to the heart of agile software development, if you try to design your process entirely up front, you are almost certainly going to get a lot wrong and waste lots of time trying to correct it. You are waterfalling your process design!

Instead, I prefer to focus on building culture. I know that sounds pretty vague, but let’s put some flesh on those vaporous bones. There are some key tactical elements that I need for my team to be successful that are truly at the heart of a successful software adventure:

• A collegial culture. I want opinions from my team. I can’t do anything without opinions. I want spirited, and well-informed, debates. I want people who enjoy debating but who also understand compromise and can move on to implementation of a decision even if they don’t 100% agree with it. Those that have worked with me will quote me looking for people with ‘opinions and thick skin’
• A testing culture. There is no greater difficulty in creating a lean, mean process than a constant barrage of distracting defects. I need people who believe in automated testing and who actually enjoy working in this way. They bring ideas about making the testing less fragile, more complete, faster… they put thought into the infrastructure to support it. Testing is the lifeblood of a lean, agile process.
• A feedback culture. You don’t just ‘involve’ the business. You have to be the business. There’s no excuse for the engineers to not understand all of the nuances of the business as well as anyone else. You give demos for everyone… regularly. You ask what they want, try to comprehend what they don’t like. Ask them to explain things about the business you don’t understand. Be curious! Make them part of the team.

This is what you need. If you make this happen, your process will avail itself as a lean and super-effective software manufacturing powerhouse! And it will be damn fun for everyone also! Hey, why can’t this be fun too? If you aren’t having fun doing this stuff, you’re doing it wrong… really.

So how do you start? Well, first, you need good people. The collegial atmosphere is built on people who possess the right qualities. Talent and experience, sure… but finding the right personalities is harder. Your coding test only goes so far. You’ve got to talk to people, get them to debate you in interviews… see if they have opinions but are fair-minded and practical. Finding these types of people goes a LONG way to building the right culture.

Now that you’ve got people, start building your testing culture. Don’t worry… if you hired the right people, than let them build out the infrastructure you’ll need. They’ll lay the foundations, but remember… you’re building culture. The testing culture is ongoing. You will constantly be tending to it and improving it… playfully chastising those who ‘broke the build’. This is the first realization that culture begets culture. You’ve already begun letting the culture, and the process, build itself!

Once you’ve got that testing culture plugging along, and the continuous integration that will surely follow, you can start to engage the business. Invite them to your demos… always! Make sure the engineers have access to whomever they need to answer their questions… no go-betweens! Let all of your engineers have time to present. It builds their confidence, gives them visibility, and allows the business to get to know them. The feedback culture will begin to blossom before your eyes.

Now somewhere in the midst of this culture building, a process will emerge. It will be lean and simple with lots of transparency since you’ve engaged everyone. Adding tooling on top of this to try to record what you’ve done and create broader transparency… well that’s fine at this point… now that some culture and rhythm have emerged.

Now you tend the garden. Make small and thoughtful changes. Let those changes sit awhile. If they work, great… if they don’t help, get rid of them. Don’t disrupt the team’s rhythm. Your process is built iteratively… and with care… just like your software.

If you build good culture, your whole business will seem to miraculously pull together towards the same outcomes. It’s not miraculous, though… you built it together with your team! I tell you… when it happens, it really is beautiful. You will have created something to be proud of… a happy team and a happy business.