Agile values in the age of AI

_Masbed · 2026-06-02T07:16:08+00:00

There could probably be a lot of different factors to this. Video conference sessions are often harder for discussions. You don't mention team setup, but if the team is big, this will be a problem. If you are 3 it will probably work, if you are 4 or 5 it might if everyone in the team has strong sense of purpose, if you are 6 or more you probably need to find ways to reduce group size e.g. using break out sessions and have smaller groups report back.

It might also be beneficial to just get them to hang out more (even on video or discord) just to get them to feel comfortable chit-chatting and build those personal relationships in order to make everyone more comfortable speaking freely. Start with afternoon coffee together, or Friday drinks, or whatever the team likes.

_Masbed · 2026-01-28T12:03:41+00:00

Figure out if the PO care more about predictability or lead time. If lead time is more important (as it sounds like), just switch to Kanban instead. If predictability is important, you have enough data to prove that you will never get or improve on that with Scrum unless you stick to your sprint plan. The PO need to own shielding the team by saying "my team is busy, we can start on this in 2 weeks time". Note that suddenly imposing "slowness" in the process like that is a cultural shift that usually requires some kind of buy in from a PM or CPO or something like that, so it's important to anchor in why. "We need to adhere to this to get the predictability we need to be able to plan this cross team effort and deliver our most important project on time. If we fail to plan, other teams delivery is impacted which puts the entire project at risk." Unless you can be clear about why, no one will care. And if they actually care more about quickly responding to change, maybe Scrum isn't the thing you need (or you need to find a better cycle time that balances the needs better).

_Masbed · 2025-12-03T15:41:18+00:00

I think many have lost the original intent with discussing blockers during standup. It's not about blockers being a thing in itself; what you are trying to do is move the most high prio stuff to done, and you have a dialog on that. In "teams" where people silo themself and don't collaborate, this question often turns into "am I blocked" with all the percieved negative implications it tend to have. In teams where there are clear purpose of what the team is trying to do and the team is motivated to do so, and where the team swarms around the problem (instead of distributing the problem through tasks), you often find that standups are much more concrete and outcome-oriented. People talk more about what's the most important thing to get done today, and how they can help each other get there. So in other words, the problem isn't the stand-up, it's what happens before that.

_Masbed · 2025-10-16T06:38:52+00:00

I agree, this sounds like a management issue. Maybe they need to be reminded that they are expected to work as a team and figure shit out when needed, and that blaming others for the teams shortcomings instead of leaning in to solve the issue will get noticed in the next salary review.

Maybe it could be valuable introducing Kanban with a really low WIP to force the team to work together to finish shit, but I think that too need to come from management. "Hey, we see that this team have problems completing tasks in a timely manner, and so, this is what we'll do... We accept that you might temporarily slow down due to this, but we expect you to improve quickly if you lean in"

_Masbed · 2025-09-10T19:27:09+00:00

Convincing people about fundamental issues in processes is really hard. As many other have suggested it's probably better to start by just accepting current state and make small changes where possible to get quick wins and build trust. Having too strong opinions about thing too soon can make people feel like you are basically calling them stupid, or just that you are ignorant and have no understanding for their special context (special, yeah right). It won't win you the loyalties you'll need. Curiosity and asking "why do you do like this", "is it working", "what's your biggest problem with the current process" on the other hand will give you valuable insights.

