Scaling Agile Your Way: SAFe vs. MAXOS (Part 2 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 developing a product or a solution has a unique context:  assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.

In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:

1.  Teams
2.  Customers/Users
3.  Agile Methods and Environments
4.  Product/Solution
5.  Complexity
6.  Value Chain (see Tables 1 through 4 of Part 1 of this blog series)

Each scaling agile parameter can assume one or more values from a range of values.  This comprehensive (but by no means, complete or exhaustive) list of 25 scaling agile parameters suggests that the agile scaling space is complex and rich with many choices.  Each organization or large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique.  However, in Part 1, I also clarified that “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise).  Systems thinking is important for Scaling Agile Your Way.

In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.  Although there are differences among SAFe, LeSS and DAD, they all are radically different from MAXOS.  In this part of the series, I will compare and contrast SAFe vs. MAXOS in some depth.

Briefly, here are the key highlights of SAFe.  Details can be found at Scaled Agile Framework:

  • SAFe requires a “Portfolio, Program and Teams” hierarchy for a large-scale agile project.
  • Each team must be a cross-functional Scrum team and may follow many XP practices.
  • Epics at portfolio levels are managed as a Lean/Kanban flow.  Epics are broken down into features that can be completed in a single release cycle at the program level; each feature is broken down into stories that can be completed in a single sprint at the team level.
  • All teams in a release train of a program must follow the same lock-step sprint cadence (typically two weeks).
  • Release train planning requires all team members (typically up to 150) from all teams in a program to hold two-day-long release planning meetings in person, which entails a substantial effort and complex logistics.
  • Release cycles are typically eight to 12 weeks long.
  • Software is developed on sprint cadence, and released on demand (but cannot be released faster than the sprint cadence).
  • Considerable time and effort is spent in various ceremonies:  sprint planning, sprint review and sprint retrospectives, release train planning across multiple teams, release review and release retrospectives, etc.

Briefly, here are the highlights of MAXOS.  Details can be found in Andy Singleton’s Agile 2014 presentation.

  • MAXOS is the scaling approach for “Continuous Agile.”  Continuous Agile combines Kanban Agile task management with continuous delivery code management. 
  • MAXOS requires a number of (almost) independent service teams.
  • Services have well-defined APIs, are loosely coupled, and have minimal dependencies among them.
  • Each team operates with Lean flow.  Applications are rapidly composed of a group or a network of services.
  • Each team is developer-centric (not cross-functional) and highly empowered.
  • Code is continually integrated in a single code base across all teams.
  • Code is continually tested with automated tests (unit, acceptance, regression, etc.) by firing off as many virtual machines as needed in a cloud-based environment.
  • Any dependency issues across teams are immediately resolved via rapid team-to-team communication.  For rapid team-to-team or member-to-member communication, tool support is essential. VersionOne provides excellent communication and collaboration among team members.
  • The typical ratio of developers to testers tends to be 10:1, as teams are developer-centric and developers do most automated testing.   There are no separate QA teams.  QA testers are called as needed for their expertise by developer-centric teams.
  • Each empowered, developer-centric team decides when to release its code (not decided by QA testers or product managers!).  MAXOS claims that this policy rationally aligns the interests of developers with consequences of their release decision; poorly written, poorly reviewed, or inadequately tested code may mean “no weekends” or “No Friday evening beer” for developers!
  • All features or stories have switches (togglers) that the product owner (called story owner) decides to turn on (unblock) or turn off (block) based on the market needs.
  • Code released in production is extensively supported by automated user feedback collection, measurements and analysis that result in actionable reports for product management.
  • Automated feedback from production environment is also used directly by developers to immediately fix problems.
  • Meeting time is minimized by “automating away” management meetings, and removing or reducing other Scrum ceremonies.  For example, sprint and release retrospectives are replaced by periodic “Happiness Surveys” and taking actions based on those surveys.

Because of these fundamental differences between SAFe and MAXOS, they represent radically different approaches to scaling agile. The contrast between SAFe and MAXOS is breathtaking, and its implications are worth understanding.  Tables 5-10 present the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

These six tables (Tables 5-10 below) follow a specific color legend described below:

B_Legend

Table5a

Table6a

Table7a

Table8a

Table9a

Table10a

Are your agile projects closer to the SAFe Sweet Spot or the MAXOS Sweet Spot? 

Or are your projects closer to the SAFe Challenge Zone or the MAXOS Challenge Zone?  Or are you in a situation where neither SAFe nor MAXOS will serve you unique agile scaling needs? If you are exploring the use of LeSS or DAD framework, I would encourage you to use the list of 25 scaling agile parameters to identify the Sweet Spot, Challenge Zone and Unfit Zone for LeSS or DAD (as I have done in Tables 5-10 for SAFe and MAXOS). Then determine if your projects are closer to the Sweet Spot or Challenge Zone of LeSS or DAD.

I would love to hear from you either in the Comments below, by email (Satish.Thatte@VersionOne.com), or on Twitter @smthatte.

Related posts:

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

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

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

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Lean, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly (Part 1 of 4)

