Jordan Job created a list of
Jordan Job created a list of
Jordan Job created a list of
In the following blog
To demonstrate the power of time-box or Sprint that makes the heartbeat of an agile framework like Scrum.
Type: Team Game
Time Needed: 45 minutes
Number of people per team: 6
The goal of the game is for each team to create as much high quality tested planes that can fly a distance of at least 30 meters . The world record holder last checked in June 2016 was somewhere in Germany
Each iteration last 9 minutes.
Please recycle the paper once done
Original Creator: Not me. I am still trying to find out. I learned it from another trainer.
There are many variations of this game. This is one way I use it in my workshops
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.
When your “tried and true” retrospective format inevitably goes stale, you need a go-to bag of tricks to freshen things up and keep your team engaged. With the help of teammates past and present, Sarah Goff-Dupont rounded up several fun variations to mix in.
Read the complete article here: https://www.atlassian.com/blog/teamwork/revitalize-retrospectives-fresh-techniques
Through our studies, we have found that a lack of true product ownership is one of the main causes of Zombie Scrum. This is puzzling as the Product Owner role as such is clearly described in the Scrum framework. However, you would be hard-pressed to find a company that comes even close to living the role the way it was originally intended. Not because these companies successfully set up the Product Owner role as required by the Scrum Guide and then found out that strong product ownership doesn’t help them solve their problems. For numerous, often very understandable reasons they go a quarter of the way and settle on fitting the Product Owner role into their existing organizational structure.
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
Are you looking for some inspiration or fun games to play with your team? Take a look at http://tastycupcakes.org/
I saw some people sharing their reading backlog and thought it was a fun idea to write mine down as well. Looking back at 2018 I was quite surprised how much books I managed to read.
If you know some books I should add to my backlog, please let me know!
I’m currently updating this post every time I finished reading a book 😉
A small note: I have not prioritized my todo-list, whenever I finish a book I pick something from it I feel like reading at that moment and start.Continue reading “My Reading Backlog”
The Professional Scrum with Kanban (PSK) course has now been out for more than 6 months at Scrum.org. As one of the first few trainers who wanted to teach this course when it came out, I find that it is a great way to combine the Scrum framework with Kanban as a strategy to deliver value to your customer.
Out of the many topics that we talk about in this class, I’ve found that the use of throughput instead of velocity/capacity to be a positive change. I’ve taught the regular Professional Scrum Master (PSM) course for about 6 years now and when I get to the Sprint Planning slides, we usually extend the conversation around velocity and capacity. I pull up my complementary slide deck around relative estimation, poker planning, charts to track velocity and we spend an additional hour on this topic. I answer questions around the meaning of story points, how they should be understood, tracked and used in multi-team Agile project.
In the PSK class, this conversation is completely different. When I get to the Sprint Planning slides, I point out that the throughput history is used as an input to the Sprint Planning. With a few examples, I show how easy it can be to get from your electronic Agile tracking system (Ex: Jira) or on your physical Kanban board.
I then get a new set of questions from students which I find a lot more interesting. The conversation goes quickly around the variation in the size of the Product Backlog Items (PBIs) that are taken by the team at Sprint Planning. I can also tie it back to Little’s Law where limiting work in progress will increase throughput, thus helping students see throughput linked to limiting work in progress. There are very few questions around understanding throughput. Students find it is a metric that makes sense to the business compared to story points.
While our industry has talked about poker planning and story points since almost the beginning of agility in 2001, I think it is more than time that the conversation at Sprint Planning shifts to historical throughput instead of using velocity. Maybe one day in the software engineering museum, we can see a deck of poker planning cards next to a set of punch cards.