Last week I wrote about the roles and responsibilities of a Developer on the Scrum team. This week is about the Product Owner (often simply referred to as the PO). It’s worth noting that the PO can also be a Developer. However, in my experience the Product Owner is more commonly a non-technical ally for the team, a specialist in the product or the industry.
The PO should not be confused with a Project Manager, that is not their role! A scrum team should be self managing.
The Scrum Guide’s first few words about the PO define their role the most succinctly.
The Product Owner is accountable for maximizing the value
The Scrum Guide 2020
In other words it is the role of the Product Owner to ensure that the Scrum Team are always working on whatever will deliver the most value to the customers and the business. Whether that’s a bug fix, a new feature, or an investigation into upcoming work.
They use Product Goals to avoid this vision becoming too short sighted and reactive, sharing a future state of the product they are working on and working with the Scrum Master and the rest of the team to make that goal a reality.
It is the responsibility of the Product Owner to ensure that the Scrum Team are focused on the most valuable work at any given team.
There are also a few key points around the PO’s role:
Should the Sprint Goal become obsolete the PO is the only person with authority to cancel a sprint
The PO is a single empowered individual, it is not a committee. Two (or more) POs cannot share a product however the PO can delegate work to other people within the team they remain accountable
The business must respect the decisions made by the PO
It is also the Product Owner’s resposibility to understand and articulate the work and make sure that the Acceptance Criteria is well defined and the Product Backlog properly ordered.
It is the Product Owner’s responsibility to communicate the work to the developers so it is clearly understood and can be delivered.
Finally, the Product Owner should always engage with stakeholders to properly understand priorities and requirements. In order to maximise value they must speak with the business and the customers to understand the biggest issues. They must then work with the team to deliver it.
There are a couple of great resources out there for POs if you’re interested. The first is a video by Henrik Knibergwhich gives a great overview of Agile Product Ownership. The second is an article on Scrum.org which discusses the PO’s role in managing and understanding technical debt.
However you cut it the PO’s role is very challenging and includes lots of difficult decisions. Be nice to your PO – create transparency and openness with your point of view and then respect their decisions.
Having covered the Scrum Events in recent blog posts I’m going to move onto the three Roles in any Scrum Team. These are Developers, Product Owner, and Scrum Master. This post will be about the Developers, I’ll cover the other two in subsequent posts.
Developer here is a rather broad term. Scrum is most commonly used in the software industry but not exclusively, and as we all know there are many other skills required to build and deliver software than crunching code. For the sake of simplicity The Scrum Guide has termed anyone working to create the product a Developer.
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The Scrum Guide 2020
It goes on to explain that the skillsets that the developers will need are wide and varied depending on the domain and nature of the product. For all intents and purposes the “Developer” is anyone who does the work. This could include (but is not limited to) Programmers, Testers, Automation Engineers, Infrastructure Engineers, and UX Experts. From the point of view of Scrum there is no distinction between these roles.
Interestingly the Scrum Master and Product Owner can also be Developers, it’s just that they take on more responsibilities with the additional role.
In Scrum a Developer is anyone who is involved in creating the increment each sprint.
Where the Scrum Guide goes into in more detail is what the developers are accountable for.
Creating a plan for the Sprint, the Sprint Backlog inother words the Developers, as the people doing the work are the ones accountable for creating the plan and Sprint Backlog. This is in stark contrast to more traditional management models where “the boss” creates the plan and assigns work.
Instilling quality by adhering to a Definition of Done the Developers are experts in their domain and professionals. They will create the Defintion of Done with the Product Owner and Stakeholders and hold themselves accountable to adhering to it.
Adapting their plan each day toward the Sprint Goal usually during the Daily Scrum. The Developers will inspect the current progress and adapt if required. They may seek out the Scrum Master or Product Owner if the impediments need to be adapted or if the approach to the Sprint Goal needs to change.
Holding each other accountable as professionals the best teams hold themselves accountable because the end results are important to them. All Scrum Team members should hold each other accountable for their actions and behaviour in a open and respectful manner.
Developers should hold each other accountable as professionals
It’s not easy being a Scrum Developer, a lot is expected of you. However, the experience of working in a team where people respect each other and have the courage to speak up and respectfully challenge ideas and designs is hugely rewarding.
This is why Scrum makes the accountabilities and values of each developer so transparent in it’s guides and resources.
The Sprint Retro is a key part of any scrum team which is looking to improve its process and adapt its ways of working to continuously improve. As with any adaption the key is transparency, the the more information the team can gather throughout the sprint around impediments or challenges they’ve faced the better. Personally I like to create a retrospective board at the start of a Sprint so team members can add their thoughts to the board as the sprint evolves rather than looking back (which always favours things which happen in the last few days).
The main challenge with the Retrospective is to avoid it turning into a moaning or helpless session. From The Scrum Guide:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Guide 2020
Scrum Masters use a wide variety of techniques to support gathering information about the sprint including anyonmous submissions, “What Went Well vs What Didn’t Go Well”, and often scenarios involving rockets or icebergs. However, it’s important to remember that the Retrospective is a working session to give the team some concrete actions on what they can do to increase either Quality or Effectiveness (or, ideally both). While having a good rant about something which went wrong or something which impeded them can be therapeutic unless an action is taken to lean from that then neither objective should be met.
Teams must look at how to improve and adapt to challenges, not just moan about what got in their way.
This kind of adaption is not easy. It requires teams to look honestly at what’s happened and see what they could have done different, this kind of self assessment takes real courage and for the team to have a real growth mindset. It’s the delicate role of a Scrum Master to balance between criticising what the team should have done and coaching them to look for alternative strategies of what could be done in the future.
Its easy to say that a Sprint Goal failed because X in the infrastructure team. It’s much harder to reflect on what the team could have done to prevent that issue arising. It requires taking acountability and to avoid casting other people as villains.
In earlier versions of The Scrum Guide the team were required to add at least one action to the next Sprint Backlog, however it is now recommended to be properly alongside other work.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Scrum Guide 2020
The Sprint Retrospective requires the three pillars of empirism to be effective however this time they must be focused inward, at what the team could change or could have done differently. It also requires the Scrum Values to be first and foremost in everyone’s mind. Impediments can come from within the team as often as outside it and we rely on our courage and respect to get us through those tough conversations.
Please feel free to post in the comments below of any retropectives which have worked really wel for you in the past, it would be great to read about them.
The Sprint Review is an invaluable session to demo progress, engage stakeholders, and discuss what to do next. However, in my experience mist teams don’t take full advantage of the session.
The Scrum Guide says
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
The Scrum Guide 2020
In other words the review is a chance to take a step back and look at the increments which have been completed during the sprint, consider the product goal, and decide the next short term objective.
This should be done in full view of stakeholders, the more transparency the better because this is how we avoid waste and poor quality.
Sharing work with clients and stakeholders is daunting but it’s far better than building the wrong thing.
Personally I’m always worried when I hear teams ask “Do we have anything to demo?”. This often implies to me that they think of the Sprint Review as a presentation of progress rather than a working and planning session. Furthermore, a scrum team should aim to release at least one increment, no matter how small each and every sprint so keep an eye out for these warning signs.
The Scrum Guide reminds us that:
The Sprint Review should never be considered a gate to releasing value.
The Scrum Guide 2020
It is far better to think of the Sprint Review as an opportunity to recap what has recently been completed (if not deployed) and a chance to engage with stakeholders on what should be done next.
Last week we talked about the Sprint Planning session, today I’m going to move on to one of my favourite scrum events. The Daily Scrum.
The fifteen minutes each day where the team catch up are some of hte most powerful, but also some of the most woefully misunderstood of all the scrum events.
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Scrum Guide 2020
In other words the entire purpose of those 15 minutes is to review the team’s progress against the Sprint Goal and ensure that they are still on track. They should consider progress, any new information they’ve discovered, and any risks they’ve found and discuss if any change of strategy is required to hit the Sprint Goal.
The Daily Scrum is about verifying progress against the Sprint Goal. Photo by cottonbro on Pexels.com
The Scrum Guide also says
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.
The Scrum Guide 2020
However, more than in almost any other event I see zombie scrum going on in Daily Scrums. In team after team, company after company I see teams standing up around a screen answering the dreaded three questions “What Did I Do Yesterday?”, “What Am I Doing Today?” and “Do I have any Impedements?” (by the way – 99% of the time people apparently don’t).
While there’s nothing wrong with this approach there’s something seriously amiss if the team do not circle back to address the main point of the meeting. Given the raw data we’ve captured from the team on their progress and their blockers do we still believe we are capable of meeting the Sprint Goal? Has something someone has said put that in jeopardy and what can the team do adapt.
The Daily Scrum is the daily iteration of the inspect and adapt pillars of empiriscm (which only works if there is a feeling of safety in the team which creates transparency). Instead of simply waiting for their turn to write the three questions developers should be listening to each other’s answers and looking for indication that the team may not meet it’s objectives.
Don’t be afraid to mix up the Daily Scrum format, but do be very nervous if you’re not discussing the Sprint Goal in each and every meeting!
Last week we talked about the Sprint. This week we’re going to kick off with Sprint Planning. The Scrum Guide defines Sprint Planning as
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Scrum Guide 2020
It recommends you do this by answering three questions. How is this sprint valuable? What can be done this sprint? How will the work get done?
In my experience most scrum teams by estimating Product Backlog Items, or PBIs (often called User Stories) and estimating how much work they can deliver by looking at their historical velocities.
This, in my opinion is wrong.
When teams do this it’s very easy for them to let the work drive the goals instead of the other way around. Rather than identifying what they want to achieve and working out how to deliver it they look at lots of granular pieces of work and cram as many into the sprint as possible, often losing synergy and coherence in the future.
It is always better for a team to look at what they want to achieve and what the various people can do to make that happen than to try and assign particular tasks to each person. This sometimes means that people’s capacity isn’t 100% utilised. But that time is infested in collaborating, learning, paying down tech debt, and supporting their team mates who are on the critical path. Far better than having everyone so stressed by an arbitrary deadline because some random user story was included in a sprint.
Working out what to include, or not include in a sprint is never easy
A team should always identify the next step forward for their product, the one which would yield the most value and plan the work required to meet that goal. They can use estimates to assess whether a particular plan for doing it is feasible. They shouldn’t focus on trying to fill up a quota of story points from estimates of varying accuracy.
It’s the PBIs which are planned to meet the sprint goal which we will use to verify our progress in the Daily Scrum sessions. This will be the subject of next week’s post so make sure you’re following the blog if you want to read it!
I am currently studying with a view to attempting my PSM-III, if I stand any chance of passing I need to go back to basics to make sure I have a rock solid understanding of the fundamentals. With that in mind for the next few weeks I’m going to go back to core scrum and share my views on some of the fundamentals.
You can’t get a lot more fundamental than the sprint. The scrum guide defines a sprint as
Sprints are the heartbeat of Scrum, where ideas are turned into value.
The Scrum Guide 2020
In scrum we plan work in timeboxes, usually 2-4 weeks. By working to a much shorter planning horizon we can gain a lot of confidence as we go by reviewing progress frequently and adapt as required as the project goes along.
It is not a release schedule!
Many teams I have worked with attempt to set their deployment schedule with their end of sprint. These should be entirely coupled, DevOps has lots of good ideas about how and when to deploy. Deployments should be done as required throughout the sprint.
The sprint is about setting a goal and a timebox to achieve it. By having a consistent length of sprint we can gain confidence in the amount of work which can be delivered by looking at how much has been achieved in previous sprints. This is the purpose of velocity and estimation (a useful tool, if not a scrum process).
During the sprint:
● No changes are made that would endanger the Sprint Goal;
● Quality does not decrease;
● The Product Backlog is refined as needed; and,
● Scope may be clarified and renegotiated with the Product Owner as more is learned.
The Scrum Guide 2020
In other words the team should focus on the objective of the sprint (the sprint goal) and not get distracted and put it in jeopardy in favour of other work.
Quality should be at least as high at the end of the sprint as it is at the beginning, one or more increments of work should be completed should be produced and all should meet the Definition of Done. If it isn’t “Done” then it shouldn’t be included and may be picked up in the next sprint. Testing phases and hardening sprints are categorically not scrum. Each price of work should be a high quality, done, potentially shippable increment.
Refinement of upcoming work and investigation of planned work continued as time goes on. Remember a sprint goal can be achieved even if the method and approach is refined as the sprint goes on.
So how long should a sprint be? This comes down to the development team in question. Generally a more work can be done in a longer sprint, however there’s more risk that something will arise which would invalidate the sprint goal. For this reason sprints should not be longer than one month.
Finally, if at any point the sprint goal becomes invalid the Product Owner may cancel the sprint. This could be for a number of reasons. The priority of work may have changed dramatically due to customer needs or the discovery of a bug (shorter sprints help prevent the waste of cancellation here). Or, the team may discover as they progress that the goal is impossible or not as valuable as originally believed. We’re in the business of doing effective work. If we discover that work isn’t going to be valuable our job is to avoid waste and move onto something which would be.
There’s probably a lot more I could add but hopefully it’s a good introduction. Do follow along for the rest of the series, next week will be Sprint Planning!
This week I want to talk about the two most important rules you can follow if you want to deliver great work and hit goals. Regardless of whether they’re software projects, books you want to write, or exams you want to pass. They are utterly underwhelming…
Rule 1: Start doing it
Rule 2: Keep doing it until you finish
There you go, I told you they were underwhelming!
However, I want to go a little deeper (otherwise this would be a very short post).
Failure to start is one of the biggest reasons people don’t do things. How many times have you planned to do something one evening only to get home and fail to do it? The reason (according to James Clear in his book Atomic Habits) is because it takes energy and effort to start doing things. Far too often our brains follow a pre-programmed pattern to avoid decision fatigue. Do you want to go running tonight or watch television? What do you need to do to start running? You’ll need to get changed, then you’ll need to find your trainers, then you’ll need to actually do the running… oh, and then there’s the shower. But the TV remote is just there.
In his book James describes ways to reduce the friction required to take on these individual habits and actions and make them easier to do day to day. I do this myself. I want to listen to audiobooks each day, so I leave my headphones by the side of my bed so they’re the first thing I pick up each morning. If you want to go for a run after work then put your kit on your bed before you leave in the morning – or even better put it on before you leave the office so it’ll actually be more effort not to go for a run than it will be to just get out the door!
Once you’ve got started that’s a huge step forward. But a single run doesn’t make you fit. A thousand words doesn’t make a book. So how do you keep that momentum going day after day to make progress until the work is done?
The first step is to understand what “Done” is. Is there a done? If it’s about fitness then you may be looking for a particular weight or time, but you may also be looking to maintain. If you’re building a product you may be looking for a number of active users. Just like in product management and software development we should always be clear about what we want to accomplish before we set off. We can evolve that view, but it helps to act as a beacon.
This leads directly into the motivation question. If we understand our objective we can track our progress towards it. Visibly seeing our progress towards a concrete goal is a very powerful motivational tool (as well as the other benefits of transparency and adaptibility). Burn up charts for your personal goals may seem like overkill, but they’re really not.
Here’s my burn up chart for my reading goal (you can see I actually made the goal far more ambitious because I was doing so well).
You can see I’m doing something similar with my cloud computing exams. This one isn’t going so well, and what am I going to do about it? Revalidate the goal, recalculate the effort and expectations, and then really myself. As with all things agile create transparency, inspect, and adapt.
I know this post started a little tongue in cheek but hopefully it helps and has provided some valuable tools to meet your own goals. Don’t forget, start… and then continue until you are done!
This is a question I hear a lot, people have heard of (or may follow) Scrum and often have read about DevOps. They want to know whether DevOps is a replacement for Scrum or if it’s something they should be doing as well. Others believe that Scrum and DevOps are incompatible, in this post I want to talk about what both of these are how (because spoilers – they can) they should be used together.
What Is Scrum?
Lets start with the obvious question, if we’re going to discuss how DevOps and Scrum interact we need to define what exactly what we mean.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
The Scrum Guide
The Scrum Guide is an extremely concise and valuable guide to Scrum. If you haven’t read it I strongly recommend you do. However, for the purpose of this post I’m going to to highlight a few points.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
Various Sections of The Scrum Guide 2020
When many people think of Scrum they discuss the Scrum Events, these include Sprints, Retros, Planning Sessions, and Sprint Reviews. However, equal importance should be given to the underlying theory of empiricism and incremental nature.
Each Scrum Team should deliver at least one increment of work each Sprint, this increment should be potentially releasable, and meet the Definition of Done. They will then meet in a Sprint Review meeting and discuss what they should do next to deliver maximum value.
What Is DevOps?
DevOps is, at it’s core an effort to reduce the divide between development and operational teams. Literally, Dev-Ops there are many practices and ways of doing this from the cultural to the technological however what has most likely led you to this post are the ideas of Continuous Integration, Continuous Delivery, and Continuous Deployment. Again, DevOps has many valuable lessons, I’m focusing on these three not to devalue the other concepts, but simply because they are some of the key concepts we need to understand for this article.
Continuous Integration requires that each developer merges their code into the master branch every day and if the master build breaks it is resolved or rolled back within ten minutes.
Continuous Delivery is a promise that any code which is the master branch is always in a potentially deployable state. Untested and unverified code is never merged in.
Continuous Deployment is an automation mechanism which pushes whatever is in the master branch into environments (often production) without any manual steps.
As you can see these are cumulative, so teams may practice Continuous Integration but may not practice Continuous Delivery or Continuous Deployment. It is also nearly impossible to practice Continuous Deployment unless you also follow Continuous Delivery and Continuous Integration.
It’s also worth mentioning the “3 Ways of DevOps” these were popularised by the highly successful book The Phoenix Project. The 3 Ways are:
Flow/Systems Thinking
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
Using Scrum and DevOps Together
Now that we’ve talked about what Scrum and DevOps are (or at least highlighted some of the relevant and key parts of each) I want to discuss whether these concepts can work in harmony together.
The first aspect to address is the Scrum concept of an increment. The Scrum Guide says that each team should produce at least one increment of “Done” software which is potentially releasable to production each sprint. I believe that the three concepts of Continuous Integration, Continuous Delivery, and Continuous Deployment are not only compatible, they are the natural evolution of this requirement.
If an engineering team is following CI, CD, and the other CD then each day (or less) a piece of work should be added to master. This means that a typical team of 7 engineers working a standard two week sprint could easily produce seventy or more increments in a single sprint. They key here is that by breaking down the Scrum Product Backlog Items down into single pieces of work which can be individually developed with a single day and then tested in isolation. This is not easy, however with practice and strong story splitting skills it can be done.
It’s also worth mentioning the Definition of Done. The Scrum Guide states that each increment must meet the Defintion of Done. Continuous Delivery states that the master branch should be always be in a deployable state. What a high performing Scrum/DevOps team should do is write automated tests which execute against incoming pull requests into their master branch to confirm that it always meets the agreed Definition of Done. This not only reduces the amount of repetitive testing work expected of the team but it highlights immediately when a proposed increment does not meet the team’s Definition of Done. If it doesn’t, it’s not merged in.
Maybe DevOps and Scrum aren’t incompatible after all? Photo by Blue Bird on Pexels.com
Before wrapping up I also want to consider the 3 Ways of DevOps I discussed above.
By building the Definition of Done into the Deployment Pipeline of the product we support the 1st Way by ensuring that the requirements of the team are baked into the pipeline.
The 2nd Way is to shorten feedback loops. Scrum emphasises the value of engaging with stakeholders frequently to ensure that they are involved and know the current state of the product. Scrum is also based on empirism, the belief that only we can only make estimates by looking at real data, by valuing the 2nd Way and shortening those feedback loops wherever possible this gives us a more accurate picture of what impact our changes have had. Simply put, this more accurate view provides the transparency we need to inspect and adapt. These are the three pillars of empirism.
Scrum also defines an event, the Retrospective where team members should meet to discuss ways to improve the quality and effectiveness of the team. This fosters the experimentation and innovation expected of the 3rd Way. These ideas aren’t working against each other. Scrum is providing events to ensure that the DevOps approaches are being honoured.
Conclusion
DevOps is often seen as a Scrum upgrade or perhaps a replacement to the agile framework. However it shouldn’t be. I believe that many of the automation and development strategies of DevOps are the natural evolution of Scrum principles and fit very neatly into any team already using the process.
With automated tests continuously testing each increment to guarantee that it meets the team’s Definition of Done increments can become smaller and a continuous flow of high value work can be delivered with shorter lead times and higher quality.
This is a question I get a lot, what are Scrum Alliance and Scrum.org and which is “best”? The truth is there is no best, both have different certifications and a different business model. In this post I want to explain the differences between the two and help you decide which to choose.
Let’s start with what they do. Both Scrum.org and Scrum Alliance offer training courses and certifications for Scrum Masters and Agile Professionals. Both offer a variety of courses for Product Owners, Engineers, and other professions but in this post I’ll focus purely on the scrum masters.
You can think of these organisations like Exam Boards, if you pass their exam you get a certificate which you can present to any employer and it will prove that you have a certain level of scrum knowledge. You can also show the badges off to your friends and family but personally I’d recommend against that. I spent half an hour explaining to my mum that a Scrum Master had nothing to do with Dungeons and Dragons…
Both organisations offer three levels of Scrum Master certification. For Scrum Alliance these are the Certified Scrum Master (CSM), the Advanced Certified Scrum Master (A-CSM), and Certified Scrum Professional Scrum Master (or CSP-SM). Scrum.org offers the Professional Scrum Master levels 1, 2, and 3 (more commonly known as PSM-I, PSM-II, and PSM-III).
Personally I hold the CSM from Scrum Alliance as well as the PSM-I and PSM-II from Scrum.org.
Where these organisations differ is in how they go about granting the certificates. Scrum Alliance require you to attend a training course organised by a certified trainer. The prices of these vary depending on whether they are being held remotely or in person, which country they are being held in, and the level of the course. Typically in the UK you will pay around £700 for a remote course and £2000 for an in person one. Obviously the trainer then pays a fee onto Scrum Alliance. Once you have completed the course you will be sent a link to take the exam on Scrum Alliance’s website. If you pass (the pass mark is 37/50 questions) you’ll be awarded your certificate.
Scrum.org also offer training courses. However, their courses are not a prerequisite to taking the exam. Personally I have never done a Scrum.org course, I simply logged onto the website and purchased the exam token. These vary slightly depending on level but the PSM-I exam is $150 dollars.
It is also worth noting that Scrum Alliance certificates expire and you will either need to attend another course or pay (about £30 I believe) to renew it every couple of years. Scrum.org certificates do not expire.
The next most obvious question is which is easier!? There is a general feeling that the Scrum.org exams are a little more challenging, however I’ve never seen any data to back this up. Personally I scored a couple of percent higher on the Scrum.org exam than the Scrum Alliance one however not enough to state clearly. If you’re looking for a simple answer on which one would be easier to achieve or which holds more market value then I can’t give that. I would say however that the PSM-II (and I assume the A-CSM) covers significantly more ground than the PSM-I and asks questions based drawn from personal knowledge rather than simply knowing the subject matter. There is a distinct step up in difficulty and, although I’ve never taken it I wouldn’t be surprised if the PSM-III was far more challenging again.
So there you have it, all the differences that I’m aware of between the two organisations. If you’re looking for a taught course with a certificate at the end then Scrum Alliance may be for you. If you’re interested in self study and funding then Scrum.org may be the better alternative however I’ve found that both are extremely high quality certificates.
dotdotdev.com 