
Not delivering end-user value - mooreds
http://www.mooreds.com/wordpress/archives/3299
======
dkarl
_We accomplished more in a couple weeks with this perspective than we had in
the previous couple of months. This also let us commit to a real project plan
and timeline. Unfortunately, the client wasn’t happy about the projected and
past expense, and shut down the project weeks after the development team was
starting to show traction._

It's amazing how long big companies will let consultant-led software projects
go on with zero tangible progress as long as the consultants tell them that
the project isn't in gear yet, they're struggling to overcome problems that
pre-date them, and they have a plan to start making a ton of progress as soon
as they can start working the right way that they know how to. The business
doesn't have a way to forecast the project, because their forecast would have
to be based on something they haven't seen yet. The minute someone says "we're
making good progress" the business will extrapolate that out and realize the
project is a money pit.

------
miguelrochefort
This is something I'm just starting to understand after being an
idealist/perfectionist for most of my life.

YAGNI seemed like a shortsighted dogma. My colleague's design decisions looked
like ugly hacks. I preferred something to be well-done than to be useful.
According to my MBTI type, I was a perfectionist of idea, not a perfectionist
of action/result. I was trying to build a cathedral, not a bazaar.

I can attribute my ongoing transformation to a single video about effective
writing:

[https://www.youtube.com/watch?v=vtIzMaLkCaM](https://www.youtube.com/watch?v=vtIzMaLkCaM)

The main takeaway is that text is meant to be read, not written. Providing
value to the reader is the only thing that matters. How well you write, how
smart you sound, how much knowledge you deliver, doesn't matter as long as the
reader gets value from the text.

It sounds obvious, but it truly changed my perspective. I recommend this video
to everyone.

------
wrnr
I do consulting in the enterprise, it's not very exciting but living on the
streets is too exciting. Most often when I start somewhere new it is like here
is this computer, install the stuff we need and by tomorrow be productive
member of the adgile sprint. Ok.

What is described in the article sounds like a luxury to me, how do I get in,
what do I do wrong, tell me?

~~~
Nimitz14
Firstly, realize you're not a consultant. You're at best a contractor.

~~~
wrnr
Thanks for the advice, it is not smart but it is clever.

------
ssss11
The very first thing he says is that there were no (or vague)
requirements/user stories. I think he should have gone back and sorted that
out.

Its a pain in the ass i know, but on my current project if we didnt do that
we’d be in a complete shitfest right now.

The first step to showing buisness value in reporting is showing the goal, and
_then_ where you are on the path to it.

------
cjcenizal
"Shape up" from Bootcamp recommends integrating one soup-to-nuts slice of
functionality at a time as well
([https://basecamp.com/shapeup/3.2-chapter-10](https://basecamp.com/shapeup/3.2-chapter-10)).

A great read for anyone interested in simple, pragmatic, and effective
approaches to shipping software.

~~~
code_biologist
I love that book. If you want those thoughts in a highly condensed manner, the
author Ryan Singer has done a number of interviews discussing the high level
concepts of Shape Up. I particularly like the Software Engineering Radio
interview: [https://www.se-radio.net/2019/11/episode-389-ryan-singer-
on-...](https://www.se-radio.net/2019/11/episode-389-ryan-singer-on-basecamps-
software-development-process/)

------
commandlinefan
> smallest bit that would possibly work

Nice thought - but I've tried that in the past, though, and smashed into
unreasonable expectations from the clients themselves: "Why just do the
smallest bit? We need the whole thing!" This only works if everybody
understands the value, and this shared understanding is rare, to say the
least.

~~~
jschwartzi
Castle walls are built a brick at a time.

~~~
AnimalMuppet
True. But one brick is not a viable castle wall.

~~~
kaens
good thing no one is advocating for laying one brick and stopping

------
colinjoy
Good, if you throw in a few more ingredients. My favourites:

1\. keeping a steady compass on where it is you want to go

architecture and strategy are extremely valuable upfront investments and are
real enablers for a more agile implementation process later on.

2\. committing to quality on "minimum viable solutions"

An acceptable MVS should incorporate more than just ticking boxes on the
functional requirements. Shipping a steady stream of rough alpha features or
POC-like deliveries will not result in a great product and happy customers.

~~~
Ididntdothis
"1\. keeping a steady compass on where it is you want to go "

Totally agree. Just keep the direction loose enough to allow for changes. In
the compass analogy it would be maybe allow deviating from course by 20
degrees.

------
mixmastamyk
Agreed.

The hard part is that such insights come thru contemplation and reflection,
things we're "too busy" to do in a vulnerable project. At the very least we're
looking busy for appearance sake.

On the other hand, we often need to do a lot of this work to acquire empirical
data. Details necessary to realize why a project isn't working. Thus why this
kind of thing happens so often in project management, similar to a catch-22.

------
Ididntdothis
I agree with this but it seems a lot of people take it to the extreme stating
that you should only do the minimum and never think ahead. I think it’s good
to have a rough idea of where you want to go and then take very small steps
toward that goal.

------
habosa
Getting something to work end to end, however small, is so important. In my
experience the earlier you do that, the better. Otherwise you have no idea
what you're building.

------
narag
Yes! That's a piece of wisdom that many managers would need to learn. It seems
easier to sell an ambitious rewrite with the newest tech than common sense, do
what's right, fix what's wrong, baby steps work.

------
mikekchar
My corollary to this is that the biggest threat to a project is management. It
is management that will cancel the project, after all. Much more than 90% of
the time, they will cancel it because they are feeling uneasy about the
progress. Your job, if you don't want a cancelled project, is to deliver
regular progress that feels tangible to the stakeholders. Every company is
different in terms of how often they need that shot of "we made progress", but
every company is the same in that the longer you make them wait, the more
likely it is that your project will be cancelled.

"Smallest thing that could possibly work end-to-end" is a very good strategy,
if the "smallest thing" is small enough. If it's not, then you have to get
even more creative. Whatever you deliver, though, it has to feel real and
tangible to the stakeholders. Usually specs and design docs do not fill the
bill.

It is critically important that if you want to "do it right", whatever that
means to you, that you interleave the quality oriented activities within a
deliverable matrix. Good specification, good design, testing, refactoring,
monitoring, configuration management, etc, etc, etc are things that are
invisible to stakeholders from a tanglible delivery aspect (unless you are
incredibly blessed). Thus, these activities must be similarly invisible from
the external view of development. Shining a spotlight on how much time you are
spending on these quality aspects of development will only hasten the demise
of your project. At the very best, they will be used as points of negotiation
from the business side - "Could you deliver faster if you didn't test this
part?". The business should be so preoccupied with looking at _what_ you are
delivering that it doesn't notice _how_ you have delivered it.

The biggest mistake I see from developers is the idea that the business must
buy into the developers' sense of values. It is, of course, wonderful if that
happens, but it is rare in the extreme. Most businesses do not understand
those values. To be fair, given the amount of internal bickering we tend to
have as developers with respect to "doing it right", I have to say that even
_we_ do not fully understand our own values.

It is important, though, that development be able to use the practices that
will give them the best shot at success. Just like a developer should not be
calling the shots for strategic business direction, so too must the business
stay out of our strategic development decisions. To ensure this, you must
create a development process that is largely boring for a person from the
business side. As soon as you link your development process with the stategic
success of the company, you invite the business side to feel as though they
should be calling the shots. This is almost always a mistake in my experience.

Deliver early. Deliver often. Make each delivery contain something that has
tangible results for the business. Make your process boring without
exceptions: "This is just how you do it" rather than "We need more time for
analysis". Refactor your code when you need to without asking for permission
rather than creating a task to refactor your code. Improve your build system
with every small step rather than spending a month up front creating the
perfect build system. However, no matter what you do, always remember that
there must be delivery. Plan your activities strategically and try to work on
quality uniformly.

------
notyourday
> Unfortunately, the client wasn’t happy about the projected and past expense,
> and shut down the project weeks after the development team was starting to
> show traction.

Translation: development team did not manage customer's expectations.

------
kf6nux
I suspect this experience is pretty common. It so perfectly matches one of my
experiences, I'm curious if it's the same company.