Consider these five very different types of organizations:

1.  An organization with fairly hierarchical management structure, traditional Project/Program Management Office (PMO) trying to transition from traditional waterfall development to agile development.  Some teams have just a few months of experience with Scrum, and perhaps worked with few XP or Lean practices.  Budgets are done on an annual basis.  Senior management pays lip service to agile transformation and treats agile as a silver bullet.

2.  A government contractor is used to delivering projects on a fixed-price basis.  The government agency has now asked the contractor to use agile methods for large-scale agile projects.

3.  The CIO and CEO of an enterprise are strongly committed to agile-lean development and have given a top-down marching order to follow agile methods.  All teams have been ordered to follow a two-week iteration cadence, while members of some teams come from an offshore outsourcing vendor.

4.  A company has found that their main competitor will be Amazon.com.  The release cycle for most of its IT projects is six months, and they know that unless they drastically reduce this, Chapter 11 is not far away.

5.  A startup company realized that unless they validate their assumptions about who the real customers are, and what the real needs of real users are, they have no viable business.  They decide to follow the Lean Startup method by rapidly developing a series of Minimum Viable Products (MVPs) in rapid succession.  Even after the first release of the product, the company must stay ahead of competition and deal with rapid changes in market conditions.

With the vast diversity of organizations and their projects, a cookie-cutter approach (or prescriptive recipe for all types of projects and situations) will not work.  Each agile project developing a product or solution has a unique context: assumptions, situation, team members and their experience and skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.

No_to_straight_jacket_agile

Many agile development teams now have some experience of team-level agile practices using Scrum, XP, Lean, Kanban or Scrumban frameworks.  Some of these organizations have experience with Scrum of Scrums (that is, two to as many as nine Scrum teams working together on a product or solution). These teams and their organizations are now setting their horizons to undertake large-scale agile projects where several (10 to 1,000) teams must collaborate to implement the common vision of a product or a solution.

In the last few years, there has been increasing interest in scaling agile-lean methods beyond individual teams or Scrum of Scrums to programs and portfolios of teams, as well as being able to compose new applications by stitching together a set of services developed by independent teams.  The recent Agile 2014 conference had numerous presentations on the topic of scaling agile.  I attended as many of them as my schedule allowed, and caught much of the rest as recorded sessions.

Many of these sessions raised the issue of ‘which scaling agile framework is best?’ I came away thinking that every large-scale agile project creates a unique situation. To tackle this question, there are really two broad approaches you can take to select the right agile-lean process for your project:

APPROACH #1: Select a well-known, scalable agile framework listed below.

A. Scaled Agile® Framework (SAFe™) by Dean Leffingwell and his associates at Scaled Agile Inc.
B. Large-Scale Scrum (LeSS) by Larman and Vodde
C. Disciplined Agile Delivery (DAD) and Agility at Scale by Scott Ambler and his associates
D. Matrix of Services (MAXOS) by Andy Singleton

If necessary, extend or adapt or customize the framework to suit your unique needs. As you gain experience, inspect and adapt for ongoing refinements and further customization. “Scaling Agile Your Way” does not mean that each new large-scale agile project must develop its own agile processes from scratch.

APPROACH #2:  Develop a customized approach from scratch.

Or, if your project has truly unique needs that cannot be satisfied by any available framework (such as SAFe, LeSS, DAD, MAXOS) even after customization of the framework, you may need to develop a set of new processes from scratch customized to your unique needs, and then sustain and maintain those processes.

In many organizations, not many in-house people have this kind of expertise that would actually work.  Moreover, this approach would be expensive and may not be cost-effective.  As such, this approach to large-scale agile projects should not be undertaken on the ground of ideological purity, but should be based on solid business reasons.

It is important to state what “Scaling Agile Your Way” does not mean.  It does not mean that each team in a program is free to choose and optimize its own agile method, practices, cadence, release duration, metric and reports, etc., without any coordination with and consideration of other teams in the program.  If this were done, although each team may end up optimizing its own way, that may ignore what is good for the higher level program.  Similarly, optimizing at the program level without any regard to the higher portfolio or enterprise level is not “Scaling Agile Your Way”.   Those kinds of decisions (disregarding the system level optimizations and trying to optimize only at a subsystem level) might amount to “Agile my way or highway”, irrespective of Approach # 1 or # 2 described above.  Systems thinking is important for Scaling Agile Your Way.

This blog series is not a tutorial on or an in-depth review of SAFe, LeSS, DAD or MAXOS.  I will provide a brief overview of these frameworks for getting started.  I will then present a set of 25 scaling parameters (organized into 6 scaling aspects) that need to be considered to decide what scaling approach and methods are best suited for your specific situation, and what kind of customization will be needed.

SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects.  It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners.  SAFe is a proven and publically available framework for applying agile-lean practices at scale.  Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe.  I will cover SAFe’s Sweet Spot, Challenge Zone and Unfit Zone, and give examples of how to customize SAFe for your situation in this blog series.

SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects.  In some situations, SAFe is a good fit (Sweet Spot), while in some other situations, SAFe may be in a “Challenge Zone” where some effort (such as enhancement and customizations) will be needed to overcome those challenges.  But even with that effort, you may be better off using SAFe, compared to developing your own set of agile processes and practices from scratch.  However, in some situations, SAFe may be in an “Unfit Zone,” i.e., it is either not applicable or will not work well.  Full disclosure: I am a certified SAFe Program Consultant (SPC).

MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams.  All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment.  MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and Edmunds.com.   MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology).  MAXOS offers a radically different approach to scaling agile compared to SAFe.  MAXOS also has its own Sweet Spot, Challenge Zone and Unfit Zone, as I will explain in this blog series.  The Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS are very different.  The contrast between SAFe and MAXOS is breathtaking.   If your competition has started to use MAXOS and you are still using SAFe, your competition couldn’t be happier!  On the other hand, if you insist on using MAXOS in situations where SAFe excels, you would be making a poor decision.  Many practices from MAXOS (such as test automation and continuous integration) can be incorporated within SAFe.

At present, MAXOS doesn’t seem to have formal training and certification programs.  I attended MAXOS presentation by Andy Singleton at the Agile 2014 conference, and have reviewed most of the public information about MAXOS, including the eBook on Continuous Agile method.

LeSS: LeSS is regular Scrum applied to large-scale development.  LeSS is developed by Larman and Vodde.  A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions.

DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues.  The DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable.  DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.

Although there are differences among SAFe, LeSS and DAD, those differences are dwarfed by their differences from MAXOS.  For example, while SAFe, LeSS and DAD are predicated on cross-functional teams with a number of meetings required, MAXOS advocates developer-centric, highly empowered teams (developers, not QA, decide to release!), and “management automation” to eliminate many meetings.  As LeSS and DAD are not as popular as SAFe at this time, I will not cover them further in this blog series.

You can use the Agile Scaling Knowledgebase (ASK) decision matrix to access a template for comparing SAFe, DAD, LeSS and other scaling agile frameworks.

SAFe and MAXOS cover a fairly large territory of vastly different types of large-scale agile projects.  Once you understand SAFe and MAXOS, and your own unique situation, you may be better off using one of those (with appropriate customizations as needed), rather than creating one from scratch and sustaining your own custom agile processes (an expensive and risky proposition).

There may be unusual situations where neither SAFe nor MAXOS may be a good fit for a large-scale agile project.  I will cover this topic in Part 3 of this series.  If you believe that your large-scale agile project has unique requirements that render both SAFe and MAXOS totally useless, and you have no choice but to create, maintain and sustain your own custom processes for your large-scale agile project, please let us know.  I would be very interested to know about your unique situation and what led you to prefer custom processes from scratch.

Customization approach:  Scrum at Scale (meta)-framework developed by Jeff Sutherland and Alex Brown starts with the basic premise that Scrum is an object-oriented framework.  Scrum at Scale framework is aimed at extending Scrum for large-scale agile projects, while retaining Scrum’s object-oriented architecture.  Scrum at Scale framework, along with its pattern library, are aimed at allowing agile projects to develop their own unique and customized methods for scaling Scrum to large-scale projects.  In Part 4 of this blog series, I will explain salient aspects of Scrum at Scale, and how its object-oriented approach may be used for customizing SAFe for your own unique needs.

Agile Scaling Aspects and Parameters:  Any large-scale agile project needs to consider a number of scaling parameters in order to decide which scaling framework would be most appropriate for its unique needs, or whether it needs a totally custom set of agile processes.  Table 1-4 shows a set of 25 scaling parameters, grouped into 6 scaling aspects:

1.  Teams

2.  Customers/Users

3.  Agile Methods and Environments

4.  Product/Solution

5.  Complexity

6.  Value Chain

The list is a fairly comprehensive, but by no means, exhaustive.  If some of the 25 parameters are not appropriate for your large-scale agile project, you need not consider those parameters.  If any scaling aspect or parameter is missing from the list, please let me know.  Each scaling parameter may take one more values from range of options. For example, “Number of teams” parameter associated with “Teams” scaling aspect has a value in the range of 10 to 1,000.  “Composition of teams” parameter associated with “Teams” scaling aspect can select a value in its range of options: Developer-Centric, Somewhat Cross-Functional with Guest Experts, or Fully Cross-Functional.  Multiple options can also be selected as long as they are not contradictory.  For “Composition of teams” parameter, only 1 out of 3 possible values can be selected.  On the other hand, for “Agile method of choice and required tool support” scaling parameter of “Agile Methods and Environment” scaling aspect (see Table 2), multiple choices are possible, such as Scrum, Scrumban, and Scrum+Lean.

Many of 25 scaling parameters are considered by ASK, DAD and Scrum at Scale frameworks.  Tables 1-4 use the following legend to indicate which scaling parameter is covered by ASK, DAD or Scrum at Scale.

  • A:  ASK
  • S: Scrum at Scale
  • D: DAD/Agility at Scale

