Feed aggregator

Mob Programming: A Whole Team Approach

Agile Connection -

Mob programming is a software development approach where the whole team works on the same thing at the same time, in the same space, and at the same computer. Collaborating like this can have great benefits for everyone involved. Here, Woody Zuill details some practices his team uses to make this collaboration work for them.

15 Useful Pacts for Agile Teams: An Agile Team Creed

VersionOne Agile Management Blog -

The Agile Manifesto values “Individuals and Interactions” over “Process and Tools.”  I suspect it was no accident that this was listed first.  Lack of communication, miscommunication, or the mistaken presumption that communication has occurred, are the root cause of many problems.  Yet, we still focus much discussion on the process and tools.

  • When and how do you conduct a certain Scrum ceremony?
  • Are you practicing pure Scrum?
  • Which agile tools do you use and why?
  • How do you use the tool?
  • What agile metrics are you using and how?
  • What best practices exist?
  • And lots more concerns and questions about how to “do” process…

However, most all change transformations to “be” agile struggle with organizational culture and many organizations and teams continue to fail to reach their full potential because of issues related to “individuals and interactions.”

Teams are the heartbeat of agile development.  It’s the people that produce business success.  Even when the organizational culture embraces agile values, the teams must also address their individuals and healthy interactions among them to maximize value.  This takes time and effort to mature.  I find we mistakenly assume that since people know each other already and even “behave” nicely, they think they can skip over the team-building activities.

Simply gathering individuals together and assigning them the label of “team” does not make a team.  Each team is comprised of unique personalities and thus there is no cookie-cutter best answer for every team.  Each team must find its own way and navigate the uniqueness of each individual to determine the best way to handle interactions that work for their team dynamic.  There should be “pacts” that everyone on the team agrees to.  If there are dysfunctions (egos, prima donnas, passive aggressive behavior, apathy, poor listening skills, a presumed hierarchy, and so on), then the challenge is an order of magnitude that’s much more difficult.  Each team is a unique, dynamic system, subject to changing moods and their environment.

Sadly, some agile teams never evolve beyond a collection of individuals who meet together at the prescribed Scrum ceremonies and then return to work independently with a focus on their individual tasks only.  Maybe the ability to track their work has improved, but they have failed to recognize and harness the true potential that comes from working as a high-performing team.  Perhaps you have seen teams who are full of energy and so you recognize the power of teams?  So, why do some teams never get there?  There are multiple factors that influence agile and Scrum teams.

Let’s assume that the organization’s leadership values the power of teams and has a supportive culture and vision in play.  So what can be done within the team to ensure that it sets a solid foundation for growth and success?

During the team forming stage, it is important for the team members to openly discuss behaviors and expectations.  There is great value in recording those discussions as a reminder to the members when they do encounter problems.  But, they need to dive deeply into what each member truly believes and feels.  Because what you believe and how you feel directly determines how you will behave.  These team discussions must go beyond the process-mechanics agreements such as what time to meet.  They need to communicate something more of an “agile team creed” or list of pacts they make with one another. Team members must be comfortable sharing their fears and concerns.

Having an agile team creed is a great starting point for deep team discussions to root out true beliefs.  It captures cultural expectations and behaviors for the team which I believe lay the foundation for a great agile team.  Here is my list of 15 useful pacts agile teams can make.  I call it the Agile Team Creed.

Has your team had these deep conservations about what they believe?  Would they agree with these items as part of their Agile Team Creed?  If not, why?  Perhaps, it reveals a cultural issue that needs attention.

Financially Positioning an Agile Transformation

Scrum Alliance -

The Internet revolution has made the IT industry grow faster, and die faster too. Any organization that survives must have good judgment regarding finances. However, it is tricky to align Agile implementation to revenue growth, because the ROI can never be that linear.

Rally Scores a B Corp Three-peat

Rally Software - Agile Blog -



Why do YOU love Rally? That’s the question we asked all our employees when we found out we earned the Best for the World: Worker Impact award for the third year in a row! We made the list by scoring in the top 10 percent of all Certified B Corporations for employee impact on the B Impact Assessment — a comprehensive evaluation of a company's impact on its workers, community, and the environment. Rally scored particularly high in the work environment and compensation, benefits, and training categories.


