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.
