Like many people my age in this industry (software development, if that was not clear), I remember how things worked before the internet and before...
For further actions, you may consider blocking this person and/or reporting abuse
I very much enjoyed reading your article and agree completely about the post agile, scrum environment. However one thing I'm struggling with in an asynchronous, iterative environment (with few meetings) is how to make sure everyone has a shared understanding of the goals and remains on the same page? Do you do this with more extensive documentation? Larger up front design meetings and then fewer planning meetings?
Meetings are just a tool to get consensus. Other tools are available but you still need to get consensus for teams to be effective. Ultimately you need issue trackers and processes for getting work defined in there. So getting consensus revolves around using those tools effectively.
A lot of OSS projects have the same need for consensus and have converged on having policies about communicating in the open and in a place where things are visible, archived, and structured. So instead of having a lot of 1 to 1 communication via email, phone, etc.: document things in an issue tracker. Have a debate on a shared slack channel or mailing list. A lot of this stuff boils down to culture.
That being said, there's nothing like some good face to face time. And meeting people once in a while helps. Doing e.g. an all hands session for communicating big decisions; having maybe a project kick off somewhere, or just meeting a couple of times a year in some location for everyone to catch up are all valid things to do.
Heh. Just today I was telling my colleagues that consensus actually isn't necessary - a lot of our decisions are so small and inconsequential (because we do small steps and thus small decisions) that getting consensus is probably too costly most of the time. We work quite well with the principle that most decisions can be made by two random developers (and have added a Slack random reply to pick a random dev in case someone needs a decision made ;-)).
Yes, it's more about providing the opportunity for people to get involved than people actually getting involved. You facilitate that by working in the open. Tag relevant people to your tickets and PRs, maybe drop a line in a slack channel, and if nobody starts arguing otherwise, you merge without having to call meetings or involving the entire team. IMHO communication and overhead needs to be proportional to the impact of the change.
For bigger teams having separate people doing the merges promotes a culture of reviews. This is exactly how OSS communities function; you don't get to merge your own PRs. Which means you need to communicate effectively to get your work in.
You quote Royce as saying
and position this as support of an "iterative" approach. Actually, it's the opposite. What people today call "iteration" all too often means to take whatever piece of crap was slapped together the first week and use it as the basis for work over the next year. Royce was saying build something, then throw it away and start over again.
The point Royce was making that you learn from what you did the first time. Of course he wasn't doing this every week. That would not be feasible with all the work he was trying to cram in. But he recognized the value of doing things more than once. This spawned spiral and later proper iterative methods in the eighties and nineties. Eventually resulting in Agile. The main progress here is the number of iterations/releases and the reducing the time that takes.
My fundamental issue with the continued uptake of Agile, Scrum and Devops is the devolution of responsibility. For a lot of people who work in IT they don't do the job to be responsible - they do it to code, to scratch that itch and to build something. Making teams responsible in the 'you own it, you run it' manner is not in my opinion a simple matter of cutting them loose and them blaming them when it goes wrong - you need to support the people and the processes. It is however a good thing to put techies closer to users - but not all techies are made alike. What is good for some is not good for all.
I've worked in many companies for over two and a half decades and in my recent engagements I've noticed increasingly levels of stress among dev teams who know they are going to have to support the whole stack when it goes live. This adversely colours development practice, it confuses codebases in swathes of (often unnecessary IMO) automation and encourages little in the the way of risk taking when it comes to design. Paranoia and burnout is actually now becoming commonplace whereas once it was little heard of.
I struggle to say that I preferred the day of the PM and the Gantt chart however in some ways is big business going down the right track with their view of Agile and Scrum? I think for the most part there needs to be a more nuanced approach to this rather than what you often see - enforcing new tools and new ways of working which a) upsets everyone's rhythm and b) gives responsibility to those who neither asked for it or want it going forwards. Time for a rethink..
I'd say in a small team responsibility and accountability are a given. I've worked in startups where there is not a lot of ceremony around going live and people do the devops because there is nobody else doing it. I've seen some surprisingly effective teams that run circles around most of the corporately unagile teams I've been in. In most bigger teams accountability is indeed the problem. People like to deflect it. So you get people asking each other for permission and then insisting on checks and balances and then asking for senior managers for permission.
Actually writing this in between two completely bog standard and risk free deploys to production. Nobody to ask for permission (or forgiveness). Actually works.
I like your post very much. And may I translate your post into Chinese and post it on my Blog. Of course I will put the link of this page and your information on the post.
You have my permission; thank you.
May I :) I'm also in IT before the internet era, I have also known UML, RUP, MDA fashion, then Agile, Scrum and before IT I came from Industry and had known the hype about Quality Revolution. But Deming the Grand Father of Quality was very upset as told by one of his friend I met because it just became Marketing. So what's happening today in Agile is just the same. As for DevOps, automation etc. it's good but far from enough because it tackles the easy part : the downstream whereas the hard part is upstream the connection with Business. Being also on Business side I can say IT is wrong headed when he thinks that complexity lies in their side alone. IT doesn't do much to ease the process for Business People in Big organisations (I'm not talking about startup). Take something like Gherkin for example used by Agile wanabees who try to impose that to a User, no wonder why Business people jerks :) And they've been more agile than IT since long since they had known lean hype before IT so they're laughing when IT comes to tell: oh we have a new revolutionnary way of working ;)
So as Deming says, stop slogan, it's time for Software to become less social hype activities and more engineering activities. The problem with UML is not UML per se , the problem is it's been created by academics who have no real world experiences in the tranche, and by software vendors who don't care much about being really streamlined. That's why I'm working on meta-tools myself because I'm really fed up by this state :)
Well put! Async iterative collaboration is the future.
Great post! Thank you!