We were used to a long sales chain for IT products and services, from vendors through distributors to resellers.
Frankly speaking this sector was and is largely drugged. The system of long chain works, in part, when it comes to products, losing sense in respect of digital distribution. To continue the chain drug operation we did a make-up from vendors, distributors and retailers to vendors value added distributors (VADs), value added resellers (VAR).
How many times you will ever hear a sentence like this: “Guys we have an urgency, we must prepare a presentation”?
“Ok no problem, what are the topics?”
“We have a rough idea of what might be of interest to the customer, but we need to talk”
“Ok, and when it’s needed?”
I am not talking about a hypothetical situation, but a real case. The following is a practical approach for the preparation of a shared presentation.
Jim use his experience and knowledge to explain how Cognitive Bias affect us in our decision making process and specifically in business management and leadership. This book is really mind opening and explains some of the major reasons behind failed people interaction.
- It is when the Scrum Team and stakeholders inspect the outcome of the Sprint and figure out what to do in the upcoming Sprint.
- It is a demo at the end of the Sprint for everyone in the organization to provide feedback on the work done.
- It is a review of the team’s activities during the Sprint.
- It is used to congratulate the Development Team if it did what it committed to doing, or to punish the Development Team if it failed to meet its commitments.
False: It is a demo at the end of the Sprint for everyone in the organization to provide feedback on the work done.
The Sprint Review Meeting is an event happening between the Scrum Team (Product Owner, Scrum Master, Development Team) and the stakeholders. The goal is not to let everyone in the organization to provide feedback about the outcome of the Sprint. The Sprint Review is not even a “demo”, for sure some of the increments delivered at the end of the Sprint will be demoed by the Development Team but this is just part of the Sprint Review Meeting goal.
- 1 day
- 4 hours for a monthly Sprint, proportionally less for shorter Sprints
- 2 hours
- As long as needed
False: 1 day
Having 1 day Sprint Review meeting could lead to too much planning and so introducing waste in the process.
- The Development Team.
- The Development Team and Product Owner.
- The Scrum team.
- The Development Team and Scrum Master.
- The Scrum Master and Product Owner.
False: The Development Team and Product Owner.
The Development Team is for sure required to not just attend the Daily Scrum but also to manage it. The Product Owner has no direct involvement over the Daily Scrum, he could attend it has external with no voice right but it’s absolutely not required to attend.
- Rooms are hard to book and this lets it be booked in advance.
- The consistency reduces complexity and overhead.
- The place can be named.
- The Product Owner demands it.
False: Rooms are hard to book and this lets it be booked in advance.
For sure for some companies room booking is an issue. Anyway this is not a valid reason why the Daily Scrum must be held at the same time and the same place. This may be an impediment the Scrum Master should work on to facilitate Development Team Daily Scrum event.
- The event must take at least a minimum amount of time.
- The event must happen by a given time.
- The event must happen at a set time.
- The event can take no more than a maximum amount of time.
False: The event must take at least a minimum amount of time.
Inside Scrum the scope of event timeboxing is to limit the maximum amount of time an event could take.
- A cookbook that defines best practices for software development.
- A defined and predictive process that conforms to the principles of Scientific Management.
- A complete methodology that defines how to develop software.
- A framework within which complex products in complex environments are developed.
False: A cookbook that defines best practices for software development.
Scrum goal is not to be a cookbook to define best practices for software development. Instead Scrum is a framework within which complex products in complex environments are developed. While good software development engineering practices like Test Drive Development and Continuous Integration are strongly suggested Scrum itself doesn’t impose them in any way.
- To monitor the Development Team’s productivity.
- To continually monitor staffing levels of the Development Team.
- Management supports the Product Owner with insights and information into high value product and system capabilities. Management supports the Scrum Master to cause organizational change that fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of software.
- To identify and remove people that aren’t working hard enough.
False: To monitor the Development Team’s productivity.
Maximizing and optimizing Development Team’s productivity toward the ROI is a Product Owner role. The Management is not directly monitoring any of the Development Team activities.