#142 | Beyond the Agile Manifesto: Debunking Myths and Embracing Adaptability with Maarten Dalmijn

Is your understanding of agile stuck in the past? Tune in to our latest Agile Ideas episode, where we chat with Maarten Dalmijn from the Netherlands, an agile, scrum, and product management maestro with a fascinating background that even includes an early appearance in an Oscar-winning film! We tackle the persistent myths around agile, revealing how its principles predate the Agile Manifesto and emphasizing the critical role of adaptability. Martin shares his valuable insights on why a rigid adherence to the manifesto can hinder progress and how agile practices have matured over the years.

Transitioning to agile in established companies often feels like trying to fit a square peg in a round hole, but it doesn't have to be that way. Maarten and I discuss the pitfalls of simply layering agile on top of existing structures and offer strategies for addressing specific client problems using their language. We also cover the inspiration behind creating content, the power of personal interests, and how to maintain motivation in the face of negative feedback. It's a heartfelt segment that underscores the importance of staying true to your passions.

Managing agile projects in large banks can be a herculean task, but Maarten provides compelling strategies to navigate these challenges effectively. From flexible sprint approaches to meaningful progress tracking, he critiques the overemphasis on velocity and story points, advocating for more practical metrics. We also explore the concept of "feature factories" and the importance of aligning business goals with product management efforts. Wrapping up, we share best practices for adaptive product roadmaps and discuss the current trends in agile-based methodologies, emphasizing the need for flexibility and practical governance in large organizations.

In this episode we discuss: 

• 0:00 Agile Misconceptions and Adaptiveness
• 9:23 Writing and Agile Mindset
• 21:11 Flexible Sprint Approach and Progress Tracking
• 24:40 Understanding Story Points and Feature Factories
• 29:54 Product Management and Business Alignment
• 41:31 Effective Product Roadmapping Strategies
• 53:10 Navigating Agile Trends and Adaptiveness
• And more...

You can reach Maarten Dalmijn here: 

https://www.linkedin.com/in/maarten-dalmijn/ or https://mdalmijn.com

His book: https://www.amazon.com/Driving-Value-Sprint-Goals-Addison-Wesley/dp/0137381921/ref=sr_1_1?crid=3LI7ZR4BTAFI2&keywords=driving+value+with+sprint+goals&qid=1689188652&sprefix=driving+value+with+sprint%2Caps%2C161&sr=8-1 

To learn more about The PMO Playbook I've created - visit https://thepmoplaybook.substack.com/ 

This podcast is sponsored by Agile Management Office (www.agilemanagementoffice.com) providing high-impact delivery execution in an agile era for scaling businesses. 

Thank you for listening to this podcast. We welcome any feedback. www.agilemanagementoffice.com/contact  

Make sure you subscribe to our newsletter to receive access to special events, checklists, and blogs that are not available everywhere. www.agilemanagementoffice.com/subscribe  

You can also find us on most social media channels by sea

Transcript

Agile Misconceptions and Adaptiveness

Fatimah Abbouchi 0:00

You're listening to Agile Ideas , the podcast hosted by Fatima Rabouchi . For anyone listening out there not having a good day , please know there is help out there . Hi everyone and welcome back to another episode of Agile Ideas . I'm Fatima , ceo at Agile Management Office , mental Health Ambassador and your host . Before we get into today's podcast and talk about today's podcast guests , I just wanted to remind you that , in case you're not already aware , I have launched the PMO Playbook newsletter . Details and access to the PMO Playbook will be mentioned in the show notes , but the PMO Playbook was something that I decided to put together and curate specific content and how-tos in and around projects in PMO . For example , some of the plays that I've included include how to set up and run a pipeline management process the most important process and most requested by all clients I've worked with over the last eight years and how to set up and manage a dependency management process also another challenge area for a lot of companies . In this PMO Playbook newsletter is curated content , very specific , detailed how-tos and that will be able to provide you insights that you can literally copy and paste and use in your day-to-day , as well as other curated content and insights that I'll continue to share . You can find details about it in the show notes .

Fatimah Abbouchi 1:26

Now on to today's guest . So today's guest , all the way from the Netherlands , is Martin Dolmite . He is someone who helps teams to beat the feature factory all over the world , and he'll tell us a little bit more about what that is . Surely Millions of practitioners have read his best practice articles on agile , scrum and product management , and he's the author of the Amazon bestseller Driving Value with Sprint Goals in the MyCode series . Martin is a frequent speaker at Fortune 500 companies , government organizations and international industry conferences . He's worked with many award-winning startups and scale-ups as well , so please join me in welcoming Martin to the show . Martin , thank you for joining us .

Maarten Dalmijn 2:13

Super happy to be here . Thanks for having me .

Fatimah Abbouchi 2:16

Your content , which we'll get into , is prolific and caught my attention . But before that , something else that caught my attention Apparently you were in an Oscar award winning movie . Tell us about that . That's correct .

Maarten Dalmijn 2:29

Well , I mean , I was super young , I was like two years old or something , but this is the way my mom tells the story , right , so you have to keep in mind it's my mom , so she probably makes it sound nice and nice . But basically there was some kind of ad in a Dutch newspaper that they were looking for babies for a second world war movie and I was selected out of hundreds of babies and and initially the idea was to just have a picture . Right , you know ? You know movies . They had these pictures of the family like a baby . I was just going to be for that , but apparently they like me so much this is how my mother tells me that they put me in the movie . So I'm actually there .

Maarten Dalmijn 3:07

It's only a few seconds , but yeah , I mean the movie is called the Anschlag , the Assault , and I'm like writing like something simple , like a tricycle or something . So yeah , it's pretty cool .

Fatimah Abbouchi 3:18

That is really cool and it's a great opening line if you're at a party . Great um opening line . If you're at a party , yeah , yeah , yeah , I mean who can say that ? Right , exactly you know what ? If you hit someone else , you probably add it to your linkedin buyer a school winning actor yeah , nowadays everybody puts I'm x , meta , x , x x mckinsey , even if they've been there for For three days .

Maarten Dalmijn 3:42

Yes , yes , my question is why are you an ex ?

Fatimah Abbouchi 3:46

That's what I want to know , oh goodness . Okay , now that we got that clarification out of the way , I'm happy to dive into all things related to many things , but one of which I want to kick off with what do you think is the biggest misconception when it comes to agile ?

Maarten Dalmijn 4:08

Yeah , do you think is the biggest misconception when it comes to agile ? Yeah , so it's . What's very interesting is , when you talk about agile , everybody starts talking about the agile manifesto . Right , and , and I I get it right .

Maarten Dalmijn 4:15

But yes uh , in my mind , agile is much older than the manifesto . I mean , it's it's kind of like uh , how do you say ? Of course they came together and they described kind of what their agile approaches had in common , so even it was already older than the manifesto . But the other part to it is the ideas that are in the manifesto basically responding to change over , following a plan as one of the elements . They are far older and don't have their roots in it , but they put the it stamp on it . They linked it to the world . So for me it's kind of like yeah , that's what makes one of the biggest misconceptions , in my opinion , to start talking about agile , you have to start with the agile manifesto . That that's what defines it like . Yeah , I'm curious what you're thinking I I 100% agree .

Fatimah Abbouchi 5:04

