Implementing basic Scrum at team-level is prerequisite for Scrum Scaling. Scaling Scrum without addressing the organizational and technical problems to implement Scrum at first place is distraction from resolving real problems.
Moreover, Scaling of flawed Scrum will amplify waste and technical debt while continuing having inadequate products.
Startups should not implement the practices common in existing companies because they are not not smaller version of large companies. The LS movement is aimed to establish appropriate practices for startups which are different from what MBA graduates learn in business schools. Thanks to Steve Blank who has articulated the philosophies and principles in his web, videos, books and others. Continue reading
User stories creation is a useful mechanism for expressing product features collaboratively. However, having sprint goal as list of user stories, based on team velocity, from my view reduces the business value of the sprint. Continue reading
The setup is a project involving sub-contractors from different vendors working in highly regulated industry.
The objective is how to make these diverse skills work as self-organized team?
The challenges are:
– Strong command and control culture.
– Non streamlined views on how work needs to be done.
– People work independently with fear to become inter-dependent.
For large organizations, projects are often characterized of being:
- Involve people from various departments with separate reporting structure.
- Involve contractors from multiple vendors.
- Introduce technology which is unfamiliar to the employees.
- General disagreement or even lack of appreciation of the project approach.
- Multiple chiefs and puzzled doers.
- Software development is sub-component of the project. Continue reading
Once I read that a project plan without risk assessment is a kid’s plan. Scrum is great framework design around “continuous risk mitigation” or probably avoidance.
Organizations who run projects in “command-and-control” mentality and making transition to Scrum are challenged and normally resort to ScrumBut implementation. ScrumBut is a low-fidelity flavor of Scrum which for me can be worst than command-and-control as it deprives the organization from doing full-fledged risk management.
Risk management is a proactive critical component in either Agile or traditional world. Agile project management de-emphasizes formal risk management. Because if Agile is adequately implemented then all benefits of doing risk management are attained. From my view, good Agile implementation can provide results which far exceed the implementation of formal risk management.
ScrumBut is where the organization wants to move to Agile but held back by its legacy of bureaucracy and inefficiencies. ScrumBut is where leadership is in the test and instead we have mediocre people who try to survive by implanting waste. That waste creates environment where morale is low and is characterized by excessive motion but with little accomplishment.
For ScrumBut I highly recommend going back to the basis of pro-active project management which can be implemented through effective risk management at various levels including:
- sub-contractors, and
Ignoring formal risk management in ScrumBut creates domino effect of spiral project failures, because of losing the pro-activity which is the back-bone of Scrum.
I had a meeting with a new Scrum team which already had business/analyst, before transitioning to Scrum, who was designated as the product-owner (PO). He was one of the most participating attendees in my Scrum class which I deliver to more than 150 employees. Continue reading