How to ‘purchase’ Coaching\Training\Consulting Services

With over 20 years consulting experience and nearly 30 years in the IT industry, it still amazes me how some companies (both clients and consultants) negotiate and manage their business dealings.   Far too often a ‘one size fits all’ solution is foisted by a consulting firm onto a ‘get the lowest price’ focused client.  Professonally, Silicon Prairie Solutions is a strong advocate that the Agile{Lean coaching\training\consulting industries need to collectively raise the bar.  Collectively, the industry places too much emphasis on certifications and staffing fulfilment that we lose sight of providing real value to our clients.

On the other side of the relationship, far too many businesses look at Agile | Lean coaching\training\consulting as a fungible service where every firm is the same and therefore the smartest think they can do is look for the lowest cost provider.  While controlling costs is absolutely a critical business activity, it can be short sighted when looking for an Agile | Lean partner.  The reason for this is rooted in the facets of the underlying problems and the nature of the consultant-client relationship.

Typically, the clients in these situations have some or all of the following challenges:

  • Different parts of the organization have different skill levels and needs with respect to training and coaching. Some areas may need a lot, others not so much.
  • There are different ‘levels’ of the organization that will need coaching and training. While it would be nice if Agile | Lean principles and practices were a team only endeavour, the managers, leaders and stakeholders at the program and portfolio levels of the organization also require some coaching and training to make any changes sustainable.
  • Every client has a different definition of success. There may be similarities between organizations, but in the end, the true definition of what success looks like is unique.

Since each situation is different (and indeed also ever changing) it’s impossible for a ‘one size fits all solution’ to exist.  Having established that, it’s a fair question for a client consumer to ask, “What should we consider when looking to purchase Agile | Lean coaching\training\consulting services?”  I won’t attempt to provide an exhaustive answer here, but I will provide five things that I think are important to consider.

  • When looking for Agile | Lean services, remember that it is an investment not simply an expense.
    • You need to know:
      • what the problem you are trying to solve is
      • the definition of success for the relationship
      • how will you measure the impact\value of the relationship (money generated, time saved, defects reduced, etc.)
      • how much money and time are you willing to commit to the investment
    • Time and material agreements are better than fixed cost. With a fixed cost agreement, one party usually assume the risk involved (e.g. changes in scope or delivery).  This is usually the consultant and for this they charge a premium.
    • How and when will mutual feedback be managed. This involves having the crucial conversations that exist in every relationship.  Make sure that these are not hidden behind an ineffective dash board or emailed status report.  Again, these artefacts are useful, they just shouldn’t take the place of real collaboration and discussion.
    • What don’t you know that you don’t know? This point is giving a nod to the fact that often organizations are looking to hire expertise that they don’t have.  It stands to reason therefore that the client organization probably has some gaps in their knowledge and understanding of what a solution might be.
    • Most importantly, is the relationship between your organization and the client built on a foundation of mutual respect. All of our successful transformations had one common element between them.  The relationships were based on transparency, trust and mutual respect.  If you have this as the foundation for your working agreements, all of the challenges that arise can be much more effectively managed.

This short list assumes that the traditional factors that are usually considered (competency, experience, references, insurance, etc.) are already established or will be as part of the evaluation process.    It’s a lot more work than simply finding the lowest cost provide, but like any investment, you get out what you put into it.   Please feel free to connect with us if you’d like to learn more.

Reflecting on Kotter’s Model for Organizational Change by Leveraging the Scaled Agile Framework

In his book, “Leading Change” (, John P Kotter describes a series of steps that he recommends can help leaders that are introducing and shepherding organizational change.  While these actions don’t guarantee as successful evolution (no such universal assurance exists), I have found that understanding and utilizing the actions has been extremely useful in the transformations that Silicon Prairie Solutions has been involved with.  If fact, when we find organizations that are are struggling to incorporate a new way of thinking and working (as is the case when introducing a model like the Scaled Agile Framework) the root cause of the challenges can often be found in the absence of one of Kotter’s recommended points.

Kotter’s steps are as follows:

  1. Establish a sense of urgency
  2. Build a guiding coalition
  3. Develop the vision and strategy
  4. Communicate the vision
  5. Empower employees for broad based action
  6. Generate short term wins
  7. Consolidate gains and produce more wins
  8. Anchor approaches in the new culture

The usefulness of a model like the Scaled Agile Framework  (  cannot be denied. It provides clarity on roles, responsibilities, ceremonies and artifacts that are crucial when changing a large system.  However, the model alone is not enough.  Understanding ‘how’ the model can be incorporated and getting some assistance in ‘doing’ the change related work is as equally critical.    

Silicon Prairie Solutions is creating a downloadable PDF that will offer some insights to each of these steps, some specific actions and reflections on each that will be made available to our visitors.  

The difference between ‘doing’ agile and ‘being’ Agile

One does not have to go far to find companies struggling with realizing the anticipated benefits of agile delivery.  Go to a conference, meetup or even a networking event (whether the theme is agile or not) and you’re likely to hear statements like:

“We’re trying to do agile, but we’re not getting anywhere…”  or “We’ve been using Scrum for six months now and it seems that we’re still struggling with the same problems.  We can’t get anything done…”

From a systems view, these statements are not surprising at all.  In fact they are expected, depending on the organization and their approach to the principles and practices.  In simple terms they are expecting Agile (big A) results with an agile (little a) investment.  Let me explain the difference between the two.

  • Agile is a proper noun. A mindset, philosophy and approach.  You don’t do Agile, you become Agile over time by changing the way you approach work, people, problems etc.  It has more to do with who you are than what you do.  It is a journey, not a destination.  This is what delivers the much touted benefits
  • agile is an adjective.  It describes nouns (events, ceremonies, roles, etc) associated with things that result from an Agile mindset.   These things are done in support of becoming Agile.

The point is that a lot of companies believe that they can ‘do’ Scrum, or some other process and that will make them more collaborative, produce more value and achieve higher quality; just some of the benefits of an Agile mindset.  While adopting these practices can certainly help start the journey, it takes more than just training, understanding and following a set of practices to become Agile.   Agile is not something that is applied to a team, division or organization.   If you do agile things but don’t support them with an Agile mindset friction, frustration, confusion, waste etc. result.  (See “We’re trying to do agile, but we’re not getting anywhere…”)

It takes real change for most companies to become Agile.  Often times they don’t have an Agile mindset.  Their management, HR structure, physical work spaces, titles and sometimes even identity are rooted in the current mindset.  (Think about your organization and how important your title or HR code is to what you earn and do.)    Thus the ability to develop one is rooted in changing their culture.  This is more involved than just introducing an agile process like Scrum.

To address the question “Why we are struggling with agile?”  is usually best answered with the a conversation around “How do we become more Agile?”

The Power of Process…


It happens frequently, but it never gets old.  Recently as part of a post training coaching session one of the senior leaders of a client organization said after a day of working with the team, “We’ve gotten more done in the last six hours than we did in the last two months….”  She was working on the same project, with the same people in the same company.  The only difference was that we helped them define, establish and follow a common process for doing the work.

This is a common experience our coaches have with our clients.  W. Edwards Deming put it this way “If you can’t describe what you are doing as a process, you don’t know what you’re doing.

We regularly come across teams and organizations that believe they have a process and that everyone understands the process.  Yet when we start asking some questions it quickly becomes apparent

  • They don’t really have a process
  • They have a series of activities that people do, but the order is not clearly called our and the roles and responsibilities are not defined and/or followed
  • Or worst of all, they have a process with roles and responsibilities, but only a few people know what it is (and it’s rarely the people doing the work). I’m looking at you PMO’s of the world…

That’s why Scrum and Agile are so powerful and have become best practices for organizing teams.  Scrum is a process that is easy to understand, has only a few roles to be filled (Scrum Master, Product Owner, Team Member) and helps people organize around what is most important, THE WORK!  That’s why it’s so important your team’s process matches your organization and why investing in a couple of days of continued education (training) is as close to a sure thing as you can get in this ever changing market.

How about your team?  Can everyone on your team describe what your process is?  Is it a consistent definition?

Systems Thinking and SAFe – Supporting the Framework


Jesse Fewell: Hi everybody. Jesse Fewell here with a special edition of Morning Fewell. Here with Martin Olson at Scaled Agile Framework SPC class. I got to tell you, I’m having a blast. For the last few days, we’ve been talking about how do we take these agile ideas and deploy them at a large organization. We’re actually here in the classroom so you guys are getting a first view glimpse of things.


You brought a refreshingly, unexpected, additional perspective on this, that we have the safe model and it’s on its fourth iteration now here in early 2016. Which is excellent, right? It shows inspecting and adapting. You’re bringing an additional perspective on this with systems coaching. Tell us, what is systems coaching?


Martin Olson: The notion of systems coaching is that when you have a group of people that are working together, they’re dependent upon each other for whatever that deliver is. A baseball team is a system. A [inaudible 00:01:06] is a system. An organization is a system. That system has its own intelligence, its own energy, its own needs so when you’re bringing safe into an organization, you’re altering the system. You’re bringing practices. You’re bringing new learnings. You’re bringing new information into the system and as such, you need to be aware that you’re changing the system.


It’s not just the application of a bunch of practices and principals. It’s the application of a bunch of practices and principals in an existing system that will impact the system and you have to understand what that impact is. You also have to make sure that, that impact sustains the system. If it doesn’t, the systems smart, it’s going to reject it.


Jesse Fewell: How do we guide the system to accept these strange new practices. These strange new philosophies and mind sets?


Martin Olson: That’s just it. How strange are they? If the gaps too far, they can’t do it. You have to meet the system where it’s at and you have to say, “Hey, at the end of the day, this is really good stuff. We’ve got teams. We’ve got this program guidance and everything else.” We can do teams and we can do program guidance and that’s not going to be the full implementation of safe. That might be to the points of, we can’t, maybe, do [crosstalk 00:02:18].


Jesse Fewell: For that group that’s not ready for the full monty.


Martin Olson: Right.


Jesse Fewell: If they’re not ready for the full monty …


Martin Olson: You’ve got a journey. It’s not, “Hey, go do the training and now walk away and do this.” That is a model that can work if it fits culturally. There’s a couple of things here I want to be very clear about. One, doing the class is awesome. I enjoy it and, again, I would say that over the last four days, you’ve gotten a pretty good understanding and maybe new learnings on and the model. It’s not a flawed model. It works. Again, I think large scale [inaudible 00:02:50] will work. I’m not versed in those models. I think the models good.


Secondly, you can’t just go do this training if you don’t understand facilitation. If you don’t understand the challenges of change management and you try and implement this, you’re going to have a long day because, in its essence, you’re changing the system. Inherently in that, you’re changing the way people behave and you’re changing something that’s very near and dear to people. Their work, their environment. We’re wired that way. Our satisfaction, our identities are often tied to work.


Jesse Fewell: With that being said, what would you say would be the top one or two hacks or the top one or two recommendations as a coach that you would recommend to someone who wants to implement a scale agile framework safe. One or two or three hacks.


Martin Olson: There not even hacks, they’re called out. Leadership. You’ve got to get leadership that understands what they’re asking. Over manage and under led is the montra. It is. Organizationally, we’re structured the way that we are through mergers and acquisitions and happen stance and traditional … We have to have these silos because they’re easy ways to organize and manage but they’re terrible ways for work to flow.


You have to have a leadership that understands that, an executive leadership. If you don’t have buy-in, with any change initiative, it’s going to get to some level and die out because the people that I’ve asked to change, if they don’t understand what I’m asking to do number one and, number two, the value, the reason why, it’s going to be a challenge.


Jesse Fewell: Number one is leadership.


Martin Olson: Leadership.


Jesse Fewell: Number two, would be …


Martin Olson: Number two is having an understanding of where you are and where you want to go.


Jesse Fewell: Right. You’re as is. You’re too be and all of that.


Martin Olson: Exactly. Where you want to go is probably going to involve some level of safe. Right? If you are using that model or whatever the framework is. You have to understand how you’re organized today, where the system’s at. You have to meet the system where it is at and then, you have to stretch that. You want this change to be sustainable. Everybody wants to set themselves up for success, right? You have to know where the system’s at, you have to meet the system where it’s at and they you move to where you want it to be, eventually.


Jesse Fewell: This has been one of the critique that safe has suffered, which is you see this place mat and you’re just like “Everyone needs to go to that solution.” What you’re saying is, “No, design the end state that fits your specific context.”


Martin Olson: Again, the framework calls out. It’s got nine principals and they’re based on agile [inaudible 00:05:26].


Jesse Fewell: Right.


Martin Olson: Folks that want to poke at it and say that, “I think it’s a misunderstanding.” Again, I would ask you, “You came into the class with that belief that it might be too prescriptive. Do you still hold that?”


Jesse Fewell: No, no.


Martin Olson: Yeah.


Jesse Fewell: It’s been really eye opening especially hearing your voice as a systems coach talking about it. Number one, meet the system where it’s at because they might not be ready to make the big jump all the way over to a certain kind of scaled agile model.


Martin Olson: They may be. Maybe they want to.


Jesse Fewell: Maybe they are.


Martin Olson: If that’s the case, wow, that’s big.


Jesse Fewell: Number two, tailor the end state to the context you’re in.


Martin Olson: Yes.


Jesse Fewell: It’s visualized best in this new [crosstalk 00:06:09] where you collapse and entire layer.


Martin Olson: Yeah, if you don’t need it. If you don’t need it. You have to know where you’re going. You have to then support that. Hack number 3, don’t assume you send people to the world. Don’t assume you send people to a class and they’re immediately a process coach and they can do that on top of their job. You have to decide if they’re working in the system or they’re working on the system when you’re doing change management. You can have people that do both, right?


Jesse Fewell: Yeah.


Martin Olson: It’s a full time gig working on the system.


Jesse Fewell: It is. It really is.


Martin Olson: On that scale and that enterprise. When you’re changing the lives and the process that involves hundreds of people, each individual has to change.


Jesse Fewell: Wow.


Martin Olson: Each individual needs some level of support. There’s a lot of coaching that’s needed there.


Jesse Fewell: That’s a lot of work.


Martin Olson: Again, …


Jesse Fewell: That’s the other lesson that I’m getting that this is a lot of work.


Martin Olson: Any change is a lot of work.


Jesse Fewell: Yeah.


Martin Olson: It’s not the framework.


Jesse Fewell: Wow.


Martin Olson: Again, there’s the notion that, “Hey, we can just go implement it” and then you might. Absolutely. There are case studies out there where organizations did that. I would purpose the reasons why that worked is it fit the organizational culture. The model met the organization where it’s at and it was timely and it was ready to go.


Jesse Fewell: Other’s, it might be more evolutionary. It might be step by step. Martin, thank you so much.


Martin Olson: Hey, my pleasure.


Jesse Fewell: It’s been a blast and I’m glad that we got a chance to share to some people. Thank you guys for listening in. Tune in next time and hopefully we’ll talk to a couple more people from class.


Martin Olson: I’ll see.


Jesse Fewell: All right.


The Difference Between Lean and Agile

As Agile at scale continues to gain momentum, the need for a better understanding of Lean is becoming more important.  The reason for this is due to what each body of knowledge is primarily focused on.

As part of any of our education efforts dealing with Agile at scale (or even across a couple of teams), Silicon Prairie Solutions includes the following as a means to establish a common understanding of the what and why for Lean and Agile.

It’s a pretty simple concept when considered visually against the different planning horizons and organization has.


PlanningOnionSAFe 4.0

Planning Horizons

These planning horizons exist regardless of the process the company is following (Agile, Lean, SAFe, Hope and Prey, etc.)  The typical planning horizons are:

  • Vision (1-2 years)
    • Where the company wants to be in the future. Typically defined by Minimum Business Increments (MBI’s) or Portfolio Epics in SAFe.
  • Roadmap (6 – 18 months)
    • This could would relate to the Program Level Roadmap in SAFe ( or a similar initiative plan.  The contents of the road map are derived from the Vision and other work items the teams must do (Dev Ops, maintenance, etc.)
  • Release / PI in SAFe (~3 months)
    • Getting working software into production and the end users’ hands. Ideally this is done on a frequent basis (the is frequency defined by maximizing value to the customer) but certainly should be done in as short increments as possible to increase feedback.
  • Iteration (2 weeks)
    • A typical team Sprint.
  • Daily
    • Daily Stand up.


After establishing these planning horizons we can now do two things:

  • Define alignment
  • Differentiate between Lean and Agile


Define Alignment

Alignment in this model simply means that the planning for a subsequent level (e.g. Roadmap to PI) supports the same strategy, prioritization and expectations.  You can see from the illustration that alignment should exist from the Vision to Daily.    This also means that alignment encompasses all the activity at the Portfolio\Program\Team levels.   Thus if the teams are not aware of the Roadmap (longer term planning and strategy) they are at a disadvantage because they will try to fill in the gaps of their understanding from a planning horizon based in week not months.  This is one of the reasons why the PI Planning ( event is SAFe is so beneficial.


Lean | Agile

Finally, we can establish a common understanding of Lean and Agile to help grow the organizational intelligence.   If one considers Lean and Agile to be related, and there are some overlapping principles and practices (Kaizen in Lean and Retrospectives in Agile, small batch size in Lean and right sized user story in Agile, etc.) we can associate Lean with the broader time horizons and Agile with the more immediate planning and execution.

In this case Lean is all about systems thinking, flow, maximizing value delivery and the overall process that the organization follows.  This level of planning typically falls to leadership in a traditional organizational structure.  That’s why SAFe and other frameworks can be so effective, it helps define the roles and responsibilities for traditional leadership.

At the other end of the planning spectrum lives the team and Agile principles and practices.  Here adaptability, collaboration, stable teams and executing on the work in a consistent manner are critical.

This model also shows the importance of the Program level in SAFe ( and if applicable the Value Stream Level.  One of the main functions at these levels is to tie the work between larger planning horizons to actual execution and delivery (Lean planning and Lean leadership to Agile teams).  Again, another benefit of using a framework like SAFe to organize around the work at scale.



Scaling Agile: Questions to Ask Before Choosing Your Agile Framework

In the fourteen years after the publication of the Agile Manifesto, many organizations have realized significant gains in productivity, quality, and even job satisfaction at the team level. According to the results of Version One’s State of Agile Survey, 94 percent of the respondents are using Agile practices in some manner.

The survey also calls out the increasing interest in scaling Agile / Lean practices across the industry. Companies that are successful in bringing Agile to the enterprise are better equipped to compete, innovate, and grow because they’re better able to adapt to the changing dynamics of their given marketplaces.

This new competitive pressure has given rise to a number of different frameworks for scaling Agile, like SAFe, LeSS, DaD, etc. Each of these frameworks have success stories behind them, not to mention a few ‘culture wars.’ An us versus them mentality of right and wrong ways of scaling.

But it’s not that one framework is necessarily better than another. It’s a matter of one framework being a better fit for a particular organization.

Which Agile Framework Will Work for Us?

The challenge that the internal change agent, leader, or Agile consultant faces when considering the different frameworks is, “Which one will work for us?”

If you believe the marketing of the various frameworks, the answer would seem to be “all of them.” But it can’t be that easy, can it? Any of these solutions will fit my organization, your organization, plus an organization in a vertical market that I’m not even aware of? I just need to pick the one that agrees most with my understanding of Agile and Lean and follow the guidelines it prescribes?


It’s a lot more involved than that. The process of introducing and implementing any scaling framework involves organizational development. We are changing the way people plan, organize, communicate, and work. The magnitude of the organizational changes involved has to be considered. So before we ask which framework will work for us, we need to ask ourselves these two questions first:

  • Where are we?
  • Where do we want to go and why?

Where are we?

Before we can chart a course for defining and implementing a new way of working, we need to understand how we are currently working. I’m not talking about documenting our processes and stage gates. I’m talking about getting a feel for:

  • the beliefs that we hold
  • the values based on our beliefs
  • the attitudes that arise from our values
  • the behaviors that reflect our attitudes

If we want to implement the changes involved in any of the scaling frameworks, there’s a good bet we’ll be looking to change behaviors throughout our organization. And if we’re going to change the behaviors of the people in an entire organization, we have to make sure that the changes are inline with the collective organizational beliefs, values, and attitudes.

In order to understand where we are as a company, let’s check out Fredric Laloux’s Organizational Development Model (Frederic Laloux, 2014, Reinventing Organizations, Nelson Parker).

The gist of the model is that, like people, organizations grow culturally in response to their environments over time. There’s a progression of paradigms that represent this evolution, each with their own metaphor, characteristics, and thought breakthroughs. I’ve got an overview of them here:

Laloux Organizational Development Model

A few points are worth calling out with this model:

  • There isn’t a connotation of one paradigm being better or worse than another (e.g., Conformist-Amber is not as desirable as Achievement-Orange). Each paradigm is the collective response of the organization to its environment and history. However, note that this indicates that the successive paradigms are better able to accommodate complexity than the previous ones.
  • Successive paradigms still maintain the previous paradigms. So a Pluralistic-Green organization may still use Achievement-Orange behaviors to drive a project and boost internal competition.
  • The leadership of an organization has a significant impact on the paradigm it reflects. This means that if the leader of an organization identifies strongly with Achievement-Orange characteristics, there is a strong tendency for the entire organization be swayed to Orange characteristics.
  • Agile and Lean practices are deeply rooted in Pluralistic-Green cultures. The collaborative nature of the practices would probably not be fully realized in Achievement-Orange and would be foreign in a Conformist-Amber culture. Similarly in Evolutionary-Teal the practices would most likely be overkill.
  • In the evolutionary path, organizations must progress fully through each stage. So in order to go from a Conformist-Amber culture to a Pluralistic-Green, the organization must become and evolve through Achievement-Orange. This is particularly important when we consider where we want the organization to go.

It’s important to know where our organization currently stands. Afterall, that’s the foundation we’ll be building on when we select our scaling framework and all of the changes that come with it. If the principles and practices of the framework are too foreign in relation to our company’s current state, our change initiative will be doomed before it’s even begun.


Where do we want to go and why?

Now that we have a better understanding on where we are, we can consider the second question. Where do we want to go and why?

What are the challenges or opportunities that we’re looking to address by introducing Agile at scale? Will these efforts address the root cause of the issues instead of just the symptoms? How will we know if we’re being successful?

If we consider the changes we’d like to realize throughout our organization in the context of Laloux’s model, we have context that’s typically not considered in the implementation of the various frameworks.

For example, each of the frameworks has some recommendations around ceremonies, roles, and responsibilities. If we look at these suggestions with an eye toward our organizational culture, we can get a feel for how much interpersonal change they might require. This is critical to consider — this is where the sustainability of change is determined.

If the changes that a framework introduces are too large a shift (say, from Amber to Green on Laloux’s model), human behavior indicates that the changes will be met with one of two responses:

  • noncommitment/passive support;
  • or outright fighting the changes

In Laloux’s model, this would be indicated by either falling back into the inherent behaviors of our current stage or maybe even regressing to a previous stage. The challenge of adopting a framework is not in following its recommended ceremonies and roles. The challenge is in making those ceremonies and roles an achievable step forward for our company. And there’s not a one-size-fits-all model available for that.

The other aspect of understanding where you want to go organizationally deals with paying attention to the way people handle change. In any change initiative, it’s imperative to let the people that are going to be affected know:

  • what the changes are;
  • how they will be impacted;
  • and what the reasons for undertaking the changes are.

It’s been said that people don’t fear change as much as they fear the uncertainty associated with the change. By making the facets of the change understandable and accessible to the organization at large, we increase our chances of a successful implementation.

Scaling Agile: The Takeaway

Organizational development is a complex and dynamic component, especially if you’re thinking of utilizing one of the many Agile scaling frameworks in the market. In the end, the important task is not deciding what framework to use. It’s to understand where your organization is today and where you’re planning to take it tomorrow with the assistance of a framework.

By understanding your answers to these two questions more fully, you can better understand and prepare for the changes that your eventual framework choice will help usher in. While each framework will tell you how it can fit your organization, the reality is that some that will fit more readily than others. To find out which ones those are, you have to look within your organization.