Thread regarding Wells Fargo & Co. layoffs

Nothing ki-ls your talent as keeping tabs on them unnecessarily and locking daily time for sprints. You take a project manager that cannot code or if knows how to code should be developing code and task them with tracking updates, but the code is ready.

I left Wells Fargo after the Agile started to role in. The problem with the higher ups new and stablished is that they want to fix everything with one tool one approach etc…this is a huge benefit for other companies picking up the good talent Wells is running off thanks to mediocre management.

@6nqh+1ipSibc1 - The notion of a "master coordinator" who must be chosen to handle all the teams is, itself, a classic waterfall move. Even worse if you decide this before the project kicks off.
We've all been in those worthless kickoff meetings, where we waste 2-3 hours hearing high level sh-t that we don't care about. Then we spend 2 hours in a catchup every other week to watch some rube go through a spreadsheet of 60something teams, line by line, asking for status reports that no one else cares about. Meanwhile, no one on that call is getting any meaningful work done.
It's very rare that someone brings up anything they need help with, because, more than likely, they reached out to whoever they needed, when they needed it. There was no need for a magic "master coordinator..." They coordinated themselves. And if they were d-mb enough to wait for that meeting to discuss it (we've all been there, the dreaded "let's take this offline"), then how much time did they waste waiting? Exactly. Meanwhile, the rest of the teams just plodded along, meeting their goals independently, only being slowed down by these massive meetings.
In your scenario of 10 teams, it's highly unlikely that each team is interconnected with every other team. Rather, there's usually one team who interfaces with most of the rest, several pairs of teams who interact (maybe with chained pairings), and maybe a couple triples. None of those need to be present for the coordination among the others. You just do it on an ad-hoc basis. And as for who is the "coordinator," the SM whose team first discovers their dependency just reaches out to the other team. There's no magic ceremonies or anointing from on high needed. The best part? No one gets into a meeting where they aren't needed.
Now, there's nothing stopping higher ups from appointing a "champion" to oversee a high level initiative, just to keep tabs. That's perfectly acceptable, though probably jot necessary. That person is fine to track statuses. But there's no need for widespread testing coordination in well-arxhitected projects, as the interfacing teams just do it together when the time comes. You don't need some PM to tell two groups to test with each other, as they can figure it out themselves.
In the rare case where there is significant interplay among several teams, Agile still has you covered. You can do what's called a "Scrum of Scrums," where the individual SMs make their own Agile team, which then handles higher level planning and coordination. But, you would break into this super Scrum only when needed, instead of starting the project assuming you need this extra overhead.

@6ioh - I'm with you, but there are still gaps in your description of Agile. Let's assume a team's scrum master is responsible for coordinating their team's dependencies. Which Agile role does the overall coordination and reporting?

Example: 10 app teams with system changes that span multiple releases. Say, eight of those apps are supported by scrum teams and two are waterfall. Do the eight scrum masters draw straws to determine who will run the overall project? Which Agile role is responsible for scheduling the cross-channel design sessions? Which Agile role is responsible for end-to-end test coordination across multiple apps? What kind of Jira record provides an overall status that shows whether the effort is on track?

At WF, we're making it work by using waterfall roles like project managers and test coordinators to supplement Agile. And, they're managing the overall project outside of Jira.

@5zmn+1ipSibc1 - you are literally describing part of the job of a Scrum Master. Their entire purpose is to take the need for inter-team communication away from the other team members. But at Wells, we just have them check boxes on release instruction forms and run a "standup" each day. An actual SM looks at external dependencies and goes to those teams to coordinate work in such a way that it unblocks both teams.
The role of story grooming, which we don't do, is among other things to illuminate cross-team dependencies, which the SM then handles. But we don't actually groom stories, our stories aren't even done right, and our SMs are glorified release paperwork pushers. Again, none of that is Agile.

@5cle - What process/procedure within Agile coordinates that work across multiple scrum teams? Aside from quarterly PI planning, what is the Agile ceremony for discussing cross-channel topics? Who is responsible for coordinating that work across scrum teams?

The answer at WF has been that we rely on waterfall processes and non-Agile roles to manage more complex efforts. There are no project managers in Agile, but that's who is doing that coordination work today on Agile efforts.

@3yzn+1ipSibc1 - It works well for far more than simple changes, or one-team changes. If your code is architected reasonably, it's not hard to manage cross team dependencies, especially within Agile, where one team can actually change things ahead of time, seed the code, and flip a switch when ready. Or, you can try to synchronize 17 teams with wildly different release schedules and policies in our clusterfuck of a "devops" solution into one "big bang" release and then be shocked when it hits the fan.
Of course, if you're hard-coding sh-t in your apps across the enterprise (which we do), or making otherwise generally boneheaded architectural mistakes (which we do), then no development lifecycle process is going to work.

