I see where you’re coming from — and sadly, many people nowadays experience “Scrum” like this. But that is just — as I said at the beginning — because Scrum is so often misunderstood and executed wrong.
Some of the psychological effects of pen & paper:
- It is in-your-face visible! No website in Jira you have to pull up — it is on your wall staring at you all day long.
- It doesn’t limit your way of creating a workflow to what the software you use dictates. No software tool UI is as flexible as pen & paper. You should develop your workflow, not a foreign software tool (people and interactions over processes and tools!)
- Actually moving these post-its yourself as a developer makes clear (to you and the PO), that you control the pace of your work. It also quickly and mercilessly shows, if there are (hidden) blockers!
- In teams some people feel more savvy with a software tool, some less. This leads to these team members being outpaced and in consequence splits the team and inhibits communication.
If these stickies on the wall as misunderstood as “we’re only doing this for the agile coach/scrum master”, then something is wrong! The stickies are there to dramatically enhance transparency and mercilessly show, where a team needs to improve — that’s what many developers (and also the management guys!) fear! But transparency and unearthing problems (to then solve them in a methodical way) is at the core of any agile or lean thinking. You wouldn’t believe, what management and development mess we could surface in some companies simply with stickies on a wall! It seems harmless (even childish, as you said), but it’s so mighty, that it frightens the shit out of management (and some developers).
About finding a good agile coach:
Sadly, you’re right. It is damn hard to identify good coaches. And having been part of a development team certainly is no sufficient precondition for a good coach or scrum master — it is just an indication.
To the grass roots nature of agile:
In essence, management still mostly rejects agile and Scrum! What many companies do is cargo cult agile. They “play” all the ceremonies and give people roles, but under the hood, nothing changes. Management still rejects the idea of agile, but they want the benefits nevertheless — and this is the reason, why many companies fail in transitioning to agile. Sadly, for a lot of innocent team members this is their first contact with agility and they’re disillusioned afterwards :(. And then coaches like me have to show them, that what they learned to be “Scrum” was not agile at all — and that’s a tough job. I do this every day in companies and I also try to help with articles like this and my video courses. It could be so much easier, if not so many greedy morons would mess things up — but as I already said: that’s the price of something good becoming mainstream.
Words like “position”, “way up”, “become a manager” are all so far away from an agile thinking, that I can understand, that Scrum cannot work in such a setting. Scrum is very, very simple — in itself, it doesn’t do a lot. The basis for it to work is the often cited “mindset” shift — a new set of fundamental human values — if this agile thinking is not established, you can do Scrum ceremonies all life long without seeing any positive impact.
And that you say, that the product owner would still “rule the team” and “push work” shows me, that there is no sign of any agile values and culture present — and maybe also no will among management to really become agile. Because where before project managers were essentially controlling people directly, they’re now forbidden to do this! A product owner can (and must) only decide, WHAT has to be done. Because the PO should understand best, what has most business value (this includes architectural enablers btw). The team has total freedom about HOW they do it and how LONG it will take — they’re only restricted by the WHAT of the PO and the demand to deliver business value regularly. This is usually much more freedom than developers had in traditional project management models — and it means more responsibility, too.
The person to keep an eye on all this is the Scrum Master! If a PO doesn’t play their role and try to dictate estimations or technologies, the SM will step in and defend the freedom of the team (with his life! A good SM must be willing to risk their job for the team!). This is why it is so important to have an EXPERIENCED scrum master — not just someone with a certificate. And yes, these are also hard to find and expensive, but messing around with junior SMs will cost more than hiring a pro for a few months!
And let me reiterate: just “playing” Scrum by doing the ceremonies and giving people roles will NOT improve anything — it will often even make things worse. It is the agile thinking (among the development team as well as among management) that will give you the huge boost which makes agile so attractive for many. Sadly, this is also the hardest part to inject into a team or organization. It cannot be learned from a weekend course, it cannot be certified, it will not work for everybody. It has to be tried, experienced and lived — it will be painful and it will repel some people, but there is no way around it.
No one learns walking by reading a book or getting a certificate — as kids we all have to try to walk, fall, try to walk, fall, … until we can finally walk. The only thing we need is encouraging parents, who let us try again and again and who protect us from falling off a cliff and hurting us badly. Agile coaches are like parents: they mitigate the risk and let you fall and learn to walk in a safe environment.