Irene Francés likes to share a board that she has been working on during the last couple of weeks. It is meant to capture the main agile resources she came across and found useful. https://loom.ly/7-gQgjs
Health checks for Teams and Leadership
In this blog post, Jimmy Janlén wants to share a powerful tool, the Leadership Health Check. It will help you become stronger as a management team and reveal improvement opportunities for how you, as a team of active servant leaders, better can enable the agile teams you support.
You can find the blog post here: https://blog.crisp.se/2019/03/11/jimmyjanlen/health-checks-for-teams-and-leadership
The Reading List for Agile Newbies
Barry Overeem created a list of must-reads for agile newbies:
The Agile Manifesto
The Scrum Guide – Jeff Sutherland, Ken Schwaber
The Power of Scrum – Rini van Solingen
Scrum: A Pocket Guide – Gunther Verheyen
Succeeding with Agile – Mike Cohn
The Agile Samurai – Jonathan Rasmusson
The Five Dysfunctions of a Team – Patrick Lencioni
The Scrum Field Guide – Mitch Lacey
The Phoenix Project – Gene Kim, Kevin Behr, George Spafford
Kanban – David J. Anderson
Clean Code – Robert C. Martin
Read his complete blogpost here: http://www.barryovereem.com/the-reading-list-for-agile-newbies/
Six Agile Product Development Myths – Busted
In this article Mike Cohn busts six agile product development myths:
- Myth #1: Isn’t Agile Just for Software Development?
- Myth #2: Is It True That Managers Have No Role in Agile?
- Myth #3: Can’t Stakeholders Introduce Change Whenever They Want?
- Myth #4: Doesn’t Everyone Need to Be a Generalist on an Agile Team?
- Myth #5: I’ve Heard that Agile Teams Don’t (or Can’t) Plan.
- Myth #6: Don’t Agile Teams Create Products with No Architectural Plan?
Find the complete article here: https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted
Bootstrapping a Working Agreement for the Agile Team
Bootstrapping a Working Agreement for the Agile Team is a simple, yet powerful practice every team should have! Read about it here: https://blog.crisp.se/2018/12/05/jimmyjanlen/bootstrapping-a-working-agreement-for-the-agile-team
Five Fundamental Questions to Assess your Agile Process
Barry Overeem writes about the five fundamental questions to assess you agile process in this article: https://medium.com/the-liberators/five-fundamental-questions-to-assess-your-agile-process-376b9230c7d8
- Value. Do we know the value we seek to deliver and are we consistently delivering the maximum value?
- Flow. Do we understand how we reach that value and are we consistently reducing the time and/or increasing the ease by which we reach it?
- Quality. Do we understand how good our product and workmanship needs to be and are we consistently and demonstrably achieving it?
- Joy. Do we know what we collectively and individually need to be joyful and are we consistently meeting those needs?
- Continuous Improvement. Do we know what we need to improve across value, flow, quality and joy and are we demonstrably pursuing those improvements?
7 Key Factors for Scaling Agile in Large Organizations
Agile adoption has grown from a small number of agile teams within an organization to many agile teams, larger teams, and entire organizations themselves, bringing a new set of challenges and complexities. Regardless of the framework, some important factors play a major role in making large-scale agile adoption successful. Here are seven aspects you should consider when scaling agile across an organization.
- Executive leadership support
- Knowledge acquisition
- Engineering excellence
- Tools and infrastructure
- Communities of practice
- Integrating nonsoftware teams
- Agile champions and change agents
Read the complete article here: https://www.agileconnection.com/article/7-key-factors-scaling-agile-large-organizations
Common or severe Agile mistakes
Mike Cohn from mountaingoatsoftware.com mailed a nice list of common agile mistakes:
Being way too ambitious in how much work was selected for the next iteration. A few people reported doing this even in the absence of management pressure to do so.
Trying to facilitate a meeting using someone else’s style. We each have our own style. Use that. Teams recognize when we’re pretending we’re someone else and facilitating with their style.
Holding meetings or other events at the wrong times. A few people reported doing sprint reviews a few days early, but then not having everything ready to demonstrate.
Telling people what to do. This seemed like a common problem, especially for any of us who worked as traditional project managers before adopting an agile approach. Other Scrum Masters reported the opposite problem, saying they remained too silent during team discussions.
Letting a story into the sprint without enough clarity about what was needed. A few people emailed that this happened because a product owner pushed for the story to be included. Others, though, said it was the team that wanted to bring the story in despite a lack of clarity.
Trying to fill every hour with planned work during sprint planning. Some teams fear an unallocated hour. When sprint planning seems done but a few people have extra hours, they planned work into those hours and then learned they’d overloaded the sprint.
Not asking enough questions. A couple of Scrum Masters said they didn’t ask enough questions. I’m pretty good at that by now, but early on, I would literally track the number of questions I asked versus the number of statements I made in each meeting to try to improve.
Forgoing the usual meetings because the team size was small. A few people replied to say they took the already-lightweight Scrum framework and lightened it further by leaving out some meetings because their teams were 2-3 people. They learned this was a mistake and that even small teams benefit from every Scrum event.
Not pushing teams a little harder at improvements they’d decided to make. In their retrospectives, some teams chose to improve at things like demonstrating to users more often or improving collaboration between coders and testers. And a few of you said you didn’t push your teams hard enough to make the improvements they’d chosen themselves.
Allowing too much discussion into the daily scrum. A few Scrum Masters and coaches emailed to say they changed the format of the daily scrum away from the standard three questions, and that didn’t work as well. Other said they let teams discuss problems too long and daily scrums started to take much longer. Another had let the daily scrum turn into a design meeting.
Not letting go of a mistake. A number of people said that they tend to replay mistakes in their heads or let mistakes gnaw at them. Once the mistake has been made, learn from it. Then let it go.
The illusion of agility (what most Agile transformations end up delivering)
Watch the inspiring video from Gunther Verheyen here: https://guntherverheyen.com/2019/01/07/the-illusion-of-agility-what-most-agile-transformations-end-up-delivering/
Some inspiring quotes from the video:
It is not a transformation if it doesn’t change how you work
– Gunther Verheyen
It is not an Agile transformation if it doesn’t simplify how you work
– Gunther Verheyen
TastyCupcakes.org
Are you looking for some inspiration or fun games to play with your team? Take a look at http://tastycupcakes.org/