So Scrum, for those that don’t know:
Scrum is an iterative and incremental agile software development methodology for managing product development.
It’s an alternative model to the old waterfall style project development and traditional heavy methodologies like ITIL, PMP, Prince2 etc. It works extremely well for complex projects with changing requirements, hence the agile label.
It challenges the traditional sequential assumptions made in waterfall and constantly readjusts, leading to more accurate spec delivery, happier developers, happier stakeholders and so on. Scrum adopts an empirical approach, accepting the problem cannot be fully understood from the beginning and that there will be requirements churn (people changing their minds). So it focuses on maximising team productivity and the amount of value development can bring to the business.
To understand the terminology a little, here are the roles, artifacts and events involved in Scrum.
These are the 3 core roles in scrum, committed to the framework and delivery of work using Scrum methodology. Scrum itself does not define any further team roles than those below.
- Product Owner: Represents the stakeholders and is the voice of the customer (accountable for ensuring that the team delivers value to the business).
- Development Team: Responsible for delivering potentially shippable increments of product at the end of each sprint (the sprint goal).
- Scrum Master: Facilitates scrum, accountable for removing impediments to the ability of the team to deliver the product goals and deliverables.
Tangible artifacts, basically things created by humans as a part of the Scrum process.
- Product Backlog: Comprises an ordered list of requirements that a scrum team maintains for a product.
- Sprint Backlog: The list of work the development team must address during the next sprint.
- Product Increment: The sum of all the product backlog items completed during a sprint and all previous sprints.
There are the main events in Scrum, there are some other additional ones that are optional (Backlog refinment, scrum of scrums etc).
- Sprint: The basic unit of development in scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration (max 1 month)
- Sprint Planning: Select what work is to be done, prepare the Spring Backlog
- Daily Scrum: What did I do yesterday? What will I do today? Do I have any blockers/impediments?
- Sprint Review: Reviews the work that was completed and the planned work that was not completed (Review of the WORK done in the sprint)
- Sprint Retrospective: Reflects on the past sprint & Identifies and agrees continuous process improvement actions (Review of the Sprint itself and the PROCESS)
So at Mindvalley, we’ve been running Scrum for about 2 years or so, in various iterations (as per the Scrum philosophy, with the Sprint Retrospective you adapt and improve the process as well as the execution of work).
We started off with no real system at all, so from scratch. People were just approaching developers directly and asking for stuff, developers were kind of prioritising based on their limited perspective of the company and doing items according to that. So there was no real tracking or accountability, no one was in charge of any of the platforms and driving value creation.
Developers were frustrated, unhappy, stressed, overworked in some cases and under-worked in others (both which makes for unhappy devs) because they had to manage requirements churn themselves, incomplete specs, testing, UAT, deployment, bug fixing and so on.
Project managers were ill-equipped to deal with the situation too, when they were used they weren’t really project managers and just annoyed the developers constantly asking for updates on progress without really helping with the tactical decisions and execution.
So we slowly started adopting Scrum, pretty much organically until it became obvious it was working for us and we started pushing to implement it more strictly, create the proper artifacts, cadence of accountability and roles to facilitate the Scrum model.
From our experience:
- 1 week sprints are too short, it feels like robotic factory work churning small parts out so fast, with the planning + reviews if there are any holidays or sick people, barely anything gets done
- 3 week sprints were too long, it felt like you weren’t sure if you were on the right track still, it was hard to estimate the volume of work for 3 weeks, and stakeholders got antsy waiting so long to add stuff to the next sprint.
- You really need to empower the PO to value rank the Product Backlog and be the final decision maker, if not the whole process will break down.
- Scrum Masters main role is as a Scrum coach, their primary goal is to make themselves irrelevant and have the PO + Developers run the whole thing themselves.
- I love the fact no one really has to manage people any more (in terms of execution, of course there is still people stuff like performance, motivation, mentoring etc), the process manages the people, we manage the process.
- The more technical solutions + process smoothers you can put in place to remove frction the better (CI services, auto deployment, having a dedicated release manager, standardized git branching workflow)
- Scrum is definitely NOT suitable for non-technical teams/departments but everyone, in every role can definitely take parts of it and learn something from Scrum.
- Language alignment is VERY important, make sure everyone involves understands the same things from the same words/terms.
- Developers will naturally enjoy Scrum as it abstracts them from the noise/chaos of the business and allows them to focus on doing excellent work, and to own the results.
- QA/Testing/Acceptance can easily become a bottleneck when everything else is running like clockwork.
- You need the highest level stakeholders (CEO, VPs etc) to buy in so they understand when the Sprint has started they can’t just add items because they feel they are URGENT and they have highest political power.
- Definition of Done is IMPORTANT.
- And ultimately, if you do Scrum right – it will not be enough. You will need to do Scrum ++, for us at the moment we’re trying Scrum + 4DX.
All in all it’s going great now we have it all nailed down, we’ve had to adjust some things, like the joint retrospective was taking too long with 30+ people involved, so we’ve broken it down by team and just turn through summaries of each team (Assembled by the Scrum Master) together after every sprint. And for us, mostly our PO is also our SM – not recommended but it’s going ok for us.
- Stakeholders are happy because we do high quality work, regularly delivered production ready software, we have a set cadence of accountability – they know every 2 weeks we deliver the highest value items to the business.
- Developers are happy because they don’t get interrupted by irrelevant inequities, once they choose their stories in the Sprint Backlog they can concentrate on doing the best possible work without the worry of changing goal posts, they don’t have to collect specs from stakeholders themselves, they get to own the process and the work done.
- POs/SM/ex-PMs are happy because they don’t really have to manage people any more, they can focus on delivering maximum value to the business, coaching developers, maximising productivity and other more relevant tasks.
So yah overall thumbs up for Scrum for complex software development.
Scrum Master Training
So a couple of us decided to take the Scrum Master Certification in Malaysia as it’s available with good quality trainers, and you just take the exam online. Plus we’d been running Scrum for a while and felt fairly competent (we’d read a lot, talked to other people etc) and were following the methodology fairly strictly.
But we wanted to validate that, plus ask some hard questions about Scrum ++ which we were evolving into. Plus other stuff like how to keep developers motivated during multiple maintenance sprints (not really related to Scrum…but hey, why not ask).
From the official Scrum.org:
The Professional Scrum Master (PSM) course is a 2-day course that covers the principles and (empirical) process theory underpinning the mechanics, rules and roles of the Scrum framework. Advanced tools for servant-leadership are provided to increase a Scrum Master’s effectiveness. These tools relate to behavioural shifts, working with people and teams, coaching and facilitation techniques, and addressing the organization.
We found the training here from Iverson, it’s a 2 day course and in a way certifies you as both CSM (which only requires attendance) and PSM1 (which requires the exam).
Iversion – Training – Other Courses (Under Training and Education – Agile).
Honestly it was a lot less about the Scrum framework than I expected, but after thinking about it – that makes way more sense. You can learn how to execute Scrum fairly easily by reading the guide. What’s harder is fully understanding the concepts behind it, the mentality required to run Scrum effectively and the psychology of the people involved.
So a lot of it was about coaching, about dealing with different personality types, getting buy-in, dealing with conflicts and so on – obviously doing all those within the Scrum philosophy. The training was experiential, so exercises, discussions and thinking about a lot of tough questions.
We learned about things like the Schneider Culture Model for example.
Which really makes you drill down in your own mind about what is right and wrong in Scrum, what can disrupt Scrum, how to elevate your team to become more mature and effective and a lot of other deep questions.
It was very good, it validated how we use Scrum and our understanding of the Scrum philosophy was pretty strong and also raised some things we can do better (WIP limits, Definition of Done, levelling up Product Owners etc).
It definitely helped me understand more about the role of a Scrum Master as a servant leader, an enabler, facilitator and mentor.
As you can see from the recommended reading list for a Professional Scrum Master, it covers the areas cross-functional self-organizing teams together with coaching & facilitation.
Our excellent trainer was Joshua Partogi who you can find on Twitter here @jpartogi, he can also do Scrum consultancy for your company if you’re struggling with implementation or have more questions than the course can cater for. He knows his shit.
As a note, this is not an advertorial, endorsement or sponsored exchange, we paid full price for the course.
Scrum Master Certification in Malaysia
So after taking the course (quite a while after) I remembered I should take the exam haha. Even if you haven’t done the training, or just want to check your own level of knowledge on the Scrum framework – you can take the Scrum Open Assessment here:
Just before I wanted to take the exam…I took this…and failed it haha. Pass requirement is 85% and I got 82% – oops. But I took the real exam anyway.
I was kinda scared by the really vague open ended questions, very philosophy based. Those with tangible answers were easy, but at least 30% of the questions were really tough. The actual PSM 1 exam is 80 questions in 60 minutes – so not a whole lot of time to ponder, less than 1 minute for each question.
In the end I passed though, thankfully haha – I got 74 out of 80 or 92.5% with my weakest area being the vague question areas (Coaching & Facilitation).
So yah, I’m a certified Professional Scrum Master now haha (PSM 1).
Scrum is great, scrum is good – but don’t be a Scrum zealot. It’s not the answer to everything.
I’d say to get the most out of it, just get your team together, talk about the core concepts behind Scrum, the problems it solves then give everyone some time to read about it (perhaps 1 week), to read and digest the Scrum Guide and Google any questions they have.
Then come together and get started, plan how to implement, who is going to play which roles and when will your Sprint Planning meeting be.
I think going to the training should come after you’ve been running Scrum for a while and you have more relevant in depth questions, you’ll get much more out of it and honestly you should be able to get Scrum up and running with the guide.
Use the training to fine tune how you are doing it and use the exam to validate your knowledge and understanding of Scrum. All in all I think they are both worth it, now we are considering the next level Product Owner training haha (PSPO).
If you’re looking for Agile/Scrum support in Malaysia I suggest this Facebook group: Agile Malaysia
Wow, this quick post about doing the Scrum cert turned into a 2000+ word essay haha, hope it’s useful to someone!