The Death of Agile?(oreilly.com)
oreilly.com
The Death of Agile?
https://www.oreilly.com/radar/the-death-of-agile/?
11 comments
I think projects are dying because most projects are products in disguise and with products you need the entire team, not just a business analyst or pm, to be able to talk to the end users. Ask yourself why most projects end up with adoption issues even the the internal ones? Because it’s another instance of “if you build they will come”. The same reason you don’t build a full fledged product in a startup - you need lots of iteration and end user feedback to succeed. Agile and project management wants to skip the whole product phase because it assumes whoever is running the show knows what’s needed - it doesn’t usually work this way.
Agile needs to be married with OKRs for mid-long term strategy. This gives product development more "why" to complement the "what."
As a technical PM, I have taken a step back from agile in setting quarterly OKRs. It has allowed me to focus on the customer and market needs with great success.
However, as the team gets looser with agile I see deliverables slipping, overengineering, user-less features, and development becoming a black box creeping in again.
Agile on its own isn't enough. So if you want less, think again.
As a technical PM, I have taken a step back from agile in setting quarterly OKRs. It has allowed me to focus on the customer and market needs with great success.
However, as the team gets looser with agile I see deliverables slipping, overengineering, user-less features, and development becoming a black box creeping in again.
Agile on its own isn't enough. So if you want less, think again.
My first Agile project was in 2007. It was fun and collaborative. We were all reading books/articles and experimenting together. It’s never been like that again. It worked kind of as intended on one project where we all had to be in the same room all day. Everyone seemed to be excited for it to end, though.
In every one of these articles I see people complaining about agile but also admitting they aren't doing it. If you are having hour long dailys (instead of 15 minutes) and don't talk to your customers, then you aren't doing agile. It sounds like you love agile but just aren't doing it.
I once worked on an “Agile” team for a year and never met the Product Owner. All her wishes were passed to us through two analysts. I’m not sure how often they had contact with her, their boss actually drove the decision making. He would meet with her, summarize for the analysts, who would write the stories for us. Which would be communicated in daily 30 minute stand ups.
I've seen proposals that state the developers will have as little interaction with the users as possible. Needless to say those projects never went well.
I've worked at places where that was the norm.
The development group was actually Agile, mostly. But the first warning sign of siloing was shortly after I started there.
Even in the development group, we had a 'bugfix' team, a 'feature' team, and a 'Development Manager's Delusions of a Startup' team. The teams were discouraged from collaborating. This lead to such joys as one team having problems they spun their wheels months on, until eventually 'the deadline' was missed multiple times and said manager had to abandon what could only have been an experiment for a future blog post or conference talk. In every case someone from one or both of the other teams had the right skillset to fix the problem in a sprint or less (which they eventually did.)
Eventually this manager was ousted, as he had given a number of presentations to the higher ups but there was never any real movement towards the goal. Additionally, the Dev team had a lesser revolt over the lunacy of what we did.
So, we fixed that. Once the silos in our groups were gone we really were agile. We still had two teams, but they were free to collaborate and work with each other.
However...
The rest of the business still had a silo mentality. We could not just go interact with the users (other employees, typically in the same building/floor.)
As an extreme: We dealt with a lot of documents. and a special piece of print software for barcodes. However, if we wanted to test a document change, we had to:
1. Send the word doc through the PDF engine. The word doc had special headers defined on specific pages, in certain spots.
2. Print a copy and confirm the dimensions match what the print room said was required.
3. Send PDF to print room for testing.
4. Wait 0-21 days for the results.
5. Get the results from the printroom and pray. The software they use will randomly edit the PDF elements to move things around. If it doesn't work, sometimes just another linebreak will work. Other times, you have to play with margins. But, you do that, and then...
6. Go back to Step 1 till you're done.
Multiple times the developers requested 'Just let us use the print software so we can do our jobs, for goodness sakes!' But to no avail. The bureaucracy did not think that was something developers should be able to do.
If the entire organization isn't Aglie, there's going to be an impedance mismatch between the parts that are agile and the parts that are not.
The development group was actually Agile, mostly. But the first warning sign of siloing was shortly after I started there.
Even in the development group, we had a 'bugfix' team, a 'feature' team, and a 'Development Manager's Delusions of a Startup' team. The teams were discouraged from collaborating. This lead to such joys as one team having problems they spun their wheels months on, until eventually 'the deadline' was missed multiple times and said manager had to abandon what could only have been an experiment for a future blog post or conference talk. In every case someone from one or both of the other teams had the right skillset to fix the problem in a sprint or less (which they eventually did.)
Eventually this manager was ousted, as he had given a number of presentations to the higher ups but there was never any real movement towards the goal. Additionally, the Dev team had a lesser revolt over the lunacy of what we did.
So, we fixed that. Once the silos in our groups were gone we really were agile. We still had two teams, but they were free to collaborate and work with each other.
However...
The rest of the business still had a silo mentality. We could not just go interact with the users (other employees, typically in the same building/floor.)
As an extreme: We dealt with a lot of documents. and a special piece of print software for barcodes. However, if we wanted to test a document change, we had to:
1. Send the word doc through the PDF engine. The word doc had special headers defined on specific pages, in certain spots.
2. Print a copy and confirm the dimensions match what the print room said was required.
3. Send PDF to print room for testing.
4. Wait 0-21 days for the results.
5. Get the results from the printroom and pray. The software they use will randomly edit the PDF elements to move things around. If it doesn't work, sometimes just another linebreak will work. Other times, you have to play with margins. But, you do that, and then...
6. Go back to Step 1 till you're done.
Multiple times the developers requested 'Just let us use the print software so we can do our jobs, for goodness sakes!' But to no avail. The bureaucracy did not think that was something developers should be able to do.
If the entire organization isn't Aglie, there's going to be an impedance mismatch between the parts that are agile and the parts that are not.
[deleted]
Agile has long been a caricature of itself but a very profitable one. Tools like Rally and Jira will make most experienced developers long for the days of reasoned waterfall. SAFE, Jira and Rally add so much overhead that a methodology for efficiently navigating that bureaucracy will be its next "revolution".
In my experience hour-long standups are routine. Sprints are "timeboxed" deadlines. Customer interaction is as rare as finding hen's teeth.
Communication ends the first time anyone on the team realizes its blowback.
Agile delivery trains are usually runaways. The effect of daily standups has become the equivalent of Prisoner of War torture techniques; wake up! what have you done! what will you be doing! How many story points? How much time? on and on... every F'n day.
Agile dead?
No, its being refactored in the Gitmos of Silicon Valley.
I may be in the minority, but at my last job I had some pretty great project managers that had us using Jira in a way that was simple and helpful.
I think part of that was they had experience and political capital. So they chose to use only about 10% of the functionality, and allowed almost no one to augment their minimal workflow.
I think part of that was they had experience and political capital. So they chose to use only about 10% of the functionality, and allowed almost no one to augment their minimal workflow.
At the first 'Real IT' job I had we started off as Waterfall using Jira.
We eventually did transition to agile, and while it was painful, having an Agile coach on contract worked out GREAT. Their job was to teach us agile in 6 months and be out.
Once we had switched, our Jira workflow was simple. I think it was the same scenario you outline above though; they had enough experience with Jira in waterfall that they knew what to use and what not to use. Which for us was Epics/Stories/Tasks/Tickets/Bugs, Attaching things, linking together (i.e. being able to track that a story was assigned to a ticket submitted by a user/customer was great for communicating with the business about priorities.) But that was about it.
We eventually did transition to agile, and while it was painful, having an Agile coach on contract worked out GREAT. Their job was to teach us agile in 6 months and be out.
Once we had switched, our Jira workflow was simple. I think it was the same scenario you outline above though; they had enough experience with Jira in waterfall that they knew what to use and what not to use. Which for us was Epics/Stories/Tasks/Tickets/Bugs, Attaching things, linking together (i.e. being able to track that a story was assigned to a ticket submitted by a user/customer was great for communicating with the business about priorities.) But that was about it.