> This enables devs to get trusted by management
I am curious about that “trust” part. In your model what happens when management doesn’t trust devs ? do devs trust management ?
I am curious about that “trust” part. In your model what happens when management doesn’t trust devs ? do devs trust management ?
Though in my experience, devs do not trust “management” writ large. But they will trust individual managers who see their job as representing their teams within the management hierarchy and protecting them from the suits. That trust isn’t automatic and usually has to be earned.
Getting development done has traditionally been a game of getting developer attention. Scrum is one way of clarifying the contract between the stakeholder and the development team. I'm sure there are others too.
IMO, you should only really care about imposing deadlines as an answer to the question "how much time is it worth investing in solving this problem?" If the scope of the solution becomes larger than expected, and it starts to look like it won't pay off, abandon it and start doing something else instead. You had a good experiment which was entered into in good faith based on the data available at the time. That's the nature of experiments. Learn your lessons and try the next one.
Trusting that your teams have good plans that fail early and incorporate fast feedback loops is generally the only real way to make sure that they have realistic scheduling/deadlines for those plans and that they are likely to generate real value. It amazes me how many people in management seem to put their efforts and emphasis mostly on scheduling the plans, rather than the plans themselves. I guess it's easier to come up with estimates for things, than it is to come up with good strategy and business value propositions/justification.
I really recommend reading "A Seat at the Table" by Mark Schwartz (ISBN 9781942788119) for a good exploration of how agile meets management trust issues, budgeting and longer term planning, and how to try to break down the barriers between "IT" and "the business" (when in most modern companies, IT is the business).
Reading the comments, I think what I was bugging is the notion that would give a task not trusting it would be done.
People point at micro-management as an effect, because it basically means providing more limited tasks with limited risks.
But I think in the long term the direction we tend to take for people we don’t trust is to set penalties (bad evaluations, demoting, firing included).
In that sense, in average there should only be people you trust at the appropriate levels of an org, so I am not sure it is important to focus on gaining trust as it builds up just by doing ones job.
That’s where I like your idea of management trusting a plan, more than focusing on the team.