Links to Article Series and Key Posts

Here’s the starting links for some article series and key posts. Enjoy!

And now to the rest of the blog….

We are speaking at Continuous Delivery Summit (CD Summit) in Washington DC!

We are happy to announce that Naeem and Brian will be speaking at CD Summit on Wednesday, November 19th. Our session is called “Realizing Continuous Delivery: From Startups to Large Enterprises” - so take a look!

Hope to see you there!

Speakers: Brian Barr, Naeem HussainLocation:

20 F Street Conference Center
20 F Street, NW
Washington DC, 20001
Every organization strives to deliver value to its customers – rapidly and with high quality. One aspect of rapidly realizing this value delivery is enabling continuous delivery in your organization. In this session we will share war stories from our client experiences that:

  • Provide you an executive overview of continuous delivery
  • Present some critical questions that can help you create your baseline capabilities
  • Share our framework that we have used for our clients to create a roadmap for all capabilities that drive continuous delivery
  • Present financial models that create compelling reasons to prioritize and invest in continuous delivery
  • Share outcomes from our Continuous Delivery experiences

Click Here to Register

For additional conference information visit the CDSummit  website.

We are speaking at Agile Philly’s 2014 Agile Tour

September 14, 2014 by  
Filed under Uncategorized

We are happy to announce that Brian will be speaking at Agile Philly’s 2014 Agile Tour on Monday, October 6th. The session is called “The Whats-Hows-Whys of Scrum”. Brian will also participate in the Expert Panel session.

Hope to see you there!

Speakers: Brian Barr

Location: Ebay Enterprises

630 Allendale Road, King of Prussia, PA, 19406

Registration and Information


This session will cover the WHATs, WHYs, and HOWs of Agile / Scrum. Too often, teams think they are agile because they are “doing stand-ups”. Beyond outlining the mechanics and framework of Scrum, this session brings to light ideas of how to implement fundamentals well and, more importantly, why these fundamentals, when done right, can lead to huge results. This session is targeted for those newer to practicing Scrum but also to those with more experience looking to re-energize their practice of Scrum.

Click Here to Register



We are speaking at Agile DC!

September 14, 2014 by  
Filed under Agile, Release Orientation

We are happy to announce that Naeem and Brian will be speaking at Agile DC 2014 on Tuesday, October 21st. Our session is called “Hop Onto the Release Orientation Trolley”. This session was first be presented at Scrum Gathering on Tuesday May 6. This session builds on concepts from our Scrum Alliance article, “The Big Lever” - so take a look!

Hope to see you there!

Speakers: Brian Barr, Naeem Hussain

Location: Kellogg Conference Center at Gallaudet University

800 Florida Ave N.E., Washington D.C. 20002




This session will cover the WHAT, WHY, and HOW of release orientation:

1) What does it mean to be a release-oriented organization? (WHAT)

2) Why should you move to release orientation? (WHY)

3) How do you make the shift to become a release-oriented organization? (HOW)

WHAT (25 minutes): Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality.

WHY (10 minutes): Release-orientation gets the entire organization to focus on the most important reason we exist as software developers – maximizing business value delivery through frequent, quality software releases. Moving the organization towards release-orienting thinking provides an invaluable lens for wise organizational decision making.

HOW (15 minutes): The move from project-orientation to release-orientation is both a mindset shift as well as a framework practice change. For too many years, we as software developers, IT shops, and businesses have been successful delivering projects.

Q&A (5 minutes): The session will finish with a brief questions and answers section.

Click Here to Register



When Planets Align

August 25, 2014 by  
Filed under Agile, Scrum

Back in May of this year, Naeem and I went down to New Orleans to the Global Scrum Gathering to present “Hop on the Release Orientation Trolley”. It was a great experience and we have had numerous opportunities to present the Release Orientation topic to clients and other agile meetups, such as Agile PA and Agile Indy. One of the keynote speakers at Scrum Gathering was Rich Sheridan of Menlo Innovations. Unfortunately, I was not able to get to Rich’s keynote. However, they gave all attendees a copy of his book, “Joy, Inc.”, which I furiously started reading on the plane ride home and finished within a few days. The concepts and the approach resonated with me deeply. I wrote a blog article about it, did some social media, and that provided the opportunity for Rich and AgileTrailblazers to connect. One thing led to another and Naeem and I found ourselves booked to come to Menlo’s “Intro to the Menlo Way” 1-day course out in Ann Arbor, Michagan.

Between booking our Menlo trip and actually going out there, I went to Agile 2014 down in Orlando in late July. It was a great conference. One of the highlights for me was going to see Lyssa Adkins at her “Facilitating Intense Conversations: What to do When it Gets Hot”. What a great session! And yes, Lyssa, you sold me on the art of agile coaching and sold me on getting your book, “Coaching Agile Teams”. I’m not done yet, but I’m learning a ton and really love Lyssa’s thinking and approach to agile coaching – highly recommend it!

Now to the planet alignment. Earlier this week, we flew out to Ann Arbor. While at the hotel the night before visiting Menlo, I was continuing to read Lyssa’s book. In the section about coaching Product Owners, Lyssa recounted a vignette from Rich’s experience – what he calls “Doing Donuts in the Parking Lot”. I won’t get into the story, but needless to say, I was a little freaked out that I stumbled upon this chapter when only hours away from visiting Menlo. I knew right then, I was in the right place that coming day.

What happens when planets align? Well, we had a great day at Menlo. You can absolutely get a lot from reading Joy, Inc. However, I would highly recommend that you sign up for going out to Menlo and see their model in action. Here’s what I saw during the visit:

  1. Singular focus on customer joy (or Business Value of Joy – getting systems that delight their users and lead to business value) leads to so many great side effects – high quality, joyous workplace for associates, solid expectation setting, etc. Their High-Tech Anthropology approach works to truly understand what will bring joy to the end users of their solutions. No more guessing what the real needs / requirements are when coupled with rapid “show & tells” (demos).
  2. Have teams use very simple, repeatable, and physically tangible (where co-located) means of running their iterations. This is such a critical element of how Menlo does business.
  3. Extremely high levels of quality lead to almost no spending on customer support. This level of quality is possible given 2 things: First, unwavering attention to TDD, unit testing, and unit test monitoring. Provides a key measure of “done” at Menlo. Second, pairing / paired programming – no line of production-targeted code is ever written without pairing. Rich made a very good case for this relative to quality but also to productivity. I am convinced.
  4. Culture matters – Rich has done some deep thinking on what makes a great culture for the company and for getting to his mission of joy. He has built his company to make sure that culture is pervasive in his shop.
  5. Menlo has done a great job at making “software factory” a term for a great place to work.
A journey with continuous learning is always worth traveling. Reading great books and visiting other companies that do solutions delivery well are great ways to make your journey.  I’m convinced that if you blaze your trail with continuous learning, your planets also will eventually align along the path.

Joy, Inc. – Great read, great approach!

May 12, 2014 by  
Filed under Agile

Naeem and I had the pleasure of presenting “Hop Onto the Release Orientation Trolley” at the Global Scrum Gathering in New Orleans last week. When you speak or go to a conference, you figure the primary goals are to learn and to teach. We can say that both goals were definitely accomplished.

Sometimes, you never know where the learning will break out. All attendees got a copy of “Joy, Inc.” written by Menlo Innovation’s CEO, Richard Sheridan.

We unfortunately had to leave the conference for a previously booked engagement before Richard’s keynote session. However, I did get the chance to see the video recording over this weekend.

I have been wanting some excuse to dive in a bit deeper into Menlo’s inner workings and Richard’s book really made that easy and plane rides home provided the time.

I have known about Menlo running “software factory tours” for quite some time and I do really want to make the trek up to Ann Arbor soon to see Menlo in action. At a previous employer, we also had a “software factory” and I ran the “software factory tours”. This was a great way to evangelize the value of agility and the critical aspects of culture and mission that allowed flow to break out.

Joy, Inc. is chock full of nuggets (my marker for a great book) when considering how to lead and operate a company. I created a mind map (take a look – you might need to zoom in a bit) with my favorite nuggets especially when considering my business and those of our clients. If I had to summarize the 3 most important to me, they would be:

  • Find a “north star” for driving everything you do as a company – Menlo chose “joy” and Richard’s convinced me that this is a great driver. Having a driver provide alignment across leadership, inside the company reality, and outside perception is really powerful.
  • Do XP, but really do pairing – if some significant part of business is solution delivery, look at Extreme Programming for practices that really make a difference. Richard does a great job at exposing the business case for pairing all through the book – freedom for continuous learning, scalability enablement, building a human-connected organization, etc.
  • Rigor, discipline and quality are critical – I have been preaching that agile and its associated frameworks is THE most disciplined way to do solution delivery. Richard makes a compelling case for this and does a great job at exposing leadership’s role in fostering (or destroying if done wrong) a disciplined, yet fun, organization.
Ok, have I convinced you to pick up the book? I hope so. Happy reading!

Thanks for a great Scrum Gathering 2014!

May 9, 2014 by  
Filed under Release Orientation

It was a great week at Global Scrum Gathering in New Orleans! We really appreciated all the energetic participation by the attendees at our session, “Hop Onto the Release Orientation Trolley”.  We really hope that all participants got a view into the What, Why, and How of Release Orientation. If you want some more material on the subject, please see our Release Orientation Mind Map with lots of clickable links about Release Orientation and background topics.

Here’s a few pics from our session. Thanks to everyone for making it a memorable week for AgileTrailblazers!

Off to blaze some new trails!


Making the Move

May 6, 2014 by  
Filed under Release Orientation

There are many considerations on how to make the move from Project Orientation to Release Orientation. Probably more than any other, the key is a belief in moving your organization’s mindset to the new of way of thinking and recognizing that the value of the old project container has vanished in an agile delivery model.