Unfortunately , there are many agile purists out there and with all the companies you know that I've come across , they tend to usually reference that and make that that that's the starting point , when it's not alternative view as well , in that , for me , even though Agile itself has become a lot more mainstream in the last eight to 10 years , I think the more popular , more popular I think Agile has always been about agility and adaptiveness , and that's what I think it is . And so , yes , there's definitely a reference to something that is really well known being the manifesto , and it's absolutely , you know , great to see those guiding principles in there . But it doesn't mean that we need to be so rigid that we're trying to adhere to everything in that , because that's not the gospel for absolutely everything that is Agile . It's evolved a lot since then . So , yeah , I agree with you and I do think that is a big misconception and really pushed by a lot of Agile purists .

Maarten Dalmijn 6:05

Yeah , and I get it right . It's very comforting that you have this , this like document you can point to . It's the truth . But yeah , I mean , as you said , adaptiveness , that that's the key thing , like I think that's the key and that's that's . I mean I uh , maybe I don't know if all the listeners believe in evolution , right , but that's evolution already . That's adaptation . Evolution is the blind watch watchmaker . Right , it doesn't look ahead . Uh , it cannot look ahead . What evolves is because it works and it doesn't understand why . And then , and that's kind of like agile as well , like we do what works and we discover it after the fact , and but we have one big advantage we can also predict and plan , we can also look ahead with our brains . So that that's the big advantage . But in the end , it's about adaptation . Yes , I agree .

Fatimah Abbouchi 6:50

A hundred percent , and I think you know you .

Fatimah Abbouchi 6:51

You know the key thing as well is that so many people are spending so many , so much time arguing and debating the what , instead of just focusing on how they apply the principles and the the . There's so many frameworks out there and methods based on agile , and there's so much good out there and also some not so good . So it's like picking and adapting those different things to suit you , based on your maturity , your environment , your organization , as opposed to rigidly fixating um . So I think that is definitely important . And the other one that I wanted to see if you probably hear a lot about is um , there is a as opposed to rigidly fixating , so I think that is definitely important . And the other one that I wanted to see if you probably hear a lot about is there is a lot of people that will say Agile is only relevant for software development lifecycle , it's only related to IT , and I find that one really difficult to accept because it's not true . But do you hear that a lot ? Do you think that that's also a misconception ?

Maarten Dalmijn 7:43

Yeah , I mean I would agree , hear that a lot . Do you think that that's also a misconception ? Yeah , I mean , I would agree . I think one of the key things though , if you look at the manifesto was kind of phrased is software development context . So if you take that very literal and say , hey , like it's meant , it's a manifesto for software development .

Maarten Dalmijn 7:55

But I think the the basic ideas are applicable to other domains as well . I think the main , the main thing is if you can make a really good plan and you can execute it , then there are going to be no surprises . You don't need to adapt , you can think all the steps ahead and you're not going to make mistakes . You don't need agile , and I think that's the key thing . So there's this famous saying from the military I don't want to glorify warfare in any way no plan survives contact with the enemy . If that's your situation , you need agile , right , and that's the main thing . And yeah , I don't think it's helpful to say agile is only for software development . The ideas are the same and , for example , if you talk about the military concepts like Auftragstaktik or mission control , I mean they're very closely related to Agile because they're trying to solve exactly the same problem and yes , they're called differently , but in the end they're trying to solve the same kinds of problems , in my opinion .

Fatimah Abbouchi 8:53

And at least there's agreement on the problems that we're trying to solve . That's the key starting with an understanding of what it is that you're trying to do , whether it's deliver value , which we'll get into , or deliver value , which we will get into , or solving a particular problem . But I think one of the big problems happening at the moment is appearing to be a lack of understanding for the C-suite and I know you do training with the C-suite from introduction to Agile . What do you think is the biggest challenge for the C-suite to jump on board and actually really be able to support Agile initiatives ?

Writing and Agile Mindset

Maarten Dalmijn 9:23

Yeah , I think one of the big challenges is that there's a lot of talk about . I think if they've heard about agile before , right , everybody has heard about it before and I think one of the main challenges is they've probably heard about it in a way where somebody just started waving I mean , I called it agile splating right , waving the agile manifesto in their face and why it's important , and I think that's totally the wrong starting points . Like you should start with where they are , what they care about , what are they challenges , and then you should talk about okay , so this is what we could do to help you resolve these obstacles , or speak their language , and in the end , I rarely talk about agile . I don't drop the word agile because there's no need to , as long as I can help them solve their problems . Why do they need to know that ?

Maarten Dalmijn 10:09

it's related to the agile For me , that's not important because , at the end of the day , we're talking about adaptation and course correcting and all these things , and everybody knows these things . You don't need to call it agile , I mean , everybody knows when they're like , for example , when you learn skiing , right , there's an element of thinking ahead and but you're trying and falling . So we all naturally understand these concepts to some extent . Yeah , so I I think that's the key thing , like start with their problems and speak in terms that they care about and they can understand . And yeah , I'm curious what , what , what , what , what , what ? What is your approach ?

Fatimah Abbouchi 10:44

maybe you have a different perspective no , no , I , I like that , um , I , I was thinking so a lot of times when we're sort of speaking to different clients and and the only the most common thing I hear , which again is literally the sentence I'm so sick of hearing that they want to go adjunct , they want to go faster , um , and for me , coming from the government , yeah it's .

Fatimah Abbouchi 11:03

It's . It's also so , so , um , so false . It doesn't actually make sense . And the reason it doesn't make sense is because a lot of these companies usually those that are well established , more so rather than you sort of start up , they've already got so much governance below and so much structure and rigidity , so then they go in and they apply agile on top , thinking that they're . So then they go in and they apply Agile on top , thinking that they're going to be able to go faster because they've restructured their team to be one of the , you know , top consulting models and whatever . They actually just complicate things a lot worse .

Fatimah Abbouchi 11:37

And I think you're right , by just talking and constantly bringing up Agile , for what Agile is is distracting us from doing the how , which is actually adapting , iterating , evolving , you know all that sort of stuff . So , yeah , I think we're aligned and that's definitely one of the reasons why I wanted to talk to you , because I can see that from your posts and I'm keen to understand , you know , seeing some of the collateral and the content you've been posting lately , which is quite entertaining . Where do you get your inspiration for some of these posts ?

Maarten Dalmijn 12:09

Yeah , so this may sound really weird , right , because I'm a product manager , but in the end I write about what interests me . If I'm excited by it , if I get energy from it , then I've got the I'm not a great writer , then I've got the best chance to make somebody feel the same excitement . That's my starting point . So , for example , yesterday I published a post because I was actually watching on YouTube . I was watching Edward Norton being interviewed at the University of Cambridge and it was just very fascinating because he was talking about Fight Club and how it's actually the same movie as the Graduates . I don't know if you're into movies .

Fatimah Abbouchi 12:42

I watched Fight Club , but I haven't watched the graduates oh , it's a good , very good movie .

Maarten Dalmijn 12:46

It's a romantic movie and it's actually , I think , from the 60s . I could be wrong , maybe , but but the interesting part is the graduate . You probably know the song , mrs Robinson . Like I don't remember the lyrics , but anyhow , the cool thing is in that movie . It's a romantic movie . I would . I've seen both . I never made the connection , but when Edward Norton said that was like ah and and , and I was kind of inspired and I wrote something . Yeah , about the movie Fight Club and the Graduate . I'm not going to spoil anything and that's that's . It's just something that happens like a spark , and that's how I do it . There's not one right way of doing it .

