Gotta love being "Agile"

You know what’s really kak? SAFe AKA corporate “agile”

The number item on the agile manifesto is “Individuals and interactions over processes and tools”. Yeah right…..

The only saving grace is that I do really get to set our own deadlines/deliverables, work on interesting projects, in tiny teams, and get paid a but load - ok that doesn’t sound bad at all :p
 
Im sitting in a standup now, listening to these idiotic PMs waffling on. We have raised that we have not yet received finalized requirements, what we received is a rough idea, missing all the meat. "Someone" commited to a March release. We informed them to go and tell whomever that it is not going to happen. No way we can dev and get all of this tested in time. Do you think they are listening?

Hell no, we are told that we are agile, we must work with what we have and 'evolve' as we get more info. We cant go back on committed dates. Hell we didnt even commit to it.

When asking okey if we pull this in what do we drop? We can only work on so many story points at a time. Nope sorry, nothing can be dropped. everything is priority nr 1.

So now we will just have to wait post March release and then nicely inform whomever that nothing went in.

That pretty much sums up how managment prioritizes work in the software dev space.
 
You cannot mould a framework and still say you are doing that framework though. You have then created your own framework. Scrum as an example has very specific ceremonies, roles and responsibilities and when you break any of them there are consequences. If you replaced what you removed then you have your own framework that may or may not work for you.

This is not quite correct. Scrum is a light-weight framework, not a methodology where adaptation is a key part of it. If you're genuinely interested in getting a better understanding of just how adaptable it is, I'd recommend you read a few books from one of the founders of scrum - his words might carry a bit more weight than mine :)

Agile Software Development with Scrum
Agile Project Management with Scrum
The Enterprise and Scrum
Software in 30 Days
 
I have inputted this thread into google translate and come up with zilch.
WTF are you guys talking about?
:ROFL:
 
This is not quite correct. Scrum is a light-weight framework, not a methodology where adaptation is a key part of it. If you're genuinely interested in getting a better understanding of just how adaptable it is, I'd recommend you read a few books from one of the founders of scrum - his words might carry a bit more weight than mine :)

Agile Software Development with Scrum
Agile Project Management with Scrum
The Enterprise and Scrum
Software in 30 Days

I didn't call it a methodology I called it a framework. And the best place to find the answer is in the Scrum guide which says the framework is immutable. Your post said "balance between adhering" and "moulding the methodology" that is not adaption.


End Note​

Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
 
You cannot mould a framework and still say you are doing that framework though. You have then created your own framework. Scrum as an example has very specific ceremonies, roles and responsibilities and when you break any of them there are consequences. If you replaced what you removed then you have your own framework that may or may not work for you.

This is why there is so many frameworks already. There is no 1 size fits all, you have to adapt it. I tell my teams to focus on 4 points - collaborate, deliver, reflect, improve. If they are having meetings and it promotes progress in one of these areas, then we are moving to be more agile. If it doesn't, they should drop the meeting and let me know. Fsck titles, fsck ceremonies, fsck management by governance.

Yeah, some would go into my teams and not know what "framework" they follow - but the team members are happy, productive and the team delivers. Screw the purists. They make life hell when trying to shoehorn a framework/methodology/dream/unicorn into a space that 9 times out of 10 is not ready for it. Nah.
 
This is why there is so many frameworks already. There is no 1 size fits all, you have to adapt it. I tell my teams to focus on 4 points - collaborate, deliver, reflect, improve. If they are having meetings and it promotes progress in one of these areas, then we are moving to be more agile. If it doesn't, they should drop the meeting and let me know. Fsck titles, fsck ceremonies, fsck management by governance.

Yeah, some would go into my teams and not know what "framework" they follow - but the team members are happy, productive and the team delivers. Screw the purists. They make life hell when trying to shoehorn a framework/methodology/dream/unicorn into a space that 9 times out of 10 is not ready for it. Nah.

There is nothing wrong with that but there is a difference between being agile n terms of the methodology and implementing a framework like Scrum. If your organization is really good at practicing the Agile values it can usually operate pretty well without a formal framework.

