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)
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:
For additional conference information visit the CDSummit website.
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
|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.|
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.
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:
- 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).
- 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.
- 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.
- 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.
- Menlo has done a great job at making “software factory” a term for a great place to work.
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.