Scrum
Lightweight Management Process
Scrum is a lightweight management process. It was adapted for software development from...
For further actions, you may consider blocking this person and/or reporting abuse
Care to outline why you think Scrum is not agile? I think I know what you mean but I am not completely sure. And to some point I'd oppose this by saying: Scrum is not project management. I go mostly with the Schwaber/Sutherland approach here claiming that Scrum essentially "is a framework for developing and sustaining complex products". A framework. Not a process. Not a very complex rule-book'ish process to follow through but rather a set of approaches to help getting teams to work "agile" yet in some way planned and structured. This way, it is as "agile" as you want it to be: The Agile Manifesto has a bunch of ideas (starting with "Individuals and interactions over processes and tools") worth respecting, and they aren't "incompatible" with Scrum if you do things right... ;)
The things the make agile actually agile are the agile engineering practices.
Scrum is a lightweight management process. The framework it outlines is a process. A management process. Suitable for products, but also suitable for marketing, or sales, or call centers, or IT, or DevOps.
Andrew Fuqua did a good job enumerating the agile engineering practices, Engineering Practices.
I'm agree with you :)
If I may, the artifacts are backlog, sprint backlog and increment. Increment is not sprint burn down chart. As I know, scrum guide never mention any chart :)
I added increment to the artifacts. The Scrum Guide does mention the burn down chart, but in passing and not in depth.
I grant you that it isn't listed in the artifacts, by The Scrum Guide. But it is a secondary artifact, as are things like velocity (if used by the team), and a roster of team members who participated in a given sprint, and vacations, and if there were disruptions (power outages, hurricanes, IT upgrades that brought development to a halt, patch Tuesday), or anything else that is a product or byproduct of the development effort.
I wasn't emphasizing the roles, events, and artifacts in my post. I figured those are all mulled over sufficiently in The Scrum Guide. :-)
I was in no way trying to say Scrum and agile are incompatible. I think they are very complimentary. Which is why I said that they can be very complimentary.
But a team can be agile without Scrum (nor any other lightweight management process). And a team could use traditional waterfall (actual waterfall in practice, not strawman waterfall lampooned by Winston W. Royce albeit not called that by name), yet still be agile.
Or a team can embrace Scrum as its lightweight management process, without being agile whatsoever.
The two are orthogonal to one another. But I think, like peanut butter and chocolate, they go well together.
Ok, thanks for clarifying, we're mostly in the same boat then. Yes, the team doesn't need Scrum to be agile, and you very easily can make Scrum a very "heavy", strict management process lacking any agility. What I just wanted to point out is: If you know you want either to become more agile while locked in a very static, strict organizational environment, or if you are extremely agile and need to get more structure into your planning, Scrum provides a framework to allow for agile teams and work while still providing an minimum set of rules for people to play stumbling across each others feet - and by possibly becoming "better" technically.
I know a bunch of teams (including ours, before "adopting Scrum") who suffered not from being in too strict management processes but rather, essentially, from being way too agile in terms of being too much focussed on satisfying internal and external stakeholders as fast as possible - and sacrificing quality, stability, maintainability for the sake of releasing features fast. In this environment, quality, testing, documentation, ... often was deemed unneeded and time spent on things not providing value, and in such environment team members didn't manage to get better in this, on their own, because focussing on more quality immediately would slow down development. This, also, isn't what agility should end up like. ;)
Agility doesn't come from Scrum. Scrum provides an empirical framework of short cycles and frequent course corrections, and a lightweight management process that can respond to change, and embrace change.
Agility comes from the team embracing the values and principles of the Manifesto for Agile Software Development, and adopting agile engineering practices. (Doesn't have to be just the team. Could be the entire department. Or the entire division. Or the entire company.)
Developing features fast while sacrificing quality, stability and maintainability is a surefire recipe to be not agile. As you saw in those bunch of teams that suffered. :-(
For all the reasons Robert Martin pointed out in his book Clean Code.
To be agile requires the team to internalize agile engineering practices, as enumerated by Andrew Fuqua. Not all of them have to be adopted, but a good scrum master should be encouraging the development team to consider suitable ones to incorporate as a development team technical decision.
Even without agile, Scrum still provides a lot of value.
And agile, without Scrum, provides a lot of value.
Genuine Scrum and genuine agile together are a win-win.
But there are a lot of pitfalls that need to be avoided with Scrum. Which is why I say "Scrum is simple, but it ain't easy".
By far the biggest pitfall I've seen is management telling the team do Scrum, without management understanding that Scrum means management's own role and responsibility has to change to make Scrum work. Management needs to pony up a full-time scrum master as a facilitator and manager of the process; a servant-leader. Management needs to empower the team to be able to make technical decisions (which is a hard change for a command-and-control organization to successfully make that transition).
Yes. I don't disagree here.
The only thing I wanted to point out: Scrum provides sort of a framework that is required for getting good work done in an agile environment in a larger style.
Scrum itself doesn't make a team agile.
But at some point, there's always a need to get things balanced. In most cases there's a load of different stakeholders with conflicting goals and requirements. In most cases, too, there are business requirements concerning available development budgets, release cycles and the like. In most cases there will be a whole load of non-functional requirements and expectations. Too, in most cases there will be "planned" development vs. fixing "bugs" (ranging from actual show stoppers that bring your system down to that one button one special user wants to be green instead of blue).
I dare to say in most "real-world" organizations (larger teams, more than one stakeholder, ...), no matter how well a team embraces agile principles, you still will need some sort of process to resolve these issues - to figure out, in example, how to work with budget limitations or release deadlines in a sane way, or how to resolve conflicting goals by getting your things prioritized.
This is not "just" about agility, it's mostly also about getting a certain structure into things as agility, on the other side, also won't work if the whole team randomly starts talking to random stakeholders to get an idea of what to do next, or if stakeholders randomly provide some team members with whichever feature request they see as important that moment.
Scrum, with its roles and processes, provides a framework to answer those questions. And that's what I initially meant: If you have a team that commits to and embraces agile principles and values, Scrum helps you getting this into your whole environment in a meaningful way without wanting "agile" and ending up in chaos.
Then we're on the same page. :-)
I think Scrum has a lot of value. (With or without agile.)
I think agile has a lot of value. (With or without Scrum.)
I think Scrum + agile together is a big win-win for both.
I think there are some dangerous pitfalls to Scrum that people ought to be aware of, so they can avoid those pitfalls. Because those pitfalls can give Scrum a bad name, and I don't think that's fair to Scrum.
Nice post Eljay.
I also share the same opinion.
The scrum is not difficult. Scrum is easy to understand.
But, the implementation is complicated. It requires involvement of each member of a particular team.
Recently I posted an article about the most common errors in the daily scrum.
Take a look.
tfsolucoes-tecnologicas.com/14-com...
I hope you like it.
Thank you Ted. :-) I enjoyed your article on the common errors in the daily Scrum meeting.
I find that the daily Scrum stand-up meeting is invaluable if the team is working on a feature together. Trying -- as a team -- to get the feature completed, as in "done-done, stick a fork in it... ship it!"
That kind of daily Scrum stand-up meeting works to keep the team focused on getting to the finish line. And is invaluable because the team is working to coordinate where some area needs more attention, and what's has made progress such that previously blocked tasks can be tackled.
On the flipside, I find that the daily Scrum stand-up meeting is nigh worthless if the "team" is not working on a feature together. They're not a team, they are basically a bunch of separate teams (which each team having exactly 1 team member), coming together to give a status report to the Scrum Master. The sniff-test to see that it's not useful to the attendees is because no one much cares what the other attendees progress is... because everyone is working on separate and independent features. How would such a team end up being split up to work on separate features?
One possibility is that the Scrum Master did not champion the team being self-organizing, and other forces pigeoned hole each team member into separate feature work. Another possibility is that the "corporate antibodies" eliminated the Scrum Master position, so there is no Scrum process champion and defender... which had the same outcome. Let alone if the team members are working on separate products, in which case team cohesion has been completely compromised. I've seen all scenarios happen at different companies.
The daily Scrum stand-up meeting ought to be by the team, for the team, because the team is working together on a feature. One feature at a time. (Assuming team-sized sprint-sized feature work, rather than a featurette that is so small it can be done by one person in a few hours.)
Addendum, after 5 years. One of my colleagues at a former company strongly advocated Scrum as a way to make the team hyperproductive.
I've been pondering what it means to make a team hyperproductive. I believe the critical difference between a hyperproductive team and a normal productive team is Clean Code. Nothing to do with Scrum, per se. Teams that embrace Clean Code will become hyperproductive teams.
And it is not that hyperproductive teams are staffed with mythical 10x unicorn developers.
Rather a hyperproductive team is merely a team that is not bogged down with unclean code. The development friction from developer facing technical debt, deferred necessary maintenance, and unclean code (code that lacks isolation, has highly intertwined coupling, has low cohesion, has spooky action at a distance, and has non-obvious emergent properties) slows down the team. Death by a thousand paper cuts.
My insight with hyperproductivity was from Robert Martin's Clean Code book. His productivity graph shows how a team's productivity sinks like a rock with unclean code. Creating the "scary gap" between greenfield era hyperproductivity and current unclean code era productivity.
Scrum does not impose any agile engineering practices upon the development team. The team is at liberty to choose their own agile engineering practices. I suggest Clean Code is a good one to start with. As had commented 5 years ago, and is worth repeating: Andrew Faqua has a nice list of other engineering practices necessary for Scrum to consider.
Very nicely summarized. Thank you.
I have an experience of working in a company that claimed to do Scrum, but in fact every single thing that you list as the reasons for Scrum not to work was followed exactly (I mean as in the list, not as in Scrum). So everyone said: "we tried Scrum, and it doesn't work, let's try something else". With the same results, obviously. :)
Oh my, I'm sorry you experienced all those pitfalls first-hand. :-(
My ulterior motive behind my post is twofold: I want to point out the pitfalls so people can avoid them, and I would really like the Scrum proponents to take on the responsibility to figure out how to mitigate these pitfalls.
I get the sense from the Scrum luminaries that they don't seem to realize that these are serious issues, and can leave people with a bad experience Scrum. (Even if the Scrum luminaries would dismiss the complaint as "You're doing Scrum wrong", which isn't so helpful.)
You probably noticed that I did not provide remedies to the pitfalls I mentioned. I don't have any silver bullets for those problems.
I hope that just being aware of the pitfalls will help someone.
Are you working as a Scrum Master? And have you ever had talked to the person on the “same” Scrum Master position and had a feeling that this position has slightly different requirements than yours? I know that the Scrum Master position might differs depending on the company requirements and a used frameworks.
Are you willing to help me and share your experience? Please spend a few minutes by filling in this short survey - Scrum Master experience (goo.gl/forms/qF5xmF9qMcVvwCxG3)
The "How many teams do you have as the Scrum Master" survey question is a bit unclear. Does that mean concurrently, or teams over time?