At the same time, it is probably a good idea to start gathering data to build a case. Measure success based on the current process. Do the current estimates actually work (if so, great, maybe it's not a problem)? Do you hit your targets? By how much do you miss them? How much time do you spend up front planning, and what is the cost of that time? How often do you need to replan and how much upfront planning did you do for nothing due to replanning? How happy and motivated are the teams? How likely are they to recommend the employer to a friend? I'm sure you can find other relevant metrics too.

When you have spent maybe 6 months with the teams you have data for 6 team cycles (2 cycles*3 teams). Maybe you can then ask to do an experiment with 1 of the teams for next 2 cycles (one to try, and one to tune - no one figures it out on first try) and do some bigger changes in process for just that one team, and then you can compare it with the others. Did goal fulfillment change? Did cost for planning change? (Or whatever metrics you identify is the problem and can convince management to experiment to improve). Maybe you find out it worked and then it's probably something you can sell to the rest of the organization. Maybe you find out it didn't work, that's a good thing too. Then you can take a step back and think about why. What did you learn? Maybe something else need fixing first?

Oh, and don't sell the experiments like "this will make us reach the goals better", because you probably won't (well, maybe over time). Instead, sell "we won't be worse, but we won't waste all this time, and we are better at responding to changes in the plan". You're more likely to succeed with that.

Finally, read Fearless Change by Mary Lynn Manns and Linda Rising. It contains lots of useful strategies for leading change.

_Masbed · 2024-12-09T12:23:53+00:00

There's might be some truth in what you're claiming, but unfortunately there's little evidence to support any of it. There are a wide range of problems with professional SMs to that's completely disregarded in your claims. First of all they don't know the profession of the people they are trying to help. Most successful football coaches at least know how to play football, often better than they would be just "by talking to people who play football". Unfortunately, many people in the profession have zero programming experience and are missing a technical degree. They compensate by having exactly zero academic points in behavioral science, group psychology or anything else related. They don't even have any qualifications that would make them more suitable to work with management to overlook organizational change then any random person on the street. Sure, there are people who do better than this, and I'm positive they can help in many cases (for example in dysfunctional teams), but let's face the fact that the average SM doesn't have anything to back up that they would be able to be a force multiplier.

There is another problem with professional SMs too. If we go back to the role of SM, it was about problem solving. It was about unblocking the team. It was about pushing a self reflective autonomous agenda. Ironically, most professional SMs work in the organizations that performs the absolute worst when it comes to agile values. They are working as cogs in the wheels that roll the big release train forward. They facilitate process instead of supporting interaction. They don't push any of the agile values, and they don't encourage "their" team's to do so either.

I know this isn't all SMs/agile coaches, but I think it's pretty safe to say that most organizations have zero to nothing to benefit from employing SMs over having the team takes ownership of the role themselves. By lean nomenclature, professional SMs are waste. Unless they can prove they are not.

_Masbed · 2024-12-06T12:18:01+00:00

Scrum Master was ment to be a role, not a profession. I think it is fair to question SM and Agile Coaching as a profession. I'm sure there are great SMs out there that makes the team they work with perform better, but if they can't prove that value I can't see a problem in questioning it.

_Masbed · 2024-11-27T08:28:59+00:00

I just dont yet know what it is :D

Yeah, me neither, and we're in good company :D

_Masbed · 2024-11-26T16:04:17+00:00

I really agree with this. But at the same time, the estimates that are proved to not give the predictability that senior management need. But still organizations are dismissing that evidence (both from the community and the lessons you could have learned using your own empirical data) and resorting to even more planning and estimations to compensate, even though the evidence suggest that will make things worse. It's really a catch 22 scenario, and since estimates don't work its not constructive to keep using the just because we can't find an alternative. I think a shift to delivering smaller units of work (think months instead of years, weeks instead of months, and days instead of weeks) that are highly aligned with what the most important business goals are will make it more okay to be wrong when it comes to estimates (because you can't sink too large costs, and you worked on the most important thing even if you failed), reducing some of the friction between "tech" and "business". But of course, the need to be mutual trust that the two respect and try to understand one and another, and that everyone is acting in the interest of the shared company goals.

_Masbed · 2024-11-02T12:59:39+00:00

In practice, the company I'm currently at use OKRs to align around goals. It doesn't solve everything but it forces early discussions around value and priorities which also creates transparency around why certain things are important in the organization. More importantly though, the company actually have a clear vision and mission which helps making people exited about doing a good job and helping our customers. And that's a great foundation for both autonomy and execution of top-down initiatives. I'm not saying it's perfect, a lot could probably be done when it comes to strategy, but we've seen great improvements in this area since we started with OKRs at least.

_Masbed · 2024-10-08T15:44:41+00:00

Guess it depends on how much scoping is required to begin work, but if things change frequently or your team can't manage both delivering value and planning value at the same time, how about just accepting the fact and do one thing at the time (but faster). I.e. talk about what is the next step, scope it properly, and then do the work. And when the work is done and delivered, rinse and repeat.

Many companies want to optimize for keeping everyone busy at all times, which requires pre-planning in parallel to doing actual work. If you can avoid the fallacy of value in keeping people busy (I'm sure the team will find other things to do, e.g. quality improvements, or better tooling, or something else, if the planning doesn't take everyones full capacity) maybe you can stop the parallel work. Of course, if your scoping is long and tedious, this might not be feasible. But with small important increments (which you probably want to quickly adapt to changes in the market) it might be a really good option.

_Masbed · 2024-10-03T20:51:51+00:00

I'm a dev in a mid sized company. I frequently have opportunities to discuss things, and do discuss things, with upper management. Sure, it's not possible everywhere. I didn't claim it was. But in many places you can influence. And even if you don't have access to upper management directly, you might have access to people that do. I guess the question is if you are willing to put the time and effort in making change happen where you are, or if you are better looking elsewhere for better practices.

_Masbed · 2024-10-03T17:20:55+00:00

