PI Planning Readiness with Jennifer Claxton

ABOUT Jennifer Claxton:

Jennifer Claxton, an Agile Transformation Manager Principal, is a distinguished leader in IT, recognized for consistently delivering exceptional business value. With a strong background in IT leadership, she excels in problem-solving and detail-oriented execution, ensuring the achievement of set goals.

Jennifer’s dedication to fostering strong team relationships, rooted in quality, integrity, and a robust work ethic, is evident. Certified as a SAFe Agilist and Project Management Professional, she advocates for Agile methodologies and efficient project management to elevate customer value.

With a Bachelor’s degree from Texas A&M University, she merges academic excellence with practical expertise.

Jennifer’s entrepreneurial spirit extends beyond technology as a small business owner and as a Certified Advanced Neurotoxin Injector, showcasing her diverse skill set and interests.

Her strategic vision and passion for innovation position her as a transformative leader, bridging technology, business agility, and customer-centric solutions.

---

Overview

Introduction to PI Planning Best Practices and Continuous Improvement

In this video, viewers gain valuable insights into Program Increment (PI) Planning and how to leverage continuous improvement to enhance planning processes. The video aims to address common challenges in PI Planning, such as adapting to market changes and managing stakeholder interruptions. By watching, viewers will learn strategies for optimizing their PI Planning and improving execution within their teams.

Key Points Discussed: T-minus Planning and the PDCA Cycle

The video covers several essential aspects of effective PI Planning:

• T-minus Planning: It explains how T-minus planning can help address issues and improve planning outcomes by anticipating potential obstacles.
• Retrospectives and the PDCA Cycle: The video highlights the role of retrospectives in the Plan-Do-Check-Act (PDCA) cycle. It discusses how honest retrospectives can identify impediments and inform necessary adjustments to enhance execution.
• Collaboration and Strategy Alignment: The importance of continuous collaboration and aligning business strategies with IT infrastructure needs is emphasized. The discussion includes strategies for integrating software development and infrastructure planning to ensure cohesive execution.

Expert Insights: Aligning IT Infrastructure with Business Goals

Jen, a key speaker, provides expert insights into the challenges of aligning software and infrastructure teams. She stresses the importance of involving stakeholders with decision authority early in the planning process to address both business needs and IT requirements effectively. Jen highlights, “Continuous collaboration and strategic planning are crucial for aligning infrastructure updates with business goals,” emphasizing the need for proactive planning and cross-functional teamwork.

Practical Applications: Implementing Effective Planning Strategies

The information from the video has practical applications in real-world scenarios. Teams can use T-minus planning to anticipate obstacles and prepare contingency plans, improving their PI Planning processes. By adopting the PDCA cycle, teams can refine their approaches based on retrospective feedback, leading to more effective planning. Additionally, aligning software development with infrastructure updates can prevent conflicts and ensure smoother project execution.

Conclusion and Takeaways: Enhancing PI Planning and Execution

In summary, the video offers a detailed guide on improving PI Planning through effective planning practices, continuous improvement, and strategic stakeholder involvement. Key takeaways include the importance of early planning, actionable retrospectives, and aligning IT infrastructure with business strategies. Viewers are encouraged to implement these practices to optimize their PI Planning and achieve better outcomes. For further improvement, consider reviewing your current planning strategies and applying the insights shared in the video.

---

Transcription

Speaker 2
(0:07) All in the football team around. (0:13) So with that, please welcome my good friend, Jen Claxton.