All Certified B Corps, including well-known companies such as Ben & Jerry’s, Dansko, Method, Patagonia, and Seventh Generation, must meet the same rigorous standards of being a socially-conscious business. We are thrilled to be honored among these companies as one that is Best For Workers.


One of our core values, make and meet commitments ensures we hold ourselves accountable to our team members and to Rally when meeting our business objectives and goals.


To spread the good news about the award, we wanted to celebrate in ways that would make a lasting impression. First, we hosted a thank-you party at Boulder headquarters with desserts prepared by employees of Community Table Kitchen, a social enterprise of Boulder’s Bridge House that provides culinary arts training for people transitioning out of homelessness as a stepping stone to mainstream employment and self-sufficiency.




Ryan Martens, our CTO and founder, joined me in sharing our thoughts on the award and how much it means not only to Rally but to us personally.


“At Rally, we've always believed that for-profit business should be a force for social good, and that passionate, engaged employees are key to solving some of the worlds toughest, most complex problems,” said Martens. “Our employees are critical to making that vision a reality, and we're proud to be recognized for fostering an environment where employees can thrive.”


Next, we asked employees worldwide to share why they think Rally is a great place to work. In addition to posting some #RallyLoveNotes in our All Employee flow on Flowdock, we’ll be showcasing even more responses on a visual display that will live at our Boulder headquarters.


Our hope is that the display serves as ongoing inspiration for our employees, customers, and visitors for years to come.


Liz Andora

Super-Sized Agile

VersionOne Agile Management Blog -

Guest post by Bob Schatz of Agile Infusion, LLC

The interest in expanding agile development practices is growing at an increasingly faster rate. The good news is that this indicates that companies are seeing positive results in their initial experiences on projects and are looking to further the expansion, even beyond product development. The challenge is recognizing that these early successes required overcoming many obstacles and shifting the mindset of a number of people. And that these things get exponentially harder as you introduce change across the enterprise.

The pressure is also put on consultants, trainers, authors, speakers, agile software tool vendors, and coaches to codify and simplify models to reduce the strain from employing agility at scale or “super-sized agile). When success happens, everyone wants to share the experience, but they often focus on showing the model that worked for them in a specific case. Since the structures are simple by design, this creates a feeling that it must be relatively painless to just replicate the experience in other parts of the company, and then to other companies.

This is similar to what we’ve seen in the past with the basic Scrum process, Lean/Six Sigma, the Toyota Production System and just about any process improvement strategy that has a significant success story to tell. As a result, there has been a flood in the community of scaled agile methods that are all too similar to be called different. Arguments ensue on a daily basis; thought leaders pit their methods against the others trying to prove why they have the right answer. A slew of marketing professionals try to position each method as the better answer in hope of attracting a “big fish” company that will tout how successful the method made them. Right now, we have no less than six scaled agile methods actively being marketed, not to mention the hybrids that companies are presenting in conferences, articles and such. And the methods just keep coming! Ultimately, success will require:

  • Identifying the problem you are trying to solve
  • Understanding your current organization and its ability to satisfy consumers
  • Identifying the gaps
  • Designing an organization and process
  • Growing your leaders at all levels
  • Execution and relentless continuous improvement

In order to bring us back to the ground, I would like to tell a couple of my own stories which might help you and your organization focus on keeping things simple and overcoming the struggles that all organizations will eventually face in order to instill a culture of continuous improvement and process innovation. These will be critical to serving your customers better than anyone else can.

Back to the Future

My first story is from what seems not too long ago, but I guess that’s what all of us “old-timers” say.  I came into the software profession as a programmer in 1984. I was hired by GE in Valley Forge, PA in the start of my senior year of college when defense contractors were building up at an incredible pace.  I was really looking forward to seeing how the little projects we were doing at school would apply to working on a massive Department of Defense project. And just to be honest, a lot of my school projects involved punch cards. So, the first scaling problem I had was keeping a huge deck of cards in the right order!