Specifically, let’s talk about five key considerations to make the move to Release Orientation.

  1. Portfolio management – It’s really important when doing agile at scale to have a lean way of getting a view of the entire portfolio of initiatives.  We need to be able to cheaply get an accurate view into every release going on.  We need to have a clear view of where we are investing – and one of the keys to Release Orientation is to start talking about investments in terms of # of teams rather than number of people.  Getting less granular in your investment currency makes the investment decisions move faster.  For Release Orientation to really work, you need to know the metrics that impact customers (rather than focus on projects) associated with customer experience, defects, etc.  We can rejigger those investment decisions based on what’s happening to the customer based on the release. You need to get into one picture the spend on business vs. architecture intent.  We also need to avoid metrics explosion. Pick only those metrics that truly give you a picture of what’s important across the portfolio and think hard about the potential nasty side effects of some metrics.  For example – we have seen a metric like “% of first pass tests that have passed”.   What’s wrong with that metric? What’s the potential bad side effect?  We will have developers stop delivering code early because they don’t want this metric to blow up.  We should really be measuring defects that got into production – where quality really matters.
  2. Organizational StructureRelease Orientation forces you to become organized around flow and especially to achieve results in the DevOps area.  Most organizations we have seen cannot be disciplined enough to invest in the continuous improvements needed in the early days of moving towards Release Orientation. Therefore, you most likely will need to create a dedicated continuous improvement team to build the bridge, lay the track, and help the delivery engine move faster, better, and stronger
  3. Release Roadmaps – One of the keys to transform to Release Orientation is to create lean release roadmaps that provide the right time granularity based on the time horizon – 12 month roadmaps or 3 month roadmaps.  We can use 12-month roadmaps to help get broader organizational buy-in to initiatives across the enterprise or within a value stream. These are really just boxes put in the rough start and end timelines for any particular initiative – no more precision and definitely not a commitment.  We can use 3-month roadmaps to provide a theme or story granularity of the expected delivery over the coming 3-6 sprints – again, not a commitment, but we have a higher level of confidence in this roadmap because we have gotten really good at story estimation when the time horizon is less than 3 months.
  4. Configuration Management and Branching – To truly be Release Oriented, you need to get to a Configuration management / branching strategy that is simple.  Everyone in the delivery stream works on the same release branch which allows for continuous integration across the release stream and minimizes the need and cost of merges
  5. Environments Management – You need environments that allow for rapid feedback and flow towards a release going out the door.  You need to create enough environments so that teams can work independently on getting their stories turned into solutions locally and then promote those solutions into environments that are used by a broader and broader set of the organization.  You need environments that can be created, torn down, and re-created via self-serve which points towards high virtualization of environments.

If you can get working on these five considerations of Release Orientation, you will be well on your way to becoming a Release Orientated, value-focused organization.

Agile Enterprise Portfolio Management for Release Orientation

May 6, 2014 by  
Filed under Release Orientation

The third foundation – Agile Enterprise Portfolio Management – A lean project funding and tracking process that ensures Just In Time funding of ideas, so that the rest of the machinery can deliver the value at rapid pace. In traditional organizations, budgeting and pre-planning of ideas for the long term and short term – many a times put the organization in a position to not pick up and work on ideas that are demanded by the market because the internal processes of the companies do not aid the company to be agile and nimble to react to market conditions. So, while your development organization may have adopted agile delivery processes, it does not truly help if your project intake process is still stuck in the 60’s.

In our several years of working at large enterprises trying to get Continuous Business Value Delivery®  to break out, we have experienced several lean portfolio management practices that can help organizations.

One of the first things that any organization needs to solve for is a longer term (e.g. 12 month) rolling roadmap that allows for the organization to make changes and be nimble at the top. Ensuring that the no one feels compelled to “stick with a plan” – instead, the focus is on delivering value continuously in the near term which ensuring that strategy can be adapted to market conditions any time – from the near future to the distant horizon. Creating Product Roadmaps and sharing with teams creates the transparency  that is necessary to motivate team members and enables participants to actively comprehend the dependencies between initiatives as they do release plans.

Secondly, turning the near term deliveries into short term (3 to 4) sprint detailed roadmaps, enabling teams to think and plan how they would approach their work and technical decisions based on both the long term needs as well as short term deliveries help the teams immensely. Create Team level roadmaps with strong steel thread management to understand and resolve release dependencies

Third, create simple but effective Risk Awareness Capabilities, incorporating both business and technical risk and a clear risk mitigation plan.

Fourth, have a collaborative Architecture Governance body. Include risk, security, operations, development and portfolio managers at the start of the initiative. Incorporate findings from architecture reviews and previous release findings into the next product and releases and create the continuous feedback cycle at the portfolio level.

Finally, incorporate release metrics into your portfolio build out – allocation of budget and resources, tightly tied in with architecture governance, generate program level road-maps, mid-term (3 months, ex) views from program down to the team. Utilize appropriate Agile Life-cycle Management tools to collect data, and figure out integration to your capital asset management tools to manage depreciation and allocation of budgets.

Without a lean implementation of Portfolio Management, it will be difficult to achieve Release Orientation.

Enterprise DevOps Accelerates Release Orientation Adoption

May 5, 2014 by  
Filed under Release Orientation

As we discussed in the previous blog, lean release management processes are the foundation block for release orientation. In order to amplify the value delivery across multiple synchronized value streams, an organization has to invest in Enterprise DevOps capabilities.
Enterprise DevOps is the second foundation to enable delivery across multiple value streams with multiple simultaneous initiatives. The following are some critical components of an Enterprise Class DevOps set up:

1) Simplified release oriented source code management: Teams are committing code for the smallest testable component and getting feedback on variance from expected results in the appropriate environments. The design of source code repository is such that it minimizes branching and merging while ensuring there is ability to do urgent and emergency releases.

2) Continuous Integration: The goal of continuous integration is to provide a low cost feedback loop to feature teams such that they commit small changes and do this frequently.  This ensures that the teams get feedback on the quality of the build, cyclomatic complexity, unit test coverage, style checks etc and most importantly, allows the appropriate team member to respond in a timely manner to fix any known issues.

3) Highly available Environments: Environments are a combination of physical and virtual entities and agile teams are given tools to self -serve their needs as much as possible. The teams are provided tools to refresh the environments, load test data etc. so they can maximize the testing time in each environment. Environment access and size should reflect the complexity of the environment and the business workflow that has to be tested.

4) Continuous Testing: Unit tests, services test and UI tests are executed during build and post deploy phases of a build. Test Data management rigor has to be in place to ensure that changes and test data from a previous release scrubbed are used in refresh process to ensure that testing can be improved in the entire effort prior to the next release

5) Release Managers should be have a pulse on expected changes during the development cycle. This ensures that as the release date approaches, all stakeholders have a clear view on the risks associated with a release and appropriate mitigation strategies can be adopted.

Once you start the journey of DevOps implementation, you will see that the feature teams are more engaged as they get to focus on the delivery of their work product and get timely feedback and hence avoid costly changes. Enterprise DevOps implementation accelerates an organizations release orientation adoption as it provides the automation needed to enhance the adoption.

Enterprise Release Management Orchestration

May 4, 2014 by  
Filed under Release Orientation

The first step is to get the organization aligned on a delivery cadence that is most appropriate depending on the type of business – more importantly the expectation from your end users. For example, if you are a bank, you would not want to bring down critical customer facing applications during peak business hours, for that matter any time during business hours. So not only do you have to pick your dates, you need to have a clear understand of exactly when during the day you would authorize a release to production. Now, imagine that you have multiple initiatives that you have organized into “project containers”. You have to now release these projects into the production environment in an organized manner, complete with the ability to rollback etc.

In order for you to deliver solutions on an established cadence, your organization must achieve synchronization in solution delivery. This is a key function of release management. As you solve for this in the most lean implementation possible, you have to figure out how to execute this release process daily in the Dev and QA environments, so that you can repeat this any number of times in the production environment at will.

Hence, Enterprise Release Management becomes a key foundation for Release Orientation.

The 3 Foundations of Release Orientation

May 3, 2014 by  
Filed under Release Orientation

In order for an organization to be successful with Continuous Business Value Delivery® the organization has to set a new destination and has to create a “new” route to reach this destination. This means, we have to REVERSE ENGINEER the entire delivery process to maximize value creation at a rapid pace.

The three key areas that need to be lean and automated, the foundations of a Release Oriented organization are 3 major process areas:

  1. Enterprise Release Management
  2. Enterprise DevOps
  3. Lean Agile Portfolio Management

We have spoken to many organizations which either are heavily engaged in a Project/Portfolio Management Office or they shy away from setting these up as they believe a “PMO” will hinder their progress. For an organization at scale, this should not be a “yes” or “no” decision. Having a lean implementation of Agile Portfolio Management as well as lean implementations of Release Management and DevOps is critical for setting up a sustainable organization.

Envision Your Agile Destination

May 2, 2014 by  
Filed under AgileGPS, Release Orientation

An agile transformation journey implies a starting point, where you are now, and a destination. That destination might not be the final end point for your transformation journey, but that destination is somewhere you know you want to go – more automation, faster cycle times, higher quality, unimpeded flow from business intent to development, or just a happier place for everyone to work. A perfect destination to choose is Release Orientation.

How do you get a picture of that destination put into the entire team’s brains?

First, you need someone in the team who has enough knowledge or experience to be able to describe the vision of that destination. This can be one person in the organization or preferably many people. The key here is that someone needs to truly understand what the future could look like for the teams so that the picture of the destination even makes sense.  This person or group does not necessarily need to know how to get to the destination yet, but at least be able to plug the destination into the company’s GPS. How do you get these “visionaries” into your team? You could hire folks that have the experience of being at or near the destination before. You could bring in agile coaching to temporarily hire in that “vision”. Most importantly, you need to give your team members time to “scout” for the destination – read lots of articles, go to conferences, or create an “agile travel book club” for a group to read and discuss their potential next destination.

Second, you need to have a Shared Vision session that extends the team of “visionaries” out to include the whole team. Spend the time to get input from what everyone’s individual vision of the future could be, add on all the knowledge and learning from your core team, and then come up with a Shared Vision of the destination.

Third, you need to plan your route. You need to create a roadmap of the incremental improvements that will move you towards the Shared Vision. Do not overthink this roadmap but also do not slop it together either. There is a good balance of thoughtful preparation of the route to the destination and just getting started on the journey. This step is probably the best place to insert some real expertise to make this lean planning happen quickly and ensure the route chosen is effective.

