As the author acknowledges most companies never fully embraced Scrum, as not all levels would buy into it, specially into what concerns managing expectations of what gets delivered and development costs mapping to actuall project budgets.
So in the end what reigns the corporate world outside startups, are mini-waterfall projects of three weeks.
I had some successes moving to kanban project management following github project kanbans. It took me 2 years but management is now starting to come on board. With kanban you can talk priorities (what goes in progress) and future (what goes in "next wave") and budget (how many people we keep on this kanban). The challenge is of course with timelines because while most business timelines are made up, no timelines makes it hard to run a team to ship stuff.
Nice to see it is working for you, on my case it is more adapting to whatever customer is using and leave after a couple of months when all deliverables are done, so there is not really the ability to fight 2 years on something.
Agile Manifesto: "Individuals and interactions over processes and tools"
Modern "Agile": "You need to put that into the Jira tool so that the process can be tracked"
And adding to the things that the author identifies: using process to Micromanage WFH teams, following plan over flexibility, experimentation and risk taking.
>Agile Manifesto: "Individuals and interactions over processes and tools"
>Modern "Agile": "You need to put that into the Jira tool so that the process can be tracked"
This was basically my daily battle with other members of the leadership team when I headed Engineering at a startup. Some teams liked to use Jira, others liked index cards on a wall, others worked off a shared Google doc. Sprint length varied, planning and retrospective meetings varied, etc.
I didn't particularly care as long as whatever method a team was using actually worked. Teams were accountable for establishing and meeting goals and I worked with PMs to ensure roadmaps generally lined up and dependencies made sense.
Yes, it created a little more work for me to get a snapshot view of everything and to coordinate the work, but the net results is the teams were happier and more productive because they were trusted to deliver results, had agency, and could do what worked best for them.
The Guardiola example is an unfortunate one as his play scheme lost effect not because it got corrupted, but because the other European teams adapted to it. Germany (mostly Bayern) vs Brazil in the Brazil worldcup was a great example on how the scheme was still effective against a unprepared team. Sadly for me, a Brazilian who was at the stadium.
Scrum, on the other hand, lose effectiveness when companies do not implement it correctly (Change the culture, empower the team, etc).
8 comments
[ 3.0 ms ] story [ 27.3 ms ] threadhttps://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
As the author acknowledges most companies never fully embraced Scrum, as not all levels would buy into it, specially into what concerns managing expectations of what gets delivered and development costs mapping to actuall project budgets.
So in the end what reigns the corporate world outside startups, are mini-waterfall projects of three weeks.
nope, what a shame, guess we'll have to put a FRAMEWORK™ in place so that our AGILE® PROCESS© justifies the existence of managers and so we can sell overpriced consultants for what should be an afternoon of reading.
Agile Manifesto: "Individuals and interactions over processes and tools"
Modern "Agile": "You need to put that into the Jira tool so that the process can be tracked"
And adding to the things that the author identifies: using process to Micromanage WFH teams, following plan over flexibility, experimentation and risk taking.
>Modern "Agile": "You need to put that into the Jira tool so that the process can be tracked"
This was basically my daily battle with other members of the leadership team when I headed Engineering at a startup. Some teams liked to use Jira, others liked index cards on a wall, others worked off a shared Google doc. Sprint length varied, planning and retrospective meetings varied, etc.
I didn't particularly care as long as whatever method a team was using actually worked. Teams were accountable for establishing and meeting goals and I worked with PMs to ensure roadmaps generally lined up and dependencies made sense.
Yes, it created a little more work for me to get a snapshot view of everything and to coordinate the work, but the net results is the teams were happier and more productive because they were trusted to deliver results, had agency, and could do what worked best for them.
However a minority of the believers cling to the belief ever more tightly, claiming that the real issue is a lack of faith.