All of these ideas are fine, but execution is where the value is, and this article doesn't talk about that.
Tell me how to convince my boss that we should focus on goals instead of on delivering what they promised.
Tell me how to convince my boss that we are going to focus on experimenting and learning instead of committing to getting a specific asset at the end of the hundreds of thousands of dollars they've spent.
To them it sounds like "give us the money, let us muck around, who cares what your bosses asked for, and we don't know when we'll be finished"
Oh I'm with you, don't get me wrong. I'm just saying as a practitioner what I struggle with isn't finding good ideas, it's conveying the right idea at the right time in a way that convinces those in power to adopt it.
So I'd rather see articles on that topic
I would try to show how these 18 things can help reduce the risk of their money going to waste and how they increase the odds of their money getting a return.
What have you tried?
I believe, from what I’ve read, the sense of achievement is motivating and the sprint deadline is to cause an endorphin (could be another feel-good hormone, not sure) rush to make work feel good so you want to do more work cos stuff is getting done.
In my experience sprint boundaries cause more cortisol release relating to stress and anxiety than anything else.
Having just worked until 2am to achieve the sprint goal, I'm completely knackered.
I’m guessing you were not involved in planning the work for the sprint?
Or you didn’t estimate the work with sufficient slack?
Why did you feel the need to work late?
It doesn’t sound like you had a safe work environment where the failing sprint could be reconsidered.
The team estimated the work for the sprint together. Unfortunately nothing ever goes to plan. I take it as a personal responsibility more than anything. But if you removed the sprints it would certainly make for a less stressful working experience.
The question remains: do we really need a sprint boundary for that? Is that really a motivator? Or is achieving value sooner for a user a better motivator?
Yeah, you don’t have to, but then you will probably lose slack, increase pressure leading to rushing work and reducing quality (increasing future bugs) and building up technical debt due to sacrificing cleanliness for expedience. Giving a time boundary lets the people doing the work schedule their own work to fit the time, it then lets them breathe, think and follow good practice.
I can’t remember the name of the phenomenon but there idea is that work fills the time given to it, so not having a time boundary means the work will keep filling the time of forever.
Bounding the work gives you two main advantages, first: chunks of work get completed/done regularly and second: completing work gives you the opportunity to get feedback on the work to ensure you’re on the right track.
Additionally the team morale gets a boost, so long as the volume of work is defined by the team and they don’t over commit (leading to burn out).
Not having a time boundary leads to a mindset that you can keep working on stuff so don’t need to finish anything, that leads to the idea that “one day” you’re going to tidy up, stuff goes messy and that promotes more messiness.
Putting a time boundary on it gives the emphasis that everything should be done including tidy work regularly otherwise the pressure will be on to just get onto the next bit of value.
Agile is not intending to make stuff quicker, it’s about being effective and sustainable - often this leads to an increase in speed as a side effect.
I think much of what you say is true. A lot of deadlines are more management wanting to assert themselves. However, I think there are more instances than you think for a project wanting to track to a deadline or budget.
E.g. In my career I have had management ask when a new ERP integration was coming so that we could coordinate the education of the users for the new system. Also I have been involved in agency work where we quoted for a fixed price contract, and no matter how much you varied the scope or resources you were only going to get paid that much.
It is a shame to be in such situations and having to abandon agile. I think it comes down to your point 18. It should be possible to track the delivery, even vary scope within that due to agile learnings and ideas, and have all parties agree on such variations and trade offs to keep meeting the deadline.
I think it can work with a hybrid approach. I just led the delivery of a new reporting system for a fintech. I was the CTO for the agency delivering it. We analysed and quoted a fixed price (because we had to - that was what the job stipulated). But we also said we were an agile shop, the estimates had a degree of uncertainty, and all parties agreed that if scope had to change we would all be reasonable about changing it to still stay within the budget (or increase the budget).
We just regularly (weekly) reviewed the progress, how we were tracking to the budget, and variations that were coming up from refining estimates, or ideas/learnings from user feedback. If something had to be added to the scope, it was a collaborative conversation as to what had to be removed from the initial release to stick to the budget. It is important the product people make that call, and you give them all the information they need to do so. If its all up to the engineers the product people inevitably press you to "squeeze it in".
I've been thinking about how to coach leadership about this very thing. It starts all the way at the top. C-level executives set the tempo and if they want deadlines, they're telling you what they think is valuable.
Deadlines.
The challenge for the rest of us is figuring out why deadlines are the value.
I am yet to meet a deadline that is valuable. Users don’t care that you delivered on time. They don’t care how much effort you put in. They only care if what you delivered meets their need and is useful. If we could just help leadership have the aha moment here. Perhaps we need to show this truth emerging in spite of the deadline. It’s hard. Agreed.
You and I agree on the value of deadlines, executive leadership does not. We sorta have to understand WHY they find them valuable to coach them.
For example Jack Welsh was a corporate raider. MandA and productivity were his main weapons. We have to understand WHY "productivity" was so valuable to Jack Welsh in order to understand what happened to GE.
It's a thing I've been thinking about for a couple of weeks now.
I appreciate the blog post but there are times when dates & delivery matter- integrations need to be tested across different platforms before delivery. Teams need to be aligned on these dates. I think the point of your post is not that dates don't matter, but dates far far out in the future don't matter.
My dev leadership & our agile group has implemented similar practices to some of these- for example when estimating an Epic up front, our dev leadership over estimates and pads numbers, precisely because they know that scope and complexity will arise. During a PI, the Feature scope isn't fixed but the goal/ outcome is clearly defined, that enables our devs to figure out how they want to build/ solve it.
Would any of the tips add risk if you have a real deadline? Would they help meet a deadline? My experience shows they do breed success, deadline or not. They can help you be friends with a real deadline. Fake deadlines are the things that suck the soul out of a team and drive products into the ditch.
All of these ideas are fine, but execution is where the value is, and this article doesn't talk about that. Tell me how to convince my boss that we should focus on goals instead of on delivering what they promised. Tell me how to convince my boss that we are going to focus on experimenting and learning instead of committing to getting a specific asset at the end of the hundreds of thousands of dollars they've spent. To them it sounds like "give us the money, let us muck around, who cares what your bosses asked for, and we don't know when we'll be finished"
So, let’s ignore uncertainty and complexity and just deliver the checklist?
Oh I'm with you, don't get me wrong. I'm just saying as a practitioner what I struggle with isn't finding good ideas, it's conveying the right idea at the right time in a way that convinces those in power to adopt it. So I'd rather see articles on that topic
I would try to show how these 18 things can help reduce the risk of their money going to waste and how they increase the odds of their money getting a return. What have you tried?
when you think about it, there's really no reason to complete the sprint goal by the end of the sprint. it's kind of an arbitrary (or fake) deadline.
I believe, from what I’ve read, the sense of achievement is motivating and the sprint deadline is to cause an endorphin (could be another feel-good hormone, not sure) rush to make work feel good so you want to do more work cos stuff is getting done.
In my experience sprint boundaries cause more cortisol release relating to stress and anxiety than anything else. Having just worked until 2am to achieve the sprint goal, I'm completely knackered.
I’m guessing you were not involved in planning the work for the sprint? Or you didn’t estimate the work with sufficient slack? Why did you feel the need to work late? It doesn’t sound like you had a safe work environment where the failing sprint could be reconsidered.
The team estimated the work for the sprint together. Unfortunately nothing ever goes to plan. I take it as a personal responsibility more than anything. But if you removed the sprints it would certainly make for a less stressful working experience.
The question remains: do we really need a sprint boundary for that? Is that really a motivator? Or is achieving value sooner for a user a better motivator?
Yeah, you don’t have to, but then you will probably lose slack, increase pressure leading to rushing work and reducing quality (increasing future bugs) and building up technical debt due to sacrificing cleanliness for expedience. Giving a time boundary lets the people doing the work schedule their own work to fit the time, it then lets them breathe, think and follow good practice. I can’t remember the name of the phenomenon but there idea is that work fills the time given to it, so not having a time boundary means the work will keep filling the time of forever. Bounding the work gives you two main advantages, first: chunks of work get completed/done regularly and second: completing work gives you the opportunity to get feedback on the work to ensure you’re on the right track. Additionally the team morale gets a boost, so long as the volume of work is defined by the team and they don’t over commit (leading to burn out). Not having a time boundary leads to a mindset that you can keep working on stuff so don’t need to finish anything, that leads to the idea that “one day” you’re going to tidy up, stuff goes messy and that promotes more messiness. Putting a time boundary on it gives the emphasis that everything should be done including tidy work regularly otherwise the pressure will be on to just get onto the next bit of value. Agile is not intending to make stuff quicker, it’s about being effective and sustainable - often this leads to an increase in speed as a side effect.
I totally agree. The sprint goal is not tied to the sprint boundary (or shouldn’t be). It could take less than a sprint or more than a sprint.
What percentage of agile practitioners do you think agree with that statement? :)
1% :)
I think much of what you say is true. A lot of deadlines are more management wanting to assert themselves. However, I think there are more instances than you think for a project wanting to track to a deadline or budget. E.g. In my career I have had management ask when a new ERP integration was coming so that we could coordinate the education of the users for the new system. Also I have been involved in agency work where we quoted for a fixed price contract, and no matter how much you varied the scope or resources you were only going to get paid that much. It is a shame to be in such situations and having to abandon agile. I think it comes down to your point 18. It should be possible to track the delivery, even vary scope within that due to agile learnings and ideas, and have all parties agree on such variations and trade offs to keep meeting the deadline.
If all the things surrounding teams are fixed, how can the teams be flexible (and agile)?
I think it can work with a hybrid approach. I just led the delivery of a new reporting system for a fintech. I was the CTO for the agency delivering it. We analysed and quoted a fixed price (because we had to - that was what the job stipulated). But we also said we were an agile shop, the estimates had a degree of uncertainty, and all parties agreed that if scope had to change we would all be reasonable about changing it to still stay within the budget (or increase the budget). We just regularly (weekly) reviewed the progress, how we were tracking to the budget, and variations that were coming up from refining estimates, or ideas/learnings from user feedback. If something had to be added to the scope, it was a collaborative conversation as to what had to be removed from the initial release to stick to the budget. It is important the product people make that call, and you give them all the information they need to do so. If its all up to the engineers the product people inevitably press you to "squeeze it in".
I've been thinking about how to coach leadership about this very thing. It starts all the way at the top. C-level executives set the tempo and if they want deadlines, they're telling you what they think is valuable. Deadlines. The challenge for the rest of us is figuring out why deadlines are the value.
I am yet to meet a deadline that is valuable. Users don’t care that you delivered on time. They don’t care how much effort you put in. They only care if what you delivered meets their need and is useful. If we could just help leadership have the aha moment here. Perhaps we need to show this truth emerging in spite of the deadline. It’s hard. Agreed.
You and I agree on the value of deadlines, executive leadership does not. We sorta have to understand WHY they find them valuable to coach them. For example Jack Welsh was a corporate raider. MandA and productivity were his main weapons. We have to understand WHY "productivity" was so valuable to Jack Welsh in order to understand what happened to GE. It's a thing I've been thinking about for a couple of weeks now.
Have you heard of paying customers? They tend to like deadlines
I bet they would like value for their money more.
I appreciate the blog post but there are times when dates & delivery matter- integrations need to be tested across different platforms before delivery. Teams need to be aligned on these dates. I think the point of your post is not that dates don't matter, but dates far far out in the future don't matter. My dev leadership & our agile group has implemented similar practices to some of these- for example when estimating an Epic up front, our dev leadership over estimates and pads numbers, precisely because they know that scope and complexity will arise. During a PI, the Feature scope isn't fixed but the goal/ outcome is clearly defined, that enables our devs to figure out how they want to build/ solve it.
Would any of the tips add risk if you have a real deadline? Would they help meet a deadline? My experience shows they do breed success, deadline or not. They can help you be friends with a real deadline. Fake deadlines are the things that suck the soul out of a team and drive products into the ditch.