Lastly, get moving! You know where you want to go, so get moving towards the destination. Just know that the route you laid out in the roadmap will change because every point in time in the journey presents an opportunity to figure out a better path and a slightly better destination.

Good luck on your travels!

That Ugly Box of Ideas

May 1, 2014 by  
Filed under Release Orientation


So, does this picture bring up bad memories of late November or early December – out in the cold, hanging these up and not sure if all or any of these bulbs were going to light? For me, this picture reminds me of projects and how, even in shops that claim to be Agile, we still have these ugly containers called “projects” hanging around. And, the memories are still as painful as the “hanging holiday lights” nightmare.

Think of any idea dreamt up by someone in the business as a light bulb – pretty familiar visual, huh? Now, think of the last project you worked on. You needed to spend way too much time packaging up all the ideas / light bulbs into a heavyweight project charter or, worse yet, a requirements document for the sole purpose of getting leadership approval for the intent or to get project funding. Once we got an approved project, the business was never sure if they were going get another “project team” allocated to them again for another 2+ years. So, instead of just starting to work on one “idea”, they felt compelled to package as many of those ideas together into a “Project” container – a big ugly box of ideas. The box is inherently full of lots of dependencies and too many ideas to get done in any reasonable amount of time. Little to no prioritization of the ideas – well, because they are all going to get done as part of the project – right? Guess what, this “idea packaging” takes a lot of time and none of us wanted to be responsible for forgetting some important idea to “put in the box”. This is just the beginning of the torture we like to call “Project Orientation”.

What’s the alternative? Release Orientation (see our first article). There are two key points from the ugly box of ideas. First, avoid the need for leadership approvals for everything. You need to train your leadership to empower decision makers at lower levels in the organization – as close to the delivery teams as possible. Second, create teams that are statically allocated to a slice or stream of the business. If they believe that they will always have teams allocated to them, the fear of losing development / delivery capacity goes away and the box of ideas a team can deliver can get much smaller.

So, here’s an idea – stop creating ugly boxes of ideas!


What is Release Orientation?


Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-Orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality.  While Continuous Delivery has become a very popular destination for many software engineering and IT shops, Release Orientation goes well beyond the rapid feedback and rapid test and release cycles of Continuous Delivery.  Release Orientation is focused on realizing value through regular and frequent solution releases going into production (or customers’ hands) – thereby realizing continuous value for the business.  In other words – Continuous Concept to Cash.

Let’s work backwards from the point of value delivery – the release – backwards to understand how to make Release Orientation a reality for your organization.

First, you need to create a widely publicized, at least internally, schedule that the entire solution delivery organization, including the business, knows intimately. The release schedule is the schedule is the schedule – it becomes the immutable part of your solution delivery. Let’s be clear – there may be many cadences of releases – the key is that those cadences are well known and predictable.  One of the key advantages of this way of delivering is that if you can get these releases to happen frequently enough and predictably, no one gets too upset if their particular idea did not turn into a release this week or month – there’s another one coming down the pike really quickly.

Second, if you’re running Scrum, you can set up your schedule of releases to be every one, two, three, or four sprints – that’s about every 2 – 8 weeks.  If your releases are much more than that apart, you will lose the ability to say to that passionate business “idea” person – “not this release, but the next one’s coming out quick”.  For each team, they look to fill the content of their Sprints from a prioritized backlog – this is standard Scrum practice. Sprint after sprint, they go and grab the items off the top of the backlog. Of course, the backlog can be entirely adjusted between sprints.  The key here is that a team has clear direction on where to grab their ideas.

Third, as part of the flow, any particular high-level idea can turn into a list of prioritized backlog items.  We have a bunch of ideas that each generates their own backlog items.  The team’s prioritized backlog is now the culmination of a bunch of ideas, broken down into backlog items that can be mixed and matched as content for any particular sprint.  In that way, THE most important backlog items, regardless of what idea they were borne from, are getting done first.  This is the key to Release Orientation vs. Project Orientation. If Project Oriented, we would need to get all the backlog from Idea #1 done first, then the Idea #2, and then Idea #3.  With Release Orientation, we recognize that some significant value can be delivered from 1 or 2 of the top backlog items generated from any particular idea.  And, in this way, we can be delivering multiple ideas simultaneously.

Flow breaks out! Release Orientation – A Continuous Flow of Value.

Learn more at Scrum Gathering New Orleans 2014 or Agile PA!


We’re speaking at Agile PA!

April 21, 2014 by  
Filed under Agile, AgileGPS, Events, Release Orientation, Scrum

We are happy to announce that Naeem and Brian will be Keynote Speakers at Agile PA on Wednesday, May 14th, at 6 PM. Our session is called “Hop Onto the Release Orientation Trolley”. This session will first be presented at Scrum Gathering on Tuesday May 6. This session builds on concepts from our Scrum Alliance article, “The Big Lever” - so take a look!

Hope to see you there!

Speakers: Brian Barr, Naeem Hussain

Location: Conference Center Building, Penn State University, Great Valley, PA




This session will cover the WHAT, WHY, and HOW of release orientation:

1) What does it mean to be a release-oriented organization? (WHAT)

2) Why should you move to release orientation? (WHY)

3) How do you make the shift to become a release-oriented organization? (HOW)

WHAT (25 minutes): Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality.

WHY (10 minutes): Release-orientation gets the entire organization to focus on the most important reason we exist as software developers – maximizing business value delivery through frequent, quality software releases. Moving the organization towards release-orienting thinking provides an invaluable lens for wise organizational decision making.

PROS/CONS Game (35 minutes): Now that the room has a base understanding of the WHAT and WHY of Release Orientation, we will break into groups at each table to play the Pros/Cons Game (see

HOW (15 minutes): The move from project-orientation to release-orientation is both a mindset shift as well as a framework practice change. For too many years, we as software developers, IT shops, and businesses have been successful delivering projects.

Q&A (5 minutes): The session will finish with a brief questions and answers section.

Click Here to Register



Blazed and Confused

March 27, 2014 by  
Filed under Agile, Scrum

Here is a reprint of my article originally published with Scrum Alliance in March 2014. Enjoy!

Been blazed and confused for so long it’s not true . . .

So, your Agile transformation journey has been underway for a few weeks, a few months, or maybe almost a year. You have blazed a path toward agility. But, much like the Led Zeppelin song (Dazed and Confused– please, you don’t have to be from the ’70s to get the Led out!), there is a huge pause in the middle of the journey, and now you are not really sure if you are going anywhere.

This is the perfect time to do two things:

  1. Celebrate how far you have blazed your trail to agility.
  2. Figure out where and how to keep moving forward on the Agile journey (and certainly how to stay away from falling back into Waterfall).

Celebrating your Agile trailblazing so far is important. Take a few moments to reflect on the effort spent, look back on your accomplishments and the distance you have traveled, and appreciate what your software delivery life looked like only a few short weeks, months, or year ago. It is important to remember the effort it took to start blazing the path toward agility. Organizations are often eager to expend the energy early in the journey because the non-Agile ways of delivering software were so painful. However, do not use this opportunity to say, “We are plenty Agile already.” There are numerous examples of organizations that get comfy with where they are on their Agile journey and feel that they have learned all they can learn. What a shame! And how subtly the fall back to pre-Agile days can happen, without your noticing that you are actually going down the Waterfall again.

It is time to push on your Agile journey! If you are truly going to be an Agile trailblazer, you need to build discontent with the status quo. What does that mean, and do I really want to build a discontented organization? Creating discontent for the status quo means raising the awareness and building a vision of what could be — and of how different, and how much better, that destination is from where you are now. This takes real leadership, not just from the anointed leaders but also from others within the organization. Anyone can recognize that the journey is never finished, that you can blaze a new trail from the place you stand now to an even better destination.

This takes creating a real culture of continuous improvement within your teams. You need to take sprint and release retrospectives seriously and make sure that investment in the smaller and larger improvements is made continuously. So, discontent in the status quo means standing still is unacceptable — and yes, we all want our organizations to feel a lack of contentment with standing still. If you are not sure where to harbor that discontent, get someone outside of your teams (leaders and team members from other teams, external coaches/consultants, Agile conferences, etc.) to help take a fresh look at things. Also, think of all the areas of solution delivery that could be improved upon compared to where you are today:

  • Intent grooming – Business ideas turn into development team member work in hours, not days and weeks, and intent is expressed in a form that fosters development and testing automation (i.e., ATDD/BDD).
  • Architecture – Software architecture is intentional and minimizes systems dependencies to allow design during Agile iterations to emerge effectively.
  • Build, deployment, and release automation – Development team members develop solutions, and continuous integration systems automatically do the rest.
  • Test automation – Unit, service, functional, performance, load, and security testing automation works to the point where feedback on any change to your code base gets run through the entire wringer in minutes or hours, not days or weeks.
  • Environment provisioning automation – Development and test environments are always available and created on demand as needed.
  • Fungible team members – Team members are cross-trained so that developers of one system can be developers of many systems, developers can develop test automation, and testers can develop as well.

So, celebrate your Agile journey so far, and get moving on blazing the next part of your Agile trail. And, most important, enjoy never being finished with your journey toward continuous improvement!

We’re speaking at Scrum Gathering New Orleans 2014!

We are happy to announce that Naeem and Brian will be speaking at the Global Scrum Gathering New Orleans 2014. Our session is called “Hop Onto the Release Orientation Trolley” (in the New Orleans theme) and will be held on Tuesday, May 6th, at 11 AM. This session builds on concepts from our Scrum Alliance article, “The Big Lever” – so take a look!

Hope to see you down in the Big Easy!

Speakers: Brian Barr, Naeem Hussain

Room: Jasperwood

Track: Hop On a Streetcar

Type: Lecture

Level: 1

This session will cover the WHAT, WHY, and HOW of release orientation:

1) What does it mean to be a release-oriented organization? (WHAT)

2) Why should you move to release orientation? (WHY)

3) How do you make the shift to become a release-oriented organization? (HOW)

