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 www.IllustratedAgile.com’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 | 2 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 agilepalooza.com 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.

http://trainingfromthebackoftheroom.de/

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

Table1

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.

Fig1

 

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.

Fig2

 

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

Table2

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 (Satish.Thatte@VersionOne.com), 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

Table12

 

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

Table13

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

Table14

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

Table15

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 (Satish.Thatte@VersionOne.com), or on
Twitter @smthatte.

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

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

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 | 5 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