4 ms·
To think of scrum as a process is wrong. It's actually an organizational pattern language. The idea is that social interactions are a complex system and there a
by mempko 7y ago
To think of scrum as a process is wrong. It's actually an organizational pattern language. The idea is that social interactions are a complex system and there are patterns of interactions which, from experience, seem to work in certain contexts.
http://www.scrumabok.org/ http://www.scrumabok.org/
It's not even software specific. Which is actually a strength.
Example, one common misconception is the daily standup is a status meeting. In fact you are supposed to replan in standup, it's a tiny planner. Not sure how you can call the ability to pivot every day not agile.
EDIT: Unpopular option, software quality is poor and it has nothing to do with scrum.
- patothon 7y agoNo. Agile is a subset of TPS (toyota production system)/Lean applied to software.
- geofft 7y agoI'm already able to pivot every day—it's part of the autonomy inherent to me being hired as a professional. I can make decisions about my work, and ask my colleagues to make decisions about our group work, as necessary to deliver on business needs. Making a process and a specific time about how to get approval to pivot is less agile.
- mempko 7y agoYou ability to pivot as an individual is already limited based on your team. In fact a unilateral pivot is destructive and can inflict pain on everyone else. I'm not sure how having implicit and ad-hoc patterns of interactions is agile. Why? because you can't improve what you can't see.
- geofft 7y agoI guess part of my skill as a professional is knowing how to work with my team, communicate as needed, understand whay they need to deliver business results and get them to understand what I need to deliver business results, prioritize as needed, and make sure I'm not inflicting pain on everyone else. If you don't have that level of trust in your team members, sure, formal process makes sense. And I'm all for it if that's what's needed to deliver business results successfully. But you're then valuing processes and tools over individuals and interactions, following a plan of when and how you may respond to change over letting individuals figure it out, etc. Again, it's perfectly okay if it's not agile if it's what the business needs. But my assertion is it's not agile.