Speaker 1
(0:20) Thank you so much, Steve. (0:22) Let me go ahead and share my screen and we’ll get started. (0:37) There we go.
(0:38) Hopefully everybody can see that. (0:39) Okay, great. (0:40) Great.
(0:41) Got the thumbs up there from Steve. (0:42) So we’re all good. (0:43) All right.
(0:45) So yes, as Steve mentioned, I was very drawn to Ken’s talk back in October for the Lunch and Learn on ways to salvage PI planning because what I was working on at the time was how to avoid having to salvage anything at all anyway by coming to PI planning with a really strong program backlog. (1:11) And so having what I call readiness of the program backlog. (1:16) And that’s what we’re going to be talking about today.
(1:20) A little bit about me. (1:22) As you heard from Steve, I wear many hats these days. (1:28) No longer with USAA, but still an avid agile coach.
(1:36) I still interact with a lot of people from USAA when they need advice or information. (1:45) While I was at USAA, I was an innovator. (1:48) I do have a patent with a group of people in claims.
(1:52) I’m a business owner. (1:54) And as Steve mentioned, I’m also PMP and SPC certified, as well as an enterprise business agility strategist. (2:01) And so lots of different types of experience that I have to draw from.
(2:09) So I’m super, super excited to talk to you guys today. (2:16) So one of the things that we ask ourselves all the time is what problem are we really trying to solve, right? (2:25) So this concept of program backlog readiness is something that I spent a little bit over a year implementing at my last employer.
(2:38) And today I want to share some of those lessons learned and other pitfalls to avoid before you even get to that PI planning event. (2:46) There is a very delicate balance between over planning and having not enough details to get started. (2:56) And so the basic concept here is to have this continuous planning effort that is collaborative between both business stakeholders and the technical stakeholders.
(3:13) It’s so important to have that collaborative bond. (3:16) So let’s get into it. (3:20) With a virtual show of hands, how many of you have witnessed a PI planning kickoff where the business context was vague, the product vision was vague, the architectural vision was vague, and Agile teams had no prior knowledge of what the work they were going to be having in the beginning as they go into their couple of days of planning.
(3:48) Sounds like a train wreck, doesn’t it? (3:51) And it was for a lot of our arts. (3:54) Agile teams were left to write spike stories and do extensive research on their features because they were left without a lot of details.
(4:04) System architects were unclear of their path that they needed for implementation. (4:09) So lots of risks get written up, dependencies are unknown, and teams found that they could only commit to about 50 to 60% of their capacity due to these risks and unknowns. (4:24) And before I move on, I’m going to pause just a minute there, Steve.
(4:27) There were a lot of hands up. (4:28) I just want to make sure that you’ve got the chat, you’ll interject if there’s something important or should I answer them on the go?

Speaker 2
(4:36) Nope, will do. (4:37) We’ll go ahead and monitor the chat and I’ll chime in if there’s a question that’s relevant. (4:41) Otherwise, we’ll clear the chat and the questions at the end.
(4:44) Thanks, Jen. (4:45) Awesome.

