Bad Reputation
How Poor Leadership Taints Software Development Practices
Everything evolves. Technology is a common example of the ongoing digital revolution, with new frameworks and languages appearing at a constant pace. The field of how we engineer software is also changing, with new practices and techniques being defined every few weeks. Agile has existed in name form since that infamous conference in 2001. Since then opinions on it’s adoption have existed in equal measure.
I’m fortunate enough to work with engaged colleagues who read as much as me. A recent find of a 2015 article on abhorrent Agile techniques, including some aspects of Scrum by one of our team has caused considerable debate in the office.
The entry is… interesting. It certainly lives up to the initial disclaimer of rants, essays and diatribes. Some points such as the affect of open plan office spaces on work rate align with my recent musings on the affect of workspace on developer productivity. Other musings raise valid concerns of the deprioritisation of technical debt over user features, which can be a symptom of poor craftsmanship.
The main premise of this article is to call out how terrible Agile, and Scrum in particular, are without proposing alternative solutions. Digging into the details, I find the article to be an unfortunate symptom of bad experiences. Here I reflect on my experiences of developing software over the last seven years in Agile and Waterfall environments. Not to rebut, but simply to highlight how weak leadership can taint practices within software development.
I Want You
The Technology industry has greatly suffered from sweeping statements regarding developer stereotypes. The quintessential developer that people imagine is still the pale antisocial guy sitting in the corner furiously typing away late into the night to create his vision.
Programmers tend not to be great at managing clients. We’re very literal people. We like systems that have precisely defined behaviors. This makes working with non-technical people harder … because we tend to take every request literally rather than trying to figure out what they actually want.
Michael O’Church, Why “Agile” and especially Scrum are terrible
Long gone are the days where programming is a solitary occupation. Working with people, technical or not, is a challenge. We are all fundamentally different. In business driven domains technologists may speak the same language, but ideas can be presented differently based on the individual. Jargon between different frameworks and languages contribute to these challenges. Our recent games of discussing Angular and REST services are a classic example where engineers themselves are speaking different languages.
Clients have diverging opinions on what features they want. Fostering curiosity in engineers is vital to encourage them to figure out what users want. Our strongest developers sit with our clients regularly and observe their processes. By understanding the process, and the technical possibilities, those engineers propose great solutions to the problems our users face. These ideas often differ to the stated client request, and have often been accepted as the preferred solution. Leaders will encourage such collaboration, and see that this time is better spent than daily pinning programmers to keyboards, expecting a churn of N lines of code per day.
Wherever You Will Go
Product strategy is an often overlooked concept in both the Waterfall and Agile projects that I have worked on over the years. I’ve had different successes and failures utilising both paradigms. This needs to be balanced with smaller, more manageable deliverables.
Corporate Agile, removed from the consulting environment, goes further and assumes that the engineers aren’t smart enough to figure out what their internal “customers” want. This means that the work gets atomized into “user stories” and “iterations” that often strip a sense of accomplishment from the work, as well as any hope of setting a long-term vision for where things are going.
Michael O’Church, Why “Agile” and especially Scrum are terrible
I’ll admit the strategy surrounding the product is often obfuscated from developers. I’ve been fortunate to experience empowerment to write user stories collaboratively with users that provided an explicit benefit. However, with both paradigms I have experienced lack of clarity on what the wider goal is, and what the roadmap is to achieve that goal.
One historic project I worked on managed in a Waterfall fashion simply had a goal of automating calculations, with no strategy to exposing users to the results. This was partially down to a refusal to adapt to change, resulting in an unsuitable solution being presented months down the line. In comparison, our early Agile experiences resulted in lots of small, useful features being delivered in a matter of weeks that combined didn’t form a cohesive workflow. Talented leaders will foster an element of purpose to promote passion among programmers using a defined product strategy.
If your firm is destined to be business-driven, that’s fine. Don’t hire full-time engineers, though, if you want talent … Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.
Michael O’Church, Why “Agile” and especially Scrum are terrible
Successful technology solutions become ingrained into our regular routines. Early innovations at PARC labs on smaller devices established that their success is dependent on their usage becoming knitted into the fabric of daily life. Our strongest developers understand user needs as well as the technical challenges. When they leave, they take that knowledge with them. As leaders it’s important for us to retain our full-time talent. Hiring consultants will help us address technical challenges, at the expense of understanding client needs.
I’ll Be Watching You
No one wants to feel micromanaged. Agile is advertised as fostering collective ownership among developers, over the traditional top-down management profile of Waterfall. I’ve had differing experiences of adoption of nanny-state surveillance by managers.
Scrum is sold as a process for “removing impediments”, which is a nice way of saying “spotting slackers”. The problem with it is that it creates more underperformers than it roots out. It’s a surveillance state that requires individual engineers to provide fine-grained visibility into their work and rate of productivity.
Michael O’Church, Why “Agile” and especially Scrum are terrible
Levels of supervision depend on the levels of trust exhibited by leads. One of my last frustrations of a Waterfall project was the sheer number of status meetings I had to attend to satisfy the obsessions of the Project Manager and Technical Manager. Deliverables were severely impacted as we spent more time talking about our deliverables than actually producing them.
By comparison, my experiences of Scrum and Kanban have been far lighter touch. Stand ups are more around communicating status and voicing blockers. I can then engage with colleagues to remediate any problems. The culture of these two teams has had more of a contributing factor in my experience than the software management paradigm.
No Silver Bullet
Across all Software Development techniques, there is considerable debate on the best approach. Large organisations prefer to establish a one-size-fits-all approach to software development. It’s human nature to want to facilitate receiving what we want more quickly.
Scrum is the worst, with its silliness around two-week “iterations”. It induces needless anxiety about microfluctuations in one’s own productivity. There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. It just makes people nervous. There are many in business who think that this is a good thing because they’ll “work faster”.
Michael O’Church, Why “Agile” and especially Scrum are terrible
Expectations do need to be managed to ensure clients don’t expect you to deliver the world. We did have experiences with Scrum initially that we delivered more features faster, which won user favour. Nevertheless, the need for space was spotted quite soon to ensure engineers had learning space. Otherwise, you establish an inconsistent work rate, with effort upticks immediately before and after releases.
We found Kanban to be more effective at establishing a constant rate. This prevented team burnout in our case. Other teams in our area still prefer Scrum, as they haven’t had the same cadence challenges.
Engaging with technical and non-technical colleagues alike is important to evolve your development techniques. Brooks stated that there is no silver bullet to solve the trials of software engineering. Neither Waterfall or any Agile methodology will fit every use case. Leaders need to trust teams to establish the techniques to take down the monsters taunting their development processes, using many smaller bullets.
Thanks for reading! Comments and claps are always appreciated.
