Many times people find unexpected advantages and benefits from Product features which was never intended in the product design. You may not call it by-products but they may deliver great value in specific contexts.
We all know the features, advantages and benefits of SCRUM as it was designed for. Managing chaos and minimizing risks through iterative development in the face of volatile requirements and a high degree of unpredictability in a software solution development environment. SCRUM was intended to be a carefully crafted strategy to help teams “inspect and adapt” in fast changing volatile situations. This was expected to be achieved by empowering a cross-functional self-organizing team and supporting them accomplish a set of defined goals in an empirical process environment, incrementally and iteratively.
For this strategy to succeed, organizations implementing SCRUM had to invert their pyramid structure, nurture and reward team-work and group accountability through a management process driven by “servant leadership”. This would entail management stakeholders to empower and support a cross-functional team, provide them the right work environment, leadership and motivation to enable the team self-organize themselves through collaborative leadership and accomplish their goals.
Who flipped SCRUM ?
This helped them discover the power of Scrum. They now took this to the development teams in a distributed development environment, gave them a clear set of requirements, a clear product design and expected them to use Scrum to build the product as per specifications. They found that if they had these development teams implement “30 day Iterations” and hold “daily stand-up meetings”, they could monitor the progress of development more effectively. They also found that using Scrum, the development teams could escalate the issues affecting their “productivity” timely to the management which helped them take timely corrective and preventive action. This enabled the management reduce the cost and time of development significantly and generate a higher degree of assurance and predictability of the product development phases (coding, testing, integration and release management)
The Product Development contexts here were very stable, with Product Requirements and Product Architecture well understood and meticulously planned and designed for its integrity, performance and quality. They were only aspiring for ways to have it built most efficiently, with least cost and time.
Product Managers found that wrapping Scrum practices over the existing traditional management and engineering practices of their development organizations, helped them micromanage development teams and their productivity. This also reflected in a set of clear results for them and they found that by keeping both the teams and their managers on their toes, every day, every iteration, they were able to save on costs and time significantly, as also generate an ability for them to track the progress of development with each iteration. This gave them confidence, predictability and assurance of the progress in product development so crucial for Product Release Planning and Product Management. They had flipped Scrum and made it work for them.
Why Flipped Scrum ?
The implementation of Scrum in the development environment was different. Teams were not empowered and self-organizing. Managers were micro-managing the team and were necessarily not servant-managers. The process formality was high and clearly defined. Productivity and Progress was tracked by the team, by the managers and by the product management stakeholders fervently and metrics generated to prove results.
Teams were told what to do, how and when based on the predefined release plans and individual productivity metrics (team velocity). They were managed, supervised and controlled by their managers who were held accountable for the execution of the Iteration Plans and the Release Plan as per baselines approved. They did that, it worked and they called it Scrum.
They had Product Managers playing the role of Product Owners cutting, copying and pasting “stories” into the product backlog from clearly inspected, approved and baselined Product Requirements Specifications. The stories reflected the development of each Feature based on clearly inspected, approved and baselined Product Architecture and Design Document. Many stories actually looked like “Tasks” well defined, coordinated and structured for the teams to implement and build them in the 30 day iterations.
Project Technical Leads were appointed as Scrum Masters to supervise the teams on a daily basis and escalate to the management the issues reported by the team members in daily stand-up meetings. The Scrum Masters were made accountable and responsible to ensure that the team delivers the features given to them for development for one iteration, at the end of the iteration.
Product Managers, acting as Product Owners, thus would receive the features developed by the development teams incrementally and they could send these deliveries to the Product Testing teams for validation. Bugs reported by the Testing Teams would be sent back to the Development Teams as new stories added into their Product Backlog. Not to mention that this enabled the Product Managers and the Development Managers to track the quality of work being done by the development teams in terms of bugs per stories and haul them up for it. Real tight control over the scope, quality, time and cost of product development was achieved in a distributed off-shored environment.
Teams here religiously perform all the Scrum Ceremonies. Iteration Planning is done by Scrum Masters in line with baselined Product Release Plan. They hold daily stand-up meetings in lieu of filling timesheets. They are encouraged to report or escalate issues they face in doing what they are doing. The progress in compiled by the Scrum Masters and reported to their Management on a daily basis. Scrum Masters maintain the Sprint Backlog, create and assign tasks to team members, update it on a daily basis based on reports at stand-up meetings and populate the burn-out charts. Scrum Masters take timely corrective and preventive actions to ensure burn-out charts are burning out correctly.
Product Managers give the Scrum Masters the Baselined version of Product Requirements Specification Document and the Product Architecture and Design Document. They are asked to convert this into stories and populate the Product Backlog for the team as per the agreed sequence in the pre-defined Release Plan.
Teams are brought in into Sprint Retrospectives after each Iteration Delivery and Scrum Masters along with Management Stakeholders tell the teams what went right, what went wrong and what they should be doing in the next iteration to ensure that the next iteration is always better than the previous one. And so goes the continuous improvement in software development.
They love this type of Scrum and so do I. It adds value to the Product Management Stakeholders in Micro-managing product development efficiency in a distributed product development environment. It helps all of them to save more money and more time. So why not let them use Scrum this way.
Let me call this new product “ Scrum-F ” to mean Scrum that has been flipped. This may be the best discovery and process innovation of the decade we are in. We already have Scrum-A, Scrum-B and Scrum-C defined and published by Jeff. So Scrum-F should be able to live undisturbed.
Have a great time flipping SCRUM !!!
As long as it adds value to you, it should be a great thing to do.
1 comment:
I felt it prudent to copy paste here a response of mine to this at agileprojectmanagement yahoogroup. It explains my rationale for what I have blogged here on Flipping Scrum
-----------
What Tom Peters said in this book "Thriving on Chaos" inspired me most, decades ago, which I see a clear reality these days in Agile.
He said "Quality Programs fail for two reasons: they have Passion without Systems or Systems without Passion"
In my earlier days with XP we would work with companies in the former context and most of the times we enjoyed working with the customers even if results are hard to come by, because each one of us, the Team, the Management and sometimes even their Customers too, had the passion in them to be Agile and had that moving one step at a time towards the right direction, even if it was very slow. Never were we hypocritical.
These days with organizations running after trying to find quick large scale fixes with Scrum, I find them all in the latter scenario. They want to have systems to enforce, with no real passion for the goals. Scrum appeals to them as they see that more as a System to implement with a set of loosely defined practices. They find this easy too as most Scrum Evangelists or Consultants don't sell and insist on the Value-Culture-Principles part of it. They sell the practices 3 x 3 and tell the customers, it is easy to do.
This helps the Management, Team and their Customers very consistently move one step away from the right direction (goals), each time they find a new quick fix to fix the previous failed quick fix. I never noticed this in XP organizations. And this reverse direction movement happens very fast, so they try to arrest it with more hypocritical systems.
I personally prefer to work where they have a passion to do something and call me to help them fix the systems to nurture their passion. I will not like to work with customers who wish that they build systems and systems only to achieve something they don't know what and why.
Hence here I am helping my customer do something because here, they have the passion to achieve something, they know what they want from it and why they want to do it. It is justified and I will help them accomplish their passion. Even if their passion is anti-pattern or anti-Scrum, they sure are not willing to be hypocrites.
I am very clear (very very clear) that no one can get anything worthwhile with Agile unless there is a burning passion to do it right across all the stakeholders (team, management, customers) that will bind them to work together and accomplish their common goals collaboratively and honestly.
I cant wait to get all my customers only in this bracket, which is what I did for the last 10 years and missed the bus, while we see all of us selling and implementing Scrum as a silver bullet everywhere.
As Hill rightly points out, we should be selling Lean, Kanban, Kaizen and TOC to organizations desperately trying to improve throughput than sell SCRUM for accomplishing an enterprise wide business culture change. Doing what Hill says will at least help them focus on a goal and generate a passion to achieve it relative to following a set of ceremonies to accomplish an unknown goal without the where-with-all to do it right
---------------
Cheers. Hope this helps clarify my blog to some extent.
Post a Comment