Venkatesh Rajamani

This insightful post delves into how Management 3.0 practices are affecting change for organizations.

This article will give you a clear explanation of how to become a good leader in this competitive world, and the techniques and tools required to reach the height of success.

Your organization has been disturbed by late launches in its last few new products, and now management has charged you with “getting to the bottom of the problem.”

I often start my Scrum training classes with this quote: "Scrum Master is an enabler not a doer". This is the second in a series of posts exploring some of the myths about Scrum Mastery.

The world is becoming more technologically complex, interdependent, and culturally  diverse, which makes the building of relationships more and more necessary to get things accomplished and, at the same time, more difficult.

When many organizations wanted to incorporate Scrum, it was a big disappointment. The leaders saw it as a failed experiment that did not yield the positive impact one would hope for. Nevertheless, I have witnessed the transformational results and great rewards an organization reaps when it truly embraces Scrum values.

In this series, I have been  Introducing some helpful tips for Scrum Masters on “Systems Thinking” - a diagnostic Tool and a disciplined approach for examining problems more completely and accurately before acting.  Lights on! Camera! 

In this series, I want to Introduce some helpful tips for Scrum Masters on “Systems Thinking” - a diagnostic Tool and a disciplined approach for examining problems more completely and accurately before acting. Lights on! Camera ! Read the Scripts, Role Play , Post me back the experimentation!! Action!!! 1.. 2 .. 3 Are you solving all the “Impediment of your teams” ? Then read on!!! Today’s Impediments come from yesterday’s “Resolution” One of the Services of a Scrum Master is to “serve” the Development Team in several ways , the Scrum guide better articulated it, One of the Services include, Removing impediments to the Development Team’s progress; Often we are puzzled by the causes of our problems, when Scrum Masters are approached with an Impediment , the easiest way to “Remove” the Impediment is to apply “Familiar” Solution to the problems, Sticking to what we know best. I would like to recall an ancient “Sufi Story” “A passerby encounters a drunk on his hands and knees under a Street lamp, He offers to help & finds out that the drunk is looking for his house keys. After several minutes, he asks, “Where did you drop your keys? “, the drunk replies that he dropped them outside his front door. Then why look for them here? asks the passerby. “Because”, says the drunk there is no light by my doorway. All find comfort applying “Familiar” Solution to problems Sticking to what we know best, but “Scrum Masters are enablers than doers” They enable teams to Solve their Impediments, After all if the solution for the Impediments were Obvious to everyone, it probably would have already been found. Pushing harder and harder on familiar Solutions & removing the Impediments so quickly will Self-defeat the Self-Organization. Most Importantly, Scrum Masters look things from a Systemic View, Peter Senge in his book articulated very well, He says The cure can be worse than the disease Sometimes the easy or quick Resolution of Impediments is not only ineffective; Sometimes it is addictive and dangerous. Alcoholism, for instance , may start as a Simple Social habit- a solution to the problem of low self-esteem or life relates stress. Gradually, the cure becomes worse than the disease Resolving all the Impediments for the teams , will create a drastic local Optimization which is worse than the “Impediment”. The long-term , most insidious consequences of applying non-systemic solution is increased need for more and more of the solution. Shifting the Impediment to the teams increases the Creativity of your teams, Constraints foster creativity in teams. Learning to handle this may be hard; Once Scrum Masters learn to Optimize things globally- The cure is permanent :) Happy Scrum Mastering!!!!

