I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting.

For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page.

It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.

"While you mentioned this during the demo, I noted: 1. Your state-drop down has only 3 entries. 2. There is a validation error 3. You get an error at the end.

We need you to fix this ASAP !!!"

Would it be better to show no progress at all until it's completely done? I know agile methodologies tell you to demo regularly, but I'm more and more under the impression that they are to provide progress feedback / reports to management.

Something like https://wiredjs.com/ might work, if you are building a web-ui.

Sucks it has to be this way so often.

Yeah it’s all perception, but cultivating the right perception is vital to effective, productive communication.

Polished things have a context of "use", not "evaluate", because we use so many polished things every day, but very rarely have any need to evaluate them (mostly only when we're buying them, or when a repair person asks us to describe what's wrong with them.) Whereas unpolished things are mostly "for" evaluating; it's rare that people use unpolished things (outside of, say, disaster-relief infrastructure.)

Does this really imply “humans are broken”? We all have limited resources and I think this could just be a first order prioritization mechanism. Of course one has to be aware of the bias but that’s a different problem.

it's not a way of gaming the system, but a way of prompting better feedback. For instance, in a Design Thinking process prototypes are more useful when they look rough/unfinished. A more polished piece of work might result in people being afraid to break things.

I use both approaches in my work:

1) demo small, tested bits during show and tells and any meetings where the point is to demonstrate progress. 2) demo large, unfinished and barely stable pieces of work when ideating, trying to figure out the next steps

2) is hard and works only if: - we know what the unstable parts are (because we have tests, so we know the gaps) - we know the audience and how much context they have

The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.

It was my first professional development job and I learned a lot of things. One of the keys was this:

Your boss and employer are not your friends. When you promise something to your friends, you owe it without any expectation of reward or return. But your employer owes you something for everything you give them. If they fail to meet their end of the bargain, that's on them and you are absolutely 100% free to leave. That can be money, time off, good working conditions, respect, trust, or any number of things. For me money was not primary (though it is nice): I wanted a good work environment, interesting work, and respect. Fail any of those and I will be looking for an exit, even if it's just a transfer within the same company. But respect is first in that. A boss who shows little respect to his employees is not someone I want to be around. I had that boss who chewed me out, I had another that kept me doing busy work for a year and kept saying worthless platitudes like "you're important to our work, we can't do this without you" when everything pointed to that being false. He was just empire building and trying to grow his direct report count, but it hurt those of us under him because he didn't have the work (but he did have the money) to keep us there. (I was still relatively junior at that job and stayed longer than I should've.)

[0] The hierarchy was something like: VP of Engineering (several divisions below him) -> Chief of Engineer (Aviation) -> Chief of Software (Aviation) -> Chief of Testing (Aviation) -> Me; other production lines had similar chains below the VP.

[1] When she was my manager I quit, or more accurately transferred to another group. Years later, I quit my last job for several reasons, one was her. She was not in our division while I was in that position, but they'd just hired her on. When I heard the name I had to verify, when I confirmed it was the same person I was ready to exit.

If he tried to chew me out, I'd just say "That's not how I remember things. I said I was 80% done, and, frankly, it was a mistake for you to pull the trigger on the release without confirming with me first."

Not if you are on an H1B visa ;-)

This works even when you're on a visa, but can take longer to be truly comfortable. I had a classmate in college who'd secured a work visa. His plan was to work for perhaps a decade in the US, save aggressively, and then return to his home country. Salaries in the US were 10x higher at the time than in his home country. Saving even 20%/year meant saving 2 years' of income every year he worked. And he was frugal enough to save a lot more than that. Invested well, taking what he learned back home, he would be set for life at this point (I didn't stay in touch so I only know the plan started well, not how it turned out).

(Perhaps you could roll over part of the 401k into an IRA first, and then take the rest as 72(t)?)

Can you expand on this? I recently moved to the US and people keep telling me to get a 401k, but I haven't yet.

  At a minimum, you should save enough to your 401K to get the company matching.
  Let's say the company match 50% on the first 6% you save.
  So if you put 6% of your salary to 401k, the company will add another 3% in addition to what you did. That's a free 3% raise. 
  Tell me another way that you can get guaranteed 50% return of your money.

 
  In addition, there is the tax advantage where you do not get taxed on your money until you retire. So you money grow without taxes until you actually need them.

  Are there bad 401k? yes, but I think very few. Check the rules of your company. But most of them are very good deals and you should take advantage of them if you can.

