Scrum is the art of, every day, asking the same three questions and expecting a different result.
Namely, for those just tuning in:
-- What did you do yesterday?
-- What will you do today?
-- What is blocking your progress?
These questions ensure the dev team know what everyone else is working on, and that slips in progress only last a day before they are reported.
So, if I say: I'll take items A and B today, then tomorrow if I say "I got done item A, but not B. The block is I need access to the database, and the DBAs aren't giving it to me" -- then the team already knows that we're a little behind on B, and the problem. Most likely, the scrum master than takes it as a to do to go fix it.
How well this works depends on how much the team trusts each other. And some other stuff, but trust is hugely important.
Subscribe to:
Post Comments (Atom)
Is there a consensus policy on how the team should deal with priority-shifts that happen within a day (e.g. "The database server is literally on fire, all hands put down other work to respond to that"), or do teams develop the policies that work best for them?
ReplyDeleteAnd what do you do when the Answer to C is "Attended this meeting to answer your three questions which impedes my progress by having to create a report of what was done yesterday and what I am failing to achieve today because I am sitting here for the next X hours while the development team talks about these answers"???
ReplyDeleteSorry my wife has had that problem on jobs MANY TIMES. Meetings are an impediment to progress when they break the flow of the day and the work.
I have several answers to this; and, in all these things, I recognize that I am only an egg. This represents my best understanding.
ReplyDeleteThere's a lot going on here; what you are describing is categorized in scrum as either a spur or an abnormal sprint termination. In the case of the first, if you have something important come up that delay some of the features you want out the door, that's ok; mark it as a spur, communicate with the client about changing expectations, etc. If this is now priority one, then deal with it.
If it's a really big change -- like maybe your company just got bought and the needs are shifting -- then you can say "the needs of this sprint no longer align with the needs of our clients, so we are scrapping it. Revert to where we were end of last sprint, cancel the product demo, and still have a retrospective."
Oh, and also, while there is the daily scrum ceremony, there is the underlying assumption that team members work together. They aren't siloing themselves into offices only to come out for the daily scrum, but are pair coding (when a good idea), talking through problems (often!), and generally working and adapting together.
In the particular case, I do wonder: How many months does it take 9 women to have a baby?
Which is to say, sometimes we think throwing more people at a problem will make it easier. But, there are for sure problems where you need a dedicated team working on it, right? And where throwing more man-months at the problem will not help.
I don't know if that is such a problem; I do know that I have no particular skills in solving literal fire. There are problems where the absolute best I can do is nothing, and where any intervention by me would just cause it to be worse, if nothing else as now someone has to babysit me.
So, those are some thoughts! I think the best is answer that scrum qua scrum gives two ways of dealing with it; a spur, or an abnormal sprint termination.
Joseph Teller I've been in those! they are, by definition, not scrum.
ReplyDeleteThe daily scrums are necessarily under 15 minutes; they should be done in ten. These are NOT reporting upwards, and they do NOT take prep work. This is for the TEAM to be on the same page; the product owner is welcome but not necessary, the client is NOT WELCOME.
In Scrum, you should have a task board. The items that need to get done are on the task board. Each morning, take the ones you expect to do and move them from TO DO to DOING. Then, take the ones you got done and move them from DOING to DONE. Talk while you do so. The ceremony of the three questions is to facilitate that conversation; think of it like a game.
If a daily scrum is taking more than 15 minutes, then the team needs help. like HALP because they are wasting their time, and need to revisit their team norms.
William Nichols: Cool, thank you! I appreciate the info. My understanding of scrum as a whole lags far behind yours, but my understanding of how scrum handles exception states lags even behind that.
ReplyDeletei can recommend a book, Tony Lower-Basch, if you wanna read it.
ReplyDeleteWilliam Nichols: We'll talk! But I don't want to side-track your whole post.
ReplyDeleteI want book recommendations
ReplyDeleteI enjoyed The Elements of Scrum:
ReplyDeleteamazon.com - Robot Check
.. which is short and to the point and broke me away from top-down thinking. The analogy I walked away with was:
trad games are to top-down management as ___ is to scrum. Where the __ is "freeform indie games!".
And, well, guess which one I prefer?
Question and side track away!