The issue I have is when people claim to run Scrum but they have "adapted" it to their organization. What that usually means they dont apply the most important components and then you have threads like these where people say Agile, Scrum and other methodologies and frameworks dont work. Often its because there is an imbalance like PO's acting like PM's and dictating timelines and sprint items etc and someone else on the team has to deal with the consequences of that. There are not many organisations who are mature enought to work outside of the framework and it not having a significant impact somewhere in the business.
 
I didn't call it a methodology I called it a framework. And the best place to find the answer is in the Scrum guide which says the framework is immutable. Your post said "balance between adhering" and "moulding the methodology" that is not adaption.
Bud, you're truly nitpicking here for the sake of it. I didn't say that you alluded to it being a methodology. If you got that impression, I apologise. I reinforced that it is a lightweight framework and a framework allows for adaptation. If we are down to nitpicking my word choice, insert the word "adapt" where I said "mould" if you prefer? I'm sure you understand the premise, though, in that it's adaptable. I also, with good intention, provided a reading list which can show you how it is "adaptable" as per the founder of scrum himself - there is an opportunity here to open you up to new possibilities within the framework. I'm definitely not here to convince you on its adaptability, and if you choose to be a purist and you can implement it in your teams in the purest form then that is sincerely awesome! My experience over the last 10 years as an SM has taught be to be a bit more flexible, though, and that is how I allow my scrum teams to run.
 
this guy has some good talking points about agile that resonates with developers

 
Im sitting in a standup now, listening to these idiotic PMs waffling on. We have raised that we have not yet received finalized requirements, what we received is a rough idea, missing all the meat. "Someone" commited to a March release. We informed them to go and tell whomever that it is not going to happen. No way we can dev and get all of this tested in time. Do you think they are listening?

Hell no, we are told that we are agile, we must work with what we have and 'evolve' as we get more info. We cant go back on committed dates. Hell we didnt even commit to it.

When asking okey if we pull this in what do we drop? We can only work on so many story points at a time. Nope sorry, nothing can be dropped. everything is priority nr 1.

So now we will just have to wait post March release and then nicely inform whomever that nothing went in.

Its time I wrote an article on this and how to fix it.

I have heard countless versions of this story in software projects over the years , and its part of a bigger problem I call "the gap" (between expectations and reality, between perceived and actual complexity etc)
 
What is worst, is the fact that this is seen as a holy grail for any type of project management i.e. non IT.

People also think that it means having as much stuff on the go as possible, when really, the BEST strategy for high delivery is to have AS LITTLE WIP (work in progress) as possible
 
People also think that it means having as much stuff on the go as possible, when really, the BEST strategy for high delivery is to have AS LITTLE WIP (work in progress) as possible
Agreed. I also think team sizes should be no more than 3-4 strong developers. It negates basically all the need for process and that old adage of too many chefs spoil the broth applies 100% to software development
 
Agreed. I also think team sizes should be no more than 3-4 strong developers. It negates basically all the need for process and that old adage of too many chefs spoil the broth applies 100% to software development
team size is super important.

I keep hearing about projects that have 10's or even 100's of developers, I cannot wrap my head around it. Maybe what they call a project is not what I think of as a project.

I am a "contractor" to the blue insurer, and we basically also use "micro" teams (2-3 developers + a BA) per project, and it works well (we use these same size teams internally too, at my actual company)
 
Dont get me started on the story point BS. My story point != your story point. How TF do you calibrate a story point?
I use 1 story point = 1 est hour of work. Easy to know how many I can complete in a week and easy to est storypoints for a feature
 
fk I hate 'Agile' in a corporate company. Fkn dumb fkrs.

Just because someone says they use “Agile”, doesn’t mean it actually is the Agile development methodology. You are probably in some morons power trip and said moron is conning you all by making you believe you are following the Agile methodology
 
The PMs are in the Project standup, not our team's standup. They call it a standup, it is actually just a normal meeting pre-agile.

And the PMs are here because no one had the guts to fire them when they realize they are not needed. So they are being entertained while adding no value, much like most politicians.
No company is going to fire PM's. Because no company is going to have technical people interact with business and manage timelines. A proper and effective PM creates and manages that fine balance between what the business needs to make money (the bottom line basically) vs the technical staff's ability to deliver something that's not rubbish.
 
Top
Sign up to the MyBroadband newsletter
X