Speaker 1
(4:45) Okay. (4:48) And so what we found was a lot of arts didn’t even have any specific time set aside to refine their features, right? (4:57) So maybe depending on what they knew was coming up in PI planning, they would schedule one and they would briefly, you know, kind of go through the features, but not an in-depth refining session.
(5:10) On the flip side, we also found that some arts were spending a great deal of the Ipsprint or iteration six doing very detailed pre-planning so that when they did get to the event, it was really just a readout and a commitment and really defeated the purpose of really talking through those cross dependencies and having that cross-team collaboration. (5:44) We also found that sometimes this feature refinement of the program backlog really was more in a vacuum, right?(5:57) Product management, the PMs and the POs would get together and they would refine the features.
(6:02) But then once they felt that their features were ready, it was more of a pitch over the fence, right? (6:09) So here you go, kind of a la waterfall style. (6:12) And the product team says, here you go, go figure it out.
(6:17) So now maybe you’re thinking, what is she going to suggest to help this? (6:25) Well, what my team and I did was just to bring a little bit more rigor to that program planning process, however or whatever they were doing to get ready for PI planning. (6:43) So in the very beginning, we had to look at, we have to look at what’s needed, right?
(6:50) In order to get a very healthy program backlog, first you need to, well, I’ll assume that if you’re operating a portfolio save or full save, those epics that are coming in from the portfolio team are complete, right? (7:09) They’re healthy, they’re detailed and they’re ready to be decomposed into features. (7:15) Or perhaps you’re in essential safe, where the process for the work to enter into your program backlog is done in a different way, but it still needs to be clear and effective so that you have this list of features that you’re going to be refining.
(7:35) Secondly, it’s very critical, and I’ve mentioned this already, that you have that product management team or the PMs and the POs collaboratively with the technical stakeholders, the enterprise architect, the system architect or system engineer, and both of those teams need to have decision authority, right? (7:56) Those people that are coming in to refine those features need to have decision authority (8:00) so that as you’re refining and going through what’s really needed for that feature, if (8:05) a slight change to the architectural guardrails or a slight change to the color of the page (8:13) or something related to product, that the people who are there have the decision authority (8:17) to make those decisions on the fly, right?
(8:22) And then the last part that’s really needed is an understanding of that historical capacity or velocity that the ART has been operating in through the past several PIs, right? (8:41) And so those are the things that are needed, but if I dig in a little bit more, when you’re looking at the product management, those PMs and POs who need to be involved, one challenge that we found was that the product managers and the product owners fell into one of two categories, right?(9:03) We either had PMs and POs that were very well versed in their business, in their product, so they knew that product backwards and forwards, what it’s been and the vision of what is to come, but they had very little knowledge of how to operate in the role of a product manager or a product owner.
(9:27) On the flip side of that, we found that we had some PMs and POs that knew everything there was to know about their role and how to operate, whether it was at scale or in essential safe, they knew how to operate, but they had no idea about their business. (9:45) And so one of the two had to give, right? (9:48) We had to either teach the role or teach the product in our coaching there.
(9:55) Same thing with the technical stakeholders, right? (9:59) We heard or I heard a lot of times at conferences and other places that as companies were making this transition from waterfall into agile, it was really initiated by the technical stakeholders in the IT side of the house. (10:18) And so that could have meant that those technical stakeholders were still very aligned with the work that needed to be done and felt like they were the drivers of driving that work to be done instead of collaboratively coming together with the business and having a full understanding of that product from the business side, as well as the IT side.
(10:47) And again, this really needs to be a very good balance between both of those sides. (10:55) And lastly, Ken alluded to this in his talk as well back in October, that the capacity of an art should stay rather flat and well understood, right? (11:08) The changes that are imposed on agile release trains sometimes make this a challenge, you know, we’re removed from the art, but consistency comes with knowledge.
(11:23) And so if we look at the historical velocity that’s been between, let’s say, 1,000 story points and 1,200 story points total that had been delivered in previous PIs, it’s generally safe to assume that it will continue at that rate. (11:39) And a lot of times the RTE and that program team has the information to make that, you know, minor change here or there into what that capacity needs to be for the upcoming PI. (11:55) And that capacity then becomes your target for your planning.
(12:02) And I’ve mentioned safe a couple of times, and I mentioned in the beginning I’m also an SPC, but really are we aligning to safe in what I’m about to share with you, right? (12:16) Does this have a true alignment to safe? (12:20) And earlier this year, right, safe launched their 6.0 version, and they added additional or updated information around some of the planning concepts. (12:34) And they talk about this concept of being organizationally ready, content ready, and logistically ready, and what the inputs and outputs of the event are. (12:50) But they still didn’t call for what we’re asking for in this deep collaboration between product and IT. (13:02) It still very clearly says that product should define the features and IT should define the enablers.
(13:11) But we made the distinct, the distinction to enable collaboration across the table whereby both sides would be better informed and defining those features and enablers together as a team.(13:28) We ask that program teams add a little bit of rigor to their refinement process to include those needed individuals from both business and IT as they were refining the backlog together.(13:40) For example, now follow me here, you have an art whose value stream is aligned to the digital experience for financial advice, and their features are to enhance the system to allow for screen sharing between the company and a client in a video call.
(14:04) Okay, so what we would suggest is that the appropriate product or business personnel that knows the details of what’s needed for that experience. (14:19) And also the technical personnel who can really set the architectural guardrails and technical direction for that screen sharing piece. (14:31) And all of those things, those people should be included in the refinement session for those features so that you’re bringing both sides together.
(14:41) There is a chance, there’s an opportunity always for arts to have a product that’s a little bit more complex. (14:50) And if that’s the case, then the refinement sessions will probably vary widely in the participation of each one of those sessions as the core team, the core program team of the RTE, the product manager and the system architect work together with those needed people on each feature as it’s applicable to the business. (15:16) But this core program team still takes full accountability for the readiness of the items in the backlog.
(15:28) We know that the product manager owns the backlog, but what we were really trying to drive home was that the entire program team really should take accountability for the completeness and readiness of the items in the program backlog. (15:47) All right, so let’s assume for a minute that PI planning is coming up. (15:57) I’m sorry, PI planning has just wrapped up for your art.
(16:04) And we’re going to start looking forward to the next 12 or 13 weeks, however long your PI lasts, and that’s how long you have to identify the features and get them refined for that next upcoming PI planning. (16:23) Some arts and program teams may have a very well-established definition of ready or DOR, as we like to abbreviate. (16:34) And in that case, it should be reviewed with that program team to ensure that all critical business and technical needs of the feature are included in that definition of ready.
(16:46) And again, referencing back to Ken in his talk, really including the why is a critical part of the business need. (16:57) We also suggested that if there was not already a definition of ready that was in existence for that art, that before any refinement started, that agreement should be made around that definition of ready and what it needs to be for that art. (17:17) And furthermore, suggested working it into the arts working agreement and shared with the art so that everyone then can become familiar with this refinement process and what’s going into it.
(17:32) And it also provided the guardrails for refining and executing the work. (17:39) As I mentioned earlier, that planned capacity or planned velocity should be the target in total story points that you want to plan for, and maybe even just a little bit more, right? (17:53) We recommended refining it just enough features so that you have about 120% of your target, which would leave that little 20% extra in case that, you know, you get into the planning event and some things have changed.
(18:12) Maybe now some strategy suggests that prioritization should change a little bit, right?(18:19) So you have that buffer there to allow for just a bit more than what’s needed for a full plan to give opportunity for change along the way, right? (18:37) But it’s critical that we don’t run into this iteration rush, right?
(18:45) We don’t want to save those refinement sessions up for the very end of the PI. (18:52) We really want to have a scheduled plan to carefully refine all the features leading up to that PI planning. (19:02) And one of those ways that we’ve suggested and Steve and I have had great conversations about is this concept of a T minus calendar.
(19:12) And so if your PI planning event is, or I’m sorry, your PIs are 12 weeks long, then you divide those up by weeks and you assign different things to happen each week so that you’re building this scheduled plan leading up to your PI planning. (19:31) And then once again, everyone can be on the same page and understand the guardrails and the importance of having this complete program backlog going into planning. (19:46) And then right before planning, as part of that iteration six, one of the last things in the T minus calendar I would suggest is the program team who are accountable for the readiness coming together and just doing a quick check.
(20:02) Maybe that’s a review with the leadership. (20:06) Maybe that’s a review with the scrum masters. (20:09) Maybe it’s just a quick check within the program team to ensure everything matches that arts definition of ready.
(20:23) So then once you’re getting ready to go into that PI planning, we introduced this concept of continuous improvement, right? (20:35) So you want continuous collaboration up front. (20:39) But then you always want to have this concept of continuous improvement in mind as well.
(20:46) And as many of you know, back in the 50s, Dr. William Deming developed a concept or method to identify why some processes just don’t work. (20:57) And it’s the PCDA, or Plan, Do, Check, Act. (21:04) And people also know it as the Deming cycle or the Deming wheel.
(21:09) And up to this point today, we’ve talked a lot about the importance of planning or the P, the plan, which includes getting through PI planning and into the execution of the plan. (21:25) And so now, if you fast forward, the Do or the D is really the execution of the PI, all those features that were clearly refined and then planned during PI planning, they get executed during the D, during those 12 weeks of the program increment. (21:49) And then what we recommended was that the Agile team that actually executed the feature would then give a fist of five or a confidence vote on that feature.
(22:10) And so as they were executing this feature and they had decomposed it into stories already during planning, if there were issues along the way that caused a waste of time or a waste of resources, then that feature may actually receive a lower vote of confidence of a one or a two.(22:32) And if there were no issues, right, and it was smooth sailing from the first story to the last and that feature was finished, then we would suggest that confidence vote was a little bit higher, right, a four or a five. (22:47) And that then becomes the C or the check in the dimming cycle.
(22:55) Furthermore, we recommended that any features that really received a low score, right, a one, a two, or maybe even a three, that the Agile team then would provide feedback to the program team on what went wrong, right? (23:11) Maybe it was a dependency that was missed that caused a two-week hold on that feature because they had to go and get some alignment with another business partner. (23:23) Or maybe there was a risk that wasn’t uncovered by the program team, right?
(23:28) So this feedback then is shared back to the program team. (23:33) And then the correction, if you will, or the inclusion of those items that were missed then becomes the A. (23:43) That’s the act.
(23:45) And the program team incorporating those changes as part of their continuous improvement process. (23:55) And then that makes up the entire PCDA cycle as a loop. (24:04) And now kind of as a side note here, my team did receive feedback from some arts who felt that this critical check could be done in two different places, right?
(24:19) So it could be done at the end of PI planning as they’re giving their own team plan, their confidence vote, or it could be done at the end as we originally suggested it after all the execution had been done. (24:37) But then when we were considering this, we realized they were really right.(24:45) It can be done at either place, but it really comes down to what problem are you trying to solve with this continuous improvement, right?
(24:52) Are you just trying to make the planning piece better by having a very clear and detailed refined feature? (25:04) Or are you trying to make the execution better whereby these carefully fully defined features make for a smoother, more risk-free execution of those features? (25:23) And so really, you know, stepping back and looking at it as an outsider, it really could be done at either way depending on which problem that you’re trying to solve.
(25:36) So what kind of results did we have here, right? (25:41) And we had in the beginning, we had several different types of arts, right? (25:49) We really kind of had mixed results in the beginning.
(25:52) So the arts that we felt or they felt they had very well-established definition of ready.(26:00) They already had a very rigorous process in their refinement sessions and well-timed out and whatnot. (26:11) They were able to pick up this very little additional rigor and insights and just run and they saw results immediately.
(26:20) Results in a smoother execution, results in less churn, less wasted time in using spike stories and whatnot. (26:32) But on the flip side, in the very beginning, those arts that didn’t have a really good refinement process, they had to start from scratch with a new definition of ready, etc., right? (26:47) They really struggled in the first and second PIs that they worked through this as they were trying to add this rigor, build a strong DOR and build a strong rigorous process.
(27:00) They did, though, after they went through it once or maybe twice, then they were really starting to see improvements over time as well. (27:12) And in order to help support them, of course, you can’t have a process without reporting where I come from. (27:20) And so we developed a couple of reports to really help guide the program team along the way to see their progress and how they were moving through this T-minus calendar, if they were behind, if they were ahead, and keeping them really on track.
(27:42) So we used that planned capacity or target that I talked about along with a buildup of features to show the progress or lack thereof. (27:55) And then we also developed a report that was specific for leaders to be able to see kind of at a glance, right, how ready an art or even a portfolio of art, how ready they were for their upcoming PI planning based on today’s date. (28:14) So I have a couple of fake examples, screenshots of examples of what we did.
(28:22) And so this first one here was the PI readiness report. (28:25) This one was really used for the program team to understand where they were in this T-minus calendar. (28:34) You’ll see here, this orange line here represents their target or what their planned velocity is for that upcoming PI.
(28:43) And in this case, it’s 1,000 story points. (28:47) And so if you see over time, I’d like to think about this as a bucket under the corner of my roof, right? (28:58) And water drops are just dropping into, especially today because it’s raining here where I’m at, the water is just dripping into this bucket and filling it up over time today.
(29:10) Same kind of concept, right? (29:11) As those features are being refined, the story points that represent those features are being dropped into this bucket. (29:21) And as we are progressing through the T-minus calendar, they’re drop, drop, drop, the features are building up to that target or the planned velocity, planned capacity of the team.
(29:35) And then this at-a-glance, it really takes into account two very important dates. (29:45) What today’s date is, and that’s what is represented here with the orange line. (29:52) And then knowing ahead of time what the PI planning date is for each one of these ARTS.
(30:00) And these are four ARTS that are all in a single portfolio. (30:05) If there was just one ART in a portfolio or one ART standalone, it would just be a single bar chart across. (30:14) But you can see these percentages across the bottom here.
(30:19) The today’s line represents here, it looks like about 37% is where these ARTS should be in a readiness perspective compared to where they need to be for their PI planning event. (30:35) And so you can see ART number two right here, they have way more than they need. (30:40) They’re hitting 45% of their total capacity.
(30:44) And their PI planning is still kind of far out there, right? (30:48) ART one is in pretty good shape, right? (30:51) They’re only at 35%, they need to be at 37.
(30:54) So they’re probably progressing at a pretty good rate. (30:58) And so on and so forth.(31:00) And so this really gave our leaders an opportunity to see how well their portfolios, their ARTS were adapting these new processes, this new rigor that we were implementing there.
(31:16) And then the PI readiness again, really giving those program teams a visual of where they are and where they need to be. (31:26) I know without even looking, Steve, that there are going to be questions about story points. (31:33) And why do you use story points and reasons not to use story points.
(31:38) But what we found in the tooling that we used with, we used Rally and we used JIRA.(31:45) And there were already fields on our feature item type that one was the preliminary estimate, one was a refined estimate. (32:00) And so as those features were being refined, initially, they would have this preliminary estimate, small, medium, large.
(32:09) And then we would, in the visual, in the drop down, you would see small, medium, large, but in parentheses, you would see a suggested story point equivalent. (32:21) So if you were going to say the feature was a small, it would have an S and it might say 10 in parentheses, right? (32:28) So that’s the preliminary estimate field that we pulled into reporting.
(32:34) And then as that feature continued to be refined, if the, and hopefully they did, the refinement team, this program team felt like they had a refined estimate, then they would put the actual point value in there. (32:51) And so remember, again, we’re talking about the program team with that cross collaborative business and IT stakeholders coming together to help refine that.(33:02) And so therefore they would have the ability to give a refined estimate.
(33:08) And this really helped not only to drive our reporting, but it helped to really start that program team to learn from one another and learn from the plan, do check act process, this continuous improvement process, and always taking that back and continuing to get better at refinement. (33:37) So really one of the places when I’m talking about results, one of the places that we really saw a lot of improvement was this process of estimating and the preliminary estimate moving into the refined estimate becoming better or more accurate, if you will, moving forward. (34:02) So we thought that was a great place.
(34:11) And now I want to thank you all and ask what questions you might have.

