Ah, yes. Leadership by fear & stupidity. I think Simon Sinec did a best practice leadership seminar about that.
Did anyone ever sneak in bits and pieces of Moby Dick text into the comments?
I can’t ‘this’ this enough. Most implementations of this fall into ‘metrics theater’ for management reporting to other management the illusion that they have a takt-time control of their output. The task-level workers often get zero value from any daily tracking unless it is “I’m done now boss, what’s next?”.
Scrum is just a form of Kanban where someone else has already made all the process decisions for you. That’s the reason it tends not to work, your business has already made a bunch of conflicting decisions that it won’t (or simply can’t) change. People work around it by trying to modify Scrum, but you’re already living in a state of sin by starting from some stranger’s pre-made decisions.
Kanban would take over like gangbusters if businesses really were willing to have frank conversations about what they’re doing and be open to change, but many people have vested interests in fighting transparency and holding onto the status quo. i.e. If my weekly status meeting gives me a sense of control, prestige, and security, then I’m going to fight any method that takes it away from me.
Well, I get to hear about what everyone’s working on; it helps keep me appraised of what the other people in the section are doing and whether there are any dragging projects which I might get yanked into with little warning. (Well, warning other than the standups.) Plus if somebody’s been working on something forever, or if they’re not working on that thing I thought they were doing for me, I can find out before the problem becomes my problem. Sometimes people offer to help one another with a task that somebody says they’re having a problem with, too.
It’s also common for the entire affair to be over with in two minutes, presuming nothing too interesting comes up. Go around the circle, one sentence each, done.
ETA: Also, management doesn’t listen to our meetings; they’re for the group’s benefit, not management’s, after all. The product owner attends but doesn’t say anything unless she has some sort of announcement. Is this not normal?
What you describe is exactly how we do it, and as much as I hate the idea of daily standups, they are pretty useful.
I agree that standups are potentially useful. Some people don’t talk every day unless they’re prodded. Sometimes people get stuck and don’t say anything, sometimes someone has a key bit of info that it turns out nobody else heard.
In principle they are useful, but if nobody is enforcing discipline, it turns into a circlejerk of “yes I am definitely contributing and important” or “here is a funny thing I found” or “we should go into every detail of everything.”
Been doing scrum style agile at work for a little over a year. From the sound of it, our department isn’t doing too bad … although my team sucks at breaking items down into two week chunks.
We also use a web site to track stories, and attempt to task out the stories with anticipated number of hours it should take. So if someone wants to know what we are working on, and how far we are on it, they should be able to look at the web site and say “Oh Zyada’s working on this task that’s a part of this story, and she’s halfway through”
Stand up is “I did this yesterday/I’m going to work on this today/I need help from co-worker/I can help anyone who needs it” Although half the time it devolves into a discussion about a particular problem… we’re not supposed to do that in standup, but it happens all the time.
It’s totally normal. But in my opinion, not generally useful. I don’t know if this is common in your experience, but in mine, sometimes it turns into a bitching session about the project, and while some find that reassuring, I don’t think it’s useful. Sometimes someone offers help that is completely unhelpful because there is an assumption it’s not already been considered, and you have to be nice and explain that you did so without making the helper feel stupid. Sometimes, you want to take a deep dive into a problem and it’s the wrong forum for that so you run the risk of wasting people’s time. And mostly, I just don’t care what everybody is doing today. I’ve listened to them drone on about their module for weeks now and I’m just not interested. Sorry. I’m just not. And frankly their voice is starting to put my nerves on edge a bit.
I realize much of this may be down to my attitude about meetings. 
We’ve gone through Agile and Lean workshops. I did like getting to work in other departments to see how the rest of my workplace ticks, and it was nice to get rid of obsolete and time-wasting procedures.
Otherwise, our company had a reorg a few months ago, and the guy who led those workshops got phased out. I don’t think the upper mgmt saw much long-term value in those programs.
Daily standups shouldn’t be status meetings, they are intended to identify and target impediments or dependencies. It’s easier and quicker to do so in person, and as mentioned elsewhere are over in 10-15 minutes. They often reflect what happened yesterday and makes sure everyone is on the same page.
Yeah, maybe our team’s too small, or maybe we’re just too shy, but nobody seems all that inclined to bitch and moan beyond a couple of sentences. Long discussions of any type are generally saved for later.
It may help that in one of our sprint reviews we decided to invent a new meeting specifically for hashing stuff out, which we do once a week. People go into that one prepared to debate, and we have the head of Support come in to explain the customer perspective. That one can run for an hour or more, but it seems to completely relieve the urge to do design while we’re all* on our feet.
- All except me - bad knees + whining = exception!
You all physically get into the same room? That’s barbaric!
Most of my project team works remotely. I’m the only idiot that drags his dumb ass on site with the customer. Even our customer management works remote and skypes in 98% of the time.
The problem is a one-size-fits-all approach.
On some projects or some phases of a project, or with some groups of a project a daily standup might make sense, and in others weekly and in others monthly.
We are on the tail end of a large-ish project ($15m, >100 people, 6 vendors systems) and we used at different times daily, weekly and monthly collaboration, each one tailored to the nature of the problem/set of tasks and resources being worked on.
Again, good proj mgmt and system dev/implementation mgmt requires experience, analyzing the problem and choosing a solution that fits, and frequently that means different styles on the same project.
Not a single person telecommutes here, unless you count the programmers who are devoted/obsessed enough to log in after hours for no clear reason*. We are indeed an odd little shop.
- We’re such an odd little shop that we aren’t asked to work more than 40 hours a week! Even the programmers! Those that log in after hours do it entirely for their own entertainment.
Our project is roughly the same size, perhaps a little bigger, and 90% of the 15 or so teams have daily scrum meetings. With two week sprints it’s pretty important to have the daily scrum, and it’s just part of everyone’s morning, like getting coffee. There are other meetings (weekly, sprint, cycle) but the daily really sets up the work day at little cost to the participants.
Scrum isn’t the only way, to be sure, but I have found that it is appropriate for many projects and can be implemented across a wide (we’re in multiple offices and timezones) large (100+ staff) group and over long term releases. The biggest win for us has been the ability to go from 1 major release every 18 months to 2-3 releases in that time. The releases get value to the customer quicker, and they are focused on the changing marketplace rather than set in stone well in advance. It can work. Other methodologies can work as well. All will fail if implemented poorly.
But not everything benefits from a strictly-structured method like having everything bucketed in 2 weeks.
At the start of our project we had a high level solution design phase that lasted about 3 months where a small team of critical experts walked through the entire flow start to finish and identified gaps and listed possible high level solutions.
The team is in the same room 40 hours per week, it’s by far the most efficient way to get through the work, no need for scrum or daily standup.
As the project progressed and the work branched out into more groups the nature of managing it shifted and some were managed by daily and weekly.
But why would you want to impose a standardized 2 week structure on top of work that is ideally managed by varying levels of time buckets and collaboration?
Because probably 95% of people who implement and champion Agile/Scrum don’t really get what it’s about. They see the 2 week sprints and daily standups as some sort of sympathetic magic that makes everything work, when in fact, they’re just suggestions- what makes it all work is the close collaboration, the intimate involvement of the stakeholders, developers, analysts AND project management sorts, and an iterative, rapid prototyping type model that works with all of the above.
It doesn’t matter whether you’re doing daily standups, weekly standups or monthly standups- that should be determined by the time scale and intensity of the project, as should the length of the sprints. I wouldn’t be surprised if there’s some kind of optimal ratio between the standup interval and sprint length, but the actual intervals and lengths should ideally emerge from the project cadence, not the other way around.
Or that’s how I understand it from reading a shitload on Agile/Scrum trying to figure out if the problems I was seeing were inherent to Agile/Scrum, or just my former company’s incompetent implementation.
And his friend who thinks that “as much documentation as necessary” means “We don’t document anything. We’re Agile!!!”
The place I was working 10? 15? years ago supposedly went agile (well, they gave half the team some training and then started doing standups when they had time). I’ve worked with agile-ish variations since. Including the 90 minute daily standup, the earlier mentioned “we don’t document anything,” the team where the sprint ended when the pm (no scrummaster) decided that it would end - regardless of whether any stories were started or done or how much time had passed (I think the longest sprint was 10 weeks and the shortest was under a week. he’d just kind of decide that morning or wander into a room and say “we’re starting a new sprint”), and the team where 3 of the teammembers vocally didn’t like agile and were actively trying to make it fail.
To be fair - I have seen some agile projects work, but I’ve never seen agile scale well.
I do like laughing at agile/scrum bloggers who spout off tips that show they have very limited job experience.
Actually, that’s not really true. If you doing Scrum you need a few essentials:
[ul]
[li]Sprint Planning[/li][li]Daily Scrum[/li][li]Sprint Review[/li][li]Sprint Retrospective[/li][/ul]
If you’re not doing that, you’re not doing Scrum. You may be doing Agile, but not Scrum which is one way to implement Agile. They’re not synonymous.
Sure, but that’s half the problem. You’re letting the Scrum nonsense get in the way of the Agile stuff if you’re going to stick dogmatically to the **daily **scrum part of it.
I mean, what if your sprint is a month long? Is there really any need to formally have a daily meeting, if twice a week is a more sensible and productive way to do it? What’s the rationale there- just because some guy at Scrum.org says so?
I don’t know about you, but there are times when I get a lot done in a day and things really change, and others where there are long stretches of “Still working on X.” is about all the input I might have.
It seems to me that Scrum is one of many ways to do Agile, and people who get hung up on Scrum to the exclusion of Agile are missing the point entirely.