The Core elements of Scrum

Coequality, Coaching, Commitment

Very recently I posted a question on Twitter “give me one reason why you think Scrum fails in your workplace?” The answers I received varied from — “Scrum is actually working really well for us here” to “If people aren’t committed to it, it won’t work. You do need a good coach to adopt it well too.” The best answer however was “Scrum by itself can’t fail, only people can.” For a while now I have had it in my head that there are specific core elements that form the foundation of a really good Scrum team:

COEQUALITY

If you have read any of my previous blog posts you will know I like to quote from the Scrum Guide quite a bit, and I am very much a believer everyone in the team is ‘a developer’:

Scrum recognizes no titles for Development Team members other than Developer. . .
Individual Development Team members may have specialized skills and areas of focus. . .

The way I see it, what the first line reads is, let’s be a cross functional! I wish it was that simple! I find it interesting how this practice of cross functionality just doesn’t seem to stick and I wonder whether it’s because growing up we are all taught to learn and master an area of expertise, such as becoming a lawyer or a doctor or a computer, which makes it almost difficult to motivate ourselves to learn something new, once we have mastered the one thing we have taken the time and to learn. Most that work with me will know I keep going on about being more cross functional, so you may ask why do i see it as such an important part of working in a scrum team? Pure and simple, it allows the team to take the opportunity to learn, adapt and appreciate the all round person that is ‘A DEVELOPER’.

Let’s refer to our scrum board. Right now, are you in a similar team, where the team is built up of java developers, testers, web developers, pearl developers etc and all the tasks are separated into different coloured post its? Imagine if this wasn’t necessary. Imagine each individual in the team was focused on completing the story rather than the task, where programmers and testers had more or less equal knowledge and skill. How much faster do you think the cycle would be to completing stories, and signing them off as potentially shippable features? It would be a huge boost. Concentration would lie in picking up any task to work on, because the team would know how to, creating a holistic circle of coequality in the team where everyone is taking ownership of moving the story into DONE!

COACHING

It’s interesting how many times I have had this discussion, about whether the ScrumMaster is an important part of the Scrum Team. If you ask me, being a ScrumMaster isn’t about making sure the team attends the daily stand ups or whether the burn-down chart is up to date! In my opinion the team can do all that — self organisation right? It’s where the coaching aspect comes into play.

Have you ever heard of a concept called Shuhari (守破離)? Shuhari is a Japanese martial art concept, and describes the stages of learning to mastery, and translates to — “first learn, then detach, and finally transcend.”

Shu (守) (Obey) — Learn the fundamentals & maintain the heartbeat

ha (破) (Digress) — Break the tradition & innovate

ri (離) (Separate) — No techniques, all moves are natural

So how does this fit into our scrum framework and the role of the ScrumMaster? Your ScrumMaster is your coach, your guide, the person who trains and teaches you to understand and appreciate scrum from the basic principles through to proficiency, guiding you through the learning process, enabling you to become self sufficient, capable and disciplined to acquire the forms and movements. So coaching is vital. We wouldn’t understand the real working process or concept of scrum or even the ability to really inspect and adapt if it wasn’t for the ScrumMaster and Shuhari. Never underestimate the value the ScrumMaster brings to the team.

COMMITMENT

But really, it all comes down to whether we are committed. This word, I sometimes feel, is thrown about rather lightly. Are you really committed to completing your sprint? How does coaching, coequality, collaboration and other elements of agility work if you’re not committed to achieving your aim? Do you have an aim? When you look at your sprint board, can you see what you are committed to delivering? This in itself is also a motivational element; how can you really make your team committed? What’s the outcome of being committed?

Let’s think about it in another way, you’re in a committed relationship, what does this mean? You could define it as a pledge or a promise, to be with, love and care for another, regardless of flaws, problems or issues. You work with your partner through the bad times, to solve problems, but at the same time you enjoy and take pleasure in the good times as well. It’s your relationship to keep hold of, care for to bring about an outcome of happiness. On the other hand, what if the dynamic of the relationship is wrong? Naturally commitment would deteriorate.

Commitment means the same thing when we think about Scrum, in our sprints, we will have impediments, but we learn to solve them, we will have times where work will flow nicely and be completed without any issues, but at the end of the day we need to also ask ourselves, what does this mean to me or us (the team)? In the above example, your partner, would mean something to you if you’re in a committed relationship. So what does your sprint mean to you individually and as a team? Does your team take pride in the work they complete? Does the team feel they are working towards something for the greater good or even for their name to shine in lights for something they designed or developed?

So think about what the aim is, the achievements, which are valuable to the whole team, and naturally the commitment will progress and grow, because the team will start to feel that sense of ownership and accountability of their success towards a project, team achievement or company wide goal.