Timeline for Team constantly fails to meet sprint goals
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21, 2016 at 21:12 | audit | First posts | |||
| Apr 21, 2016 at 21:12 | |||||
| Mar 29, 2016 at 13:10 | comment | added | Telastyn | @Danikov - it's not failure to use sprints correctly. Hell, most companies do that. It's that they made no meaningful actions to improve over the course of a year and a half. | |
| Mar 29, 2016 at 10:02 | comment | added | Danikov | I'd like to understand the concrete extrapolation between 'failure to use sprints correctly' and 'incompetent to the point of firing'. | |
| Mar 29, 2016 at 7:00 | comment | added | Frisbetarian-Support Palestine | How does this answer have so many upvotes? | |
| Mar 27, 2016 at 7:51 | audit | First posts | |||
| Mar 27, 2016 at 7:51 | |||||
| Mar 25, 2016 at 18:10 | comment | added | Brian White | "You're defining your team's success solely by how well they are fitting to the bureaucracy of the methodology". Agreed to a certain extent. People over process is part of the agile manifesto after all. But I heard a one sentence description of agile i liked that seems relevant: keep doing what works, stop doing what doesn't work. Option 1 - get better at story pointing. Option 2 - switch from scrum to kanban, which is also agile. In kanban you just take the most important item off the top without dealing with commitments per se. Can alleviate guilt if that's what you're doing already | |
| Mar 24, 2016 at 23:33 | comment | added | Erik Hart | @Telastyn: Then "make things better" may likely mean: estimate triple or quadruple time/points or scale down quality expectations (e.g. omit unit tests, allow spaghetti code). Perhaps, for some one-time projects, the last might even be acceptable. | |
| Mar 24, 2016 at 23:05 | comment | added | Telastyn | @ErikHart - good developers with bad estimates miss their sprint commitment half the time, maybe most of the time. Missing their commitment for 18 months straight means they don't fulfill their word and don't care to make things better. | |
| Mar 24, 2016 at 22:59 | comment | added | Erik Hart | Will you fire good developers just for bad estimates? Or for new demands and unexpected external dependencies and problems, multiplying development time? Especially when there is pressure like "hey, you want like 4 days for this task, somebody else could code it in 4 hours!". Developers are not politicians, and may likely bow to pressure for impossible commitments. Or they resort to creating mostly untested (not unit test covered) spaghetti hacks in time, which may work in an initial test case, but keep the support team busy and are impossible to maintain after a while. | |
| Mar 24, 2016 at 11:52 | comment | added | gbjbaanb | The thing is, "success" in creating a product is never measured in terms of how much spare time you had at the end of a fortnight. If at the end of each sprint, you delivered working software, then the excess stories you planned into the sprint are irrelevant. They'll be picked up next sprint, so what! You're defining your team's success solely by how well they are fitting to the bureaucracy of the methodology. That is not Agile. @bmarguiles has it right - scrum is a guide, not holy scripture. | |
| Mar 23, 2016 at 19:23 | comment | added | corsiKa | Having worked in a one-product-shop before, there is more pressure to "fill the bucket" than there is in a bigger place with different and shifting priorities. It's possible the devs are afraid to say no even though the things that should go in plus the 'flavor of the month' things from management are more than they can deliver on. It takes a lot of guts to tell the CEO no, no matter the size of the company. | |
| Mar 23, 2016 at 19:15 | comment | added | Lindsay Morsillo | @Orca: In 18 months, you should've been able to cut down the size, scope and number of stories to the point where you achieved some success. I would think 3 sprints is a reasonable amount of time to figure out the smallest pieces of work you can accomplish in a sprint. Once you achieve that, use what you've learned and build up slowly. Build up of the competencies of the team you have. and remember: This is a team sport, not just the developers, but the scrum master, the folks responsible for the product and feature descriptions, QA, etc. all need to work on the solution. | |
| Mar 23, 2016 at 18:04 | comment | added | JeffO | @MichaelBorgwardt - You'd think untrained managers would be more likely to blindly look at failed sprints and hand out punishments without any consideration. I agree that to a certain extent either someone doesn't care about failed sprints or they feel like putting more pressure on the team could have negative consequences. | |
| Mar 23, 2016 at 17:29 | comment | added | Michael Borgwardt | I do not find that hard to believe at all. Most likely the failure to meet sprint goals doesn't cause acute problems because features are still being delivered fast enough for the business side to work reasonably well, maybe because the product doesn't have much competition in its niche and sales don't depend on promising new features and delivering them on time. | |
| Mar 23, 2016 at 17:10 | comment | added | Telastyn | @MichaelBorgwardt - because so many managers have formal education in management? Yeah, there might not be multiple levels of management, meaning the owner has just let this go on for over a year - and I find that harder to believe. | |
| Mar 23, 2016 at 17:01 | comment | added | Michael Borgwardt | A "small software company with 1 product" probably doesn't have multiple levels of management, and quite possibly the existing managers don't have formal education in management. | |
| Mar 23, 2016 at 16:37 | comment | added | Lightness Races in Orbit | Yep, this is spot on. | |
| Mar 23, 2016 at 16:05 | history | answered | Telastyn | CC BY-SA 3.0 |