Why Should We Be Agile? A Slack Takeover with Griffin Jones
Thought leaders throughout the software community are taking over the TechWell Hub for a day to introduce themselves, answer questions, and engage in conversations.
Agile coach and consultant Griffin Jones presided over the first Slack takeover, which led to some insightful discussions. Here are some of the top questions and takeaways that happened in the TechWell Hub.
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 is yet to 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 analogy comparing agile versus waterfall to cooking versus 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 dialogue and provide honest feedback. @Janna Loeffler feels you should make sure you’re implementing agile processes for the right reasons, not just because they 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 an open space, teams put the individuals first, figure out their people’s needs, and can implement agile strategies based on team feedback.
Of course, there might be team members who never buy in to becoming agile, so Jones said you may have to step in, have the “This does not seem to be working” conversation, and help find an alternative.
What Should We Consider for Story Estimates?
“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. With immature teams, @Artem Fomin suggests disassociating story sizing from numbers and using another metric, like dog breeds (six breeds, from chihuahua to Great Dane), instead. 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?
