Added a line about supporting teams and customers in setting up and measuring initiative success criteria

[random82]

The main reason for that is I found business agility missing in the role description. I find those skills useful when working with customer and worth putting explicitly into the role difinition

[rbanks54]

I think it's a little too specific/prescriptive. A/B testing is just one way of trying an idea, for example. Also, business agility isn't what you're describing - it's an experiment mindset and evidence based learning.

If you want to talk business agility, talk about waste reduction, increasing a team's capacity, raising their skill level, avoiding low value work, etc.

Maybe try some rewording to see if you can better express what you're after, while leaving it generic enough to take different approaches.

[glav]

Agree about being too specific/prescriptive. I don't think you can (or should) list out ways you can assist, just the fact you should be able to run with the process and augment it or add value.

On a slightly more pedantic note, the line: "balance the "iron triangle" constraints of time, cost, scope and quality" suggests 4 aspects of the triangle, when there are only 3 (ie. remove the 'scope').

[random82]

@rbanks54 - changed the title and wording as well. Let's put business agility aside and let me know your thoughts.

[random82]

@glav - There is a main problem with "iron triangle", even if you deliver high quality product, on time/cost and within a defined scope, the journey doesn't end there. We need to measure impact of that predefined scope to learn more about its impact on the business.

The iron triangle helps in delivering outputs (awesome software), hypothesis testing helps to measure outcomes (how happy customers are using the awesome software). My main intention is to emphasise on helping customers to deliver things that may impact their business positively, as opposed to just delivering original scope, on time with high quality.

Does it make sense?

[andrewabest]

@random82 I agree with the sentiment, but I still think talking about hypothesis is too specific, as @rbanks54 mentioned

I am comfortable with coaching my team and a customer on how to measure business value of intitatives I help to deliver, in particular how to develop and test a hypothesis, how to design and execute a hypothesis testing and communicate results to stakeholders in an objective and transparent way.

So what about gauging business value before you deliver an initiative? How do you justify actually pulling the trigger on something in the first place? We have been using impact mapping with a lot of success, which also steps into needing testable results - which is what you are talking about. This is all well and good, but too prescriptive for madskillz.

I think you could almost narrow it down to your first sentence

I am comfortable with helping my customer inspect and measure the impact and value of their software initiatives

[glav]

@random82 Yeah I understand that, but with more than 3 points, it ceases to be a triangle :-) which is how it read (ie. attributing 4 points as the Iron triangle - more of an Iron square). So, "balance the "iron triangle" constraints of time, cost, scope and quality" would become "balance the "iron triangle" constraints of time, cost, and quality" then you might add any extra content around scope management etc however your last line is as concise as it needs to be imo "helping customers to deliver things that may impact their business positively, as opposed to just delivering original scope, on time with high quality.

[glav]

Looks like Andrew beat me to it. Agree with the first sentence comment.

[random82]

@glav Just to clarify - I'm not changing the iron triangle part. For some reason GitHub picks it up as a change but the only change I propose is about hypothesis testing

@andrewabest - yup, that sounds about right and really like how you put it. Commit coming soon :)

[glav]

@random82 Well, there are still only 3 aspects in the Iron triangle, not 4 as is currently stated in the text.

[random82]

@glav actually, depending on interpretation, there can be more than 3 aspects (or constraints) of Iron Triangle even though there are only 3 vertices.

Some theories put a quality as a fourth constraint lying in the area of the triangle, while others merge scope and quality to a single vertex. I prefer a separate fourth constraint because it shows much better a difference between delivering great scope with low quality or state-of-art product with irrelevant scope that no one wants .

I consider the Iron Triangle as something occasionally helpful, rather than have to follow rule. I believe there are projects over budget and over scope that result in huge success while projects on time and within a budget may end up without any impact on a business. It's about building right products.

I don't agree with putting hypothesis driven development as something that controls only the scope part of the Iron Triangle because each hypothesis may define its own scope, time and budget, as well as ROI and success criteria.

I also this is slightly off-topic and I'm happy to fix it in a separate pull request if you like.

[andrewabest]

See https://en.wikipedia.org/wiki/Project_management_triangle for some context that illustrates @random82's point. Agree it is a separate discussion.

[andrewabest]

New wording looks good to me @random82 :shipit:

[glav]

@random82 Yes it is a different discussion and wasn't really questioning that aspect anyway, again was being pedantic. In reality there are quite a few more to be considered dependent on context and am not going to, nor is it actually valuable to this task, to define them all. If no one else cares, then I am not going to lose any sleep over it. The changes as they stand look fine and remove some of the prescriptive nature of wording that was present initially.