Five Values of Scrum

I’ve just come across my CSM notes and thought that it was about time I wrote them up so I could dispose of the paper copies. I couldn’t think of a better place to start than with the five values of Scrum.
I’ve broken this post down so each heading is a value, then the scrum alliance definition in italics, then my own thoughts on that particular value.


Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.

We all need focus in order to be able to concentrate on the work that we have at hand. People focus in different ways, but in my experience developers always imagine that to focus they need to work alone.

Rarely has anyone I’ve worked with talked about what I think is the most important part of this value, work well together. To spend an amount of time working closely with another is a rewarding experience, and I find it to be more so than working alone. The best work that I’ve produced has always been in collaboration with one or more other people. Often we’ve come away saying that we couldn’t have done that work alone, and that we’ve been completely dependent upon the other person’s effort.

I would love to see more companies showing and encouraging their employees to pair program. It ticks so many more boxes than just focus. It helps to build T-shaped people, ensures that more than one person knows how any piece of how the system works, and allows for two-way mentoring (the more senior person will impart knowledge, the less senior will impart passion).

I’ve also found that developers are far more productive when pair programming. When one’s working with someone else, they keep each other in check. If one’s mind wonders it will soon be brought back by something one’s partner says. One can’t just go off to check facebook as there is a colleague whose time will be wasted. Now this isn’t to say that the pair can’t wonder off together, but because there are two, one will lose interest and pull the other back on track.


Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.

In all, I think this is probably the last value to achieve. To undertake greater challenges the whole team has to be pulling in the same direction. To have greater resources at a team’s disposal, the team must have the respect of the business so that they are willing to invest in them.

I think that on every development team I’ve ever been on there have been people who are repeatedly coming up with ideas to improve the product in one way or another. When businesses give time and resource to their engineers to experiment, their engineers will reciprocate by delivering value in mostly unexpected ways. If only the business management dictate the direction of the product then that product is limited by the imagination of the business managers. This isn’t to say that the less technical side of the business can’t come up with ideas that add value, but that everyone is limited by their technical knowledge. Engineers are more likely to know about the latest thing their technology can do, so managers should be encouraging them to implement these things in order to gain a competitive advantage in the marketplace.


As we work together, we express how we’re doing, what’s in our way, and our concerns so they can be addressed.

If an individual thinks that saying they need support in an area will result in that support, then they will speak up quickly and ask for help. However, if they think that saying they need support  will result in a bad review and / or no bonus, then they won’t say anything.

This requires positive management practices. The only way that an individual can be open is if they feel confident that it won’t be used against them in the future. More than one manager has used my requests for support in a review to show how I’m not performing well.

People learn at different speeds and in different ways. Managers who recognise this and tailor their approach to each of the individuals they manage will find that not only do their subordinates progress well, but they will also be fiercely loyal.

When someone asks for help treat it as an opportunity to reduce business risk, and not as an example of that person’s ignorance.


Because we have great control over our own destiny, we are more committed to success.

When a team can choose how to engineer a solution, they will choose to the best of their ability. (This is why sending your technologists on as many conferences and courses as possible is so important.) Most engineers are passionate about the work that they do, and make efforts to keep up to date with the latest thought leaders in the industry. As a result of this the team will have some of the best information about how users interact with software, how data is transmitted between servers and clients, how data is best stored and retrieved, and everything else in between.

Most managers of technical teams are no longer technical. Due to their change in status they are likely to find themselves spending their time learning about managing, worrying about their teams, budgeting, keeping the next level of management happy, and probably also having a lot more fun thanks to their increased income! These are the people who should be supporting the engineers by defending their decisions, funding them, and doing whatever else is required to facilitate value delivery.

When people feel that they have a say over their work and the direction the team takes they will be more committed. This will naturally encourage them to work harder, deliver faster, and stay with the company longer.

Ensuring your team is committed reduces the risk to your business that knowledge will walk out the door.


As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

When I was working for a manager who regularly showed that he respected me and the efforts I made, I felt free to push any boundary that I wanted to push, and therefore pushed more boundaries in the time I worked for him than the rest of my career put together.

The best example I have is the time I asked to have something as an objective, and then asked for it to be removed. I asked my manager if I could have an objective that required me to implement a new technology into the company, and he agreed. After doing some further research and understanding it better I decided that it wasn’t the direction the company should be going at the time. At our next 1:1 I asked him to remove it from my objectives. He gave me a mild grilling, making sure that I had an understanding of the technology and that I could justify removing my objective. Within a couple of minutes he agreed that I could have it removed.

I knew that  this manager  respected me, and I knew that he wouldn’t think less of me for changing my mind. When review time came he had forgotten that we agreed to remove the objective, and so I had to remind him during my review. I didn’t mind this, as I had no fear that he was going to punish me.

Working for someone who doesn’t appreciate that their subordinates have failed fast, or worse still uses that as ammunition against them at review time, will result in that employee fear trying to improve. If one is scared of failure then one doesn’t try. If the only way to avoid negative outcomes is to avoid risk, then risk is very quickly avoided. Show your subordinates / employees how much you respect them by celebrating their efforts, regardless of what the outcome is. Allow any lessons that need to be learnt from the experience to be learnt by creating a positive environment, praise the person for putting in the effort, and move on without regret.

Originally Posted at

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.