Fatimah Abbouchi 13:25

That's a really . That's a really , a really a good way of explaining it . I agree with you because , but one thing is you have to be open to listening , to looking , to hearing . So you know you're open to these ideas , which is good . That means you're not married to your ideas , you're open to other perspectives , which I think is really great . And correct me if I'm wrong , you started writing even though you were told . Was it one of your secondary school teachers that told you ?

Maarten Dalmijn 13:49

Yeah , yeah , yeah , it was my Dutch teacher and she said like you should never become a writer because basically you suck . And yeah , I was like thinking okay , but the thing is , I always loved writing so much that I didn't really care what anybody thought . I mean , who cares if it's shit or if I like it ? That that's the win already .

Fatimah Abbouchi 14:09

Exactly You're expressing yourself and , and remind me , you started writing because you were reviewing some tech gadgets that you were receiving and you were getting for free , and you decided to start writing .

Maarten Dalmijn 14:18

Yes , yes , like I don't know , 15 , 16 , something like that . Yeah , I was like oh , this is a way to get free stuff . I'm going to write .

Fatimah Abbouchi 14:26

Amazing and you know what you say . You raise a good point . I think there's a lot of fear sometimes and I'm sure there's people listening now that maybe watch this podcast or on YouTube or listen to it and probably think , oh , I want to do what you're doing and I want to write , and maybe a bit scared to take that first step .

Maarten Dalmijn 14:42

But correct me if I'm wrong , you're probably writing better now than you did when you were 15 because you've continuously iterated and practice and apply that agile principles by learning and and improving on the way yeah , I hope so , like I mean , it's so difficult to say right , but but I think my writing has improved a lot and still improving and yeah , but it doesn't even really matter , that's not why I do it , I just like it a lot . If I , if I wouldn't have nobody reading it , you know I would still enjoy it . It still is like , and sometimes it can be disappointing because you hope , right , that some people read it and find it interesting , and sometimes you just an article where you put a lot of effort in and nobody cares . Oh , that's okay . But I mean , how can I say ?

Maarten Dalmijn 15:25

I think that I wish more people would just do what they like ? I think that because , at the end of the day , you're a thief of your own time and what you get from it is joy . And of course , we all want to make money , right , but the joy , that's priceless and that's what nobody can take away .

Fatimah Abbouchi 15:41

Yeah , 100% . I love that . And , speaking of writing , so I know that you've written a book which is quite popular actually and got a lot of good reviews , so Driving Value with Sprint Goals . One of the things I read was that you missed all the timelines for the book except for the first two chapters . Can you tell us a little bit more about that and what's the book about in a bit more detail ?

Maarten Dalmijn 16:01

Yeah . So basically , when , when you write a book , you get a contract and I don't know if every publisher works the same way , but I assume they're probably all going to work pretty the same way . So they want timelines like so they want there's a timeline there for the first two draft chapters , for the full manuscript . And that's tough right , because you I've never written the book . How the hell do you forecast timelines ? So the other part of it which makes it tough is there's actually some clause in there that if you basically you're delayed , they can hire a ghostwriter to finish your book and pay that ghostwriter out of your future royalties .

Maarten Dalmijn 16:39

Oh , wow , okay , so it's not going to be your book and you're never going to make any money out of it . That's basically the worst case scenario if you're late and yeah . So you have this contract looming in your head . So what did I do ? I worked for a weekend . I finished like 20% and I said , okay , I can do it in six months . So I gave timelines , six months finished the whole thing . So what happened is the first two chapters I had done over a weekend . So that's the only timeline I hit . That was in the contract , because it was already done before I signed the contract , and all the other timelines I missed .

Maarten Dalmijn 17:10

But here's the key thing right , the publisher . I was regularly sending them chapters . They really liked what they were seeing . So I was actually telling them , hey , like I'm going to miss all the timelines . And they said don't worry about it as long as you're producing stuff and it's good . That's the key thing . I think it's more kind of like contracts . They always contain this language , as when everything goes to hell , they have an option , an out to recoup some of the money . But at the end of the day , they want to make money and the best chance is if I write the book . You know what I mean Because , yeah , I mean , if you find a ghost writer , they may be a better writer , but they might not write a better book because they don't have the same understanding . So , yeah , that's it in a nutshell .

Fatimah Abbouchi 17:50

So that's the risk that you know they have to take as well by bringing someone else in to finish your book . It sounds very similar to a Danish professor We've done a lot of work with Denmark and then one one of the Danish professors says he , literally with all of his books and research writing , leaves it to the last minute , and I always wondered why . But yeah , I think that kind of concept of what you just described is probably more familiar than maybe some people realise . Well , good on you for finishing the book . Tell us what's it about . I mean , obviously your title is a little bit clearer in terms of what it means . But what made you drive ? What drove you to write the book ? What was it about that topic that you felt would needed to get out into the world ?

Maarten Dalmijn 18:29

yeah , so the key thing I wanted to write about is , if you look at most scrum implementations or even agile implementation , well , they're very rigid .

Maarten Dalmijn 18:38

You know what I mean , and it's kind of like they try to follow a recipe , follow these steps , and then you're going steps and then you're going to be adaptive , then you're going to be agile . And I thought that , yeah , how do you say ? I thought that's one of the biggest problem in the agile world today , and I actually wrote a book which is about Scrum . But it isn't about Scrum . It is actually about how do you leverage goals to deliver more value . And it's really about how do you make your teams more adaptable , more flexible and do the right thing in the moment . And that's also why the subtitle is like Humble Plans , exceptional Results , because the basic idea is every step you take should help shape the way . So when you do the work , you discover what's going on . You can adapt . And that's the key thing .

Maarten Dalmijn 19:20

And what's interesting is , I rarely talk about Scrum . I rarely talk about Scrum Masters . You know what I mean or what the product owner does . I just really try to focus on okay , so you've got a team , they've got a mission , they are working towards a goal . How does that help ? Why is that important and why is it even crucial for an agile way of working ?

Maarten Dalmijn 19:40

And that's what my book is about . It could have just as well been called driving value with goals . You know what I mean . But yeah , and I just felt very passionate about it because , yeah , we get so distracted by all these events and people even mistakenly call them rituals and ceremonies but we get so distracted by all that stuff that we forget about focusing on what is the really the only thing that matters and that's kind of like , hey , this is the goal we're working towards . How do we get closer to that goal ? What's the next best step we can take ? And all those events and values are just a means to an end to help you do that better and that's why we should start the other way around .

Maarten Dalmijn 20:15

We should not start with all the events and do this , but this is the goal , and how do we get closer to that ? That's the key thing , and I think we get so distracted from that and that's why I felt compelled to write this book . I want I want to see more flexibility and adaptability and less rigidly like , hey , this is , this is what the scrum guide says or this is what the agile manifesto says , because , at the end of the day , we need to do the right thing at the right moment , and no book or recipe is going to tell you that .

Fatimah Abbouchi 20:42