The first project I was assigned to at GE was a massive system involving hardware, space vehicles, communications, ground stations, and a host of other components and challenges that made my head spin. The system involved thousands of people across multiple contractors and government agencies all working together to solve a huge problem. It was even more complicated by the fact that this was a classified system where we had to deal with compartmentalization and people with different need-to-know levels that restricted with whom you could collaborate.  The project management was mostly visual techniques and we relied heavily on interface control documents, which let us know the inputs and outputs for our piece of the puzzle. (In reality, those documents were not entirely accurate, coordinated, or followed, which caused more than a few defects later in the project).

We all relied heavily on each other to communicate from one component or process to the next. System integrators tried to keep an eye on all of the parts to ensure a smooth system-wide deployment. These projects went on for years. We employed what we now know as the waterfall development model, but at the time we just referred to it as MIL-STD version 2167.  Now, I’m not claiming that these were smooth projects. They were terrible and required massive amounts of overtime (which luckily we were paid for), rework, and heroics of some of us to pull it off. These were much different times, but looking back, we did what always worked, and used common sense and a will not to fail. We were motivated to serve our nation’s best interests and we were young, enjoying cashing in those big overtime checks. Organizing ourselves was less of  an issue, knowing that we had to solve important problems and everyone was focused on success.

For my 12 years there, the projects got bigger and more complex. We kept using the same organization techniques because they worked for us in those circumstances.  Every project required a level of heroics at the end, which nobody would tolerate today. These were different times. Today’s software development environment requires faster speed, much higher quality, and the ability to adapt to a much higher rate of change. My point here is that we didn’t need a model to tell us what to do and, to my knowledge, there was never a Scaled Waterfall Model.

A Burning Platform

Fast-forward through a number of great experiences, including a very successful start-up where I really learned the value of agility in its purest sense before “agile development” was a term. At the end of 2001, I wound up as the vice president of development at Primavera Systems. Now part of Oracle, Primavera makes enterprise portfolio, program, and project management software. This was where we used Scrum staring in early 2003 in an organization with almost 150 people — that became one of the first, and certainly well-publicized agile success stories.

We started off with the goal to improve our lives, our products, and our relationships with other groups in the company. We had serious issues with our product and process. More importantly, our people were suffering. Nothing I tried in all of my leadership experience to date had worked to my satisfaction in my first year there, so it was time to radically re-tool.  Scrum was just a leap-of-faith decision to attempt to save us.

Our challenges began with figuring out how to create Scrum teams. We wound up with about 20 of them all working on a single, large enterprise product. We ran into a lot of issues with builds and people stepping on each other, so we innovated. We set our focus on stopping the branch/merge environment and forced ourselves into a single trunk, so everyone was now responsible.  We had discussions about how to coordinate dependencies, coordinate development of feature sets involving multiple teams, and how to deal with obstacles that affect many teams. As with everything we didn’t have an answer for, we designed experiments and tried them. This led us to create the idea of having a representative from each team form another Daily Scrum after each team conducted their own to coordinate and deal with cross-team topics. This eventually became known as the Scrum of Scrums. It also led to solving the issue of having 10 product owners learning to coordinate their decision-making by establishing a chief product owner role.

We created the idea of an integration Scrum team focused on testing integrations with other products in our portfolio, as well as third-party integrations. They also did continuous performance testing. We carved out fixed days/times for functional meetings so that directors of development, testing, documentation, etc. could spend two to three hours developing their people and their disciplines. We had teams who organized around certain product areas, architecture, and database development, helping to keep everything coordinated. We kept working on the process to improve and expand it.

Once we had a good handle on our own work, we had all other organizations participate in Sprint Reviews so they could get access to the product being developed. We brought in end users from the very start and just kept getting more and more of them to participate, which really helped us to build a better product. They became increasingly engaged in helping us manage our portfolio and product backlogs.  As we moved forward, we dealt with other challenges like having multiple chief product owners, all with their own products wanting to use the same Scrum teams, and learning to manage the flow of work.  Later, we encountered  the challenges of distributed development and forming Scrum teams in India and the Ukraine.

Through it all, we just kept doing the hard work of solving problems and not looking for the silver bullet as Ken Schwaber had taught us so well. The message is clear; agile development practices are simple by design; implementing them is hard. It requires people who want to improve their circumstances. They want to serve their customers better than everyone else. They are willing to use their smarts to design experiments that will help them get there. And they are willing to fail sometimes, but learn quickly.