WHAT (25 minutes): Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality.

WHY (10 minutes): Release-orientation gets the entire organization to focus on the most important reason we exist as software developers – maximizing business value delivery through frequent, quality software releases. Moving the organization towards release-orienting thinking provides an invaluable lens for wise organizational decision making.

PROS/CONS Game (35 minutes): Now that the room has a base understanding of the WHAT and WHY of Release Orientation, we will break into groups at each table to play the Pros/Cons Game (see

HOW (15 minutes): The move from project-orientation to release-orientation is both a mindset shift as well as a framework practice change. For too many years, we as software developers, IT shops, and businesses have been successful delivering projects.

Q&A (5 minutes): The session will finish with a brief questions and answers section.


REGISTER NOW for the Global SCRUM GATHERING® New Orleans 2014 - #SGNOLA


Sixth installment – the starting problem series – the worst leadership mistake

As experienced leaders, we expect that our managers and executives trust us as well as give us autonomy in decision-making. Some call this empowerment. The secret for this empowerment begins with trust.

Way too many organizations, attempt to adopt agile methodologies. Many fail. Leaders in these organizations make one critical mistake – they do not have confidence that given the new “freedom”, their team members will do the right thing. At the core, they lack trust. Now, as a manager or leader, there are deliverable that you are accountable for. And if you cannot deliver on these expectations, it is clearly a setback and in many cases with consequences. So how can you as a leader navigate this situation?

Consider these guidance:

1) Grow up – you have hired adults and so, you just have to allow them to be adults. Tap into the core element of responsible adults – have your team and individuals make commitments. They do not need directions at every point. Let them do their job.

2) Shorten feedback cycles – be selfish – ensure that they do not commit to deliver in 18 months, instead, have them break things down delivery to every few weeks. This will provide short-term delivery goals and evidence, and give you runway for building your confidence.

3) Set goals – you are still the leader and you have to set goal. The key is to influence your team to buy into the goal. Don’t impose, influence.

4) Listen  - if your team raises an impediment, acknowledge and work with them to resolve it. Take ownership – be the person who backs them and they will back you. Represent them, but challenge them to keep chugging along.

5) Ignite their passion – trust your team, challenge them to deliver, ignite their passion. Praise them for hitting the short deliveries, congratulate, and appreciate.

To get your team to trust you, you will have to trust them first. Your growth is dependent on their success. Get out of their way, be the coach, provide direction and your constraints. For where you want to go, let them determine the road – trust the team. You will get incredible insights on how to get there fast and cheap.

<<Previous Article

The Starting Problem Series – Fifth installment – Is innovation and reward important in agile transformation?

Inspired at @gwu @uchicago

I recently was a judge at the Annual GWU SEAS R&D showcase where young talented engineers displayed their latest work. Three impressions that I walked away were: 1) the boundless creativity and imagination displayed by students and 2) how much I learned about their projects in that short interaction and 3)  the most important one – the pride each student felt when s/he presented their work.

In one moment, I time traveled to my days in engineering school as a student and then the transformation as a young adult working for large corporations. Once in the corporate world, that receptiveness to new ideas from diverse set of talents was not as much nurtured. Unless of course, you had the good fortune to inherit a manager who really cared or work for a company whose DNA is sequenced for teams and innovations. However, this is fabled manager seems to be the exception rather than the rule.

In my personal journey as a student of agile methodologies and as leader or follower of organizational transformations, one repeated pattern emerged, and that is when organizations transformed some how, people became engaged, new ideas flowed, information was shared and innovation broke out.

Here is what I think are some intrinsic reasons why innovation breaks out in agile organizations:

1) People feel pride in their work because agile organizations recognize teams and individuals continuously delivering (every sprint and release)

2) People build on diverse ideas because agile organizations break down silos and allow humans to interact, to build on each other’s ideas, to grow intellectually, and really experience collective problem solving

3) People influence others to join them to solve complex problems because agile organizations foster leadership by influencing others to join their cause.

4) People feel a sense of accomplishment because agile organizations deliver something their customers actually use

5) People feel they have contributed because agile organizations allow individuals to exhibit their expertise and craftsmanship

As you design your organization for agile transformation, ask the key questions:

1) Are individuals allowed to display their expertise?

2) Are they delivering continuous business value to get the shot of fulfillment?

3) Are team members empowered to make decisions and lead without significant permissions?

4) Are delivery-distracting team member politics minimized (i.e., managers, needing permission, etc.)

5) Does your reward system support both team and individuals?

It is critical that organizations hire the best talent and then create the environment that utilizes the passion and entrepreneurial spirit of these people to allow innovation to break out. We all know innovation is key for business growth today. Let’s ensure that as these young grads join the workforce, their ideas and passions are guided to create great value. Go Boundless Creativity!

<<Previous article | Next article>>

The Starting Problem Series – The Problem with Agile Recipe Books

February 2, 2014 by  
Filed under Agile, AgiLEAD, Starting Problem Series

Ever tried getting a recipe book and recreating your favorite dish made by your favorite chef? You have followed all the instructions, gotten the right ingredients, and channeled your inner Emeril, but the dish still does not come out a 5-star meal. What has this got to do with agile transformation? Read on.

You heard a colleague boast of results they achieved using agile methodologies at her last job, or maybe your boss just asked you to drive agility into your organization. To get the ball rolling, you are now reading a book on agile requirements and doing lots of other research on agile frameworks. You have officially embarked on your agile transformation journey. Let’s assume you are in an organization and at a level in the pecking order that you can influence change. Also, let’s assume that you have convinced your peers to support you in this transformation. Where do you begin? What is the recipe to agile transformation?

Agile transformation is much more than recipe, ingredients and following instructions. The journey is about being open to experiencing the transformation, giving up control and exploring new boundaries of leadership. The prize – an organization so self-organizing and committed to delivery that every associate enjoys coming to work like nowhere else they have been!

You will know if your transformation is heading in the right direction when, for example, a developer makes suggestions about changing your release processes, drives it through your organization and his plans and ambitions are not held back by the “owner” of release management process. This, my friend, will create the joy to be at work. Your organization will rejoice as examples like this become common place and they start realizing this is the sort of work place they want to be..

Here are some ingredients that may be part of your recipe:

1)    Talk to your leaders, listen to their concerns – their leadership is most valuable to make the transformation successful. Engage your leaders with delivery responsibilities and map these responsibilities to the outcomes that are expected. Publicize these outcomes within your organization, support your leaders and hold them accountable for timely progress. Your leaders must deliver real change – not reports or a new reporting mechanisms – rather real change that impacts the way people work.

2)    Cut the red tape – every process that does not add direct value to the customer is waste – you can bet that you have plenty of waste in your system. Create a backlog of this waste, prioritize based on the impact of eliminating the waste, and execute the backlog by putting automation or a leaner process in place. One at a time – do it.

3)    Set money aside to invest in DevOps – free up your developers to focus on one thing – delighting your customers with flawless software. In other words, let them be software craftsmen. Get your developers and testers out of the business of creating manual builds, deploys and manual testing.

4)    Get your best people to build your technical practice. Let your architects solve the biggest technical hurdle – getting your development operations to flow. Ensure that your technical practice delivers continuous feedback to all stakeholders involved.

5)    Bring an über transformation specialist, or “transformation chef” onboard – a dedicated, experienced agile transformation specialist. There is no substitute for this ingredient. The reasons are simple. First, the transformation obstacles this “chef” has experienced do not need to be repeated by your organization – avoid unnecessary pain where possible. Second, the “chef” can help you plan out your agile journey and some near-to-long term waypoints.

While there are many outcomes to be expected, exercise good judgment in picking your “transformation chef”, the recipe and the ingredients. Imagine if your executive team is expecting a gourmet meal from your transformation and you end up serving them a Big Mac! You might find yourself working at the golden arches!

<<Previous Article | Next Article>>

The Starting Problem Series – Realistic Agile Transformation Expectations

Expectations are everything. If you set a goal, communicate it and then meet it, your team is thrilled and so are your stakeholders.

Organizations quite often operate with their collective head in the sand and have self-proclaimed “optimized” internal processes and are therefore not looking for critical feedback to make improvements. Over a period of time, they become dysfunctional. However, since this decay in processes and capabilities is gradual, no one internally feels the pain or the need to change. It’s almost like the frog that is put in cold water and then the pot is set to boil. Alas, it’s too late for the frog to find out how close it is to its end. It usually takes a new leader or a costly error that causes organizations to change their product delivery processes and adopt agile methodologies. Usually, these errors force a change in leadership and the new leadership drives change in the organization.

When an organization gets into the groove of transformation, leadership demands root cause analysis and inevitably, a lot of questioning of current processes and procedures happens. A common problem during this phase is that some people utilize this opportunity to look for “organizational scapegoats” who are believed to be the root causes for these problems, with little or no appreciation for why the process had been put in place. It usually takes a long time for processes to be embedded in an organization and the transformation period leads to some unreasonable expectations for effective process changes to be realized in a very short period of time. All the while, expectations of in-flight projects are to move as fast if not faster than before as soon as the transformation starts.

Agility and transformation can bring out the best or worst of your organization. If your transformation is guided correctly and the focus is on answering the 5 Why’s, you will arrive at the core processes that need to be re-engineered. Surely, there will also be a few laggards in the organization who may not be on board with transformation, and hence may have to depart from the organization. This should not be surprising as not every one in every organization can be assimilated into an agile organization. Agile also amplifies the needs of your organization’s demands – especially from “traditional cost centers” – development, QA, and infrastructure. Suddenly there is need of investment for the right resources and to invest in new tools and infrastructure to promote your organization’s agility. It is key for leaders focus on lean and then automation – focus on getting to short-term results with a long-term success strategy.

As you start your transformation ask a few critical questions for investments:

1)    Do you have the right team members – who can BE agile, not only DO agile?

2)    Have you committed sufficient budget to invest in building key DevOps capabilities that can help in accelerating your organization?

3)    Is your leadership committed to aligning resources and processes to ensure that flow can breakout?

4)    Are your teams willing to be empowered and be held accountable? Is your leadership willing to de-centralize decision-making?