No , because no one book anywhere in the world manifesto included can know your culture , your environment , the maturity , the past experience , the people , all of that stuff . So how can you possibly apply Even the best recipe books in the world the way I'd cook versus maybe yourself or my husband or a friend ? They're all going to be different outcomes , they're not going to look identical . So it's a guideline . Effectively . You know going to be different outcomes and they're not going to look identical , so , no , there's a guideline

Flexible Sprint Approach and Progress Tracking

Fatimah Abbouchi 21:11

. Effectively .

Fatimah Abbouchi 21:11

You know what's really interesting , one of the things I've seen in some of the large banks that we have here I've seen mainly in the banks , but I'm sure it happens elsewhere is , I find , you know , working in sort of the project management office space . Usually we , you know , the liaise with the scrum masters and the agile coaches . But I was observing for a period of time with one of our clients and I was just seeing the actual teams . Every sprint , every two-week sprint . They were running in two-week sprint , every two-week sprint . They would run out of time to deliver everything they said they were going to deliver in the goal and they would literally pick it up and they would move it to the next fortnight and they would just continuous , and they did that for like nine months . So what's your thoughts on that ? Um , and you know , is it , is it best practice not to be moving between sprints , or like . What's your thoughts on that approach ?

Maarten Dalmijn 21:53

well . What's interesting is , I think there are different schools of thought , but for me , agile is about being fluid and doing the right thing in the moment , and what I've observed very often is it's the final day of the sprint , somebody wants to work on something valuable and then they say no , you cannot pick that up because you're not going to complete it . To me , that's absurd . You're not doing the right thing at the right moment . I mean , it could be that there are other more useful things that you could do , like documentation . Please do that Right , but for me , I don't get that . I think you should always do the right thing at the right time , and if the right thing at the right time is a lot . So I'm much more in the camp of keeping the sprint flexible and carryovers don't really matter as long as you're making the most progress towards your goals . So that's the key thing . So let's say , you've got a sprint goal .

Maarten Dalmijn 22:40

I think one of the big problems is estimation right . Our estimates are always wrong . That's kind of the big problem . So what you don't want to do and this is what most scrum teams actually do is they start the sprint , they push in 10 tickets right or 10 user stories with an estimate . So the problem is , before starting the sprint , you lack understanding your estimates . It might be 10 story points , but in reality the whole batch of work maybe is 50 story points or 60 . So you're already doomed from the start .

Maarten Dalmijn 23:09

And that's why I think it's way more important that you keep your sprint flexible . You pull in work gradually , based on the reality , how much work it really is , and then every sprint you kind of have a feedback moment hey , how much progress that we make , that we make more or less progress , but it's actually about the actual work you've completed and not like the guests you pushed in at the beginning of the sprints . And that's why for me , it's really crucial carryovers . I couldn't care less , as long as we're making the most progress towards your sprint goal , as long as we have good cycle time . You know what I mean , that , what matters , and yeah , um , so I that's I mean that can . Sprint should be flexible and every two weeks you just inspect and adapt . You see how you're doing . And , yeah , you're sometimes going to get sidetracked , there's going to be a production issue and all these other things , but that's okay , right , but you keep your eyes on the price , which is a sprint pool for the goal and you also don't want to wait to the end of them .

Fatimah Abbouchi 24:02

In most of the time I find that you know their sprints finished on a wednesday . You don't want to wait till the day before the end of the sprint to then call out that you're going to have challenges in delivering whatever it is that you said you're going to deliver and I just think it's a bit of a lack of understanding in relation to what was in the sprint . And you know you mentioned estimation and I know that you're very vocal about story points and you have a perspective on that . I've been in companies where they don't understand it so they completely just dismiss it , say it doesn't work , it's completely crap , and then they'll just go with , like T-shirt sizing , and then in others that are , you know , absolutely all over story points

Understanding Story Points and Feature Factories

Fatimah Abbouchi 24:40

. So what side of story points to you works and why is it so misunderstood ?

Maarten Dalmijn 24:45

Yeah , yeah , I mean , story points are just incredibly complex , right ? You just ask someone how do you define a story point ? You get all kinds of different answers , and I think so for me it's . I'm in the Mike Cohen camp , right ? He just says story points are about effort , how much work it represents . You can story point bugs . Some people even say you cannot story . You can story point anything that represents work in my opinion , even say you cannot story you can storyboard anything .

Maarten Dalmijn 25:11

That represents work , in my opinion . So you've got risk , you've got complexity , you've got uncertainty . They all influence effort but they're not a lot , not enough . So you cannot say story points are equal to complexity , because sometimes you've got to do very simple stuff but it's a lot of work . So , um , I think story points can be useful . I think one of the main things is the team decides and it's for them and I think , the business . They should not worry about velocity because at the end of the day , if you read the history of velocity , it's based on ideal days .

Maarten Dalmijn 25:43

So how it started was a team , an XP team , with Ron Jeffries . They were using ideal days and the business didn't get it what you planned 30 days . So why didn't you finish those 30 ideal days ? And the business didn't get it what you planned 30 days . So why didn't you finish those 30 ideal days ? Well , because we've got other meetings and blah , blah , blah . So the business didn't get it . So what did Ron Jeffries do ? He was very smart . He just said we're going to multiply it by three and call it points . Then nobody knows the time it represents and then they'll get off our back . But yeah , so it was good intentions , right it was to confuse the business .

Maarten Dalmijn 26:15

Yes , to kind of like get the business off the back . But then people actually started weaponizing it and thinking wait , these are points . The sky is the limit .

Fatimah Abbouchi 26:23

We can achieve more points , exactly .

Maarten Dalmijn 26:24

And that's where it went wrong , because that's kind of as stupid as saying hey , the team has 100 ideal days , right , they have a total like potentially they can do 100 days of work in the sprint . I'm just making up a number and then now we're saying they can do 200 ideal days . That's absurd , right , but that's what we're doing in velocity . That's where it kind of went wrong so I think the estimation approach really doesn't matter .

Maarten Dalmijn 26:44

You can use ideal days , you can use story points , yeah , you can do simulations , no estimates . I think it all doesn't really matter . I think the key thing is you should tell the business what are you working on ? When do you roughly expect it to be done ? Yes whether it's generated using yummy , gummy bears or story points , it doesn't matter like , and I think that's . That's where it goes wrong . Like I , I don't care about the estimation approach , and I think the business shouldn't care either .

Fatimah Abbouchi 27:15

They care about the forecasts and yeah well , they , they , they care about how their you know their money is being spent , if they're , if they're funding . You know your persistent team and they're obviously investing in develop . You know investing , um , whether it's a product owner in the team is a part of developing out . Whatever it is they're developing and they're putting in SME time and expertise and all that sort of stuff . They're going to care about the outcome and so they have to understand how you're working so that they can fit into that . Otherwise it's like chalk and cheese .

Maarten Dalmijn 27:47

Yeah , no , you're right , they have to understand . But I think one of the big mistakes is , in the end , right . Software development needs exploration and innovation .

Maarten Dalmijn 28:00