So, Now What Do We Do?

The answers to large-scale agility do not lie in a book, or a set of slides, or a poster. Every project that has more than one team is a project at scale, and every environment is different. The answers will emerge when people are willing to put in the work. There are no shortcuts; seeking shortcuts will only result in change initiatives that will not survive the test of time. Stories like these can help spark ideas, but they are not to be followed like a recipe. Doing so only sets us up to repeat history. So, the first question is not which model to follow, its asking yourselves “What problem are we trying to solve?”

Why is it Called an Agile Transformation?

VersionOne Agile Management Blog -

Guest post by Charlie Rudd of SolutionsIQ

We’re not in Kansas anymore.

Most organizational change initiatives are not called transformations. So how come agile change initiatives are? To answer this question, let’s first review some examples of organizational change as well as the impact they have on the people in the organization.



Note in the above table how the magnitude of change deepens as you move from the top to the bottom of the table. At the top of the table, the change has little impact on the day-to-day work of most individuals. However, at the bottom, the impact of change can be quite profound. For example, changing the corporate culture uproots deeply embedded behavior and necessarily changes long-standing beliefs and assumptions.

Working with this principle, we can identify three levels of organization change magnitude:

Superficial org change

This type of org change has little impact on your day-to-day responsibilities and activities. Many corporate re-orgs are actually superficial. For example, your company may hire a new VP, but that doesn’t necessarily affect the project you’re working on, the work you perform on it, or the people you work with.

Significant org change

This type of org change has a greater impact on you. Your job or your work environment is affected, but usually not your role or job description. For example, some work procedures may change, and you may receive training or new software tools as a result. You may even have to join a new team or someone new joins your team. Perhaps you have to move to an office in a different building. Whatever the case, when your organization undergoes a significant org change, you are definitely affected even if the effect is rather minimal.

Transformational org change

Often, after a transformational org change, you have a new role that you have never performed before. Your job responsibilities change radically. So do your supervisors and their responsibilities. You have to approach your work in an entirely novel way, learning completely new skills, and often a new vocabulary. The unwritten rules that used to guide how you act and what you do no longer apply. Your work world is completely new. It’s surprising. It’s refreshing. It’s strange.

Let’s now consider where agile transformation fits within this org change magnitude framework:

Agile org change

In an agile transformation initiative, some of the change is superficial – some more significant – but when successful, the bulk is transformational. Learning new practices and tools are needed, but not sufficient for lasting success. Change must go deeper, in many cases down to the roots of corporate values, and what had been unquestioned management principles. It must encompass a new way of thinking about work and your place in this new world. Long-standing assumptions and unwritten rules go out the window as you discover new ways to work together with your colleagues, every day. This is why it’s called an agile transformation:  you, your job, your responsibilities, your management, and your organization are transformed into something new.

So are we in Kansas anymore? In a word:  nope. We’re not in Kansas. Agile transforms your world. It’s surprising. It’s refreshing. It’s strange. Whatever you think agile may be, there’s one thing it’s not:  business as usual.

So You Want to Scale Your Agile?

VersionOne Agile Management Blog -

Guest post by AgileBill Krebs of Agile Dimensions

Some teams – such as sustaining engineering teams – are fine with Kanban. This method shows work on a taskboard as it progresses from waiting, to doing, to done, with an eye toward cycle time and focusing on a few things at once.

Some teams are fine with traditional Project Management Body of Knowledge (PMBOK – from the PMI) – as in special client engagements.  This covers key project aspects such as cost, procurement, communications, and may use a Gantt chart to plan jobs of known but varying sizes.  Unlike most of our agile projects, this will assume there is little likelihood of change.

Some teams are fine with Scrum development.  Two-week iterations and sprints give vital visibility into progress, and also windows for change.  Teams learn empirically and use these iteration windows to tune and adjust their product and procedures.  Extreme Programming (XP) plans in a similar fashion, but adds some technical practice to build quality in.

These teams often have nine or fewer people, with three to six months for work.  But what if the project or product you deliver has 40 people?  100 people? 300 people?

