Are You Safe With SAFe?
Is SAFe the right framework for my organization? After all, there are numerous other frameworks (Disciplined Agile, Nexus, LeSS, S@S, etc.) that claim to deliver similar results and impart comparable benefits…
This question is at core of our upcoming webinar.
In this session we will turn our focus to the Scaled Agile Framework (SAFe) and how organizations have successfully implemented it. We will provide practical tips and tricks, examples, and approaches to implementing SAFe in a way that ensures the success of your agile transformation.
If you feel a bit concerned about the FUD, join this webinar to hear real life examples, best practices and experiences from the folks who help define SAFe and implement it across multiple verticals.
Transcription
Myriam:
It is with great pleasure that I would like to introduce you to our speaker, Ken France. Ken is currently VP of Scaled Agile Practice at cPrime and was CEO at Blue Agility, now a cPrime company. He has recently achieved the status of SAFe Fellow by Scaled Agile, the highest recognition awarded for knowledge, thought leadership, training excellence and large scale implementations, as well as other achievements in SAFe. He has over 25 years; industry experience in various companies. As a developer, lead consultant, VP and particularly as an executive transformation coach within Fortune 500 organizations, helping them achieve success on their transformational journey. He holds a master’s degree from John Hopkins and as well as a graduate of Ohio State University. And I can tell you that if you ever meet Ken, he is a very avid fan of Ohio State University. Go buckeyes! So without further ado, I’d like to pass the baton over to Ken. So Ken, the floor’s yours.
Ken:
Thanks, Myriam. Let me jump into first having my obligatory Dilbert opening, which, any good presentation in the agile space has. So I figured I’d start with a cartoon. It’s about a guy who shows a cartoon before giving a boring presentation. But it doesn’t work for the audience because the cartoon has no punchline. So, I’m just going to assume that everybody is laughing at my opening Dilbert cartoon. Alright, let’s jump into this. The agenda. So, what we’re going to cover today is some of the things that people are saying about SAFe. Then we’re going to get into really what is SAFe and hit some of the highlights of that for folks on the call that maybe aren’t as familiar as others, but then we’re going to get into the real guts of the presentation on how do you make SAFe, safe, meaning how do you apply it pragmatically and in a way that’s going to give you the benefits of the framework without maybe some side effects that you don’t want to have by trying to implement too much, too fast. So we’ll talk through some examples. I’ll give you an example from a client situation and how we incrementally adopted safe and then I’ll share some parting thoughts and takeaways for you as we go. I do anticipate having some time for questions at the end. So please queue those up to Myriam and I’m looking forward to it.
All right. First let’s talk about what people are saying. So there’s a couple of notable quotes and articles that are out there. One of the first ones that hit the Internet was the boys from RUP, the rational unified process or back. I am actually proud to say that I’m one of those boys. I was at Rational for a long time and just like the rational unified process safe was not meant to be implemented wholesale or taking everything and applying it to every context. So, I can understand some of the perceptions can had about being back and I think again, if you attack it pragmatically, I think that’s okay. But that was one of the early famous quotes from Ken Schwaber. David Anderson chimed in, Kanban, the anti-SAFe for almost a decade already.
So, as David Anderson is the thought leader behind Kanban and really feels like Kanban is the way to go to scale. Ron Jeffries: “I do not like it. It’s fast food you can do better.” So his article was called good but not good enough, so he definitely saw some of the benefits in SAFe, and just felt like we can do better and we definitely agree that you can continue to do better. And so, these articles, as you see from a few years ago and as SAFe has been evolving based on feedback from the market. So, I do believe it’s better at this point than it was back in 2014. Some other more anecdotal comments that are not attributed are, it’s too big. It’s too prescriptive, it’s too complicated. I have a recent client says “in our culture, people will try to follow this step by step without deviation”.
That concerns me, and I could see why that would concern you if you have a culture where if you put something in front of people, they feel like they have to do all of it, then you do have to get them out of that mindset because that is not the intent. And then lastly, it’s all essential. What would you take away? I’m just the mindset that everything’s in there, of course you have to do it and we’re going to try to talk you out of that in this session here. Everything’s in there for a reason and if you’re having the type of problem that would lend itself to that solution, then great use that otherwise implement it more minimalistically. Alright? So those are some of the things that people are saying out there. Let me get a little bit into the basics of SAFe just to provide a grounding for the rest of the presentation for some of the newer folks.
So SAFe is a framework. It is the leading framework for large scale enterprise agility. The key thing about SAFe is that it’s based on a set of proven, integrated principles and practices. So everything that’s in SAFe is in there because it’s been shown to add value in one or more context or by one or more actual customers doing it. It wasn’t a theoretical framework that was put in place to then put out into the market to see if people would use it. It was more, harvesting from the market and harvesting from customers that we’re seeing value in these practices. And so that’s really what SAFe is. It’s a set of proven integrated principles and practices for Lean Agile and DevOps, if you look at it just from a presence in the marketplace are some statistics that were shown at the last SAFe Summit.
And you can see just the number of professionals trained 300,000 number of partners like cPrime, 200 across 50 countries, just the number of 70 percent of the US fortune 100 have adopted it in some form, training available, etc. So these are just some statistics on how the presence that it has in the market. All right? Enough of that marketing stuff, what is SAFe really. And so I can’t talk about SAFe without talking about the principles before the practices. Some folks will look at SAFe, and I probably should’ve put this in the quotes. it’s not agile. It doesn’t really conform to the spirit of the agile manifesto and I would strongly disagree with that. It is fundamentally taking what’s in the manifesto and extending it. The House of lean, taking lean thinking. I’m trying to eliminate waste, which is where the pragmatic, minimalist mindset of implementing SAFe come from. How do you make sure that you have a foundation of leadership, respecting people, recognizing that small pieces of work need to flow through your system, giving time and space for innovation and relentless improvement. Ultimately with the goal of delivering value to the customer. That’s ultimately what we’re trying to do here. And deliver it with a story. Just the shortest sustainable lead time, which is the time that we know about the desire for change and the time that we get it to the customer we want. We want to minimize that time. SAFe has a set of core values, built in quality program execution, alignment, transparency. These are foundational beliefs that really drive what SAFe is and what SAFe does. Think about these four bullets as being the elevator pitch for SAFe as you are explaining what is SAFe trying to achieve.
It’s really building in quality earlier and more often, not just individual teams executing well, but teams of teams or programs as the term is used here, I’m getting alignment from executives. I’m setting direction and funding large initiatives down through the people doing the work and then being very transparent on the challenges we’re having, the truth of where we are and what we need to do to really deliver the value. So all of those things come together. The Agile Manifesto, the house of Lean, the core values of SAFe are reflected in the SAFe/Lean, agile principles, which really is the scaled version of the principles from the manifesto. It is meant to take all of the goodness that comes in all the other methodologies to help individual teams and projects , adopt agile practices and scale them to very large enterprises from taking an economic view, so prioritizing our work, making sure that we get the best economic outcome, looking at the whole so applying systems thinking, not optimizing from the parts for the parts, but for the whole assuming variability and preserving options.
I summarize that as deferring commitment until the last responsible moment. I’m sure you’ve heard that concept in agile. That’s really what that principle says is that we don’t know everything upfront, so let’s defer commitment until we’ve learned enough to do that. Then principle four goes hand in hand with that and says, if we’re going to learn, let’s learn fast with very quick integrated learning cycles. Let’s face the progress. We are making an objective evaluation of working systems. We want to measure our progress. We want to measure that the product is performing well to the customer and we want to improve our process the way we’re doing it, so different ways to measure objectively how we’re proceeding. Principle number six is really about maximizing flow from the house of lean. You’re basically taking variability and trying to limit that variability by managing your work in progress, by reducing your batch sizes, by managing your queue lengths, not letting your backlogs get too large, so all those things are really to help improve flow and then to drive alignment.
One of the core values in applying cadence and synchronization, making sure teams are working on the same cadence and entire teams of teams are working on the same cadence so that we’re coming to the same decision point at the same time and we can make tradeoffs and manage dependencies and do things like that that we need to do by being synchronized and being on the same cadence. We want to recognize that knowledge workers are not always just motivated by money, that they have things that intrinsically motivate them. Like Daniel Pink talking about autonomy, mastery and purpose, those are intrinsic motivations, not driven by money and so we want to make sure we find ways to unlock that intrinsic motivation to get people excited about what they’re doing. And then lastly, we want to decentralize decision making. We want to put the power into the hands of the people to make decisions with local information where it’s best applied.
Now we have to put guard rails and decision making frameworks and have vision and things in place in order to allow decentralized decision making to happen. But a lot of the parts of the framework really address that. So at its core, its principles over practices for SAFe, but obviously you need practices too. So, this is version 4.6 of the framework that was recently released into the market and I’ll just give you a very quick summary of the different parts of SAFe. There’s the team level, which essentially you have what everybody knows, and loves is agile teams working in a Scrum, Kanban or a hybrid type process. Executing their work with user stories and those sprints or through that flow based Kanban system. It’s really what and love. It’s individual agile teams. We then take those individual agile teams and we scale them up to a team of teams construct at the program level known as an agile release train.
So, in this case we’ve got multiple teams and we start taking all of the aspects of Scrum and scaling them up one level and plus some other systems. I’m thinking type constructs. For example, the product owner role scales up to a product manager role to help look at the vision and the future of the product and align with stakeholders and then pass that alignment down to the product owner. The release train engineer. the RTE is really the Uber Scrum Master of the train. I’m making sure that teams of teams are collaborating well and managing dependencies and removing impediments. So that’s a scaling up of the Scrum master role. The systems architect engineer is really the technical authority on the train. Making sure that we put sufficient architectural guard rails in place and guidance for the teams to then emerge their design beneath them. So, this concept of emergent design still exists, but it’s within the construct or the context of intentional architecture from that architect, so really that architect being the technical authority is the scaling up of the Dev team concept from the team level, so we’ve taken the team level roles and scaled them up, but we also take stories and scale them up to features.
Stories as finishing a sprint timebox. Well features finishing what we call a program increment or a Pi Timebox, which is five sprints, so it was taking that same construct of a timebox and work finishing in the timebox and scaling it up one level. And so just the time box itself is scaling it up and then just like we do for individual sprints. We have a sprint planning, we have a daily standup, we have a review and a retro. We’re going to have those same ceremonies at the program level. We’re going to have Pi Planning. At the {Program level, you have a Scrum of Scrums at the program level, which is the equivalent of a daily standup. At the team level, you have a meeting called the Po sync at the program level, which is basically the equivalent of the backlog refinement session.
At the team level you have the inspect and adapt workshop. That’s basically the combination of their demo, the review and the retro, so at the program level you’ve basically taken the concepts of the team Scrum at the team level and scaled it up one level to drive that full release train. You scale up one more time to the large solution level. This is where you’re building really large solutions. Like an example I’ll show you in a second when you have multiple release trains collaborating together, so in this scenario I’ve gotten multiple release trains, but I still follow the same pattern of scaling up Scrum . One more time. I still have those same three roles that are now scaled up across release trains. I still keep the PI timebox because I don’t want to have a larger time box, but now I have this, this piece of work called a capability which breaks down into features across multiple release trains.
Now I’ve gotten multiple release trains within the context of what’s called a solution train at this level, working towards a common solution and then lastly the portfolio level is where we’re setting strategic themes and centralizing the budgeting. The funding for all of this here, we have epics that span PIs so you don’t see a timebox at this portfolio level because Epics can span PIs and Epics. Then decompose into capabilities and features and stories eventually to get the work done. So that is a very quick flyby of the SAFe framework at a very high level. Let me put this in context by an example. So let’s say we had a portfolio that we wanted to colonize space and so when I look at it at the highest level, I’m a in my portfolio. When I have something to get people to space the space shuttle type system, I may need an interim refueling station or something depending on where the destination is, so I’ve got a docking refueling station and then maybe I can envision ultimately a floating city of some sort where people actually will live on a day to day basis.
So, let’s say this is how I envisioned my portfolio eventually. So that’s at the portfolio level. This entire portfolio will eventually deliver these solutions to allow me to colonize space. Well, let’s take one of those things. The space shuttle, okay. Each one of these things could break down into one of these large solution levels where an individual. So for them to build this space shuttle, I may have one large solution for that one. I may have another large solution for the docking station and another large solution for the city. So each one of these could become its own instance of the large solution level, each with their own set of release train supporting it. Okay, so I’ve sort of broken that down one layer. Now let’s take the space shuttle and continue to break it down. In order to build the space shuttle, I need multiple release trains.
I need one that’s going to handle communications. I need one that’s going to handle propulsion and I need one that’s just going to build the actual chassis of the space shuttle. So each one of these could then become its own release train that has to come together to ultimately build this space shuttle. And then if I take one release trains, so I kicked the communications release train and break it down to the different pieces. I may have one working on the displays, one working on the panel up here, one working on the panel down here and while I’m working on this other panel, so I may have individual teams now that breakdown this entire cockpit here into the different components that were required to come together to form that. So, when you look at this, I may have, five to 19 teams down here at this level on one release train.
And then I’ve got 50 to a hundred and 25 people across all those teams, plus these program level roles that forms one release train, and then I may have multiple release trains for this large solution. So you may be talking 500 to a thousand people and then for the whole portfolio you may be talking 2000 and 5,000 people in this scenario because you’re talking a very large portfolio now you’re not. You might be saying to yourself, this is a very large example. This is much bigger than I am and that’s the exact point of this talk is that the framework can scale to something this large or it can be reduced down to smaller for other environments as well. But that just gives you some sense of how this framework might actually come together in that example.
And so, based on that previous example is that it’s not one size fits all. There’s different configurations of SAFe that are available to you. The core configuration is called Essential SAFe. This is basically just a release train. You could just have an environment where you have very small release train, it’s at least a decent number of teams, five or six teams that need to collaborate and manage dependencies. So the train construct makes sense. If you had one or two teams that have to collaborate, you may not need the concept of a release train and maybe too small that you even need to go into essential SAFe. Then you may have portfolio SAFe that will, I don’t really have the solution level where I have trains, but I’ve got a couple of trains and I at least need some guidance over top of them to fund them and to give them epics and to set some direction.
So, I’m just going to put a portfolio level on top of essential SAFe. And that’s my portfolio safe scenario. And then I may also have a scenario where I do have multiple release trains that are coming together for a large solution level, but this may be a government context where the portfolio level is actually being performed by the government customer. Not by my enterprise, so that I may just be operating a large solution SAFe within my enterprise. So, this just gives you an example that there’s, there’s different configurations to apply to different circ stances. So as we head into this next section, we’re going to start talking about how to actually be SAFe and the framework and some different scenarios.
So how do we make it SAFe? So the first thing that I would start with to make any kind of a change safe, whether it’s the SAFe framework or any other framework, is really making sure you make change management a first class citizen. You’re changing for a reason. You have to create the right climate for the change. You have to be able to enable the organization and engage the organization and the change and then you need to be able to implement and sustain the change. So Kotter’s Leading Change book has an approach and a methodology for doing this. There are others as well. I’m not on the firm in my mind, it doesn’t have to be Kotter, but you have to be taking change management seriously and approaching it in that way. So, the message there is the first way to be safe is make sure you’re thinking about change management because the transformation you’re going to be going through is more than just technology and technical stuff.
It’s really about changing people’s mindset. And so you have to make sure change management is important part of it. So the next point is to, don’t fool yourself. meaning you want to make sure that you recognize that it’s a framework, right? And that blind adherence to it, you may end up fooling yourself. So really make sure that you’re treating it as a framework and taking the good parts, the context that you’re operating within is everything, right? Sometimes people will say, well, if I tailor SAFe in this way, is that a good tailoring or a bad tailoring? And my first question is the old classical consultant answer. It depends, right? What is the context that you’re talking about? Why are you thinking about making that change?
Is there some extenuating circ stance with the people or the environment or the technology? Is there some reason why you still thinking about adhering to the core principles? So, the context matters and it’s very important to understand the context. The other thing is certainly the principles you always have to go back to, but at the end of the day, you implement SAFe to get some outcomes, right? Your goal of implementing SAFe is not to conform to the framework. Your goal in implementing Scrum is not to conform to the Scrum framework. It’s to get some kind of outcome for your business. Well, what are those outcomes? Are they outlined in your vision or are you measuring your real outcomes as output? When people look at things like velocity or just look at just philosophy or just your number of releases or just how many features did, we get done or how many stories did we get done.
That’s not the outcome you’re looking for. The outcome you’re looking for is what did those stories and features do for your business, right? Do they make you more money? Did they increase your market share. Did they do something else you were trying to do from a business perspective, not just the act of getting the work done is really what you’re going for, and so just as the getting the work done itself is not the only thing, you’re looking for being, running the perfect Scrum or running the perfect release train is not your goal either. So definitely focus on outcomes, not output and make sure you’re really getting your bang for your buck. The other thing that I want you to realize is that, don’t believe everything you see. The big picture that you see on the framework. It’s a domain model.
It’s not meant to be a process flow, so there may be things in there shown at a certain place or shown in a certain context that are just there to try to communicate the concept to the reader and it doesn’t necessarily mean that it has to be there or that it can only be there. A great example of that is the suppliers, right? When you look at the big picture, the suppliers show up at the large solution level as the conceptual release train and that’s shown there because in a lot of scenarios, like when I talked about the space shuttle, you could really think about different suppliers. Then think back to Apollo 13 in that scene where they were trying to figure out how to get Apollo 13 home and you had Northrop Gr man in there and you had different suppliers in there that had built different parts of that spaceship.
So, in a sense, each one of them could be viewed as operating as their own release train and they own a specific part of the solution that they were delivering. So it’s very common in that large solution environment for the suppliers to show up there, but I’m sure many of you probably operate in environments where suppliers are embedded on individual teams, right? You may have mixed teams with suppliers on teams. So just because suppliers are shown on the big picture at the large solution level doesn’t mean they have to live there. And it doesn’t mean that’s the only place that they live. It’s just where they chose to model it. There’s many other examples like that. For example, the customer is showing up only at the large solution level. If you actually choose the configuration where you hide the large solution level. If you choose essential SAFe portfolio, say the customer will actually move down to the program level just to continue to reinforce that the customer can also show up anywhere in the framework.
So, treat the big picture as a domain model, not a process flow and recognize that the same person could actually fill multiple roles in some contexts is. So look at these as roles, not necessarily people. And really take what you see in the graphic with a grain of salt because it’s not meant to communicate preciseness as some people sometimes read it as. Let me give you an example of how implementing safe and an incremental pragmatic way it could happen in real life. So, this is an example from a financial services train launch the context here. It was a large financial services firm. They were modernizing their retirement systems. They were going to be choosing new platforms and new applications, new methodology. Really, they were getting a lot of feedback from their members that their systems were just too hard to use.
They weren’t stable enough and they just weren’t getting the job done. So they wanted to just revamp the whole system. So their approach was to evaluate and select technologies, for the platform that they were going to try to buy instead of build wherever they could, they wanted to establish that platform and then incrementally start building on top of it, they had an aggressive timeline to meet the business demand that they needed. And so they knew they were going to eventually grow to a pretty large team, so they wanted a framework to help manage the complexity and so they chose SAFe as their framework, mainly because architecture was really treated as a first class citizen in the framework. And this was going to be a very architecturally heavy project. And the big picture provided clarity and allowed leadership to have the comfort level to say yes, right?
And for those of you that are in a position of being a champion or a change agent, that a lot of times the biggest challenge is to just get a yes to start down the path. And so if you can put something in front of them that’s going to get the yes, you’re looking forward to at least get started, that’s a good thing. So that’s what SAFe for this environment is it allowed them to at least get started. And so what happened? So we started into the implementation and we realized that out of the gate we did not have enough work to have an entire release train present. They’re just, we had to make too many technology decisions first before we got to that point. So we adopted an approach called bringing cars onto the train that is not an official safe term.
That’s just what we ended up calling it. So the first car, so basically the first team, we formed a single architecture team with the architect, the system architect as the product owner. We taught them SAFe for Teams, because we knew eventually this was going to be a release train, so we taught them and train them with the knowledge that they were going to be moving into a full SAFe implementation at some point. And so we introduced the epic feature story hierarchy at this time that large solution level didn’t exist and we wouldn’t have needed it anyway. So we introduce features or epics, features and stories. And we basically with this team did three to four sprints as they did their proof of concepts, pick their technology platforms and the least started to form a core platform with that technology. Then we brought a second car onto the train. We basically started the feature team that was an end to end cross functional team that basically started building on top of that platform.
The business was the Product Owner in this case, and we launched them the same way, say for teams and had them run for a couple of sprints, while the first team, the architecture team continues to build out the platform, more will ask more platform got built and we’ve validated some of those decisions with this first team. Then we brought two more teams onboard, so cars three and four came on that started to build more and more onto that platform with business people. As the product owner. we at one point, because at this point we have three. We have four teams now, so we basically just asked one of the Scrum masters to just step up a little bit and start to act like a Release Train Engineer (RTE) across those four teams, there wasn’t a separate RTE in place.
We just had one Scrum Master play that role in addition to their team Scrum Master role and we had one product owner start to act as the product manager role, so starting to see those program level roles and again, car ones that kept building out more of the platform. So, at this point we’ve got three feature teams building on top of a platform, the platform is pretty much been validated. We’re pretty comfortable with the technology decisions that were made and we’re really now ready to start cranking out the features. And so then three more teams were formed, all feature teams and then addition that first team, that car one team that was an architecture team, they also became cross functional, got a business product owner and they became a feature team as well because the platform has been built out enough and by this point there was enough skillset across the other teams that if further platform capabilities were needed that the right team could just take it on and get it done.
And so, at this point we became a full release train. We started doing PI planning and really, we’re operating in that essential SAFe framework, if you will, that I described earlier. And then finally that team one I’m architect that had been the product owner for that first architecture team, took the role as the true program level system architect to continue to guide the technical solution forward from there. So this was a very lightweight incremental approach that ultimately resulted in a release train, but we did it incrementally and pragmatically implementing just enough process, not creating new roles until we needed them and not implementing new processes until we needed them. So this was a very successful approach. And got the team to value very quickly.
So, some other ways besides that example, other ways to be SAFe, so keep the focus. Meaning when you come out of Pi Planning, you spent two days as a release train coming together for Pi Planning and you’ve built this program board that reflects that plan. Don’t walk out of that two day session and ignore the plan and just let things start to happen. Be Very intentional on changing that plan. Track yourself against that plan and your Scrum of Scrums which will happen once to twice a week. So use that plan and intentionally deviate from that, as things change and as you have to get feedback and get concurrence from your product management team to change scope if that’s the right thing to do, but just don’t blindly go do that without that handshake with the product management team. Fill in gaps.
So, like I said earlier, SAFe is framework. The big picture is a domain picture. it’s not a process flow. Every single piece of every single process in the industry is not embedded in there. There may be other techniques such as some of the product agility techniques that our DevJam folks brought in some concepts from Spotify, from other frameworks, bring more and more into the framework that you need to satisfy certain problems that are not solved in the framework today. , build your own playbook on how you’ve implemented the framework and tailored it to make sure it’s safe in your environment. We’ve done that at cPrime with something called BlueKit, which is basically our implementation is how we implement SAFe for our clients in a toolkit that we use for our coaches. Look for ways to optimize over time.
I’m look at a program level Kanban system that’s recommended, look at feature flow and story flow. As the ART matures, are you actually getting flow of these big pieces of work through your system? So use your, Kanban systems, you can use value stream mapping to see what you have, bottlenecks in your processes. All these are different ways to look at SAFe fill in gaps that are there and bring your own spin to things and still conform to the core principles. All right, so a couple of parting thoughts before I opened it up for Q and A. I’m just kind of keeping it real. A fool with a tool is still a fool. So going back to the don’t fool yourself safe as a tool. It’s got lots of other tools inside it, but at the end of the day, it’s a tool and you need to use the right parts of it for the job at hand.
So, don’t try to use the wrench to hammer and a nail if parts of it are too big or too much, then don’t use those parts yet. Wait till you’re ready for those parts or you may never be ready. Okay. Use other. You use the most pragmatic minimal thing that you can to solve the problem you’re having and don’t feel like you have to implement it just because it’s on the framework. So be pragmatic, be realistic about where you are and be authentic and why you’re making changes. And if you’re a leader in the organization, if you’re a change agent, you need to be authentic by actually walking the walk as well and do exactly as you are preaching that others should do. So you have to be in the framework and be a participant yourself. Don’t believe everything you hear or read.
Like I said, there’s a lot of comments out there about SAFe and some of my opening slide that is too big. No, all approaches and frameworks have failures, so to point at a SAFe failure here are safe failure there. I could point out just as many Scrum failures or Kanban failures, there’s lots of reasons that initiatives fail. Blaming the tool that you had. Certainly the tool can have a piece in that, but at the end of the day you have to look at what are the real challenges you’re having and would any framework fail. So don’t throw the baby out with the bathwater because of what you might have heard others experience being the facts are always friendly. Track the data, track baselines of how you were operating before and how you’re operating after that should be true of any new process you implement.
How do what you’re doing is working? What are your measures? And then the case studies out there on the Scaled Agile framework site really show you the successes that people have had using the framework and the last one about those methodology wars. I don’t have a whole lot of patience for them myself. To me we’re all trying to solve the same problems of helping people develop software and systems better. Every framework has its positive aspects and negative aspects. I would love it if as a community we just work together to make them all better and not say, this one’s better than that one, so use this one instead. So to me the methodology wars are not productive but delivering value is. So let’s do that instead. So that is just a little bit of me keeping it real. At this point, we’ll open it up for Q&A. Do we have questions, Myriam?
Myriam:
We actually have quite a few questions. John asks a very good question and one, I know you have extensive experience in .He asks, what are some of the challenges or concerns for enterprises that might be facing using both waterfall and SAFe? Is there a way to kind of optimize how those two approaches can coexist within an organization?
Ken:
Absolutely. So there’s a lot of mixed environments I’ve seen. I don’t think I’ve seen any environment that has gone completely agile, are completely SAFe or any non-waterfall, so you’re always going to have some aspect of waterfall coexisting. So my advice is one, sometimes it’s looked at as too black and white. I’m either doing agile or I’m not doing agile on doing waterfall, all aren’t doing Scrum or Kanban or whatever. So, to me there’s shades of gray there that even waterfall programs can look at the way they’re operating and start to incrementally introduce some concepts to eliminate waste and to produce value faster. So, the first thing I would do is say, don’t try to make it too much of a, of a one and zero us versus them on and off type thing. There’s shades of gray in between a waterfall program, international program, but if you have a waterfall program that’s largely operating in phases with phase gates and something along those lines, really the best thing you can do, and there’s a couple articles out in the website that talk the scaled agile website that talk about this. What you really have to do is established synchronization points between those programs as an agile program. Either using just Scrum or SAFe You’re going to have more flexibility in your plans to adjust plans to accommodate the waterfall schedules and their milestones that are there. So I’m set up those synchronization points and understand where their milestones are and what milestones they have to meet. So, I’d say just be sensitive to that and then invite them to your PI planning session and invite them to some of those program level ceremonies to at least make sure you’re aligned from what you’re trying to go together and then set an integration points, so you don’t have to wait until the end of their milestones. They’re going to have something available to integrate earlier in the process. Get them to agree to have an informal integration point with you and that’s just planted into your spreads. Set a stake in the ground that says on this date were going to integrate these two components and make it happen. So I say the overall messages drive alignment by inviting them to ceremonies, change your plans to adjust to there’s as you can and are able to, but, but really just by working more closely with them. Hopefully over time you’ll do us most as pulled in more and more into working in an agile way, but they may do what, one practice at a time, which is fine.
Myriam:
Okay. Thank you Ken. And we have a whole slew of that came in. So, Thomas asks what would be the minimal number of people you would want optimally to be able to implement at least essential SAFe?
Ken:
50 being the bare minim number of people. Again, that’s a guideline. Again, I would go back to, at what point in time are you having the problems coordinating between these teams, , that you feel like you need to add a little bit more, , process or ceremony or what have you around it to make that, to gain that alignment? So, a lot of it is, when do you start having the problem that too many people are going to cause. And so, like the approach of bringing the cars onto the train, we waited until we saw that, hey, we started to miss friends and we were starting to miss milestones we were trying to deliver because we just had too much coordination involved and we weren’t on the same page with the vision. And so, start incrementally introducing those things.
And just like with the bringing cars onto the trains, to me essential safe is not an all or nothing, do it incrementally, but do it based on real problems you’re having not, hey, we have 50 people, so we have to form a train because that’s what the lowest number is their train. Okay. But even if you had 40 people and you felt like you were having trouble getting them all on the same page, I would, I would say adoptive, very lightweight, , small release train where you may be even do what we did and say the Scrum master is going to act in the RTE role in this product owner is going to act in the PM role and don’t feel like those have to be different people necessarily. , my, my opinion is it’s always easier to add more later. Start Small and see if that solves your problem.
Myriam:
Okay, great. And then we have a question surrounding metrics and we often see. I’d be interested to see what you think about this one. You indicated in the, in the presentation to measure before and after an engagement. And the question is, what if the organization has not measured, don’t measures before the engagement, how would you measure this before you would go into implement SAFe?
Ken:
I would start to collect those measures as soon as possible. At the beginning of the engagement, you may actually experience some improvements that you wouldn’t capture and improvement from a baseline, but you’re never going to measure improvement if you don’t capture some baseline against which to measure. So to me it’s measured something as soon as you can, even if it’s not everything, it’s been my experience that every organization measures something that you can latch onto to show improvement in they may not be the ideal things that you’d love to measure going forward. , so I’d say overall fine, find the valuable something that they measured today and try to show changes to those. And then second, the things that you really know you should be and want to be measuring, get a baseline established as soon as possible, and then be able to show incremental progress from there on both of those.
Myriam:
Okay. Thank you. I hope that answered the question. In Agile, we’re not supposed to talk about roles, Dev, lead versus data, etc. Is that something that’s changed with safe? It sounds like we are to acknowledge the people can do different roles, but isn’t that still emphasizing specific skills?
Ken:
Let me think if I can get that question. So, we’re told not to. can you repeat It, Myriam? I want to make sure. Okay.
Myriam:
One question. So basically, that in agile we don’t talk about specific roles, only the people or the skills that are involved. It sounds like we can acknowledge in SAFe that people can do different roles, but isn’t that in a way still emphasizing the scale? So I guess the relationship between what is involved in a role versus.
Ken:
Yeah, we just talk about a minimal set of roles, product owners, Scrum masters and dev teams. Right. And we certainly talk about what kinds of skills should be in that product owner and Scrum master role as we talk about what kind of skills should be in depth team members, but that obviously that would vary whether that dev team member as a developer or a QA engineer or an analyst of some sort. , so I, I still think you have the same, the same spirit and safe where you have different roles that represent different skill sets of people to fill those roles like a basically the RTE and the release train engineer and the solution train engineer all from a skillset perspective have very similar skill sets to that Scrum master because you’re scaling up that role. So those kinds of people can ultimately through more and more experience and more and more soft skills.
No go up that hierarchy. Same thing on the product owner side, product owner, the product manager to solution manager. All of those are essentially the what and under understanding that comes with business knowledge. So I still think you have the same concept that different roles imply certain skill sets to fill those roles. So that the main point that I was trying to make was that depending on how quickly you’re scaling and then to what scale you are, that you don’t necessarily have to have another version of the roll on top of it. So that, that’s that scrum master. Also planning the RTE role, for example. It’s not like it’s a scrum master also playing the system architect role where there’s very different skill sets involved. It’s more they’re playing the next level roll up in the scaling framework than the role they are, which is essentially I’m doubling down on their skills in that role already.
So, I didn’t, I didn’t mean to imply that we’re, we’re kind of changing that mindset. It’s really the same mindset. It’s just that there’s now more roles that are defined than just the three that are on a Scrum team. Even though those roles that are defined above, kind of inherit a lot of those characteristics from those lower ones. It’s still meant to be the mindset of certain roles equate to certain characters, certain skillsets, want to find the right people for those roles. But recognize that depending on the person that may exhibit multiple skillsets, they could play multiple roles in some cases.
Continuation of that. We have a couple of questions that are related to careers in SAFe. And so, Katherine and Aatish ask, what are some of the best ways that you can contemplate getting hired in a SAFe role with backgrounds such as IT, project management, quality assurance, and have some of the SAFe certifications. What are some of the skills and/or the strategies that they can look into to get hired into those SAFe positions?
First, let me preface my answer that there are more roles that are involved in a large scale SAFe implementation than what you see show up on the big picture. A lot of folks think, hey, if I don’t see my role in the big picture, I must not exist in the framework. Now the project manager as a great example, you don’t see any role on the big picture called a project manager. You don’t see any role called a development manager or a QA manager or anything like that. But these roles are all recognized and exist and enterprises, they just hold different responsibilities than those that are shown in that domain diagram that I talked about before. So to me, to be successful with a career in SAFe, one of the misconceptions I think is that I’ve got to forget everything I know about developing large scale software and systems today and learn a completely different thing in the SAFe environment.
And while certainly yes, you’re going to learn new concepts and new techniques, a lot of the foundational skills and knowledge that you have are very, very transferable. And so, the advice that I would give is to really get knowledgeable in the framework, get a certification, ideally your SPC certification that makes you as a designation of your knowledge of the framework and how to implement it. And then based on what your core competency is, work with the organization to find the right home for you. Some people that were in that classic project management role, if they exhibit the right mindset and the right way to evolve, they can become the Scrum Master or the release train engineer or the solution train engineer depending on the level that you were.
They could also start to drive the organization towards that better metrics measurement model we talked about earlier where we need people that can bridge the gap between how we measure and assess today and how we want to do that in the agile world. So someone that really understands how people were looking at metrics and understanding the way the system was progressing today, who better than, than them that understand the old world to help move people into the new world, into the new set of metrics. So, I’ve seen organizations where project managers and the PMO are really focused on that transition. Others will focus on helping agile contracts get put in place. So as we’re engaging our contractors, we’re not trying to engage them and fixed price, fixed milestone contracts and then asking them to be agile in our agile team. So we have to evolve that.
So, when you look at the transformation from a big picture, there’s lots of roles that are needed to move the organization along that path, not just the roles that you see on the big picture. So, don’t constrain yourself saying, I have to make myself, somebody on that big picture when there’s lots of other roles that are out there that are valuable and supported by like business analysts, for example. You don’t see business analysts on the big picture either, but they exist at all levels of the framework to help define the work and understand the work and get it created in the proper way. So to me, the first thing is an open mind. The second thing is get knowledge of the framework and get yourself a certification. And then third is work with the organization to align your passion with the roles that exist there and find the right home.
Myriam:
Great. Thank you. And then we have a question from Karen, she asked is SAFe only implemented in the IT realm or can it be implemented in other areas of an organization beyond IT?
Ken:
SAFe is absolutely not just for IT, it is meant to be used across the board by all parts of the organization that have a stake in what the business is doing as those outcomes that I talked about. So yeah, certain aspects of the framework are going to be used more heavily and in the IT technical side, like some of the technical practices and built-in quality, but there’s parts of the organization that have nothing to do with technology that needs to be involved in the framework to be setting those business outcomes. We need to define now what do we need to be doing in the market to be competitive. I’m not even just from a technology perspective. So the whole idea of the framework is in order for it to truly be successful, all parts of the business need to come together and participate in to contribute.
Ultimately, if it’s the technology change that’s needed, yes, the IT organization is going to build and deploy that and try to do that as fast and as high quality as possible, but there’s many parts of the organizations that need to change outside of technology to change business processes, to change the way we market, to change the way we sell, to change the way we price to change the many things about it. So not only should all parts of the organization be participating in the process, but then they themselves internally can use some of the constructs themselves. As an example, we as a consulting company, well we don’t build technology products–or in some cases, we have some of that–but we as a general role, we’re more of a consulting company, right? We still use aspects of the SAFe framework internally to help plan and make sure that we’re aligned on what our priorities are and where we’re heading. So we don’t have to be building software to use some of the valuable parts on the planning and collaboration side of the framework. And the same could be true in your non-technical organizations, what parts of the framework can you use to drive planning and track work internally and make sure that you’re prioritizing your activities and maybe use the time boxes as forcing functions to get marketing plans out or things like that. So the overall message is all parts need to come together in their appropriate role to drive your business outcomes, but then leverage the framework yourself internal to your parts of the organizations to help improve efficiency as you can.
Myriam:
Okay. Thank you, Ken. And then we have two last comments. So Jeff, who’s a 14 year veteran of the agile industry said that he had been curious but skeptical about SAFe and that your explanations were enlightening. So, he wanted to thank you for that. And we hope that at least most of you felt that that was the case. And then Asita asks a question. And Ken, I’m going to throw that one kind of back to you and commend you on that because it seems we have some interest. So Asita says, when is your next webinar? So while we say our farewell, thank you for committing him, if you’re interested in a particular topic, please add it in the questions pane or you can reach out directly to me or Ken, ken.france@cprime.com or myriam.sanie@cprime.com.
And our time together has now come to an end. And once again, I’d like to thank Ken for really providing us some great insights on how we can stay safe in our implementation of SAFe and how to avoid some of the pitfalls that organizations may encounter and also how to get launched and SAFe. And of course, we’d like to thank all of you very much for taking the time out of your day to day to join us and we really hope that you found this session of value. As I mentioned earlier, we will be sending out the recording of the presentation as well as the slides and so be on the lookout for that. And we really hope to see you again on one of our future webinars and we appreciate your time and hope you enjoy the rest of your day. Thanks, everyone.
Ken:
Thank you. Thanks for that comment, Jeff. Appreciate it.
