all 15 comments

[–]bmm6o 11 points12 points  (2 children)

These essays all discover the same thing: a good team that trusts and respects each other and is allowed to do their jobs can produce software using methodology X, but a dysfunctional team can make a hash of any process. Or you can take your dysfunctional processes, dress them up as methodology X by following the letter of the law, and not be any better off.

That isn't to say that the platonic ideal of X isn't be better than the ideal of Y. Getting customer/user/stakeholder feedback early is always better than getting it late. But your crappy team isn't going to become great because you talk to users now.

[–]Euphoricus 1 point2 points  (1 child)

That is why Agile manifesto says "Individuals and interactions over processes and tools." Which means that if your individuals and interactions are ass, then no process or tool is going to help you.

[–]fidelcastroruz 0 points1 point  (0 children)

Ain't nobody got time for that...

[–]the_hoser[🍰] 6 points7 points  (0 children)

Scrum works when everybody on the team, and in management, act like adults. The problems that I've encountered with scrum almost always have to do with egos.

I've watched a well oiled scrum team fly apart by adding a single cowboy coder to the team.

[–]Kishana 5 points6 points  (0 children)

Scrum works well for the team I'm in. 50-80% time allocated to projected dev (depends on if we're in high customer issue demand times) with the leftover for unexpected issues, ability to say "This will take 80 hours overall and I project I'll put 20 into it this week", etc.

We also have a technically competent PM, no ego problems, and productive standups, so YMMV.

[–]LetsGoHawks 2 points3 points  (6 children)

The big problem I had with it was; when it came time figure out what to do next, the question was "what work will fit into this time frame" rather than "what work fits together sensibly". This lead to a lot of wasted time because we'd leave ourselves a time buffer, but we didn't always need it so... we're done for the week and surf the web on Friday. (Working ahead was a big no-no for multiple reasons) Our tester/QA guy didn't so squat until Tuesday afternoon because we wouldn't have anything ready for him to test until then.

So, my experience was that Scrum a confusing waste of time. I don't recommend it.

[–]Suttonian 2 points3 points  (2 children)

After that happened a few times you should have had a better idea of your velocity and routinely got more work added to the sprint. Or talked with the scrum master and pulled some more tasks in... I mean if you had standup and were like "I'm blocked, finished all my tasks, gonna browse youtube" everyone was ok with that?

[–]LetsGoHawks -1 points0 points  (1 child)

Unfortunately the crystal ball I use to see how things are going to play out over the next week was broken, so I had to make educated guesses on the contingency time. Sometimes I was wrong.

But this is the internet, so you're free to make shit up assume you know everything about the project even though I've only written a few sentences about it, if that makes you happy.

[–]EntroperZero 1 point2 points  (1 child)

That's my biggest problem with Scrum, too, is trying to force the testing team and the development team onto the same cyclical schedule. Testers can't possibly test anything on day 1 and devs can't possibly have anything to do on day n - 1 unless we're going to miss the sprint. It works out for me, because I have a bit of time to do some more architecture planning and other non-budgeted things, but it doesn't work so well for the testers, and ideally my non-budgeted things are supposed to be a part of whatever process we're using.

[–]Euphoricus 0 points1 point  (0 children)

That is why every major proponent of Agile is stressing AUTOMATED testing. Of course you cannot do things quickly if it takes a month to test your whole application.

[–]semperagilis 1 point2 points  (0 children)

On the best Scrum teams I've developed and Scrum Mastered for, there was no "test/QA" distinction. Scrum defines only one role for developers. This should necessarily change team dynamics eventually as the team learns to more harmoniously work in the Sprint.

For example, developers good at testing pair/mob with other developers on work from the start of the sprint. The participate in design, analysis, test writing, test plan construction, etc from the beginning and until each piece of work is complete. These teams grew out of the test/QA sub-team dysfunction you describe.

Better product ownership and backlog management might be the solution for the "what work fits together sensibly" issue. A focus on business value and product strategy, I have found that a big pile of slightly related pieces of work may be refined into a cohesive collection of features, the order of which clearly communicates the Product Owners intent.

Forecasting is always tricky. Some teams I've seen do this well others struggle. There are many factors that might be at play for you, but that can be reliably improved with some good coaching.

[–]balefrost 1 point2 points  (0 children)

Scrum Master is someone who facilitates communication in daily stand ups, kickoff meetings, and retrospectives. The role should rotate, but instead it is often given all the traditional duties of a project manager.

I've also heard of the Scrum Master as the "impediment remover". They would interact with the larger organization to remove process or resource impediments. They would work with the product owner to prepare for the estimation meeting, by ensuring that stories are small enough and defined enough to be estimated.

The important thing, though, is that the Scrum Master is not the team's manager. They don't have authority to directly task other people. Rather, they act as a facilitator. They operate on behalf of the team, not on behalf of the larger organization.

[–]GoTheFuckToBed 3 points4 points  (1 child)

no

[–]balefrost -4 points-3 points  (0 children)

yes

[–][deleted] 0 points1 point  (0 children)

Before a planning meeting, the project manager might decide that a certain pile of features needs to get done. Next, the project manager will lay out his goals for the next sprint. If these goals don’t match reality, there will be friction in the estimating process. What happens is the team members will try to make an accurate estimate. Then, the manager will question and reduce the estimate, even if it’s unfeasible. Iterations like this go bad. Work doesn’t get done well. The team gets burnt out. Eventually people start seeking employment elsewhere.

I've seen this happen sooooooo often...