Live data from Hacker News

The no excuses culture

steveblank.com

121–130 of 171 posts

Re: The no excuses culture

#121
post #90

Earlier quoted context omitted.

Are you sure? Daily standups = checking up on you every 8 hours, and then you have tons of checkups in-between. Retros, sprint planning, ticket management. Agile methodology is designed for a tech lead to know what each member of the team is doing. Agile methodology is not "here's a large task, I don't want to hear from you again until it's completed".

None of that stuff is "Agile". Those things are artifacts / ceremony related with specific methodologies which are only "agile" to varying degrees. Read the Agile Manifesto, there's almost nothing prescriptive in there at all. Agile methodology is designed for a tech lead to know what each member of the team is doing. That might be the case for some specific "agile" methodology, but if there's a core essence to Agile…

How, exactly, is embracing and responding to change going to happen if there's not frequent communication? What form of agile methodologies have the developers going off on their own for weeks without oversight? How do they 'respond to change'?

A strict literal reading of the agile manifesto doesn't include daily standups, yes, but if you read it at anything other than the most superficial level, frequent communication is necessary.

Re: The no excuses culture

#122

I'm surprised that nobody here realize that this marketing team has reinvented part of agile and lean managment? Making devs accountable but not holding responsible, group solving problems and Andon, prioritizing tasks, a bit about handling external dependencies, kind of sprints, visibility, staying on budget... They're obviously not following Scrum in Action at the letter, but I really saw a striking resemblance wit…

It's not surprising that no one else commented about it because agile/scrum/lean are terms that cast a huge net.

If I just set deadlines, then I've recreated part of Scrum which has deadlines at the end of Sprints. Deadlines existed long before Scrum was defined.

I think of Agile, Scrum, and Lean as just names for common ideas about the nature of how work can get done efficiently. Very few of the ideas from these practices are unique to those practices. The reasoning for why those ideas work doesn't go away if you don't call it Agile/Scrum/Lean.

The important thing to recognize is that the ideas have merits on their own, and their inclusion in any particular lexicon or philosophy is incidental.

Re: The no excuses culture

#123
post #95

Earlier quoted context omitted.

No of course not. The whole problem that Steve is talking about here stinks of mismanagement of some sort tho, that isn't really fixed by telling people "stop giving me excuses on delivery day". Something is wrong with the whole organization, but he isn't able to figure it out, so he's telling people to put up or shut up. He's attacking the symptom, not the cause. Read on the Toyota Production System for alternative…

Something is wrong with the whole organization, but he isn't able to figure it out, so he's telling people to put up or shut up. I think for any of us to try and go into specifics on that particular case, without a lot more information (unless we were there), is an exercise in pointless speculation. I think it goes without saying that all generalizations are flawed, and I'm sure the company did need more than just "s…

I agree. I very much enjoyed this article. Even though Steve's situation may not fit every organization perfectly, I think the core concept holds true.

The way I see it, the symptom is giving excuses the day of, and the problem is people thinking they are entitled to a job with only putting forth minimal effort.

Re: The no excuses culture

#124
post #121

Earlier quoted context omitted.

None of that stuff is "Agile". Those things are artifacts / ceremony related with specific methodologies which are only "agile" to varying degrees. Read the Agile Manifesto, there's almost nothing prescriptive in there at all. Agile methodology is designed for a tech lead to know what each member of the team is doing. That might be the case for some specific "agile" methodology, but if there's a core essence to Agile…

How, exactly, is embracing and responding to change going to happen if there's not frequent communication? What form of agile methodologies have the developers going off on their own for weeks without oversight? How do they 'respond to change'? A strict literal reading of the agile manifesto doesn't include daily standups, yes, but if you read it at anything other than the most superficial level, frequent communicati…

> How, exactly, is embracing and responding to change going to happen if there's not frequent communication?

Frequent communication doesn't have to be synchronous, prescheduled, or in-person, though, and it doesn't have to be through a heirarchy (team lead).

Also, the phrase "Agile methodology" is almost an oxymoron (and absolutely incorrect in terms of most of the methodologies it is applied to); a development methodology in the usual sense cannot be Agile, though a team's higher-level methodology that controls choice of and change to the development methodology can be.

Re: The no excuses culture

#125