Note that some of the 25 scaling parameters are not covered by any of these frameworks.  For example, “# 5. Composition of Teams: Fully Cross-Functional” scaling parameter is covered by all A (ASK), S (Scrum at Scale) and D (DAD); while “# 5. Composition of Teams: Developer-Centric” scaling parameter is not covered by ASK, Scrum at Scale or DAD.

Table1b

Table2b

Table3b

Table4

As you review the information in Tables 1-4, you will realize that the “scaling agile” space is complex and very rich with many choices.  Each organization or a large-scale project is likely to select a different combination of these scaling parameters as relevant; moreover, the value or range of values for each scaling parameter for a project or an organization is likely to be unique.

What agile-lean scaling approach are you considering: SAFe, LeSS, DAD, MAXOS, or something else?   What are your customization needs, and does your selected approach fit well with those needs?  I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com). I’m also on Twitter@smthatte.

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

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

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

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

7 Things I Validated in My First Month With VersionOne

What’s your lucky number? In June, I attended the Agile West BSC/ADC conference in Las Vegas and didn’t do so well at the roulette table; however, two months later on 7/21/14 (lucky 7s) I placed an even bigger bet; not on red, but on Pantone Color Number 216. It’s the signature color of VersionOne, the all-in-one agile project management tool and services provider.

After almost seven years of building up my agile acumen at Cars.com, I decided that it was time to close that season of my career, and I began researching and planning my next career challenge. I outlined three key pillars that were very important to me and my ability to truly enjoy going to work every day:

  • Customer Centric Vision – Having the ability to know WHY what we do matters to customers, and matching values and alignment to priorities.
  • Clear Agile Direction – Finding a company who is moving the agile ball further down the line.
  • Fun and Innovative Culture – Life is too short and if you are going to work hard, it makes it much easier to find the joy in your job if you have fun doing it.

These were the most important traits I was seeking in part because they were the things that made me love being at Cars.com. I plugged into my network, had some interviews (and one offer that didn’t work out), and continued my quest to not settle until I found a career that valued these same traits. Then, just when I thought that finding my career “Match.com” was out of reach, I found an opening for a Chicago-based Product Speversiononecialist that turned out to be the perfect blend of vision, direction and fun.

Luckily for me, it was also at a place I knew very well, VersionOne. After a few interviews and a relatively painless courtship, I accepted the position and can report that so far it has been a jackpot payoff.

Since my start at VersionOne, I have validated or learned seven key things that I believe you can also learn from, no matter where you work:

  1. The customer is king (or queen); however, not everyone is a customer – If the slipper doesn’t fit, you can’t force it!
  2. Community is very important – Sometimes a company does things because it’s for the greater good.
  3. You can’t fake culture – If you’ve got a great culture, you’ve got it. Hang onto it.
  4. Agile is a mindset, not a methodology – Like culture, the question is not “Are you Agile?” but rather, “How Agile are you?” If you aren’t sure, take this Agile Development Quiz.
  5. Cold beer, anyone? A cold beverage and a game of pool after work is still a great way to end the day. When they say “Work Hard, Play Hard,” believe them!
  6. Valuable training is essential – Among the many other benefits, new-hire training as a group bonds people together and to the company.
  7. VersionOne is a great place to be because of the people, agile project management products and services to help companies achieve agile success, as well as VersionOne’s commitment to the agile community at large.

Going into my Product Specialist position I tried hard to find red flags, indicators that would give me some warning or reason to pause. At the end of the day, every flag I saw was Pantone 216. It’s my new lucky number!

I hope you find your lucky number, whether it’s a career at VersionOne, a business engagement with us, or something totally unrelated!

Read more on my personal blog at a12p.blogspot.com.

 

Posted in Agile Adoption, Agile Methodologies | Leave a comment

This is Way Better Than the Ice Bucket Challenge!

If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.

But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.

I posed this question:

What’s the Best Way to Spend 10 Minutes?

Let’s think about this for a minute…

You could:

  • Ice-bucket challenge someone
  • Set a stapler in a Jell-o moldStapler
  • Crash someone’s Facebook by inviting them to Candy Crush
  • Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
  • Load a DVORAK driver onto a PC with a normal keyboard
  • Clean those 24 sticky coffee rings off your desk
  • Assign a bunch of fake stories to people

But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.

Why?

2014_SOA_banner_300x250

“The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”

– SD Times Editor-in-Chief David Rubinstein

Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.

If you take it, you get:

  • Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
  • Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
  • Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes

What are you waiting for? Take the State of Agile survey now.

take survey now image

 

Posted in Agile Adoption, Agile Development, Agile Management, Agile Methodologies, Agile Software, Scrum Methodology | Leave a comment

Bouncing Agile: How Google Analytics is Related to Agile Success

It was a normal day.   I was reading articles, blogs, emails, Tweets, stories and a host of other types of information.  While perusing an item, there was an interesting link and I clicked into another Web location.  When I arrived, the newly presented topic was not what I expected so I navigated away from the site.  Little did I know, this interaction was most likely recorded by Google Analytics as a “Bounce.”

