On every project I have encountered in recent years I have found that the degree of agile religiosity is on the increase.
It is as if the practice of agile gets more and more ornate with time, as layer upon layer of observances & penances are added by adherents, practitioners and training providers alike. These days every company has an agile high priest who brings their acolytes into the forms and observances as interpreted in that company. They start to call this best practice and eventually find themselves bogged down with traditions, ceremonies, practices, certifications & project office compliance obligations that never really met their project needs to start with.
All this project pain being self imposed!
A initial observation in looking at the 2001 Agile Manifesto is that it is presented as an emergent realisation of what makes the process of software development an agile one, based on the author’s actual experience in developing software.
These are (a) experiential guidelines, (b) focused on software delivery, and they (c) set a tone for where the emphasis must lie without being prescriptive.
“Individuals and Interactions over processes and tools” is the exact antithesis of what is happening every day in companies around the world who claim to be following agile. Scrum masters have codified their ceremonies to the extent that the ceremonies (a religious word for processes) prevent real conversations between team members.
The all too often heard “Take it offline after the stand up” means that stand-ups devolve into admin sessions for the project manager at the expense of wasting the time of the entire team without any of the much needed interaction between team members.
Hey Scrum Master — don’t be lazy — do your admin before the stand-up and rather add value by facilitating Interactions between team members by allowing relevant dialogue to take place, while still keeping control over the time.
In order to be able to best do this, scrum masters could make the effort to learn the necessary domain knowledge associated with their project, and this way they can guide meaningful interactions. Every software development project requires two types of knowledge — (a) knowledge of the solution domain and (b) knowledge of the software & devops stack in use. Scrum Masters who are conversant in both of these can add the most value in enabling interactions between team members.
I have sat in stand-ups watching a bumbling scrum master fight with the project tools (partly because the tools themselves are not intuitive to use & partly because they just do not know how to use their tools properly) and valuable mind-space is wasted while constraining the team and project to work the way the tool does. Tools are useful and necessary but not more important than the team and their interactions. When looking at your tech stack (a tech radar is one way to do so) the project tooling becomes an important aspect of how the project is setup and a big driver of project cost — both in terms of license costs and time spent fighting & faffing with the tooling.
I have heard remarks of “anti-pattern” during team project meetings when the team watches while the scrum master fights with the tooling trying to do what should be the simplest thing on the project board. It is true, we all can see when software forces us to do something in an awkward or frustrating manner. For most projects, keeping things simple has efficiency benefits that developers & managers alike appreciate. Simplicity does not mean being feature poor. Taking a look at common project tools quickly reveals why complexity erodes the effectiveness of even the best scrum master.
The agile value of “Individuals and Interactions over processes and tools” is better realised when the project tooling simply works and does not get in the way.
For most software development teams, Teamfu is an ideal project companion for the scrum master. It just works and does not get in the way.
