Context
A couple of years ago, I attended a Scrum training that was so kindly sponsored by a previous employer. At that time, I have already been practicing Scrum (which I now know actually wasn’t) in some form or another for seven or so years. So, understandably, I was excited (despite my bias against classroom-type training) to finally learn the fundamentals I felt I was lacking. Unfortunately, instead of laying a foundation, the training ended up getting me even more confused. And this sense wasn’t exactly isolated. As a former colleague humorously put it, many felt they knew less about Scrum after the training than before.
Here are some claims the trainer made that I found questionable:
- The Scrum Master and Product Owner are not part of Scrum Team (he probably meant the Development Team)
- Sprint 0 is a good/useful practice
- QA is done outside the development team
- UX involvement is only needed at the end of the Sprint
Looking back, as bad as that training was, it turned out to be the best training I attended in a long time (if not, ever). Not because of the delivery and definitely not because of the content but because of what it awakened in me, a desire to go back to the basics, to take it upon myself to answer the question “What is Scrum?” and to practice Scrum as faithfully as its creators intended; not because I think they are infallible but because of a sincere desire to really learn, master and ultimately adapt it (nobody wants dogma or to be dogmatic – to follow blindly – but Shu-Ha-Ri: follow the rule, “break” the rule, be the rule). So, in a very real sense, it set me on my Scrum journey.
(And, who’s to say that that wasn’t in fact the intent of the trainer. Perhaps, he really is a Scrum Master!)
What follows are some of my notes in the beginning of that journey (which I wrote some days after the training); mostly taken from the Scrum Guide and some articles and videos I have encountered online (that I unfortunately failed to note down). Those in italics I have added more recently.
(I have since moved on from the Scrum Guide to Scrum Patterns and I feel I have barely scratched the surface in gaining that depth of understanding that true masters possess.)
Brief History of Scrum
- more than 20 years old; created around the 90s, has evolved since -- latest incarnation is defined by the Scrum Guide
- created by Ken Schwaber, Jeff Sutherland; Mike Beedle also a pioneer, all three are among the 17 original signatories of the Agile Manifesto
- actually predated the agile manifesto; but conceptually based on it (but more so -- both historically and conceptually -- on Lean or more accurately, the Toyota Production Systems)
Side Topic: Agile Manifesto
- around the time the manifesto was written, waterfall was still the dominant software development methodology
- but there was a growing movement away from it; there were already distinct agile "ways" e.g. XP, DSDM, Crystal, Scrum
- basically, these "new ways" of doing software development was a reaction to waterfall and its perceived shortcomings:
--> big upfront planning + big release at the end of a long (several months long, even years) development phase resulted in delays, cost overruns and outright failures
--> traditional project management's focus on standard/stringent/heavy-weight processes and treatment of people as interchangeable/replaceable "resources"
- founders/creators/thought leaders on these "new ways" gathered and realized that though they have differences, they agree on a lot of things and have come to strikingly similar conclusions on how to do software development better
- the result was the agile manifesto - a distillation to the essence of these "ways" -- a set of values and principles that elaborate the values; so in way, agile is a mindset
- in many ways, agile is the polar opposite of waterfall:
--> people are the most essential; each one is unique and brings a unique value to the table -- they're not replaceable (in the sense that say servers are)
Side Comment: Agile for me is all about tightening feedback loops and continuous learning and experimentation.
Back to Scrum: So What is Scrum?
A framework...
- it is a FRAMEWORK, not a methodology, not a technique
- analogy: building construction: foundation (agile manifesto values) + framework/structure (scrum) + exterior/interior design/details (methodology + practices + techniques)
- a methodology is more prescriptive with specific processes/practices/instructions; a framework can be built upon, filled in, though it also identifies boundaries/limits/restrictions such that when you go beyond them you are already outside of the framework
--> this will be made clearer later on
...for addressing problems and delivering solutions/value
- but a framework for what? a framework for addressing complex ADAPTIVE problems (such as developing software) and productively and creatively delivering the highest possible VALUE (i.e. value-optimizing)
- it is iterative and incremental; iterative pertains to the "process" and means repetition of activities (paulit-ulit), incremental pertains to the result and means building on top of past results (paunti-unti)
- what does iterative and incremental development enable? agility, flexibility, adaptation, changing course..why? (explain -- see pillars)
The Scrum Team
- the essence of Scrum is a small, stable and autonomous team of people -- the individual team is highly FLEXIBLE and ADAPTIVE
- they collaborate and interoperate
What is Development?
- when the words "develop" and "development" are used in the Scrum Guide, they refer to complex work and pertains to all activities needed to deliver a product increment (i.e. requirements analysis, design, coding, testing, docs, packaging, release, etc.)
Scrum Theory
- based on empiricism -- rooted in experience, encounter with reality, observation, experimentation
- pillars: Transparency, Inspection and Adaptation
--> inspect and adapt is a feedback loop, a cycle and is basically iterating the scientific method (there is a problem, you make observations, you come up with some hypothesis, you test it by experimenting i.e. trying out your hypothesis, you make conclusions, recommendations for future research/investigation, repeat)
--> inspect and adapt is only effective with transparency
--> every Scrum event is an opportunity to inspect and adapt
Side comment: I think these points are very important but are seldom emphasized in trainings. This is basically the Scrum thesis applied to software development: software development is a complex and adaptive process (as opposed to predictive; it is a blackbox/fundamentally uncertain because it is a creative process rather than well-defined/well-known; its first principles are unknown); to manage it and the risks that comes with it, we need an adaptive process, we need to constantly inspect and adapt, thus we need transparency, we need iterative and incremental development and not only that, we need the iterations to be short (to minimize risk); the product increment is basically an experiment and we learn, make conclusions, make adjustments, launch new experiments based on the stakeholders’, customers’ and market’s feedback).
- commitment, courage, focus, openness and respect
- for you to reflect on; very important since as always values are the foundation where awesome things are built-on
(This was me attempting to relate/map Scrum values to Company values.)
--> build for the long term (commitment, courage, focus)
--> wear the customer's shoes (commitment, focus)
--> our employees and their families matter (respect)
--> humble (respect, openness)
--> hungry (commitment, courage)
--> have a point of view (courage, openness)
- values + pillars build trust; as we know, trust is very important -- organizational health rests on it
Scrum Team
- Product Owner
--> maximizes the value of the work done by the development team by clarifying and prioritizing product backlog items by value to the customer
--> can delegate but is ultimately accountable for the product backlog
--> there is only one PO per product backlog; the ultimate authority on "what" (but not "how") to do
- Development Team
--> self-organizing, self-managing; decides on the "how", how to turn product backlog into RELEASABLE increments
--> releasable is "DONE"; Scrum Team defines "DONE"
--> cross-functional; has all the skills (requirements analysis, designing/architecting, coding, testing, documenting, etc.) to create a product increment
---> does that mean every team member must have all the skills? No, but broad competencies are desirable and acquiring those competencies/skills are encouraged since it promotes collaboration, mitigates risks among others (T-shaped developer)
--> no titles, sub-teams regardless of work being performed, regardless of domains
--> development team members can have specializations, areas of expertise/focus; gaining deep skills/mastery over a specific area is also desirable and is encouraged
--> members may work on specific tasks but accountability belongs to the team as a whole; every team member is accountable for ensuring that the sprint goal is achieved
Scrum Master
--> helps team understand and practice Scrum; to follow its rules, stay within the framework
--> serves development team by removing impediments
--> facilitates decision-making, coaches development team on self-organization and cross-functionality
--> helps find techniques to help team be more effective
===
"Final" Words
Some weeks after I gave a "talk" to the team based on these notes, we decided to go over the Scrum Guide as a team. We spent an hour a week (or was it every two weeks) over several weeks going over the Scrum Guide, reading and re-reading it, discussing and reflecting on passages in it. We were conscious of how similar the format we adopted was to that of a Bible study (and we laughed at ourselves for it -- but we took the process and the learnings seriously nonetheless). Indeed, during those sessions, we took the Scrum Guide as our (Scrum) Bible. We also spent time, individually, taking and re-taking Scrum.org's open assessment. It did not take long until we were consistently getting 100% (the set of questions in the open assessment is quite limited) so a teammate asked me, "What's the next step?". I did not have a ready answer for her at the time but I did come back with one a few sessions later: "Scrum Patterns".
(I hope to add more links to resources in the notes above at some future date.)
No comments:
Post a Comment