Projects like these would require scaling up your agile.  Authors such as Jutta Eckstein, Scott Ambler, Kenny Rubin, and Dean Leffingwell have all described ways to do this.

Using such concepts in practice with dozens of teams has shown six key areas:

1)  Roll-out – does management and the teams know agile at scale is different?  Are they committed to doing it, and have they had some training on multi-team agile?   Do you have someone prepared to program manage a team of teams?

2)  Common language – one team can use whatever terms they wish.  But when team of teams (aka, Scrum of Scrums) forms, it quickly becomes a mess where some say ‘Feature’ and some say ‘Epic.’  Pick a scaled agile methodology and vocabulary, and make that your organization’s common language.

3)  Features – it helps organize larger projects to use the ‘parent’ of a story.  Let’s call this a ‘Feature’ (like Dean Leffingwell’s Scaled Agile Framework® or SAFe™).  While we still use small Stories, it becomes more important to plan ahead using larger Features so other teams can know when to depend on our output.  This also helps stakeholders gain a picture of our product even as the number of Stories multiples as the team grows in size.

4)  Align the business – with larger projects, it becomes even more important for business-facing parts of your organization to connect with your scaled agile process. Planning at higher levels such as portfolio (multiple products) and program (multiple teams) becomes more integral to how we work.  But working with our market experts is harder if they do not understand our terminology and approaches to delivering at scale.  Other areas such as accounting and your project management office may need to understand your scaled approach as well.

5)  Kick off each release – spend a little more time before each release to look for dependencies between high-level features.  Let teams know what’s coming, and have them discuss how they will deliver together.

6)  More than a dozen teams – it makes sense to forge four or even 10 teams into a group that delivers a product.  But if you product requires more than a dozen teams, that will be big enough to demand another sub organization with its own program manager.

Agile development has been used in many projects, large and small.  Keeping these six factors in mind will help with your enterprise-strength projects. Taskboards may be sufficient with smaller projects, but larger projects benefit from tools designed to see things at more levels – portfolio, program, and team.

What steps can your project take to work smoothly between teams? 

“AgileBill” Krebs has over 20 years of programming, performance, project management, and training in the IT industry at 5 IBM labs, banking, telecom, and healthcare.  He has used agile since 2001, and taught it to over 2,000 people worldwide. He has presented at agile conferences, IBM Research, and conferences on education. Bill’s certifications and groups include SPC, PMI-ACP, CSP, ICE-AC, and others.  He hosts the Distributed Agile Study Group and is a member of ALN, the Scrum and Agile Alliances, ACM, AERA, PMI, and more. He is pursuing a graduate degree in education technology, while working as an enterprise agile coach in the healthcare IT industry.

Scaled Agile Framework is a registered trademark and SAFe is a trademark of Scaled Agile, Inc.


Scaling Agility Beyond IT

Scrum Alliance -

Many established organizations lack the maturity to tackle agility and continuous delivery in its true spirit, not realizing that they have to radically revolutionize themselves at frequent intervals just to stay relevant. . . .

Slipping into ScrumBut

Agile Connection -

ScrumMasters don't like to talk about their own troubles or failures, even though they say it’s good to fail. They don’t like to admit it happens to them, too. Sometimes it just creeps up. If you've started relaxing your Scrum principles and feel yourself slipping into ScrumBut, take hope: You and your team can recommit.

Scaling Agile Your Way: Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS (Part 3 of 4)

VersionOne Agile Management Blog -

In Part 1 of this four-part series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project developing a product or a solution has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.

In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (see Tables 1-4 of Part 1 of this blog series).  Each scaling agile parameter can assume one or more values from a range of values.   Each organization or a large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique.  However, “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise).  Systems thinking is important for Scaling Agile Your Way.

In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe), LeSS, DAD and MAXOS.  Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.   In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  SAFe and MAXOS represent radically different approaches to scaling agile. Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

Today, I will focus on the Sweet Spot, Challenge Zone and Unfit zone for SAFe and MAXOS:

Sweet Spot:

  • Indicates a good match between a scaling agile framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
  • Implementation becomes easier, more efficient and effective

