AgileSparks-Agile Consulting/Training With a Spark
AgileSparks is providing Agile/Scrum/Kanban solutions including training, coaching, assessment, All things Agile/Lean,focused on Agile Transformations, Scaling, Organizational Agility, Agile Marketing, DevOps, Kanban, Lean Startup.Follow this blog to know more about Agile.
At AgileSparks, we’re known for speaking out against what we call Agile Theatre where a company goes through the motions of adopting Agile but stops short when it comes to changing the way the business operates. Real agility affects every aspect of an organization and therefore, requires a massive cultural and operational shift.
SAFe is a path to agility, but the organization does the heavy lifting
So, what does SAFe implementation look like when an organization goes all-in to achieve agility at scale? We wanted to give our readers an understanding of what it takes and invited Canadian firm, RAPID RTC to share its story of transformational change.
RAPID RTC delivers market-leading, proprietary software solutions to several verticals including the automotive and agriculture sectors that enable comprehensive lead management and lead generation through real-time customer conversations via its Lead Manager, Chat, and Text products.
At the time of our engagement with RAPID RTC, this successful company was poised for continued expansion and growth. It had goals to enter new markets and had interest from customers in new verticals. But the company’s evolution had revealed challenges that were impeding its ability to capitalize fully on the opportunities. These challenges included:
Too much time estimating and prioritizing
Products consistently taking longer to release and costing more than expected
RAPID RTC was experiencing some of the classic product development challenges. What was encouraging was its level of commitment to invest in real change. Together, over five months, we undertook the following:
RAPID RTC has made a remarkable transformation. In 2018 it was an organization looking for ways to keep up with its growth and business opportunities due to challenges resulting from a waterfall development approach. Over that pivotal year, the company changed its team structure, development language, methodology, and deployment strategy.
Results to date have included:
Significant improvements in time-to-market
The ability to monetize product development faster
Deeper staff engagement and satisfaction
Momentum resulting from every part of the organisation creating and investing in business objectives and working together to achieve them.
“AgileSparks gave us the foundation to help us mature as a company. In business, a company continually evolves to meet new challenges but over the years, our development and product management processes became bloated, cumbersome, and we could feel the nimbleness slowly eroding away. We needed a way to involve multiple stakeholders and provide accountability to each other to create a unified path forward that was responsive to our customers. Make no mistake, Agile is not a pill that makes everything perfect overnight. It takes time and applied commitment from every level of the company, but if the commitment is there, I can’t speak enough about the results I have witnessed.” – Glen Demetrioff, President & CEO, RAPID RTC
How did RAPID RTC do it?
Get an inside look at how RAPID RTC approached its SAFe journey alongside AgileSparks. Learn how it put Agile to the test before committing to it, what went into orchestrating the foundational event that launched the transition, and how teams along with the whole organisation reorganised to become more agile.
“We felt it was important not to move too quickly in our transition. I compare it to cracking an egg—you don’t want to swing it too quickly, but if you don’t swing it hard enough it won’t break. It’s a balance.” – Keith Meyer, CTO, RAPID RTC
Working with teams I sometimes feel that teamwork is similar to the weather: everybody talks about it but not much is done. When I talk about teamwork I mean doing the work together, as a team. Advising with each other is good, planning together is necessary, going to lunch as a group is fun and like the other activities, is probably a good way to get nearer to team work. However , as said above, I’m talking about doing the work together. And here are 3 steps that will help you get nearer to that worthy cause.
First step: no personal assignments. Most electronic boards (e.g. Jira, TFS, Gitlab etc.) have an “assigned” field on stories. Don’t use it. As simply as that. Let it be empty. During planning meetings don’t talk about who’s going to do a story, leave it to later. When is later? Later is when we need to start working on the story, when it is next in priority. And then also don’t assign a person. Talk about who will start working on it today. Who in plural, I mean. Then tomorrow, in your daily meeting or during the day, agree who should work on it then. This is a team thing. There is no specific one developer responsible for the story, it is the team.
Some people will say: but how will we know who is working on what? The answer is simple: if you are working on many stories in parallel it might indeed be difficult to know that. So work on less stories in parallel and then everyone knows who’s working on what.
Second step: Weekly mob programming sessions. Mob programming is the activity where the entire team is developing together. Set a meeting room with a big screen, one computer and one keyboard. The keyboard moves every 5 minutes from one person to the next. The team decides what the driver (the person on the keyboard) does. Now work on your ongoing tasks. People who hear about this for the first time find it hard to understand this but you need to try it out. It works like magic. This is an activity that brings the team together. Spend every week 1.5-2 hours on this, going on some of the ongoing tasks and good things will start to happen. Llewellyn Falco wrote a book about this.
Third step: Pairing. Pairing is when two developers develop on the same workstation. Remember that most of what you do during development is thinking, not writing, so one keyboard is not a problem. In workshops I’ve lead people always say its more fun to work together and they think of more creative solutions. Alistair Cockburn and Laurie Williams show pairing is 15% more effort (e.g. while one person will do the job in 2 days, two will do it together in 1.15 days) but other benefits make it a thing you must do. Arlo Belshee wrote an essay about promiscuous pairing, a must read.
The daily meeting is a good place to think who will pair with whom today.
To summarize, the main problem with team work is that is doesn’t look good on a spreadsheet: you see plainly more people on the same job and you don’t see that magic that it does. Don’t let this stop you. Start by not assigning specific people to tasks, move on to mob programming and then find opportunities to pair. You will see results quite quick.
As a system admin or a project manager you often find yourself torn between management requirements and users who find the tools not as comfortable as they would like them to be. Jira is without a doubt a tool that can raise mixed emotions among users. Lucky for you, most of the users’ challenges can be easily handled.
1. Complex workflows and too many required fields
The most common challenge users experience when working with Jira is complex workflows. Many project managers love to stay in control and with Jira’s capabilities it’s quite easy to do; You make users fill required fields, add screens and validations between status changes and in no time you have created the most complex workflow ever! Congrats! But hey – what about the end users?
Can we handle it?
When creating workflows, plan ahead, stop every few minutes and think how would you feel if you had to pass this workflow for every issue. Create simple workflows that have minimum requirements from the end user. If possible, assemble the required fields into one screen before closing an issue. Trying to think like users will help you find many non required fields that can be removed from the system. Win win situation.
2. The many views confuse users
Putting aside addons that enable more issue views, any Jira user can view a single issue on several different screens; An issue can be opened on a full screen view, or as a ticket with some details on a board. Also, it can be viewed on a quick view on your board or in a search query with defined fields. Different views can cause confusion between team members, who may miss critical information if working with a view different from the other team members.
Can we handle it?
If you are working with a board, I would suggest fitting the quick view to provide the needed details so it will provide the best view for your needs and everyone will be able to work inboard mode. If it’s not possible and working in board mode will not be sufficient, you can make it a collaborative team decision which view they all agree to work with.
3. Excel is still required; Jira cannot provide me everything I need
Many times, project managers can find themselves looking at Jira and trying to figure out how to do a simple thing but just cannot. It may also be a simple automation that you thought should be integrated into any Jira project yet it seems Atlassian does not agree with that.
Can we handle it?
Yes, there are things that you can’t do in Jira such as calculation of velocity by team vacations, or mixed reports of story points and time estimation combined. yet, in most cases you can extract everything from Jira. You just need to know where to look; As stated on issue #2 above, there are many ways to view issues and there are many ways to find what you are looking for. Even if Jira wasn’t able to provide what you needed, in most cases you can easily find an addon for this purpose.
4. It takes a lot of time to load pages
When working with Jira on a daily basis you may feel that Jira becomes slower over time; It takes more time to load pages and extract queries; Editing issues may take more time to perform and the frustration makes you use Jira less and less.
Can we handle it?
The most common reason for slowing down is too many admin privileges and uncontrolled changes. The first thing you want to do is removing privileges from users that don’t need them. If they need an extended super user then create one but don’t give them admin. The 2nd step is to remove addons that are not in use and make it a difficult process to request more addons. Let good old bureaucracy help you. Next you need to remove and unite as much custom fields as possible. Then do the same with the workflows. In most cases you can use the same workflows and similar fields for at least 80% of your projects.
Jira doesn’t come with a manual for best practices, but still, it is expected from you, as a project manager or as a system administrator to know it all. There is a huge database of answers online, but if you can’t find what you needed, you can always contact an expert. if your team experiences difficulties or you have found other solutions for the mentioned problems, please share with us in the comment section below.
In the last couple of years, I’ve been writing about SAFe on the AgileSparks Blog, providing guidance articles for the SAI, and creating some complementary approaches and services in the SAFe context. All based on experiences in the trenches helping AgileSparks clients achieve agility at scale. I recently created a curated collection of some of my favorites and started to provide copies of this book to participants of my Implementing SAFe and RTE classes.
Here are some of what you might find inside:
How to tell if SAFe is the right move for you
Tips for studying for the SPC exam (relevant for other SAFe classes as well)
Stories about ART leadership teams
A different approach to estimations in SAFe
is SAFe unsafe?
SAFe – A framework or a methodology – and why do we care?
Improving SAFe implementations with Flow metrics
Moving to ACTUAL actual business value when it comes to PI objectives
Applying SAFe in an Agile Marketing context
How to create a workshop for figuring out SAFe implementation strategy
I am now sharing it in ebook form. I hope this is useful to you on your SAFe journey! (Warning – it’s a bit raw at the moment – Consider this an MVP – I’m still considering whether it’s worthwhile editing this into a real mini-book, feedback is welcome on whether that’s a worthy idea…)
The Scrum Master’s’ role has become one of the most important and challenging roles in modern organizations, since they act as the main interface between top management and the teams that actually produce and deliver the company’s value to the customer.
Because of the position as an interface between top management and the teams, the SM’s professionalism has actual impact on the team’s performance and on the actual value the organization is able to deliver.
The 3 main aspects of the SM’s roles are:
The SM’s service to the teams
The SM’s service to the Product Owner (PO)
The SM’s service to the company
The SM’s service to the teams
High performing teams are one of the main forces of successful companies, initiating innovation and creating value to the company.
The Self Organization of a team is a major attribute for maximizing this value and the SM’s role is to create the environment, protect and improve this self-organization of the teams.
The SM service to the Product Owner (PO)
As the person accountable for maximizing the value of the product, the PO has a significant impact on the team’s delivery and the product’s quality.
Helping the PO to adopt the Scrum and Agile concepts is an important service that the SM should give the PO. The transparency, refinement of the Product’s Backlog and focus on value- driven development are important aspects of this service.
The SM’s service to the company
The SM as a Change Agent is accountable for ensuring everyone understands Scrum and Scrum values. Understanding and adopting the 5 Scrum Values will Help the SMs to achieve their mission and lead the change in the entire organization.
Understanding the SM role and all the aspect of the services they are required to provide will help improve the SM positioning and leadership in the organization.
Recently, I had the opportunity to work on legacy code with several teams from various organizations. I would like to share my experience.
We usually start by choosing a piece of code that is “painful”: changing frequently and “scary” to touch because of its complexity. We explain that our purpose is to make the code simpler, readable and easy to change. Establishing the motivation for what we do is important!
In essence, the steps we take are:
Use extract method/rename to make the code more readable (specifically applicable for very long methods).
Write and execute the first unit test (that’s usually the toughest part) as described by Michael Feathers.
Add more unit tests until the area you want to refactor is satisfactorily covered.
Refactor to make the code more maintainable (working in very small steps, as described by Joshua Kerievsky).
Make the required change using TDD.
The purpose of (1) is to see the forest, not the trees. Long methods tend to be unreadable. Using “extract method” helps you see clearly what’s going on. Once you gain vision, you can start to rename. Arlo Belshee talks about this.
As an example, look at these two statements:
At the first if statement, we have extracted the condition to a method. Remember that what you do most of the time with code is reading it. You need to make it readable.
Item (2), as mentioned above, is the difficult part. You need both to master the technique and have the resolution to do it. I usually do it with the entire team and so, together, we have the required courage.
For instance, take a look at this behemoth method.
Pure fun, eh? This is something I call an amusement park methods. We usually start by trying to call it with nulls. Sometimes it actually works and we have a first unit test. Then we start to slowly fill in the parameters. Maybe instead of a null send an empty dictionary. Maybe instead of an empty dictionary send a dictionary with two entries. And if there’s no choice sometimes we run the actual application and serialize the parameters, to be deserialized in the unit test later.
Sometimes we change a method from private to public, sometimes we add a method to better control a member, and there are more vicious things we do. Sometimes it can take a whole morning to do this. However once you understand this, it becomes very simple.
Then you start looking at coverage.
Once you have the first test, things start to move faster (3). You start adding more and more tests. You start looking at coverage reports to see which lines of code are covered and which aren’t. If something is not covered, you can add another unit test to cover it.
Now (4) we can start to make bigger changes. Once you have the unit tests in place you feel free. You make a small change, you run the test. Another small step and the tests run again. Some IDEs have plug-ins that run the tests every time something is changed.
This is the time to get better familiar with the automatic refactoring tools of your IDE. Make sure you are familiar with introduce parameter, field, variable. Extract class is a very nice one and so is the ability to convert a method to static and move a method. The trick here is to make as fewer manual changes as possible and move the code around fluently.
Many times by this point, there is a small disappointment. The code you feared in the morning now looks quite simple. The real challenge is making the code simple, solving the puzzle.
Now we reached the point when we can quite easily add some code to fulfill a new requirement (5). We can add a new test, see it fail, make the required change, see it pass and maybe do a little refactoring. Nothing like the joy of seeing unit tests turn from red to green.
(the above are unit tests from a very nice exercise called Gilded Rose)
What is the connection between Uncertainty and the Scaled Agile Framework?
Uncertainty is one of the core reasons we need to be agile. Different modes of Business/Requirements/Technology uncertainties impact our economic costs in product development – especially the potential impact of risk. The first principle of SAFe™ is “Take an economic view”. I frequently use my “uncertainty filter glasses” to take an alternative economic view. I find it helps Scaled Agile/SAFe™ practitioners/leaders understand both the need for Agility as well as examine various work system design considerations. In this article I introduce the Stacey Matrix which is one of my favorite models for understanding the uncertainty landscape as well as implications of uncertainty on various specific SAFe™ design decisions.
Making it Concrete – The Stacey Uncertainty Matrix and its relation to the Scaled Agile Framework
As I wrote about at some length in Risk-Aware Product Development (a.k.a Agile) explaining the concept of Requirement/Business/Technology uncertainty is one of the first things I do with most audiences I meet for the first time. On a Leading SAFe/SPC class this typically takes place in the first module when we go over the need for SAFe. This is not a core part of the materials but I take the time to explain it anyhow and then find myself referring back to it throughout the workshop.
The first layer of realization is that our problem with the classic approaches to product development is that they were built for complicated endeavors but not complex ones.
Then we layer on more interesting realizations like the fact that for some endeavors like those approaching the “Anarchy”/”Chaos” domains probably the best approach would be a “Skunkworks” style cross-functional co-located fully empowered small team. As you grow a bit farther from Anarchy you can scale agility using an approach like the Scaled Agile Framework. At these levels of uncertainty/risk the trade-off of distributed teams, distributed PI Planning, system team, component teams, shared architects/UX MIGHT make sense and are worth considering.
As you approach the simpler domain sometimes even the alignment rationale for “whole train” PI Planning can be reconsidered. Is that SAFe™ heresy? maybe. But I find that telling people “Whole ART PI Planning” is mandatory is less effective than showing them WHEN it has a better economic impact. (BTW as you grow in complexity/uncertainty you also need better people that are more engaged – which the Whole ART PI Planning helps with as well)
In general, this thinking helps leaders at these workshops grasp the various economic levers that go into tailoring a SAFe™ implementation. I find this disarms some of the resistance you get when people feel something is “a must”. Using this approach they typically go out with a stronger conviction to avoid some compromises and a better feeling about the compromises that do make sense.
To take another example of how I use the uncertainty matrix during SAFe™ training/implementation discussions – SAFe™ talks about a hierarchy between ART Product Management and the Product Owners working with the teams. A typical and sensible question people have is “Who should wear the Product Owner hat?”. Using the uncertainty matrix, we realize that in some cases the Product Owner should be a Product Manager (probably the top two quadrants of the matrix) and in some other cases he can also be a more technical leader (Especially on the far right side of the matrix). As the typical organization I work with is struggling to fill those Product Owner roles, this realization helps them deploy their people more effectively in a way that minimizes the risk of ineffective feedback loops due to the wrong individuals being in the tight Product Owner loop.
Understanding uncertainty and its attributes and implications is in my view and experience a critical step of buying into the need for agile as well as gaining the ability to design an effective agile approach for your context. Presenting the Stacey Matrix and trying to map it to your reality is one technique I used to help people gain this understanding. Using it as a decision filter/design criteria for further SAFe™ tailoring questions complements this initial presentation/exposure and grounds it. If you are teaching Leading SAFe™/SPC classes, explaining the need for agile to leaders/executives, or working with an organization to implement a scaled agile approach, I believe you will see improved results if you add this technique to your toolbox. I know I have.
Last week I facilitated a 2-day Agile Marketing workshop for one of my clients. As usual, the discussion about the Marketing Backlog and how to move from a big bang marketing campaign to a more iterative approach via smaller slices of stories was one of the highlights.
As usual, I introduce the concept of User Stories which are the most popular way to represent Product Backlog Items (PBIs) in the Agile world and are also very popular in the Agile Marketing space. We looked at some awful examples of stories, such as “As a marketer I want to install Drift on my site” or “As a user I want to see a webinar” and then moved to stories that provide more insights about a real user (e.g. “As a VP Marketing focused on Demand Generation”) and their intent (e.g. “so that I could get more demand generated from people who hate forms and lead magnet registration-walls“)
We then broke out into multiple teams each taking an actual campaign/project they’re planning for 2019 and creating the Marketing Backlog for it.
User Stories belong in Product Backlogs (Not Marketing Backlogs)
One thing we quickly noticed was that the User Story format and perspective was confusing some of the teams. Their stories talked about their product benefits and were very similar to stories you’d expect to see in a Product Backlog rather than a Marketing Backlog.
What’s the problem you ask? Well, the Marketing Backlog ISN’T a Product Backlog. The Product Backlog reflects everything that is known to be needed in the product.
The Marketing Backlog reflects everything that is known to be needed for marketing the product/service.
What’s the problem with User Stories?
Ok, so the Marketing Backlog talks about marketing. What’s wrong with using User Stories to reflect Marketing Backlog Items (MBIs)?
Until recently, I didn’t think there was a problem. But last week’s discussions convinced me that talking about Users isn’t serving us well. It gets Marketers thinking about the product/service benefits and not about the customer/buyer journey and how they want to influence it – which is what we want the marketing stories to be about!
Buyer Stories For The Rescue?
One tweak we used in the workshop which helped the marketers think about the right things is a switch from User Stories to Buyer Stories. These stories talk about the buyer’s journey and his/her perspective.
The format of Buyer Stories is still very similar “As a buyer I want to perform some activity so that some buyer journey goal”. Buyer reflects a specific persona going through the buyer/customer journey. the activity typically relates to research, consideration, comparing vendors, learning, pitching internally, checking social proof and the like.
The goal is a tricky one. Is it to solve the business problem and if so is it similar to the goal of the product/service we’re marketing? Is it to streamline my “job” as a buyer and minimize the risk I’m choosing the wrong product/service or taking too long to decide? I’m looking forward to experimenting with this a bit more in the trenches and see what makes sense.
Map the Journey with Story Mapping
Story Mapping, created and popularized by Jeff Patton, is one of my favorite techniques for working with agile backlogs. (Yael, my colleague, wrote about it in our blog a while ago). Story Mapping is a perfect fit when you’re trying to break a big marketing campaign/play into smaller slices. You look at the different stages of your buyer’s journey and then break down the big campaign/play into small pieces that fit into the different stages of the journey.
From Buyer to Buyers (a.k.a Account-based Marketing) with Impact Mapping
Many marketers in the B2B or enterprise space are dealing with multiple buyers with different needs and jobs they’re trying to do. A technique that can help map what kind of impact they’re trying to have on the different players (or what kind of impact these players are trying to achieve) is Impact Mapping, created by Gojko Adzic. This technique can then help marketers identify the marketing deliverables that these players would need to achieve the desired impact on the purchase. This is another great way to refine a marketing backlog and emphasize that we’re interested in the impact on the purchase/buying journey rather than the impact that the product/service will itself have on the business.
Sometimes a Buyer Story IS a User Story
There can be an overlap when there are product capabilities that are needed in order to effectively market the product. Think “freemium version” or some other product/service capabilities that are requested by the marketers. But note these should be the result of identifying gaps/bottlenecks/weak spots in the way the funnel operates, not based on features asked for by customers or prospects.
YMMV – Inspect and Adapt what to put in your Marketing Backlog
This blog provides an example of how Agile Marketing isn’t exactly like Agile Development. If you are a marketer looking at Agile or you’re coming from the Product/Technology world and you’re helping marketers understand Agile and Scrum that’s something that is important to remember.
Yes, we’re still talking about empiricism, Sprints, Increments, timeboxes and Scrum Teams. But some areas like the definition of the “Product” are different.
Luckily though, User Stories aren’t mandatory in Agile. They’re a complementary practice. Use them if they make sense. Use something else if it’s better. Mainly – experiment with something and remember to inspect how it’s going and adapt if needed.
SAFe includes Scrum – so how come many Scrum practitioners and thought leaders consider it unsafe?
The Scaled Agile Framework (SAFe) is one of the most popular approaches to applying agile at scale out there. SAFe’s perspective is that “Nothing beats an Agile Team” and it doesn’t try to reinvent the wheel or even innovate too much when it comes to the Team level. It takes advantage of established frameworks and techniques that work well – Scrum being the first and foremost of those.
Where it starts to get interesting (unsurprisingly) is when the patterns and practices for scaling are introduced – in SAFe’s Program Level. SAFe’s premise is that in the real world one team typically isn’t enough and several teams need to work in concert to build larger systems/solutions/products. In SAFe’s Program Level, a key piece is the Agile Release Train which is considered a team of Agile teams.
When it comes to the Program level SAFe doesn’t try to reinvent either – but here it uses Scrum/Kanban as a starting point and innovates in order to deal with some specific challenges of larger programs. SAFe also deals with Larger Solutions and the Portfolio, but let’s leave those out of the scope of today’s discussion.
The above intent, together with the fact that SAFe uses the Scrum Guide as its reference to what Scrum is, are encouraging signs. So, again, why do so many Scrum practitioners, trainers, and thought leaders consider it unsafe and a Scrum-but? I hear a lot of questions and claims. Let’s try to recreate some of these discussions and along the way make some recommendations?
Looks like SAFe’s Scrum Master is a coordinator and focal point for the team – not just a servant leader and coach accountable to enacting Scrum.
Yep. SAFe’s Scrum Master is more of an Agile Team Lead. This is much easier to implement in the real world but also means it will be much harder for the team to self-organize because they have a team lead that isn’t just focused on helping them improve via Scrum but is also their focal point for Scrum of Scrums, during PI Planning, etc.
The way I look at it – this is indeed a compromise that SAFe practitioners should be aware of. And part of the journey of implementing SAFe should be to maybe start with this Scrum Master stance but evolve towards more of the classic, professional Scrum Master stance over time. To use the leadership styles model we discuss in the Leading SAFe class – the starting point is more of an orchestrating and technical expert kind of leadership stance and the goal should be to evolve towards a more serving the team and the process style over time.
The main concern I have is not that SAFe’s Scrum Master is different than how Scrum defines it. It’s that this difference isn’t made transparent – which doesn’t give practitioners the opportunity to inspect, think about it, and maybe adapt. Maybe your organization is actually better off with an Agile Team Lead than a Scrum Master. But you won’t have a chance to think about it and decide if you think you already have Scrum Masters.
SAFe’s Product Owner is a proxy, not a real Product Owner. They are more similar to a team member focusing on the stories than a person accountable to optimizing value delivered by a Product.
SAFe’s approach to product ownership is that scale is achieved by splitting the product ownership role between Product Management, which is more like the classic Scrum Product Owner, and the Product Owner, which is indeed more like a proxy or technical product owner working more closely with teams. One of the main reasons SAFe takes this path is that it’s hard for one Product Owner to deal with too many teams while balancing both outbound and inbound activities.
Large Scale Scrum and Nexus prefer to have one Product Owner for the entire product with one Product Backlog. In real life, these Product Owners are typically accountable to the value delivered by these multiple teams and rely upon a lot of assistance from the Development Teams in order to deal with the challenge of scale.
If we ignore the differences in lingo, This is quite similar to SAFe’s approach. But we can’t ignore the differences in lingo. We DO want to see Product Owners as individuals owning products and being accountable to optimizing value.
What I’ve seen in the trenches ranges from SAFe Product Owners that really own a product within the bigger solution, own a set of features or even a specific feature that is currently being developed, all the way to technical product owners that aren’t real product owners. There’s definitely room for more discussion of this continuum and the impact of it in the SAFe PO/PM body of knowledge (Similarly to the discussion of the Feature/Component team continuum).
Scrum is a simple framework that deals with complex domains. SAFe seems more of a methodology to Scrum practitioners as it has many more details and seems to try to solve all challenges in a prescribed way. SAFe’s creators seem to enjoy the fact that it is complicated since it provides an excuse for more and more training possibilities.
Well, the reality is that SAFe serves the mainstream market of practitioners that struggle to get from Scrum’s simple framework to an approach that works in their reality. Scrum simply doesn’t provide enough answers to some of the tough scaling challenges, and not everybody has the time or skills to come up with an approach that works in their context. This market needs some more guidance.
Looking at SAFe as it grows over time I see a constant struggle between the desire and drive to simplify and focus on the essentials to the desire to give more answers. Like any other product, it is tough to figure out which features/aspects to build, get rid of, simplify, and how to optimize the experience. It’s hard to create the ideal scaling framework.
Beyond how SAFe is defined, there’s also how people perceive it. And yes lots of practitioners prefer to see it as a Methodology rather than a framework. As someone teaching SAFe Program Consultants, I try to discuss it in my classes. (See a recent blog post I wrote about this)
SAFe’s Sprints are 3 months long and are planned in detail – How is that Agile?
Well, let’s unpack this. SAFe has a cadence at the Team and Program levels. The team-level cadence is called Iterations but other than that different name is almost identical to the Scrum Sprint. It is 2 weeks long, the goal is to deliver a potentially releasable increment of working software, There’s Iteration Planning, Daily Standup (which is essentially Daily Scrum), Iteration Review and Retrospective.
I’m guessing the confusion kicks in when people look at the Program Increment. That’s typically 8-12 weeks long and includes multiple Iterations (4-6 typically). Why don’t we just have a Program Increment that is at the same length of the team-level increment? Because from an economic perspective the transaction/coordination costs for running the whole program on a 2-week cycle don’t make sense. Think about having big room planning with 100 practitioners every two weeks. Kind of hard.
Why do we even need this big room planning in the first place? Now that’s another question. In situations where teams do have some dependencies, when we need a longer horizon business planning and we do want to involve everyone in having discussions about what is valuable, realistic, and converge on plans, big room planning comes to the rescue. Do we have to have these discussions every two weeks? probably not.
So the approach SAFe takes is to look at each one of the program-level activities and consider both the coordination cost/overhead as well as the holding cost or cost of delay and come up with the right frequency. For example, while Program Increment Planning happens only at the Program Increment cadence, System Demo, which is similar to the Sprint Review but at the program level, happens on the iteration cadence so every two weeks typically. Why? Because the cost of delayed empiric feedback is very high and we understand we live in an uncertain environment, we assume variability and we want to preserve the option to adjust course throughout the PI.
This is similar to the Scrum Planning Onion. Teams and Agile Release Trains plan at the Daily, Iteration, and Program Increment levels. The deeper in the onion we are the more detailed we plan, but the shorter our planning horizon. So in Program Increment (PI) Planning we should plan for a longer horizon but at a much lower level of detail. Do a lot of SAFe practitioners plan the PI in too much detail, not leaving enough room for uncertainty and learning once we get to the Iteration and Daily planning levels? Oh yes. Does a lot of Scrum practitioners do the same thing for the Sprint not leaving enough room for uncertainty and learning throughout the Sprint?
Like the Sprint Goal guides the Dev Team in case they want to consider changing the Sprint Backlog, PI objectives help teams adjust course throughout the PI if it helps them achieve their objectives.
Bottom line, SAFe’s Program Increment and the way you plan it can be closer to “following a plan” or an agile basis for “responding to change”. I certainly see it and teach it as the latter.
SAFe focuses on predictability much more than it does on empiricism and value discovery
SAFe actually tries to balance business agility with predictability. Both of those are important to the typical enterprise-scale technology organization.
SAFe includes mechanisms such as PI Planning, Roadmaps, forecasts, PI Objectives, confidence votes to provide predictability. It includes Stretch PI Objectives, The Innovation and Planning iteration and specific recommendations on how to plan in order to maximize predictability in face of variability and uncertainty.
It also includes System Demos, Continuous Integration, Minimum Viable Products, and others in order to deal better with uncertainty.
And there’s no assumption that predictability will be absolute. A program/ART that achieves 80% predictability is considered within a reasonable range. And this predictability is measured in achieving outcomes, not delivering stories or points. This supports agility of adjusting what features we deliver and how as long as we focus on achieving the outcomes the business is focused on.
SAFe allows you to defer integration and hardening to the end of the Program Increment
Not really. SAFe used to have a Hardening iteration but it’s been decommissioned for years now. The Innovation and Planning iteration is the place to take a breather, do some innovation activities that work better when you can clear your head and focus on them (Which doesn’t mean by the way that innovation isn’t allowed or needed throughout the PI), reflect on the current PI and plan for the next PI. integration and hardening is part of the definition of Done that each team strives for within every 2-week iteration. The System Demo that happens every 2 weeks is an opportunity to review the whole integrated system increment, get transparency for where you are, and inspect and adapt the plan for the rest of the PI accordingly.
What you could do about this as a SAFe practitioner/trainer
I wish more SAFe practitioners would dive deeper into the Scrum world as a step in their life-long learning journey. A self-respecting SPC should also have enough knowledge and experience with Scrum to pass at least some of the Scrum.org assessments. The same applies to people training SPCs. They should have a very strong experience with Scrum and Kanban. An advice to those planning to register to an Implementing SAFe class and become SPCs – verify your SPCT knows his/her Scrum and Kanban. Check if they have a PSM1/2/3.
On an ongoing implementation, one useful thing you could do is run a workshop reflecting on the Scrum Guide and what are some key gaps to consider addressing. I’ve done this in one of my larger financial tech clients and it was a pivot point in the implementation. We looked specifically at the Scrum Master and Product Owner roles, identified a lot of gaps and changed our perspective about these roles.
What you could do about this as a Professional Scrum practitioner/trainer
As an SPC Trainer (SPCT) and a Scrum.org Professional Scrum Trainer (PST) I’m committed to helping people understand and implement SAFe safely. It isn’t the only scaling approach I work with, but a lot of people seek me out when they do want to implement SAFe but want to keep to the true spirit of Agile/Scrum.
I’m glad to see more and more of my colleagues in the professional Scrum.org community that are interested in working towards better understanding of Scrum Theory, Values, Events, Roles and Artifacts in the SAFe world. After all, that’s what it means to be a community that shows respect, openness, and courage.
Since SAFe is so prevalent, I think this is a huge opportunity to improve the profession of software delivery.