5)    Does your leadership team recognize the value of a transformed organization and are they willing to dedicate top talent for a few months to drive organizational change?

The responses to these questions will give you an indication of what expectations need to be set with your team, leadership and stakeholders whom are all eagerly anticipating your transformation yield results.

As you start your agile transformation journey, ask the difficult questions, be honest about your organizational capabilities and those it lacks. Plan the transformation and communicate the transformation roadmap so that all stakeholders involved can a have realistic expectation of your agile journey. Otherwise, you may find yourself in jumping out from one boiling pot to different, “agile pot” and, again, not realize the heat is turning up. .

<<Previous Article | Next Article>>

The Starting Problem Series – The Agile Resource Allocation Dilemma – Part 2

In the previous post, we outlined the Agile Resource Allocation Dilemma and recognized that this is a pervasive issue and a tough one to solve.

If you need some motivation to start solving for dedicated teams, here are some results that you could expect if you start agile teams without 100% dedicated allocation:

  1. Scheduling ceremonies – stand up, planning, review sessions, etc. become a nightmare due to conflicts in priorities and working on multiple initiatives, resulting in a lack of daily accountability of deliverables.
  2. Instead of teams working together every day and having opportunities to collaborate, they negotiate “how many core hours do we have a day and when?” This leads to uncertainty of delivery capability at the team level and more importantly task switching for resources that, as we know, causes waste in the system.
  3. The product owner and scrum master are often at odds with the functional managers whom still generally have delivery accountability and will often call the prioritization decisions. Given the other critical projects that need to be completed, additional task switching is inevitable.
  4. Sprint commitments mean nothing since team members with partial allocation do not consider the agile team as their “first team” and hence, struggle to establish and to own the team’s sprint goals. This commitment that individuals provide and then strive to meet, evaporates with partial allocation of resources leading to unmet sprint goals.
  5. Even for those team members whom are 100% dedicated to the team, it is often challenging to motivate them to commit to goals when other important team members are committed part-time to the cause and have other priorities. Missing sprint commitments becomes acceptable and a culture of commitment cannot find a foothold in the organization.

If you find yourself in this situation, here are some thoughts to consider:

  1. If you can get 100% allocation at the start of sprint – do it. This is absolutely the best course of action, so ask the “5 Whys” when someone tells you that “partial allocation is the best we can do.” By the time you get to the 5th Why, you will often find that the partial allocation mentality can be overcome.
  2. When you stand up agile teams, ensure that each team member can claim that their team is truly their “first team” – i.e. all work that is prioritized for a team member during transition is allocated via his/her first team. The functional managers need to request capacity from the product owner and scrum master of the agile team. In other words, if there is other critical project work, consider shifting those stories over to the team where the critical team member lives, prioritize it appropriately, and have the team commit to that work along with their other sprint commitments.
  3. Ensure that every person can claim that they are part of an agile team – i.e. they do 60% or more work for this team during transition. In this way, all team members will get familiar with operating within agile practices and they will most likely start demanding that all their work comes through the backlog and team commitments.
  4. Allow your product owner and scrum master to plan your initial sprints with capacity utilization of shared resources between 50% to 70% and gradually transition to 100% over 2 sprints. In this manner, you can treat the “other project work” as ad-hoc requests to be serviced with any remaining capacity.
  5. Determine a transition plan for achieving100% resource allocation, pick a date for getting there, and stick to it. The transition time will ease the pain of moving to the new allocation model and the deadline will provide some urgency to make sure you get there. This is time to be disciplined about the transition – don’t fake it!.

As a leader if you want to drive a “culture of commitment” in your organization, you have to demonstrate this commitment by your actions and allow agile teams to form that can make commitments. This is such a critical element for enabling your organization to create value at a sustainable pace. When you create dedicated teams, you significantly increase the team’s probability of success and hence, the results you expect from agile teams. When you have chosen to transform to an agile organization, begin with making this commitment – the commitment to fully allocated resources in the agile teams. The results will be exceptional!

<<Previous Article | Next Article>>

Passed the Certified Scrum Professional Exam!

January 17, 2014 by  
Filed under Agile, Training

Happy to report that I took the Certified Scrum Profession (CSP) exam this morning and passed with flying colors! My biggest reason for working towards the exam was using it as a forcing function to do a whole lot of reading about a variety of agile subjects. Over the past 8-9 months, I read the following titles and added to my knowledge base using mind mapping software (I love iThoughtsHD on the iPad):

  • Agile Software Development with Scrum – Ken Schwaber
  • Agile Retrospectives: Making Teams Great – Esther Derby
  • Succeeding with Agile: Software Development Using Scrum – Mike Cohn
  • Agile Estimating and Planning – Mike Cohn
  • Test Driven Development: By Example – Kent Beck
  • Agile Product Management with Scrum – Mike Cohn
  • Refactoring: Improving the Design of Existing Code – Martin Fowler
While I have been doing the Agile and Scrum thing for 9+ years now, there’s no substitute for continuous learning. So, thanks to these authors and Scrum Alliance for a great excuse for upping my agile game.

The Starting Problem Series – The Agile Resource Allocation Dilemma – Part 1

Congratulations! You have now convinced your management team to adopt agile. Everyone (or at least most) in your leadership team have extended their support toward this initiative. Everyone believes that this transformation will be excellent for your organization as 1) you are adopting agile 2) claim that your organization is challenging the status quo and 3) you will be able to do product delivery faster.

All transforming organizations and their respective leadership experience a tremendous amount of excitement during this phase. There is a desire to get 100% results and now the leadership team has to commit resources to agile teams to jump-start the transformation. At this “starting point” is when transforming organizations experience the challenges with making commitments.

Typically, prior to adopting agile, a software development and delivery organization would be organized around functional skills – Development, Quality Assurance, Project Management etc. This “tower” or “silo” organization makes sense in the waterfall world to “maximize” effectiveness of the delivery of the artifacts associated with that functional skill. In addition, team members work on multiple projects and tasks that are allocated to the resource by a project manager. This structure and process is very common across most pre-agile organizations.

In the new world, all these resources need to be part of agile teams – self organizing teams that produce 100% of the results based on sprint commitments made by its team members. The management team expects nothing less than this. However, the challenge facing leaders is that they often do not fully adopt the “dedicated team member” principle of agile and continue to allocate part time resources to the intended agile team. The most likely cause of continuing to split allocations of team members is that they still have a critical role or knowledge required to deliver other critical projects.

In the next posting, we will outline the impact of ignoring the dedicated team principle and some ideas for helping to transition to fully dedicated teams.

Next Article>>

AgileTrailblazers sponsoring Agile DC 2013

September 22, 2013 by  
Filed under Agile, Continuous Business Value Delivery, Events

AgileTrailblazers is proud to be one of the sponsors of Agile DC 2013. This conference is being held on Tuesday, October 8th from 7 AM – 5 PM at the Kellogg Conference Hotel at Gallaudet University in Washington, DC.

If you are attending, come by and meet Brian and Naeem at the morning coffee (on us!). We would love to meet you and talk with you about how AgileTrailblazers can help your organization achieve outstanding results with Continuous Business Value Delivery®.

If you haven’t signed up yet, go to the Agile DC site and make sure to be there for what promises to be a great event!

See you there!

The Big Lever

September 7, 2013 by  
Filed under Agile

I have a new article published today with Scrum Alliance on why release orientation (vs. project orientation) is so important to being agile.

Team Design Patterns – Wrapping it up

August 5, 2013 by  
Filed under Agile Organizational Design

Pulling all the ideas together from this article series, I want to leave you with a couple of key thoughts when you are trying to design your agile organization:

  1. When designing your next organizational structure, keep in mind that the target for your organization should be the Ideal Team Structure. The journey may take months or years, but you need to organize your teams to bring the opportunity to incrementally reach this target.
  2. Don’t avoid the inevitable disruption that a move from waterfall process to agile frameworks will bring. The impacts of the disruption won’t last for long and the benefits of doing business in an agile way will pay dividends quickly.
  3. Agile frameworks require thoughtful construction of an organization that maximizes delivery flow. Maximum delivery flow breaks out when the development teams are directly connected to the Business Intent Generators (BIG’s) and you don’t need multiple teams to turn intent into delivered solutions.
  4. These articles represent some agile team patterns. Your organization will most likely need one, many, or a hybrid of these patterns to be successful. If you have not had experience with an agile transformation and how to design your organization for this change, hire a solid enterprise agile coach to help you with this part of your transformation. You won’t regret it!

This completes this series on Team Design Patterns and I hope you found it useful and informative. Please post a comment to let know.

Previous article

© 2012-2013 AgileTrailblazers, LLC – All Rights Reserved

Team Design Patterns – Feature teams with mixed-composite skills

August 5, 2013 by  
Filed under Agile Organizational Design

This article is about the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skill teams.

Let’s assume that you still have an organizational issue of too much specialization of skills. With that assumption, it is difficult to jam-pack all skills, knowledge, and expertise into a 7 +/- 2 sized team to be able to transform every piece of business intent into a workable software solution. The idea behind mixed-composite skill teams is that you can create different mixtures of skills across many teams (each sized at 7 +/- 2) and design those teams so that their skill mix is a composite of skills that match the patterns of the business intent. Because you need the intent to be bite-sized (i.e., can be turned into “done” solutions in 2 weeks or less), it is very likely that any particular piece of intent will suggest changes to 5 or less platforms / components. So, let’s say that you design our teams in the following patterns:

  • Teams 1 and 2 possess a mix of skills in components A, B, C, and D
  • Team 3 possesses a mix of skills in components C, D, E, and F
  • Team 4 possesses a mix of skills in components A, B, C, and F
  • Team 5 possesses a mix of skills in components A, D, E, and F
  • Team 6 possesses a mix of skills in components B, C, D, and E