It's not assembly line work and and and that's one of the the big problems I see is there's so much pressure on teams to deliver stuff yeah and I mean , if you see these teams that are just focused on delivering , they don't talk to customers , they don't validate stuff because everybody's just putting pressure on them to deliver things , to deliver features , and I think that's one of the biggest mistakes . Maybe you get a higher ROI in terms of feature delivery , but the biggest mistake is building a feature that isn't used , that is so expensive . It's a parasite . It's going to get support tickets . You're going to get questions from sales . Every future feature is going to be slower because you're building on a bigger code base . It's just setting your up for failure and I think that's the biggest mistake I see . Like , when you focus on squeezing like all the story points out of the team , you're just going to get more features , and it's just as stupid as my book , right ? Imagine I would have focused on writing as many pages as possible . That's not what it's about .

Fatimah Abbouchi 28:53

No , absolutely . And you know , one of the things that you mentioned is like you can sit there and spend all this , all your resource , time and effort on building features . But not only is what the development team is developing matters , it's also how you go to market , how you do the marketing , how you do the marketing , how you do the sales , how you integrate operations , the governors , all of that stuff . So who cares ? If the development team delivers all the features , If it's not integrated , it's not sold properly , it's not , you know , all of that sort of embedded in the company , then you've just wasted and you're going to have to go back and redo it .

Fatimah Abbouchi 29:26

And that was a prominent problem with a home loan program that I was part of in one of the banks , where they I think you call it the feature factory . They were obsessed with features and they would break down the features to such a minute level of detail so they can acknowledge that they've done , you know , 50 , 100 every quarter , whatever it might've been . So how do you help teams beat the feature factory and tell me a bit more about what the feature factory is ? Yeah , so how do you help teams beat the feature factory and tell me a bit more about what the feature factory is .

Product Management and Business Alignment

Maarten Dalmijn 29:54

Yeah . So feature factory I think it's a concept coined and popularized by John Cutler and I'm basically it's companies that just obsessively focus on shipping features , and what I always say , like delivering a feature , it's like telling a joke , it doesn't matter unless it makes people laugh . Right , it needs to . So it's not about the feature , it's about what the feature makes possible . Yes , and I've worked at a startup and I've seen this problem firsthand . So so basically , uh , they were building a sas product and it was configurable , and if you would go to the configuration menu , there were like 200 checks boxes with settings that the customer couldn't see , but 200 , and some of them you were not allowed to turn on at the same time . So this is the feature factory , right , like you just have a product , it can do everything . It's a swiss army knife , uh , but yeah , you're cannibalizing your own product because , basically , you cannot please all kind , different kinds of customers because they've got very different needs . So , in the end , in the feature factory , the idea is the more features you deliver , the more value you deliver , which is , just like I said , it's just as nonsensical as the more words you write , the better the book is . Actually . What you want to do is deliver as little features as possible you know and make as much as a difference as possible . And and because the less features you have , the smaller your code base you know the lower the infrastructure costs , the quicker it will be to add new features .

Maarten Dalmijn 31:20

But I think the hard part is figuring out what are the features that are going to make a difference , and but that that's where our effort should be , because writing code is a very slow and expensive way to find out that you're wrong . You know , so you should . Ideally , you should do cheap things , you should actually make prototypes and you should talk to customers and really understand what are you trying to achieve . Could you show me how you're doing this today ? And yeah , what very often happens in these feature factories ? There's just somebody from sales that says , hey , we need a google calendar integration . And then what happens in these companies ? Okay , we're . Hey , we need a google calendar integration . And then what happens to these companies ? Okay , we're going to build a google calendar integration , yeah , and then they build a google calendar integration and then nobody uses it because nobody knows why , why we even built it in the first place and that's a feature factory .

Maarten Dalmijn 32:05

Uh yeah , in a nutshell . So how do you help that ? You need to talk , you need to start with the problems , right , and there's a . There's a story which I think very beautifully encapsulates it . It's actually so . You know , nowadays , right , if you go to an elevator , all of them have mirrors , right , there was a time where none of the elevators had mirrors , so what changed ? Why did suddenly all these elevators get mirrors ? So there was a hotel in new york and one of the big challenge that in this hotel was that was an old building and everybody was waiting for these elevators . So the hotel was lovely , but the hotel manager just constantly kept getting complaints the elevators are slow , it's staying too long , and he had looked into it . Right , it's going to cost millions of dollars to fix this problem because you need to change your building . It's just super expensive . But then , what's very interesting , there was like a young student there , a psychology student and he actually said .

Maarten Dalmijn 33:00

What if the problem isn't that they're waiting so long , but that they're bored while they're waiting ? What if we just add a mirror so people can look at themselves and look whether they look sharp and they have something to do ? You know , and they added the mirrors and all the complaints evaporated wow and this is just and this , this is just a simple example .

Maarten Dalmijn 33:21

Right , it's about what's the problem and what you're trying to solve , and yes and yeah , and then it you could have not spent the millions , never made that money back . Or , if you really focus on the problem , you can come up with something brilliant , like this mirror which every elevator has nowadays .

Fatimah Abbouchi 33:39

I love that analogy . I'm going to use that in a post and I'll make sure I credit you for raising it to my attention . That's a really funny one With you know , thinking about , you know your example of the Google calendar . What I thought when you were saying that was like what if they end up replacing Google , like next month ? But I actually seen in an organization where one team was building and it was a manufacturing sort of software . They were building some manufacturing software . There was a significant project for their size , about $500,000 . A significant project for their size , about $500,000 . And as they got like six months into the development of this software , they realised that they were going to have to make some changes because there's a risk associated with the project continuing . And what they found out was there was another project in the same company that they didn't realise another team was doing . That was absolutely going to completely wipe out the relevance of this software project , like bananas . And so that's where I like to play . I like to help align all the different teams so they're all on the same page with what they're doing .

Fatimah Abbouchi 34:43

But one of the things I was going to ask in relation to that is like where , where we know the business like , I like to say that the business just generally struggles to understand the concepts of project management , fundamentally , right . We spend so long trying to educate them on project management and it's not their job to know that . Then you have this thing called agile , which even the best of us sometimes are confused about what kind of agile people are talking about , and yada , yada , yada . So what do you recommend , particularly because you are a product manager ? What do you recommend , particularly because you are a product manager ? What do you recommend as some techniques or tips to engage the business better , without overloading and confusing them , but getting them on board that journey ?

Maarten Dalmijn 35:18

yeah . So I think one of the big challenges is the moment you start kind of , for example , let's say , the business comes to you , right , we need a google calendar . If you immediately start questioning them right , they will get really defensive , because they're kind of get the feeling like , oh , like he's not , like they are not taking my request seriously or they're doubting whether I know my stuff . And I think what I always try to do is just ask questions like try to get them to put all the cards on the table , like oh , that's a great idea , how did you get that idea ? Just extract information , and then you begin asking questions , not why , but like okay , so who's going to use it ? Okay , uh , how , how does it fit in their daily work ? What are they doing at the moment ? Usually you'll hear we don't know , like , okay , I so . So maybe we should talk to them . You know what I mean and and , and , and , and and and .

Maarten Dalmijn 36:13

Because , at the end of the day , what I really try to to hammer home is it's not about what we build , it's how we , what we build , enables them to do something better or differently , like the progress it grants them in their lives .

Maarten Dalmijn 36:26

