What’s your opinion on PI planning and sprints at Truist?
15 replies (most recent on top)
SAFe is how you do Agile, but find a way to employ all those people that haven't provided value in a long time. PMPs are SAFe at the bank.
My team was doing Agile at the bank before the COE and TDLC overhead was layer onto to us. We all were given Safe Agile training, and the bank even paid for my certification exams. Now we have new team members that aren't given any real training(in person, interactive, hands on) and the Learning portal required CBTs are laughingly bad. We are well established at doing PI planning that we could really condense into a day instead of two. Our release train is well coordinated and we pre-plan a lot to identify risks and dependencies. TDLC paper work and release management is the bane of our existence as we are not a core function, but they treat us with nearly the same level of risk and bureaucracy. The scheduling in the integrated test environments is painful. We had to hire IT PMs just to be able to get through all the SNOW requirements to get our monthly releases into production. Why am I taking SNOW courses for DAST/SAST scans to literally be tested on which screen to upload evidence? But I can't get my Agile BA SaFe training due to budget? I get it, there were a lot of sc--w ups at merger, but I bet they were waterfall teams or were due to timeliness that really couldn't be met, but we had to.
How many scrum masters and release train engineers are required to tell the worker bees what to do?
Get some AVPs in there. Those professionals can make it work. Sprinkle in an LDP Bro or two (but with less ra-e tendency) and an obligatory DEI hire.
Now we are going somewhere!!
So "Program Increment" is the newest moniker for tackling the latest Epic, or is it divided into a smaller piece? (Been out of the game for awhile).
This is right on the money. Pre-merger activities within agile programs were lead by certificate-holding, paint-by-numbers scrum masters with no real clue how to account for complex requirements or work with diverse skill sets. Planning was nothing more than throwing cr-p against the wall and then kicking work down another iteration or two when it couldn’t get done because no one could identify risks.
It was a dysfunctional system from the start and easily the d-mbest experience I’ve ever been a part of in my career. It hasn’t gotten better from what I’ve seen. I sit in on PI Planning occasionally and it’s still a bunch of in-fighting and arguing.
@1ccu+1r7Cf8BF - * Newsflash *. Welcome to working for a bank! Every bank has its own flavor of TDLC and PML due to the regulatory nature of working for a financial institution.
@2wqt+1r7Cf8BF - PI stands for “Program Increment”. It’s a scaled agile paradigm.
What does PI stand for?
We are in no way shape or form agile other than planning in sprints. TDLC makes us waterfall. We are not agile, we just plan on sprints and do tons of paper work. If we we're agile we would adapt to the needs and abilities of our teams and not be forced into a framework that goes against the whole purpose of agile.
PI Planning and Sprints are fundamental parts of SAFe (Scaled Agile Framework). Sprints are also a fundamental part of Scrum (or colloquially, Agile). In our organization we try to make the most of PI Planning and Sprints. More autonomy needs to be given to the Product Owner to accept or mark features ready as long as the features meet the definition of ready. Far too often I’ve seen where Product Owners accept features in PI Planning that are not ready, and it makes their life a living he-l along with the delivery team and EXD team members.
As long as features are ready ahead of the PI planning event, then PI Planning should be a productive ceremony. It’s up to the Product Owner to facilitate effective Sprint Planning ceremonies by setting Sprint Goals with the development team and Scrum Master. As long as the Sprint Planning goes well and dependencies are resolved, the Sprint should go well.
My impression of the entire PI planning process was that the real purpose was to wear down the developers so that they would commit to whatever the PMs wanted to hear, just to get the hellish meeting over with.
I can never hear a thing the guys in Chennai are saying. And it hasn’t ever mattered..
@ iid+1r7Cf8BF what division is that were it worked spectacularly?
If business has right resources to support product management these PI planning helps a lot to reduce chaos. In our division, I have seen spectacular improvement in delivery with PI . Saw mess in PI planning in another division.
They are a waste of time and resources. Spend more time on them than getting any real work done.