A New RTE’s Struggles

As a new Release Train Engineer and former Scrum Master, I am ambitious and excited to dive in to help my train and teams succeed. In both roles, I struggle challenging and supporting my trains and teams to follow a few concepts, I believe are valuable.

Vertical Delivery (working software is the primary measure of progress)

Why is this important?

Working software demonstrates progress, enables healthy feedback into the development process without too much re-work and illustrates how much work it takes to deliver amazing software (plus we can celebrate the progress!)

My Struggle

Overall, shifting mindsets is hard. Our tech team can do the work. Moving away from getting everything together from the onset, is the difficult piece. Getting one piece of data from the database to the UI or even faking the data and getting data to flow from one place to the front end can be a big change. One thing I’ve seen that seems to help think through how to deliver vertically – during PI Planning, one team planned out what they would demo at the end of each iteration. If the demo description didn’t seem to deliver new value, the work may not be very vertical.

Set Based Design (assuming variability; preserve options)

Why is this important?

Change is inevitable. This helps designs and solutions pivot away from dead ends when new information is acquired. Also, this helps support innovation and conquer unknowns.

My struggle

From my perspective, during PI Planning or Iteration Planning the team has a clear idea of how they are going to do something and then go and do that thing. While this makes sense (SAFe also mentions how this is normal), it seems like we hurt our ability to innovate and try new solutions that may work better than just sticking to the plan (responding to change > following a plan). I don’t know if this is just a concern because of the technology we use and mindset we’ve created or if every organization has this kind of dilemma when also trying to deliver valuable working software.

Improved Predictability (program execution)

Why is this important?

Predictability helps others understand when they can receive their valuable working software. The more predictable a team, the better experience and experiences matter a lot. For example, if we expect websites to load within milliseconds and it takes 20 seconds to load a website that will result in a bad experience. That experience matters because we won’t go back to that website if it takes a long time to load.

My struggle

Sizing is hard. Sizing is an estimate, but it doesn’t need to be precise. I think this takes practice and the better the work is broken down, which also takes practice, the better we can size. I believe the skill of sizing can be improved and results in better expectations when it comes to major gaps. Often, I see rushed estimations (maybe because of pressure) or I don’t see a lot of time spent thinking through the estimates. Again, there is a delicate balance between wasting time on solving the entire story (analysis paralysis) versus getting just enough information to estimate how long it will take to complete the work.

What do you think?

I know the teams and trains I work with can execute on these concepts. I think as an RTE I can better support them in doing this by finding examples, finding mentors to help guide them and being unafraid to challenge “the why” when someone says it “can’t be done” like that.

I wanted to share my struggles because I think others have these struggles, and it is OK to openly talk about what we are working through. If anyone has any suggestions or thoughts, I’d love to hear from you and what you learned along the way!

Photo Credit: https://medium.com/@media_75624/release-train-engineer-rte-is-not-a-traditional-manager-b51536bd6664

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/

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/

SAFe Team Self-Assessment Experience

Our company recently adopted the SAFe framework. One pillar of SAFe’s House of Lean is Relentless Improvement. There are many ways to identify areas to improve – retro, inspect and adapt, iteration review and system demo just to name a few.

Another tool that SAFe provides is Team Self-Assessment.

When I started looking into the tool, I noticed there wasn’t clear direction around how to use it, just a short description of the tool’s purpose. I started to think:  

• Does each team member take this and then I average the scores?
• Do we take this together, like sizing, where we all agree on a number?
• Do I want to get a quick snapshot here, or have the team kind of think about each question (with a timebox either way)?
• Am I over thinking this in general?
• How often should this assessment be taken? Once a PI, multiple times? Once every other PI?

I started to do some research on implementation practices and I found an article with great ideas.

• What I liked
  • They suggest doing this as a team activity, rather than having people take the assessment and submitting it back to one person
  • They used an external facilitator, so the entire team could focus
  • They used a planning poker cadence (everyone says their number at the same time) using post-its & time boxing each question
    • Also, they used posters to represent each category and placed sticky notes along the axis (see pics in the post)
• Questions that remained
  • Does it make sense to do this more often than once a PI?
  • How does this work with remote team members?
  • How does the scoring work with a poker cadence? Discuss it to meet somewhere or just average the scores?

This article helped me think about implementation, so the team took the assessment last week and here are some more takeaways from our experience.

Our Implementation

• We took the assessment after the second of six iterations in our first PI (after ~1 month)
  • I originally planned to do this each month, to get a good idea of how the team is working within the PI
• We used Zoom to facilitate discussion (3 remote team members and 3 local team members)
  • Everyone had a working webcam
• I shared my screen as we went through the excel sheet, to be transparent and visual
• We spent ~45 minutes going through the entire assessment (keep in mind, this was the first time we did this)
  • We counted down 3-2-1 before giving our score using our hands
• We posted individual scores on the webcam using our hands; fist = 0 through five fingers = 5
• I quickly average all the scores and marked them on the excel sheet
  • I then asked for any comments, especially at the extremes of scoring
  • I tried time boxing discussion 2-5 minutes so we could keep moving

Our Learning Lessons/Feedback

• Some questions were not applicable because we didn’t complete that SAFe event yet or haven’t completed the PI yet
  • Example: “Team reliably meets 80-100% of committed PI Objectives’ business value” – we only completed 2 iterations so we couldn’t answer this question
• Some questions seem more like a true/false answer or simplifying the scoring may be needed in the future
  • Example: “Team participates in System Demo every two weeks, illustrating real progress towards objectives” & “CI, build and test automation infrastructure is improving” could be true/false answers
  • A 0-5 scale is rather large for short questions in this format. It may make sense to modify the scoring scale to simplify the assessment. Maybe 1-3 like The Five Dysfunctions Of A Team assessment (1 = Rarely, 2 = Sometimes, 3 = Always)
• The discussion after the question is more valuable than the actual answers to the questions
  • One of my team members made this comment and it was insightful because everyone can interpret the questions a little differently. So discussing the questions after the answers helped everyone think about the question and how the team can improve

Overall, this assessment worked well after the first two iterations. It helped the team take a step back from the day-to-day and think about the bigger picture. Also, I think this tool is useful multiple times per PI, but you need to modify some of the questions. Lastly, I think the next time my team is in-town, following the other blog post about using posters and post-it notes to take the assessment is a great idea that I want to implement.

If you have any questions, suggestions or other experiences, please reach out and let me know!