Almost every change Yabe-san introduced risked decreased efficiency and quality of service in the short term. Having the cleaners distracted from their jobs by talking with passengers, decreasing measurement and oversight. Even making the cleaning crews more visible to the customers went against the hospitality and travel best practices which hold that this kind of work is to take place out of sight and all friction for the customer is to be removed.

But everything Yabe-san did increased the possibilities for human connection. Not the usual, scripted staff-customer communication or the usual manager-staff meetings, but inefficient, unnecessary communication not directly related to completing the task at hand.

Rather than managing for control and compliance, he was managing for transparency and connection.

Internally this not only resulted in a skyrocketing of morale but an outpouring of creative ideas. The Tessei staff not only came up with innovations that improved their own jobs, but helped design the shape of the bins on the new Hokuriku Shinkansen Line, and they came up with the idea for the nursery and baby areas in Tokyo Station.

And, of course, it was this feeling of human connection that resulted in passengers cleaning up after themselves because they did not want to create extra work for someone they had just seen working so hard.

It led to people realizing that we are all on this train together. Yes, it eventually made processes more efficient and less expensive, but more importantly, it actually made life a little bit better for everyone involved.

As I said, when I got stuck, the problem was never with coding or other technical issues. Of course, understanding every little detail of Flask was difficult sometimes—I was also hunting bugs for hours, sure. But the things that stopped me were mostly mindset related.

So here are a few practical pieces of advice to get over these issues—for my future self and for you—if you want to get a hobby project done!

A particularly worrying variant is the Scaled Agile Framework or SAFe. Essentially this is codified bureaucracy, in which the customer is almost totally absent. It is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done. Essentially it subordinates the agile teams to the bureaucracy, rather than doing what is necessary to achieve business agility, namely, namely [sic], transform the big monolithic internally-focused systems into arrangements where the budgets, HR, Finance and so on are flexible and externally focused in support the Agile teams in operations. The insignificant role of the customer in the chart above is indicative of the problem.

When asked what stops them from safely and regularly deploying every change into production environments - everybody seems to have their own reasons. Organizational, cultural, historical, technical, contractual.. Some go as far into denial as saying : "Oh, we don't need continuous delivery. In fact most companies out there don't really need it." But the underlying reason is of course the lack of confidence. Nobody wants to be the culprit for a system outage. According to a number of industry surveys the average cost of one hour of downtime is around 75000 USD. There's a lot at stake! So instead we choose to move slower, to add controlled handoffs and build home-grown guardrails. To hire more Ops engineers and call them SRE to feel more secure. Rarely discussing the price of establishing and maintaining all of these over time.

...

Engineers who've experienced true CD can't really fathom any other way of delivering software. As @giltayar puts it "CD ... is a total game changer. It changes how you perceive software development and delivering features... I did CD and EVERYTHING about how I developed changed. It was magical."

What’s going on is that without some kind of direct experience to use as a touchstone, people don’t have the context that gives them a place in their minds to put the things you are telling them. The things you say often don’t stick, and the few things that do stick are often distorted. Also, most people aren’t very good at visualizing hypotheticals, at imagining what something they haven’t experienced might be like, or even what something they have experienced might be like if it were somewhat different.

You need two things to effectively move fast: a culture of psychological safety and smart investments in tooling. Employees need to feel empowered to speak up if things are moving too fast—if they are concerned about why a feature is being built and to identify gaps in the processes. They need to feel they won’t be blamed when something breaks. Building this requires empathy, open communication, and teamwork. This psychological safety is the foundation of being able to move quickly and quickly recover when things break.

Next up is selecting the right tooling and processes. Invest in tools that make things easier. Tools should be useful, usable, and change the underlying problems, not create more.

Time is seen in a particularly different light by Eastern and Western cultures, and even within these groupings assumes quite dissimilar aspects from country to country.

I’ve used the term *Feature Factory* at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

Many developers have been voicing their concerns about Agile being broken lately. Among them are prominent figures like Robert C. Martin and Kent Beck – two of the people who charted the Agile Manifesto. Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt; frameworks like Scrum are just “red tape,” which they were never supposed to be; programmers are asked to commit to arbitrary estimates and deadlines and never get the time to think thoroughly about the features they’re creating. So if we can acknowledge and work on these problems, perhaps we can fix Agile.

But here is the real challenge: How can we learn to recognize our own ignorance and misbeliefs? To begin with, imagine that you are part of a small group that needs to make a decision about some matter of importance. Behavioral scientists often recommend that small groups appoint someone to serve as a devil’s advocate—a person whose job is to question and criticize the group’s logic. While this approach can prolong group discussions, irritate the group, and be uncomfortable, the decisions that groups ultimately reach are usually more accurate and more solidly grounded than they otherwise would be.

For individuals, the trick is to be your own devil’s advocate: to think through how your favored conclusions might be misguided; to ask yourself how you might be wrong, or how things might turn out differently from what you expect. It helps to try practicing what the psychologist Charles Lord calls “considering the opposite.” To do this, I often imagine myself in a future in which I have turned out to be wrong in a decision, and then consider what the likeliest path was that led to my failure. And lastly: Seek advice. Other people may have their own misbeliefs, but a discussion can often be sufficient to rid a serious person of his or her most egregious misconceptions.

Interesting article written by David Dunning, of Dunning—Kruger effect fame.

1–10 (81)   Next >   Last >|