Clearly, "Agile" doesn't mean what management thinks it means...

@2esi - What you're describing probably works for simple changes that are limited to one team. (Those simple minor maintenance tasks were never an issue.) Agile breaks down when the effort has changes across many different applications (scrum teams) and impacting multiple stakeholders. That's when you need tried-and-true waterfall processes to manage the complex dependencies.

For another example of the sheer a--hattery that is WF Agile, look at all of the top-down, one-size-fits-none tomfoolery we have to deal with, which is the absolute opposite of normal Agile.
Teams are supposed to be empowers to work the way that makes sense for the given project, maybe with some basic guardrails in place. Instead, we've got all of this bureaucracy adding cr-p into our sprints that have no business value, and mandating the most minute parts of team workflows, even when it makes no sense.
Case in point. My team is trying to sunset a legacy application by moving its functionality into a modern application. But we have to migrate to newer logging platforms, do all these tech debt improvements, upgrade our ui components. For an app we want to retire. Oh, and now we have to add tons of unit tests or our builds won't succeed, in an application that was designed and written without unit testing in mind. And since our build won't succeed, we can't clear tech debt and SHRPs. Which then rewrites us to take ALL of our devs off the main project to replace this app to write unit tests just to get a build to pass their scans. Guess what's not getting done now? The work in the other application that will allow us to retire the legacy app.
In true Agile? The PO would say "fu-k that, it's a waste of time," and you'd turn off the scans that break the build, and you only do critical patches to the system and its external libraries. No one would question it, even if it "breaks company policy" because it just makes sense for an app you want to get rid of. And you'd have it retired in 6months. Instead, we're on year 2 of this now.

BRDs? Traceability matrices? I've been doing this for over 15 years, and I have never seen them legitimately used, except to blame someone a year down the line. Youre going to spend a month, maybe two, designing a document that is wrong, that mo one will use, and that will be out of date two weeks before it is approved. And then, you're two months down the road with no actual work done. Way to go!
The only reason you need those things is for someone to come along at the end if a six month project and say "that's not what I asked for" or "yes, that's what you asked for." Guess what, if the business is actually involved on a weekly or biweekly basis, there's no way that can happen, because they'll catch the fact that the system isn't doing what they need within a week. And it gets fixed before you build 17 other modules on top of it. That's actual Agile.
Traceability? That's acceptance criteria. Oh wait, you don't have those? Well, start doing them. That's actual Agile.
You don't know why something works the way it does? Then why was it coded? Why is it not in the JIRA that's tied to that line of code? Oh, you just made a "God JIRA" that said "build a ticket." That's not actual Agile.
Oh, you don't have sysyem access or test data and that messed up your sprint? Then why did you take the JIRA into your sprint when it wasn't ready? Why isn't your SM getting that access and test data so you can move the JIRA to ready? Oh, right, because your not actually Agile.
All of these things that you think you need, you actually don't, if you actually practice Agile. It's like a load-bearing wall... You can take it out just fine, but only if you replace it with a steel beam. At WF, we just took out the wall but never put in the beam, so now the house is falling down.
But thank God we do an "Agile Maturity Assessment" every 6months, where nobody knows what the terms mean, but we give ourselves a 4 out of 5 anyway. You know how many times I've done such an assessment at other Agile shops? Zero. Because they actually practice Agile. And have retros, where you regularly figure out what you need to fix on a per team basis... and then fu----g fix it.

The waterfall environment worked somewhat better at WF BUT almost all large projects failed to either deliver on time, on budget or on purpose and most of the time on none of those goals. Iterative development linked to iterative business goals would. Break down the beast into incremental value added pieces along the way. Nobody wanted anything but the whole enchilada at once. The Funding project process drove this with only the BHAGs getting funded so everyone created BHAGs. Rewrite the deposit system became the goal instead of build a new account interface, rewrite the posting module, change the GL interface, etc.

Ugh. I am in a non-tech group and we would like to attempt to use JIRA for managing all of our work efforts. NO assistance can be found, requests for an Agile Coach go unanswered. Super frustrating.

Agile is failing in my area because we do not have dedicated, trained scrum masters and Kanban leads. These folks are doing double duty as developers so the whole agile process gets shorted. Also no product owners from business so tech does user stories which are incomplete. No budget for doing it right with dedicated roles, so at the end of the day we're just "faking agile" while our leaders say we're fully agile. Oh, and every coach has only lasted a few months. Welcome aboard the agile shitshow.

