The 25 Best Agile Graphics from Vitality Chicago

Since founding Vitality Chicago in 2015, we’ve published nearly 200 blog posts. Most of them have included a great graphic or image that is meant to convey some truth about Agile.

The creative talent behind the graphics is Hazel Fernando. Hazel has been with us since the beginning and she is the creator of nearly all the graphics and designs we use for blogs and social media.

Best 25 Agile Graphics of All Time (so far!)

Here are my top 25 graphics from the last 5+ years. I’ve ranked them based on 1) popularity of the blog post and 2) how much I like them! So, counting down from 25 we have…

#25 – Why Scope Creep is Complete Bullshit

The graphic shows a fictitious monster threatening a team. And Scope Creep has become just that – a made-up monster intended to strike fear into teams. The threatening term is applied to the gap between what people think they need at the start of a project or initiative, and what they find they actually need later. It is probably why the Agile Values included the statement, Customer Collaboration over Contract Negotiation.

The main point of this blog is that Scope Creep is an outdated concept. It MAY apply to projects with a clearly defined plan and scope upfront, for example, constructing a house or a bridge. But it is a bullshit concept when it comes to technology projects that include a fair amount of uncertainty. And people should stop using it in the context of those tech projects.

Check out the blog post here: Why Scope Creep is Complete Bullshit

#24 – The Impact of PMI’s Acquisition of Disciplined Agile

After the announcement of the purchase back in the fall of 2019, things were quiet for about a year as the big fish ingested the small fish. But things are not quiet any longer with the announcement of 4 refined Disciplined Agile Certifications in Q4 of 2020. It should be clear that PMI and Disciplined Agile is now a big fish and should not be ignored.

Check out the blog here: The Impact of PMI’s Acquisition of Disciplined Agile

#23 – Fight, Flight or Freeze – How Technology Leaders are Showing Up Now

Without a doubt, 2020 was a crap year.  The pandemic caught everyone by surprise and caused amygdala hijackings for most of us.

The amygdala normally has a backseat role in our decision-making. But when we are stressed our or under attack, the amygdala will often step in and take charge. And since the amygdala acts faster than our executive brain, it often gets it’s way.

Back in May of 2020, I noted that Technology leaders seemed to be choosing one of 3 reactions to the COVID pandemic – Fight, Flight, or Freeze. You can explore the implications of each of these responses here: Fight, Flight or Freeze – How Technology Leaders are Showing Up Now

#22 – Help Your Agile Team Overcome Learned Helplessness

Learned helplessness is the act of giving up trying as a result of consistent failure to be rewarded in life, thought to be a cause of depression. It can be seen in organizations where people give up trying to improve or change things.

The antidote to learned helplessness is the Growth Mindset. First identified by Carol Dweck in her book Mindset, the growth mindset is a shift in thinking that leads to growth, learning, and hopefulness.

Check out the blog here: Help Your Agile Team Overcome Learned Helplessness

#21 – It’s “Almost Done”

Almost done is a misleading status. Here are some specific things you can do to avoid using the status of “almost done”:

• Get Binary
• Create a Team Definition of Done
• Stop Using Hope as a Planning Tool
• Reduce Work In Process
• Mark the items as Not Started Instead
• Break those Items Down into Smaller Items

You can learn more about what these mean in our blog here: It’s “Almost Done”

 

#20 – There Are Too Many Scrum Meetings

One of the most frequent complaints I hear about Scrum is that there are too many meetings in Scrum. However, if done correctly, there should be a maximum of 16 hours of meetings for a 2-week sprint or 20% of a team’s capacity. And those are timeboxes so they represent the maximum and teams can use less time.