So we have to start there and and yeah , I try to involve them , even in this conversation we just have a call and I actually did this , for example , for this Google Calendar integration example , I actually went on a call with the customer and I just said because , look , I want to build this Google Calendar integration , but I cannot build it unless I understand how are they working at the moment ? What are they doing ? So we hopped on the call and she just it's a woman I was talking to and she just told me this is what I do every day . And she showed me like yeah , I would like to . And basically the problem wasn't I need a google account integration . The problem was I want to know what everybody is working on in each day , right , and when it's expected to be done . Very different problem , doesn't need a google counter , yeah , and those examples .

Maarten Dalmijn 37:13

You then you give a presentation in a company , right , where you actually say , like , look , we had this request and then we actually talked , and then we found we needed this . And this is why we should always talk about , okay , what problem are we trying to solve and why , how are they currently doing it ? Because then we can better help you . We're not experts in the world of the customer , right , they know it best , but that's why we need to be humble and listen to them , because then we can build a solution that's going to help them actually do a better job and and yeah , we cannot skip that part .

Maarten Dalmijn 37:46

And yeah , repeat , repeat , repeat and and slowly you will get there . But I think it starts with respecting them . You know what I mean , not just saying you're not providing you , you're not providing me what I need . You're giving them feeling that they're stupid because that doesn't work . So you need to meet them where they are .

Fatimah Abbouchi 38:04

And , yeah , intense curiosity and , and I think um you should meet them where they are and like speak their language , you know don't go in there talking to them about story points and blah blah blah , like that's . If they don't understand that , you're going to confuse them before you even get started . You'd like to just want to extract the information that then you can go and play back to the relevant teams .

Maarten Dalmijn 38:25

Yeah , yeah , yeah , absolutely , absolutely , and I think that's the crucial part . And then what I also think is , sometimes you're blindsided , right ? You get a request where you're like your initial feeling is this doesn't make any sense , this is going to be a huge amount of work , and if you tell that immediately to them , they will feel bad , you know . So what I then tend to do is I just let it sink in , start asking questions , like I said before , and then I said , said okay , I need to think a little bit about it . Then you get back to them and then you can tell it when you're not as emotional , but giving it some thought .

Fatimah Abbouchi 38:56

You can give them a few questions and then generally , they'll realize oh wait , maybe this wasn't such a good idea but , the big , but you're preserving the relationship , and I think that's really important and I think , um , you know , sometimes in some of the larger organizations I know , working with product managers , it's quite difficult necessarily to get to every single stakeholder .

Fatimah Abbouchi 39:16

So one of the ideas and I'm keen to see if you've got any ideas for those listening in this space . But one idea was you know , one product manager was going out individually to different people across a two-week period , you know , to show a prototype or to get feedback or whatever it might be , only to realize that that there you go , you've lost two weeks or a sprint or whatever it might be . So then we sort of suggested to her why don't you go the other way ? Why don't you , you know , host a one or two-hour session , invite all of the proposed stakeholders whether they think they need to come or not , include a little memo on that explaining what the purpose of that call is . They get to decide if they think there's any value for them , and then you basically save yourself two weeks of work . So we did that and that actually saved a lot of time . Is there any sort of tips or tricks or techniques you use , perhaps maybe in this space or when doing sprint goals , for example , that you could share with listeners ?

Maarten Dalmijn 40:08

Yeah , so one technique I think is really powerful is using something like story mapping , where you just even involve some of the stakeholders . We actually start talking about what is the journey of the user , what , what are they , what is their goal , what are all the steps they're doing and it's not about the products , and then you start talking about okay , so we understand the journey .

Maarten Dalmijn 40:28

It starts here , it ends here , it is what they're trying to achieve and then , you start talking about the products and then you start making , and then that really helps with generating this common understanding . Hey , we're not here just to build features . But that actually starts with this . This person that's trying to I don't know plan a project or write hours , whatever they're trying do , and how do we fit in that world ? And I think that's a really powerful starting point because suddenly they understand the choices you have to make and why you're doing things a certain way . Yeah , I think , and like you said before , like if you do Scrum , you've got a sprint review every two weeks , every two weeks . Talk about , hey , like how are we delivering value ? You don't have to demo every feature . You know what I mean . And , yeah , I think these things can be extremely helpful .

Fatimah Abbouchi 41:18

I think that's a really good one and this links into , I'm sure , your roadmapping sort of thinking about roadmapping and sort of setting up and evaluating and developing really good , strong product roadmaps .

Effective Product Roadmapping Strategies

Fatimah Abbouchi 41:31

What are some common pitfalls that usually happen for companies trying to put in place good product roadmaps ?

Maarten Dalmijn 41:40

So I think one of the biggest problems I see in companies is high work in progress . So companies are just unwittingly working on too many things at once . And if it's very interesting because actually many managers believe it's a good thing if everybody's busy , right , that's good . But actually if everybody's busy , that that's bad and and that's a , that's a very and and the way to explain it's kind of like if you're at the supermarkets and the person at the cash register is 100% busy , the supermarket is going to lose money because there are people that are going to see the line and just going to be like screw that , I'm going to go home and I'll come back another time . So that's why the supermarkets are always focused on we don't want to have a line , we don't want the person at the cash register , the cashier , to be 100% busy , we want them to be like 70% busy , because that means the customers are following through . The same kind of mentality we should also have with our roadmaps . So the biggest problem I see is we make a roadmap for one year based on estimates , which are guesses , made before we start , and then we've already committed to the huge chunk of work . And the problem is , let's say our capacity is 100 , right . So the first problem is we plan probably around 100 of our capacity because we have we think these are the most valuable things , but we don't take into account all the surprises . There are stuff that we're going to miss . Marketing needs something , production issues , so . But to make things even worse , our estimates can be extremely wrong . It could be that first project , which only takes two months , it takes four months . Right , and that's just because it was so much more work than we had anticipated , because the code base contains technical depth or because the api we wanted to use cannot be used . So we need to build some kind of middleware or all kinds of reasons . And then , after the first month , everything on the roadmap will be delayed , because if the first thing is finished , I can guarantee you cascading effects . Almost everything is going to be .

Maarten Dalmijn 43:44

So I think the biggest mistake companies make is , I would say , less . There needs to be less on there . Right , because you can always do more things , but the moment you over commit , you're actually going to do less and you're going to be frustrating . So there needs to be less on there . The other thing is don't try to plan one year with , in full detail all the stuff you're going to be doing , because maybe that first thing you've delivered is way more valuable than you have anticipated . Maybe you want to double down on that .

Maarten Dalmijn 44:14

There needs to be room for this adaptiveness , and if there isn't room for the adaptiveness , then then yeah , why are we doing agile , you know , like if we just want this and I think that's the hard part like our brains are really good at predicting and planning , seeing this beautiful roadmap gives us the illusion of control . It makes us feel all warm and fuzzy inside , just admitting we don't know how valuable it is . We don't know exactly how long it's going to take . That's probably closer to reality and that's what our roadmap should reflect to some extent , at least for the stuff we're going to be working on , longer than three months for now , because who knows what's going to happen . And that's what your roadmap should take into account . Maybe a bit of a fuzzy answer , right ?

Fatimah Abbouchi 44:57

No , no , it's fine , I could take a lot from that . So you know , thinking about the annual planning . So annual planning , I find , so I don't think any company I've dealt with and has been at least 30 in the last 20 years are pure agile , pure agile , none why ? Because many of them still do their annual cycle financial planning and things like that . So that's one . So their roadmap probably annually maps to their financials and whatnot .