Because the pattern of business intent suggesting software changes in components A, B, C and D is more common, you can allocate 2 teams (Teams 1 and 2) that align their skills to this pattern of intent. The skills in Teams 3 through 6 match less common, but still often occurring, patterns of business intent. So, as a final step in the story splitting and grooming process, you need to steer the final stories towards the teams that have the needed skills to turn the story into a delivered solution. This certainly adds a level of complexity to the Product Owner’s role – matching story intent to team skill mix. It also implies that you may need to broaden out the breadth of Business Intent Generators (BIG’s) that feed into this pool of mixed-composite skill teams to be able to reasonably utilize their capacity. For example, if BIG 1 (see picture in the Ideal Team Structure article) requires 3 teams worth of capacity to get its expected level of solutions delivered, it might be difficult to construct 3 teams with the right mixtures of components A through F and keep them all well utilized. However, if BIG’s 1, 2, and 3 were to share their teams, they would combine to require 6 teams worth of capacity to get their solutions delivered. You then have significantly more flexibility to build the right team skill mixes across 6 different teams to marry up with how the patterns of intent are generated from these 3 BIG’s.

One very key point in constructing mixed-composite skill teams is that it provides the real opportunity for knowledge sharing and movement towards development of generalizing specialists (multi-skilled team members). For example, a developer on Team 3 who starts out with specializing in component C knowledge could readily work with other developers on the team to pair program and learn components E and F. Once that developer is now knowledgeable in all 3 of these components, they could be moved to Team 1 and provide the ability for that team to cover any story that involved change to components A through F. With leadership permission to broadly spend on knowledge sharing, you will have many teams that could handle any business intent that came their way. Before you know it, this organizational structure has transformed into the Ideal Team Structure.

So, if you can figure out what your patterns of business intent look like and then can build teams that fit those patterns, you will be blazing a trail towards 100% feature teams by starting with mixed-composite skill teams.

In the next and last article in this series, I will wrap up my thoughts on feature and component teams.

Previous article | Next article

© 2012-2013 AgileTrailblazers, LLC – All Rights Reserved

Team Design Patterns – Feature teams supported by component teams

July 21, 2013 by  
Filed under Agile Organizational Design

In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.

Here is a picture of an example solution delivery organization with feature teams and components teams:

Feature and Component Teams

From a flow perspective, Business Intent Generators (BIG’s) create a product backlog for one or more feature teams. The feature teams are built with members whom have the skills and knowledge most aligned with building solutions that meets the business intent. Additionally, the feature teams are constructed to maximize their ability to build the solutions for that business intent before needing to reach out to other teams to develop other required portions of the overall solution. When the feature teams get too big to be truly agile, you can create component teams constructed from team members with skills and knowledge specialized around specific platforms and/or components. Reminder – when beginning your agile transition, this model only makes sense when you have too much specialization of skills to allow the ITS to break out.

When the feature teams need updates to platforms and/or components that live outside of their team, they create backlog items for the component team(s). The component team Product Owner works with the feature team Product Owners to prioritize backlog items coming from across potentially many feature teams.  If you need to organize with component teams, it is best if each feature team only needs to interact with one component team that has all of the skills and knowledge of platforms and/or components not present in the feature team. In this design, there are two teams (i.e., one feature team and one component team) involved in delivering solutions to meet the business intent. If your architecture is very complex and specialization is very deep in the components of that architecture, you may need to have multiple component teams servicing each grouping of feature teams if all the component skill and knowledge cannot fit into one 7 +/- 2 component team. Whether you have one or more component teams for any feature team, it is most important to mix up the component specialization skills in each of the component teams so that team members can start working on cross-training and knowledge sharing across the various components and start the journey towards building an organization of generalizing specialists. It may be tempting to organize your component teams around singular components to minimize the disruption to current organization of platform/component specialists. This is probably the worst option for component teams as it does not provide any cross-training opportunities nor any path towards building an organization of generalizing specialists for the ITS.  The organizational re-design may be unsettling to team members. However, it may be an important aspect of beginning your journey to agile solution delivery with a clear signal to your organization that business will now be done differently. If the reasons for the organizational decisions and change are clear and communicated well, the shock of the new organization will soon pass and the highest majority of the team will help get the company to the new way of operating.

In the next article, I will outline the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skills.

Previous article | Next article

© 2012 AgileTrailblazers, LLC – All Rights Reserved

Team Design Patterns – Large Feature Teams

July 16, 2013 by  
Filed under Agile Organizational Design

In previous articles, I outlined the guiding principles for organizing agile teams (start here if you haven’t started the article series yet) and described the Ideal Team Structure (ITS). This is the first in a series of articles to describe various organizational design patterns to start the journey to the ITS given the real possibility that your large organization cannot switch to the ITS immediately upon starting the transition to agile solution delivery.

Given the challenges of an organization of specialists and complex systems architecture, the simplest way to organize your new agile teams is to stuff everyone needed to deliver solutions for the business intent into large (10 – 40 people), dedicated feature teams. The obvious disadvantage is that you are tossing out all the benefits of having small teams (7 +/- 2). First, think of all the communications connections needed for, let’s say, a 30-person team. According to Brooks Law, that would be 435 different communications paths within the team. Second, agile ceremonies, such as sprint planning meetings and daily stand-ups, will most likely turn into arduous, extended grinds with so many people in the room.  The other possibility is that these ceremonies happen within the expected time boxes (i.e., 15 minutes or less for stand-ups) but the worth dissipates as people rush past the real value of executing the fundamentals of the ceremonies in order to keep to the time box.

However, engineering is all about finding the best solutions given a set of constraints. If your teams can get past the downsides of a large team, this organization of an agile team may be the best solution for the short term. The biggest advantage of the large team model is that you do not generally have to reach outside of the team to build solutions for almost any business intent. From an ideal delivery flow perspective, keeping the builders of the solution in close collaboration with the Business Intent Generators (BIG’s) is a huge advantage.  Because you have almost every skill needed to build the desired solutions, the need for managing dependencies across teams is minimized or eliminated. Most importantly, the large team model does provide a path towards the Ideal Team Structure (ITS). With the mixed skills, application knowledge, and domain knowledge all on one team, team members can pair together and work in less familiar applications to gain a broader set of knowledge and skills. If this knowledge sharing investment is done well, team members can rapidly make their journey towards becoming generalizing specialists while retaining their learning in a knowledge capture platform (i.e., wiki). Before too long, the need for a large team diminishes as the ability of a smaller team of generalizing specialists can now build solutions that used to take a much larger team of specialists.

The key is to not live in the large team model for a long time. You need to clearly plan and execute your people transformation towards creating more generalizing specialists and thereby building for flexible feature teams that are more aligned with a 7 +/- 2 ideal team size. If you are going to try out this model as your interim step towards the Ideal Team Structure (ITS), you need to make sure to put an experienced agile lead (i.e., Scrum Master) in place to help facilitate the team’s activities and minimize the impacts of the large team disadvantages.

If the large team model scares you (and it should!), I will outline alternative agile team organizational models in future articles.

© 2012 AgileTrailblazers, LLC – All Rights Reserved

Team Design Patterns – Ideal Team Structure (ITS)

July 6, 2013 by  
Filed under Agile Organizational Design

Before I get on with describing the less-than-ideal organizational models, I thought it would be useful to spend some time describing what the Ideal Team Structure looks like to paint the picture of the target. And what better way to paint the picture than with a picture…

 Ideal Team Structure

The picture shows an example of two big departments, but this Ideal Team Structure can extend to many, many departments. Within each department, there are one or more Business Intent Generators (BIG’s) where each BIG has one empowered decision maker for the business. Most often, this BIG will play a function as a Product Manager for a line of business. Each BIG has a single backlog that is prioritized by Product Owner which could be a separate person or an additional role played by the BIG. Each BIG’s backlog can be serviced by one or more feature teams of generalizing specialists, sized at 7 +/- 2 people, living and collaborating right with the BIG’s. These feature teams are outfitted with the skills and knowledge to be able to create and modify 100% the system components needed to delivery that business intent.

At some point, the business intent can be larger than the scope of one BIG and takes on more of a “program-sized” look. So, it is inevitable that there will be dependency management across backlogs. If the nature of your product line makes this the case more often, you may want to have a role in your organization that plays the uber-Product Owner with responsibility to coordinate the de-composition of business intent into the BIG’s backlogs, manage dependencies across these backlogs, and set the over-arching priorities at the program level. To that end, the BIG’s in the business might also need to re-organize to help minimize the amount of dependency management required.

To make sure the feature teams are running at peak performance, you need to create continuous improvement teams (see the original overview article). When one or more feature teams come up with a retrospective backlog item that might be too big for them to address in the next iteration, the continuous improvement teams catch this backlog and build the requested support tools and systems for the efficiency and effectiveness of the whole solution delivery organization. Depending on your current needs for development operations tooling, you may be able to have one continuous improvement team service a total of 10-20 feature teams.

So, you might be thinking – this is more complex than I thought it would be. Well, the answer is when you scale your organization to deliver large software systems, the inherent challenge of organizing a large group of people needs to be tackled – regardless of your solution delivery framework. The Ideal Team Structure (ITS) deals with these challenges well to create an organization that flows, has the right teams at the right size and flexible skill sets, and is well supported.

In future articles, I will outline team design patterns that provide an interim stepping stone from a big waterfall delivery organization towards the ITS.

Previous article | Next article

© 2012 AgileTrailblazers, LLC – All Rights Reserved

Team Design Patterns – Feature Teams and Component Teams

July 6, 2013 by  
Filed under Agile Organizational Design

I spent time outlining the guiding principles for organizing agile teams in my last article. With the challenge of delivering business intent where changes to 10’s of platforms / components are needed and we only have developers and testers who specialize in singular platforms / components –   how do you organize?  There have been many books, whitepapers, and blogs (see here, here, here, and here). talking about the tradeoffs of feature teams (which can also be referred to as business vertical teams or product-aligned teams) and component teams. A feature team spends their days delivering user stories that are highly reflective of needed business intent whereas component teams spend their time delivering user stories that are generated by the feature teams because they need components outside of their scope of knowledge or responsibility modified to deliver the overall solution.