We are going towards "Agile" Transformation, One of our goals is to increase velocities across all our teams by X% , Have you heard this? I have heard Marc Andreessen’s adage that “Software is eating the world”, this is becoming the differentiator for Industries that were previously thought to be more manual. A Company that is known for developing “Agile” products surveyed more 18,000 customers and Software development professionals, and this is what they discovered 77% practice Agile Development. -Atlassian Survey,2016. The well-known Contributor of this game changer is “Scrum” – A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Velocity is just a Complementary & Optional Practice in Scrum When you start adopting Scrum, at any point in time the total work remaining to reach a goal can be summed. Various projective practices upon trending have been used to forecast progress like burn-downs charts or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. Especially, agile frameworks like Scrum doesn’t mandate any practices to be used, however these are Complementary practices that is found to be useful. These practices are used to build “Dashboards” to make decisions. But the Agile development does not necessarily lend itself to the kind of dashboards and reports beloved by managers. The few metrics it produces make little sense outside of the context of team planning. Given this shortage of usable information, it can be tempting to re-purpose velocity as a measure of productivity. After all, it’s a measure of team capacity so it follows that changes over time could be used to indicate overall shifts in productivity? “Velocity is an option to Measure progress” not the value! Alongside these complementary practices that we have, the biggest risk with this approach is that velocity is a planning tool rather than a specific measurement. It’s an estimate of relative capacity that tends to change over time and these changes don’t necessarily indicate a shift in productivity. It’s also an arbitrary measure that varies wildly between Organizations, teams and Products. There’s no credible means of translating it into a normalized figure that can be used for meaningful comparison. What is Velocity then? Velocity is an indication of the ability to turn Product Backlog into releasable functionality across time, or for a specified price. I want to increase my team velocity == my goal Given that velocity is such an arbitrary measure it is easy to game, Inflate it or Deflate it. By equating velocity with productivity you create a “perverse incentive” to optimize velocity at the expense of developing quality software. Consciously or not, teams will start trying to demonstrate an increase in productivity by massaging velocity upwards, if the goal is set as Increase in Velocity is directly proportional to the productivity .Worse still, they may start cutting corners to deliver things. This can lead to a build-up of technical debt and the product they create will be brittle. Magic Moment- Open the team’s burn-down charts If you distribute burn-down charts to senior management. Every sprint, the progress line magically starts to intersect with the delivery target. The shape of the line may vary wildly, but somehow there’s a speeding up or slowing down in the second half of the sprint to meet the expectation. Velocity is a measure of the amount of work that a team can do. This is not the same as measuring the value or impact of this work. Velocity may actually be relatively stable in a successful and well-established team as the amount of raw effort available for each sprint remains constant. In this case, putting artificial upwards pressure on velocity will only serve to distort estimates. Can you really measure software productivity? Productivity is determined by looking at the inputs and outputs of an activity. It’s easy enough to measure the inputs for software development, but it’s actually very difficult to measure the outputs in any consistent way. Most importantly, it is Outcome that Matters, not the Output. A raw, quantitative measure such as numbers of lines of code does not provide any reasonable guide. It is too dependent on wildly variable factors such as coding style, development language and implementation approach. It can also be counter-intuitive as well-written code that has taken time in crafting often requires fewer lines of code. How do we Measure Value? If you derive a measure of productivity from velocity then you will see a statistical improvement. This is not the same as successful development. Ultimately, Agile Frameworks like “Scrum” process framework relies on empirical approach, Empirical process relies on Inspection, adaptation and transparency, that enables continuous feedback loop between development teams and the commercial context. A more meaningful measure of success should take this into account and focus on real-world benefits rather than abstract measures or normalized indicators. But remember, A release is required to realize the Value. So, Am I saying metrics are bad? No, I am not saying “metrics” are useless, they are not just management indulgence, they help you gather Information, decide on corrective action , most importantly how to figure out how to evolve. If you tend to satisfy on-going Management hunger for reports, you end up creating meaningless overhead. End of the day, Software is Complex and that can’t be predicted, but only forecasted! Then, what do I measure? Measure the value of your Investment, One of the ideas that Ken Schwaber put across is known as "Evidence based Management "- He says, Evidence-Based Management for Software Organizations is the first useful method for transforming software from an expense into a profitable asset. Especially the, The Agility Index™ software enables you to measure the improvement in business outcomes and track the return of your investment. Covering EBM is out of scope of this article, I would recommend to go through the below link for more Information on EBM, https://www.scrum.org/resources/evidence-based-management-guide Source of References www.atlassian.com www.scrum.org/resources www.benmorris.com www.hbr.org

The Scrum Master role is a new one and often mis-understood by teams and organizations who are Implementing Scrum. When I work with organizations often I see Scrum Masters role is not taken very seriously, A frequent response is to make the “leftover people” the Scrum Masters. They might be nice people but often lack the right traits, motivation, and Scrum knowledge to be effective Scrum Masters. They might morph the role into something else which then becomes accepted “definition “ within the organization as the way a Scrum Master should be. So, eventually that leads to False assumptions about the Scrum Master role . After all, the Scrum Master should know if they’re doing things correctly, right? Sometimes well-meaning Scrum Masters who are new to Scrum or not a good fit for the Scrum Master role cause things to happen that are actually counter to Scrum and detrimental to Scrum adoption, thereby transforming them into anti-Scrum Masters. Scrum guide clearly articulates that, “The Scrum Master’s job is to work with the Scrum Teams and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path” Surviving the Traditional Corporate Culture Traditional organizations have a project coordinator who coordinates work between teams. When you adopt Scrum, the multi-team coordination is the responsibility of the teams. Many teams are so used to having a coordinator role to do this type of work, But Scrum Masters enable the teams to do this on their own. There are many ways than Organization's culture may need to change, in order for Scrum teams to thrive. Perhaps your Organization has a culture of "dictating" and "telling" the teams on what to do and coordinate on their daily activities. Often, this starts with some Constraints. But, Constraints foster Creativity Help the teams this way by Introducing Some of the Practices listed, Create Team Agreements on Co-ordination Mechanism, eg: Nexus Daily Scrum - The Nexus Daily Scrum is an event for appropriate representatives from individual Development Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies or cross-team impacts. For more information on Nexus please refer : https://www.scrum.org/resources/online-nexus-guide Introduce teams to each other. Facilitate a discussion , only if needed Enhance the Transparency of the teams using, Information Radiators (For ex: Dependencies, for the teams to Inspect & Adapt themselves). Teach the teams the purpose of each of the events and ensure the purpose is understood by the entire Scrum team and the Organization. Work with other Scrum Masters in the Organization to improve the effectiveness of the Scrum Implementation. If teams are Distributed, Help the teams by Introducing “Good” practices on Distributed Model. If multiple teams are working on the same backlog , help the teams create mutually accepted “Definition of Done” which will make their Integrated increments potentially releasable. Inspect & Adapt! References: www.scrumguides.org https://www.scrum.org/resources/nexus-guide