I was lost. It felt like slipping through a crack in the Universe, Sliders-style, into reality where you can't understand people discussing the things you do for years. There were few other developers attending, seemingly just as startled by all this.
The whole thing ended with some Agile activity for all attendants which I can best describe as a mix of kindergarten class and Baptist sermon. I could not comprehend the intent, the procedure and the desired outcome (and whether it was achieved).
People attending SM training are often just middle managers learning enough to know WTF their SMs and PMs are talking about in meetings.
Also, there's no requirement for SMs to be coders, it's a role a lot of BAs take on. Some experience in software development context is desirable tho.
I found a lot of my SM training relateable to real life. My team went crazy for planning poker because it got a lot of assumptions out early.
Standups were impossible because some people started at 1pm, others finished at 4pm.
I see Scrum as a bag of tools to apply to teams. Some work, some don't.
1. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time.
2. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works.
3. Junior (or some senior) developers being stuck for a long while without asking for help.
4. Ignoring the customer and building what you think should be built.
None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.
What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto.
Like always, it's a strange whisper game...
Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.
I think most teams drop agile practices before they have knowledge to show they aren't appropriate, they usually never get used at all. They adopt what they have to because they don't really want to do it at all because they consider a large chunk of it doesn't work.
Changing the process from a position of knowledge and experience on it is one thing, doing it without that knowledge is the more usual thing and its harmful.
To be fair, project managers often decide to keep using X or leave out Y without consulting anyone first.
Also, to be fair, project managers are rarely organized or explicit about where the project is and where it should be with respect to cross pollination. If they tracked their goals there like they did other things, you'd see some developers taking this style of project under their wing.
That being said, my experience largely matches yours. Though I find the success rate in setting up a closed feedback loop (actually demoing for the actual people that should be happy with the actually deployed feature) is much lower than people notice, so I'm not sure agile is as technically useful as it seems. It's politically useful, for sure. You can say "Working on the wrong thing? I gave Henderson eight demos as work progressed this fall!"
And sure you sometimes know that certain things need to be implemented but it should not be done without anyone else knowing it. At least it should be known and agreed upon with the team and then discussed with or made visible for the product owner/PM/whatever role.
But I've worked with guys who spent most of the time surfing the web or were really territorial with their code. Or teams that were just shitty at communicating with each other so you had frequent misunderstandings or blocking. Or people who said "Yeah, this will be done in a week" and then after one week they say one more week etc.
Some are personal issues that should probably be handled by a boss and some are just shitty engineering practice that could be fixed by conversations (provided someone actually knows good engineering practices). But that also requires people not to get defensive and say that we have always done it this way and it works or become angry because they think you are calling them out.
Instead agreeing about things like these:
1. The work we do is agreed upon by all and is visible on a board or website.
2. Every day in the morning we chat for 15 minutes about how things are going and if we need help.
will fix some of them in my experience and the angry people can whine about the process for a while instead of directing that anger at team mates.
You can use process to force change, but, personally, I think a strong manager/leader would aim to resolve these issues irrespective of the process. Also, and I think this is why so many complain about agile, is that it is used to change these types of behaviour and is then seen as ‘the bad _guy_’.
My personal view is that the process should be aligned with your business, not as a tool to fix people challenges.
The 15 min daily catchup is invaluable irrespective of your overall process.
Easier said than done though :).
Happy to talk further and learn from your experiences. Thanks.
Scrum has some really serious flaws:
1) It creates a massive disincentive against refactoring technical debt (refactoring stories essentially have to be 'sold' to the product owner).
2) You end up spending more time than is necessary in too-long meetings. Planning should really be done continuously rather than in biweekly meetings.
3) The idea that you should deliver working software every two weeks is outmoded. You should be aiming to deliver potentially shippable increments continuously.
2 planning can be continuous, just every two weeks you look at what you should focus on next, you can still bring stuff into the sprint along the way if everyone agrees
3 you plan to deliver a bundle of value every two weeks (so you can bite off enough to get stuck into, but not so much that you can head in the wrong direction for long) but you can release as soon as the code is ready, no need to wait until the end of sprint.
That does not make them qualified to rank and/or write refactoring stories.
IMHO, they should tell the developers how long to spend on refactoring/tooling (e.g. 30% of their time) and developers should figure out themselves how to spend that time.
That isn't scrum, though.
>planning can be continuous, just every two weeks you look at what you should focus on next
That's saying on the one hand that planning both is and is not continuous.
>you plan to deliver a bundle of value every two weeks
I call this mini waterfall. It's a good thing to shoot for if you were y previously doing releases every 3 months. It's not a good thing to shoot for if you were previously doing daily releases.
And fully agree the po won't write the refactoring stories, but anyone can write stories. I'm not that technical but I've never worked somewhere where the team wasn't able to talk about the value of tech debt etc and help me understand the value of bringing them in.
They can talk about it, but under scrum it has to be sold to the PO to get it prioritized. I've worked with plenty of dev teams that could talk but couldn't sell.
And it's the hardest kind of thing to sell, because the benefits are diffuse, abstract and usually long term, whereas feature stories are the exact opposite.
I've seen this whole sales pitch/pushback process fail in lots of places. Techie explains problem to PO in techie terms -> PO's eyes glaze over while they nod their head and agree that this stuff is important -> story keeps getting pushed down the backlog in favor of stories that have a concrete dollar value attached. -> quality suffers as a result.
1. The person making a decision like "should we do refactoring" should not be incompetent. They should be technically great and also in tune with the company's business needs. I know some smaller companies have non-technical people in all non-dev roles, so it's either the devs who do the work deciding or a non-technical person deciding, but that is just stupidity, at the very least the guy who is the boss of the development team should be a development guy. I seriously doubt that at for example Microsoft or Google, a non-technical person makes this type of decision.
2. The incentive system should not be messed up. Especially at companies with multiple levels of traditional managers, you have problems like people treating their job almost like a game, where they try to make their numbers good at the end of the year or avoid ever telling their bosses something their bosses don't want to hear... They completely lose alignment with the company's interests and treat their job like a game of looking good to their boss, so even if they understand the need for something they might say no to avoid missing a deadline they told their boss they would hit etc... This doesn't really happen at SD companies because most of them are new and never developed this type of culture but it happens at companies that are in another field and just have a SD department
I also don't think the solution of "30% of time" is good. Sometimes you need more, sometimes less, sometimes it's more important, sometimes less, sometimes more urgent, sometimes less. I still think you should "sell" refactoring to your boss, but the "boss" at a level where "should we refactor" decisions are being made should be an extremely technical guy who also knows how it will affect the business side of the project.
No, it's a process problem. Devs can't directly assess the relative importance of setting up a CI server compared to the new login workflow. If they could, there wouldn't be any need for a PO. POs probably don't grasp exactly how important setting up a CI server is. And why should they?
>The person making a decision like "should we do refactoring" should not be incompetent.
That's a given. If they're incompetent, no matter what process you give them they will inevitably just make things worse.
>I also don't think the solution of "30% of time" is good. Sometimes you need more, sometimes less, sometimes it's more important, sometimes less, sometimes more urgent, sometimes less.
Yeah, sometimes more, sometimes less depending upon how much pressure customers are putting on you, if the trade show is next week, if it's a quiet week, etc. IMHO PO should choose the % each sprint and devs should choose what goes in it.
>I still think you should "sell" refactoring to your boss
That's tantamount to saying you don't want it to get done, because devs are typically shitty salespeople. Also: do you really care whether module B is decoupled from module A or a new CI server is set up? Why not just say "spend 30% of your time this sprint on code quality improvements" and leave it at that?
At most, the devs should sell the % of time they want each sprint. Honestly though, I'd be happy to let that be 100% at the PO's discretion. Just don't make me try to explain to a non-techie why it's important that I need to refactor some tests.
I just don't see the reasoning behind hiring someone who is non-technical for such a position.
And the answer to "why should they" is precisely because they can then understand the development side better and these types of problems are avoided. It allows them to make more informed decisions. Basically, why should they not?
Really? When I look at the list of authors of the Agile Manifesto, I recognize several names as belonging to people who have made a career out of coaching and advising. Several of those people made their careers by bragging about their involvement in a catastrophic failure.
I mean, they're probably all better software developers than I am. But I think that sytelus's description seems to be right on, at least for many of the Agile Manifesto authors.
In other words, agile has just become a stick for companies to beat their developers with. That wasn't the original intention, but I would suggest that's at least part of the reason why management types like the term 'agile' so much.