Scrum's pillars and values underpin its framework. Embracing Scrum's core values is more important than perfectly adopting any of the practices. In this article, we'll explore the pillars and values in a little more detail and share some examples of the core values in practice.
Core pillars and values
Scrum has three pillars: transparency, inspection, and adaptation.
- Transparency. Our requirements, progress, and issues are all out in the open.
- Inspection. We frequently inspect what we've built and how we built it.
- Adaptation. We frequently adapt what we're about to build and how we'll build it.
Scrum also embraces the core values of commitment, courage, focus, openness, and respect.
- Commitment. The CRM team commits to achieving the customer's goals.
- Courage. We have the courage to solve tough problems.
- Focus. We focus on the work of the CRM project.
- Openness. Our communication is open and honest.
- Respect. The team members respect one another's professionalism and ability.
Transparency should be a defining characteristic of all Scrum CRM projects. In the spirit of transparency, we should be providing information about our project so it can be observed by any stakeholder. This can include:
- Publishing our story map and release plan for everyone to review
- Providing all stakeholders with access to review our product backlog
- Pinning our sprint boards and burndown charts to a wall where everyone can see them
- Inviting all stakeholders to our sprint review meetings
- Letting everyone know about the current state, recent progress (and setbacks) and future plans for the project in our internal communications
I like to use a wiki in my CRM projects, usually Atlassian Confluence, where we publish our story maps, release plans, backlogs, retrospective notes, and sometimes videos from the latest sprint reviews. The project's burndown charts are also published on the wiki so that any stakeholder can visit the wiki site at any time and see where we're at.
Maintaining the wiki is a team effort. Sometimes, if we're lucky, there's someone from a project management office who helps provide guidance so that project wikis are consistent and best practices are shared across other projects.
Inspection and Adaptation
Inspection and adaptation are part of empirical process control and the scientific method. By adopting these pillars we are acknowledging that it's impossible to know all our requirements at the outset of the project. We admit that we cannot design the perfect solution before we start to build it.
Empirical process control is the opposite of defined process control. With defined process control we always get the same output given the same set of inputs. There's very little variance.
Given all the variables in a CRM project, we can't rely on the same set of outputs given the same set of inputs. We need to do some work, inspect the outputs and be prepared to adapt our next unit of work. We need frequent feedback.
Scrum's events provide lots of opportunity for inspection and adaptation. Each event inspects a smaller scale piece of work. They are release planning, sprint planning and reviews, retrospectives, story previews and daily standups.
If your team finds itself skipping sprint review or retrospective meetings then you're not giving yourself the opportunity to properly inspect and adapt the CRM system or your way of working.
Scrum projects require a commitment on several levels:
- Commitment from each team member to the project's goals.
- Commitment from each team member to each other to work together as a team.
- Commitment from the team as a whole to work together to achieve the goals of each sprint.
When I've worked with high-performing agile CRM teams, commitment has expressed itself through several examples:
- A team member taking on a task that doesn't play to their usual skills in order to meet the team's commitments for the sprint.
- Team members organising their schedule and any other project work so that they can always attend the Scrum events.
- A team with spare capacity completing an extra story in the sprint that amplifies the achievement of the sprint goal.
Scrum projects aim to improve our customers' experiences through digital transformation. We do this not because it is easy but because it is hard (to paraphrase a fellow Irishman). The most impactful projects are not the easy ones with reasonable goals but the challenging projects with ambitious goals.
A challenging project doesn't mean it has an unrealistic timeframe or half the resources it needs. That's not ambitious. That's reckless.
A challenging project has lofty goals that will revolutionise organisational performance even if we're not sure how to achieve those goals at the start of the project.
Courageous CRM teams set ambitious project and sprint goals. They work on risky features early in the project. They aren't afraid to experiment with new techniques and ideas. They aren't afraid of feedback from CRM users or real customers. In short, they are not afraid to fail. But when they do they fail fast.
The hardest agile CRM projects I've worked on are those where I'm also working on something else. You'll always perform your best work given the opportunity to focus on one project. Distracted by a second project, or support work for another team, and you'll lose focus.
There are several advantages to being able to focus on one CRM project at a time. You're always available just at the moment when your skills are needed so the team isn't stuck waiting for your focus to return. There's also an intellectual focus you can achieve when you only have one project to concentrate on and don't have to mentally switch your brain into another context.
As far as you can, focus on one agile CRM project at a time.
Hand in hand with the team's transparency to its stakeholders is each team member's openness to the team. If you're stuck on a task, behind on a story or struggling with a problem then let your team know. At the very least bring it up in the next daily scrum but you don't have to wait until then.
On my best Scrum CRM projects, I worked alongside talented team members that were always willing to share and declare any blockers. Even when it revealed a deficiency in our own skills. We knew the other team members had our backs and we'd learn something new as we figured out the answer together.
The spirit of openness is really only possible when you also have respect for your fellow team members. Trust them to be capable, talented individuals with a unique combination of skills that enriches the team. We respect the diversity of ideas and contributions because teams that all march to the tune of a single person underperforms over the long term.
I've been fortunate enough to work with lots of CRM practitioners on my agile CRM projects, maybe more than one hundred. They've all made a valuable contribution to the projects I've worked on, and I'm grateful to each of them.