A couple of days ago, I was struck by a colleague’s point about how confusing it can be when listening to people who have strong but conflicting opinions about various agile practices. The remark was brought about by a discussion concerning the pros and cons of different estimation techniques, and whether or not you should even practice estimation at all. It was a great conversation, but I can see how someone with less experience or minimal exposure to the techniques we were talking about could be left feeling very lost. Working out who you should listen to can be a challenge when there is a multitude of people putting forwards seemingly conflicting ideas. As someone who will passionately argue in favour of things like story points, I think it’s crucial to be reminded once in a while that there is no such thing as a one-size-fits-all technique guaranteed to make a process perfect. A lot of factors contribute to the success or failure of a project, and there will always be aspects that are unique to individual projects. There may be an element of politics at the client’s organisation that hinders change, maybe the team is not particularly experienced, or perhaps it’s the polar opposite of both these situations. It’s easy to forget this when debating different techniques and ideas at a conceptual level. You wouldn’t pick a brand new supercar to navigate across rough terrain, and you probably wouldn’t choose an old but reliable truck to speed around a race track. While both machines may be brilliant pieces of engineering, each has its specialism. Some practices are better suited for particular situations, so it’s beneficial to keep this in mind whenever you are taking part in discussions. Software projects tend to be complex endeavours. There are a whole host of techniques and tricks that you can use to help you manage this complexity, and often people will have their favourites. However, you should regularly reflect on how these are serving your team and make adjustments to them as necessary. The crucial point is that you are always asking yourself if your process is working for you and if there is anything you could do to improve it. There is an idea I particularly like that I was introduced to at : we should strive to have strong opinions, loosely held. Strong opinions can be great; they make for engaging and stimulating debate, backed by a passion that’s hard to ignore. But we shouldn’t hold onto them so tightly that we block out all other options and ideas. Made Tech It’s important to be pragmatic when recommending practices to people and be open to alternatives. Just because something did or didn’t work for you in the past, doesn’t mean that it will or will not work for someone else in the future. By all means, share your experiences and thoughts, but don’t sell them as if they are the only choice. Previously published at https://davidcapper.dev/posts/arguing-over-agile

Polar

Visit my blog!

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Arguing over Agile: Let's Get Pragmatic

Too Long; Didn't Read

Company Mentioned

David

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Arguing over Agile: Let's Get Pragmatic

Too Long; Didn't Read

Company Mentioned

David

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES