Even better, PMO managers who tout their Black Belt Sigma 6 credentials and insist you follow their project documentation templates, but couldn’t manage to organize a pisser at a bar. Love those guys.
Scrum doesn’t dictate sprint length. Not all teams in my office do 2 week sprints. But weekly standups aren’t really standups, so I agree with Telemark – that’s a core component of scrum. It’s called a standup because it’s just supposed to be everyone literally standing up at their cubes and getting on the same page for the day. It’s in lieu of status meetings. If you’re doing your standups monthly that’s just a status meeting by a different name, and it’s not core scrum.
Which is fine – if I recall my scrum training correctly, there’s nothing to suggest that it’s dogma. It’s all about using what works for the team and jettisoning what doesn’t, and if jettisoning one of those core scrum components works for the team then scrum has no problem with that – it just stops being scrum.
That’s what I’m getting at; the point is to remain agile, not to be dogmatic about a particular way to go about it, which IMO, is where a lot of companies and the people involved lose their way.
If daily standups were really 5-15 minute informal gatherings among peer co-workers, then that would be one thing, but I’ve NEVER seen any that have actually worked like that. They’re always… oppressed(?) by the presence of various managers, and end up being a daily status report instead of a mechanism for coordination. Something’s gone way awry if your participants are thinking more about what they’re going to say that’s not going to make them look bad when they go around the room vs. talking about actual project coordination stuff.
There’s nothing that says sprints need to be 2 weeks long. It works well from experience, but we’ve done 4 and 6 week sprints in our organization. Various Scrum organizations have suggestions, but 2 week sprints aren’t an integral part of Scrum.
Daily meetings however are a formal part of Scrum. If done properly, it’s not a time sink and it performs a quick, vital, function. Again, rapid identification and resolution of impediments and dependencies is part of Scrum.
I don’t think people are doing that here, at least I’m not. Scrum is the form of Agile we’ve chosen, but there are others and they all have value. But if you’re going to call yourself Scrum people are going to assume that you’re actually following the official Scrum guidelines. If you are doing a different form of Agile, don’t call yourself Scrum.
If that’s how the daily standups go that doesn’t seem like scrum’s fault, or even dogma’s fault, since anyone dogmatic about scrum would insist on a casual 5-15 minute meeting without managers present. What you’re describing sounds like not enough dogma!
We’re nominally using it on my project.
Heck, I was a certified scrummaster a few years ago when the company made a big push to get people ready to go… then they decided they wouldn’t pay for the renewal process every 2 years (100 bucks a pop). Now they’re pushing it again. :rolleyes:
It’s a good concept, but while we claim we’re more Agile… it’s still 3 months between production builds. Not terribly agile at all.
Managers don’t belong in daily standups; they’re generally not part of the scrum team. The daily is by and for the scrum team; it’s an internal meeting. If the organization isn’t committed to empowering the teams then whatever they are doing isn’t Agile, let alone Scrum. I agree, that would be frustrating and counter-productive.
Exactly. Basically what they did was co-opt the parts of it that were the easiest to implement and show that we were “agile”, without actually getting real buy-in from the company as a whole.
So we started having formal standups with managers and doing work in sprints, but we didn’t do the actual important stuff like getting the business stakeholders to show up to the standups, didn’t do anything approaching iteration and prototyping, and were still held to various timelines and performance metrics that were unrelated to anything agile at all.
So it ended up being the case where everything basically worked the same as it always had, but with the extra burden and/or annoyance of having to try and carve it up into two week chunks, and having to report your progress every single morning.
It was awful.
This is the most common Agile/Scrum implementation that I have seen. Managers just want to copy someone else’s homework instead of figuring out what’s right for their work context.
That’s commonly called ScrumBut, as in “We do Scrum, but we don’t do X, Y, and Z.” Translated, we don’t do Scrum.
PMO (Project Management Office) and Six Sigma are two different things. A PMO is typically an organization that sets project standards across the company. Six Sigma is a data-driven approach and methodology for eliminating defects in a process (originally manufacturing, but ultimately any repeatable process).
So here’s the problem:
A company wants to implement a project - by definition, a temporary, discrete, largely bespoke solution to a particular problem. Design and implement a software package, reorg the company, open a new store, whatever.
The company has a limited budget (as all companies do), but they only kinda know what they want to accomplish with the project. They might even have no actual idea how to actually do it.
So because you have all these unknowns, you need to put in place a process for designing, executing, validating, and providing oversight for these project. Depending on how often your company runs projects, they might only kind of know how to do that (or not at all).
So basically you end up with all these imperfect methodologies for consolidating a group of strangers together to build something AND make sure they are doing it correctly AND also making sure what they are building is actually something that is going to solve your problem.
Of course, hiring project managers and scrum lords (or whatever they are called) and Agilvangelists also costs money that could have been spent on people doing actual work. Except without those people providing oversight, the workers might not be working on the right stuff (costing even more money).
I disagreed with you. By and large, I’m not regarded as an “idiot”. See, how much I just helped you!
You haven’t met Steve. I’ll introduce you.
My suggested approach:
Pick a best fit SaaS solution with a recommended implementation partner. They will take care of the related project management methodologies and bring in a team that is already familiar with the routine. You engage as the key stakeholder and do your parts, which should largely be defined for you as well. You’ll still have to have some idea of how to provide oversight, but the actual project implementation methodology won’t require high core competency and day to day oversight from your (client) side.
Most people do Scrum/Agile wrong because the right way is really hard. Scrum isn’t just about taking a 8 week feature and chopping it up into 4 2 week blocks, that’s just pointless busywork. It’s about rethinking your entire development process to prioritize learning over productivity. I find this image an effective way of illustrating the concept (although it’s not perfect).
The goal for each sprint is to generate an artifact that can help inform your areas of biggest uncertainty to inform your next sprint. Crucially, that artifact doesn’t need to have any relation to the content of the final project you’re delivering. If you’re building a car, building a wheel contributes to the progress of the final deliverable whereas building a skateboard, nothing in the skateboard will remain in the final car but agile says you should build the skateboard because the skateboard contributes towards the learnings of the final car.
Scrum/Agile done right should result in you throwing away a lot more work but also delivering value faster which is why it’s so hard to practice because doing it feels deeply counterintuitive to people. It feels wasteful because you’re constantly working on things that you know will have to be thrown away rather than working on cranking the wheel on the core deliverable.
This is why having a good scrum master is key to the success of scrum which is difficult because scrum masters who actually understand scrum are painfully hard to find. The two week sprint is a good rule of thumb forcing function but it shouldn’t be followed religiously. Most of the time, it’s possible to take a 8 week feature and figure out how to figure out the minimal set that fits inside a 2 week sprint but not always. For example, one thing I see commonly is if you’ve validated that having a recommendation engine that delivers performance above a certain threshold would result in significant business value but you’re not sure if it’s technically feasible to achieve that level of performance, then sometimes what you need to do is just accept that it’s going to take a team 8 weeks to figure out how to do that. You need a good scrum master to recognize when this is the case and be willing to break the rules in service of the product.
But ultimately, when I hear people say they have problems with scrum, I almost always believe they’re correct because the proportion of places that actually do scrum as a form of pointless busywork is very large.
The organisation I work for is Scrum-ish in some areas, Agile-ish in others. My immediate team, most of us have Scrum training (two certified Scrum Masters, one Product Owner). We do daily standups because we’re on a bunch of fast-moving projects and we can be re-tasked with little notice, so it helps to stay in touch.
My larger team pretends they’re Agile because they have a regular catch-up meeting which the leader insists on calling an Agile review, but they’re not Agile in the slightest.
Another area is Agile but doesn’t know it. I set them up (in consultation with them) with a daily standup and a retro/review on a weekly cycle - they don’t have traditional software iterations or product to ship, exactly, and a weekly cycle works better for them. Their main beef was being scattered across five locations and wasting a lot of time on trying to track down who was doing what, so a short daily works really well for them. Half or more of their workload comes in on the day, or over a day or two, it’s all very short cycle; they do backlog-grooming style management on the few longer-cycle projects they’re working on. I never told them it was Agile, because it’s Agile that’s been bonsaied into a shape unique to them - if they knew it was Agile, some of them would roll their eyes (having been evangelised at with other systems that promise the world) and the rest would argue process definitions for weeks on end, so it was easier to just not tell them 
The software-focused parts of the business are solidly Agile, and I envy them. Was part of a major project with one of them, and it was one of the smoothest-running shows I’ve ever been in. A good project manager/Scrum Master/ringmaster/whatever you wanna call them makes a huge difference.
Underline mine. I think that’s one of the key details that some people don’t get. Like any management philosophy (or any other kind of algorithm, for that matter), Agile is valid under certain conditions but not others. There’s things that can be improved by doing successive improving runs, others where it makes sense to sit down and plan; your succesive runs will be worth jackshit unless they do include some planning, your plans are worth exactly the same if you’re incapable of updating them when they encounter that immovable object known as “Production operator” (other versions: “Warehouse operator”, “Maintenance guy”, “Salesperson whose addressbook puts a phone book to shame”, “Lab tech”…).
Whenever I get a PM who wants us to “run a little end-to-end prototype” on the first day at the client, and even if there happens to be a system that’s already got data from other places, I know I’m dealing with someone who has no idea what he’s talking about; “a little end-to-end prototype” takes three days if you sew everybody’s lips together and run through the “everything comes out roses” with data that for once is actually good.
This is a good point. So much of this depends on context. A business that can deploy 10 patches a day, and can afford to lose a thousand customers if they get it wrong, can and should do iterative development. The cost of failure and retry is trivial.
If you’re designing a lunar mission, though, the astronauts would really prefer not to be part of a possibly successful iteration. The cost of failure and retry is literally astronomical.
If this is followed religiously, though, it means that Scrum is completely useless for most applications. We write financial software, and a half-right tax calculation is literally worse than not doing it at all. In actual reality you have your minimum viable product, and then you have escalations on the concept - often adding features rather than a complete redesign. But the minimum viable product has to actually be viable. And if it takes three months to get something viable, you can’t fit that into any sprint that could be called a sprint. You can break it into parts and work on it that way, but they’re parts, not successive generations.
This is why I say that Scrum is clearly designed by (and for) a three man team doing web development out of a garage. The fingerprints are all over it - the notion that things are released to the customer weekly, the notion that everybody on the team can or should do every task equally well, the idea of getting something (anything!) out quickly to establish a customer base that you can give a proper product to later. Which is all great if you actually are a three man team working out of a garage, but everybody else has to, what was the term? Scrumbut. They have to throw out the parts that clearly won’t work for them and which would be insane to attempt.
There’s a lot of good concepts in Scrum, but as specified it’s one-size-fits-one. If you’re not that one size you have to let out the seams a little.