“The only ‘real’ work in software development teams is writing code”
Are you Serious? — Episode 63
The ‘Are you Serious’ series tackles Scrum misconceptions. All its articles have this theme and can be read on their own.
Agile approaches such as Scrum are demanding for software developers: new skills are required in order to thrive in a team environment. It is not enough for a developer to churn out complex code seasoned with fluent APIs, elegant implementation of design patterns and awesome algorithms. These days, developers need communication skills too, as well as an ability to collaborate, and a genuine respect for ‘the business’ side of software development.
After all, the code would not exist without the business need driving its creation. In software development teams like Scrum Teams, shouldn’t we all help each other to thrive? In order to do this, Software Developers need to avoid snobbery towards work that does not involve writing code, and resist the urge to be tortured artists, ninjas or — worst of all — ‘10x developers.’
A Question for Software Developers
As developers, we need to ask ourselves: do we believe non-technical work is important for a development team? Or do we believe that only code is important, and everything else is ultimately disposable?
I believe that this question is at the core of the challenge with agile approaches and their chances of success in teams and organisations.
If software developers look down on non-technical work and see it as inherently less valuable than writing code, collaboration with stakeholders will become more difficult.
Here’s the thing. Writing and maintaining code is expensive. A business hires people to do it in order to satisfy a customer need or a business need.
Ultimately, no matter how well written your code, it is ultimately a means to this end, not the end in itself.
When you look at things from this perspective, writing code is similar to many activities on a development team:
- Understanding business and customer needs is valuable.
- Clarifying those needs as they adapt is valuable.
- Ensuring that we do just enough work and no more than is absolutely necessary is absolutely valuable.
- Ensuring the customer is always aware of what increments they will receive and when is valuable.
- Building relationships and safety inside software development teams and organisations is valuable.
None of these valuable activities can be successful with writing code alone, and all the conversations on modern software teams that use agile approaches are designed to keep all of these valuable activities in view, so that the best quality code can be written.
Your definition of ‘real work’ in software development should include these activities if you want to be a part of a successful team or organisation. In my mind success means satisfying customer needs and avoiding wasteful work. Does that match your idea?
If we fail to satisfy customers or work wastefully, we risk working in selfish ways. We might just want to be left alone to write code… but what if that code never makes it to production, or worse, is never actually needed by anybody. What a waste for the business, what a missed opportunity, and also, what a waste of your talent!
Wouldn’t it be more meaningful for you (and less wasteful for everyone else) to solve the most important problems for customers? Long-term, doesn’t that approach give everyone the best chance of success?
Agile Approaches demand Social Skills to Succeed
When those 17 guys came up with the Agile Manifesto in 2001, they were all working on different philosophies and approaches to building software. Their approaches were all incremental, iterative, lightweight, and oriented towards creating the right working environment for people and teams.
In writing the four values and twelve principles together, they found common ground between those different philosophies: what could really improve software development in teams and organisations?
They settled on many common threads. Among them was one about the evolving role of software developers. To succeed as individuals and in teams and organisations, developers needed to evolve, adapt and learn new skills. Developers needed to be more effective in the world of business, and to understand ‘the game’ at the same level as so-called ‘business people’.
The new definition of ‘real work’ outlined in the agile manifesto appeared to include more than just writing code.
Communication Skills
Before 2001 for example, Kent Beck was working on a lightweight approach to software development along with Chet Hendrickson, Ron Jeffries and Ward Cunningham. It was called ‘eXtreme Programming’ or XP.
Here’s how they defined it:
“XP is a style of software development focussing on excellent application of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine.” — (Xtreme Programming Explained)
XP places a high value on communication skills and teamwork in software developers. Programmers could no longer just be left alone to work their magic if they wanted to achieve greater things: they needed to recognise collaboration as a part of the job.
You don’t necessarily write code if you are collaborating with people on your team who are not developers. I might be wrong, but I believe this idea found it’s way from XP into one of the principles in the Agile Manifesto:
“Business people and developers must work together daily throughout the project.” — (Agile Manifesto Principle)
Collaboration
Scrum also requires the development team to be team players and supplement their skills writing code with others.
Note all of these references to collaboration from the Scrum Guide (below). In every Scrum Team activity, the Development Team works with others to get the job done, and none of this necessarily involves writing code.
Refinement
“This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.”
Daily Scrum
“The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.”
Sprint Planning
“The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.”
Sprint Review:
“The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.”
Sprint Retrospective
“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of ‘Done’.”
Scrum demands that software developers know a little bit about forecasting, continuous improvement, inspecting progress and sprint goals. Demanding!
There is a lot of learning required to develop skills in these areas. However, an a priori requirement for engagement with this learning is respect that this work is just as ‘real’ as writing code.
With this respect in the bank, software engineers will be well equipped to collaborate with business people and to ensure that everyone involved with the team has a better chance of success.
Scrum and other agile approaches help teams figure out how to collaborate inside organisations so that the have the best chance of solving complex adaptive problems together. The end goal is to satisfy the right customer needs without waste, and this requires communication skills, collaboration and respect from everybody, especially those who write code.
To give your team and organisation a greater chance of success, your definition of ‘real work’ should include writing code… and a whole lot more besides.
