Image CC BY-SA 2.0, Guy Sie
This has been earlier published in Medium
Everyone agrees that it is easy to write clean and functional code that actually works as intended and integrates well to the system it is part of. Of course development processes are also automated from commit to production deployment, feedback is constant through the process from automated quality assurance to production monitoring and proactive customers are eager to help with continuous development efforts.
On an ordinary day the domain of software development is instead a playground for all kind of creative and technical people. Quality of software varies depending on who practices the craft and how. It is too easy to take the easy way out and cook some spaghetti code with bug sauce.
Thats why I’ll take a look at how to craft quality software with a series of blog posts covering software development processes from different viewpoints. Creating quality software is not rocket science but it requires discipline, right tools for the trade and a mindset to build complex systems that are maintainable, extendable and operable with great user experience.
In this first chapter I’ll discuss about one of the most important aspect of any kind of project: people.
The Living context
When managing projects, architecting complex systems with cool new technology (or boring and old if you have bad luck) and multitude of vendors it is easy to forget that it’s not all about “things” and “processes” that count when deciding which projects succeed and which fail. Developing a system may include multiple different actors: stakeholders, team members, other vendors with their teams and so on. These form a living context to cope with, a truly visible layer besides all the things that need to be managed. Except that managing people and interactions tends to be a lot harder than doing Kanban with tasks. I’d dare to say that most difficult problems arise from tensions between people, not from technology.
Following key points describe some of the most important aspects for enabling crafting of systems with perceived business value.
Without commitment there is no focus to deliver quality and problems shall arise. When there is mutual commitment between different parties there is also momentum that makes it easier to make progress. It is crucial to get everyone related to a project to focus on common goals.
Conflicting forces in a project just generate friction that leads the project astray.
Transparency & visibility
Even with strong commitment decisions are done blindly if there is no context available to those who decide. This works when someone is making decisions from an ivory tower and also when freedom and responsibility is given to individuals. In ivory tower management model decision makers rarely have hands-on experience on what they are deciding about which leads to suboptimal outcomes. On the other hand individuals can’t make informed decisions without visibility to relevant information which also leads sometimes to bad results.
Open culture and availability of information are foundation for self-steering teams.
When discussing about how to steer a project towards its goals, its often stated that proper management is needed to make sure everything stays on the track. I would rather turn this upside down and speak more about enablement, enabling people to do their best and empowering teams with freedom and responsibility. Leading a project means enabling success by removing obstacles, shielding team from unnecessary and making personal growth possible.
I’m not saying that that traditional management is not needed but the focus needs to be human centric.
Taking people factor into account and making sure that there are enough soft skills to manage interactions throughout a project is essential for crafting quality software. Enabling individuals and making context visible makes it possible for people to make their own decisions without management level overhead and wasted time.
When people are happy and motivated, issues are discussed openly in a constructive way and goals are clear for everyone it is also easier to apply other aspects of software development into to the same context.