The Mythical Man-month is a timeless collection of software development essays compiled by Fred Brooks. In the first chapter, The Tar Pit, Brooks likens the joy of programming found by building things that work, solving problems and the pure entertainment of learning new things along with producing tangible products that once were merely thoughts, with the woe of not having the power of deciding what to build and when – these are decisions usually made by stakeholders or (often) project managers.
But what can Scrum masters do to address this paradox? Scrum masters are often seen as project managers that implement agile practices. But in reality, a good scrum master should – and must – put in practice the culture fostered by agile frameworks to balance the scope (the what) and the schedule of a project with the joy of engineers in building things.
There are several ways that this can be achieved. In this blog post, we’ll cover some of them.
Fostering creativity
One of the principles proposed by Brooks in The Tar Pit chapter is that programmers are motivated when they learn new ways in solving a problem and when they see their products working, solving a problem in real life. If you’re following scrum, then during the retrospectives you must propice a space for engineers to talk about what new tools, features or enhancements can be made in the project. The technical outcome might be implementing static code analysis tools, or allocating some time to do a refactor to implement best practices in code design (i.e. clean code).
By making sure that you – as a Scrum master – allow engineer to be heard and foster their creativity by working with your PO to prioritize the proposed tools or enhancements, you’re effectively keeping the joy of programming that Brooks in his book, The Mythical Man-month describes in the first chapter. This brings us to our next item in the blog: working with the Product Owner.
Working along the Product Owner (PO)
It’s easy to forget that the PO is also part of the scrum team. A good Scrum master works with the PO not only to ensure that backlog items are ready, but also to foster an agile mindset in the PO as well. Things that you can do as a scrum master with your PO is to ensure that the PO is focused on adding value on each sprint rather than focused on fulfilling an agenda. Of course, deadlines exist in large projects and there will be marketing schedules that consolidated companies must adhere to. But effective communication of why there are specific goals in a specific timeline is key to ensure that the PO shares the responsibility of the said schedules with the development team – and vice versa! Because when you ensure that the PO is available to share and communicate road maps and timelines with the team, you open the door for the team to provide feedback to PO on the feasibility of the road map.
If you open this two-way road of communication between the PO and the team, you’ll be balancing one of the problems pointed out by Brooks in the Tar Pit where product schedules are overwhelming for the programming craft. You see, schedules are not just laws that must be enforced into the developers, but shared goals that must be shared among team members: both engineers and product owners.
The burden of debugging
Another activity that Brooks identifies as a woe in the programming joy is debugging and reading code written by someone else (or yourself from the past 😉 ). Bugs are often hard to accommodate in a roadmap or a sprint because a) Bugs are not planned and b) they don’t add value to the customer (rather, they remove value from what the team has worked on).
So, what can you do as a scrum master if bugs are inevitable and no one really likes to work on them? Again, work with your PO and the team to leverage the amount of bugs worked in each sprint. Make sure to avoid having a “bug-buster” guy. You know, the developer who always get assigned bugs because he is the only one left in the sprint without anything else to do. Ideally, bugs are in the sprint backlog ready to be worked on by anybody.
Keep an eye on the amount of bugs worked in every sprint. If you see that bugs are increasing on each sprint is a very good sign to pause for a bit and invest in a good refactor. You don’t need to wait until a retrospective to talk about this – you can schedule a call with key members (an architect, a lead developer, the usual “bug-buster” guy) and the PO and evaluate if there is a technical debt component that must be addressed.
Contemporary solutions for timeless challenges
As you can see, even though The Mythical Man-month was written almost 50 years ago, current industry standards such as scrum resonate to what past engineers and software development teams faced in the past.
Do you want to read The Mythical Man-Month by Brooks?
You can buy it from here and you’ll be helping this blog for more content like this. Thank you!