Challenge Zone:

  • Indicates a challenging match between a framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
  • Requires more implementation effort compared to the Sweet Spot

Unfit Zone:

  • Indicates a poor match between a framework and a scaling agile parameter with a specific choice or range of choices for the parameter
  • Poor match could happen for one of two reasons:  (1) the parameter value chosen is not applicable, or (2) the parameter value chosen will not work well

Figure 1 illustrates the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presents similar information for MAXOS.  These are organized by the six scaling aspects mentioned above.  You will see four arrows in each Figure showing our recommendation for taking your large-scale agile projects closer to the Sweet Spot over a period of time.  I urge you to carefully review all of the information presented in Figures 1 and 2.  There is a lot of information, and it will take time to fully understand.  You may find it helpful to discuss with other agilists within your company.

Figure 1: Sweet Spot, Challenge Zone and Unfit Zone for SAFe

Figure 2: Sweet Spot, Challenge Zone and Unfit Zone for MAXOS

 From the information in Figures 1 and 2, it is clear that SAFe and MAXOS offer mostly distinct Sweet Spots, Challenge Zones and Unfit Zones, although occasionally there may be some overlap.  For example:

  • As shown in Figure 1, cross-functional, self-organized teams with co-located or close-by time zoned team members working under low to moderate governance structure offer a Sweet Spot for SAFe. But in Figure 2, self-organized, developer-centric (not cross-functional) teams of co-located members with minimal governance overhead offer a Sweet Spot for MAXOS.
  • In Figure 1, emerging user needs that must be discovered with sustained effort represent a Challenge Zone for SAFe; in Figure 2, the same scaling agile parameter value offers a Sweet Spot for MAXOS.
  • In Figure 1, low to moderate product modularity represents a Challenge Zone for SAFe, while Figure 2 shows that low modularity (tight integration of all code) creates an Unfit Zone for MAXOS.  On the other hand, a high degree of modularity in the product/solution architecture represents a Sweet Spot for both SAFe and MAXOS.
  • In Figure 2, heavy and rigid governance, or heavy/life-critical regulatory regime represent an Unfit Zone for MAXOS. But in Figure 1, the same scaling parameter values offer a Challenge Zone for SAFe.
  • In both of these, we see that, “Tightly coupled hardware product with embedded software and services (ex. appliances, cars, medical devices, smartphones, wearable computers, military gear, industrial equipment)” represent an Unfit Zone for both SAFe as well as MAXOS.

Get As Close to the Sweet Spot As Possible

If you decide to use SAFe in your enterprise (at least for some programs and portfolios), ideally you should try to get as close to the SAFe Sweet Spot as possible.  I have similar advice if you decide to use MAXOS (get as close to the MAXOS Sweet Spot as possible).  It is quite possible that your entire enterprise is not close to the Sweet Spot when you are just beginning your scaling agile transformation effort.  In that situation, I suggest starting with a scaling agile pilot program of 5 to 10 teams; after their initial education on SAFe (or MAXOS) is over, have this pilot program start as close to the Sweet Spot as possible.  This may require changes in some of your historical processes and practices, and development of SAFe (or MAXOS) with clear understanding and support for from your senior management.

For example, a pilot for SAFe may need to choose a relatively moderate domain complexity project, fairly modular architecture to minimize inter-team dependencies, co-located team members for most teams, a good deal of test automation and continuous integration (with prior training), a set of strong servant-leader ScrumMasters for each team, low to moderate governance overhead, low to moderate regulatory compliance regime, low to moderate impact of defects, etc.  See the Sweet Spot for SAFe in Figure 1.  If the pilot program teams are not close to the Sweet Spot yet, senior management will need to help them get there as the starting point for the pilot to make the scaling agile journey less painful.  With the experience of one release cycle underway, more pilot programs can be started close to the Sweet Spot; in fact, while the first pilot is going on, one to four more pilot programs can be identified and necessary effort expended to bring them close to the Sweet Spot as a starting point for their upcoming SAFe (or MAXOS) pilots.

Dealing With the Unfit Zone