Fatimah Abbouchi 45:21

The second thing that kind of stood out for me is you know , you talked about 100% capacity . It's really interesting because we were working in a client environment and the vendor , vendor , the large vendor on this program of work , um , was actually refusing to give estimates beyond two weeks in advance . They believe that they will only estimate every two weeks and it's as a vendor who's providing services over a period of one or two years , like that was quite ridiculous . It's just ridiculous , um . And then the other thing that I thought of and I wonder whether is it is a technique that may be relevant in this road mapping space is , you know , as the concept of like , must have , should have , could have , you know , the moscow concept , is that something that you would typically use in narrowing down that work in progress list or no , not really like I think .

Maarten Dalmijn 46:10

I think the key thing there is so , so let's say , we've got one project that we're working on , right , and you have this vendor , which is really difficult because they don't want to give an estimate . So I think the key thing there is you do need to have some kind of estimate , but don't waste time on it , right ? So you just say , okay , this is the thing , probably it's going to take nine months , whatever . It is right , and I think the biggest mistake companies make is start with a first milestone you know what I mean and and and really estimate that , break that down and if that milestone is estimated two months and it's going to take usually it takes four months or whatever then you update the timeline and then you tell them hey , the rest is going to take 12 months . They're not going to like it , right , but that's the reality . It's kind of like a weather forecast .

Maarten Dalmijn 46:58

You've got better information and then you can indeed talk about scope . Are we going to make and I I I don't really use moscow or these things I really try to focus on what are we trying to achieve here ? What's the outcome ? What's the smallest valuable outcome and what is the scope related to that . You know what I mean , because the thing is the moment you start talking about features I've been there it's very often must have , must have , must have , because everything is important but the moment you start , a must have yes , yes , okay .

Maarten Dalmijn 47:30

So what I tend to do is more start like how is it anchored in what this persona is using the products ? Let's say it's a finance person . They're trying to close the month , for example . So maybe we just say , okay , we're going to enable them to close the month , or whatever it is . What is the scope related to that ? What is the smallest possible scope we can deliver ? Because , related to that , what is the smallest possible scope we can deliver ? Because then you can , how do you say you can really have flexible scope discussions , you know , and in the moment it's not anchored in the the role of the user , then it's , yeah , it can become very fake , you know , because everybody thinks everything is important , because the sales guy will say , if these , these thin things aren't in there , I cannot sell it . You know what I mean . But why can't you sell it ? Well , because I say so .

Fatimah Abbouchi 48:13

Yeah , that's the challenge , because you're right , if you use that sort of concept , everything's going to be a must-have . If you don't use that concept and you do what they normally do and that is , put everything in there anyway and without it , they will argue that they can't . So it's like it's really challenging . Without it , they will argue that they can . So it's like it's really challenging . So I think it's like maybe putting like there's a fixed depending on what kind of you know ways of working you're using , there's a fixed capacity in the team , and that has to be taken into account . It's not unlimited and therefore you can put everything in there .

Fatimah Abbouchi 48:48

So I guess , as long as there's a way to connect what the capacity is versus however you want to score the work thing in there . So I guess , as long as there's a way to connect what the capacity is versus what the however you want to score the work , then I guess you bring the two together and perhaps you can get people on board that . But you're right , you definitely need to be adaptive , um , and if you're not , and you've got a fixed date , fixed hard date , then you're not running agile and so , yeah , definitely going to make up that , make up your mind early , yeah .

Maarten Dalmijn 49:10

And I think , one of the crucial things there is . So I've worked on projects that have been delivered on time and products that have been terribly late , and the projects that were delivered on time . You know what they all had in common .

Fatimah Abbouchi 49:23

What .

Maarten Dalmijn 49:23

They delivered something early , that works .

Fatimah Abbouchi 49:26

Yep .

Maarten Dalmijn 49:26

So I think one of the biggest indicators that projects are late is and it's very obvious , right , if you like they're working on for four months . There's nothing on production , you can't see everything .

Maarten Dalmijn 49:36

That's the moment you're screwed , that's the moment it's going to be so all the effort , I think when starting a project , we should really think about how can we deliver something early , as early as possible , that works , because the projects and really soon like I'm talking something in like one month or six weeks you have something that works , and that because that makes everything else easier . Because you've got something that works , you've got a UAT environment , you've got production , the QAs can start testing sooner , and the problem is all the other projects that I've seen that are very delayed . Then you've got the late integration problem . Suddenly everything has to come together and , yeah , the last 10 , 20% , that's where you're screwed . So you want to get to that last 10 , 20% as quickly as possible .

Fatimah Abbouchi 50:24

And you also want to make sure that what it is that you're delivering quickly is something that I guess is tangible enough for the business to understand .

Fatimah Abbouchi 50:32

Like they're not going to care if you said we developed a hundred lines of code , they're going to be like whatever . I can't see . I can't see that . One thing that I see as a common recurring issue in organizations that are less mature in their agile journey I'm keen to see if you've got some thoughts on this is they typically , you know , they'll have all the different scrum teams and they'll have limited , say , testers , or limited developers or whatever type of resource that's limited , and so they'll have , say , for example , tester John Smith . He'll be split across . You know , in this example , there's four value streams and they've got multiple different teams members within each value stream , but because there's only limited testers , they'll put John Smith tester across three of the four value streams and then that tester is split and spread across . What's your thoughts on that ? Is that just the recipe for disaster ?

Maarten Dalmijn 51:24

I mean there's this quote . I think it's from the goal and it's any progress , any progress . Improvement , not at the bottleneck , is an illusion you know , yeah .

Fatimah Abbouchi 51:37

So what's the ?

Maarten Dalmijn 51:38

bottleneck , it's QA . So the example I use I always talk about coffee , right ? Imagine you've got a coffee shop and you've got a barista , and the barista can make 400 espressos per hour . And you've got somebody who's great at making cappuccinos they can make 200 , 200 cappuccinos per hour . How many cappuccinos per hour are you going to make ? 200 .

Maarten Dalmijn 51:58

There's no point in adding another barista that can make espresso . So in this case you're wasting a lot of money , burning money to deliver something at the speed of the qa of that , one person spread over three projects . That's the bottleneck . So what's the solution ? More qas , right , or let's developers do something ? You tell the qa , hey , you're going to coach the developers , you're going to , and if they're like crucial stuff , right where there's money involved , or you're going to do it . But actually your job is going to be that that you remove your own bottleneck . You know , like that's your job . Is it optimal ? Still , probably not right , but I think the alternative is just folly . It's kind of it's trying to run an espresso shop where you have you can make 400 espressos , but you've got uh , how do you say someone who can only make 200 cappuccinos per hour . So you're screwed , you're only going to deliver 200 cappuccinos and you're paying someone all these people to not deliver anything . That's a waste of money and yeah , and that's what you should be talking about .

Fatimah Abbouchi 53:00

And and I think it's really difficult I've been in this situation very often and yeah , I see that , I see that and I like that analogy um what I thought of when you were describing

Navigating Agile Trends and Adaptiveness

Fatimah Abbouchi 53:10

. I was like imagine having one person right , that is , the barista across four coffee shops yeah , yeah , yeah , yeah , this is simpler even two , even two coffee shops like , and having to keep track .

Fatimah Abbouchi 53:21