But one must also 100% expect themselves to evaluate thoroughly T&C, pros and cons before signing up for anything, including a visa.

I happen to get along really well with the person three levels above me, but I can't imagine dealing with getting direct negative feedback from him. Honestly, more of my conversations with him over the years have probably been about things unrelated to work than work-related; we don't just hop over my direct manager and his boss unless there's a really good reason for it.

And yep, I was actively avoiding that environment too.

Someone is bound to jot that down and interpret it as a hard commitment regardless of any other details or conditions.

I've come to realised this, "true" agile is more like being funny and smart(not that I am either). If you have to tell people you are smart or funny, you probably are not. Ever noticed how smart people(the really clever ones) are just absurdly smart without walking around telling everyone "hey I'm smart", usually the nicer they are the more intelligent they are(yea you get exceptions), same with funny :)

I feel it goes double for "agile-processes" if you have to walk around and tell everyone (management or interviewees how agile your process is, it's probably not)

On the other hand if you have a look at the original Agile Manifesto[0] it is a different beast all together. It specifically seems to go against using set processes altogether and basically boils down to nurture organic communication, to adapt and focus on getting shit done.

I suppose the "agile" in the former sense is a compromise to edge closer to the latter, while still maintaining a familiar corporate structure.

EDIT: [0] https://agilemanifesto.org/

The places that went "we do all the agile incantations in the book, because that's the only way," well, those actually had a scrum-o-fall culture.

If you want to be working with a team trying to be funny, at some point you have to use the word "funny" and "comedy" to make sure you all are actually trying to do the same thing. And make sure the producers and show runners agree that it's a comedy you're making.

Same with agile.

If a country explicitly calls itself "demoractic" in the name, it's likely not.

They usually expect a fully working demo

You must demo the product in a form that leaves the right impression of the current state. If you are painting a picture of a polished product, expect polished expectations. Instead, show the bugs and say "we are still working through this section" Show missing pages, show your work in progress. Show wrong colors. Show potential, wave your hands and tell them to imagine this part working. Don't fake it. If that feels wrong, then a demo isn't right.

If you show it in a form that looks complete and polished, even if you say it is not, how can you expect any other conclusion from the viewer other than "it's practically ready!"?

Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint.

There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.

Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase.

If planning has to work you should be familiar with what you are building , with poor information on the bug/ code / stack planning agile is just useless overhead . it works great for yet another CRUD app where you know the requirements to the dot and know exactly how to build or fix not always , most management fail to differentiate

All the reasons in the TFA are also why it is hard to estimate , what and how much time will take .

I mean obviously this only makes sense as a way of organizing a team who are trying to build something exploratory - that’s what scrum is meant for. If you are trying to pursue a solo research project within a team the rest of whom are doing scrum then... that’s not a problem agile can solve.

Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the effect without bothering to dig deeper just because someone is clocking me on a timeline I committed.

It kills all the joy and fun, work becomes boring, this is by design, it is hard to run an organization unpredictably. If only management trusted you to deliver without looking over shoulder constantly ( when the situation warrants it)..

It is not only a engineer's gripe, it applies to management too, the board/ market forces them to be very short sighted, unless you are musk/jobs/buffet it is hard not to buckle to market pressure and invest in longer term opportunities.

The point is not that planning is bad, it can do a world of good in many including unpredictable situations, it is more that blinding pushing a framework especially agile because it worked somewhere and everyone says so, or the manager can't be bothered or won't risk doing something different as the situation warrants.

[1] https://cloud.google.com/blog/products/management-tools/sre-...

Scrum is a collaboration hack for creative problem solving teams, not a managerial accountability tool. The version of scrum where stand ups are for checking on the team’s progress and velocity is reported on up the org is using the tools of scrum to solve a very different problem than the one that it was designed for.

I’m sorry you don’t believe it’s possible but I can tell you from experience that it is possible to use the processes of scrum and the principles of agile to help a team collaborate on open ended creative problem solving tasks.

Sometimes your demo is nothing more than 'here it is in the log doing xyz' or 'I added this thing to this config file'. Not all demos are big flashy ordeals. The team I am on right now most of my demos look exactly like that. I can usually do them right after the standup. Our team allows it because we are mostly remote and talking to each other helps.

I personally use scrum as a weapon to make sure management does not overload our teams. Those made up story points are a good way to say 'you have tasked us with 4 months of work in 2 days'. You have to know your manager too. You have to talk to them. Know what they are looking for. Some take a very hands off approach. Some want the nitty gritty details. For both of those a 'oh that is going to take 3 months' may sometimes work. But it does not give them actionable items to help you. The task broken down into some sort of chunked out work does. Sometimes you do not know. It is OK to admit that. That is when you make a discovery story. Make sure they are onboard with that story is to help you find out what is needed. Even then you will still learn along the way.

I worked with one guy who wanted to task things down to 15 minute increments, 6 months from now. He kept failing. Because he was being too narrow. He refused to do story points. Because they were 'stupid' yet management kept piling more stuff on him to fail at. He was in every weekend and in until 9PM every night. Because he had no tools to push back. Give your management numbers and actionable items or they will assume everything is hunky dory.

For all the things that can be atomic like that, it's good practice.

The bigger ones just take time, and aren't shown, until ready for use.

I wasn't talking about intra-team demos to, say, product owners.

Not having demos of incomplete features would just hide the issues until they are released to the final customers, creating a problem you didn't have before, and making it much more complex to solve.

Progress gets quantized. Some quanta are small, easily shown, etc... other quanta are a bit bigger, less easily shown.

There is a similar problem in manufacturing.

Atomic releases.

While making something, there are many subtle tweaks to the BOM. Changes, substitutions, removals, adds.

Upstream people can make a real mess out of all that, and one way to prevent it is to only deliver releases that are resolved and intended for manufacture.

"where is revision 4?"

Doesn't exist, won't get manufactured, etc... "Use Revision 5 plz."

For the case of insuring expectations get aligned, a mock up can be used. Deliberately used to generate a spec.

In my experience everything can be broken down if you spend five minutes actually trying to break it down. And the benefits are very much worthwhile.

People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.

4-11 years depending on exactly what you'd define as "brownfield"

> People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.

True but beside the point. The same point stands: you can always find a way to make a worthwhile improvement in two weeks - something that's useful on its own, even if it's also the first step of a much bigger improvement plan.

Sure, sounds straightforward enough. Start with simple cases (e.g. universe is a unit circle), you can definitely implement useful pieces within two weeks.

> first the mathematical models behind it need to be created then implemented in software.

That's not a real (i.e. user-facing) requirement.

(Cause another lesson is that people have a lot of trouble giving worthwhile feedback on a verbal/written description of something, they gotta see a thing in front of them).

I've learned this adage years ago (I think it was from Spolsky), but nowadays I'm in a project (re)building an UI from scratch as a sole developer aaaand I made the same mistake.

I was doing some UI prototypes about activating a process, big green Activate button, opens up a confirmation dialog, spinners with some artificial / simulated delay because I didn't do the back-end, and it caused confusion with our tester because she was wondering if activation actually works.

I've got three options; remove the button for now (I should do that), partially implement the activation (changing a status in the back-end), or fully implement the activation (which has a lot more prerequisites).

I've learned the opposite. If I communicate clearly that what is being shown is little more than a mock-up, executives of all levels and technical skill, all the way down to managers just above myself, all understand that a very thin and scripted demo is not anything close to a finished product.

Describing the demo as a "house of cards" that will collapse with a single misstep gets the point across nicely, while also giving the demo audience an eyeful of what can be accomplished if everything is handled appropriately.

Demos are carefully scripted and rehearsed, values are hard-coded, and absolutely nothing exists that does not prop up the demo for the purposes of the script and the talking points.

It is hard to describe to someone who hasn't written an application demo like this just how little actually exists behind the UI.

Anyway, my point is that if you choose the correct words, anyone can understand that it's like a painting of an application, and not an actual application, just like a painting of your mother is not actually your mother.

What are they going to do? Fire me? I can go anywhere. They can't find me anywhere.