Much of the writing on feature and component teams puts feature teams in the “good” camp and component teams in the “bad” (and sometimes “evil”) camp. With the challenges outlined above, to some degree, component teams might be a necessary evil. The key is that your initial organizational design has feature teams as well and that you are creating an obvious maturity path towards possibly eliminating the component teams by pushing that component skill and knowledge towards the feature teams through knowledge sharing and architectural simplification. Ultimately, the goal is to create feature teams of generalizing specialists, living and collaborating right with the BIG’s (Business Intent Generators), and able to create and modify 100% the system components needed to delivery that business intent – the Ideal Team Structure (ITS).

In the next series of articles, I will outline specific organizational design patterns and discuss how each of them support the organizational design principles and how well each of them start carving the obvious path towards the ITS.

Previous article | Next article

© 2012 AgileTrailblazers, LLC – All Rights Reserved

Agile Organizational Design – An Overview

June 25, 2013 by  
Filed under Agile Organizational Design

Transforming to an agile solution delivery model is filled with lots of challenges, especially when you are talking about solutions delivered in an organization of a large scale. In these large organizations, one of the most common practices to achieve perceived efficiency is to build an organization of specialists. Every specialist knows how to get their specific tasks done very efficiently. Additionally, large companies typically have very large and complex software architectures for their systems. Between the specialists and the complex architectures, the job of getting the entire solution delivered is actually very inefficient since it “takes a village” (often a very big village) to get anything delivered. The most intrusive inefficiency with these organizational models is that they are not designed with support for natural delivery flow.

So, when faced with transforming from these challenges to agile delivery, there are some guiding principles that can help determine the best organizational design to make your move to agility most effective – i.e., getting the most business value delivered.

Those agile organizational design principles (in priority order) are:

  1. Organize around flow – Flow starts where the business intent is generated. So, you need to first figure out where the empowered decision makers in your business are living. Generally, if you are in a large company, there will be many “Business Intent Generators” (or BIG’s) to identify. True flow in your solution delivery will most readily break out if you connect the BIG’s directly with the team members with the skills and knowledge needed to build the solutions that meet the business intent. By connecting the BIG’s with the right team members, you maximize collaboration with the business and reduce information needing to take hops across teams in the company.
  2. 7 +/- 2 teams – There are numerous writings about the benefits of moving to delivery teams that are small, between 5 and 9 people. Beyond the most well-known benefit of reducing communication complexities associated with large team sizes, small teams foster the culture of commitment to achieving short-term goals which is harder to break out in large teams.
  3. Start journey towards flexible teams – When you start with an organization of specialists, you need to organize your teams so that you start making progress in creating an organization of generalizing specialists. By building up these more flexible team members, you improve the probability that someone on the team has the knowledge and skills to get any particular business intent turned into a solution, and therefore, the team does not need to reach outside itself to deliver. As the team members are more flexible, the pressures on having larger-sized teams diminish as well. There are two key paths to begin the journey towards flexible teams. First, you need to put people with differing knowledge and skills on the same team and then provide them the time (and potentially reduced expectations for actual delivery) so that they can concentrate time on knowledge sharing and capture. Second, you need to work on simplifying and consolidating your software architectures to reduce the learning curve for team members to pick up new skills and knowledge.
  4. Build continuous improvement teams – The move to agile requires support for rapid development and refactoring. This support includes continuous integration (CI) systems, agile configuration management (CM), rock solid environment provisioning and support, test automation tooling and governance, and agile release management. Many of these support roles are best filled with folks that understand these practices. However, for example, you could find some smart developers who are fed up with the lack of CM, CI, and environments. These developers would very passionately get a first round of these practices and tools in place to get you started. The main point here is that you do not forget to get these support roles funded right away and create continuous improvement teams to “catch” backlog to build these support tools and systems for the efficiency and effectiveness of the whole solution delivery organization.

So, you have the guiding principles for organizing to build teams for agility. Now the reality hits – you are starting from a large solution delivery organization of specialists and you cannot adhere to all of these principles immediately.  In some future articles, I will outline some team design patterns for large companies that deal with the tradeoffs across the guiding principles and may provide some thoughts on how to organize your teams as you move down the trail of your organizational transformation to agile.

Go to the next article

© 2012 AgileTrailblazers, LLC – All Rights Reserved


Keynote Speech at Agile After Dark

June 21, 2013 by  
Filed under Agile, Events

Just finished presenting as the keynote speaker at an Eliassen / VersionOne event – Agile After Dark – Enterprise Agile – in New York City. It was a fantastic event and I got the chance to also be a panelist after the keynote along with some other practitioners of Enterprise Agility.

My presentation was titled “Four Views of Enterprise Agility” where I walked through four perspectives of Enterprise Agility – Executive, Product Line Owner, Associate, and Customer. This presentation is embedded below.

Some recommendations for viewing:

  • Hit “Start Prezi” to start.
  • View this in full screen mode by pressing the full screen button in the lower right corner of the frame.
  • Press the Play button in the lower left corner to put the presentation in auto play. Voiceovers are included.
  • If you want to skip to past the current slide, hit the right arrow key and the voiceover will pause and pick up in the next slide.


SAFe for Small Value Streams – The Portfolio Level and Wrapping It Up

At the Portfolio Level, there are really no significant impacts for SVS pattern organizations. We still use Kanban systems to manage the business epic and architecture epic pipelines that flow into each of the Agile Release Trains (ART’s). In SVS pattern organizations, we still have high value in utilizing Investment Themes to drive operating budgets across all the ART’s. Additionally, because an SVS organization is operating at scale, we need to have an Enterprise Architect to drive technology direction across all programs / ART’s.

In summary, SAFe provides a fantastic framework for scaling agile at Small Value Stream patterned organizations. With the addition of a thin layer for SVS Level Product Management and Backlog, SAFe provides a solid structure for implementing broad program initiatives while maximizing flow for the majority of product development happening locally within the SVS’s.

<<Previous article  1  2  3  4  5  6  | End of article series!

SAFe for Small Value Streams – Business Intent Flow and Organizing to Deliver Program Level Features

Small Value Stream (SVS) pattern organizations have the largest portion of their product development flow starting locally with intent generated from within each SVS. Therefore, we can optimize the planning within any SVS by using the Vision, Roadmap, and Program Backlog elements of SAFe by localizing these concepts to each SVS. However, there are rarer, but important, program-wide epics that require coordinated flow and planning across multiple SVS’s and their associated teams. I first introduced the following picture in the second article in this series. It depicts the business intent flow between the Program and SVS Levels in an SVS organization.