If your team members complain about too many meetings, I am willing to bet they are assigned to more than one team. That’s not going to help your productivity (see item #4 below).

You can stop that counterproductive behavior of assigning people to multiple teams. Or you will have people going to a bunch of meetings only to report that they didn’t get anything done because they were too busy attending meetings. Your choice.

Check out the blog here: There Are Too Many Scrum Meetings

#19 – Hey Scrum Masters, You’re Not the Jira Lackey!

Many Scrum Masters today don’t really understand the Scrum Framework very well and see their job as mainly a team administrator.  They’ve become the “Jira Lackey” for the team, which means that much of their time and effort is spent on updating items in the online agile tool, sharing Jira on their screen for meetings, creating nifty dashboards, and running reports. I just want to scream at them, “Hey Scrum Masters, you are not the Jira Lackey!”.

Check out the blog here: Hey Scrum Masters, You’re Not the Jira Lackey!

 

#18 – The Circus of Agile Certifications…And a Challenge

Early in 2020, I made a decision to make a comprehensive list of all the possible agile certifications. I was shocked to learn that there were over 250!

I made it my goal to learn as much about those certifications as possible and vowed to get one new certification per week in 2020. I got 12 new ones before giving up the quest when COVID struck.

Learn more about the known  agile certifications here: The Circus of Agile Certifications…And a Challenge

 

#17 – Stop Hovering Over Your High Performing Teams

I was sad to see a certain set of managers at a company who were directly involved in what each person on their team did. The team members were grown-ups, fully adult, and they were experienced software development professionals. Yet the managers still got involved in every small decision. They hovered over the team members like helicopter parents.

Check out the blog here: Stop Hovering Over Your High Performing Teams

#16 – Creating Reality-Based Forecasts in Agile Projects

Creating forecasts that are surprisingly accurate is not difficult. You simply need to use the team velocity, the team’s estimate of the backlog to be delivered and some common sense to create a forecast that is grounded in reality.

Check out the blog here: Creating Reality-Based Forecasts in Agile Projects

#15 – Project Managers Make Lousy Scrum Masters

The skills needed to succeed as a project manager are very different than those needed to be a Scrum Master. Unfortunately, many people overlook this and think that success as a PM will mean success as a Scrum Master. That usually backfires.

Learn more here: Project Managers Make Lousy Scrum Masters

 

#14 – Using the Scrum Framework? Don’t burden Scrum Teams!

This blog was inspired by the amount of overhead I noticed at a client. For every Scrum team member, there were a number of other “helpers” who were involved but not directly involved in producing anything.

Instead, those extra people directed team members to work on different things, called meetings to gather status, churned requirements, changed priorities or introduced urgent requests, and generally created distractions and unnecessary work for the Scrum Team.

To the extent that the external parties remain directly involved, they slow the scrum team down. The higher the ratio of interested parties (i.e. weight on the boat) to those doing the work (i.e. rowing the boat), the slower the team will go.

Check out the blog here: Using the Scrum Framework? Don’t burden Scrum Teams!

 

#13 – Scrum Masters Need to be Good Listeners

I was at a client site and sitting near a Scrum Master when I overhead a series of his phone meetings. In addition to speaking loudly, I noticed that the Scrum Master talked a lot. Not just occasionally, but continuously through the meetings. If I had to guess, I’d say he spent 80% of his time talking and 20% listening. Does that seem right to you?

As a Scrum Master, listening is one of the most important tools in your toolbox. While there are reasons for the Scrum Master to speak up, in general, Scrum Masters should be listening significantly more than they are speaking.

Here are some specific action steps that Scrum Masters can take to overcome the tendency to speak in those meetings:

1. Track Your Talk Time with a Tally Sheet.
2. Record Your Meeting and Listen
3. Ask Others what they thing
4. Try Not Speaking at all
5. Bring in an Observer

Check out these tips in the blog here: Scrum Masters Need to be Good Listeners

 

#12 – Tips for an Effective Daily Scrum Meeting

This diagram was somewhat self-explanatory. Rather than being the hub of communications for a team, the Scrum Master should encourage good communications among team members. Easier said than done, but quite necessary.

Check out the blog here: Tips for an Effective Daily Scrum Meeting

 

#11 – Stop Snowplowing in Agile

One of my clients a few years ago shared their frustration with Scrum. Their brand new agile team was assigned a fixed scope of work to be completed over a fixed number of sprints.

As the team was new, things did not go according to plan. Rather than adjust the plan for the reality of the situation, the managers simply pushed out the work that was not completed in the first two sprints and added it to sprints 3-5.

Learn what happened next here:  Stop Snowplowing in Agile

#10 – How to Successfully Transition from Waterfall to Scrum

Moving your organization from waterfall to agile is a simple leap of faith, right?

I wish! Making the change to the Scrum Framework is not simple. Many organizations have tried and failed. In the downloadable guide, I’ve outlined some of the patterns that have led to success as well as pointed out some of the common traps that others have fallen into.

Though there is no one perfect pattern, by following these guidelines and running small experiments, you too can successfully navigate the change from what you are doing today to success with Agile and Scrum.

We recommend an approach that consists of Planning, Training, and Coaching. And then Iterate.  You can download a step by step guide for free – learn more here: How to Successfully Transition from Waterfall to Scrum

#9 – The Messy Middle Ground of Agile Transformation

While moving from waterfall to agile does require a leap of faith, the leap in the previous image looks like a straight line. And it also looks like going from waterfall to agile is pretty quick. These are not characteristics of agile transformations.

That whitepaper referenced in the previous item has been downloaded over 500 times. While I hope that at least some of the agile transformation steps I wrote in that paper were helpful, I don’t think the cover image was very accurate.

That image and my description don’t accurately portray the difficulties that organizations experience in trying to adopt agile. That process is not quick and it nothing like a straight line – leaving one thing and arriving at another.

Now with some hindsight, I have come up with a better depiction of how many leaders feel about moving from waterfall to agile ways of working. Read about how many organizations are stuck in the middle ground here: The Messy Middle Ground of Agile Transformation

#8 – Challenges with Agile – Organizations that Don’t Want to Change

We all know how hard change can be. As an Agile Coach, you didn’t expect things to be easy. But what do you do if you begin to feel that change is impossible, and everyone in the organization is working against you? What if it looks like things are actually getting worse instead of improving?

Read about a coach that I know that tried to do the right thing but was fighting an uphill battle: Challenges with Agile – Organizations that Don’t Want to Change

#7 – What Makes an Agile Coach Effective

You cannot coach someone who doesn’t want to be coached. And, that desire to be coached is based on trust.

Learn about trust and about how to become an effective coach here: What Makes an Agile Coach Effective

#6 – Story Points – Love Them or Leave Them?

Story points are a popular way to use relative estimating with agile teams. I like them because they are fast and accurate enough.

Others avoid story points and just use item counts and cycle time or throughput accounting.

Still others prefer to work with hourly estimates. (I find that those waste people’s time, cause more disagreements, and tend to lead to micromanagement and undesirable behaviors by team members and managers.)

The worst approach is to use both story points and hours and convert back and forth between points and hours.

You can learn what to use and what to avoid here:  Story Points – Love Them or Leave Them?

#5 – You All Just Got Punched In The Face – Now What?

A wise man once said, “Everyone has a plan until they get punched in the face.”

And yeah, I felt like I got punched by Mike Tyson in 2020 and I suspect a lot of you did as well.

The question is, what did you do next?

Check out the blog here: You All Just Got Punched In The Face – Now What?

#4 –For High Performing Teams, Stop Assigning People to Multiple Teams

This blog post was mentioned earlier. For many people, they think that they can get more done by spinning up more teams and assigning people to more than one team.

Except it doesn’t really add capacity to your organization. You cannot go any faster or get any more done by starting more projects and more teams.

What does happen is that your people will be busy with context-switching and attending multiple projects or Scrum Meetings. So they will get a lot less done.

Stop assigning people to multiple teams. Learn more here: For High Performing Teams, Stop Assigning People to Multiple Teams

#3 – How to User Story

User stories are extremely popular with agile teams and have become nearly synonymous with agile ways of working and Scrum, even though they are not part of the Scrum Framework. Unfortunately, when used incorrectly user stories are one of the worst ideas to come out of agile.

A recent conversation with a client revealed misuse of user stories that I don’t think is unique to that client.  The approach can be best demonstrated in the illustration shown above. Learn more including what not to do here: How to User Story

#2 – Downloadable Agile Principles & Scrum Cheat Sheet

Our downloadable tip sheet got even better this year with an overhaul from Hazel Fernando, artist in residence. Hazel added more graphics and simplified the language to make it look great and read well.

Check out the blog and download your own copy here: Downloadable Agile Principles & Scrum Cheat Sheet

#1 – There Is No Spotify Model for Scaling Agile

My number 1 pick for best image is this one about the Spotify framework. One of the key features of Spotify’s approach (circa 2012) was the Chapters, Squads, Guilds, and Tribes. And that is also one of the most copied elements of what Spotify was doing.

Unfortunately, you cannot copy-paste that into your organization and become Agile like Spotify. It just doesn’t work; don’t even try. Don’t say you are adopting the Spotify Model because there isn’t one.

What you can do is run experiments. You can also take a hard look at those cultural elements that made Spotify successful and see what you could do at your company. Learn more about experiments and culture in the blog here: There Is No Spotify Model for Scaling Agile