Releasing every sprint isn’t part of scrum. The idea behind each sprint is to have a potentially releasable product. Each work item taken on during the sprint should meet the definition of done, and therefore each sprint should result in something that’s potentially releasable, but there’s nothing in the scrum rules that say you can’t release every 4 sprints or so if that makes the most sense for your customers. Ultimately releases are a business decision made outside of the team.
It all sounds like busy work to me.
I’m not sure you read the blogpost you linked to - because it is an argument against that image because the image is, to put it softly, deeply problematic.
I’d suggest taking a closer look at the words below the picture.
Given that in scrum the business owners are the team’s customers, then yes you are supposed to give them a release every sprint. What they decide to do with it is, of course, their business.
But honesly, my point was that it’s pretty clear what sort of business model Scrum was designed by/for; the frequent release schedule is just one piece of evidence towards that conclusion. Companies which do not match that business model will only hurt themselves trying to follow it - for example any software team of any size will want to eschew the “everybody does everything” model in favor of having dedicated specialists for the various tasks, to make better use of people who are very good at some things but not as good at others.
Honestly it’s not, at least not all of it. The really obvious benefit from scrum/agile is the concept of breaking things into manageably-sized tasks and using a backlog to prioritize the handling of those tasks, with somebody in charge to keep a close eye on both how the tasks are progressing and whether changing circumstances have changed the priority or even the necessity of some of those tasks. Even if you take only that one part of it, it is leaps and bounds better for the development and maintenance of a system than the waterfall model, which was the de-facto model in use prior to Scrum and its peers entering the scene.
The various meetings all have turned out to be fairly useful - and the less useful they are, the shorter they tend to be, to the point of barely being an inconvenience. That depends on you keeping unnecessary managers out of them though. (The presentations to you stockholders excepted, obviously.)
If implemented poorly it is.
If implemented correctly it’s part of an efficient engine for producing results.
Pretty much like any software methodology.
While some environments may have been very waterfall-ish, in my experience in erp/distribution/wms software dev and implementation over the years (since 1983), I’ve never been part of a real/pure waterfall project. Every project plan has been based on the nature of the problem at hand.
This is typical flow of projects I’ve been on:
1 - Map out major phases - e.g. go live with ABC, next 6 months work on next group of priorities, next 6 months work on the next group etc. (note: most of the projects I’ve worked on in my career have had a large minimum viable product - you can’t install a partial solution into a distribution center and expect the business to just stop processing the other 80% of their business).
2 - Within phase of work, break down the work into natural chunks based on a variety of variables
Examples:
System X must get upgraded in production before it can be included in the overall solution (for various technical or business constraints) - so spin off a group to handle that upgrade/implementation
Systems A, B and C will require changes but are dependent on the final solution from system Z- so that integration work waits until the solution surrounding system Z is designed
3 - Within the chunks of work:
break the work down into smaller chunks - typically functional areas and sub-functional areas within an overall flow
Identify which areas have known solutions and which areas do not - approach them appropriately
Map out a plan for working in parallel or overlapping sequential (design+dev+configure+procedures+test) as much as possible given resource and expertise constraints
I’ve never been part of a project where we didn’t look at the problem and adapt the approach accordingly. Maybe I’ve just been lucky with the environments I’ve worked in.
Maybe. I ended up getting jumped from waterfall straight to Scrum. It was a dramatic difference, let me tell you - which is probably why I’m talking so happily about it despite simultaneously pointing out that the second you adopt it you’re probably going to throw half of it in the garbage bin.
I think the most important aspect is that trust between developers and management is a prerequisite for agile to work, not an automatic result of trying to use an agile process. If everyone is covering their own ass, it doesn’t matter what your process is, and something like scrum just turn into counterproductive bean counting.
I have worked for dysfunctional companies that didn’t really have any process, and just forcing people to meet every day or at least multiple times a week would have helped. I worked at a company with 15 people and we would waste months trying to solve the wrong problems. All the software engineers sat in the same room but all the communication was talking about the immediate problem you were dealing with with the person you knew had first-hand knowledge of it. Just forcing people to talk about what they were doing in front of everybody probably would have prevented some egregious examples where we had to reconsider underlying assumptions, or realize we were actually battling hardware and didn’t need to.
I grouse, but I’m in agreement with both of you on many of the advantages you’ve outlined. I’m just often irritated by the evangelical approach some take to SDLC and refuse to be flexible or course correct where it’s clearly the wrong tool for the job/problem. Also, I hate meetings where people who are not solving the problem are invariably the ones doing all the fucking talking. But that’s not the fault of agile. It just tends to create more opportunities for the time wasters. Who, in my experience, is often the client. And just you go ahead and try to tell Steve not to attend or to keep his mouth shut.
I’ve seen it said that culture eats process for breakfast. And I absolutely agree that in a culture where time-wasting morons hold power, all process improvements do is turn them into more effective time-wasting morons.
Second this.
I have worked on waterfall projects that delivered a complete product that was immediately shelved for being obsolete / not what the customer wanted. Or that had the release date pushed back over and over again (with all the devs on recurring “crunch time”). The way that features had been scheduled, meant that if anything took longer than expected to implement then the whole project would slip, because the plan included implementing critical functionality right up to the end.
I joined this thread to be devil’s advocate and list some bad points about Agile.
But big picture: I never want to use any methodology that doesn’t have frequent releases and appropriate feedback / course correction again. It makes a huge difference.
We are agile at my current job, for 2 years. 2 week sprints, and it works well. It worked especially well recently with one customer on a new product this year where we were able to respond quickly with tweaks and fixes.
Frequent releases and course corrections can work very well.
<agile rant>
At my prior company we had a ‘waterfall model with phases of concurrent develop-build-test cycles’ for many years, and then the Scaled Agile Framework (SAFe, https://www.scaledagileframework.com/) was deployed and tried for 3 years (still ongoing now, 6 years later), at a time when other significant changes were made — in personnel and management, and also office moves that included changes in location and eliminating cubicles for open work areas. The company also brought in certified SAFe consultants, some of whom are still there and have converted to permanent executive-level employees. The personnel and management changes, several of which seemed unduly punitive to the ‘old breed’, along with new management shooting down and taunting new ideas and some honest feedback in sprint retrospectives, resulted in a caustic and untrusting environment. That caustic environment propagated throughout the large, geographically distributed SW engineering groups (about 22 agile teams across 4 offices, most in 2 offices in different US time zones and 1 in Europe and 1 in Asia) plus many who permanently worked from their homes mostly in US and some international), and resulted in significant distrust.
What started as a large, mostly passionate and caring and dedicated and experienced workforce resulted in several key departures, some key early retirements, the rest of us no longer caring and just punching the timeclock in and out and watching the clock for 5 o’clock to arrive. Many of us had been there for 10-15+ years, myself included, and had nice benefits due to our seniority. Yes some corrections needed to be made. Product quality had dropped, and monolithic releases resulted in a constipated development organization. They drubbed the caring and passion out of us, and the punishments and ridicule on those who spoke out in honesty and perhaps some misplaced passion taught all of us to keep our heads down and shut up.
It was an amazing set of significant changes, all started at the same time when they really did not need to be. Truly baffling. The powers-that-be revealed incredible stupidity.
I am glad I’m no longer there. It’s been 4 years since I left and that company is still trying to turn it around.
</agile rant>
As a result of that experience, most of us scoff at agile, and SAFe/Scaled Agile Framework in particular. We feel poisoned by it. Myself included. Fucked by it, truth be told.
Bumping the thread a bit:
I’m taking the PSM-1 professional scrum master test in a few days. I am, however, someone with no tech/IT/project-leading experience. I’m doing the PSM-1 just because it’s cheap, I’m currently jobless and have time, and figured it can’t hurt. Does having scrum-master certification generally only benefit people who are already in the industry and have lots of experience with running software (or some other management) projects to begin with?
I can’t speak for industry-wide since I am in a niche industry (I do hardware and software design for industrial control), but the company I work for has no use for a full-time professional scrum master, except for when we first converted to scrum/agile/mumble mumble/something or other. We brought in certified experts to tell us how this stuff was all supposed to work, then we trained our managers and project leaders on how to do it. Then we started running sprints and having daily standups, and the experts told us what we were doing right and what we were doing wrong, and in some cases we figured out how to fit the round pegs into square holes (scrum and agile are great for quick app development, but some aspects of it don’t work well for complex software and especially for safety critical systems). Once we got it all ironed out, we no longer had any need for outside experts on just scrum/agile. We ended the contract with the scrum/agile experts, and now it’s only our own people that run all of the sprints and standups.
When hiring new folks, we look for scrum/agile types of experience, but we are mainly looking for people who are already familiar with that type of development so that we need to do less training to get them up to speed. We don’t hire people specifically to lead daily standups and run sprints. Most of the people who are in those positions now were hired as developers or industrial application engineers (folks with chemical engineering backgrounds, generally), who have years of experience and have worked their way up into supervisory positions. If you were, say, a Windows developer with a scrum certification, that would put you ahead of an equally qualified Windows developer with no scrum experience, but that’s it. It wouldn’t get you hired as a scrum master in our company.
But like I said, I am in kind of an oddball industry. When we hire new folks, we expect it to take them at least six months before they can really be productive. The system we make is just too complex. Heck, just the “beginner” course on how our system works takes two weeks, and that doesn’t even get into a lot of the features of the system. Anyone running a sprint would need to have years of experience with all of the complexities of our system, so bringing a newbie in to run a sprint isn’t going to happen.
I worked at a company that did scrum / agile throughout the company. First I was in software development, where the concept seemed appropriate and mostly worked. Then I was in tech writing where frankly it made no sense, and we were basically just faking it.
Re: scrum master, at one point we all had to take scrum master training (although we were not going to be scrum masters) and it’s basically a super-easy brain-dead thing that anyone can do. Maybe it’s changed since then, I don’t know.
At one point the company encouraged people to transfer to scrum master positions. They paid higher than development and were idiot jobs leading standups and filling out spreadsheets. A bunch of developers decided to become scrum masters. Personally I think it was a poor decision on their part but that’s just my opinion.
eta: I see you’re jobless, in which case, go for it!
Some time after I last posted in this thread, I actually joined the leadership team for a “strategic Agile” practice at a management consulting firm. It’s a little vague what that actually entails, but it’s basically a combination of running Agile projects and setting up large corporations to run Agile.
It’s actually harder than you think because most companies still have this mentality of trying to predict how much work a bespoke project will require over a fixed (and often arbitrary) time period. So you still get a lot of gathering requirements up front, dividing them up into “user stories” and then working 2 weeks at a time. And because they think like that, they still try to mitigate risk by gathering more and more requirements up front instead of building working code in smaller increments.