Speaker 2
(34:20) Perfect. (34:22) And thank you, Jen. (34:23) This has been great.
(34:25) Typically, yes, we have lots of questions at this point to tee up from the chat. (34:29) I have an unfair advantage because you and I were working together in this context. (34:35) And so I was able just to answer the questions based on what we did together.
(34:40) But I don’t want to kill anybody’s opportunity to ask a question maybe that they didn’t put in the chat. (34:46) So go ahead. (34:47) If you’ve got a question, raise your hand and we’ll get those answered.
(34:57) Any additional thoughts that you didn’t see popping up in the chat? (35:05) All right, Mr. Perry.

Speaker 4
(35:08) Forgive me if I didn’t catch this, but how do you balance the need? (35:12) I get the need for rigor, love that, and in some contexts, that’s what it’s all about. (35:18) But in other contexts, there’s a need for innovation or a need to explore a bit.
(35:27) How do you balance that? (35:28) Because that’s a very different approach. (35:31) Trying to nail down all the requirements and such actually works kind of counter to what you’re trying to do there.
(35:37) So can you give me a feeling for how you manage that balance?

Speaker 1
(35:43) Oh, great question, Tom. (35:49) Features that are born out of innovation are always going to be a little bit more unclear. (35:55) They’re going to have a little bit more risk.
(35:57) They’re going to have more unknown unknowns as opposed to known unknowns, right?(36:05) So they have to be treated a little bit differently. (36:08) I would say that as we’re inviting the business stakeholders and the technical stakeholders to the table, that we would want to have people who are knowledgeable.
(36:20) Maybe the innovation includes a new technology or maybe it’s an updated business process. (36:29) You would just really want to have those stakeholders, the knowledgeable stakeholders, involved in helping to refine that.