Sounds to me like the real problem is that Steve Blank does not have a system to get enough context from individual contributors to know that a project is slipping well before the deadline. This is a management problem being cast as a individual contributor problem (we need to fire those lazy, incompetent employees who don't ask for help when they should /s), what a bizarre inversion of reasoning. Edit: Management sh…

You miss the point that "no excuses" is exactly that system. A manager shouldn't have to ping every subordinate every day for status updates, that's annoying to both and should be unnecessary. Management only works through delegation, you need to trust your subordinates to do delegated tasks without hand-holding, but you also need to give them a protocol for exceptions, which is exactly what this is. Managers usually…

I abhor status meetings with the round-robin format. As an individual contributor I love to collaborate with anti-meeting managers. The catch is to get the IC's to provide timely information on successes and blocks. I like the idea of asking that all the IC's email announcements of their successes as they happen. There's one less reason for the "status" meeting. The rest of the equation is to get people to automatically network about their blocks. That takes care of another major, routine component of status meeting. Now it can be valuable to workshop or otherwise, in one place, collaborate about a problem. I once had a manager who supported classic-form scrums. He was the one who had the Outlook fu for scheduling a meeting on the calendar, so he scheduled the scrums, but he did not appear at the scrums. He did circulate among his reports, but he didn't have to have long conversations with them, because all the other mechanisms were getting the work done.

A regularly-scheduled meeting tends to become the ONE channel for communication, and with such a meeting on the calendar it is a little unconvincing for a manager to say that they want to hear about blockers before the meeting instead of during it.

Re: The no excuses culture

#126
post #67

That's the Curtis LeMay approach to management.[1] He was famously into management by fear. We see this problem in software, especially in DevOps and "agile" shops, because the process is so forgiving of delay. In a manufacturing plant, no product comes out until all the component parts are ready. So there's a "no excuses" culture about running out of parts, or having an assembly line station down unexpectedly. Softw…

Software business is different - that much redundancy in planning would make you loose customers or annoy higher levels of management. That is whole reason for agile - you trade safe planning for week by week transparency and tight estimates.

It us also price for doing bew things. Web shops that crank one similar project after another tend to be on time - they work like factory.

Re: The no excuses culture

#127
post #36

Earlier quoted context omitted.

Ah the 'I'll fire your ass if you give me an excuse on the due date but of course an attempt to maintain an open line of communication between now and then will be met with sunshine and rainbows.' Let's call this disingenuous bullshit what it is - management by fear. Don't tell me you're about 'collective problem solving' in an environment where people are constantly fearing for their jobs.

Heh, I think it made sense upto the point where he threatened firing people. I agree that is too extreme: you're gonna quickly lose a lot of people who perform best when they're not under constant pressure.

I disagree. Strongly.

A common attitude of effective managers as documented by First, Break All The Rules can be summed up by, "I never waited too long to make the right hire. I never fired the wrong one quickly enough." Having the wrong employee is very toxic for your organization and culture.

The rules that Steve laid out do not actually put pressure on people. They amount to, "Be accountable for what you say, try to make it work, and let people know quickly once you hit a roadblock." It is about effort and communication, not achieving results.

People who don't put in effort and don't communicate can't be made to, and can't stay. But people who do, can. And, on average, this will work out well.

Re: The no excuses culture

#128

This story being about a marketing department might seem like it's not applicable to a software company, but when it comes down to it, we still break down our work into bite-sized stories that can/should be accomplished in a timeframe that's estimated ahead of time. Some shops have more nebulous tasks because they've never done something before, I get that. But for the build the thing we know how to stuff? We should…

I believe this just isn't possible for a whole lot of projects. Codebases tend to grow so large, and people tend to come and go, so people don't really know most parts of the code, so then a lot of the time estimates are inaccurate to the point of being useless.

Re: The no excuses culture

#129

Excuses happen because people don't want to be blamed. If your team had an excuses problem, it's a response to a blame problem: when a problem is identified, people aren't looking for solutions, they're looking for someone to blame. Saying "no excuses" and "we're holding people accountable" might fix the excuses problem, but it exacerbates the blame problem. "Holding people accountable" is just blaming people harder…

The treatment of airplane crashes comes to mind here for me. Crash studies look for cultural and technical improvements that reduce the risk of the same thing happening again, as even "pilot error" ultimately points to some problem in education or work environment.

Re: The no excuses culture

#130
post #36

Earlier quoted context omitted.

Ah the 'I'll fire your ass if you give me an excuse on the due date but of course an attempt to maintain an open line of communication between now and then will be met with sunshine and rainbows.' Let's call this disingenuous bullshit what it is - management by fear. Don't tell me you're about 'collective problem solving' in an environment where people are constantly fearing for their jobs.

Heh, I think it made sense upto the point where he threatened firing people. I agree that is too extreme: you're gonna quickly lose a lot of people who perform best when they're not under constant pressure.

It's not just losing the wrong people, but also retaining the wrong people: A common outcome of management by fear is that people learn survival tactics: Avoiding commitment, shifting responsibility, finishing tasks poorly rather than late, ass-covering, and outright cooking the books.
Post reply on HN