and then they wonder but you're right , even you know if , if they can cut up um , you know , upskill colleagues , 100 and maybe , like they can do 80% of the role , they potentially can increase the budget and the count of people in the team , which is often the option they don't want to go with because they don't want to do that , they don't want to have to head count . Or option three is they have to reduce scope or delay the completion of certain scope or features to a later point in time . So there is options .

Maarten Dalmijn 53:54

They just don't want to listen to them , do they ? No , no , they just want it . Now it's just absurd because at the end of the day , you've got a team right . It's kind of saying you've got a striker , he's playing on three different teams , yes . And then you're like , okay , let's call it . We need to score a goal . Let's call the striker . The striker's gonna come exactly , minutes , exactly . Even if we had like ronaldo on our team .

Fatimah Abbouchi 54:07

It would be like trying to spread him , even with his talent . It wouldn't work anyways . Um there you go , funny story . Um , so just um , just surrounding out , thinking about . You know you write a lot about , obviously , agile and scrum and all of these different topics . What are you seeing as like a significant trends ? Is it , you know , tech related ? Is ai related ? Like what are you seeing as the trends happening now ?

Maarten Dalmijn 54:31

well , I think ai is obviously a trend . I mean , uh , but it's going to be very interesting , I think , the next coming five , ten years . There are very different perspectives . So some people say , uh , artificial general general intelligence is really near right Next 10 years , it's happening . Elon Musk is even saying it's happening in the next years . I don't know right . I'm not an expert in AI . I want to stress At the moment , based on what I'm seeing , I'm in the camp . It's not happening . I just don't . I'm not in the happy camp . It's amazing . I see it used for all kinds of stupid use cases . I'm not that impressed . I mean I'm impressed compared to what was possible before , right , but I don't think it's that good . So time will tell right . Maybe I'm wrong . I'm definitely not an expert , so I could be very wrong .

Fatimah Abbouchi 55:19

Never mind .

Maarten Dalmijn 55:21

But if you look in the realm of Agile , what I'm kind of seeing is more and more Scrum criticism . I think people are kind of tired of agile and scrum . That's kind of the feeling I'm getting I'm also curious to hear your perspective .

Fatimah Abbouchi 55:37

That's kind of that's criticism with um , with safe and and sort of models like safe . I'm seeing some eber in the absolute hate it camp to the um . You know , love it , but I'm finding more people are getting , even though it's like I think the fastest growing before scrum , I think safe is . I'm finding a lot of people were sort of feel burnt out by it . Um , that's what I'm hearing anyway yeah .

Maarten Dalmijn 56:00

So I don't know , I think I think so . Basically we had like the world west of agile right before , before the agile manifesto , I think that's how jim highsmith calls it yep , uh . Then we kind of had the copy paste agile era right where everybody was kind of looking for uh boxes to copy paste , like safe and scrum . And I think now we're going to go into the agnostic agile era , like where people are like I don't care whether it's called scrum or it's called safe , we have patterns , they work in specific situations and we're going to try those platforms and we're going to figure out something that works in our situation . So I think that's kind that's what I'm hoping is happening , because I really believe scrum and safe . You know they were helpful because they kind of made people realize like there are all these kind of different toolboxes and stuff that you could be doing , but I don't think it makes sense to say you have to do this , this is the framework , uh no like you don't want to do a daily scrum , don't do a daily scrum .

Maarten Dalmijn 57:02

And and then , of course , in the scrum world they always say yeah , but you can do that scrum doesn't say you can't do it . Right , okay , great . But I think everything should just be a pattern , like there's no need for a bundle of patterns , because all we see is hate , dogma , fighting safe . Scrum is not the same as scrum , and I think the moment we move away from towards patterns , then we're still going to have arguing like should we use story points or no ?

Maarten Dalmijn 57:33

estimates but yeah , those are , I think , less bad I'm curious what you think more , more so that as people .

Fatimah Abbouchi 57:42

But those people that are complaining and saying that it's not this and I just want to debate all day long with you know , not constructively , I say they're just not delivering . So they that's probably why they've . They just want to debate all day long , you know , not constructively . I'd say they're just not delivering , so that's probably why they've got the time to complain and say all these things . I agree , one of the things that I've been driving for at least the last six , seven years since setting up AMO was , my view is around adaptive governance . So one thing that happened about six , seven , I'd say maybe eight years ago .

Fatimah Abbouchi 58:11

I originally set up AMO because in working in the large banks they were trying to figure out how they blend sort of agile ways of working and governance versus , you know , the traditional ways of working governance . So I was trying to help them find the conduit , and over the last few years I've found that the best approach when it comes to governance is changing the how , not the what , because governance is governance , no matter where I am in the world , and so I think it's more changing the how and being adaptive , and it's not based on any method or process or framework . It is simply what will work for that company at that time and making sure everyone has the same page with it . So I agree with you on that .

Maarten Dalmijn 58:49

Yeah , and that's the future . I so I agree with you on that . Yeah , and that's the future . I think I hope , but maybe not . Maybe we're just too attached to the shiny frameworks and being able to say I'm a Scrum Master , I'm a safe SPC .

Fatimah Abbouchi 59:02

Yeah .

Maarten Dalmijn 59:03

Like maybe it's going to stay this way forever . I could be wrong .

Fatimah Abbouchi 59:06

Maybe I definitely we'll have to ask one of the people on LinkedIn that has about 15 tags on their surname . They can't keep up with the number of certifications . So we've got a Martin , we've got a tradition to ask a final question and basically it's simply is there anything else that you'd like to share with our listeners ? A call to action , a piece of advice ?

Maarten Dalmijn 59:31

or a question to ponder before we wrap up today .

Maarten Dalmijn 59:32

I just like to challenge people , like whenever you're thinking we should do it this way because SAFe says so , scrum says so , don't do that thing that the Scrum Guide says or what SAFe says , like , try the thing you wanted to try out , see if it works . Maybe you'll be confirmed right and what's safe or Scrum says is great . But maybe you had a great idea , so don't worry so much about adhering to any guide . In the end , it's reality what matters , and I think that's what we should be doing more , like trying stuff out , because even innovation comes from trying stuff out , even when we believe it's not going to work . And yeah , all these guides were written by fallible human beings like you and me . They're described in a fallible way , so that's why I think it's really dangerous if we kind of try to stick to them and stifle our creativity and imagination . It's okay to be wrong and , yeah , we should acknowledge that more , like we should try to be wrong more often , because if we're never wrong , we're never going to innovate .

Fatimah Abbouchi 1:00:35

I love it . Experiment more . There you go . Said by a true Agilist Amazing . Thank you so much for your time . This has been great having you on board . We're actually out of time , but I know we could have kept talking . I say that to all my guests , maybe because I just like asking a lot of questions , but thank you , I really appreciate it , particularly your morning time over there .

Maarten Dalmijn 1:00:54

I appreciate you doing it kind of after work hours . So thank you very much .

Fatimah Abbouchi 1:00:58

You're welcome . Thank you so much for listening to this podcast . Please share this with someone or rate it if you enjoyed it . Don't forget to follow us on social media and to stay up to date with all things Agile Ideas , go to our website , wwwagilemanagementofficecom . I hope you've been able to learn , feel or be inspired today . Until next time , what's your Agile Idea ?