11–20 of 329 posts
Agile is a mindset.
Understand the mindset, absorb it, make it yours, and build the process that's working for you based on that mindset.
Stop complaining about Scrum, it's just a tool, and tools deprecate.
I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the processes that dominate will reflect those priorities.
On average, the first priority of managers and execs is maintaining the power structures that make them a big deal. But true Agile processes are about empowering teams to self-organize around serving users. Ergo, Sturgeon's Law [2] applies here too: 90% of company software process is crap.
I think reason why Scrum in specific won out is that it combined a process framework unthreatening to executives with the multilevel marketing scheme of Scrum certification. Executives got to keep doing what they were doing, the workers got a "didn't stop breathing" certificate, and coaches got paid. Win, win, win!
[1] http://williampietri.com/writing/2011/agiles-second-chasm-an...
At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
The project mgmt response was, "Attendance at standups is mandatory."
Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together.
Then I got fired. That solved all my scrum problems.
He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…
It's not even software specific. Which is actually a strength.
Example, one common misconception is the daily standup is a status meeting. In fact you are supposed to replan in standup, it's a tiny planner. Not sure how you can call the ability to pivot every day not agile.
EDIT: Unpopular option, software quality is poor and it has nothing to do with scrum.
At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
Otherwise, here's a couple of notes freely given with no claim to excellence except that I've worked with successful scrum teams and unsuccessful ones:
* The 'business' is everything. All code is liability. Code that can't do things the business wants to do and hinders those things is a particular cost to the business. Product Owners who don't understand that "refactoring code to make it extensible before extending it" is the cost of doing business just have to learn that lesson. If they won't, let them go. Bad ones are a dime a dozen so you can always hire another clueless one if you want. It's like having a loan that you're paying lots of interest on. Saying "We can't spend time refinancing that. We have to go earn money." doesn't make sense as some absolute truth.
* Engineering is not in contrast to the business side. There is no need to represent engineering because the product owner is supposed to be able to understand all inputs into the program. If engineering is slowed down by the lack of dealing with some technical debt that's not some engineering problem divorced from the business. It's the business. This requires reaching across from the engineering side, being clear when things aren't going well, not starting on ridiculously long "refactoring" projects that are just lateral changes, and being clear what the expected outcome of any tech debt relief is. Avoid "feels cleaner", "is more elegant", "is more extensible". Talk in terms of outcomes: faster response to outages, the ability to add things like X (requires you to understand the product some, which is something an engineer should do), less time spent debugging issues. If trivially measurable, measure and demonstrate improvement. Builds trust.
* I'm not too convinced "Scrum Master" needs to be a solo job for anyone. The incentives are skewed. If you have a team of ideal people and they all pick up on the principles and you correct the bad patterns they have, they won't need you. The job inherently obsoletes itself which means the median person taking the role will entrench themselves in process to keep themselves relevant.
* 20 people at daily standup makes no sense. It's 10 minutes or 15 or whatever so you have 30 s to describe something. It isn't so much the time, though, but the fact that there are too many people here together in the room. It makes no sense. Find smaller units of organization. Conway's law presents but the alternative is much worse.
Earlier quoted context omitted.
> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
Managers are the only people that like daily standups, so far as I can tell. I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
Then ppl came along and said that they were "too complicated" we need something Agile! In actual fact, those ppl didn't understand the process frameworks and just created a specific instance of one and they wondered why it didn't work for all projects, organizations, technologies, etc. And then they said those processes are "too simple" - what can we do? "Maybe we should create a way of generating a process?", they then said. And so it went...
Earlier quoted context omitted.
> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
Managers are the only people that like daily standups, so far as I can tell. I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
Think of it from the point of view that managers have mangers they report to. When shit goes wrong they have to cover their asses. "So it's late. But did you check on their progress? Wait just over slack, no actual meetings? Ok, that obviously needs improvement".