12 ms·
Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
- saas_co_de 9y agohttp://programming-motherfucker.com/ http://programming-motherfucker.com/
- csours 9y agoI suppose it's as good a programming religion as any other.
- make3 9y agojust saying motherfucker a few times does not magically create a solid argument
- rockostrich 9y agoI don't know. Samuel L. Jackson seems to do alright even when he doesn't have Tarantino writing for him.
- throwanem 9y agoZed Shaw is a treasure. I'm not sure he's all that much of a role model.
- k__ 9y agoWell, he's good at heart and knows his stuff. Like all of us, he's just human
- saas_co_de 9y agoI don't know anything about the guy but his analysis of agile consultants and agile development agencies is spot on.
- taherchhabra 9y agohttps://learnpythonthehardway.org/book/advice.html https://learnpythonthehardway.org/book/advice.html
- lwkl 9y agoThat's probably exactly why you are told that you are socially awkward. Edit: I don't know the creator is there a story to this I don't know?
- subway 9y agohttps://en.m.wikipedia.org/wiki/Zed_Shaw https://en.m.wikipedia.org/wiki/Zed_Shaw
- make3 9y agodo people really pair program in real life? I've never actually seen it
- rebeccaskinner 9y agoJust to counter the other responses here. Yes, and it's even more dreadful than you might imagine if you've never done it. I recommend running fast and far away if you ever find yourself interviewing on a team where pairing is the default assumption.
- dudul 9y agoYes.
- make3 9y agoat which company did you see it, and was it everyone
- spinningarrow 9y agoYes, and I highly recommend it! source: used to think pair programming was odd until I gave it a proper go.
- crdoconnor 9y agoI find it useful for knowledge transfer. It's a good way of bringing new hires up to speed for the first week / two weeks. If you leave them to their own devices they have a tendency to get overwhelmed and fearful of continually bothering you to ask questions. It's sometimes a more efficient way of building stuff where, for a particular task, you need a whole bunch of knowledge or information that's currently living in somebody else's head. Also, if I'm having one of those days when I feel sluggish having another person there kickstarts me a bit... Defaulting to pair programming for every task - especially when the conditions above are not met is a super inefficient and overbearing way of developing though.
- swagtricker 9y agoYes. Pair programming as the default for me since 2004. I've done it full time for 8 years at an XP shop (Scrum was added later) w/ 3 teams of 20+ total on 3 different continents. Worked for an Agile consultancy and trained people on Pair Programming and TDD for 4 years. I'm now working for an org that does both Pairing AND mob programming (https://en.wikipedia.org/wiki/Mob_programming https://en.wikipedia.org/wiki/Mob_programming). It takes time, patience, and humility to learn how to do well. I find teams that pair simply build better software that has less bugs. There's literally a book on it to consider (https://www.amazon.com/Pair-Programming-Illuminated-Laurie-Williams/dp/0201745763/ https://www.amazon.com/Pair-Programming-Illuminated-Laurie-W...).
- DoubleGlazing 9y agoOh yes, this rings true with me. I once worked at a company where the powers that be decided to go all Scrum. They hired a PM to convert all project, inc ongoing ones, to Scrum. It turned an enjoyable job in to a miserable one.
- taeric 9y agoFunny to see this. I thought getting commitment was one of the soft mechanisms of scrum. An annoying one, because power dynamics are always at play. Still a mechanism, though. I think I'm supportive of the idea on removing it. Seems the goal is ultimately to find ways in rhetoric and action to align the teams in working to the end goal. Which, often, might require tradeoffs to reach a timely delivery. And timing is a requirement.
- crdoconnor 9y agoIt probably made more sense to put it in in the beginning when the process was still being sold to senior managers. Now that scrum is much more embedded, taking out for the reasons given makes more sense.
- justspamjustin 9y agoMy team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team together and discuss it. When we see that there needs to be architectual discussions and high level planning, we do it immediately when we recognize the need for it. The idea that you can try and commit to or even forecast how much can be completed for a period of time is pretty absurd. Just identify the minimum requirements of what needs to be done and do it. Retrospective is still productive. But sprint planning is a waste of time IMO.
- jryan49 9y agoIf you read the actual Agile manifesto, what you are doing now is more agile than scrum :)
- smackay 9y agoA lot of the artefacts of a process are intended to help teams transition from the old way of doing things and to help teams who have stalled or failed to deliver. Sprints, as far as I understand them, were intended to get the wheels turning and to demonstrate results at regular intervals so the customers for any software development effort could see progress and gain confidence that the team was going to deliver. Once everything is up and running smoothly then it's entirely reasonable to drop all that and just focus on delivering - you don't need a lot of packaging an rituals to do that.
- hinkley 9y agoBut Scrum is working! Why would we ever change?
- henrik_w 9y agoI agree, I have the same experience.
- jryan49 9y agoI still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.
- philbarr 9y agoAbsolutely - some people hear, "people before process", think it sounds great, then immediately go looking for a process to implement it and find Scrum.
- crdoconnor 9y agoI think that's largely the fault of the manifesto. It is entirely unclear about what putting "individuals before process" actually means. One way I've seen it used was as a way to justify organizing meetings as a means to solve an increase in defect regressions rather than allocating extra work on automated tests. The former was "individuals and interactions" and the latter was tools and processes. I thought it was a reasonable interpretation and also wrong.
- ionforce 9y agoMaybe people are ultimately imperfect and others are looking to process to smooth over those imperfections.
- jt2190 9y agoThe Agile Manifesto suffers from "the curse of knowledge": The signatories are all very experienced, and deeply understand all of the differences between projects and people and when to be flexible and when to be rigid, and they know that it's important to not specify a method for every situation. But there are many, many people entering the software industry who don't have their years of experience, and who need very clear, basic instructions as a starting point, and hence Scrum steps in to fill the gap. What's unfortunate is that scrum isn't a program for developing software managers from rigid, by-the-book managers into experienced, agile managers: Instead it encourages newbie practices for everyone, forever.
- qznc 9y agoNow I would suggest to deprecate "sprint". It is not healthy to sprint continuously. Sane software development is much more like a marathon.
- dudul 9y agoI don't know if this is meant to be facetious, but I actually fully agree. "Sprint" is a terrible analogy because in reality it is impossible to be sprinting all the time. I usually just say "iteration".
- neltnerb 9y agoI'm confused, doesn't your statement mean the analogy is good? You can neither "sprint" at work continuously nor constantly sprint in reality.
- dudul 9y agoLet's say you do 2 week sprints as part of your process. You do a sprint, finish it, and then do another sprint immediately after. How is that viable? Effectively it means that you never stop sprinting. I don't think it's sustainable.
- neltnerb 9y agoIs that actually what scrum suggests sprints are? Thanks, I missed that, that's silly if so. I assumed by the name that this was like a one week a month kind of thing.
- theptip 9y agoI think there's quite a lot of getting hung up on the word itself here... According to the Scrum guide, a sprint is just: > a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. (http://www.scrumguides.org/scrum-guide.html#events-sprint http://www.scrumguides.org/scrum-guide.html#events-sprint) There's nothing that says you need to "sprint" through your sprints, quite the contrary it's supposed to be a way of measuring your team's steady-state output by making the feedback loop short. If people are really hearing the word "sprint" and thinking "ah, Scum is telling me to work at 110% all the time without stopping", then I put forth that no methodology or change of terminology is going to save them from themselves. However, I suspect there's something about the timebox structure that makes short-term thinking the default unless discipline is applied, and discipline is hard.
- romanovcode 9y agoCan we deprecate scrum in 2018?
- bamboo_7 9y agoYes yes yes. It never made sense to me that our ticket sizing was supposed to be an estimate and yet the planning that used those estimates was considered a commitment. Totally insane.
- philbarr 9y agohttps://imgur.com/a/OnJKA https://imgur.com/a/OnJKA
- joejerryronnie 9y agoFantastic, I'm using this in my next presentation to management.
- rapala 9y agoI have always thought commitment in this context as "we commit this much time for this task, then we stop and reevaluate" instead of a deadline.
- gedy 9y agoWe had Ken Schwaber come in to our shop early on in Scrum when we were struggling to get a new product going, and at its basics Scrum made tons of sense. Get a small group of people together to figure out how to make the highest priority items to ship to the customer (each written in a few sentences), then leave that group alone until the sprint was done. The "commitment" was on delivering the value in the few sentences, not matching mockups, specs or some never-ending chain of tasks. It was a really simple and effective approach, but where it broke down was: there's a lot of people/roles/depts who have no idea how to work incrementally. UX "needs to work ahead", product "needs the whole backlog", Ops "have their own backlog", etc. Scrum didn't work with everyone hawking over a few engineers - then it just becomes task tracking bullshit.
- woliveirajr 9y agoTag [2011] is missing...
- sctb 9y agoThanks! Updated.
- brightball 9y agoThis is perfect.
- perseusprime11 9y agoIs Agile & Scrum still relevant? I am seeing more and more consultants who used to selling this stuff have moved upmarket into Lean and Digital Transformation of companies.
- EngineerBetter 9y agoI wrote an article on the negative psychological impact of commitments in sprints (https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-jones https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-j...). It's great to see renewed focus on shifting away from a term that has been used to make developers' working lives unpleasant, leads to lower-quality code, and gives false certainty to stakeholders.
- daanlo 9y agoI am a big fan of scrum precisely because of the word commitment (I hand't realized it was removed). Forecast means we need to use a larger estimate next time. Commitment means: "how can we still get this live". In a good culture the answer to this should rarely be work extra hours or reduce code quality - it should be reduce scope of functionality. Without the commitment you often get micro feature creep, where a bunch of non-essential micro features are added. A bit like this (https://lawsofux.com/parkinsons-law.html https://lawsofux.com/parkinsons-law.html). It is also the obvious moment in time to tell a product owner "we need to remove functionality x or not ship". Without the commitment that important conversation is never had. In my experience micro & macro feature creep is one of the biggest issues in sw development. Obviously you can still do the above with the word forecast, but forecast empowers you less to actually change anything (apart from better aka higher estimates next Sprint). On a general note: I feel scrum is often misused to "manage" engineering teams, when it is really a productivity tool that the team should use for itself.
- brightball 9y agoDepending on the size or the organization, that word commitment can create numerous issues. It can keep teams from collaborating because of a need to finish their commitments first, effectively blocking the other teams and delaying actual delivery of the product. You can see the same issues in customer support requests. The second that somebody decides to measure completed sprint commitments, you are in deeeeeep trouble because it forces people to low ball to hit that number. It removes your ability to pivot. The entire concept of sprint commitments in a moderately sized team is borderline destructive. This change is the best news about software development I’ve read in YEARS.
- je42 9y agoThis PDF is pretty nice. Regarding the differences of Kanban vs Scrum. https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf