SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.
Why would you hate spending 1 month out of 4 for “planning” and then 40% of the time in the remaining 3 months also for “planning” resulting in a massive destruction of productivity all so you can now claim that “yeah, you delivered a fraction of what the company was delivering pre SAFE, but at least we planned on delivering a fraction of what we delivered Pre-SAFE.”
It is a good question but the answer may be unsatisfactory: it depends. I think that the popularity of scrum is due to its catch-all nature and the way it sounds reasonable when you explain it to someone, especially a non-developer.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from.
Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it".
Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot.
Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better.
When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical.
For existing or larger organizations, I think what you're saying is very true.
This is a very unsatisfactory answer - but you have to grow a culture. Working with people to match their personal goals with organizational goals. High degree of mutual trust. Cooperative design. Group ownership of the codebase and rotating responsibilities. Lack of 'magic knowledge'. Sufficient infrastructure development to reduce rote workload on developers.
All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.
That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
No, you're totally right though - culture is everything, and the experience of being a part of a team how it works is everything.
I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
We do a very loose agile process and everyone seems to like it. Basically, we have a standup every morning. Each team member has up to 1 minute to list (in very brief form) what they did yesterday and what they plan to do today.
It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.
Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.
This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.
We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
"what they did yesterday and what they plan to do today" is not something you can read off people's commits
"I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y.
Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.
Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.
Each person is limited to 1 minute, and most people only use about 10-20 seconds. So, the meetings are usually done in less time than it takes to go to the bathroom. I think everyone sees the value in calibrating our trajectory for a few minutes every day -- it often saves more time than it consumes.
Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business.
This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready.
Would love to hear anyone's processes they used that have worked well for them from start to growth.
Personally, I think SAFE or Agile/Scrum are good starting points.
The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.
The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
I heard an interesting perspective for startups - Kanban/Scrum is useful sometimes before launch, and not using scrum after is beneficial.
Mostly because launching changes so much.
Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.
I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
I developed an alternative called “Hot-Potato Agile” while at Google. I got buy-in to try it, but then was laid off in January just before we could start. So if you have a team that likes sprint cadence but hates the scrum busywork and is open to an experiment, let me know! I still want to flesh out this thing’s rough edges.
