7 Habits, Agile, Agile, Experiment, Focus, Goals, Improvement, IT, Leadership, Learning Lessons, PI Planning, Release Train Engineer, SAFe, Scrum, SDLC, success, Technology, Tools, Trying, Vision

Prioritizing for I & A and PI Planning

A few weeks ago I started a new position called Release Train Engineer(RTE). This role is responsible for facilitating the Agile Release Train (ART) moves efficiently and executes effectively.  

When I started the position in late June, I had 2.5 weeks to get prepared for the two most significant events within the Scaled Agile Framework (SAFe) that fall on the same week – Inspect & Adapt workshop (I&A) and Program Increment (PI) Planning. I & A is the final event during the PI and PI Planning is the kickoff to the next PI. I & A is an opportunity to celebrate all the great work done in the past PI and identify ways to relentlessly improve for the next PI. PI Planning kicks off the next quarter to determine what work can get accomplished within the PI.

I quickly realized with my end goal in mind (a successful I & A and PI Planning) I needed to identify what was the most important (and urgent in this case) things to get done and prioritize those items accordingly. (side note: in the future, I hope to find ways to move some of these items into quadrant 2, so they are less urgent and just as important)

Here is what I did to get ramped up and successfully facilitate I & A and PI Planning

  1. Identify the right people – Making sure I knew who the Product Manager (PM), Product Owners (PO), Scrum Masters (SM), Solution Architect and Software Architect were, was my number one item. This was my top priority because I needed to understand what work was going into the next PI Planning and understand how the current and almost completed PI was coming along. Asking questions to the right people would help me understand the most important information in a short period of time.
  2. Understanding the features being brought into PI Planning – This was my second highest priority because the RTE needs to make sure these items are ready for PI planning. The RTE doesn’t control this work and due to this, they should make sure features are as ready as they can be before PI Planning. If the features are not ready, the RTE needs to facilitate their readiness. In this case, we had a few features intended on being ready for PI planning, but one feature needed to be broken down. The PO and Architects did a great job of working in the last two weeks to get this feature broken down in a way that multiple teams could work together, rather than dumping all the work on one team.
  3. Making sure socialization happens and is helpful – Socialization is hard but important, which is why as a new RTE I wanted to make sure this was happening and going well. Socialization is a proactive preparation approach to PI Planning. If the features aren’t ready or unclear, socialization will suffer because the team will get bogged down by questions and may cause confusion in the future. A lack luster socialization will create inefficiencies in PI Planning, which can slow down a very fast paced two days (you can read my last article here about socialization).
  4. Brainstorming the I & A narrative – I & A is an opportunity to tell a story about the train’s journey during the PI. It is not a time just to dump data or point fingers. It is a time to improve and part of that improvement is to understand the context behind what happened in the PI using data to help elevate the narrative. I chose Grit as the anecdote to tell the story. The team has a ton of passion about Appraisals and persevered through many challenges. The data helped show how a lot of great things were achieved, despite the challenges throughout the PI.   
  5. Understanding data – Data can be dangerous if used incorrectly or misunderstood. As a new RTE who was not part of the train in the past, I was unsure what data was being looked at and measured throughout the PI. I talked with several of the right people (like the Scrum Master) to understand what they were or were not tracking. Also, I bounced ideas off other RTEs to identify what data made sense to use. I used a handful of data points in our I & A: Capacity Allocation – Planned versus Actual, Train Velocity – showing how work from another PI came in throughout the PI, and Cumulative Flow Diagram – showed how our cycle time was pretty good despite lots of unplanned work.
  6. Reviewing the SAFe site – When I started, I had a working knowledge of SAFe and the RTE role, but I am always learning and finding new information. In fact, I referred to the SAFe site on a regular basis when I was a Scrum Master. As I began to prepare my presentation, I constantly referred to SAFe’s site to make sure all my presentations hit on the major items needed for both events.
  7. PowerPoint – Creating my slide decks was really the last thing I did, BUT it took way more time than I anticipated. PowerPoint is not something I use often because I don’t give a ton of presentations and when I do use PowerPoint, I don’t make a bunch of slides. This time around, I knew I needed more information on the slides especially because of the Problem-Solving Workshop. Despite the time I spent working in PowerPoint, I still believe it made sense to prioritize this last because everything else I did before this gave me the content, I needed for my slide deck.

Image credit: https://www.developgoodhabits.com/eisenhower-matrix/

Advertisements
7 Habits, Agile, Estimation, Experience, Improvement, Leadership, Learning Lessons, SAFe, SDLC, Technology, Vision

3 Tips For Your Next PI Planning

April kicked off our second Program Increment (PI) Planning event using the SAFe framework. My team and I reflected on the difference between PI 1 Planning and PI 2 Planning.

Three topics came up that we believe helped us improve our PI Planning.

Clear Socialization Purpose and Different Meeting Types

  • Understanding the purpose of socialization helped the team understand why socialization was so important and what needed to be accomplished during these meetings. This led the team to identify what they already knew and what gaps they needed learn, which led to better questions during each session.
  • Our Product Owner used a variety of socialization meeting types to produce new insights and different questions.
    1. High level, first pass – we just went over the features we intended to plan during PI Planning. This was to get our feet wet.
    2. In depth with shared services – This helped us think about our dependencies and ask questions we didn’t think of during our first session.
    3. Teach Back – Our Development Team taught our Product Owner the features we were going to work one. Any gaps in their teachings our Product Owner answered in order to finalize our preparations for PI Planning.
  • Side note: The teach back was inspired by a separate team that was planning on doing the same thing!

Begin With The End In Mind Strategy Towards Team PI Objectives

  • Identifying and clearly writing our PI objectives upfront helped the team envision our destination, so we spent the majority of time figuring out how to get there.
    1. The Development Team did an excellent job using the remaining time to come up with how to accomplish the objectives and they were able to take on unexpected work because it fit into our destination.
    2. A fourth feature was brought to us and because of our clear objectives, the Development Team knew they could commit to the feature.
  • Working closely with our business stakeholders and other train leaders to get feedback on our objectives helped speed up the process. This prevented us from getting stuck and verified we were headed in the right direction early in the process.
    1. We had great conversations about what should and shouldn’t be a stretch objective.
    2. These conversations helped us think about what we truly control and not trying to achieve outcomes out of our control.

Shorter Feedback Loops From Shared Services and Business Stakeholders

  • Leveraging our shared services with more urgency and without hesitation helped us get answers quickly and prevented major bottlenecks in the planning process
    1. Listening for key phrases like ‘I am not sure how that works’ or ‘I assume that is what was meant’ immediately triggered our Scrum Master to bring in stakeholders, shared services or other leaders to help get answers
  • Working hand-in-hand with business stakeholders helped improve ideas around the objectives to avoid unclear wording and reduced time to get business buy-in when finalizing our objectives.
    1. Also, because we were getting our business stakeholders involved earlier, they seemed more engaged and more part of the team.

What helped you in your PI Planning or what do you think of these tips? Let me know!

Photo Credit: https://www.agileoctane.com/2018/03/31/the-magic-of-safe-pi-planning/