Who's Responsible for the Daily Standup?
Ilan Kirschenbaum
A Scrum Master recently asked me: What should he do if the team members don't want to do the daily standup every day? After all, he told me, the daily stand up should happen every day, shouldn’t it?
Well, first thing’s first. One thing you should know about Scrum is, that if you don’t hold the daily standup at the same time, same place each and every day, the Scrum Police will not pay a visit. There will be no embarrassing scenes of people taken, handcuffed, into the Scrum Police car, no paparazzi photographers will be there, taking mugshots of teammates for the Scrum Culprits Weekly magazine front page. None of that, guaranteed.
More important is to understand - why hold a daily standup in the first place? And why same place, same time?
How To Manage the product backlog for 8 teams in 5 important steps?
The product backlog (PBL) is probably the second most important artifact in any LeSS (Large Scale Scrum) \ Scrum implementation, the only artifact I find more important is the product itself.
In a on-team scrum the Product Backlog is pretty much simple (though not easy) to manage, if you follow the recommendation of having each team take 3-4 PBIs (product backlog items) per sprint, this means that the product owner needs to deal with about 12 fine-grained product backlog items at any given time, not all require full attention.
Why 12 you ask?
It is recommended that we have product backlog items refined & ready (AKA groomed) for the next two sprints or so.. Given that we have 4 items in progress, 4 for the next sprint and 4 being refined for the next-next sprint. Total is 12.
Got it? Good :) If not, please feel free to contact in the comments or contact me personally
So far so good, now let’s scale it to 8 teams. (8 teams) x (12 items) = ~100 items, which is what the LeSS Framework suggests to be the limit of items that one Product Owner can deal with simultaneously. I know it sounds like a lot of items to deal with, but it is totally doable when performing the Product Owner role as described in the LeSS framework.
The Large Scale Scrum framework is designed (just like Scrum, mind you) in a way that the Product Owner deals mostly with prioritization and less with clarification, with this description most people agree that 100 Product Backlog Items sounds like a reasonable number.
Assuming that you work properly, at any given moment there are ~33 items in work which require low to no attention, 33 items ready for the next sprint that requires low attention as well, so most of the work is spent on the remaining 33 items, now what should the PO do with these items?
Mainly: Prioritize. Given that you have a 40 hour work week and a two week sprint, that gives more than enough time to prioritize 33 items and even get some more stuff done. Capish?
May the force be with you,
Elad Sofer.
If you are looking for a laid back type of training in which you can stay in your seat and just listen this training is probably not for you. There will be plenty of activities in the duration of the 3 days, some of it will remain a surprise, some of it will be pure fun, some of it will be challenging and difficult, some will take place after the formal training hours…
Q6: Why should i attend a training with you (Elad Sofer)?
I will let others answer this question:
- "Dear Elad, training was very valuable, it was done in a clear and graceful manner. I learned a lot. Thank you for the dedication, professionalism and the knowledge you gave us”, Orna Shapira - Agile coach.
- “The training was filled with useful content, When we focused on LeSS and LeSS hugh i could imagine my organization in most of examples and explanations which very much fit my needs. I have written down at least 10 things i would like to try with my team and my organization and you have given me plenty of food for thought, Thanks." - Irena Label - Cisco
- "Amazing course. Learnt a lot of new and interesting stuff which I'm going to share and implement in my organization." - Alon Cohen - RSA
Upcoming Courses:
Why do I need to play games in retrospective?
Anat Alon
All of the teams I have worked with had come to understand that the retrospective ceremony is a necessary tool when wishing to increase effectiveness. However, many are still struggling to yield valuable action items in these meeting.
I (and every website on Google search) highly recommend using of games during retrospective meetings in order to achieve valuable results. And yet, I am often asked:
“How can I facilitate the retro meeting without these silly games? The team members find these to be a waste of time, and they are certain we can get the same results without them.”
The answer is Yes, and… You probably can, and in order to do that each team member needs to be skilled in creative thinking, able to stimulate and enrich his perspective on his own, as well as capable of challenging his base assumptions. Most team members are not skilled enough to do that.
Games helps us hone these skills, and here is the scientific explanation:
How many Product Owners do you need?
What is the ratio of Product Owners / teams in your organization?
Please, let's play a little game: Before reading this post, write your answer in the comment, just a number, you don't need to explain... do you mind taking the challenge?
Why am i asking? Well… when Scaling Scrum (using the LeSS = “Large Scale Scrum” framework) there is a rule that there should be only one product owner
“There is one Product Owner and one Product Backlog for the complete shippable product”
Here are 4 reasons that explain why:
ROI over ego
It is common that managers in big organizations to try pull the product in different directions as a result of technical and/or political constraints, this causes the system to be sub-optimized and reduce its effectiveness.
Having a single product owner ensures that priorities are driven by business value and not by ego, prestige or other irrelevant aspects, this one person is accountable for the ROI of the product from a whole product customer centric view.
Simplicity over Complexity
When having multiple product owners, it is still required to have another person often from marketing or a similar business unit that is focused on managing and synchronizing the work of the other product owners, in addition to the extra people we need (multiple Product Owners) coordination roles are wasteful and creates additional and unnecessary complexity which should be avoided.
Direct communication over Proxies.
Many will agree that when the developers understand customer needs they deliver better products. Given that Product Owner are mostly busy with prioritizing the requirements, having multiple product owners create a situation in which it is very tempting for the product owner to use her free time and “help” with things such as low level clarification of requirements which is the role of the development team.
This harms the team-customer communication, that can eventually lead developers to develop the wrong requirements, or worst, not care about the customer.
Empowerment over Micro-management
When having one Product Owner per team, it is common that the Product Owner (as a result of free time and the will to contribute) starts interfering with the team’s work, specifically with execution related decisions such as design choices, team members work distribution and micro-status monitoring.
This dynamic is bad for your organization and results in teams taking less responsibility and a drop in motivation.
These are the main reasons i see.
Got other reasons? Disagree? Please comment.
Agile Engineering Practices