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.
Apart from the excellent hands-on training style that is so often a part of agile training sessions and the sheer density of the well thought out course material, I also really enjoyed the opportunity to engage with some of the leading people in the Scaled Agile community.
Dean Leffingwell (SAFe’s Chief Methodologist) has industry experience second to none, having been a part of the iterative development movement, in particular the Rational Unified Process, one of the major precursors to the Agile movement.
Al Shalloway’s company, Net Objectives, has been Agile as long as I can remember and is an industry leader, Al himself is a thought leader, particularly when it comes to Lean and Kanban.
As with all my visits to the States, I try to tone down its sometimes larger than life nature and look at its sheer scale from a pragmatic perspective. When all is said and done our endeavour is the same even if the scale is different.
And running Agile projects at scale is what SAFe seeks to address, value streams of work that span many different teams. The SAFe framework and its curators don’t claim to have all the answers, and nor should it or they. After all, each organisation is different and has different ways of achieving its goals. SAFe is merely a framework which like all good Agile frameworks, encourages you to inspect and adapt your process.
One of the key attributes of SAFe that makes it so attractive is that it seeks to address how the existing Portfolio and Program management levels interact with the Agile (usually Scrum/XP) teams who are actually building the products. It merely seeks to make these management levels operate in a more Agile way.
Over the coming weeks I’ll write a series of blog posts around different aspects of the Scaled Agile Framework, sharing my learnings and understandings as best I can.
Our newest Agile Coach Joe keeps the rest of us updated on the latest in the Agile world, as well as providing team coach and Scrum Master services to some of our development projects. He's also one of the cameramen for The Board.
Author Slide Up
Recently Alistair Cockburn, one of the 17 original Agile Manifesto authors, posted a question he was asked by a person called Gaboo, about the role of the Scrum Master.
Part of any Agile process necessitates stopping and thinking about the quality of the product you are producing as well as the quality of the methodology that is being used (12th principle ~ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.) With this in mind, questions about whatever framework we may or may not use should not only be asked, but embraced and seriously thought about when brought up.
Gaboo wanted to know:
Is there anything implicit which says that the Scrum Master must have background in software process improvement and psychology?
If they don’t have a professional background, how can they judge team dynamics and software development issues?
How can the progress of the team or the performance of the Scrum Master be measured?
I immediately saw why Alistair posted this question. These are all extremely valid questions as the role of the Scrum Master is a bit hard to understand in the business world. Managers are responsible for planning, delivering projects and organising the team. If a Scrum Master isn’t directly responsible for delivering the product and the team decides how they want to organize themselves, what is the Scrum Master responsible for and what kind of skills do they need?
I posted a response to Gaboo’s questions and I answered as best I could without using definitions and doctrine. I tried to focus on my experience with the Scrum Master role and how it fits into our team’s dynamic.
Questions 1 & 2 were similar and I tried to tie them together with this response:
It doesn’t hurt to have experience in software if you are coaching software teams, but not in order to solve their problems. It may be useful to have similar experiences to that of the team so you can relate to them. The Scrum Master position is concerned with enhancing productivity through collaboration, not through software or a commanding influence.
Question 3, about measuring the progress of the team and Scrum Master, I answered with:
I think the only way I can attempt to share any insight on this is to indirectly answer your question with the thought that Agile (Scrum) is a framework to encourage empirical thinking/reasoning in a team. If a team isn’t iteratively looking at what it’s producing and how it’s producing it, it isn’t progressing. Because of the iterative nature of Agile (and thus Scrum) this evaluation is always being made. Though there are many tools to measure progress and influence, the very act of iteratively analysing the team is a progress indicator unto itself.
To get the full context of my answers, and a few more tid-bits concerning the Scrum Master’s role with impediments, you can read my full response on Alistair’s blog post on Why do we need a Scrum Master?
These are my thoughts on the subject. I’d be interested to hear about anyone else’s experiences/reservations on the role of the Scrum Master.
A former Scrum Master and Agile Coach, Kirstin is Boost's General Manager.
Author Slide Up
In episode 11 of The Board, we decided to to change the format a bit by introducing some sofas to the set and adding a third presenter. The result is a little less formal and more conversational, let us know what you think of the new format by commenting below.
During the episode we talked about Agile in Government and the Scaled Agile Framework (SAFe). We covered:
the introduction of Agile in smaller steps, perhaps starting with a visible workplace