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.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Scrum Methodology | 1 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

Corporate Values: Really Valuable, or Really Just a Poster?

You hear about the agile values and they seem to make sense, but what the heck is a value system? And how do you use value systems in your daily work? Do your values really help you do your job better, or are they really just a poster in your office kitchen?

When I say values, I’m talking about beliefs that guide behavior – as opposed to the term value meaning ‘the benefit of what is being produced.’ In software we use both “agile values” and “business value,” but they represent different things.

Corporate values have peppered company literature for ages.  These value statements are important expressions of the community and culture within a company.  In larger organizations, however, those values are often so abstract that it’s tough to impact a team’s work.

The notion of a value system to guide agile software development emerged in Kent Beck’s inclusion of values with the introduction of Extreme Programming (XP) in the late ‘90s.   A similar set of values was added to Scrum soon afterward. And soon after that, the Agile Manifesto was born. It brought software teams a straightforward value statement that today remains a powerful influence on the behavior and success of agile software development teams all over the world.

The concept of a human value system has been reasonably well studied in psychology since the ‘50s, but before 1999 (when Kent posed the question, “What is it that we value?”), developers simply didn’t talk about values – only the work at hand. People brought abstract, personal values in to work with them, which may have influenced behavior lightly.  This introduction of a value system was one of the most innovative parts of XP.  The XP values are Communication, Simplicity, Feedback, Courage and Respect. With the Agile Manifesto, that contribution expanded to the broader software industry and beyond, opening a new focus on behavior and improving the way we do things.

Let’s back up and define the agile values…

Watch this video: “The Agile Manifesto – 4 Agile Values Explained”

Sound familiar?

You’ve probably seen these agile values introduced in agile training, and they are easy to learn. They also read well on posters. But how do they affect you every day, every sprint, every release?

The utility of the value system is often lost to the intense focus on the agile frameworks and practices. Back when XP was still the most common agile approach, I gave a popular talk that included asking the audience, “What is XP?”  Invariably, it would take many minutes and an awkward silence after all of the practices were exhausted for someone to timidly mention the values.  Most certified Scrum people are not be able to articulate the Scrum values.  Of the roughly 150 words squeezed into the official Scaled Agile Framework® diagram, only one of values, Code Quality, made the cut (alignment, transparency, and program execution are the omitted three).  We have a long way to go to appreciate the important role that values play in enabling teams to be empowered to adapt their practices and maximize their delivery.

So, why are these values so important?  Aren’t we doing OK with the values being the footnote they are?

To see the answer, one needs to look no further than the frustration expressed around the dogma of agile.  A common complaint of Scrum team members is an almost irrational commitment to follow the rules of Scrum blindly.  Ironically, one reaction of the Scrum community to SAFe™ is that it is overly prescriptive in how organizations should scale Scrum.  In both cases, an increased focus and incorporation of the values leads teams to a better place.

In the absence of shared values to guide the adaptation of our practices, teams are left to resort to static rules to guide their behaviors.  We see silly arguments like “Should the Product Owner participate in the Daily Scrum?”  In the context of the Scrum values (Focus, Courage, Openness, Commitment and Respect), a team can answer that question easily and optimally by themselves.  We don’t need to enforce consistent practices, as long as teams apply the values to their situation.

Let’s explore some specifics 

The agile values system can guide daily decisions about working through problems with teams and individuals in a way that corporate values may not be able to.  Any problem we are trying to solve can be addressed with more rules and process, more contracts, more documents, more upfront planning.  Those are our traditional, comfort-zone, status quo solutions.  I can almost guarantee that in an early sprint retrospective with a new agile team, some of the feedback will be, “Had we spent more time documenting up front, we would not have had this problem.”

There will be times where those items “on the right” in the Manifesto will be part of the solution to our challenges.  But a commitment to our values will drive innovative solutions that better support our use of agile.  Examples include the increased use of tele-presence technology with distributed teams — reconstructing our workspaces, reconfiguring teams, and even relocating people — and collaborating with people we didn’t even realize were involved in, or affected by, our work.  The values will guide us to solutions that enhance agile, rather than contradict it.

One of my favorite examples where the values guided the solution to a problem was an SDLC compliance change at a very large financial services company.  Existing SDLC practices required numerous artifacts to be delivered within each phase of a project.  Requirements documents had to be signed off during the requirements phase, prior to design, etc.  The agile advocates needed this process requirement changed to empower agile teams to deliver shippable increments in each sprint.  But this needed to be done in a way that was still compatible with the majority of project teams who were still following the phased approach.

So, rather than create a big conflict, demanding that the whole process be changed, a simple change was made.  Audit artifacts are still required for the business, but teams have discretion as to WHEN artifacts get produced.  All of the artifacts are required when they close projects, but the team decides when it is optimal to do it. They don’t have to sign off on a Requirements document in the beginning of a long plan. Requirements can be modified over time, and they can furnish a signed-off Requirements document at the end. This moved the organization closer to the Individuals and Interactions value, while respecting the importance of Process and Tools in the broader organization.  A dogmatic stance on Scrum practices would not have been so open to that solution.  Later, further updates gave teams more discretion of WHICH artifacts were valuable enough to produce, further empowering the teams for continuous improvement.

So, the next time you’re in your Daily Scrum or Retrospective – or even just solving a problem – reflect on what is being talked about. How are teams and individuals working together to identify solutions? As you move across release and process design (teams and programs), pull out the agile values and assess whether your decisions and those of your teams reinforce the agile values or diminish them. Are they helping the organization make decisions that drive working software?  Use the values to guide your solutions and improvements.  If values aren’t helping people do their jobs better, why bother? At that point, they are just poster fodder!

Posted in Agile Adoption, Agile Leadership, Agile Methodologies, Agile Software, Agile Teams, Extreme Programming, Scrum Methodology | 3 Comments

15 Useful Pacts for Agile Teams: An Agile Team Creed

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.

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.

Posted in Agile Adoption, Agile Leadership, Agile Management, Agile Methodologies, Agile Teams, Scrum Methodology | Leave a comment

Super-Sized Agile

Guest post by Bob Schatz of Agile Infusion, LLC

agile-infusion-bob-schatzThe 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?”

Posted in Agile Adoption, Agile Development, Agile Portfolio Management, Agile Teams, Agile Tools, Distributed Agile, Scrum Development | Leave a comment

Why is it Called an Agile Transformation?

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.

Posted in Agile Adoption, Agile Management, Scaling Agile | 2 Comments

So You Want to Scale Your Agile?

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“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.


Posted in Agile Development, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology | Leave a comment