Why Scrum in Big Hierachies fails without CEx level support
I was hired as a Software Engineer with Experience as a Scrum Master. But.. we abandoned any overhead in our Scrum when nobody was paying attention to the estimations, Jira, Burndown - neither project leadership, nor developers and certainly not anyone from the rest of the corporation.
Sure we still have Continuous Integration and Deployment and some testing and linting architecture in place, also Scrum Demo Day and even the occasional planning between doors. But this is done very quickly or automated, but basically with the major parts of Scrum we did away with. Don't get me wrong, retrospectives are still extremely important for a beginner team, but at many occasions such can be done at the coffee break or lunch. In my opinion you should have retrospective only when it feels necessary and then it should be conducted in an ad-hoc manner - with a moderator.
Being a Team means that Everybody is a Servant
I am still understanding my role as lead Web developer as being a servant. Of course, without monetary power it is pretty hard or seemingly undoable to motivate others to do what seems best for the product and the customer. But if you keep performing yourself until problems are fixed and quality is high, and always, always offer your help and ear and time and attention to your colleagues, chances are people start to giving back and contribute and forget any monetary obligations or ego along the way.
Our CTO is a highly anti-authoritarian and knowledgable servant leader himself
What I do now is in order to keep everybody in synch and to mitigate duplicate work, I create changelogs in our Slack every day.
In this Slack I write down basically the commit messages with enriched detail each midnight of the day with an overview of the whole day. Here you can see such a daily change log:
Oh, by the way, the almighty Slack (Screenshot) furthers direct communication and every other synchronisation is done verbally.
In conclusion, as much as I love Home Office myself, for the merging and communication part, being present in the office seems to be absolutely necessary. Hand gestures, face mimics and subtle communicative messages are not transmitted in chat. So when the heat is on, merging without the code creator present is the devil in disguise. Maybe we will introduce screen sharing over the Slack Plugin Screenhero to mitigate problems of merging code of colleagues that live further down near the Alps.
Closed, Silent Work Environment as root-cause for Success
We have the privilege of being able to work together in one room with closed doors in a very low noise office directly in the building of the multi-billion-euro customer.
This way our CTO can directly "Scrum Demo" and interface with the higher managerial part of the customer and does not disturb at most times the flow of the developer team with the burden of having to sit through pointless meetings or having to argue with snappy careerists.
No Meetings and No Estimates sometimes works
Let's say, a single developer of the high-performing team needs to be present at some inter-team meeting only when it can't be avoided and some leadership personality colleague with interpersonal skill set is currently not available. By staying in flow, we did increase our performance almost three-fold, from 30 story points to 80 story points in only 8 weeks.
Show me the numbers you might say! I don't have em, I shall reply!
We did get from 30 to 80 SPs because we stopped estimating, measuring and quantizing. Humans are organic, complex beings - you will fail if you start to measure performance in order to increase performance. Communication, personal relationships and motivation can't be measured easily and even if - they shouldn't.
Another argument against estimation is that management absolutely reliably always ignores Estimation and Developers hate it - so why use it? Abandon it. No Estimates!
Estimation. We don't estimate anymore. Management absolutely reliably always ignores Estimation and Developers hate it - so why use it? Abandon it.
Important for forming a real team is that you and everybody else in the team keep serving each other, also laggards or whoever you got in your team. Chances are you need their unique skills, too.
Retrospectives are done immediately
When somebody doesn't like something he or she needs to say so. Conflicts need to be resolved as fast as possible to don't let grudges sink in. In essence, when everybody offers his open mind, will and heart you are destined to become a high performing team that pushes out complexity in quantity like a swiss clockwork.
Working Product over Documentation, Specification and Performance Measurements
Our app after 3 months of work is fully stateful and reactive, responsive, themable, multi-lingual, secure and deployable via a seven-letter command to iOS and Android Devices and build in about 7 minutes via the almighty BuddyBuild.
Without my colleagues this marvel would never become a reality, without abandoning the burdon of endless meetings performance measurements and the vast overhead of Story Estimation and Board updates this would not have been possible with our resources.
As a result of eliminating these major impediments, we created this multi-million dollar app in a few months time even on this absolutely horrendous Beta Software Stack, the duo Ionic 2 Beta and Angular 2 Beta, they say - it never rains, but it pours - and it is absolutely true.
Special thanks go to our CTO who is a highly anti-authoritarian and knowledgable servant leader himself. No doubt, servant leadership brings out the best in people and propels you and your team into becoming high performers.