People get far more done if they spend less time labeling things and thinking there's a new canned technique that's better than what's been done before.
Dear Agile, I’m Tired of Pretending (2018)
351–360 of 420 posts
Re: Dear Agile, I’m Tired of Pretending (2018)
#352I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
I just screamed this at someone (over IM, not really screaming) that estimates in scrum are meant to measure complexity and not time to completion. There are still people in 2019 saying things like "1 point is 1 day of work" and I want to murder them. The whole point of scrum is that time estimation is futile.
Estimate complexity and then measure your velocity as tasks get completed and you can make a rough forecast of future velocity.
Re: Dear Agile, I’m Tired of Pretending (2018)
#353“I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it . . . Scrum is a very simple framework within which the “game” of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.”
This was Ken Schwaber, co-creator of Scrum. 10 years ago. Ten years after, things did not get a lot better for big corporations that were born with leaders used to waterfall.
I agree with almost everything in this article and I completely agree with what Tootie wrote above: "The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery."
As the article rightly noticed being Agile is not just building faster. It is delivering "value faster". That also means: "do not build what does not need to be built" and every 2 weeks be willing to scratch what you have worked on. Instead in most of the big companies the business people present shiny objects to the leadership and their goals is to build those shiny objects. Nobody wants to say: "We were wrong". The result is a few projects were people worked for 1 year and then the project is abandon. Even if the idea was good, nobody wants to work on little improvements.
It seems that Agile, Scrum, and most of classic agile lingo have a bad connotation for most of the people in these days. Some (over) simplifications that were made to make Agile easier to adopt ended up making things worse.
People in big corporations are used to the "flavor of the month" Most of the people really do not look for a revolutions there. They are just looking to how they can seem smart to impress their bosses and being promoted. That how Scrum got in. And that is why it will never realize its full potential there. They do not want to change how they think and how they do things.
I run a pretty successful team inside a bigger organization. I wanted to use story points. Start from scratch and have the team get a sense for what 1 point is. And my boss really wanted us to use story points. He only had one requirement we had to use this equation 1 story point = 1/2 day of work...
Trying to explain him that one of the reason you use story points in the first place is to stay away from time did not go anywhere. All the other teams were using that equation and we could not be the only team that was not to using it.
Frankly speaking, I think it is hard to work at the "inter-team" level if you cannot use the same unit. That's why in Agile you want truly autonomous teams. But big organization were not organized in that way. So you need to re-organize the company in a different way... but assuming there is the desire, who is going to drive that change? Who is going to take the risk of changing something that work in some way in a way that is not going to work too well for a few months?
In my humble opinion, it is almost impossible to change an existing a waterfall organization and make Agile work inside of it. Only a leader with a lot of trust by everybody in the company and a lot of courage may be able to make it work.
Most of the people that hate Scrum, Kanban or other flavor of Agile had experience with a "Cargo Cult" Agile preached in big companies and usually end up thinking that Agile is sooo screwed up. A big corporation will usually embrace embracing some things that usually really help (ex: standup meetings) and change a ton of other things that will make things worse.
You like the Agile mindset, you are going to be a lot more successful if you start from scratch with new young people or people that really want to commit to make things great.
For a new organization is easy to start with a simple "Agile template" and make sure that the team is really onboard with a continuous improvement mindset. Keeping regular retrospectives will make things evolve quickly in the right way.
Re: Dear Agile, I’m Tired of Pretending (2018)
#354I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smal…
>Even bad estimates are better than no estimates
Absolutely not! An estimate should not be a random number but should be constrained with available data however small it might be. If you feel that you don't have enough to form a "guesstimate" do not give me a number but first work on finding the data which will enable you to form a proper estimate.
Once you give an estimate, no matter how many times you explain that it is a "guesstimate" people tend to lock on to the given number. It then becomes a real battle trying to explain the hurdles (and there are always some unknowns) while revising the original estimate. Soon mutual distrust develops between the implementation engineers (stressful and detrimental to actual execution) and the management leading to everybody losing faith in estimates. Agile/Scrum have exacerbated the problem with their short time windows and sprints. In one team that i was on, people just gave up and started quoting 2 weeks for any and every feature, trivial or non-trivial and the whole exercise became meaningless.
PS: The book "How to Measure Anything: Finding the Value of Intangibles in Business" is worth reading to get some ideas on how one might do proper estimation.
Re: Dear Agile, I’m Tired of Pretending (2018)
#355*And while we’re at it, we’ve got to stop treating dev teams like they work in a factory."
Beautiful
Re: Dear Agile, I’m Tired of Pretending (2018)
#356I personally found that a good methodology: each team member has clear area of ownership/responsibility. John does X, Jane does Y, Ann tests X, Jeff tests Y. Everyone logs their own tasks. We define and work towards a sprint. No elaborate planning, no estimates. The peer pressure is enough to get everyone moving.
Managers often tell me that my process is chaotic. They want more visibility and deterministic completion dates. We adopt Agile process. Now we have long sprint meetings. I think we get less done.
Re: Dear Agile, I’m Tired of Pretending (2018)
#357Earlier quoted context omitted.
Oh come on. Any decent project manager understands the difference between an estimate and a deadline and plans and communicates accordingly. It's not rocket science. Stuff gets shipped on time all the time.
Any decent project manager who wants to keep their job will acquiesce to people further up in the org chart who want deadlines, not estimates, and who consider the difference between the two to be as fuzzy as it needs to be.
>who want deadlines, not estimates, and who consider the difference between the two to be as fuzzy as it needs to be.
This is exactly it. Well said!
Re: Dear Agile, I’m Tired of Pretending (2018)
#358I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
There are ways to get better at estimates. And a proper process will help you to do it. Unfortunately most of the orgs do not do it.
1) We know that "People are bad at estimates". That is why the estimate should come from the team (not one person in the team). Most of the orgs that I know do not do this. And to be honest they are not set up to do it because people in a team do not have overlapping skills. Ideally you have a team where people can take other people jobs (to a certain degree). You can then, during grooming, play "poker scrum" to estimate (where it is harder for people to cheat following what the lead person says). It is ok for somebody to say "I have no idea". The AVERAGE (not the MODE) is used for the estimation. If the items are more than 2 card apart have the 2 people at the extreme say why they think they think it takes the little amount of points and the other person why they think should take the large number of points.
2) If it is hard to agree on the estimation, the item probably needs to have a "spike" where more assessment or design is done in order to make clear what need to be done. In my team we also agree that a story has more than a certain number of points, we may say that it is too big and we have to break it down.
3) During retrospective or a specific meeting we have the team look at the time that an item really took and when it was more than 2 card off, try to understand what was under or over estimated.
Usually after about 5 cycles, people start developing a sense of what the right amount of story point should be for a story.
If you are always left by yourself at estimates and you never properly scope the task before and reflect on the variance afterward, it will be very hard to become good at estimations.
Re: Dear Agile, I’m Tired of Pretending (2018)
#359Earlier quoted context omitted.
No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smal…
> You must never turn estimates into a promise, Whoever asked you for that estimate will do that for you… > always remind people they are estimates. …even if you remind them. I mean, the reasonable ones won't, but many people aren't that reasonable. I've been in an interview last week where they told me the teams were strongly committed to the features they planned to do each sprint. Which I interpreted to mean that…
It’s funny because even with capital a Agile / Scrum, in 2011 the term commitment got changed to forecast [1]. But then many companies who are dogmatic about Agile still use estimates as commitments anyway. That makes technical debt really hard to avoid... One solution is to create technical debt tickets in the backlog so people become aware of it.
Re: Dear Agile, I’m Tired of Pretending (2018)
#360Earlier quoted context omitted.
I'm not a nuclear aircraft carrier refueller, so maybe the domain is different in a way I don't understand, but it's ridiculous to need a five year plan to just refuel something, people refuel cars in five minutes everyday. I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car. Thats about how your comment sounded.
+1 However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_. I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop? Planning meetings dont happen…
>i can _bound the problem_
This is the nub of the problem when it comes to software. I understand your skepticism but software development is really very different from other activities. It is "mind-stuff" (and thus quite unstructured) which needs to be expressed in very precise language to solve an [almost always ill-defined/constantly redefined] problem. The inherent complexity involved is huge due to the number of degrees of freedom and malleability involved.
I can do no better than point you to the article "The Humble Programmer" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...) written by one of the pioneers of Computer Science to really understand the issues that make Software Development such a complex and difficult activity. And since then (the article is from 70's) we have made matters exponentially worse by orders of magnitude.