Google states that, “Analytics helps you analyze visitor traffic and paint a complete picture of your audience and their needs.”  Things like Page Views, Average Time on a Page, Entrances and Exits are tracked for behavior.  However, the most interesting metric could be the Bounce Rate.

BouncingBalls

“The Bounce Rate is the percentage of single-page sessions (i.e., sessions in which the person left your site from the entrance page without interacting with the page).”  In other words, they were attracted to a specific page and when they arrived, they left the site without interaction.  The lower the “Bounce Rate,” the longer they interacted with the page and the site.  According to Google, “If you could only choose one metric to look at, Bounce Rate might be your best choice.”

So how does this relate to agile development and agile success?  Similar to a Web page or site interaction, a team with a high “Bounce” rate will not be as productive as one that is stable and has stayed together through more than just a short introduction.  When people are added or removed on a regular basis, there is not time to understand the full scope of work or the people involved in it.

Medinilla states, “The principle of assigning projects to teams assumes that some team stability is needed.  If you are changing team composition every 2 weeks, you are essentially managing a resource pool in disguise.  On the other hand, if you are using agile development’s definition of a ‘team, ‘which is more than a group of people commissioned to do the same job, you’ll need some time for the team to ‘glue’ or, as some experts call it, ‘gel together.’”  (Medinilla, 2012)  It is this unnecessary change, or “Bouncing” that causes confusion, demotivation and poor results in the area of agile success.

There are many benefits to making an agile team stable, one of which is learning.  Alistair Cockburn (2006) asserts, “Novices don’t stay novices forever.  People who are novices on one project become experienced by the end of the same project… This ability to learn along the way helps many projects.  Within a single project’s timeframe, the people learn new technology, new problem domain, new process, and how to work with new colleagues.  Often an agile team struggles through the first 2 increments, becoming stronger and stronger until successful results at the end are almost a given.”  Bouncing from team to team and project to project doesn’t allow enough time to learn technologies, domain knowledge, processes and characteristics of people.

To help track the Bounce Rate of your agile team, Ekas & Will (2013) have recommended a metric: “Validate that you have a whole team; track the team membership each iteration, beginning with the first iteration; and review it regularly.  Confirm that the whole team starts together and finishes together… if the goal is to have stable, dedicated agile teams, then having an indicator immediately available to confirm that this happens can be a big incentive.“

For example:  A team of 5 people starts Iteration 1 with a whole team and completes it with the same 5 people so the Team Bounce Rate is 0%.  Iteration 2 starts with 5 but ends with 4 so the Team Bounce Rate is 20% and the Team Bounce Rate trend after 2 iterations is 10%.  Compare this trend to velocity or throughput after each cycle for evidence of them being connected.

JumpingForJoy

Success with agile development can be measured as a form of bouncing.  Both people and process can be affected by it.  Just as when a reader will try a certain link and bounce back out before truly understanding the main points of the page, so time is a factor in allowing teams to come together properly.

Give your teams a chance to gel.  Give them a chance to learn.  Give them a chance to be successful and maybe the bounce rate will turn into a jump for joy.

References

Cockburn, A. (2006).  Agile Software Development:  The Cooperative Game.  Upper Boston, MA:  Pearson Education.

Ekas, L., & Will, S. (2013).  Being Agile:  Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”.  Upper Saddle River, NJ:  IBM Press.

Medinilla, A. (2012).  Agile Management: Leadership in an Agile Environment.  Heidelberg, Germany:  Springer Science & Business Media.

Posted in Agile Development, Agile Management, Agile Metrics, Agile Project Management, Agile Software, Agile Teams, Agile Velocity, Iterative Development, Scrum Methodology | Leave a comment

Scaling Agile: How Do You Scale from Projects to Programs?

Guest post by Johanna Rothman of Rothman Consulting Group

You have some agile teams who are successful. Good for you!

Now you have a strategic project that will require many agile teams to create a program. You know you need people in several locations. You know you need a cross-functional business team to make sure you address the needs of Marketing, Sales, and even Legal. How the heck can you make this happen?

In the agile project management literature, there is a notion of program management. A program is a collection of projects with one business objective. Each project might have its own deliverables. But the real value is in the program. The sum of all the projects is greater than any of the parts.

How do you scale from an agile project to an agile program without a lot of hierarchy?

What is the Most Efficient Network in Your Organization Right Now?

When I talk to people about scaling agile, I ask this question:

If you want to move information in your organization fast, what do you?

What is the most efficient way to move information in your organization? People often smile and answer, “The rumor mill.”

People in your company have informal networks. They talk to each other. They help each other. They connect to each other in any number of ways which managers don’t know about. You can use these connections to help agile programs succeed.

“When I discovered that one of the testers needed a little help building an automated test framework, I took 15 minutes and did a screen-share. I showed her how I had started our framework for our testers. It wasn’t exactly what she needed, but it was a start for her.

She understood where I was going. She took that framework, improved on it for her team, and got them going on their own framework. It took me 15 minutes. That’s all. Now, they have their own framework, which is different from ours. That’s okay. Our testers got a show-and-tell the other day from their testers. Our testers came back all excited about the refactoring they could do. I knew it would pay off. – Senior developer