The other extreme of the Sweet Spot is, of course, the Unfit Zone.  If a pilot team finds themselves in the Unfit Zone for at least one scaling agile aspect, the pilot will very likely fail.  For example, if a SAFe pilot program must use contributions from the open source community, or a MAXOS pilot program must operate under a rigid or heavy governance structure, or work under a life-critical regulatory regime, it will most likely fail.  Senior management must either take action to remove the issues creating the Unfit Zone, or select a different pilot program that does not find put the pilot in the Unfit Zone for any of the six scaling aspects.

Your Journey to the Sweet Spot is Your Tailored Journey

Your transition of your pilot program to the SAFe (or MAXOS) Sweet Spot will be your own customized plan and journey tailored to your situation.  You need to consider where these pilot teams are now, the gap between their current status and the Sweet Spot, and the effort and time needed to bring them closer to the Sweet Spot.  This effort will be dependent on each team’s situation, and is a very important aspect of “Scaling Agile Your Way.”  How do you take a pilot program close to the Sweet Spot is going to be your own unique journey and cannot be copied from a recipe book.  If a pilot program or a specific team within that program cannot reach the Sweet spot across all six scaling aspects, maybe it will come close to the Sweet Spot for four out of six scaling aspects, and stay in the Challenge Zone for the remaining two.  When a pilot program is in the Challenge Zone with respect a scaling aspect, it does not mean that the pilot program cannot start or proceed; but it does mean that you need to be prepared to spend more effort and overcome difficult challenges if you are going to operate in the Challenge Zone.

For example, if a pilot program has one or more teams with their members in different locations with widely different time zones, the SAFe Release Train Planning (two-day event required by SAFe) may involve a lot of complicated logistics and travel time/expenses for remote people, for which senior management support might be hard to come by (after all, “this is a pilot” is likely to be the argument).  If the pilot needs to operate under a traditional, hierarchical and rigid structure, it may create many organization impediments, complicating the challenges for the pilot program.

As shown in both Figures 1 and 2, your transition plan is to move as close to the Sweet Spot (the inner most rectangle area) as possible from the directions of Unfit Zone and Challenge Zone. This is illustrated by four broad arrows pointing toward the innermost rectangle in Figure 1 for SAFe and in Figure 2 for MAXOS.  If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The culprit is likely one of two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate its understanding and commitment to the success of scaling agile.

2.  Rooted in the market and business environment of your organization.  These reasons cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment the scaling agile framework practices with your own custom practices and retain the practices from the framework that are still applicable.

Table 11 below captures the Unfit Zone and Challenge Zone in its two rows, and the above two classes of reasons in its two columns.  The cells in this table illustrate specific examples of an action plan.

Table 11: Reasons and Actions for Unfit and Challenge Zonewith Examples

The transition from Unfit or Challenge Zone to Sweet Spot will require planned, disciplined and concerted effort — and a good understanding and true commitment from your senior management.  This journey will be uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but still have few areas in the Challenge Zone.

Customization Needs and Opportunities for Implementing Your Scaling Agile Framework

In addition to your unique and tailored journey toward the Sweet Spot of your scaling agile framework, a very important aspect of Scaling Agile Your Way is that each team, program or portfolio may need to implement key aspects of its framework in unique and customized ways.  It seems that the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be used to implement a variety of process modules of SAFe in customized ways.  Customization needs and opportunities for the MAXOS framework will come mostly in the context of implementing its advanced engineering practices of code contribution, automated testing, continuous integration, feature switches, continuous delivery, and making use of cloud computing facilities, etc.  I will elaborate on this topic in Part 4 of this series.

Are you about to start your scaling agile journey?  If so, do you have one or few pilot programs consisting of 5 to 10 teams in mind?  How do you feel getting them started closer to the Sweet Spot of SAFe, MAXOS or any other framework of your choice (such as LeSS or DAD)?   Have you run into the Unfit Zone for any scaling aspects?  I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com) or on Twitter @smthatte.

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Stay tuned for my wrap-up of this series:

Part 4: Scaling Agile Your Way: How to develop and implement your custom approach

Project View Versus Product View

Scrum Alliance -

This article highlights why it is essential for an Agile team to develop a "product view" to deliver the benefits of Agileto the business. It also explores a few ideas to enable the product view.


Alistair Cockburn -


Subscribe to Torak - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator