The Three People Who Need to ‘Just Say No’

Guest post by Scott Dunn, Rocket Nine Solutions

“We have too many things going on!” I hear this often from developers, product owners, even management. The problem is that we might be enabling this problem unknowingly (that does not, by the way, go away by itself). Depending on your role, I have three ideas for three different people: (1) the team, (2) managers and the PMO, and (3) the ScrumMaster.

At the team level, this complaint of too m­any projects or initiatives is very common. When I was a manager, my people would come up to me and say, “Jim in Marketing thinks I should be working on his request; Leonard just told me his changes were needed yesterday; and yet, we’re not even halfway done with Scotty’s list. Can you please tell me what’s the priority??”

Now that we’re doing Scrum, the priority is clear, right? There’s only one stack-ranked list from which to work. That gives us clarity, focus, limited work in progress, short feedback loops with everyone, and an increment of done-done potentially shippable software. Hallelujah!

Only, this is often not happening. No single list for a person, no limit on the work, no singing Hallelujah. The majority of companies and teams I’ve worked with miss out on this incredible win because they break a fundamental principle of Scrum… The team members are shared, or maxtrixed, with other teams or projects.

When stakeholders or management come to the product owner with a new request, the response from the product owner should be, “Let’s talk about where it fits in the backlog. Thanks; I’ll see where goes,” or perhaps, “Please tell me where it goes.”

Instead, these requests sometimes go to management or the PMO, and the manager or program manager says, “Okay, I’ll grab some people and get right on it.” But they’re grabbing people who are on dedicated Scrum teams. “Oh, that’s right – we’re doing Scrum. Okay, I’ll grab some people and form a new Scrum team and get right on it.”

And we’re back to people asking what’s priority, because “Jim thinks his team needs me about 75%, Leonard just told me their team needs me 100%, but my current team isn’t even halfway done with Scotty’s list. Can you please tell me what’s the priority??”

This matrixing is costing us not only in frustration at the team level. It’s costing us real dollars. According to a recent post on, research shows the cost estimated at $450 billion dollars a year globally. How? A 40% drop in productivity, 50% longer to complete a single task, and up to 50% more errors. Doesn’t sound like something we want to do, right?

Too many things going on.

So what can we do to improve right now where we’re at? There are a couple of immediate actions, and perhaps a bigger, and more valuable, solution long-term.

First, product owners…

Tell the requestors “No.” In Henrik Kniberg’s wonderful overview video of the product owner role, he says practicing saying “No” goes a long way. I typically respond with a different version – “Yes, AND…” That is, “Yes, AND if you show me which of your previous requests this new request is more important than, we can do it at that point.” With tougher stakeholders, I’ll admit that I have said, “I’ll put it in the backlog right away!” I would do that (I don’t run around lying to executives), but I would sit on the request and wait if this the request was “urgent but not important.” Or perhaps they would soon be distracted by some new, bright and shiny thing. Ideal and healthy? Perhaps not. But there are some places that I felt I had to pick my battles and use my time responsibly and effectively for more value elsewhere in the company. And dealing with pushy or whiny Ryan from Department B wasn’t always it.

Managers and the PMO

Second action is for managers and the PMO – tell the requestors “No” by not starting up yet another team. The truth is, if you have 100 developers and testers in IT, then you should have about 10-14 teams. The numbers tell us that matrixing is costing us a massive lack of focus. It also costs you in lost opportunity. Rather than simply delivering the most valuable thing in a month, we often deliver the 1st – 12th most valuable things at the end of a year, with not much business value or feedback in the middle of that year. And value degrades. A customer-requested feature delivered long past peak demand is just not as valuable as delivered at the height of market/customer demand.


Thirdly, ScrumMasters and internal agile coaches should tell the requestors, “No,” by talking with stakeholders and decision makers about these costs. Over and over again, I hear those guiding the agile adoptions at their companies tell me they’re in a matrixed organization. They admit that they know it’s bad, but they’re hoping it will change. If we could be honest for a moment, if you’re in this situation, how long has it been this way? How long have you been hoping for change? As a change agent, have you shared this information with them? Is there any buy-in, a timeframe, or roadmap for change in this area? Most commonly, real organizational change (such as how work is fed to teams from the program and/or portfolio) begins with understanding and support from top executives and stakeholders.

One example of a framework for alignment at these levels is the Scaled Agile Framework® (SAFe™), which provides some nice guidance for addressing this problem. First, we work in terms of value streams, which certainly something the business should relate to, and all contributors within that value stream are on teams. A level above the team’s Product Backlogs is a Program Backlog with a product manager who is the single point of accountability for this larger span of work. Although this can be handled in pure Scrum with a chief product owner, figuring out how to implement this can be quite difficult. The following can take years, if ever, to figure out on your own (especially without external coaching, which most aren’t fortunate enough to have:

  • The “what” of a portfolio, strategic themes, vision and roadmap
  • The “how” of actual coordination and ynchronizing the work of many teams
  • Governance such as architecture or UX

SAFe gives you a running start in these critical, but typically shelved, areas.

Even more helpful to help executives understand and support agile is that SAFe gives a simplified and easy-to-understand (ok, easier) context and plan for your stakeholders and other key roles from whom you need support for change. Keep in mind that many feel that we are in the Late Adopter (from the Technology Innovation Adoption Curve) state of agile. These Late Adopters are typically risk-averse, don’t like change, and would like a plan – at least to start with. To tell them, “We’ll self-organize around how to do agile here and we’ll figure it out,” is probably not something they want to hear.

I hope you found some ideas in this article that you can take action on and help others in the organization do the same. If so, we can all get back to the good stuff – meaningful, challenging work that delights stakeholders and customers.

Posted in Agile Leadership, Agile Management, Agile Teams, Agile Velocity, Lean, Scaling Agile, Scrum Development | Leave a comment

What is the Prerequisite of Success When Scaling Agility?

Guest post by Timofey Yevgrashyn, Ciklum

Today more and more enterprises are looking into agile approaches as the answer to their needs. It doesn’t matter if a big company starts scaling agile with or without acting Scrum teams. What matters is the way the company goes from the “let’s-scale-agile” decision to the visible results of scaled agility.

Why scale agility? A few thoughts.

One could say that the apparent reason to apply scaled agile practices is when you have many agile teams that are cross-dependent and working on the same product(s). But it wouldn’t be true as in our practice; the number of people doesn’t drive managers to even start thinking about applying methods above the team level.

What interesting is, the decisions to scale agile often come from the top. The feeling of “something is wrong with the business” on the top level is much higher than that feeling at the team level where the use of Scrum or other agile methods usually starts.

While talking to more senior management, the problems could emerge through the main “pain” areas, which have been reported in a number of agile development studies. Briefly, these areas are quicker time-to-market, better quality of the product, higher engagement of people and higher productivity. One or another, or even combined pain feeling in these areas, leads the enterprise management start thinking about better methods or development practices that could help coordinate many agile teams. The company management itself, or with the help of consultants, realizes the need for scaled agile. And so they start looking for already known frameworks such as the Scaled Agile Framework® (SAFe™) or experiment with their way.

Scaling agility doesn’t come easy.

It is worth mentioning that an organization structure is the result of that company’s history. Rarely (not to say never) is organizational structure architected in a scalable way from the beginning.

To be able to deliver better software and respond to change at the same time, an enterprise should overcome the major pitfall in scaling an organization. This pitfall is the traditional mindset of project-oriented companies instead of value-oriented companies.

Many of you have seen the triangles picture. It shows how the sequential phased approach (aka waterfall development) is compared to agile development methods in their view on three cornerstones: (1) scope, (2) time and (3) teams – resources and/or budget:

triangle image_Tim

Many organizations with a desire to scale agility still approach projects in the old, traditional way. The business part defines the total scope, and the software development part (or a vendor) is expected to estimate and plan how many resources and months they need to deliver what they were told.

At the same time, the agility of an organization means delivering what users need and cutting out waste from the original ideas to maximize value. This demands that an organization build a structure that, at regular pace, delivers a working product and then just balance out the decisions of what to do next in order for the business to develop.

What companies do before scaling.

Organizing people and communications around value streams is one of the major changes that happens when a company decides to scale agility. Even if the decision “let’s scale agility” is supported from the very top level, and everyone is eager to achieve this state quickly, there’s still a long way to go.

In our practice, this change requires management and key people to review how the organization earns money and delivers value. Often the discussion on how to organize teams around value streams requires changes in the team’s composition. This leads to the human factor and necessity to take this change carefully.

While the top level, or portfolio level, usually focused on value streams alignment, the other part of the organization should review roles, responsibilities and authority levels. Looking on the team and program levels, the need for coordination between teams emerges and, thus, different roles are needed. Nevertheless, these new roles should not be mapped directly to the old company structure. Built from the agility point of view, the duties list for these roles would include: serving, coordinating, and enabling as the primary drivers.

SAFe produces recommendations on what functions are needed on different levels. But like any other framework (LeSS, DAD or simple Scrum), SAFe should be used with care and deep understanding of why the role is needed and what value it brings to the enterprise.

Above organizing around value streams, it’s worth the reminder that an actual software development team is just an intermediate phase from the end-to-end value stream point of view. This makes dependencies on the upstream (usually product analysis and requirements preparation activities), requiring a seamless integration with the downstream (usually stabilization, packaging or deployment).

While both boundaries are meaningful, alignment with the upstream – and especially with business decisions – is critical. As our head of consulting mentioned once to a client, “There is nothing worse than having a great software development team with a great and optimized agile processes, doing wrong things.”

Such initial misalignment in practices makes it apparent that the organization should learn additional methods for content/requirements handling and practices at the program and portfolio levels to support agility at scale. As experience shows, it takes time for those responsible for the content of the product to adapt these methods to a degree where agile teams see the difference between before and now.

Furthermore, if your organization hasn’t had a rhythm of delivering working and demo-able product on team levels, it is risky to launch a joint program with many teams working together and call it scaled agility. The gravity of non-delivering could pull back any well-educated and well-coached organization.

A Program cadence (sometimes called “a release”) is a higher level of the rhythm and alignment achieved when business, content and delivery people can agree on what, when and how. Even if an organization plans their first-ever release cycle together with starting sprints on the teams level, still it would take time before management in charge of the “let’s-scale-our-agility” idea could clearly see benefits and results.

Something would go wrong, definitely.

It seems quite a clear path of activities that an enterprise goes through from decision to actual scaled agility:

  • Reorganizing around value streams;
  • Identifying the missing or new roles and responsibilities;
  • Embracing additional Backlog handling methods on all levels (Portfolio, Program, Team);
  • Achieving a rhythm of delivering working and demo-able results and then aligning on the high-level cadence such as a release;
  • Adapting continuous culture change and keeping up the momentum
  • Our observations show that even having a clear guideline and proven scaled agile framework in-hand, many companies will deviate and take this path differently.

One of the major obstacles has always been, and remains, company politics and old-fashioned culture that oppose the initiative of agility at enterprise-scale. Even with support from top management having a long walk to go, scaling agile challenges persons and ambitions, and causes fears and uncertainty with every decision.

One of the major signs will be a continuous culture change that regularly happens. Such a culture shift could manifest itself in small improvements handled by a team daily. Or it could be regular, healthy and actionable retrospectives, or in a high-level alignment that allows many people to plan together and deliver what’s intended, without a big overhead.

The motto that helps my colleagues and myself be patient on this is “Scaled agility is not the goal, rather a direction.” Thus, even being armed with clear steps and frameworks, we continue helping our clients incrementally to gain value from transforming to scaled agility by inspect-and-adapt all the way.


Posted in Agile Adoption, Agile Coaching, Agile Leadership, Agile Teams, Enterprise Agile, Scaling Agile | Leave a comment

The Next Generation of Project Management

Guest post by Chuck Cobb, Breakthrough Solutions/The Business Excellence Group

The concept of agile project management is very rapidly evolving and will have a significant impact on the project management profession, causing us to rethink many things we have taken for granted about what “project management” is for a long time.  However, we are in the very early stages of that transformation and there is a lot of confusion that exists in today’s world between the agile and traditional plan-driven project management (aka “waterfall”) communities. Many people see them as competitive and mutually-exclusive alternatives.  Some of the factors that contribute to this confusion are:

  • Many stereotypes and misconceptions exist about both agile and traditional plan-driven project management
  • Agile and traditional plan-driven project management principles and practices have been treated as separate and independent domains of knowledge with very little or no integration between the two
  • Agile and “waterfall” have been treated as binary, mutually-exclusive alternatives and many people make the mistake of force-fitting a project to one of those extremes

It’s no wonder that project managers and others might be confused by all of this!

A large portion of closing the gap that exists between the agile and traditional plan-driven project management communities can be attributed to a mindset change that includes:

1. Getting past a number of stereotypes and misconceptions that exist about both agile and traditional project management

2. Broadening our thinking about what “project management” is

Here are a few examples of the most popular stereotypes and misconceptions that exist about project managers:

1. Project managers are very “Command-and-Control” oriented.”

There is probably some reality behind this stereotype. Project managers are noted for getting results and sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams; sometimes that’s necessary.  Many times that behavior is expected of a project manager by the businesses in which they operate.  For example, if a project team is underperforming, the project manager is the one often held responsible and is expected to take corrective action to get the project on track.

2. Project managers are rigid and inflexible.

This stereotype also has some reality behind it, too. For many years, project managers have been held accountable for managing the costs and schedules of projects; and we all know that in order to meet cost and schedule goals, you have to control the scope of the project. That, in turn, requires a disciplined approach to managing change where change become the exception rather than the norm.

3. Project managers only know how to manage by the “waterfall” methodology.

The emphasis on managing costs and schedules for a long time has required accurately defining the requirements upfront, which leads to extensive use of “waterfall-style” methodologies that are based on trying to define project requirements in detail upfront before the project starts.  The emphasis on cost and schedule management is a significant reason why that approach continues to be used today.

4. Project managers are just not adaptive and cannot adapt to an agile environment.

I don’t believe that stereotype is correct, but it does require a significant shift in thinking for a project manager to make that adaptation. A good project manager knows that you have to adapt the project management approach to fit the problem rather than force-fit every problem or project to a single approach.

It should be apparent from all of these stereotypes that many of these behaviors are a function of the environment in which project managers operate, and are influenced by the expectations that businesses have of project managers. Creating a broader image of what project management is will also require influencing the environment and expectations on project managers.

Here are a few examples of the most popular stereotypes and misconceptions that exist about agile:

1. Agile projects are totally unplanned.

There is actually a lot of planning going on — It’s just a different kind of “just-in-time” planning that is more spread out through the project rather than being done heavily or totally upfront.  However, doing upfront planning is definitely not inconsistent with an agile approach. As an example, I was asked to rescue an agile project where, two years into the project, the project had no end in sight, and senior management had lost confidence that it would ever produce results. When we re-planned the project, we discovered that the scope of the effort was just too large to be done by a single agile team in any reasonable amount of time. If more upfront planning had been done, this problem would have been discovered much earlier.

2. Agile projects do not use any process and are totally uncontrolled.

That stereotype is also not accurate. Most agile projects use Scrum, which is a very well-defined process.  It’s a different kind of process – it is much more empirical and adaptive rather than rigid and prescriptive, but it is a well-defined process. It is also not difficult to apply whatever level of control you want to an agile project.  As an example, a few years ago I managed a large U.S. federal government project for the Federal Aviation Administration. We were able to create a hybrid model with a sufficient level of control to meet government contracting requirements, but at the same time provide a sufficient level of flexibility to further define detailed requirements with an agile development process.

3. There is no project management required for an agile project.

Although there may be no one with the title of “project manager,” in an agile project at the team level, there is plenty of project management going on.  It’s just a different kind of project management and the project management functions are distributed over a number of different people on the team rather than being held by one particular individual called a “project manager.”

  • The product owner in a Scrum project performs many project management functions by setting the direction and priorities for the project and making decisions as the project progresses; he or she is responsible overall for the success or failure of the project from a business perspective.
  • The ScrumMaster performs some project management functions by facilitating the team and the process, and is also responsible for removing obstacles that impede the team’s performance.
  • Everyone on an agile team performs some very basic project management functions in planning, estimating, and managing their own work, as well as tracking and reporting progress. Each member of the team as a whole must also coordinate and integrate all the activities of the team.

4. Documented requirements are not consistent with agile. Documentation is still useful in an agile project where it adds value.  Of course, documentation should not be done for the sake of creating documentation; however, there are many situations where it makes sense to document requirements in an online agile project management tool using a simple user story format as the project progresses.

In “The Next Generation of Project Management,” we need to:

  • Broaden our thinking about what “project management” is and think of it as a function, not a discrete role associated with someone called a “project manager,”
  • Develop a fully integrated agile project management approach that blends both agile and traditional plan-driven approaches in the right proportions to fit a given situation when necessary, and
  • View agile and traditional plan-driven project management approaches as complementary to each other rather than competitive

This is a significant challenge and will require a lot of new thinking, but it can be done.

It feels very similar to an evolution that took place when I worked in the quality management profession in the early 1990s. Up until that time, the primary emphasis in quality management had been on ‘quality control’ and inspection; the image of a ‘quality manager’ was heavily based on managing those functions.

  • The predominant quality management approach at that time was based on inspecting products before they were released from production prior to shipping to the customer and rejecting any that didn’t meet quality standards. It’s easy to see how that approach was inefficient because it resulted in a lot of unnecessary rework to correct problems after the fact and it also wasn’t that effective because any inspection approach is based on sampling – and it’s impractical to do a 100% sample. For that reason, this approach can result in a very mediocre level of quality.
  • A far better approach was to go upstream in the process and eliminate defects at the source by designing the process to be inherently more reliable and free of defects. That didn’t mean that the prior emphasis on quality control and inspection was obsolete and eliminated; it was just not the only way to manage quality, and wasn’t the most effective approach in all situations.
  • At the same time, “quality” took on a much broader meaning. It was no longer sufficient to produce products that were free of defects; producing products that were free of defects became just ‘table stakes’ to play in the game.  To be successful, companies really needed to go beyond that and produce products that really delighted their customers.

That was a gut-wrenching change for many in the quality management profession. Instead of being in control of quality and being the gatekeeper with the inspection process, a good quality manager needed to become more of a coach and a consultant to influence others to build quality into the way they did their work.  This changed the nature of the work dramatically for many in the quality management profession and eliminated a number of traditional quality management roles that were based primarily on the old quality control-and-inspection approach.  The similarity to the changes going on in the project management profession should be apparent:

  • Project managers needed to recognize that simply controlling the costs and schedules of a project was no longer sufficient; the project had to be successful from the perspective of producing value for the customer as well.
  • To be successful in more uncertain environments and focus on producing value, project managers need to be able to take an adaptive approach that is appropriate to the level of uncertainty in the project.
  • Finally, they need to give up some of the control that has become associated with the project management profession – in some cases, they may need to become more of a coach and a consultant to influence others rather than being in absolute control of a project.

This can dramatically change the role of a project manager and, in some situations, the role of a project manager as we’ve known it may no longer exist.  For example, at a team level in an agile project, you probably won’t find anyone with a title of “project manager” because the project management functions have been absorbed into other roles and are done very differently.  That doesn’t mean that project management is no longer important, but it may cause us to dramatically rethink what “project management” is in a much broader context than the way we may have thought about it in the past.[1]

About Chuck

Chuck Cobb is an Adjunct Professor at Boston University where he will be teaching a brand new, graduate-level course on agile project management. He is passionate about helping close the gap between the agile and traditional project management communities. To that end,

  • He has published two books on agile project management (a third book entitled “The Project Manager’s Guide to Mastering Agile” will be published in early 2015 by Wiley Publishing)
  • He has written over 50 articles on his blog site and has recently developed an online training course to help project managers learn how to develop an adaptive approach to project management that blends agile and traditional project management principles and practices in the right proportions to fit any situation

Chuck has worked with VersionOne for a number of years and has devoted a portion of his new book to using the VersionOne agile project management tool as an example of the importance of using tools in an enterprise-level agile project management strategy.

[1] Cobb, Charles, “The Project Manager’s Guide to Mastering Agile – Principles and Practices for an Adaptive Approach, Wiley Publishing, 2015

Posted in Agile Adoption, Agile Benefits, Agile Project Management | 3 Comments

Time to Celebrate with Great Reviews!

Someone recently asked me what one thing would make any company’s Agile transformation and adoption more successful? Almost before the question left their lips, I shot back – “great reviews, company-wide great reviews!” The most mature Agile organizations I’ve seen have regularly scheduled company-wide review meetings. These reviews are light on presentation and heavy on demonstrating working successes. The other positive factor for these review ceremonies is that they have active participation by managers, leaders and C-Level executives. These organizations regard reviews as sacrosanct, too important or valuable to be interfered with.

During my Certified Scrum Master (CSM) training a few years back, our class was struggling to find an answer to the Magic Management Metric question. The Metric that enables managers to say, “Ah-ha! Now I get this whole touchy-feely, self-organized Agile mindset thing.” Our instructor was a little put off by the idea that we needed to prove our worth and the value Agile brings to the powers that be at our respective companies. His terse final answer was that “If a leader wants to know what the team is doing, come to the review!”   After all, valuable working software delivered on a continuous basis trumps everything, doesn’t it?

Unfortunately, the reality is that the teams have become victims to our own self-crated Frankenstein’s monster. Most self-managed teams haven’t made it easy for leaders to attend even a handful of reviews. Each team plays by their own set of rules: some use two week iterations, some deliver daily but you can probably be sure that only 10%-20% of the reviews happen on the same day and even fewer happen at the same time.

This could be one of the driving factors towards the need for a more scaled multi-team view for agile delivery that is becoming more popular in the marketplace today. Process and program are seen as the glue that will bring various teams to communicate together. It’s not that companies don’t value individuals and interactions; they just value process and tools more, because the other way isn’t working too well.

The reality is that it is still desirable and possible to deliver customer value across self-organized lean teams, and many great companies are succeeding in doing so.   One way is by adopting regularly held All-Company Agile celebratory review meetings to help foster the collaboration and communication team need to be more effective. It’s still about the interactions and delivering working software. For any enterprise looking for a better way to radiate information on a consistent and customer focused way, here are some ideas to help your teams and leaders engage and execute healthy “All-In” review ceremonies:

  • Have ONE all-company review meeting; every team and every leader should be represented. This is sacrosanct, and it is the highest priority meeting on people’s calendars.
  • Teams need to synchronize their review cycles to a regular meeting cadence. This can be helped by having teams align to their iteration schedules.keep-calm-and-review-it
  • Have a set schedule order for who is speaking, but don’t over prepare. Keep it concise, but allow enough time to show each team’s results.
  • Each team gets an opportunity to demo their valuable customer working software during the review. Use collaborative online meeting options like GoToMeeting, if you have distributed teams.
  • When it makes sense, show your customer using the new and improved software. DevJam’s David Hussman recently recommended using your mobile devices to record customers demoing the software as a great way to accelerate Product Driven Learning. You don’t need a documentary, just live, real video feedback.
  • Reviews should be Agile method agnostic. You can regularly review the valuable accomplishments of SCRUM, XP and KANBAN teams at one time. It’s okay!
  • Cheering, hooting, clapping, and congratulations are encouraged. It’s called a celebration for a reason. Woot, Woot!
  • Feedback is encouraged, but even more important is having leaders engaged, present and observing what is and is not working and learning how to, as’s Leadership Engagement model shows, Encourage Monitor and Remove Big Impediments to support future team success.
  • Facilitate the time for feedback collection and Q&A to help keep the meeting on track. Use other creative methods like breakouts, note cards, or a simple post-review on-line survey to collect and report feedback back to the product owners and teams.
  • Course correcting is still reserved for the team-led retrospectives. Teams should regroup soon after the review, provide feedback and make tuning observations to improve future results. Then the actions should be shared, and provided to the appropriate levels across the org.

The interesting thing I’ve discovered from observing All-In reviews is that when everyone from the CEO down to the Summer Intern celebrates the wins of two weeks of effort, multiplied by many teams delivering substantial value to customers on an early and often basis, everyone wins. EVERYONE!

What types of actual results might you begin to see using ALL-IN reviews?

Team health becomes more transparent and the need for health-check driven metrics is reduced.   This increases the time available for productivity gains and the overall delivery team morale. Quality is more apparent, defects are reduced and the feeling that I should check my Facebook or LinkedIN pages at work goes down. Leadership’s motivation to remove impediments and understand “the system” and the knowledge of what is truly going on goes-up. And finally, the ability to achieve shared company-wide goals and demonstrate the ways teams are impacting customers in a positive consistent way is recognized and encouraged to thrive.

Tom Peters says you should “Celebrate what you want to see more of.”  Our highest priority should be to review team accomplishments, promoting even more success, more agility and more happy customers!

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management | 3 Comments

SolutionsIQ: Automating Application Development, SAFe, and Other Takeaways from AgilePalooza Seattle

“How do we get the servers to be as responsive as our software development?”

SolutionsIQ developer/coach Ben Tomasini asked this question last week at AgilePalooza in Seattle. It was just one of the many topics that he and a number of other speakers covered at the event. Attendees learned about system automation, scaling frameworks such as SAFe™ and some of the interesting ways that agile and scrum are being used at development organizations around the Seattle community.

Check out Ben’s ESPN highlights reel from the event:

For more information about SolutionsIQ visit the AgileIQ Blog.

Or go to to find out when the next AgilePalooza is coming to your area.

Posted in Agile Development, Agile Leadership, Agile Management, Agile Tools, Continuous Integration, Scrum Tools | Leave a comment

The Guide on the Side

I’ve delivered quite a few training classes over the last several years, most of them in how to effectively utilize Scrum and Agile tooling in the delivery of software. And yes, I’ve relied heavily on Powerpoint decks to get my message across, doing my best not to read from the screen, but deliver the information in an engaging way. If you’re a trainer, you know this can be a tough thing to do. You gotta be on, and know your subject matter inside and out. Without that, not much else matters. Once you’ve got that down, it’s a matter of conveying the message and helping the learners understand. How we do this varies. Much of it is our own personal style, and what we learned from someone else along the way. But here’s a dirty little secret… many of us trainers aren’t really professional trainers at all. We just know something so well that someone made the decision to throw us in front of people to share our knowledge.

I’ve seen some really good showmen/women as I’ve attended training classes over my career in IT. It’s a truly impressive (and sometimes entertaining) thing to watch; a performance really. They know their stuff, no referring to their notes, lots of eye contact, voice inflection and fluctuation, a few jokes thrown in for good measure, smooth flow and spot on timing. And we all clap at the end. Bravo! I aspired to be that polished.

But a colleague recently told me about this idea called ‘Training from the BACK of the Room’ based on a book of the same name by Sharon L. Bowman.

photoIn true Agile fashion, I tried it out in my Agile tool training classes. At first, it seemed uncomfortable to me. I had my old slide deck down pat and knew it well, so who better to share all that great information than yours truly? In my traditional training model, I was the ‘sage on the stage’.

But I vowed to really give this new thing a shot. I still used a Powerpoint deck, but the number of slides went from about 100 to 15. Training became more of a conversation, a series of exploratory exercises, and discussions afterward.

Rather than providing step by step instructions on how to perform a certain exercise, I’d give them a challenge, like…

  • Identify at least three help options in the tool.
  • Create two user stories. Name one ‘Add book to wish list’, and the other ‘Remove book from wish list’.
  • Create an Epic called Manage Customer Account
  • Create three child backlog items under that Epic called…

You get the idea here. I’d have similar challenges around Release Planning, Sprint Planning, blocking stories, closing stories, setting up notifications, creating and sharing conversations, reports, etc.

I get folks heavily involved in showing the class what they did and how they did it. Dig into their thought process. Recognize and appreciate that others may have done the same thing differently, but achieved the same result. Literally have them come up to the front of the class and drive on my laptop, showing us all how they did it (see pic above). I thought I’d have to call on folks to get participation, but I didn’t really. They mostly volunteer. They’re eager to share what they learn. I encourage folks to work in pairs (paired learning), but not everyone does, which is ok.

The feedback was surprising (to me anyway). Initially, I felt like I wasn’t really doing my job as a professional trainer. But folks loved this new format! The feedback forms (which were better than my previous classes) only told part of the story. In addition, people would come up after class and tell me they had never had a training course like this before. The majority of students really liked being engaged in this new way. To be fair, there was a minority that didn’t really care for it. I understand.

Oh, and yes, I literally did train from the back of the room (sometimes the side or front too). Most of my time was spent walking around, helping folks who got stuck or had questions about the exercises/challenges I gave them. The struggle is part of the learning.

At the end of the day, what I learned is that being the ‘sage on the stage’ is not as good as being the ‘guide on the side’. I know… it rhymes, but it’s true. We shouldn’t expect a performance from our trainers, or to sit in awe, as they impress us with all their knowledge and showmanship. That’s not the point. As students in a training class, our goal should be to learn something that hopefully helps us do your jobs better. As a trainer, it should be to help them learn. When they go back to their real job, they should be able to recall what they learned, and apply it to their own unique situation. As Trainers, we can make it stick by engaging students, challenging them, asking questions and guiding.

If you’ve attended training like this, what did you like (or dislike) most?

If you’re a trainer, have you seen this method applied to training other than ‘technical ‘or ‘tool’ training?

Posted in Agile Adoption, Agile Management, Agile Teams, Uncategorized | Leave a comment

Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method

There is rarely enough time or resources to do everything.  Therefore, agile teams must use prioritization to decide which features to focus on and which lowest rank-order features could be pushed out of scope when close to the end of a timeboxed sprint or release.  For agile development projects, you should linearly rank-order the backlog, rather than coarse-graining prioritization where features are lumped into a few priority buckets, such as Low, Medium, High, Critical priorities.  Linear rank ordering (i.e., 1, 2, 3, 4 ….n) avoids inflation of priority, keeps everyone honest, and forces decisions on what is really important.  It discourages the “kid-in-a-candy-shop” behavior when the business side clamors that everything is high-priority or equally important.

For agile and Scrum projects, the sprint backlog contains backlog items including stories, defects and test sets.  The scope of work for each backlog item is small enough to fit inside a typical short two- to four-week sprint.  Epics (large stories) present in a release backlog may not have been decomposed into stories during release planning; they will be decomposed during sprint planning.

The responsibility of agile prioritization is shared among all members of a team; however, the prioritization effort is led by the product owner.  Here, I will use the generic term “feature” to denote an epic or a story.  The context will make it clear if “feature” means “story” (in the context of a sprint backlog) or “epic” (in the context of a program or a portfolio, and release backlog).  Note that an epic rank order is separate from a backlog item rank order. Epics and backlog items are conceptually different, and should not be mixed or aggregated while developing a rank order.

In this blog post, I will present a simple but fairly comprehensive method to linear rank-ordering a backlog.  The method is extensible, customizable and very practical.

Let me start with a simple example.  Table 1 shows a sample backlog of five features (F1 – F5) along with each feature’s “Total Value” (Column B) and “Total Effort” (Column D).

Table 1: Sample backlog with Total Value, Total Effort,
Total ROI, and Rank Order


I will soon explain what I mean by Total Value and Total Effort.  The Total Value for features is estimated by the agile team; it is a relative number and not absolute (such as dollars).  Similarly, the Total Effort for features is estimated by the agile team; it is also a relative number, not absolute (such as ideal days or hours).  Relative numbers are easier to estimate than absolute numbers, and are adequate for agile prioritization.  The Total Value for all five features is 1,791, and the Total Effort is 14.  Percent Total Value (Column C) is calculated with simple math; for example, % Total Value of Feature F1 is (190/1791) = 10.61%.  Similarly, % Total Effort (Column E) is calculated similarly; for example, % Total Effort of Feature F3 is (3/14) = 21.43%.   Figure 1 illustrates the % Total Value and % Total Effort for each of five features, F1-F5, as two pie charts.  Note that, by definition, the full pie of either Total Value or Total Effort always represents 100% of Total Value or Total Effort.



Figure 1: % Total Value and % Total Effort distribution of
five features in the sample

Column F of Table 1 calculates Total Return on Investment (TROI, a relative number) for a feature as the ratio of % Total Value of the feature (Column C) to % Total Effort of the feature (in Column E).  This is an economic model that tells us how valuable a feature is based on its TROI.  Column G of Table 1 calculates % TROI for each feature; for example, for Feature F2, its % TROI is (0.87/5.72) = 15.18%.  Column H of Table 1 shows the rank order of five features based on their % TROI data.  F4 is rank-ordered # 1, F3 as #2, F2 as #3, F5 as #4 and F1 as #5.

What is the Total Value and how do you calculate it?  

I now present a comprehensive definition of “Total Value,” yet simple to calculate and very practical to use for agile projects.  First let’s start with the notion of value of a feature to its provider (the organization developing the product or solution).  This “Provider Value” consists of parameters, such as:

  • Revenue increasing parameters: Examples of these parameters are number of new sales, increase in market share, cross-sales or upsell opportunities, etc.
  • Other benefits parameters: Examples of these parameters are alignment with the product strategy, intellectual property (patents) creation, etc.
  • Cost savings parameters: Examples of these parameters are operational cost savings, customer support cost savings, etc.

Depending on your organization’s business and product, some these parameters may or may not be applicable to you.  If you are an IT organization developing solutions for internal use, “Revenue increasing parameter” is not very applicable or may need suitable modifications.

Donald G. Reinertsen has proposed a rigorous economic framework to prioritizing value delivery (“Principles of Product Development Flow, 2009”). He points out that, “If you quantify one thing, quantify the cost of delay (CoD).”  As Dean Leffingwell has pointed out, CoD of a feature is an aggregation of three factors: User Value, Time Value and Opportunity Enablement, Risk Reduction Value (“Agile Software Requirements,” Chapter 12, pp. 266-267).

  • User Value: The potential value of a feature (expressed in relative terms) in the eyes of the users.
  • Time Value: A relative estimate based on how the User Value decays over time. Features deliver higher value when delivered early, and a lower value when delivered later by the time the feature has become commoditized.  As an example, Time Value for “Implement new UI standard with new corporate branding” may be at best modest; on the other hand, “Implement new 2014 federal tax law provisions by Dec. 31, 2014” has an extremely high Time Value prior to Dec. 31, 2014 if you are developing a tax package for tax year 2014.
  • OR Value: Opportunity Enablement, Risk Reduction Value:
    • Opportunity Enablement: Work done on a capability for one or more features may be more valuable to us depending on how it helps us exploit new opportunities. As an example, “LDAP for distributed directory information service” capability implemented with one or more features may open up new opportunities in the future.
    • Risk Reduction: Risk is anything that hasn’t happened yet, but might, and would jeopardize the success of the project. As an example, work done on “Use an alternate component to deliver required performance” for one more features may be a good risk reduction approach.

Two works done independently by Noriaki Kano and Karl Wiegers are very interesting and can help us in agile prioritization by modeling agile value.  The Kano model, illustrated in Figure 2, shows how customer satisfaction changes with absence or presence of features, and the impact of feature enhancements on customer satisfaction.



Figure 2: The Kano model of customer satisfaction

  • Must-have, mandatory feature: There is low to moderate customer satisfaction for including the feature, but a high penalty for excluding it.  When this feature is present, user satisfaction remains low until a threshold is reached.  Thereafter, enhancing the feature produces a less-than-proportional reward.  The center point (the Present line in Figure 2) of this curve gives rise to the minimal marketable feature (MMF).  For a solution to be viable, it must contain some requisite set of MMFs.  However, enhancing an MMF will not produce a proportional economic return; i.e., gold plating this feature does not offer much value.  Typically, these features have either become a commodity (all competitors offer them), or they are required for some compliance or regulatory reasons.
  • Game changer, exciter, and delighter feature: This feature is unique, compelling and differentiated; even a small investment produces high customer interest and satisfaction.  There is high customer satisfaction for including the feature, but no or low penalty for excluding it.  Additional investment produces higher proportional satisfaction.  These features provide the greatest leverage for investment.  As an example, consider a car navigation device that gives accurate navigation guidance based on real-time traffic conditions, congestion, and accidents using “crowd-sourced” intelligence.
  • Linear performance feature: Investment in this feature returns proportionally higher user satisfaction; i.e., the performance is linear (see the diagonal line in Figure 2).

Note that with passage of time, ‘Game changers, exciters and delighters’ as well as linear performance features may become must-have features in a market that is intensely competitive, such as the mobile device market.  What is a game changer today (e.g., voice recognition or maps) may become a commodity feature in few years.

Karl Wiegers’ model (“First Things First: Prioritizing Requirements,” published in Software Development, September 1999) recommends an approach that is similar to the Kano model because it considers both the positive benefit of having a feature and the negative impact of its absence.

The User Value, as proposed by Reinertsen and Leffingwell, can be calculated based on the following two parameters inspired by the Kano and Wiegers models:

  1. Delighter parameter: User delightment for including the feature
  2. Penalty parameter: Penalty for excluding the feature

The information presented so far gives us a good foundation to define the Total Value.  Note that all factors or parameters in the equation below are estimated, relative numbers (not absolutes).

Total Value = Provider Value + User Value + Time Value + OR Value

Furthermore, Total Value can be based on parameter weights; i.e., it can be Weighted Total Value.   Table 2 illustrates how to combine all the above parameters into a Weighted Total Value model.

Table 2: Weighted Total Value Model


Each parameter can be assigned a Parameter Weight in the range of 0 to 10.  Weight value “0” means the parameter should not be considered (it has no weight or impact).  Weight value “1” means the parameter has the least weight (or impact), while “10” means the parameter has the most weight.  As an example, if the parameter “Increase market share” has a weight of 9, while parameter “LDAP for distributed directory information service” has a weight of 3, then the weight of “Increase market share” is three times the weight of “For distributed directory information service.”  If all parameters have the same non-zero weight (such as 3 or 8), the impact of the weight is identical and, effectively, parameters are not weighted relative to each other because they all have the same weight.

Parameter values reflect an agile team’s collective judgment or consensus based on the discussions between the product owner and the cross-functional agile team members.  Parameter value “0” means the parameter is not relevant for that feature in the row (the parameter has no importance).  Parameter value “1” means the parameter has the least importance, while “10” means the parameter has the most importance.

The Weighted Total Value for each feature is the weighted sum of products of parameter weight and parameter value.  For example, for Feature F237, the Weighted Total Value = (7*5) + (9*0) + (8*0) + (7*5) + (8*3) + (6*6) + (9*4) + (10*9) + (10*10) + (3*0) + (6*9) = 410.  The Weighted Total Value of all five features is 1,748.  Therefore, % Weighted Total Value for feature F237 is (410/1,748) = 23.46%.  Note that the Weighted Total Value for each feature is still relative.

Note that the Weighted Shorted Job First (WSJF) method used by the Scaled Agile Framework® (SAFe™) is subsumed by the TROI method proposed earlier.  WSJF captures only User Value, Time Value and OR Value.  It does not take into consideration Provider Value, an important part of the Total Value.  It neither requires nor precludes the weighted parameter model proposed in Figure 2.  It also does not specify how to calculate the User Value, and is not tied to the Kano or Wiegers model.  Thus, the Total Value model is more general than the WSJF model of SAFe.  You may choose a subset of the Total Value model to create the WSJF model, if that’s what you decide to do.

The TROI method can be subset to a very simple method of ROI = (User Value / Effort) or ROI = (Provider Value / Effort).  But it would be too simplistic to do so; ROI simply ignores the Time Value.  A higher ROI feature may be less sensitive to schedule delays than a lower ROI feature that is more sensitive; in this case, a simple ROI method will yield a wrong rank order.  So avoid using simple ROI method.  Both TROI and WSJF capture the cost of schedule delays.  As explained above, TROI subsumes WSJF.

What is the Total Effort and how do you estimate it? 

Agile teams usually take into account only development and testing effort for each feature, and estimate relative effort in story points.  I suggest that the team (consisting of cross-functional skills) takes into account not only development and testing effort, but also training (customer support staff training and customer/end-user training), delivery, deployment, operations and customer support for each feature.  Total effort needs to include not just development and testing effort, but all of the efforts listed above.  If a project is a small project of a single team that is largely stable, using story points will suffice.  Story points represent the relative estimated effort and serve as a good, reliable proxy for incurred cost or investment needed to develop, deliver, operate and support a feature.

For large projects with multiple teams (organized perhaps into programs and portfolios), story points estimated by each team must be normalized so they have the same scale and semantics; otherwise, combining story points across teams — or doing any math based on story points — does not have a well-defined meaning.  You may use the Calibrated Normalization Method to normalize story points across multiple teams of a project.  This method is applicable to backlog items as well as epics, even when epics are not broken down into stories.  Using the Calibrated Normalization Method, the estimated relative effort for all features (epics and stories) and workitems (defects, spikes, regression testing, reducing technical debt, etc.) can be expressed in a single, common currency of normalized story points, and has the same meaning across the whole enterprise.

Agile Prioritizer Template

I now provide a downloadable Agile Prioritizer template to make the math easier for calculating Total Value, Total Effort and Rank Order so you can quickly do agile prioritization in linear rank-order fashion.  The template has an instruction worksheet that shows how to customize the template for your specific needs.  You may subset the template if your needs are relatively simple.  As you fill out the Agile Prioritizer template, it will instantly provide you the rank order of features.

Product owners should treat this as their “first-cut rank order,” carefully reviewing all data calculated in white cells of the template to develop insightful understanding.  Pay close attention to what may seem surprising or unexpected.  Present and discuss this data to your agile team members.  If there is a need to change any information that you had entered in the template, go for it.  The template will immediately recalculate the rank-order information.  Final rank order should be recorded in Column D of the template by making any adjustments for dependency information recorded in Column F, and by applying your judgment.

Try to minimize dependencies among features as much as possible.  But a small number of unavoidable dependencies may remain for reasons such as:

  • System or resource constraints
  • If a specific sequence reduces the risk substantially than other possible sequence(s)
  • Business reasons
  • Reuse opportunities (design reuse, code reuse, knowledge reuse, etc.).

Any other changes in the rank order based on your judgment should be done and reflected in Column D, which indicates the final rank order of features in the backlog.  There may be other factors involved that may not neatly fit in the model of the Agile Prioritizer template, such as the latest competitive intelligence.  There is a definite role for human judgment; a good product owner or team demonstrates good judgment in producing the final rank order.

I would like to make the following key points as I wrap up this blog post:

  1. All prioritizations are local and temporal: Note that, by my definitions here, the Total Value of a feature is a global property of the feature, while Total Effort is a local property of the team implementing the feature. A feature with a lower-weighted total value may require less relative total effort from a specific team, and therefore, should be implemented ahead of another higher-weighted total value feature, if that feature requires more total effort from the team.  All priorities are inherently local.
  2. Prioritization changes as time goes on: Rank order of a backlog may need to be readjusted or recalculated at the end of a sprint, release cycle, or major event.  As features are added, deleted, revised, refined, groomed, and as more knowledge becomes available, it will be necessary to recalculate the rank order of a backlog. Game changer features may become basic-commodity, must-have features.  The Agile Prioritizer template makes the prioritization job easy.  Even the weight or parameter values may change.  And with experience, a team or an organization may decide to customize the Agile Prioritizer template differently. However, make sure that a rank order indicating linear priority does not create rigidity or reduce agility.  It should only provide guidance to the team in deciding what to focus on and what may be pushed out as the team approaches the end of the timebox.  Also, don’t prioritize too early; prioritize as needed, closer to “just in time.”
  3. Keep the TROI model simple: Although the Agile Prioritizer template is temptingly easy to extend by adding more parameters, resist that temptation.  A more elaborate model may not necessarily mean “more accurate” rank ordering.  It is adequate to pay attention to the parameters influencing the Provider Value, User Value, Time Value and OR Value as appropriate to your business and your situation.  But don’t overdo it.  You may even subset the model to match it exactly with the SAFe WSJF if you are working on SAFe projects, and need to follow the WSJF-based prioritization.
  4. Financial calculations are not required: Often business managers ask for specific financial information, such as how much expected revenue the product will generate, or expected cost savings. Those questions are much more difficult to answer, and are not essential to doing agile prioritization.  Relative Total Value and Relative Total Effort numbers are adequate and are easier to estimate as shown in this blog post.

I would love to hear from you on this topic: How do you to plan to use what you’ve learned here and the downloadable Agile Prioritizer template to better prioritize your work? Do you see a need to enhance or customize the template, and in what way?  Let me know either here, by email (, or on Twitter@smthatte.

Related Articles
The Agile Management Blog – VersionOne: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method | Project Management Buzz

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Scrum Methodology | Leave a comment

What is DevOps, Anyway?

We just got done moderating the latest webinar in the AgileLIVE series… “The Challenges and Rewards of DevOps.” The series started last week with Damon Poole, chief agilist at Eliassen Group. Damon did a really good deep-dive into What is DevOps? and we wrapped up today in Part 2 with Andy Powell and Ian Culling of VersionOne.

Here are some of the comments in my notes:

  • DevOps is inextricably linked to Continuous Deployment/Delivery/Everything.
  • DevOps automates and accelerates the build-test-deploy infrastructure.
  • DevOps reinforces that “working software in customers’ hands is the measure of DONE, not features that made it into the release.”
  • DevOps is a goal. You can’t just leap into it. It requires trust, people working closely together.
  • Ops often hears: “’Those dev cowboys’ want to deploy every minute of every day.” Ops is here to make sure nothing breaks in production. DevOps aligns ‘em.
  • For DevOps to work, it is critical to have really good collaboration and trust between development and operations teams.

But the most interesting comment I heard came over the Q&A panel from an attendee:

“Is DevOps infecting Dev people with Ops thinking, or is it the other way around?”

What do you think? Whether you are already rolling with DevOps at your organization, or just trying to learn  what is DevOps… we’d like to hear your opinions.  If you want a copy of the recordings for AgileLIVE: The Challenges and Rewards of DevOps, simply post a comment here and we’ll send them.

Posted in Agile Adoption, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile programming, Agile Teams, Agile Testing, Continuous Integration, Iterative Development | 5 Comments

Scaling Agile Your Way: How to Develop and Implement Your Custom Approach (Part 4 of 4)

In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management’s 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 (Tables 1-4 of Part 1).   I also 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.  SAFe and MAXOS represent radically different approaches to scaling agile. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  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.

In Part 3, I presented the Sweet Spots, Challenge Zones and Unfit zones for SAFe and MAXOS. Figure 1 in Part 3 illustrated the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presented similar information for MAXOS.  The Sweet spot indicates a good match between a scaling agile framework and all scaling agile parameters; consequently the implementation becomes easier, more efficient and effective.  The Challenge Zone indicates a challenging match between a framework and one or more scaling agile parameters, and requires more implementation effort compared to the Sweet Spot.  The Unfit Zone indicates a very poor (almost unworkable) match between a framework and one or more scaling agile parameters.

In Part 3, I explained why it is a good idea to get as close as possible to the sweet spot of your chosen scaling agile framework; it increases the likelihood that your pilot large-scale agile project will have fewer difficulties in succeeding. 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 root cause is likely to be one of these 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 their understanding and commitment to the success of scaling agile.

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

The journey from Unfit or Challenge Zone to Sweet Spot is 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 may still have a few areas in the Challenge Zone to address.

In this final part of my series, I explain a very important challenge for Scaling Agile Your Way.  It requires each team, program or portfolio to implement one or more key aspects of the chosen framework (whether the key aspect is in the Sweet Spot or Challenge Zone) in unique and customized ways.  I explain how the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be applied to SAFe to make it less prescriptive, “modularize” SAFe, and allow customized implementation of those modules.

The Scrum at Scale framework provides a general language for talking about how to scale Scrum.  At its roots, Scrum is an object-oriented framework.  Each role, artifact and ceremony is defined by the teams’ objectives, participants, inputs and outputs.  Core Scrum allows for many different ways to achieve objectives within given input/output constraints. Modularity allows organizations to establish and improve agile practices incrementally by focusing on one independent module at a time.  Scrum at Scale aspires to develop a “pattern library” of successful approaches that can be used in different contexts; this pattern library is being developed based on a crowd-sourcing approach.

Tables 12-16 in this post (see below) present 10 modules of the Scrum at Scale framework:

1.  Team-Level Scrum Process
2.  Strategic Vision
3.  Backlog Prioritization
4.  Backlog Decomposition and Refinement
5.  Release Planning
6.  Release Management
7.  Feedback
8.  Continuous Improvement and Impediment Removal
9.  Cross-Team Coordination
10. Metrics and Transparency

As the Scrum framework is object-oriented, each of these 10 modules has a set of well-defined goals, inputs and outputs.  It is up to each entity (team or business unit or organization) to implement each module in a way that best suits its own needs and constraints, so long as it produces the desired goals and outputs from a given set of inputs.  The details of implementing each module should be left to each entity, as the implementation details are expected to be different.  Each of Tables 12-16 presents two modules and explains how object-oriented implementation of each module is applicable to SAFe.

SAFe is characterized by its critics as too prescriptive; some of this critique may be fair while other is not.  Critics allege that because SAFe is (overly) prescriptive, it may not work well in many situations.  This prescriptive orientation (real or perceived) of SAFe can be reduced considerably by taking a strong, object-oriented approach in modularizing and implementing SAFe.  Instead of prescribing or specifying how different goals or ceremonies of SAFe should be implemented, why not follow the object-oriented approach of Scrum at Scale framework while implementing SAFe — where each module’s goals, outputs and inputs are emphasized while leaving the implementation details to each entity (team or program or portfolio)?  Of course, constraints arising from inter-team or inter-program coordination and synchronization must be met; even those constraints should be specified in terms of their goals — not by prescribing their implementation details (think of “object-oriented” constraints). 

Table 12:  Modules 1 and 2 of Scrum at Scale (Meta)-Framework
and its Application to SAFe



Table 13:  Modules 3 and 4 of Scrum at Scale (Meta)-Framework
and its Application to SAFe


Table 14:  Modules 5 and 6 of Scrum at Scale (Meta)-Framework
and its Application to SAFe


Table 15: Modules 7 and 8 of Scrum at Scale (Meta)-Framework
and its Application to SAFe


Table 16: Modules 9 and 10 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table16Customization needs and opportunities for the MAXOS framework

These will arise mostly in the context of implementing its advanced engineering practices of:

  • Code contribution
  • Automated testing
  • Continuous integration
  • Feature switches
  • Continuous delivery
  • Collecting and analyzing automated user feedback
  • Making use of cloud computing facilities on a massive scale, etc.

There are open-source and some commercial products available for automated testing, continuous integration and using cloud computing facilities for software development, testing and deployment.  I will not elaborate on MAXOS customization here.

How may an object-oriented implementation of SAFe (applying Scrum at Scale meta-framework guidelines, as explained in this part) suit your organization’s needs and constraints better than following SAFe “by the book?”  Besides the aspects of customization covered in Tables 12-16, are there any other aspects that come to your mind?  I would love to hear from you on these questions or any aspect of this four-part blog series, either here, by email (, 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

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

Posted in Agile Management, Agile Methodologies, Agile Metrics, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Scaling Agile, Scrum Methodology | Leave a comment

10 Things You Could Do When You’re Done Writing Code

So you’re two-thirds of the way through your iteration and there are no more development tasks to complete. Nice work! Understandably, your instinct is to pull another story into the iteration, but doing so has risks and disadvantages. When you add additional work into the iteration, you’re increasing the batch size. This causes additional complication due to increased changes in the code base. It usually results in carryover, which has a demoralizing effect on the team. And it eliminates an opportunity to get feedback on the emergent product before additional work is embarked on.

Remember, the iteration was planned so that all members of the team can function at optimum efficiency, not so that the developers can program at optimum efficiency (Yes, there is a difference).

Before you peek into your product owner’s backlog and working on something outside the iteration plan, have a look at this list and consider doing one or more of these things instead:

1.  Refactor something you recently wrote
2.  Add unit tests to an uncovered area of code
3.  Find a technical tutorial on the Internet
4.  Offer to pair with a developer on another team
5.  Estimate open items in the backlog
6.  Create some automated functional tests
7.  Clean your desk
8.  Ask your product owner about the next release
9.  Help your product owner create acceptance criteria for items in the backlog
10. Implement a prioritized improvement suggestion from the last retrospective

This isn’t an exhaustive list. What am I missing? Let’s see how many more items we can add to it. Give me your ideas in the comments, or tweet them – @johnkrewson.

Posted in Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile programming, Agile Software, Agile Teams, Extreme Programming, Iterative Development, Scrum Development, Software Craftsmanship | 6 Comments