Speaker 2
(36:40) And we had a similar question in the chat earlier about does that prep, the T-minus cadence and rigor, cause people maybe to hesitate changing the plan in PI planning? (37:01) And my response back was that, at least not in my experience, as long as we message it properly, that there is no plan. (37:08) Even coming out of PI planning, there really isn’t a plan, right?
(37:10) There’s a commitment to sprint one, iteration one. (37:14) But yeah, as long as we’re clear that whatever we come in with, we can throw all of this out if need be, and we’re working through it as a group. (37:23) So…

Speaker 1
(37:23) Absolutely. (37:25) Yes, absolutely. (37:26) And I mentioned having this target and actually refining up to 120% of that target in areas where either the product or the business process was more complex or was used to change, often change, right?
(37:49) Maybe it was from innovation. (37:50) Maybe it was from the market change or a strategy change. (37:56) Then we actually would go up to 150%.
(38:00) Now, that is, though, going to require some balance, right? (38:06) Between over planning and having just the right amount. (38:12) And so, having something in the backlog that would help to make that transition easier.

Speaker 2
(38:24) Oh, to wobble apart. (38:24) If there was a change. (38:25) Yeah, I gotcha.

Speaker 1
(38:26) But also, right, and I mentioned this too at the beginning, is that those business and technology stakeholders that are at the table really have to have the authority to make those changes, right? (38:43) Because sometimes what I’ve seen is you get down to the planning part and something changes, but nobody really has the authority to say, okay, yes, make that change.(38:55) And so, we go into the PI knowing there’s a change coming, but we didn’t have an opportunity to plan it because the people that we had didn’t have the authority to say, yeah, change it.
(39:07) And so, that is another balancing act.

