I’m not a software developer. I don’t do QA. When something goes wrong with WordPress – I get in touch with a developer at Agileana to fix it (thank you, Luis).
So, I was a little reticent about taking a Certified ScrumMaster (CSM) class. As a non-developer, I didn’t know how much it would actually help me in my day-to-day work.
But even for me, unassuming content writer, taking a class on Scrum was illuminating.
In fact, it was reiterated several times in the class that, even though the Agile Manifesto mentions “software development,” if you replace that “software development” with any other word, it can be relevant to most people’s work.
Scrum is an agile framework and is purposely left open ended.
More specifically, Scrum is “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions to complex problems.”
Not a reference to software in sight.
So, for this post, forget user stories and use a broad definition of potentially shippable product or increment. It’s been done before, but here are some reflections on my CSM class:
Scrum and Priorities
There is never enough time to do everything in a project. This is why agile is useful. Constraints change, the needs of the product owner change, the world changes during the project.
Scrum is a way to build a complete product that satisfies the most important needs of stakeholders or the product owner are taken care of.
By valuing working products and responding to change, Scrum is a useful method for completing products that meet stakeholder needs and are still relevant.
But it is how Scrum does this that I found most useful.
Scrum and People
What stuck out to me the most was Scrum as a more collaborative approach. One that centered on human experiences and relationships to develop a product.
There is an obvious nod to this in Scrum theory. Scrum is established on empiricism or, “that knowledge comes from experience and making decisions based on what is observed.”
But, you can see these ideas baked in throughout the Scrum Guide. For example:
“The Scrum Team is committed to achieving its goal but also supporting each other.”
Relationships within the Scrum team are critical to the success of a sprint. This concept really resonated with me.
We broke up into Scrum Teams to work collaboratively on a project at the end of class. It became clear how critical supporting other members of the group was. And how trust, even with a group strangers, was paramount to the development process.
Scrum and Accountability
There’s a bold statement in the Scrum Guide: “scrum is simple.”
In theory this is true. If one can hold themselves accountable for commitment, focus, openness, respect, and courage – sure, Scrum is simple.
Once roles are defined and your responsibilities are clear, it can be easy to work and feel motivated in a supportive environment.
Though, I would argue, that Scrum could also be difficult on an individual level. Scrum relies on the individual to hold up their end of the bargain. To not hide problems when they arise. To take ownership over their own work. To commit to goals—albeit self created goals.
It’s something that can be difficult to do, especially if you’re not used to working in an environment like this.
Scrum is Open Ended
Scrum is not prescriptive. It won’t tell you how to do any one thing in particular. Though, it does give a lot of guidance on how to organize and work with the people on your team.
So now, I go on to incorporate Scrum into my work – to start thinking of projects in smaller increments, with sprints, reviews and retrospectives. To look towards transparency, inspection, and adaption.
And who know what this change will bring. The teacher of the class continually reiterated something along the lines of ‘scrum doesn’t solve problems, it exposes weaknesses.’
