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.
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.
There are many misconceptions about what Agile means. Here are a few of the most common that I've heard:
So then, what is Agile?
Agile frameworks, like Scrum, are generally easy to understand. With many teams where we have taught and coached, there are some common mindset and practice tweaks that make a real difference to productivity. Here's our top 3 easy fixes to boost the level of productivity of your agile implementation.
1. Establish Team Norms - When teams first form as new teams or when the composition of a team changes mid-stream, many teams skip this step of establishing (or re-establishing) Team Norms. Without this critical team discussion, team members have to discover through time, usually too much time, what expectations they have from each other on how to work and interact as a team. This usually leads to passive tolerance of bad team behaviors and formation of cliches (sub-teams) gossiping about the dysfunctions in the other team members. Alternatively, make sure to take a break from delivery and hold a 2-3 hour Team Norms session to air these expectations. The Team Norms session should talk about values that team members hold dearly, expectations on logistics for how the team operates, and a solid airing of how the team wants to deal with conflict. You should expect that these discussions will be challenging. However, on the other side of establishing Team Norms, you will have a team that has clarity on how to work together as a whole team. With that clarity, you will find that the level of team dysfunction will be significantly reduced, and conversely, the productivity of the team will rise and a foundation for continuous improvement in the team is now possible.
2. Measure and drive your "Ready-State" backlog - Agile is not just about the software development and testing. When Agile is really working well, it is about the flow of product ideas moving rapidly to production-ready, customer-consumable product updates. One very common productivity-killer in Agile teams is not having enough well understood, "groomed" backlog when iterations / Sprints start. This lack of "ready-state" backlog leads to teams struggling during planning (i.e., Sprint Planning) to know what they are supposed to build and how to build it. Half-baked planning leads to ineffective iteration execution and often with product that does not meet the customer need, therefore leading to re-work. There are 3 easy steps to inject a new level of discipline into your team to get a solid ready-state backlog. First, establish a clear Definition of Ready - which criteria should backlog items meet in order to be declared "Ready". Second, define a backlog grooming / refinement flow with clarity of roles / responsibilities for moving backlog items from "Grooming" state (i.e., backlog item needs additional refinement) to "Groomed" (i.e., backlog item is teed up for final refinement by the whole team) to "Ready" (i.e., the whole team has declared that the backlog item meets the Definition of Ready). Third, the Backlog / Product Owner should report regularly in daily standups the depth of "ready-state" backlog. The depth should be measured in how many iterations / Sprints worth of backlog are in the Ready state. If the "ready-state well" is getting dry (below one iteration's worth), this should be a signal to the team to jump into re-filling the well and put more energy into grooming additional backlog. With a solid ready-state backlog, teams will find that planning will be more effective and that iteration execution will be clearly aimed at the target established from planning. With clear goals, the team will be wildly more productive towards achieving real customer-valuable delivery.
3. Take retrospectives seriously - Too often, teams take the "check the box" approach to retrospectives. Given retrospectives are a defined part of Agile frameworks like Scrum, teams almost feel forced into holding retrospectives and cannot wait for this meeting to be done and over. The skepticism or boredom with retrospectives are usually associated with one of a few causes - no real action taken from the retros or re-using the same format for retros over and over. For teams that take retrospectives seriously, they are the critical enabler for a Culture of Continuous Improvement. Teams that embody a real Culture of Continuous Improvement have no ceiling on how productive they can become. There are two easy steps to make retrospectives impactful for your team's productivity. First, establish as part of your Team Norms (we talked about this above) a commitment to hold the team accountable for identifying and following through on at least 1 improvement from each retrospective. You can build this accountability into your retros by starting each retrospective with a look back on the improvement commitment made in the last iteration and having a transparent discussion on how the team did on acting on that improvement. Second, if retros are getting stale and boring, spend some time to read Agile Retrospectives (Derby / Larsen), understand the suggested structure for conducting retros and look for new ideas for different activities to "mix it up" at your retros. The structure suggests conducting a Closing to reflect on the retrospective itself - a "retro on the retro". This might seem like overkill, but you will quickly find the approach and activities for retros that really resonate with the team and produce valuable improvements.
These 3 fixes can really get your team to the next level of productivity. So, step back and take a critical view if any "tune ups" could be valuable for your team.
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.
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!
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.
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.
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.