Speaker 2
(39:11) Love it. (39:12) Thank you. (39:13) Alan, what do you got?

Speaker 3
(39:17) Yeah, so over and over again in my career as a coach and in organizations, often there is a problem in the flow of work. (39:29) I’ll just say that because it can be broad and big or whatever, but there’s a problem in the flow of work and the go-to reaction is let’s plan more. (39:40) And so, that means let’s start planning sooner and let’s start doing it.
(39:43) And so, I’m not trying to say all these ideas that Jennifer has elucidated here are wrong or bad. (39:50) It depends on the circumstances and so on. (39:52) But to me, this feels like things I’ve seen before where somebody says, well, we should start planning the next PI and sprint one of the current PI as a way to fix problems like market changes or stakeholders are interrupting the teams all the time, but that’s not being recorded.
(40:12) Or there could be all kinds of root causes as to why the plan didn’t work out well and just simply saying, well, we should plan sooner, earlier, and more is not addressing the root causes.(40:25) So, I’m interested in how we can determine that this T-minus plan or whatever, that this solution is the solution for our circumstance. (40:40) Are there ways to decide that, hey, this might be a good idea, but for us, the problem really is something else?

Speaker 1
(40:48) Again, great question, Alan. (40:49) And I will actually refer you back to the plan, do, check, act loop, right? (40:58) Because hopefully what’s happening is the art is participating in that retrospective at the end of the PI and really being honest and truthful on what those impediments were what the holdups were, where the wasted time might have been, et cetera.
(41:24) And a lot of people, a lot of arts do have these retrospectives, but then maybe they forget once they get into the execution of the next PI, they forget to say, hey, remember when we were having our retrospective, we talked about the business stakeholders are always interrupting our teams and going straight to the teams and saying, hey, I need you to change this. (41:48) So maybe we need to take some action to prevent that, right? (41:52) It’s the act part.
(41:54) You can go through plan, do, check, but unless you add that act on at the end to get those impediments busted and those things that are in the way pushed out of the way, that’s where the real goodness comes in. (42:10) And I think, and I have experienced where great retrospectives have happened, but the follow-through just was lacking.

