“Trusting people to be creative and constructive when given more freedom does not imply an overly optimistic belief in the perfectibility of human nature, it is rather a belief that the inevitable errors and sins of the human condition are far better overcome by individuals working together in an environment of trust, freedom, and mutual respect than by individuals working under a multitude of rules, regulations, and restraints imposed upon them by another group of imperfect people.” – First Things First, Stephen Covey
During my fourteen years in the software development world, I’ve seen a lot of variations of the software development process. I didn’t really start thinking hard about the development process until I was introduced to a fairly strict Agile regime at HP in 2009. For several years after that, the question of what is the “best process” rattled around in my head, mixed with literally hundreds of hours of conversations and meetings on how best to run “the process” and ultimately produced a cocktail of confusion that made my brain hurt every time someone mentioned “t-shirt sizes”. While many of the credos and reasons to run an “Agile” process seemed to align well with my experience, some of the details were simply mind boggling in their claims and implementation. Further, any time I tried out or read the details of other methodologies (e.g. Lean, RAD, etc.) they often seemed to boil down to variations of the same thing.
This is not a take-down of Agile or any particular process and I would not claim that “software development processes don’t work” (as this guy does… although he makes some great points about measuring effectiveness of processes). But I do believe that there is far to much religiosity and rule-following without critical thinking driving many software dev processes in business. My take in general would align more generally with Zwischenzugs: it doesn’t really matter what you call it, devs will dev (if you get out of their way) and businesses like to call processes something so we end up with names (read his article for more detail – it’s pretty good). It turns out those names also make some groups of people lots of money so there’s that.
But behind it all, there is something – software devs are doing a job that will have common characteristics across all variations of technologies and projects. As well, businesses have reasonable expectations and requirements of the developers they pay and those expectations and requirements will have broad commonalities across all sectors. Any time abstractions can be made to that level, mental frameworks can be built around them and through reasoning and logic persuasive arguments can be made about why a particular mental framework works well and should be adopted. Thus processes are born.
So let’s do a thought experiment: let’s pretend there are no software development processes in existence. Then, based on our assumptions above, ask, what are the fundamental needs of a development team? What are the fundamental requirements of a businesses that pays developers as it relates to the development team?
Setting aside they myriad of “human needs” everyone has, a software engineer fundamentally needs (1) to understand what they are too design and/or build and (2) to be aligned with management/stakeholders on when the thing will be produced. Then, setting aside the myriad of “needs unrelated to the dev team” a business has, businesses fundamentally need to have the dev team deliver the product/software/service/thing that ultimately allows them to execute their market strategy.
There are numerous needs that can be extrapolated from these three and likely innumerable ways to restate them but I will assert that if anyone one of these three things is missing or done poorly, the business will not survive long term. Let’s assume you agree – so what? Well, then there are three fundamental needs and we should then look for the most effective way to meet these needs. Enter “the process” (that shall remain without a name).
“Businesses fundamentally need to have the dev team deliver the product/software/service/thing that ultimately allows them to execute their market strategy”
Seems clear, but how? Well, someone in the business better have a strategy. Something rational, logical and that will deliver a competitive advantage is what I’d recommend. A product strategy dictates features and evolution of software and that means you can list what those things are. So do that. I’d recommend keeping the list in a cloud-based solution that anyone on any device can have access to – it covers all the bases (here’s why).
Now you have a starting point for helping the dev team understand what they are to design and/or build – dev need #1! You meet up with them, talk about why you built the list you did, what you need the things to do, etc. You all look at the list together and management/product designer/strategist says, “Yep, if we do this we’ll win.” And the devs say, “No problem, we know what you want and (because we just talked about all the details) we know we can do this.” Last piece is the timing. This is dev need #2 but note that it also absolutely a key requirement to allow the business “…to execute their market strategy”. We’ve come full circle – the business needs stuff that requires engineers, the engineers have to understand what they want, business needs to know when it can be done, engineers must know when the business expects it to be done – everyone is happy (in theory… reality is brutally complex sometimes). Of course, when it comes to delivery, the business wants everything yesterday and it is the lead engineer’s job (or, just “you” in a lot of cases) to tell them they’re nuts and software is approximately 1000x easier to talk about than to deliver effectively. More discussions ensue, devs talk about testing, managers heads hurt, some people cry a little bit but at the end, the business will understand if their strategy is viable given what they want and when they want it and the devs will understand what they should build and when it should be done (as well as have a good sense of the fudgeability in all the estimates). Managers run off and manage, developers scurry off and develop and three months later everyone is amazed at the software delivered and the money comes pouring in.
Look at that – we just outlined the entire software development process. We used a list and a couple of meetings.
I’m not being sarcastic – I know that it only sometimes works as I just outlined. But that’s because people screw things up. There is nothing wrong with the process. People have fears, people want control, and people distrust other people so people build bigger and more elaborate processes because what they’re really trying to do is control other people, or at the very least, limit the damage that they believe others will do. And sometimes this might be the right move. The average corporation has a lot more money than risk tolerance and will gladly trade inefficiency for less risk.
But I digress. If you happen to work with good people that you can trust, you really should only need a list and a couple of meetings. Everything else is just executing the work.
Here’s a simple, rough outline that is infinitely scalable if the right people are grouped into the right teams (which can be tricky – it is often not intuitive how to do this given that it often requires a matrix organizational hierarchy).
Use tools (not process) to enable high frequency interactions between team members to generate quick feedback loops on features/ideas/problems under development.
Every week or two (pick one and generally stick with it), review prior week(s) work (what was accomplished, what was not accomplished) and plan coming week(s). During planning, team members talk at a high level about what will be accomplished over the next 1 or 2 weeks. Stories/tickets/cards (the items in the backlog/list) are assigned to team members. Variations: 1 or 2 weeks doesn’t really matter… some people feel strongly one way or another but in my experience, if weekly, the meeting is just shorter.
Every week or two, manage the backlog with the team. Team members look at what new work has come in, what needs to be prioritized and “rough out” specific features/stories/tasks as they see fit.
That’s it, that’s the process. Of course there is more work to do – there will be demos and proposals and testing and etc. But those are just mechanics/execution/”the work” – good engineers working with good managers know how to do all that stuff. They don’t need a process to tell them how to do it.
Look, all of the latest, greatest software processes purport to do what I’m suggesting a process needs to do. Otherwise they’d be worthless. The problem is, they also do lots of other things. They create ceremonies, rules, and graphs that require interpretation and alignment in every team to be useful (if they ever reach that point… and optimistically, it usually takes many hours of meetings to do so). But if you trust people, hold each other accountable and take ownership for the product, a list and a couple of meetings is all you should need for a highly effective software development process.
Last thought, as always, above all, do what makes sense. The team should do what the team wants to do that meets the needs of the business. And, as outlined above, the business requires “…the dev team deliver the product/software/service/thing that ultimately allows them to execute their market strategy.” If they do that, why would anyone care what the process is or what it is called?
