Welcome back to my blog! Today, I want to share some insights from my recent office hours, where I tackled a few pressing questions about agile practices, particularly around story points, team sizes, and emergent architecture. These topics are crucial for anyone looking to enhance their understanding of agile methodologies and improve their team’s performance.
The Evolution of Story Points
I recently had a thought-provoking conversation on Twitter with Daniel Kahney, who suggested that story points have caused more harm than good in our industry over the past two decades. Initially, I was a fan of story points, but my perspective has shifted significantly. Here’s why:
- Lack of Value: Story points are meant to be a relative measure of effort, but they often fail to provide real value. Each team interprets story points differently, making cross-team comparisons meaningless.
- Predictability Issues: The standard deviation in story point estimation can be as high as 30%. This wide variance makes it difficult to predict what a team can deliver in a sprint accurately.
- Focus on Throughput: Instead of relying on story points, I advocate for measuring throughput. This approach focuses on the number of items completed in a given timeframe, allowing teams to optimise their processes more effectively.
By shifting our focus from story points to throughput and cycle time, teams can make more informed decisions and improve their delivery capabilities. I believe that embracing this change sooner rather than later will lead to better outcomes.
Rethinking Team Size
Another question that came up during my office hours was about team size. The Scrum Guide suggests a team size of 3 to 9 members, but I’ve seen teams thrive with sizes beyond this range. Here’s what I’ve observed:
- Larger Teams Can Work: In my experience, teams of 10 to 12 members can be effective, especially when they incorporate various roles, such as site reliability engineers, within the sprint. This structure allows for better handling of outages and ensures that the team can maintain focus on delivering value.
- Quality and Efficiency: Larger teams can manage more complex tasks and maintain high-quality software in production. They can also run essential checks, such as security and performance benchmarks, without disrupting the flow of work.
While traditional thinking suggests smaller teams are better, the reality is that as we integrate more roles and responsibilities, a slightly larger team can be beneficial.
Selling Emergent Architecture
The final topic I want to address is the concept of emergent architecture. This idea can be challenging to sell to stakeholders who are accustomed to more traditional approaches. Here’s how I approach this:
- Emphasise Flexibility: In today’s fast-paced market, businesses need to be agile and responsive to opportunities. Emergent architecture allows teams to adapt and evolve their systems as new needs arise.
- Real-World Examples: Look at how companies pivoted during the recent pandemic. Many organisations rapidly scaled their infrastructure and introduced new features to meet changing demands. This adaptability is a testament to the value of emergent architecture.
- Engage Stakeholders: It’s essential to communicate the benefits of this approach clearly. Help stakeholders understand that embracing change and flexibility can lead to better market positioning and increased competitiveness.
Conclusion
In summary, my recent discussions have reinforced my belief that we need to evolve our practices to stay relevant in the agile landscape. Moving away from story points, re-evaluating team sizes, and embracing emergent architecture are all steps in the right direction.
If you have any questions or want to dive deeper into these topics, feel free to reach out. I’m here to help you navigate your agile journey. And remember, Naked Agility is available for DevOps and agile training and consulting—don’t hesitate to contact us for a free consultation!
Hey
Okay, welcome.
Makes agility. I name national scrum trainer.
But once naked agility is available for DevOps and agile training and consulting, contact us for a free consultation.
Oh, so I am wanting to have a little ad event a few things. This is my mmm office hours. Office hours is where I answer any questions that I’d asked. Baris is going to be moving from Tuesdays to Wednesdays as of next week, but you can effectively ask me. I think I have a link here to go to a forum where you can ask anything.
This is somewhere where nobody knows who you are and what you said, so don’t put anything in the content that we don’t. But I have a few questions that have come up over the last couple of weeks, and I just finished a professional scrum master class for a programme who to cling in. Are we a regular class that I and check for questions? We are going to talk about story point evolution.
I had a conversation on Twitter with somebody who asked whether what I thought of story points. I was buying to Daniel the counties. Thanks that story points have damaged our industry over the last 20 years, as put it back amount. But I replied and said I agree with Daniel. I used to think that story points were awesome, and I don’t. So we’ll chat about that.
I talked about team size because I think the traditional six plus or minus three is as we get or our complex at building software. I had a question in my class around how to sell emergent architecture decoders. If you do want to ask a question and you are on either LinkedIn, Facebook, Periscope, or Gup-a, please feel free to ask the question in the comments. I should be able to, as they come in, maybe a delay, but be able to see as they connect platforms. You can also go ask questions form, and I will ask.
So I have just a quick update on the classes that will be running. The Oslo class has just finished. They only have one more class on my schedule. I’m going to update my shape liked more.
But I have a professional scrum unban cool annual Vacanti. Aims on currently have a couple of students registered, and we are hoping to have a lot of fun in that class as we use a new technique to deliver a virtual classroom and to eight experience Daniel. I found eita analytics or flow better and bring that in part of this.
Oh, first up is story point evolution. Story points are they’ve had an interesting life, been around for quite a long time, and I think I agree with Daniel. Daniel Candy said that they’ve damaged our… Let me see if I can find that tweet.
So the reason that I don’t like story points is they don’t actually provide value. I’m sure Daniel would do a much better job of describing the additional value that you get than different measures. Story points are something that we’ve been trying to use in the agile community for a long as they are relative estimation. They don’t have a value outside of the team because they are reflective of how the team effort. They are not something that we prepare across teams because each team comes up with different values. They are not something that we can measure that team by, but they are traditionally used by the development team to understand based on their history of point delivery, like city based on that and how many things they might be able to bring into their sprint.
Also, at the product owner looking at what’s the progression that acting with the backlog problem. The story points is that their standard deviation of what you think you’re going to get, what you get, and maybe that worst case, the best case. That standard deviation is so wide or than 30%. The starvation is so wide, the ability to predict so 30% sprint own sprint a huge difference getting stuff and not getting stuff.
So what can we do? Well, as part of the PSK class, you can go download and read the Kanban guide for scrum team. We talk instead about throughput. It doesn’t care about size, whereas velocity at story points cares about the size of the item. So you’re going to sum up the story points backlog all right in the spin backlog. Paucity, sorry, Rupert, and only cares about the number of items per unit of time. So that unit of time could be print. Some how many things that I deliver. One of the advantages of that is if the team want to game that, i.e. they want to make the numbers bigger to look better, they need to reduce the size of the items. Size of the items is good. Get smaller batches and actually process a lot more quickly.
But it also allows us to look and instead if we collect throughput. So we calculate very… We know our throughput. We go our cycle time from when we decided the work has started to when we played ends at collect our working process. How many items currently have between by unions and we’d work start even when it finished, no matter how many columns. An idea of how long things have in light are those. Even you can have it bonds as well. You can break it out that way, but really if we can model that, we can use Little’s law, get an understanding of if we reduce our work in process that we could potentially increase our cycle time. And if we want to deliver more things, we need actually smaller. We can’t tell any of that just from story points because they’re not just size dependent but an objective measure rather than a subjective measure.
So I started off at liking story points, and I then moved towards thinking 30 points make sense for immature teams because they’re easy to understand, easy to pick up quickly. I get started with, but that the limitations of story points I think cause more damage at a time. And I would rather a team started as possible being at their throughput, liked in their cycle time, broke item aging and process. If they start that sooner rather than later, they get used to it a lot more quickly. They’re able to look at the data and maybe make better optimisations, make better decisions from events as legal.
But that was my thought process, my journey towards that story points are a bad idea. And maybe not as against them as Daniel is, but I definitely think there are a thing of the past.
So the second one, second question was around team size, and we talked a lot in scrum about team size. We have our particular questions in the… But particular questions in the scrum training around can a team be smaller than B? Yes, it can. The scrum guide recommends it at team at 3:00 and 9:00, but it doesn’t say they have to be. The other question is usually a… Oh yeah, first they can t be better than 19. Teams can be way better than 9. Is that going to be optimal? Are they going to be able to dictate and understand what everybody’s working on and work together effectively? That might be a different question in that space though.
What I would like to discuss is I work with a lot of teams. I worked for a long time as a Microsoft MVP. Yes, used to be a fast, and I was EV UPS. I’ve been working with those along with the other for a long time, and their teams are bigger ballet than at night. They have teams in 12, and the reason they have teams between 10 and 12 is because they’re doing a lot more things inside of the sprint or that they’re able both having high quality working software in production.
Something that they use is a state reliability techniques, but they have engineers inside of the sprint. And I think if my understanding is correct, it might have changed since the last time that I spoke to, but they have two people at pair sprint allocated to the website reliability. In each team, there are two people dealing with that. So anytime they have an outage, they are the first responders that outage, not interrupting the team working on adding value to the product. They may have to bring in other people that are currently adding value to figure that out there, but they are your hopefully not going to have an outage. If there is an outage, the root cause analysis this and the time they’re there, they’re dedicating up, up spending that time to pause analysis, figure out all of the things that might need to change in order to make the product better. Some of them may be small things, some of them may be big architectural change. Get those things onto product backlog, and then as their day-to-day job when they’re not dealing Energon, their job is to work only those site reliability tasks, making your application more stable, efficient, less buggy and our architecture.
And I would use an option that rule site reliability engineering is rotated through the team so that you don’t have somebody just through time as a specialist in that role. We need to get it running. Now, they also give responsibility to their team function. Obviously, they’ve got SR Easton, so teams that build a feature are responsible for buying a feature and doing and maintaining it in production. So they have to cite what telemetry they’re going to capture. They have to look at that telemetry. Everything’s good. Partly there was that there was SR ease, but it does leave the rest of the team be the focus adding value and be interrupted. That means that the team needs to be that little bit bigger - bigger than you from team.
Well, but maybe 10 to 12 is an extra person still than the name we generally look at. And the reason that they have that extra person is that they’re doing more stuff during print in a traditional project market product cycle. And especially the old TFS product cycle from the door, they would have shipped to production once a week, Bruce, and had a service pack. Every year here, they have a service pack. Then I respect I’m in that model. A lot of work got left end cycle. You have a code freeze, and they have to go and stabilise the code and that’s our Ollie and be my technical debt fixing bugs, that kind of thing. But there’s also work to secure the product, to run security checks, to run performance benchmarks, to do all of that work.
And now in modern techniques that they are using, they run all of those things inside of the team. So they’re not running them in our secondary age. I do the tea by a different department gives them feedback. Veltman tea elves making sure but good purity, the automation around the security that I knew done. And even the rest he could write exercises to get the additional stuff the theme. So their teams are a little bit bigger, and I think that is an indication of things to come from any team. That may be the traditional thing that people about 5 to 6 from team not going to be enough as we bring and not only have we got quarters and testers, also bring in security experts and operations and functions metrics as we’re bringing those things that are national Lilly understand quality of the work that the Bing and the act half on production and on and what ad looks like.
I am a trade to know what broken something or whether the varmints or whether are actually using the feet. I did be all our tea bigger, and so I want to see bigger than elf. That’s that for me is quite a big team, but I think it’s within the context of the organisation. Some organisations will be all of those things talking about and still have small teams. Other organisations will have to add.
So that was the second one. We talked about story points and moving towards the more and style metrics talked about.
So the other one that I had was emergent architecture. I think I’m going to be interested if I can have a decent answer, but this one, the question was around how do you sell marriage in architecture to be cold? That idea that we’re not going to know up front. It’s not possible for us to know up front, and there may be things that we would have added to architecture in a waterfall or terrific project management model where we would have made a bunch of decisions or features that we actually build.
I would be a yeast and to have our architecture in urge over time. Maybe in the first sprint wheel and fit I’m adding value. That’s the time we’re working with architecture.
Time to do it. I’ll have at slack. Arge amounts of new phone. But selling imagine architecture to stakeholders the organisation, I think this is something that’s just a change in a organisations. Organised in order to facilitate adjuvant practices. I’m not talking about just agile within buffer engineering team, rest of the organisation in order to take advantage but speed both we’re team. And really that I mean, let’s go back a bit because that’s not the point. The hope, the whole point is that a business needs to be able to take advantage of opportunity as they arise in the market, to be able to see an opportunity, go, let’s build something around that, take advantage of that, whether that’s getting a new product into the market, whether that’s adding new features into the market, whatever that is.
If you look at the current at covent crisis and the number of the shift that organisations have made in the fever’s or delivering, especially in the space of virtual pain. So all the video conferencing applications ramped up not only their infrastructure but potentially certain features. Microsoft have already started rolling out 3 by 3 instead of 2 by 2 windows. They’ve already started rolling out at hand raised as an infant part of the product and other things. End call was one of them. The zoom add to pivot from adding new features towards adding security and actually adding the incorruption said was in the product, actually doing things very different other than before the crisis happened.
And even things like I use our platform called Lord order to pour game is remotely. And by four months ago, they were lucky if they hit 5,000. You even be accessing their system. Now they’re having 5,000, having to ramp up Orman’s scale their server, skill their instances like everybody else. But these pivots of both what features were going to build when we’re going to miss them as well as scaling up are things that organisations that have been able to have it like that word but change what they’re doing to be prioritised.
The organisations I’ve been able to that more quickly are the ones that have been able to take advantage of this opportunity or them to our market share to visibility across the board. So it’s important to be able to sell the ideas behind architecture idea in our ability to change a longer time.
And I don’t know that I did a good job of bringing that, but you will probably let me know in the comments. And I don’t see any comments coming in, so let me just check my list of things. And I did have our conversation with a couple of folks after the class around how do you get executive buy-in? Who do you get people and God executive and leadership who are not yet on process the ideas? The ability of changing the week, not just level but about the organisation too. Ditch the idea of the tip hierarchies, our mental model, move towards stick Dylan.
A shallower hierarchies. I didn’t have a good answer at how do we change. I mostly worked with organisations I’ve already decided to change. Bring me in to help them with training, help them coach, and they’re there already on a path when I have the first conversation with. Yeah, I didn’t have an answer for that. If you have an answer to that, please let me know.
We could get you on. I know at out that topic. So if you’re interested in talking about executive buy-in.
Well, I think that’s all of the content that I had just now. I don’t see any questions coming in. Now let me just check the booth. Oh, there’s only two answers though.
Please ask questions. I have our link to ask questions anonymously. You can also put them in the chat law here, and I will happily answer them.
So if you… It would be really helpful for me if you would subscribe to YouTube. Rubber option button is, and hopefully I will either see you in class soon, hopefully 9 o’clock or so empty, or in another class that we should do. Oh, and if you’re in Atlanta, I am cool. I’m helping facilitate professional from product with Russel Miller. Anta find it on the scrubland org website.
Pretty awesome class, so I think our YouTube up for that if you’re anywhere.
Okay, thank you very much. Naked agility is available for DevOps and agile training and consulting. Contact us for a free consultation.
