Why Should We Be Agile? A Slack Takeover with Griffin Jones
Tags: Slack, Software Development, DevOps, Agile, Software

by Owen Gotimer

Back in August 2018, I flew down to TechWell HQ to meet with our media team and brainstorm ideas that would help us grow and nurture a community of passionate software professionals.

One of the ideas we all liked was some form of expert takeover. We had seen companies give employees control of their Instagram for a day so they could share behind-the-scenes looks into their days.

How could we use that same concept in the tech space? Boom! The TechWell Hub Slack Takeover was born.

Basically, we’ve been inviting thought leaders throughout the software community to takeover the TechWell Hub for a day to answer questions, engage in conversations, and introduce themselves to the community.

Griffin Jones joined us for our first Slack Takeover which led to a few insightful conversations, so I wanted to highlight some of them.

Why should we be agile?

“How should someone approach explaining what agile is and why agile?” –@Parveen

Getting your team to understand why being agile will help is one of the keys to a successful agile transformation. @Griffin Jones used three points to explain the differences between waterfall and agile:

— Waterfall works well if we know exactly what we want; Agile works well if we think we know what we want but part of what we want will be discovered

— Waterfall works well if we know how the future will unfold; Agile works well if we are unsure of how the future will unfold

— Waterfall works well if we can get huge efficiency by doing lots of upfront planning; Agile works well if we are willing to be a bit inefficient in order to be more effective

@David Kramer offered an awesome analogy comparing agile vs waterfall to cooking vs baking. With cooking (agile), you can sample as you go along and adjust, but with baking (waterfall), you put the ingredients in the oven and hope for the best.

How do we keep from reverting to a pre-agile mindset?

“As we transform to be more agile, what are some team culture lessons you can share that will help our team members shift their mindset to not go back to the way we used to do things? ” –@brookser

When implementing agile, it’s important to create a space where team members can have open dialog and provide honest feedback. @JannaLoeffler feels you should make sure you’re implementing agile and agile processes for the right reasons and not just because it worked for someone else. If teams feel frustrated or blocked, they will revert to their old ways because they are comfortable with them. But by creating a space for open and honest conversations, teams put the individuals first, figure out the needs of their people, and can implement agile strategies based on team feedback.

Of course there might be team members who never buy-in to becoming more agile, and @Griffin Jones suggests being open and letting people choose the road they want to take. However, there are situations where Griffin feels you have to step in, have the conversation of “this does not seem to be working,” and help that individual find an alternative.

What should be considered for a story estimate?

“Estimating story points leads to long-winded discussions on our team regarding what should be considered for an estimate. All discussions inevitably lead to ‘well this is simple not complex, but it’s time involved, so do I estimate higher?’ How would you recommend steering the conversation away from time or is it a losing battle?” –@samn

Estimating — or not estimating — story points is a hot topic in agile. Some agilists suggest not using numbers to estimate story points at all. With immature teams, @Artem Fomin suggests disassociating story sizing from numbers and using another metric like dog breeds (e.g. six breeds from chihuahua to Great Dane) instead. If a story is complex, risky, and involves a lot of effort, it would be a Great Dane, whereas a simple, quick story would be a chihuahua. This approach allows teams to decouple story points from the hours spent on tasks.

@David Kramer suggests setting baselines for the simplest and most complex stories to give boundaries to estimates. Where does the story fall in comparison to the simplest and most complex stories in the project?

How can you participate in a TechWell Hub Slack Takeover?

We are busy scheduling experts to takeover the TechWell Hub and share their ideas with the community and have three takeovers scheduled for February:

Up Next: Johanna Rothman | February 6

On Deck: Janna Loeffler | February 21

On Deck: Michael Bolton | February 28

Join the TechWell Hub at hub.techwell.com to connect with @Griffin Jones, @JohannaRothman, and the rest of our global software community. Hope to see you there!