This anecdote is an example of small-world networks and communities of practice in action.

In large organizations, people have mailing lists that are the start of communities of practice. In this example, a senior developer answered a question for a tester. He spent a small amount of time coaching someone in another area of the program. The return was tremendous. “His” testers are now improving on their testing.

johanna-people-imgIn small-world networks, people want to work toward a common goal. Many of them share connections, but it’s not necessary that everyone connect to everyone else. If enough people have connections to many other people, that is good enough.

In large organizations, between the project mailing lists, the functional group mailing lists, the project and program blogs and wikis, and whatever else the agile program uses for communication, there is often a way for people to connect with one another.

The small-world network helps people solve problems rapidly. But that doesn’t help people learn what the status is. How can you organize to learn the status in an agile program and elevate risks? Even if the technical folks can solve their technical problems, you still need a way to organize to see the big picture.

How You Organize the Technical Teams in an Agile Program

jrothman-imgIf you think “scale out, not up,” this is one image of a technical program team. Think spokes of a wheel, not a hierarchy.

The software program manager coordinates the delegate project/program managers of the feature teams. As you can see, some of those teams are small programs themselves.

Sally is an agile program manager for six feature teams. Her teams all collaborate on a significant feature set. They work together on a backlog. Once the product owner decides that the team has done enough for that backlog, the feature teams might work on other features. They might exit the program entirely. It all depends on what the program needs. In an agile program, you want to take advantage of your ability to replan based on feature team availability, and backlogs being “done enough.”

Joe, Tim and Henry have single-team projects. In order to show status and elevate risks, Joe, Tim, Henry and Sally would come to the program team meeting, along with the program product owner, the deployment person, and anyone else you need from the technical side of the program.

If you have a program architect, that person would participate, also. Teams embed architects in an agile program. However, you might need to discuss the risks at the program level with an architect. It all depends on your risks and challenges.

A program team meeting is a problem-solving meeting, not a micro-commitment meeting. Since the technical people can solve problems, you don’t need a daily standup for the program team. You do need to elevate risks, and see product backlog burnup charts, among other metrics, to see if the program is on track from the technical perspective.

That’s just for the technical team. What about cross-functional business interests? Cue the Core Team.

Agile Program Management Works Across the Business

johanna_3

Back in the ‘80s, I facilitated a cross-functional Core Team across the business. We had a person each from Sales, Legal, Marketing, Training, Finance, Marketing Communications and Hardware. We needed to release within a particular market window so we didn’t miss a specific opportunity. I bet this sounds familiar to many of you. We had inter-dependencies up the wazoo.

I didn’t know about agile. I didn’t know about Kanban. I knew about the value of monthly deliverables, and asking people to commit to small, do-able actions. I knew they each had their “own” work to do. I knew that the program’s work was their work, too. But I suspected they wouldn’t see it that way.

At the beginning of the program, eight months before our projected launch, I asked them to meet biweekly for an hour. We had an action-item list at the bottom of our agenda, which you would recognize now as a Kanban board. Everyone had just one item, and the item only took a few hours to accomplish.

By the six-month mark, we met weekly. By now, we understood how to work together across the organization. The Hardware guy understood how to work with the Marketing guy. (These guys are all generic guys. Some of these “guys” were women guys.) The legal guy was happy because we were not going to ship an empty box. So was I!

Best of all, the product came together, as planned. Not as estimated—not even close. But because we worked our inter-dependencies each week, and replanned as we saw our deliverables, and kept our action items small, we were able to release the product in our market window.

We worked in a cadence, kept our WIP (work in progress) limits small. We replanned. We used what we now know as Lean and agile approaches.

Agile Program Management Scales Out, Not Up

Note that the teams don’t try to solve everyone’s problems. The technical teams solve the technical problems. They integrate all the time. They provide good data and insight to the technical program team.

The technical program team solves the risks and understands where the program-level problems are. The program team doesn’t have to solve the technical problems, unless the technical teams are stuck. The technical teams can always ask for help.

Because agile program management uses small-world networks, and is not a hierarchy, this approach scales out well.

The core team solves the cross-business problems. They do not attempt to manage the project portfolio, unless that problem is also in its purview. In small companies, it might also manage the project portfolio.

Program management is not new. Applying agile and Lean methodologies to program management is a new twist on program management.

To read more, see Agile and Lean Program Management: Collaborating Across the Organization, https://leanpub.com/agileprogrammanagement.

About Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She has been in the software industry for over 35 years—and she never fell for the waterfall promise. She’s the author of eight books about management and project management. Her most recent book is Manage Your Job Search. Her upcoming book is Agile and Lean Program Management: Collaborating Across the Organization. Read more of her writing on www.jrothman.com and www.createadaptablelife.com.

Posted in Agile Methodologies, Agile Portfolio Management, Agile Project Management, Kanban, Lean, Scaling Agile | Leave a comment

Building Software Craftsmen

