I would love if Apple started treating app analytics like they do my GPS location or my camera permissions. Basically, if apps want to send analytics, they must go through an iOS API.
Then as a user, I can inspect what apps are sending and how frequently. I should be able to block requests or set myself as anonymous. Or allow apps for certain amounts of time etc.
In my experience when people focus too much on sprint deadlines, they miss the purpose of sprints.
Timed sprints exist not for the benefits of managers, but for the benefit of developers. They exist so that the development team has a shield against managers making last-minute decisions and changing priorities without notice.
If the focus and discussion is regularly on short term deadlines, then the developers are not driving the process, the managers are. It means that sprints are seen as a management methodology and not a development methodology. And then everyone has a hard time.
Managers who think this way know they’re not “allowed” to make mid-sprint changes so instead they focus on the end/deadline.
The managers should be spending their energy supporting the team and figuring out what the priorities are for the next sprint(s). If they’re spending their mental energy on deadlines then they’re doing everyone involved a disservice.
Sprints exist so that both management and devs can realize that there is more work than there is time. It forces devs to be focused and scope their work. It forces management to prioritize and scope down as well.
Keeping the deadline of the sprints is supposed to force management and devs to agree on reasonable scopes, such that the output of the dev team becomes predictable with time.
This enables devs to get trusted by management, breaking the poisonous relationship.
Yeah, in my experience this is “boundary setting” — and it’s absolutely critical to a healthy dev culture.
When I was a baby manager, I focused hard on Agile process and deadlines / roadmap commitments. And you’re right; it completely ruined my relationship with my team. They saw me as a representative of the oppressive corporate overlords, which is totally fair because those were the people I was trying to impress.
It took a few failed projects for me to get it through my thick skull that “doing things right” meant protecting my team from this behavior pushed down from above. It meant giving them space to do the job we paid them for. I realized I was letting my anxieties overrule people who knew way more about the issue than I did. It meant listening more and pushing back on unreasonable requests.
And it turned out my boss didn’t care about missed deadlines for the most part — he cared way more about production incidents. The best way to reduce production incidents is to work deliberately and not take unnecessary risks. A side effect of this was that we had way more power to say “no” to other teams, which made maintaining the code base a lot easier.
> protecting my team from this behavior pushed down from above
OT, but it's super common to hear in management circles about how managers are supposed to "protect" or "shield" their teams from the nasty CTO or CEO or some powerful stakeholder. IMO this is just not sustainable.
A CEO or any powerful person pushing a manager too hard accomplishes absolutely nothing at best, and is a disaster at worst. This kind of thing really hurts the morale and culture of the whole company.
Glad to know your boss is one of the good ones. My current CTO is like this and compared to the company I was in before it's night and day.
Tbh this is exactly what the article is talking about :)
If an organization has the right customer focus, internal deadlines should be meaningless. Customer-focused orgs are generally better places to work overall because there is a shared sense of what is important.
Sprints also have the pleasant effect of forcing some coherence onto work.
In the Old Days, teams might build software like a layer-cake: All the lowest layer, then the next layer, then the next, and so on to the top. So at the beginning, we’d be building infrastructure based on projections (a fancy word for “wild-ass guesses”) of what the subsequent layers would need.
You can, in theory, do that in sprints, but with an emphasis on delivering “working software,” sprints would help devs and stakeholders pick very small end-to-end increments and build whatever was needed to make them work.
This kept everyone focus on work that was known to be needed, and since you were building a complete increment, the team would be building the infrastructure at the same time it was designing and building the functionality relying on the infrastructure.
This kind of thing has its own failure modes, of course, but it eliminated a number of catastrophic project failure modes without even getting into the value of delivering working software sooner and revising priorities based on feedback.
When management doesn’t trust devs, they micromanage. Often on things they’re way out of their depth on.
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.
Having a steady stream of deliverables and seeing that the devs can deliver on their promises, enables management to shift from control to guidance. That's not to say that it always happens, but I've seen it work.
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.
Define "trust". As an industry I think we often talk about the wrong things here. People look at this from the point of view of controlling IT & developers (controlling costs, deadlines, functionality, etc.) when really everyone should be looking at it instead from the point of view of maximising value to the business. That's what Agile is really all about - it should really be about trusting that people will make good decisions based on the currently available info (which will likely be different than when you started the project), do good experiments, and find good compromises. This is especially true if unforeseen delays to a team's work has a knock-on effect on other people (which a good manager will try hard to decouple and avoid, deliver incrementally to lower the risk, or at least include healthy contingency for).
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.
but it is very possible that you can create 'something' in 2 weeks vs. 'nothing' in 6 months.
and in most cases, 'something' * 12 > 'nothing'.
(although that 'something' might not be very changeable, or complete, or 'good')
and thus agile, getting things done with people that haven't done things before.
(not meant to be snarky. long design iterations require experience in the problem domain. now days, no-one has experience. or the problem domain is new).
Scrum is for when you have a central dev team in a company that's shared between multiple groups.
Once every sprint, you get all the managers in a room and let them fight it out. The result is a list of features that will be in the sprint. Everyone more or less gets their turn, depending on how powerful they are and whether something is legitimately urgent. Even if something is urgent, they can probably wait two weeks if they don't get it in this sprint. The dev team gets to work on something without interruptions for two weeks. The alternative is having everyone pushing around the devs, continuously changing requirements, overloaded devs, and general chaos.
The critical factor there isn't the sprint, it's the product owner. As long as the PO has the power to prioritise work, and as long as they are the only gateway for getting work into the team, chaos (from this direction, anyway) is minimised.
PO or scrum master as gateway for new work is sort of misguided malpractice that continues the insulation of developers. It may work if PO or scrum master has a clue, "lead" by asking/helping the team, but often in practice they are not technical themselves or external to the team. Having stakeholders fighting for priority and say, builds up helluva toxic environment that trickles down as well.
There's a perfectly healthy middle ground where POs are the gateway to new tasks but don't isolate the developers from the rest of the organization, nor disregard developer input.
And since we're talking about Scrum, PO and Developers (traditionally) supposed to sit together with stakeholders for Review meetings, gather feedback from them and provide input on the next tasks.
What works depends heavily on the circumstances and the team (people first). What is to be accomplished: software delivery, operational quality and/or user/customer interactions? Are the responsibility boundaries clear or not? When overall structure is clearer, it is more straightforward to decide who are the best decisionmakers for the team..
What works for one team, might not for another. It's a good idea to have semi-stable teams as there is significant overhead creating temporary teams and disbanding them.
When there's no true need of urgency or the deadlines are outright fake, kanban and maturity may make a good alternative to scrum/sprints. It may even allow for some flexibility how to allocate people and borrow temporarily from other teams. You don't want teams to silo down, which they do the minute they are formed to start healing the wounds. Teams will need clear responsibility boundaries to be able to make effective decisions, while also granted the slack, incentives and psychological safe learning environment that fuel the necessary and logically next steps.
> If the focus and discussion is regularly on short term deadlines, then the developers are not driving the process, the managers are. It means that sprints are seen as a management methodology and not a development methodology. And then everyone has a hard time.
Right. This is the thing that's nearly impossible to achieve in most places and why so many people hate Agile: because they're dealing with "imposed agile" where the managers are driving the process.
Yep, the article argues that "locking sprints is a terrible process" because you're either going over or under the mark set upfront. As if those are the only options.
The idea of locking sprints was a reaction against the problem of going _sideways_ , i.e. "changing priorities without notice" and requests for unplanned work to be done "now" without any thought of the effects.
Exploration of the solar system could be the greatest human endeavour of the next hundred or thousand years. Both manned and unmanned missions will be needed.
North American plugs also only go in one way, unless they are unpolarised, and pretty much all modern appliances have polarised plugs. The only stuff that doesn't are stuff like cell phone chargers, which is actually great, because sometimes it's more convenient to have it pointing the other way.
It is an increasing problem. I've defaulted to never answering numbers I don't have saved unless I expect a call. If it's important they should leave a voicemail. I wanna say a few years ago it wasn't this bad, then I realized I had missed a lot of spam calls cause I had my number behind Google Voice (free with Sprint) and now it is just ridiculous.
Also idk about other states, but in FL everything is public record, so after I bought my house I've gotten spam letters and calls like crazy.
This year I've been getting three types of spam calls (in Australia):
1. Spam call from new 03 8xxx xxxx range, I was sure these were VoIP numbers handed out by MyNetFone but haven't been able to prove anything. I can't remember what the content of the call was
2. International spam call from Mozambique (?). The call never connects if I pick up.
3. Private number, recorded voice in Mandarin. I think this is a tax scam.
I'm sure I'd seen some changes in the laws regarding caller ID this year, but I can't find it.
In Denmark, phone sales to consumers are generally illegal though strangely insurance and newspapers are excluded.
There's a national "do not call" list you can sign up to as well. This is amusing called the "Robinson List", presumably after Robinson Crusoe. The same concept is used in a dozen other countries.
I guess the penalties are severe enough that it generally only very shady people call, such as those pretending to be from Microsoft and calling to fix your computer.
It's also illegal in the USA, and we have our own national do not call list. The problem is the spammers are mostly using spoofed numbers (I get calls from my own phone number quite often) and are not actually physically located in the USA. It's difficult to prosecute some call-center warehouse located in Asia.
Rather off-topic, I was surprised by how readable this was to someone who doesn't speak a lick of Danish (me):
> Robinsonlisten er opkaldt efter Robinson Crusoe, som er en fiktiv person, der optræder i romanen Robinson Crusoe af Daniel Defoe. Han strander på en øde ø og lever isoleret.
EDIT: Just FYI this is a clip from a Norwegian comedy program. Danish and Norwegian have very similar written languages but sound very different when spoken. In reality with some practice Danes, Swedes and Norwegians can speak together and understand one another.
It's primarily an American problem, but I've seen in the last year or two an uptick in certain kinds of Spammy activity to my Australian mobile number.
The most prominent type, and have appeared in the last two years are the one-ring-only calls from some foreign country. They're trying to get you to call back to some premium-rate number.
The second are SMS based random spam. Just an hour ago I got spam from "JbHiFi" (even though it's not them, I've never given JB my number) with phishing/spam "you won a contest". I also get random SMS spam from other sources.
Then again, if you have any kind of landline in a regional area you're going to get a ton of fake NBN/Telstra/ATO/etc scammers.
The downside of inventing it is the US has a massive amount of legacy in telephony that few other nations have to deal with. That opens up tremendous opportunities to break the system. But, hey, we get +1 as our international code, so there's that.
The scenarios are usually less about creating realism, and more about crafting interesting combat puzzles.
“The Last Of Us” does a great job imo. Each fight offers different strategies and paths. And the enemies are usually there for a reason with some explanation in the AI interactions.
Then as a user, I can inspect what apps are sending and how frequently. I should be able to block requests or set myself as anonymous. Or allow apps for certain amounts of time etc.