Speaker 3
(42:19) Yeah, that’s always the, seems to be the pitfall and the consistent need of a retrospective to be valuable. (42:29) You have to have follow-through. (42:30) Yep, I agree.

Speaker 5
(42:31) Great question. (42:32) Thanks, Alan.

Speaker 3
(42:33) Daniel, what do you got?

Speaker 5
(42:36) Hey, thank you. (42:37) Thanks, Jen, for the presentation. (42:39) A couple of times I’ve seen a challenge where the software product team has plans that will affect infrastructure and the infrastructure teams have plans that will affect software, but nary the two shall meet.
(42:57) And I was wondering if in your process you encountered that and what you did about it.(43:02) You want to talk about modernization, Jen?

Speaker 1
(43:05) Yeah, exactly. (43:08) That was happening across the board when we were trying to, actually, when we rolled this out within PNC, the PNC insurance space and the accompanying IT space, that was every day. (43:27) And that’s one of the reasons why we really, really hounded, and I’ve said it a couple of times, the continuous collaboration along with the continuous improvement, but the importance of having those stakeholders at the table that are not only well-informed, but as I’ve already mentioned, have the decision authority to make changes, and you have to develop a plan together.
(43:54) And a lot of that starts before you even get to the program backlog. (43:58) It starts with the strategy and how you’re going to marry those two needs together. (44:04) We have certain things we need to meet from the business, but from an IT perspective, we’ve got infrastructure that is going to be out of service, so we need to update that software in order to allow the business strategy to be met.
(44:26) It’s a delicate balance, but I think that really has to start ahead of the program backlog in the portfolio or in the strategy conversations about how they’re going to weave those things together.

Speaker 2
(44:43) Yeah, that’s a great point. (44:44) And if you’re doing essential safe, just to add on to what Jen’s saying, it’s a little more tactical, but for all of us that have been SPCs for a while, we remember when Dean introduced those enabler epics, and how do we start to look at infrastructure well in advance strategically, as Jen’s talking about, because we didn’t have that concept in the early days of scaling. (45:08) So, yep.
(45:11) Anything else that’s top of mind right now? (45:21) All right. (45:21) Well, thank you, everyone.
(45:23) We appreciate you hanging out with us for the final get-together of 2023. (45:30) We wish everyone happy holidays, and we look forward to seeing you again in January.

Speaker 6
(45:38) Thank you.

Speaker 2
(45:40) Take care, everyone. (45:40) Appreciate it. (45:41) Thank you very much.