New at Boost. Just moved here from Berlin to work as an Agile Coach. Interested in all kinds of continuous improvement, the lean organisation and coaching others to become agile.
Author Slide Up
Yesterday I went to see Shane Hastie’s presentation on Product Ownership. It was interesting to meet some of Wellington’s agile coaches and I enjoyed the presentation a lot. Having said that, I was a bit surprised that some of Shane’s ideas and statements didn’t cause more controversy. Having just moved to NZ two weeks ago, I kept the questions to myself at the time, however having had a longer think about it there are some thoughts I’d like to express.
The main topic of Shane’s presentation was introducing the audience to the idea that good product ownership requires a team rather than a single person.
He started by asking the audience what they think the problems with product ownership are. I didn’t take notes, so I don’t remember all the answers, but here’s a few:
“Product Owner is not the Product Owner.”
“Product Owner is not empowered.”
“Product Owner is not available.”
“Product Owner is just a proxy for senior management.”
“The architecture is too complex for the Product Owner.”
“The Product Owner does not understand technical debt.”
I agree that some of these issues are serious and have to be dealt with. It is natural to start tinkering with the process and it’s a good thing to do. Instituting a Product Ownership team though will probably not solve the problem, but may make it worse.
I’ve seen those symptoms before and most of them were attributable to a bad or half-hearted Scrum implementation.
Shane used the backlog as an example of why he thinks one person must be overwhelmed by the role of Product Owner. He referred to the Scrum Guide where it states
“The Product Owner is the sole person responsible for managing the Product Backlog.”
The problem with this quote is that it is a bit out of context. In the next paragraph the Scrum Guide states:
“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”
For the sake of the discussion I’ll ignore this part of the guide:
“The Product Owner is one person, not a committee.”
As the guide says, the PO is the one accountable for the backlog. But that doesn’t mean he/she has to do all the backlog refinement alone. I know companies who keep their backlogs completely open, so that everyone can pitch in new ideas. What the Scrum guide says though, is that one person has to be accountable. As it is the Product Owner who is responsible for the success of the product, he/she has to be the one who prioritises the stories. When in doubt which feature is more important, the Product Owner can talk to stakeholders, ask the development team for their opinion and so on.
Shane is certainly right when he says that being a good Product Owner is not easy, because you need to have a lot of skills. Here’s an overview from the presentation.
Although I agree with most of the skills listed on this slide, I don’t think that the Product Owner needs to know about UX and graphic design. I’ve seen Product Owners with UX skills spend a lot of time on upfront design instead. I’d rather let the development team figure out a good UX solution which of course requires having a UX designer in the team. Also I’ve not yet met a Product Owner with legal or compliance knowledge, but they have all managed to deliver successful products regardless.
So let’s take a closer look at what Shane proposes:
Some further thoughts I had during the presentation:
large management overhead
risking design by committee
some of the skills should be on the development team (especially UX/graphics)
what is the Project Manager for?
this resembles SAFe program layer although Shane didn’t talk about scaling
this will probably interfere with self-empowered teams
longer decision making process hence longer time to market
For me first and foremost, a good Product Owner needs a vision, good communication skills and a good understanding of his or her role and responsibilities. He/she should know whom to talk to when there are open questions and be there for the development team when they have questions. Does that mean we need a Product Ownership team? I’m not convinced.
How Scrum is an ideal way to become familiarise yourself with the Agile way of working
Gavin Coughlan: Hello, and welcome to episode 34 of the board. I’m Gavin Coughlan, an Agile Coach here at Boost Agile, and today we’re going to be talking about the Scrum versus Kanban. I know that’s not the correct pronunciation of Kanban, but we’ve been trying all morning…
Formerly a front end developer, Gavin is an Agile Coach with Boost. He helps organisations transition to Agile through team training and coaching.
Author Slide Up
I can clearly remember my first ever meeting. I was excited about being a part of it. It was an important meeting with a select group of key decision makers, business owners, major stakeholders, and me. My manager was ill that day so I was injected in to the meeting to represent the web team. I knew nothing about what we were to discuss, and certainly had no preparation time, so I was a seat filler. But still, it was a big meeting and a first for me, so I was enthusiastic even if I was little more than meeting meat.
This enthusiasm dwindled throughout the next four hours as I witnessed people discuss, as far as I could tell, nothing. Points were repeated ad nauseum, people had monologues for no apparent reason other than to be heard and discussions moved in infinite circles. By the end of the meeting absolutely nothing had been decided except than another meeting was necessary.
By the tail end of this prolonged catchup I was staring out the window feeling intense envy towards all the people I could see walking around outside unaware of the mental torture being inflicted on me in this stuffy room. They could feel the air on their cheeks, hear the birds in the trees and remember what joy was; all things that I had long forgotten.
As a result, I had come to dread meetings. But over time I found some methods of making them more productive and easier to endure.
I noticed that people’s eyes started to glaze over after the hour mark at meetings, and people were definitely mentally disengaged a half hour later. This graph demonstrates people’s attention span in the meetings:
So ensuring there is a timebox applied to each meeting is just one of the ways you can make it more concise, and therefore more productive. It also helps protect against being Colombo-ed. Anyone who remembers the legendary Colombo will also recall how he always had “just one more thing” to bring up when his interviewee thought the interrogation was over. I have seen this in meetings many times, everyone is closing notebooks, shuffling papers and generally making motions to leave, but someone decides that’s a good time to Colombo the meeting, to bring up “just one more thing”. A strict timebox gives you the opportunity to nip that in the bud, much like Norm from Cheers:
A timebox helps to minimise discussions about irrelevant topics that can often clog up an otherwise productive meetings, and helps make discussions about relevant topics more focussed. People know they have limited time, and need to make that time as valuable as possible.
When I was first introduced to Scrum I was pleased to see that each meeting had a very clear agenda. I was even more pleased to see that the four prescribed meetings were in place to help avoid other surprise meetings throughout the duration of a Sprint. I was nearly ecstatic when I saw that these meetings were all strictly timeboxed, and one of them was a mere 15 minutes long!
Going in to a Scrum meeting you know what you need to achieve and the maximum amount of time you have to achieve it. I have seen situations where teams have not gone through everything they wanted to at a meeting and felt the desire to keep going past the timebox. It’s tempting to let this happen, but calling a close to the meeting regardless of whether the team has achieved what they intended or not means that the next time the meeting rolls around, they will be more mindful of the time they have at their disposal.
Daily Standups are a great example of timeboxing in action. I have seen people sit down and get comfortable at Standups, arrive late, talk in circles, get in to too much technical detail and talk about work that is not a part of a Sprint. All of this obviously leads to a Standup that stretches far beyond it’s 15 minute timebox, and it quickly becomes a meeting that people resent attending as they know it’s going to carry on for an undetermined length. But if you cut it off at the 15 minute mark regardless of what is happening, people will learn to be more concise and stick to what they need to discuss to ensure everyone knows what they need to do, what everyone else is doing, and the general state of the Sprint.
How do you make sure timeboxes are been adhered to? I have learned through experience that it is unwise to throw projectiles at people if they seem to be going to deep in to the detail, as that can lead to minor injuries and unpleasant lawsuits. Tazers are generally frowned upon, as are most violent means. Ideally the team will police themselves at meetings, and call each other out if needed. They need to feel like they can do so, and may need help to get comfortable with it. But once they do, and the meetings are productive and complete within the timebox, then it should be a meeting that people want to attend rather than avoid.
Previously developer Jesse now brings his experience as a team member with within a highly functional Scrum team to his work as an Agile coach.
Author Slide Up
Recently Gavin and I were able to attend an Impact Mapping workshop run by Gojko Adzic. We got to spend the day trying out Impact Mapping and seeing how we can apply it to different situations. It’s an excellent tool, so we thought we would give you a run down on the basics and a couple of ways that you can apply it to your projects.
What is Impact Mapping?
Impact mapping allows us to link deliverables to high level business goals. By doing so we are able to understand the assumptions and motivations that underpin a user story and how each deliverable helps us move towards business goals. This link helps us to remain focused on delivering value in the highest priority areas.
The basic process
To begin creating an Impact Map you have a discussion based around four simple questions:
Why? – What do we want to achieve? What is our goal? e.g. Increase revenue, acquire more new customers, increase customer retention.
Who? – Here we aim to identify the stakeholders/user groups that could influence the above goals e.g. Customers, regulators, help desk, competitors
How? – Considering our goal and the actors that we have identified above what behaviour are we going to try to change to reach our goal. What impact are you trying to create? e.g. Buy more often, invite friends,
What? – Once we know what impact we want to have we can decide what we are going to do to. These could take the form of software (user stories) but could also be changes to processes.
At each step take time to consider how you could measure the goals and changes that you are discussing.
A simple impact map for an online retail store
How to apply this to your current project
One of the most interesting discussions we covered during the day how to use Impact Mapping to prioritise your backlog.
When working with a large backlog it can be hard to decide which stories offers the most value. You can create an Impact Map in reverse, so start with deliverables, link them to the impacts you would like to have and who these deliverables will affect, then what goals each of those link to. Using that information we can start a different conversation with the business.
Once we have mapped each deliverable back to goals you can then discuss which of these goals is most important to the organisation. For example, is increasing the number of sales more important than increasing customer loyalty? It will hopefully be easy for the business to prioritise these high level goals. Once they have chosen a goal to focus on then you can look back at the deliverable that are linked to that goal and prioritise this smaller subset of the backlog.
What is the Release Planning Session and how does it relate to the PSI and Release Management?
The PSI/Release Planning meeting
What is Release Planning?
When we kick-off an Agile project, the very first thing we will do is some form of collaborative, deliberate discovery workshop to determine the initial set of User Stories that will be worked on by the team(s). As part of this workshop we will often encourage the Product Owner to prioritise the stories into releases (the number of releases depends on the size of the project), as a way to determine what holds most value to the business and what needs to be worked on first. XP (eXtreme Programming) actually names this collaborative workshop “Release Planning”, as does SAFe.
The key thing to understand with Release Planning and the resulting Release Plan is that the further it looks into the future, the more volatile it’s predictions become.
SAFe understands this and suggests that teams only draw up a Release Plan for the next 3 months of work. In SAFe 3 months of work is known as Potentially Shippable Increment or PSI (covered in my previous post), So although the Product Management team will probably have a Roadmap looking ahead up to 3 PSI (9 months) ahead, the teams will only have a very clear picture of the current PSI (3 months). The feature content of each subsequent PSI will get less clear the further away it is.
This approach is very similar to Rolling Wave Planning project management where work is planned in time periods called “Waves”. Rolling Wave Planning is used on projects where progressive elaboration – iterative development – is required, usually as a result of tight timeframes and the necessity to re-priortise the scope of the work accordingly in order to meet schedule milestones. Sounds like Agile, right?
The Product Management team of one of our key clients has used Rolling Wave Planning very successfully to plan the work for one of our Scrum teams for past 5 years, a total of 135 Sprints. They plan in 3 month Waves, starting off each year with a 1 year, 4 wave, Roadmap.
What is the Release Planning Session and how does it relate to the PSI and Release Management?
SAFe literature calls this session Release Planning, but this meeting isn’t necessarily about determining what will be in the next actual release of software to our users. Instead it determines what the teams will be working to deliver for their next PSI (Potenially Shippable Increment). Granted, for some finishing a PSI will coincide with actually releasing the product, but for others they may choose to release off the PSI cadence, at times determined by the Release Management team. This is something that Dean Leffingwell refers to as “Develop on cadence. Deliver on demand”. Whichever way your organisation works, what the teams will be determining in their Release Planning meeting is what they will be designing, building and testing in the next 3 months, or 5 – 6 sprints.
In some of the SAFe literature I notice that they refer to the release as the PSI/Release, for me that really clarifies it.
Anyway, onwards and upwards, let’s look at the Release Planning meeting.
The PSI/Release Planning Meeting
The PSI/Release Planning meeting precedes that start of work on the first/next PSI. So, if the project is just about to kick off, the meeting will take place before the start of the first Sprint. If the project is already underway and are about to complete their PSI then this happens during the HIP (Hardening/Innovation/Planning) sprint.
The Release Planning meeting is attended by all members of the program. The aim of the Release Planning is the following:
Align the teams to the Program’s vision/objectives for the next iteration of the product.
Provide guidance for both UX and Architecture, just enough to maintain consistency across the organisation/program and enable the teams to complete their work.
Provide the teams with face-to-face, high-bandwidth-communication, planning time to determine how they will work together to build the next PSI. This will include resolving any dependencies between the teams, identifying and, where possible, mitigating any risks.
An example agenda looks something like this:
The primary objective of the first day is for each of the teams to take ownership of one or more features from the Program vision and create a Release Plan for the team. They do this by taking the feature(s) they’ve selected, and with the involvement of their Product Owner, break them down into stories to which they will give rough estimates. Each team will then map the stories into Sprints for the PSI, create a risk sheet (using colour coded post-it notes) and try to resolve any inter-team dependencies by verbally negotiating with the other teams. The final and most important output is a set of SMART objectives that the team will be working to for the coming PSI. The Product Owner will work with the team and other members of the Product Management team to assign business value to each objective so that the team is able to priortise accordingly.
Once the individual teams Release Plans start to take shape, they will start to add what they know to the overall PSI “Program Plan”. This highlights the new features (blue post-its), feature inputs (yellow post-it notes), anticipated delivery dates and any other relevant milestones (orange post-its). Most importantly it visually represents any dependencies the teams may have across their product with pieces of string to link the dependent items. These dependencies will no doubt be high on the identified risk sheets of the relevant teams.
This activity takes up most of the afternoon of the first day and is co-ordinated using a Scrum of Scrums approach, i.e. each team will send a team member to the hourly Scrum of Scrum meeting so that they can co-ordindate their Release Planning activity and determine if they are on schedule.
Once the PSI “Program Plan” has taken shape and/or the timebox expires, the Draft Plan Review will take place. This again is a tightly timeboxed meeting where the teams will present the highlights of their draft plans to all members of the Program.
This feeds into the final meeting of day 1, the Management Review & Problem Solving session, where the Program Management team meet to discuss any challenges presented by the draft Release Plan. The intent of this meeting is to resolve those challenges by negotiating scope and potentially resourcing.
At the start of day 2, the Program Management team present their suggested planning adjustments and the teams breakout to adjust their plans accordingly. Once the team has re-determined their objectives for the PSI, the business owners will make any adjustments to the business value for each objective if necessary.
During the Final Plan Review, the teams will present their plans to the entire group. At the end of each team’s timebox they will present their list of risks and impediments, but note, they don’t try to resolve them at this stage. If the plan is acceptable to the business owners, the team brings their PSI objective and program risk sheets forward to aggregate with the other teams.
Once all teams have presented their plans and the full set of objectives and risks is presented is assembled at the front of the room, the group work together to “ROAM” the program risks. The ROAM acronym stands for the following: Resolved, Owned, Accepted, Mitigated.
One by one the risks will be assessed, discussed openly and categorised into one of the above groups.
After the risk assessment activity is complete, the team will take a confidence vote, usually in the format of a fist-to-five vote. Closed fist demonstrating zero confidence, up to 5 fingers which demonstrates complete confidence. If the level of confidence is low, the plans will need to be reworked and any necessary adjustments made. Once the teams’ confidence is high, the plan can go forward.
The final step is for the group to carry out a Planning Retrospective to capture what went well, what didn’t go well and what could be done better for the next Release Planning session.
The outcome of 2 days of collaborative workshopping is a Release Plan for the PSI. This will, just as with XP, get refined and re-prioritised once more detail becomes available as work on the PSI progresses.
The current voice of our social media channels, Ruka also looks after our financial systems and generally keeps the rest of us in line.
Author Slide Up
In most cases your first idea will not be your best idea. In order to illustrate this concept we recently did an exercise with our Agile Coaches. We first came across this activity when some of our team members attended Jeff Patton‘s Passionate Product Ownership course. Jeff calls it Circles, we called it the smiley face game.
This exercise is best for 3+ people.
Materials you’ll need:
one sheet of A3 paper per person
a sharpie for each person
Ask participants to fold their A3 paper lengthwise, then in half, and half again until they have folds that form 16 squares.
Give them 2 minutes to draw different smiley faces in each square. If you see people are stuck, mention that they can be creative and think of animals etc when drawing smiley faces.
After the 2 minutes is up ask them to pass their paper clockwise to the person next to them and ask them to tick the smiley face they like and cross the one they don’t like. Ask them to keep passing the papers clockwise until they end with their own paper.
Once they have their own paper in front of them ask everyone to put their hand up if they have ticks in the first row of squares, then the second, third and fourth.
Then ask if they have any crosses in the first few rows and ticks in the latter rows.
Usually you’ll find that people get either few or no ticks in the first row of smiley faces, this nicely illustrates that the first idea (or smiley face in this case) is not their best idea. You can see this when you look at the page as a whole as well, the lower half of the page tends to show better, more creative smileys.
What does it mean – Scaled Agile Framework (SAFe)?
The Scaled Agile Framework for enterprise – SAFe – describes a framework for scaling Lean/Agile in the enterprise. The SAFe Big Picture highlights the individual roles, teams, activities and artifacts necessary to scale from the team, to teams of teams, to the enterprise level.
This workshop is run by Paul Flewelling, an Agile coach and certified SAFe Program Consultant.
Description of workshop
Scrum advocates a team size of between 5-9 for optimal results, but what happens when the product or value stream that you are developing requires a lot more than one Scrum team?
This workshop will look at what is possible when running a project at scale, we will describe a framework which can be used to manage at the team, program and portfolio levels of the organisation. We’ll also look at some of the lean/agile foundations that this framework is built upon.
At the team level we’ll show how teams are organised, how work is co-ordinated between teams and how each team determines what they will be working on. We’ll also look at the benefits of running feature driven teams over component driven teams.
At the program level we’ll look at how program management keep the work flowing to the Scrum teams as well as making it responsive and adaptive to change.
At the Portfolio Level we will look at how the needs of the organisation can be driven by the vision delivered by the Portfolio management team.
Along the way we’ll provide tips and pointers as well as looking at tools like Rally, which provides full online support for this way of working.
If you want to know more about SAFe sign up now through Eventbrite.
A former developer and start up entrepreneur, Paul has 20 years in the tech industry. Paul now helps organisations with their Agile transformations as an Agile coach and trainer.
Author Slide Up
The team level in the Scaled Agile Framework (SAFe) doesn’t look very different from any other Scrum team setup. SAFe advocates the use of a hybrid of Scrum and eXtreme Programming (XP), which isn’t unusual. Most teams that adopt Scrum will adopt practices from XP whether they know where these practices originated or not: User Stories, Test Driven Development, Simple Design, Pair Programming and Continuous Integration have become widely accepted as good software engineering and allow the team to maintain high quality while moving at speed.
Co-ordination of teams with SAFe
The way that SAFe manages co-ordination across teams is where added structure starts to appear. SAFe is used for running Agile projects at scale, 50 -125 people working on one value stream, and because we’re using Scrum and Scrum advocates an optimal team size as 7+ or -2, we will have multiple teams working on the same value stream. This will mean, at the very least, that teams will have inter-team dependencies to resolve. SAFe manages this by putting some structure around the Scrum teams in a few ways.
It advocates that the teams operate on the same cadence, i.e. the sprint duration is the same across all teams.
The teams synchronize their sprint start and end dates, this enables better co-ordination between teams.
It suggests that Potentially Shippable Increments (PSI) of a product of this size will only be possible after an arbitrary number of sprints are completed, nominally 4 or 5.
SAFe advocates the use of a final Hardening/Innovation/Planning (HIP) sprint at the tail end of the series of sprints.
The HIP sprint
The HIP sprint is used for the following purposes:
Hardening: Ensures that technical debt is reduced and time is given for any speciality testing that needs to take place, e.g. system wide performance testing.
Innovation: Providing time for teams to follow up on ideas and out-of-the-box thinking.
Planning: Assess progress and complete PSI/Release Planning for the next period.
A prerequisite to the planning that takes place during the HIP sprint is the Inspect and Adapt workshop, a meeting that is used by the entire group firstly to assess progress made in the last PSI, secondly to determine what can be done to improve their process in the next. The Inspect and Adapt workshop is akin to the Sprint Review and Retrospective used by the individual teams at the end of each of their sprints.
Other activities in the HIP sprint will include putting aside time for continuous education, infrastructure activities and so on. The HIP sprint is characterised by having no backlog items that provide new value and is purely devoted to the activities described above. Allowing time for these activities during the HIP sprint means that the development cadence can be maintained year around, with no special scheduling adjustments required.
SAFe advocates the above structure to drive alignment between the teams so that they can steer towards a common goal for the PSI without having to think about the dates or timings of the other teams. The pattern, x sprints + 1 HIP sprint, will be familiar to anyone who uses Rolling Wave Planning, a planning technique used specifically to allow for progressive elaboration.
The team backlog
The final piece of the puzzle at the team level is how each team determines what is on their respective Product Backlogs, also known as the Team Backlog in SAFe. As with any implementation of Scrum, each item on the Team Backlog is a work item, these work items are determined by the team in conjunction with their Product Owner. The team is able to add work items as it sees fit, but the Product Owner has overall ownership and it is up to the Product Owner to prioritise the work as they see appropriate.
The main driver for the work items are the team objectives for the PSI, these are determined by each team during a planning session at the start of the PSI. This session is known as the PSI/Release Planning session and is a 2 day session involving all teams, it is one of the key meetings in SAFe and is important enough that we will devote the next blog post to it.