When you first hear about Scrum, you will hear about certain meetings, roles and of course, the idea of Sprint. You will also be led to Agile Manifesto, which is the fundamental for Scrum. This is important knowledge which touches the technical and organisational side of Scrum.
But you also need to know about five core Scrum values that should be followed by everybody involved with Scrum team (project, product, etc.), not just the roles that methodology itself describes.
To strictly use and follow these rules is not easy, but Scrum is not for everyone and, from my experience, not everybody fits well to requirements of Scrum. Those values and their relation to Scrum can be described with this picture:
I want to start with this one, because it may involve people outside of the Scrum Team and it can be used even before Scrum comes into place. Why? In some environments, you need to convince upper management (or clients, or even your colleagues) that doing Scrum is worth the risk. This requires guts to go and talk to people, sometimes even breaking the „chain of command”. You need to be sure about your arguments when presenting Scrum to decisive people and not afraid that many times your proposal will be refused.
The company (or clients) also need to show courage when it decides to trust the Scrum process (and hence, the developers) to guide the work needed to satisfy the requirements of product.
Another place when you need to show your courage is at the Planning meeting. This is the place where Development Team need to say “no” to the Product Owner (and to the clients in the process) when it feels the PO proposal is overcommitment, but sometimes (very rare from my experience), team will add some work to the original proposal, confident about their skills and stamina to deliver all of the features.
You can also say that raising impedements on the daily basis is form of showing courage. You already heard that Scrum is designed for professionals. “Why should then I raise something that stops my work? If I say that I can’t do something, I will be seen as unprofessional. I might be received as a liability by the rest of the team, maybe I shouldn’t say it out loud on the team meeting?” I think otherwise. The faster your problem is removed by the team, the more value team can add to the current sprint. And what if your blocker turns out to be a critical bug in client’s production environment and will harm your product image? This is what the daily meeting is for anyway.
From the Scrum roles perspective, Scrum Master is probably the one who should show this value the most. It is necessary when you need to guide the team on the meetings (especially to fit within the timebox of some), but also to defend the team from the “wolves” attacking it (sales team providing promises of new functionalities to the clients without contacting team first, clients constantly changing their minds and raising new features as bugs in the software).
Product Owner also needs to show courage in trusting that team actually chose maximum possible amount of work for the sprint. On the other hand, he needs to tell clients that the functionality will not be delivered this time, but during the next increment (this could be heated discussion :) ).
Member of the development team needs to show courage in proposing improvements to the product. You are the one developing it, so you could have more technical knowledge that Product Owner himself. Do you know the tools and technology that can be used to improve the product and give it competitive edge over the rivals? Let’s add it to the Product Backlog! You will also propose improvements to the process itself (SM is not a perfect person, and your product environment is probably not perfect too) on the Retrospective meeting.
In summary, courage is needed almost on the daily basis to give the scrum possibility to work at full power.
Today, the developers are not individuals sitting in their tight rooms, doing some “magic” so that after 6 months, you will receive your long awaited computer program.
Now we sit in open spaces, collaborating tightly together with other members of the team and clients to drive the software in the best possible direction. Open space is one of the ways how this value could be implemented, although I’m not a fan of large open spaces (huge room for 60 people is not the best solution). A single scrum team should be placed in one open-space like room to encourage communication and reduce other ways of exchanching knowledge.
One example that even moves this further is that your Scrum Board is openly presented on your room wall so everybody can see it (or a public account on the online tool you are using is given to all interested people). You can also add your Product Backlog, Definition of Done, Retrospective notes to he public list to show that you have nothing to hide.
This value also means that you should listen to people and their ideas. Even if you are working in the project for very long and seem to know everything, there can be this new guy that comes in and provides something fresh. If you are a Product Owner, listen to your developers’ ideas, because they could be worth more in the long run than couple requirements from the clients. And Scrum Master should be open to critical view of other people and change when people around see that something is wrong.
In conclusion, openness is the way of showing that the rules of software development are changed and that work on software is more transparent to everybody.
If you chose Scrum in the first place, you commited to the new way of working. You also commited to listen to the voice of your Product Owner (one knows what is the best for the project and is responsible to maximize project’s ROI) and your Scrum Master (one knows Scrum the best and has the duty to defend you and the process).
You show commitment by doing your work the best you can to maximize the amount of work done during the Sprint.
Entire team commits on the Planning Meeting that this fraction of the Product backlog will be done in this Sprint (if you don’t have such confidence, don’t say yes).
You also commit that you will be present on your team’s meetings, most importantly, the Daily Scrum.
Product Owner shows commitment to the order of importance in Product Backlog items. There is a reason why it’s this way not the other and it is PO’s job to decide what is the best for the product.
Scrum Master shows commitment in guiding the team through the difficult rules of Scrum. He should stand in for the team and defend it from the ones who want to divert them from the Scrum path. He should be present to solve any and all team’s problems and help them in putting all the effort into the daily work.
In shortest, commitment is the best way to achieve success in Scrum project.
This value is closely related to commitment, because without team focus on the Scrum Goal, the initial commitment to the Sprint Backlog could not be achieved. The team needs to be sure that it is focused on the work present for the next increment, so it is completely devoted to achieving it.
You also need to remember that all the work that should be realeased in the Sprint should adhere to your Definition of Done, fulfilling also other quality, performance and style standards. That needs your focus to remember about all of these when the Sprint end is approaching quickly.
Scrum Master is the one that makes sure that team does only things from the Sprint Backlog and is not interrupted with other things (or even worse, other work) that relate to the project.
Imagine that you are working on one of the User Stories from the backlog, but you are constalntly dragged away from this by: important analysis of future enhancements, top priority bug that appeared yesterday and it was already promised to be solved today, company wide mandatory meeting, etc. This way your US can last ages and you won’t finish it this Sprint for sure. That is the responsibility of everybody to raise such things as impediments for Scrum Master to remove.
During Scrum training we had an excersise that showed how much overhead is generated by switching between tasks. We had 3 columns in which we needed to write numbers from 1 to 10, Roman numbers from I to X and letters from A to J. First run, we tried to write one number, then one Roman number, then one letter. Second run, we wrote all numbers first, then all Romans, then all letters. Even with this simple task, the second run was over two times faster than the first one. This is the power of focusing on one task and finishing it in a whole.
So, if you are a Scrum Master and hear that one of your team members is constantly asked to do something “very important” outside of the Sprint scope, make sure that this doesn’t happen.
Focus is essential for the completion of your work as you previously agreed it will be done. If you forget about it, you will pay the price in the long run.
This is the last one, but it should be a part when using every other value.
Every time you are defending Scrum ways of work, you need to do it in a civilized way.
Even between your colleagues in the team, you need to treat everybody as equal as you can and remember that you are a Team and ultimatealy you should cheer your success together and embrace your failures together without blaming any single person.
This is especially visible on the Retrospective meeting, when you are listing the things to be improved (or stopped). On such events, no single person name should be raised. You are responsible for the work, the atmosphere and success as a whole. When somebody really doesn’t align with the effort or is even harmful to the team, I would address this personally and try to fix the situation this way.
When you are facing customers with the news that their functionality won’t be ready this Sprint, you need to do it in respectful way. Don’t shout, don’t threat, calmly explain your point of view, otherwise you might lose your customer and hence your product (or project) might be gone.
Respect also means that you should take Product Owner’s decisions about which items are the most important for the product. You should trust his knowledge and vision as he is the one behind taking care about project success.
Product Owner should also respect decision of the team when they say no more work can be done for the current sprint. They should know better when they are overwhelmed with work and that this pressure is too much for them to handle.
Looking from a different point of view, respect might also mean that you participate in every Scrum meeting and are not late for any of them (especially the daily one which is the shortest). You should also participate in such a meeting fully, without distracting the team and driving your attention away from the topic (such as using cellphones, browsing internet, etc.). Every such event has its reason and is essential for success of Scrum implementation and for your Team performance as a whole.
Respect is crucial so you are seen as a team that everybody wants to work with and everybody wants to work in. It also helps to reduce unnecessary tension between team members and in the relations with outside world.
While Scrum training gives us lots of information about roles, processes, meetings and artifacts, Scrum values give us more insight about human aspect of team and project.
They also give us rough description about ideal psychological and personality profile of Scrum team member.
It’s difficult to follow those values. It’s even harder task to introduce them into your team, but it’s worth the work.
The more team understand how it needs to behave to make work smooth, the more it will work as a single fit organism.
So Scrum values should be raised and reminded often and used in a daily work to make everyone’s life in Scrum easier.