So many good comments in here. I’m a QA which they are trying to turn into a QE. So we can learn to write automation code for regression scripts. Training is poor and working 55 hr weeks leaves no time to learn. They say we are agile, but here’s the many reasons we aren’t. QA must take on the work each monthly release per the business even when it’s above our bandwidth. Our applications are integrated with many others. Getting them all in sync is complicated and if any app is down, it impacts everyone. User Stories don’t contain much info, miss the BRD’s. This causes many questions and production issues that sometimes need emergency fixes. We have turned into admins, tracking and updating so many JIRA boards which is time consuming. Too much red tape to work around. Getting needed access is hard and time consuming. Staff is getting burned out and leaving and not being replaced. (Many with years of experience). Just my thoughts and experiences. Thx

Let me contribute to the list of lists...

1. WF Agile is way too rigid. Everything must be done just so or you fail QA.
2. The sprint concept is arbitrary and ridiculous. My teams burn way too much time on admin work, trying to make everything fit into sprints.
3. Story points are useless. Our stakeholders want to know how much it will cost and when it will be ready. They don't give a c--p about story points.
4. Way too many meetings. You don't need to meet every two weeks for a retrospective. Zero value add.
5. Everything is a fire drill. You don't have the right system access or necessary test data at the start of the sprint? Oh, f--k! We need it now! Now! Now!

@akm. That’s because they stupidly got rid of the people who used to do these things and put it onto developers who never did.

They implemented Agile but add tons of red tape along with it. The net efficiency gain was zero. Developers spend way more time on writing QA scripts and automation than developing.

I work on one of the largest web apps in the company. I was there from day one. When we went from waterfall to Agile they literally would not let us say "BRD" anymore. Without a BRD you have no traceability. JIRA is not a substitute for a BRD. Call them what you want, story/epic, but it's no replacement for complex scenario evaluation. Production has been a $hit$how with nobody knowing why something was implemented. You might get lucky and find the implementation JIRA but there will be minimal documentation. Furthermore you cannot expect every developer to automatically have a decades worth of knowledge on all parts of the system just because you say we are Agile now. It doesn't work that way. You cannot move one dev from one area and have them immediately pick up work and get going. Change one thing and it's a cascade.

And finally, agile is over 20 years old. It's not some new modern thing.

Surely someone has come up with a better way than what was dreamed up 20+years ago?

Or, maybe not...

It is a boondoggle. It is terrible everywhere outside if true technology organizations.

Agile only works for systems that are compartmentalized.

Too many systems here are so interconnected that you can’t change one without affecting several others. A big reason why waterfall worked for years with a lot less problems.

It is not a mindset so much as too many legacy systems, which is not necessarily a bad word if it works. That’s why you still see banks and insurance companies still using them even though they were supposed to go away for the last 20 years. Also these companies look at IT as an expense rather than the investment it truly is.

We are handcuffed in a sea of red tape.

Agile does not integrate well in this scenario.

I'll add:

1. Lack of true leadership support
2. No real role training making responsibilities different for the same role.
3. Total sc--w up rolling out Agile tools in impossible to navigate configurations.
4. Our systems are not like standalone apps on your phone. The integration and connections are huge. One dead team with a huge backlog can hold up everything.
5. Installing code turned off is not a change install.
6. "Product" definitions are all over the place. Opening an account is a product. Opening an account online for a mortgage on weekdays only is not. Specificity ki--s ingenuity.
7. Growing number of coders who can only code what they are told. Thank you offshoring.

Leadership implemented this bottom to top.

I could write a whole book on why Agile is failing at Wells.

Here’s the table of contents:

1. “Manager” isn’t a Scrum accountability
2. Kanban and the art of pushing work
3. The importance of “stable teams”
4. Don’t. Mix. Roles.
5. Transparency: How hidden agendas ruin agility
6. Individuals & Interactions > Processes & Tools
7. You can’t command and control your way into agility
8. Continuous non-delivery: The importance of getting change management right
9. Homer’s donut: “You’ve clearly taken items off the candy rack and tried to pass them off as sprinkles.” A department is not a product. A division is not a product
10. Focus, Respect, Openness, Courage, and Commitment and why you won’t find these values at the top, but you should still embody them anyway
11. Just say no. Controlling the size of your backlog
12. Continuous improvement

Apart daily stand up, does agile simply imply the removal of low level management layer?

Because I do see managers whose sole function is to manage, but he only has like 3 reports.... what does he do everyday?

Because what they are doing is not Agile. It's ScrumFall. They took waterfall, added the meetings of Agile, and pretended it's Agile.

Agile requires tremendous discipline when it comes to time and process. WF not good at time-boxing, meeting deliverables and/or executing with consistency.

It's not possible to be 'agile' when it takes 1-3 three weeks of toiling through the utterly broken and inconsequential release process to get any production change deployed.

It's also not possible to be agile when there is no time available to work on automated testing suites, which would save so much time down the road, and provide confidence that changes made to address the enormous amount of tech debt are permitted to be made.

Finally, no one really wants to be 'agile' here anyway.