Continuous delivery means "keep producing valuable software in short cycles" not "keep producing large amounts of commits to repository" :p
— Piotr Maksimczyk (@AgilePiMa) April 30, 2015
Autor: PiMa
In SCRUM there is no Fibonacci
In SCRUM there is no Fibonacci, planning poker, stand-ups, scrum boards, burn-downs, ceremonies, groomings, and refinement is not a meeting.
— Piotr Maksimczyk (@AgilePiMa) April 28, 2015
My scrum master’s activities are completely invisible
Many times my activities as a SM are completely invisible to teams. They're intentional because the team must feel their success not mine 🙂
— Piotr Maksimczyk (@AgilePiMa) April 27, 2015
Where the hell is diversity?
100% of our teams use planning poker, fibbonacci, jira, 95% use scrum and have review/retro/planning on one day.Where the hell is diversity?
— Piotr Maksimczyk (@AgilePiMa) April 26, 2015
Sprzątanie po niedoświadczonych managerach
Praca SMa w organizacji to często sprzątanie po niedoświadczonych managerach. Gdyby ktoś Ich dobrze nauczył to SM byłby niepotrzebny :p
— Piotr Maksimczyk (@AgilePiMa) April 1, 2015
The only valuable idea
For me the only valuable idea is the one immediately introduced, then tested within a team and/or within a company and/or with real users.
— Piotr Maksimczyk (@AgilePiMa) November 13, 2014
Good vs best scrum masters
Good Scrum Masters teach a team how to be agile in a way close to SM's heart. Best enable the team to be agile in a way close to theirs.
— Piotr Maksimczyk (@AgilePiMa) October 12, 2014
Try this chart to visualize lead time
To visualize PB items' purposefulness (red color), lead time, size, release frequency and some trend try this chart. pic.twitter.com/xKEOZqOLg7
— Piotr Maksimczyk (@AgilePiMa) August 29, 2014
Velocity
If you start your journey towards measuring Scrum team’s agility, it is possible you will find it valuable to measure Velocity. I intentionally called the metric the mother as this is probably the most recognizable metric in an agile world. Yet it’s empirical value is often overestimated. Consider below example.
The team’s velocity is systematically decreasing over time. Does it mean the team is doing less and less work over time? Yeah! Sure! Let’s help them to do more. In fact, you can observe some common pattern. Without usage of reference estimates, stories required the same amount of work, often tend to be estimated with less and fewer story points over time.
The team’s velocity is systematically increasing over time. Does it mean the team is doing more and more over time? Yeah! Sure! Let’s give a bonus to them. In fact in this particular company bonuses are based on teams’ velocities so teams to get higher bonuses play with this metric and estimate the same tasks as higher and higher over time.
In a perfect world, velocity should be used as a planning tool only, for a Development Team to predict how much work can be done in the forthcoming sprint, for a Product Owner to plan consecutive sprints and releases. Assuming your team’s estimates are not changing over time, you can still use this metric during measuring team agility. See the charts below.
The first one is classic Velocity chart showing how many story points is done at the end of a sprint. Vertical bars indicate Velocity calculated in the consecutive sprints. The trend line is in the form of a moving average calculated from last 5 sprints. Take into consideration the “doneness” of points must be calculated according to the actual team’s Definition Of Done.
The second chart is exactly the same data shown not as absolute story points but on a relative scale, where 100% means the highest velocity the team has ever reached. Each time team reaches new highest value, this value becomes new 100% and all old data is being recalculated.
To be more precise, here comes an example of calculation. In last 3 sprints team reached 15, 20, 15 story points. We convert these numbers to 75%, 100%, 75% respectively. In 4th sprint team reaches 25 points, so the new relative numbers are 60%, 80%, 60%, 100%.
This kind of measuring can be used by a Scrum Master as a “raising the bar” tool for which team should be striving for in forthcoming sprints. To be more specific. If a team reaches new 100% Velocity, Scrum Master can ask a team questions like “what can we do better in the next sprint to hold the same high velocity?” and facilitate discussion so the team can improve.
Measuring Velocity can be good starting point for measuring team agility however, this is only the beginning of the journey.
Note! After 2 years since writing the article above, my knowledge in the field of metrics improved dramatically. I highly reccomend yo to read also an article titled Real-life Agility Metrics And Visualizations That Will Lead You Towards Evidence-Based Decision-Making.
Organizational focus
One day, together with Jacek Wieczorek and Maciej Krzywiński we visualized the organizational focus. The idea behind the MAKATKA PRZY ZARZĄDZIE was very simple. On the wall next to the highest management room, we put all organizational goals together with team names which were focused on them as well as all other initiatives with their teams.
It showed that 70% of company teams didn’t work on company goals but rather were focused on other initiatives.
The result was completely unexpected. The highest management removed the visualization from the wall :p
A year later Paweł Rzymkiewicz showed it on the Agile By Example conference.
https://twitter.com/rudygosia/status/527815956903788544