Let’s dig into the picture a bit, starting at the top. For those rarer Program Level features that cut across multiple SVS’s, the Program Level Product Management team is responsible for managing the Vision, Roadmap, and Program Backlog at the Program Level (depicted in blue). The Program still needs to manage business features along with architecture features (depicted in red) that are applicable across multiple SVS’s. The SVS-Level Product Management team (one for each SVS) is responsible for managing the Vision, Roadmap, and SVS Backlog at the SVS Level (depicted in green). Depending on the needs and priorities at the Program Level for the next PSI, the SVS Level Roadmaps and Backlogs will be informed by those Program Level priorities.  Additionally, an allocation model developed for each PSI will be utilized to determine the apportionment of the Program Level features vs. SVS Level features for each SVS. Those SVS’s, and their associated teams, that are heavily allocated towards Program Level features for the upcoming PSI (like SVS # 1 above) will be fully involved in the Program-Level Release Planning event at the start of each PSI. These SVS’s can still plan for delivering some SVS Level features in that PSI but they will focus their attention and priority on the Program Level features during Release Planning. SVS’s and teams that are slightly impacted or not impacted at all by Program Level features (like SVS # 2 above) can send proxies (such as Product Owners) to the Program Level Release Planning event rather than sending all team members. Therefore, when considering SVS and team allocations for Program Level features, it is better to have SVS’s and their teams mostly involved or mostly uninvolved with the delivery of program features so that there is clarity of participation in the Release Planning event.

As expected from SAFe, the participants in the Release Planning event will produce a set of PSI/Release Objectives and a PSI Program Plan. Those Objectives will mostly include the Program Level objectives but can also include any notable SVS Level objectives that should have visibility at the Program Level. The majority of SVS Level objectives will not be included in the Release Planning’s Objectives since they represent planning that is primarily done sprint-by-sprint (or PSI-by-PSI if that is preferred by the SVS) solely within the teams of that SVS.

Regardless of a particular SVS’s participation level in the Release Planning event, all teams within the Agile Release Train will still gain the lean benefits from a common cadence (i.e., 2-week sprints and 8-12 week PSI’s) and synchronization across all teams.

The System Demo held at or near the end of every 2-week iteration still holds the same value in the SVS pattern organizations. The System Demo should be concentrated on the PSI/Release Objectives and no significant time spent demonstrating any local SVS objectives which can be targeted in a separate demo aimed towards the local SVS stakeholders. Similarly, the Solution Demo, as part of the PSI’s Inspect and Adapt workshop, should be concentrated on the PSI/Release Objectives.

For SVS pattern organizations, the Program Level is really the most impacted level in SAFe. The next article will describe the Portfolio Level of SAFe applied to these organizations.


SAFe for Small Value Streams – The Program Level

When considering the Program Level of SAFe applied to Small Value Streams (SVS’s – see the first article in the series for an introduction to SVS’s), I will describe SAFe elements that “work out of the box” and those challenges that SAFe brings and solves for SVS’s.

First, let’s look at a working model for an Agile Release Train, or ART, for an SVS pattern organization. As I described in the first article in this series, an SVS pattern organization, we might have 10 – 20 SVS’s all working on a connected technology stack with each SVS having 1 – 4 teams.  Therefore, we are talking about 20 – 50 teams contributing to the code base for the next release, assuming we average about 2 – 2-1/2 teams per SVS. The SVS pattern ART then requires these SAFe elements across all SVS’s to frequently release software across the 20 – 50 teams: 

  • Release Management – the SVS ART still needs a governing set of stakeholders who ensure the release content is technically sound and coordinated to be a viable set of business intent. Because there are many SVS’s, we might need to proxy in the Release Management team to represent the combined interests of all business lines. Often, this representation can come from the business that is the closest proxy for the customer – like the Sales or Marketing business.
  • Shared resources, including User Experience (UX), System Architect (SA), and Release Train Engineer (RTE) – Because the SVS’s are often connected by a common technology stack and deliver combined releases, all of these shared Program Level roles are critical for making the Train run. A UX team ensures the user experience remains consistent across the deliveries from the 20 – 50 teams. Similarly, the SA ensures lean governance of existing and evolving architectures in the design and code delivered by the teams and works with the teams to ensure that an architectural runway is maintained. And most critically, the RTE makes sure the success of all elements of the upcoming release.
  • System Team – we still gain enormous value in an SVS pattern organization by centralizing the System Team functions such as configuration management, continuous integration, end-to-end automated test governance, and environment management. If staffed liberally, we can more economically provide all of these important services to the 20 – 50 teams with little to no wait times for servicing the needs of all teams. Additionally, we can provide key governance on these delivery elements to ensure the release gets out the door reliably.
  • Inspect and Adapt (I&A) workshop – all of the elements of I&A still apply for SVS organizations. There is real value from the solution demo, quantitative measurement, and problem solving aspects of the I&A workshop. Because the release orientation of the SVS organization, this I&A workshop provides the venue for focusing on release or program level continuous improvement. For practical purposes, we will have representation from each of the teams attend the I&A workshop rather than trying to have 150-400 team members all in the same room.
  • Economic Prioritization – all of the existing aspects from SAFe for prioritizing work based on the economics of product development flow using WSJF (Weighted Shortest Job First) are still wholly applicable for SVS organizations.

So, for SAFe at the Program Level, we have not yet covered Roadmaps, Vision, Feature Backlog and Product Management. The SVS’s develop most of their business intent independently from other SVS’s. However, we still need to get those rarer, but very important, program-wide epics and features delivered. I also have yet to cover the topics of Release Planning and Objectives. Since these topics are really the crux of using SAFe in an SVS pattern organization, I will devote the entire next article in this series to these topics.

SAFe for Small Value Streams – The Team Level

One of the great parts of the SAFe framework is the emphasis on usage of industry standard practices like Scrum and XP (Continuous Integration, Pair Programming, Test-Driven Development, and Acceptance Test Driven Development) at this level. Scrum provides the light framework for teams to deliver “done” software at a regular cadence and XP provides many of the disciplined technical practices that make it possible for teams to be hyper-productive.

So, even though the number of teams in a SVS is small (1 – 4 teams), to be truly agile, the practices within each team still require frameworks like Scrum and practices like XP.

Regarding SAFe’s Potentially Shippable Increment (PSI) cadence and synchronization, these elements do impact teams but still fit very well in the SVS pattern. All of the SAFe concepts around Lean Product Development Flow still apply to the SVS pattern. These organizations benefit from a common cadence across SVS’s for aligning program intent delivery or synchronization of commonly used technology stacks. Therefore, PSI’s are still very useful in an SVS pattern organization. Because it is more the exception for needing coordination of business intent across SVS’s, each SVS can generally develop useful, marketable intent in shorter timeframes. Therefore, the PSI for an SVS organization might not need a full suggested 8-12 weeks (i.e., 3 – 5 two-week development sprints plus the Hardening-Innovation-Planning (HIP) sprint). In my experience at SVS organizations, there is often the ability to align to shorter PSI’s (4 – 5 weeks). Especially if the SVS organization invests properly in continuous integration, the overhead for releasing to production can be small enough (<= 1 week HIP sprints) to favor the value of releases getting out the door at a higher frequency. SAFe does provide for the release cadence being faster than the PSI cadence. However, I have found that the value of a HIP sprint, and in particular the Hardening intent of the HIP sprint, synchronized across the many SVS’ is often necessary to get to a viable production release.

In summary, the Team level of SAFe works pretty much as-is for organizations with the SVS pattern.  Some of the SAFe Program Level elements do have impacts on operation of the Team Level. These team-impacting elements include Release Planning and Inspect & Adapt Workshops. These will be covered in the next article on the Program Level.

<<Previous article  1  2  3  4  5  6  Next article>>

SAFe for Small Value Streams – Small Value Stream Pattern Explained

To get grounded on what the Small Value Stream (SVS) pattern looks like, I will describe what SVS’s (1 – 4 teams, roughly 7 – 35 team members) look like.

First, let’s describe some examples of business value streams at a financial services company so you can get a flavor for the problem set:

  • Deposit Services – business aligned to checking, savings, and CD products
  • Deposit Operations – business aligned to back-office processing of deposit product features, such as check deposits, ACH processing, etc.
  • Home Loans Acquisitions / Sales – business aligned to marketing of and acquisition of mortgage customer applications
  • And so on….

Second, there is the matter of scale. For medium-sized companies, the IT investment in their products does rise to a level that you still need to be concerned with how to scale agile delivery. However, you are generally talking about IT shops with 100’s of team members rather than 1000’s. This does not preclude the potential that the SVS pattern might be present in larger companies. However, you will generally find that larger companies, due to their scale, will have 6 – 12 teams dedicated to each value stream much like the examples given above. In SAFe terms, that is about the right size for an Agile Release Train.

Third, the business intent for these SVS’s are most often not connected to each other. Therefore, they can create and maintain vision documents, roadmaps, and program backlogs that are mostly independent from each other and that allows them to make faster, local, and more adaptive product decisions. There are occasions, more the exception than the rule, where program level program initiatives need to take precedence over the SVS’s local priorities. For example, re-branding the website or an architectural shift to a new database version or system. For these broader initiatives, coordination of priorities and feature backlogs across each of the affected SVS’s is required to make these program deliveries happen.

Fourth, as an optional element of the SVS pattern, the technology stack (presentation tier, service layer, and back ends) for any SVS might be heavily shared across multiple SVS’s. So, while the business intent is mostly independent across SVS’s, there is a common set of platforms and components that are updated by teams in many SVS’s. As further optional element of the SVS pattern, these updates by many SVS’s could combine into a common, synchronized release that happens at a predictable cadence.

So, the SVS pattern emerges because: 1) the scale of each value stream is relatively small, 2) their business intent is rarely connected across value streams, and 3) optionally the technology stack is shared across value streams.

Therefore, for example, elements of SAFe, like the “all team members on board” Release Planning event, do not seemingly help the majority of value delivery across 20-50 teams. Can I realistically expect to get 300+ people in the same room for 2 days? Probably not. And if you could, would such a meeting have any chance of being effective? Definitely not. But what about those rarer program initiatives that do cut across multiple SVS’s – how do we get them delivered? In a future article, I will describe how SAFe, in a slightly modified execution at the Program Level, could be used to aid in the delivery of these larger program initiatives. As a preview of that article, here’s a picture that introduces Small Value Stream Product Management and accompanying Vision, Roadmaps, and Backlog for each SVS.


You might be saying, “Do we really need another layer?” Well, the highest majority of product management planning is happening within each SVS regardless of the broader Program Level planning. Therefore, the SAFe Program Level Product Management is relatively lightweight and provides a binding structure for getting those rarer cross-SVS initiatives delivered. I will spend more time explaining this flow in the future article.

In the next few articles, I will start looking at each level of SAFe, Team, Program, and Portfolio, and outline how it can be applied to organizations with the SVS pattern.

<<Previous article  1  2  3  4  5  6  Next article>>

Applying Scaled Agile Framework (SAFe) for Companies with Small Value Streams

Last year, I got inspired to read Dean Leffingwell’s “Agile Software Requirements” book. As I read Dean’s concepts (better known as the Scaled Agile Framework™ – or SAFe for short), it was obvious to me that we had independently arrived at similar framework-level solutions to scale agile and move towards release oriented delivery (see my Scrum Alliance article – The Big Lever). My experience that is most relevant to SAFe occurred during my tenure at a medium-sized financial services company where we transitioned from waterfall to agile and then grew to execute monthly releases with solutions contributed from 30+ scrum teams. The principal difference in our frameworks was that ours was developed around the fact that we had many small business value streams mostly disconnected from each other regarding business intent but connected by a mostly shared technology stack that provided the solutions to every value stream. Each small value stream only required (or could only afford based on our budgets) between 1 to 4 teams worth of capacity.

At the end of 2012, I had the privilege to attend the SAFe Program Consultant (SPC) Certification training in Boulder with Dean leading much of the training. Yes, I passed the test and became an SPC! But, more importantly, I started thinking about all the benefits of the SAFe framework and how it could be applied into a Small Value Stream organization much like the one described above.

This article series will explore:

  • A deeper dive into describing the pattern of a Small Value Stream delivery model,
  • Similarities in frameworks between SAFe and the framework we developed at the financial services company – for the purposes of this article series, let’s call this SVS-AF or Small Value Stream Agile Framework, and
  • Potential execution modifications for SAFe to account for the SVS-AF shortfalls and benefits.

I hope that you find this article series helping you apply SAFe if your organizations have the Small Value Stream pattern. This article series is mostly intended for readers with a high level of familiarity with SAFe and agile concepts.

1  2  3  4  5  6  >>Next article

Agile-Colored Glasses – mentioned in VersionOne’s Agile Chronicles

March 21, 2013 by  
Filed under Agile

Scrum Alliance article, Seeing the World Through Agile-Colored Glasses, got a nice mention in the March 2013 VersionOne Agile Chronicles! Nice surprise!

Seeing the World Through Agile-Colored Glasses

February 27, 2013 by  
Filed under Agile

My article “Seeing the World Through Agile-Colored Glasses” got published on Scrum Alliance this morning. This is my take on trying to explain what agile really means. Thinking about agile as a lens for seeing the world, making decisions, and taking action. Take a look!

Presentation at Philly ETE Conference

June 17, 2012 by  
Filed under Continuous Business Value Delivery

Naeem Hussain and I had been working on the Continuous Business Value Delivery (or CBVD) concept for a while and put the first round of that concept together for the Philadelphia Emerging Technologies for the Enterprise Conference in April 2012. The focus of the session was about the leadership and management innovations that are critical for enabling CBVD.

A full audio recording of the session with accompanying slides can be seen here. Hope you enjoy it and please post back any feedback.

© 2012 AgileTrailblazers, LLC – All Rights Reserved