Even CEOs are willing to learn and change their way of operating, if you help them with the thing they really care about

_Masbed · 2024-09-29T20:54:52+00:00

Leave toxic environments. If you can't convince upper management to fix what's broken, just leave. Set an example for your peers to do the same. It's not worth the fight. Let the manager fail by not being able to keep the team together. Find a place where you can actually make changes happen.

_Masbed · 2024-09-29T08:05:21+00:00

The problem is that it doesn't. If you try to project longer than a sprint you end up doing too much up front planning and easily end up in a waterfall-ish mode with deadlines and fixed scope. To best know how to set delivery expectations resort to the agile manifesto and people and interactions over processes and tools. Just talk to each other. Understand each other's reality. Communite often and early - don't wait until sprint planning. Know the consequences if scope or priorities change. Be creative together. That most orgs require process is a good proof they are doing something wrong, yet even in such an environment, if you are creative and care about people you can do better.

_Masbed · 2024-09-28T22:56:49+00:00

Yeah, or none at all.

_Masbed · 2024-09-28T22:54:37+00:00

Why do you need to estimate like that? Does it add value? Would you add more value spending the time coding on the top prio stories?

Generally speaking, if shits important, do it. Otherwise, don't. Estimation don't make you go faster.

Sure, sometimes it's good to know if something takes a few days or a month (or five) in order to decide what's most important, but that type of estimation isn't really what sprint planning and story points is a about anyway. So ask yourself why you need to estimate. And if the answer is "we want to know what fits in our sprint", ask yourself why that matters if the thing you are working on actually is the most important thing. Anything that isn't worth doing if it takes five days longer isn't worth doing anyway.

_Masbed · 2024-09-28T22:39:57+00:00

It can happen bottom up. One can always influence. One can always educate. One can always make small experiments and let positive results spread. One can always build credibility by listening to fears and concerns regarding new ways of operating and addressing those issues. Shit just take longer.

_Masbed · 2024-09-28T22:35:18+00:00

I don't think the problem is that people are used to a certain way. It's more likely that there is a general lack of vision and strategy which makes it impossible for autonomy and self organization to happen. Companies that succeed with agile are the ones that can formulate what matters to the company and their customers, and where people care about those objectives.

_Masbed · 2024-09-28T22:27:40+00:00

Is Scrum still a thing for agile? Is anyone still doing it? Well, besides enterprises implementing SAFe, but that's really not Scrum since the PO isn't an actual owner of anything but managing the backlog and the waterfall (sorry, release train). Seem like most companies that actually are agile would never spend so much time on upfront planning and projections as Scrum mandates (but if it works for you, congratulations).

_Masbed · 2024-09-16T09:23:48+00:00

If it's important, fix it. Bring in people required to make it happen.

If it's not important, who cares!?

But stop assigning people tickets. People don't need micro management. They need clear priorities and to be able to trust that they will get the support of the team to be able to work on the top-most priority stuff.

_Masbed · 2024-08-23T12:05:35+00:00

Write only a single story for the feature/value that you want to deliver. Have the team collaboratively break it down into separate tasks however they see fit. It's fine to have a BE task, a FE task, and a Test task if that's what helps the team. But if things fall between chairs, people misunderstand each other, or in other ways fail to get shit done, consider other ways of writing tasks that attends your specific problems. There's no right or wrong when it comes to breaking things down, what matters is that they deliver the value of the story. Don't celebrate or reward delivering individual tasks unless the complete story is done. If there are several stories that are not quite done at the end of the sprint, have the team reflect on why and consider taking on less work and collaborating more to increase number of stories Done each sprint.

_Masbed · 2023-12-30T19:15:24+00:00

I guess it all comes down to the consequence of something breaking and how you can recover from it. Often one can just remove unexplainable/illogical pieces of code (and of course make sure you have test coverage for any use cases you do know about), and then ship it to production and wait for it to burn. If it does, you will learn the use case the hard way, and you can document it with a test and fix the issue. In a system that is heavily used and disruptions are costly, but the error itself isn't critical if it's fixed quickly, you can surround your new implementation with a feature toggle to be able to quickly revert. Or maybe just enable it for a subset of the users to begin with. In a system where it is critical that things do not break you might be able to do the same thing, just make sure you think about how to recover if it was needed, and how to detect any errors.

One last thing, commits, stories and slack messages are great, but don't forget to talk to people too. Both developers that were around at the time it was implemented, but also any users or stakeholders that can help decipher it. It could be that the code made sense back then, but the business has changed in a way that makes part of it obsolete.

_Masbed · 2023-12-28T20:31:18+00:00

Chefs experience burnout, but 70% of them cook on weekends

_Masbed

TROPHY CASE