Fork me on GitHub
#off-topic
<
2016-12-20
>
dominicm11:12:45

That's very interesting.

fellshard18:12:35

(It's not far off from what the original agile was intended to be, it seems to be more a lashback off of the 'corporate Agile' mentality. See Jeffries' 'The Nature of Software Development.)

fellshard18:12:32

Estimation gets blamed a lot, but it's still a necessary evil insofar as a business does need them to decide whether value will be received in time or not.

fellshard18:12:57

The problem is turning around and using those estimates as strict timelines that developers must deliver to.

sveri18:12:36

@fellshard Exactly, that is what we do. We usually have to estimate story points and estimate the time for tasks. But this is solely for "planning" and our team lead knows that estimates are wrong all of the time. Still he wants it. And never, not once in 5 years, I heard that we were over time.

sveri18:12:57

Or were put under pressure to finish a task.

sveri18:12:29

One cannot blame agile / scrum for bad management.

fellshard18:12:26

Turning agile / scrum into a management methodology does tend to lead to bad management, though.

agile_geek18:12:51

Estimation is only a problem because most businesses can't make a definitive measurement of the value of the software change. If they could measure value in terms of profit/loss for each change and they provided an estimate of value of each change then the estimates become less problematic as you can make judgements like "ideally this feature give me x value at y cost but I can't wait so I'll take x-20% value for a subset of the feature at cost y-80%". Then even if the cost 'estimate' is off as long as the value estimate is close it's acceptable. Of course if you ask businesses to provide a value estimate they generally can't so proving the point about development providing a 'cost' estimate. The real problems tend to stem from project based thinking rather than platform/product based thinking. Projects are inherently finite and focus on time, resources (which together make cost) and features (scope). These are all easily measurable but without a 'value' estimate tweaking those 3 dimensions usually ends up in poor code quality the next project has to pay for in longer time lines and more expensive features.

fellshard18:12:31

So, how can we focus on better measuring value provided? At least on the tangible spectrum, if not on the intangible spectrum.

agile_geek18:12:21

I like the idea of the #noestimate movement but try doing it in a consultancy "Yes we will build you this software. No, I don't know what you will get, no, I don't know how long it will take and no I don't know what it will cost". Take it from ex-CTO of a s/w consultancy, you won't win clients this way!

fellshard18:12:37

I was wondering the other day if we shouldn't be ethically responsible for hardening every single piece of code we write before release, since the software we write may be arbitrarily extended in the future, whether we're there or not. Then it becomes a baseline for all our estimates. But that might also be rather extreme...

agile_geek18:12:58

Ask the business what does success look like and how can we measure it

fellshard18:12:03

Yep, but try getting the business to let you build in metrics, especially with their existing systems

agile_geek18:12:22

then design something into your architecture to measure that

fellshard18:12:34

You'll spend a metric ton of time in some places just getting the metrics set up. Second-best is simply measuring your own software and hoping they can infer the actual value in their own business.

fellshard18:12:58

Which is... risky and still prone to bureaucracy and political haranguing as usual.

agile_geek18:12:03

I think we need to challenge them to state what the value is and how it's measured

fellshard18:12:31

Try telling that to our management team >_>

agile_geek18:12:38

If they can't give at least some idea then why are they asking for the s/w

sveri18:12:47

Hm, why does a developer need to know the value of features?

agile_geek18:12:44

Because it helps prioritse. In theory I suppose the developer doesn't as long as whoever is prioritising does

agile_geek18:12:00

but I would make this completely transparent

agile_geek18:12:12

it helps me if I know the value of what I'm building

agile_geek18:12:25

I might make different design trade offs

agile_geek18:12:39

if I know the impact of the feature on the business

fellshard18:12:56

It's goal-alignment. You understand why they need X, so you can craft X to be the most suitable and generate the most present and future value.

agile_geek18:12:51

Typically businesses ask for a solution "I need an IOS app" but in reality they have a problem to solve that has a value to them. If you know that you may come up with a better solution.

agile_geek18:12:29

It may even drive the business to pivot and do something else entirely

sveri18:12:46

Hu? That may be so for very small businesses, but usually I would say, if a developer has to decide the priority of features, your process is broken already.

fellshard18:12:11

A good product owner will have the information and intuition needed to identify and make those pivots, and the grounding with the team to stake future milestones. It's not usually a dev role to decide the next milestone.

agile_geek18:12:13

Got to go but if your interested on my thoughts on Agile (and Scrum in particular) I have loads of blogs about the subject - https://chrishowejones.wordpress.com/

sveri18:12:09

I just created a common sense manifesto ๐Ÿ˜„ https://github.com/sveri/Common-Sense-Manifesto

agile_geek18:12:07

The who makes the decision depends on what flavour of Agile your using. In Kanban or Developer Anarchy you may not have a Product Owner. And this stuff scales to massive projects (done it myself)

sveri18:12:19

@agile_geek I have to admit I have a hard time believing this works. How do developers figure out what customers want?

agile_geek18:12:40

@sveri business says what the 2-3 most important things are and how to measure them. Devs build metrics for measures into delivery. Deliver small and frequently and measure the effect.

agile_geek18:12:20

A-B testing is simple case of same thing

sveri18:12:35

@agile_geek Ah, ok, so there is a backlog and developers basically create "tests" to measure value. Sounds like a nice idea. Gives a different viewpoint on the problems to solve.

agile_geek18:12:27

Yep. Except ideally it's a backlog of 2-3 problems to the biz and how they measure them. Dev teams then design small incremental "tests" to move the biz in correct direction.

agile_geek18:12:04

Also helps work out what has real value

sveri18:12:01

@agile_geek Thanks for the explanation. I like the idea, but would not want to do it myself, if I dont have to, but rather have somebody else take care about value calculation.

agile_geek18:12:58

I know what u mean but I do think we need to remember our job is not to write code, our job is to deliver value.

sveri18:12:39

Hm, I totally agree with you. I am mostly on the value side. But that can also mean I only write code that generates value and it is up to someone else to decide what generates value.

fellshard19:12:33

You write, they decide where value is, and you work together to figure out how to measure.

fellshard21:12:42

Just made a pitch for FP to folks at work, I think they remain unpersuaded. Time to work on that salesmanship...

meeli23:12:02

@fellshard @sveri @agile_geek re. estimation, we are building a project estimation tool in hoplon/clojurescript/clojure - http://estimate-work.com - hopefully trying to make estimation great again so even though itโ€™s a necessary evil, maybe make it slightly less evil

meeli23:12:51

โœŒ๏ธ