Links to Article Series and Key Posts
Here’s the starting links for some article series and key posts. Enjoy!
- Blazed and Confused (Scrum Alliance article)
- The Starting Problem Series
- Keynote Speech – Four Views of Enterprise Agility
- Agile Organizational Design
- Applying Scaled Agile Framework (SAFe) to Companies with Small Value Streams
- Seeing the World Through Agile-Colored Glasses (Scrum Alliance article)
- The Big Lever – Project vs. Release Orientation (Scrum Alliance article)
- Management Innovation to Achieve Continuous Business Value Delivery (presentation at the Philly ETE conference)
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.
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!
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.
- 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.
- Organizational Structure – Release 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
- 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.
- 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
- 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.
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.
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.
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.
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:
- Enterprise Release Management
- Enterprise DevOps
- 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.
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!
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!
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.