I see Craftsmanship as the answer to an issue that has been rising in importance over the past several years.  Agile, as a development methodology, has hit the mainstream.   While in many ways this is a good thing, there are some drawbacks.  The majority of attendees at the major conferences are now project managers, while in the past they were developers, or at least a fair mix of both.  This has helped socialize the ideas around agile development and is a good thing, but we also need to seek balance in the Force.  This has given rise to the Software Craftsmanship movement, which is focused on the Art of Writing Software, and what is required to create great software, especially in the agile world.  In a previous post, I mentioned how important Craftsmen are to the agile world.  But how does one become a Craftsman?

First, lets take a look at the state of affairs of our industry, job-wise.  It is pretty well known that being a softwaresoftware developer outlook bls
developer is a lucrative career, but the numbers are still somewhat surprising.  According to the U.S. Bureau of Labor Statistics, the median salary for software developers in the United States is around $93,000.  The statistics further show that the number of jobs in the software development field will grow by 22% in the next 10 years.  This is significantly higher than the rest of the job market.  So how are we going to fulfill these needs with high-quality developers?

Obviously, we need to train a lot of really talented people.  We need them to be able to create software well, and also to be able to work well together.  Currently, the primary source of education in software development is via the universities and colleges.  Unfortunately, not only is this failing to provide enough programmers for the jobs, it is also failing to provide the high level of quality and experience we will need.

Now, universities are great for a lot of things.  They provide a strong level of theory and understanding of the underlying science and logic.  What they don’t provide is real-world experience and practical applications of knowledge.  This needs to come from somewhere else.  My suggestion is to turn the clock back a few hundred years, and turn your team room into a workshop.  Let’s populate that workshop with Craftsmen.  We may not have all of the Craftsmen we need to begin with, so we need to build and grow them.  This can be done by applying an apprenticeship program and using the craftsmen’s model for further career development.  Let’s take a look at how this would work.

Apprenticeship

ApprenticeshipLet’s begin with the idea of hiring apprentices.  An apprentice is someone who may or may not have a formal education in software development.  What she will have is the desire to learn.  The question remains, “What will she learn and how will she learn it?”  For starters, we will focus on five main areas:

  1. Crafting Code – The art of using one or more programming languages to create clear, well-factored code.  We want our apprentices to be polyglots by the time they become journeymen, so we will do this in more than one language.
  2. Applied Principles – Well-written code isn’t enough.  An apprentice needs to understand principles like SOLID, and know how to apply them.
  3. Technologies and Tools – While programmers need to be able to practice activities like Refactoring by hand, they also need to know how to use certain tools, as well as which tool to choose for a particular task.
  4. Work Habits – Programming is about more than just showing up, slinging some code, and going home to play Mine-Craft.  Especially in an agile software development shop, we need to be able to build muscle memory around the activities that make good programmers great, such as TDD, Continuous Integration, etc.
  5. Soft Skills – The days of the socially inept programmer are over.  Software apprentices will learn how to work in a team, how to communicate with others, and other soft skills that tend to be forgotten in the traditional learning environment.

An apprentice will learn these foundational areas through working on real projects, under the tutelage of a mentor.  Ideally, that mentor might be a Master Craftsman, but if one isn’t available, then experienced, well-versed Journeymen will make good mentors as well.  At the beginning of her apprenticeship, the apprentice might do some basic things like creating and220px-Wanderbuch_journeyman_Wobrausky_from_Daschitz_02 maintaining the continuous integration environment, some bug fixing, or other tasks.  Over time, she will work with her mentor and other Craftsmen on real-world activities and projects, continually adding value to the team.  When the apprentice has demonstrated her ability to move on to bigger and more challenging projects and tasks, it’s time for her to be recognized as a Journeyman.  We will explore more about the life of a Journeyman in another article.  In order to become a Journeyman, the apprentice must show her expertise by doing, not by taking tests.  Real work pieces that evidence her abilities in various areas and languages, coupled with having paired with everyone on the team, will determine an apprentice’s ability to move on.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile programming, Agile Software, Agile Teams, Continuous Integration, Scrum Development, Software Craftsmanship, Test Driven Development | Leave a comment

Encapsulating Value Streams and the Object Oriented Enterprise

Guest post by Mike Cottmeyer of LeadingAgile

When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.

The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working, tested increment of the product… and is, therefore, what defines the basic requirements for a Scrum team.

When you put analysts, designers, developers, and testers into a single workgroup; let them work across skill-set boundaries, self-organize to balance load; and have them collectively produce a working, tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.

Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness. You have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.

Why Scrum Breaks?

The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real-life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.

When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.

It’s my assertion that these planning dependencies are what result in teams going through the motions of Scrum without realizing value Scrum promises. Last month I did a talk at Agile 2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.

That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.

The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.

SAFe (Scaled Agile Framework) and Value Streams

I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile 2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise-level scale. Scaling Scrum is the topic du jour.

Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean (Leffingwell) has written since he released Scaling Software Agility, I have a ton of respect for his work, and I agree with the basic patterns he has introduced.

(At) this conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.

At LeadingAgile, we typically coach an explicit value stream in the middle-level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.

It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier; it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.

Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.

SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.

We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.

We believe this concept is methodology-independent and will make any methodology you choose better in the long run.

Why SAFe Breaks?

Scrum isn’t trying to break dependencies within the team; it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working, tested increment every couple of weeks.

SAFe isn’t trying to break dependencies within these larger value streams, either. It is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work, and stabilize throughput while producing a working, tested increment every PI.

There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?

If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.

If SAFe is ultimately going to struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about ‘SAFes of SAFes’ or ‘SAFe Product Owner Teams’ or ‘SAFe Portfolio Solutions Teams?’

I suspect we might. I think we might also see evidence of this already.

Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already, given how well SAFe is doing in the market.

If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon, and are people talking about this?

Ken and Jeff Got it Right

Back in 2006 Ken Schwaber put up a slide where he illustrated a team-of-teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely coupled teams (and at that time, that was NOT my reality).

A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that, “teams were never expected to self-organize across class boundaries.” They were implicitly saying that encapsulation was the expectation for a Scrum team to form.

Jeff Sutherland, as we speak over at Scruminc.com is talking about Object Oriented Design (OOD) in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.

I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum nowadays don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.

When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put into place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago, but that is seldom implemented.

I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum.

SAFe is a Compromise

I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.

That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.

At this point in the evolution of my thinking, I find myself in a place where I don’t believe the scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.

We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.

Refactoring Your Enterprise

The only real, long-term sustainable approach to Scaled Enterprise Agile is to take the long, hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.

The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peaceful harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery (DAD), and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.

With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future state starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like which help us get there, while still running our businesses effectively.

If I think about it… that was really what my talk last week was about. It’s up on my blog, and was recorded by the conference, but that might take some time to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend ;-)

– See more at: http://www.leadingagile.com/2014/08/encapsulating-value-streams-object-oriented-enterprise/#sthash.qGNQvwhB.dpuf

Posted in Scaling Agile, Scrum Development, Scrum Methodology | 1 Comment

Secret Recipe for Building Self-Organizing Teams

Guest post by Venkatesh Krishnamurthy, Advisor and Curator, Cutter, Techwell, Zephyr

Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project.  I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets.  Here are the key ones:

  1. The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
  2. Team has neither time pressure nor delivery timelines

I thought to myself that this is not a self-organizing team, but a directionless team.

As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams.  I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).

I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.

One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine.  As Joseph puts it, building self-organizing teams is like preparing soup.  I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.

The below table illustrates the mapping:

venkatesh-image1

 

To conclude,

  • A self-organizing team needs a leader, the right amount of pressure apart from the right set of constraints/goals to succeed.
  • The true test of the self-organizing team is their collaboration ability during war time and not during peace time.
  • There is a difference between a team organizing themselves and a self-organizing team.  Don’t ignore the “self” part.
Posted in Agile Management, Agile Methodologies, Scrum Development, Scrum Methodology, Scrum Software | Leave a comment

The Impact of Agile and Lean Startup on Project Portfolio Management

With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management.  This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.

Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level.  The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture.  The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.

Below are two ways that agile PPM differs from traditional PPM:

Traditional PPM:  Optimize portfolio resources (individuals) by skill set
Agile PPM:  Maximize value delivery to customers by team capability

Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio.  One reason for this is because most traditional organizations are structured and organized by functional specialty.  That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.

Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc.  When this is the case, project execution may be throttled by a particular skill set at each gate.  For example, if you have five business analysts, you will be limited to the number of projects that can be active.  However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk.  The sad truth is that most organizations really have no idea of their true project capacity.

In agile organizations, the team (not the individual) is the unit of capacity measure.  Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams.  So, how many projects of each type can you have active at any one time?  I don’t know; each situation will vary by organization, team, and context.  However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution.  If it doesn’t help, experiment.

For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value.  Of course, that assumes that the teams are not already working on other items.

Traditional PPM:  Maximize Revenue and Evaluate Project Health
Agile PPM:  Govern Empirically through Validated Learning

One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet.  In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.

Revenue is the metric of wildly satisfied customers.

Stated another way, many would say that the sole objective of PPM is to maximize shareholder value.  This is done through increasing revenue, but it misses the point.  Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value.  By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing.  Wouldn’t it be appealing to find that out sooner rather than later?

Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects.  This is great—in theory.  But one of the big problems with this approach is the way in which health is typically measured.  It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators.  None of these approaches offer an objective mechanism of determining if the project is actually building the right thing.  Personally, I’ve managed projects that have delivered the wrong solution on time and within budget.  The kind of objectivity that’s required is customer validation.

A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding.  Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name.  Agile projects aim to build small increments of a product.  This means we are dealing with smaller return-on-investment (ROI) horizons.

Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem.  This is known as A/B testing, a.k.a., “split testing.”  Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent.  Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.

Summary

While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well.  In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.

What are your thoughts?  How can you begin to apply these concepts within your own unique context?

Posted in Agile Adoption, Agile Benefits, Agile Portfolio Management, Enterprise Agile, Lean, Lean Software Development, Scaling Agile | Leave a comment