Search

Agile Transformation In Large Organizations

As agile readers, I am sure we all agree that LARGE is a relative term and may not be defined just by number. What does LARGE imply? Is it something that has employees above 5000 but completely structured  Or an organization that has <1000 employees but complex due to the silos, style, and technical limp.  My personal definition - Large organization can be defined as an organization that has fostered distance between employees with process, silos, hierarchy and complexities. Numbers don’t reflect the magnitude during the transformation, but the complexities and the mindset to change. Over the years I have realized, transformations of companies with 10K+ employees and slightly structured, will take same amount of effort as an organization with 1000 employees but unstructured !!! Similar to the two piles of books below. Where does one take more time to find a book? And the answer defines the magnitude of LARGENESS.  Let us assume, for the above pictures, if the problem statement is given as:  Find a book called “Why Agile?” Scenario 1: Considering the books are thrown and piled all around the room, one would take almost days together to get the above problem statement resolved, despite the fact that it is such a small collection of books.  Cause of Delay: Not structured  Chaos and redundancy Impact: Cost of delay Scenario 2: Books are arranged in an orderly fashion, could be alphabetical, year based, genre etc. !!!  Also, this is digitally transferred to make the search easy via computer seen in the picture. In this scenario, one may not take more than 30 mins to find the book stated in the problem statement Impact: Efficiency   In a software world, efficiency should be the measure of Largeness. Lower the efficiency higher the complexity and the magnitude of measure. As, despite the number, journey of transformation is the same. It has to go through the same cycle of form, storm, and norm and perform in order to successfully adopt agile transformation. Irrespective of the approach or magnitude it is always important to understand the organization prior to committing to transformation or adoption.  An analogy to Agile transformation is, similar to any long journey, it gets as pleasant as the people surrounding you; you get a grumpy passenger your trip gets grumpier. There are many articles and blogs that describe impacts of people and surroundings on health and mindset. Hence it is very critical to building safer and pleasant roadmap , that emphasizes and enables empowerment and self-organized organizations.    Few steps that can enable a pleasant travel are: Simple steps to a pleasant journey by Sushma   Leadership Buy in: This is very critical and I write about this all my blogs, as they could be the major inhibitors of change if not in sync. They need to be made aware of what this change could bring and how it would impact their organization. It is usually a myth among leaders that, Agile implies delivery in 2 weeks and a fast track tool to production, as suppose to the reality which includes complete mindset and organizational change. Hence it is important that they understand the impact during ideation than in the middle when their struggling direct report squeal up to them!! Coach management on enablement than heroism. As many Agile leaders define, it’s an attitude change to build enablement and empowerment within teams than building a dynasty of managers. Motivation is intrinsic and not something that can be driven by bonus or money. Recognize and Build optimal teams:  Team structures could vary between organizations; some work the best in a matrix wherein others may build Agile teams with single reporting structure. Organizations with open culture and fearless platforms are optimal for Agile teams. During initial transition, it is always advocated to have diverse reporting within the teams to enable health conflicts and feedbacks. Define Agile techniques and cadence: Build techniques that optimize the efficiency of transformation. During inception phase of transformation, it is always encouraged to have all ceremonies planned in accordance to the Agile framework. Many organizations prefer to have sprint planning of a 2-week sprint to be 1-2 hours and end up creating half-baked stories that do not sync with the definition of readiness. I have noticed teams that conduct 3-4 hours of sprint planning build stronger and optimal backlog for the team to build appropriate product that syncs with the vision. Coach your teams: And Practice what you coach, be an example. Be a leader to harvest leadership among employees. Build Fearless platform of speech. Retrospective: Identify key areas that need further iteration of change, build a plan and implement.    Agile Mindset: Enable teams to identify the Agile way!! Encourage an environment that seeds openness, transparency, and fearless speech. Build a collaborative mindset, a place where someone swims right in front of a shark to save their peer. Integrate Technology: It is always important to facilitate the behavioral change with technology that facilitates this change. Build stronger CI/CD, modularization, and automated testing. It is critical that the system and architecture promote the agility of the teams. The simplicity of tools also plays a vital role in encouraging agility among teams. Tools and Reports used to assess Agile maturity need to be transparent and manageable.   Going to @mcottmeyer 's On Leading Large Scale Agile Transformation. Not really sure if it will scale for our org at scale in the engerprise — mheusser (@mheusser) May 5, 2017 Complex tools can lead to frustrations and resistance towards the change  
Rated 3.0/5 based on 1 customer reviews

Agile Transformation In Large Organizations

403
Agile Transformation In Large Organizations

As agile readers, I am sure we all agree that LARGE is a relative term and may not be defined just by number. What does LARGE imply?

  • Is it something that has employees above 5000 but completely structured 
  • Or an organization that has <1000 employees but complex due to the silos, style, and technical limp.

 My personal definition - Large organization can be defined as an organization that has fostered distance between employees with process, silos, hierarchy and complexities. Numbers don’t reflect the magnitude during the transformation, but the complexities and the mindset to change.

Over the years I have realized, transformations of companies with 10K+ employees and slightly structured, will take same amount of effort as an organization with 1000 employees but unstructured !!!
Similar to the two piles of books below. Where does one take more time to find a book? And the answer defines the magnitude of LARGENESS. 

Let us assume, for the above pictures, if the problem statement is given as: 

Find a book called “Why Agile?”
Scenario 1: Considering the books are thrown and piled all around the room, one would take almost days together to get the above problem statement resolved, despite the fact that it is such a small collection of books. 
Cause of Delay:

  • Not structured 
  • Chaos and redundancy

Impact: Cost of delay

Scenario 2: Books are arranged in an orderly fashion, could be alphabetical, year based, genre etc. !!!  Also, this is digitally transferred to make the search easy via computer seen in the picture. In this scenario, one may not take more than 30 mins to find the book stated in the problem statement

Impact: Efficiency  

In a software world, efficiency should be the measure of Largeness. Lower the efficiency higher the complexity and the magnitude of measure. As, despite the number, journey of transformation is the same. It has to go through the same cycle of form, storm, and norm and perform in order to successfully adopt agile transformation.


Irrespective of the approach or magnitude it is always important to understand the organization prior to committing to transformation or adoption. 

An analogy to Agile transformation is, similar to any long journey, it gets as pleasant as the people surrounding you; you get a grumpy passenger your trip gets grumpier. There are many articles and blogs that describe impacts of people and surroundings on health and mindset. Hence it is very critical to building safer and pleasant roadmap , that emphasizes and enables empowerment and self-organized organizations. 
 
Few steps that can enable a pleasant travel are:

Simple steps to a pleasant journey by Sushma
 

  • Leadership Buy in: This is very critical and I write about this all my blogs, as they could be the major inhibitors of change if not in sync. They need to be made aware of what this change could bring and how it would impact their organization. It is usually a myth among leaders that, Agile implies delivery in 2 weeks and a fast track tool to production, as suppose to the reality which includes complete mindset and organizational change. Hence it is important that they understand the impact during ideation than in the middle when their struggling direct report squeal up to them!! Coach management on enablement than heroism. As many Agile leaders define, it’s an attitude change to build enablement and empowerment within teams than building a dynasty of managers. Motivation is intrinsic and not something that can be driven by bonus or money.
  • Recognize and Build optimal teams:  Team structures could vary between organizations; some work the best in a matrix wherein others may build Agile teams with single reporting structure. Organizations with open culture and fearless platforms are optimal for Agile teams. During initial transition, it is always advocated to have diverse reporting within the teams to enable health conflicts and feedbacks.

  • Define Agile techniques and cadence: Build techniques that optimize the efficiency of transformation. During inception phase of transformation, it is always encouraged to have all ceremonies planned in accordance to the Agile framework. Many organizations prefer to have sprint planning of a 2-week sprint to be 1-2 hours and end up creating half-baked stories that do not sync with the definition of readiness. I have noticed teams that conduct 3-4 hours of sprint planning build stronger and optimal backlog for the team to build appropriate product that syncs with the vision.
  • Coach your teams: And Practice what you coach, be an example. Be a leader to harvest leadership among employees. Build Fearless platform of speech.
  • Retrospective: Identify key areas that need further iteration of change, build a plan and implement.

  

  • Agile Mindset: Enable teams to identify the Agile way!! Encourage an environment that seeds openness, transparency, and fearless speech. Build a collaborative mindset, a place where someone swims right in front of a shark to save their peer.
  • Integrate Technology: It is always important to facilitate the behavioral change with technology that facilitates this change. Build stronger CI/CD, modularization, and automated testing. It is critical that the system and architecture promote the agility of the teams. The simplicity of tools also plays a vital role in encouraging agility among teams. Tools and Reports used to assess Agile maturity need to be transparent and manageable.

 

Complex tools can lead to frustrations and resistance towards the change
 

Sushma

Sushma Arvind

Blog Author

Sushma has a history of turning break even projects into profitable projects through delivery of cost saving solutions via effective process &amp; tool management. With over 15 years of experience in delivery , she has been fortunate to work with multiple organizations that adapted different delivery framework. She has experience in leading large organization transformations and re - engineering delivery that mapped to success and cost . Her belief is "Agile is an attitude to get done with quality, adaptability and retrospective" and there is no single prescriptive process that can fit every problem.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

The Ultimate Guide to the Agile Manifesto

Are you interested in learning about what Agile Manifesto, what Agile’s core principles and values are and what they have to offer to help you benefit from the same in your organisation?Well, if you are, then you have come to the right place, because after reading this article, you will come to know about:What Agile Manifesto isThe purpose that Agile Manifesto servesThe history of Agile ManifestoWhat Agile Manifesto values areThe values of  Agile Manifesto principles.By the end of this article, you will have comprehensive knowledge about Agile Manifesto, its values and principles. Expansive as it may be, but it will feature core elements that define Agile in itself and how it can sort things out in any type of organisation.Firstly, Agile software development, also known as Agile, is an outlook to software development, one that unfolds requirements and solutions through the collaborated effort of self-organising, cross-functional teams and their clients or end users.It recommends planning using adaptive methods along with evolutionary development, empirical knowledge, and continual progress.This is a very short description out of the ocean of information about what Agile actually is. However, let’s stress on what Agile Manifesto is.What is Agile Manifesto?The Manifesto for Agile Software Development, commonly referred to as Agile Manifesto, Is a legal official order that includes twelve principles and four values to show the way for an iterative and people-centric approach to software development. It focuses primarily on testing while keeping the code simple, delivering the functioning bits of the application as soon as they are ready. It promotes an easy, clear and simple approach to developing software in short sprints so that each functioning bit of the software could be analysed and tested based on the client’s or the end user’s requirements, and may be changed if required to meet their needs.Although this set of values and principles were formed primarily for software development, the same can be applied to different forms of business.This makes Agile a very effective and flexible method for all forms of business.The history of Agile Manifesto and its developmentIt all began in Snowbird, Utah from February 11 to 13, 2001, where the ‘Manifesto for Agile software’ was formed. In the meet, seventeen developers formed this manifesto, ones such as Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. They already had established themselves as leaders in the software industry and abandoned the ‘Waterfall’ approach.They realised the difficulty in creating good software and wanted to introduce new values to software development teams. This led to the desire of having a process etched on stone, a process that they were already practising on to bring a change in software development. Together, they published the ‘Manifesto to Agile Software Development’, that marked the beginning of the Agile movement.Agile Manifesto comprises of four fundamental values and twelve supporting principles, ones that head the Agile approach to software development. This manifesto defines the values and principles that software teams should embrace to achieve the landmark of creating good software.Agile Manifesto ValuesWe will discuss the four values of Agile, each value having two aspects, the ones at the left emphasise over the ones at the right. What is great about this manifesto is that it does not propose alternatives, but defining values, thus encouraging developers to pay attention to certain areas whilst not bypassing others.According to the Agile Manifesto, the four values are as follows:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationRespond to change over following a planLet us see what these values individually have to offer and what we learn from them.1. Individuals and Interactions over processes and toolsThis stresses on the fact that although the right tools are vital to developing good software, it is very essential to have a cognitive unit to perform the task in the first place. A team of developers working together on a project with separate but unique tools in a single room will perform efficiently and quickly to deliver before or on the deadline day than isolated developers working with a well-defined process and a common set of state of the art and sophisticated tools in a huge office.We are not denying the fact that tools do not play an important part in creating good software. Of course, they do but we should bear in mind that tools do not work on their own and need people to make them work.And what are human beings in general?We are social beings and deliver quicker and with more efficiency when working together in a group. A cognitive unit of hard working and smart employees will work in tandem without any communication gap and make the flow of work smoother2. Working software over comprehensive documentationIn the past, there were records of lots of time being spent on documenting the product for development and delivery under tight deadlines. Test plans, technical requirements, documentation plans, interface design documents, technical specifications, technical prospectus, and approval required; the list was endless and this caused long delays in development. Documentation is important and serves the purpose of making the end users or co-workers understand how the software works. But there are times when the developers of a company are left with an uphill task of doing the documentation even before the commencement of developing the software, and if the company follows Agile methodology, then they should remember that the primary aim of a software developing company is to develop software, not to engage in the documentation for the majority of their time.Here, Agile comes into play and makes things easier for the developers. It breaks down the requirements of the client in the form of documents as user stories and that is exactly what each developer would need to begin working on developing the software.3. Customer Collaboration Over Contract NegotiationYour customer is the key to your success. Logically speaking, customers are the ones who help you in making better software. And How? Well, that is easy to explain. Customers are the users who will end up using a particular software. Developing the same while taking feedback and inputs from them will help you focus on the prime objective of giving the customers what they really want. They might not help in providing you with the next breakthrough idea, one which you have to come up with, but working closely with them and listening to their input will help you create what your customers desire for and as a result, develop flexible and successfully developed software.Sometimes, legal contracts with customers act as a barrier for you in communicating with your customers. You will need to devise a plan to separate the legal bounding that you have with your customers from the product relationship.Contract negotiations will be there as a part of the deal, but forming a relationship with the customer to facilitate communication will help you interact with the customers with a human touch, failing to do which will not help in developing great software. Creating a relationship with the customers will help in knowing their preferences, thoughts, and opinions. This might be a difficult task for you, but in the long run, doing so will help you achieve much better results.Remember,There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.- Sam Walton4. Respond to Change over Following a PlanChanges do happen in software development. Changes in technology, business trends and strategy, etc. Being flexible with the flow of change is what the fourth value of Agile all about.Following a project plan is fine. However, the same must be flexible and should have some room for changes or it will soon be forgotten as some misplaced faith of self-righteousness.This, on the other hand, makes the life of software testers difficult. Let me tell you why.The software testers analyse and test the functioning bits of the software after its development. However, due to sudden changes in the technical part, business plans or strategy, the testers are not aware of the sudden changes or updates that the developing team are made aware of and need to change their testing strategy accordingly.This results in communication gaps being formed between the testers and the developers thus putting the testers under tremendous pressure to deliver on time.In order to get this issue sorted out, you need to go back to the first value of Agile, which is communicating across teams to stay updated about the changes for a better and more effective workflow. It is more like an initiative to be taken by the testing team, that is, to communicate with the developers to stay in the loop of changes or a new course of action.Now that we have covered on the four values of Agile, let us move ahead to show you what the twelve principles of Agile have to offer and in what way they can help.Agile Manifesto PrinciplesThe twelve Agile principles form the ‘twelve commandments’ of the ‘Agile Movement’ methodology, ones which embrace change and consider the customer as the focal point. They also denote the movement’s intent, that is, to bring development into alignment with business needs, as described by one of the signatories of the manifesto, Alistair Cockburn.The twelve principles of Agile development include:1. Customer Satisfaction through Early and Continuous Software Delivery:The best way to make customers happy is by delivering the software early for testing and feedback, to let them know about the progress, the implementations, and acknowledge the delivery value by fulfilling their top priority requirements first. Each iteration has an outcome, a working code that can be applied to examine and respond to the ever-changing user requirements.2. Accommodate Changing Requirements Throughout the Development Process:This stresses on responding to change instead of staying strictly aligned to an approved plan. It involves a simplified version of handling change with the necessity of no formal documentation or approval. This is done to have control over change for the customer’s competitive advantage because it fastens the response to the latest changes in the business to bolster your advantage to emerging opportunities.3. Frequent Delivery of Working Software:This explains how to provide immediate value to the customers by delivering working features. Each iteration or Sprint must end up in yielding a product release. The teams ensure that each feature is fully developed, tested, customised, and styled according to the customer’s satisfaction before considering it as delivered. The structure of the project team can be bettered by focussing on the delivery of value with a fixed delivery timeframe.4. Collaboration between the Business Stakeholders and Developers throughout the Project:Agile development principles aim at keeping requirements and documentation light.The primary thought process is that it is fine and acceptable for changes to happen in software development. This results in close collaborations being given importance to clarify requirements on a timely basis to always keep all the team members notified during the development of the software.5. Support, Trust, and Motivate the people involved:Fruitful and competitive projects depend on focussed, trusted, and motivated individuals to get the job done. Team members are allowed to select the work they are most interested in by self-organisation with no interference of external management. Micromanagement and top-down approach is a strict no-no.6. Enable Face-to-Face InteractionsThis form of interaction is the best one of the lot. No other mode of communication could beat this one, especially when you need to get to the root of an issue. Feedback via face-to-face interaction or video conference (for the teams separated geographically) is always encouraged as it involves a smoother transfer of information amongst the members.7. Working Software is the Primary Measure of ProgressThis is done by collocating a number of teams in an open area and programmers are paired with each other at each workstation. So what that means is, each pair works in a symbiotic manner. The programmer at the keyboard, known as the ‘Driver’. The other one, known as the ‘Navigator’, actively works on the programming, thinking more about the overall direction. Normally, the job roles are to be switched to have a better understanding between each other.This results in better coding, as these symbiotic interactions help in clarifying the complexities and hidden details in the coding task in a better way. This also leads to a smoother exchange of information and knowledge amongst the team, hence reducing coordination efforts greatly, and improving the flexibility of the pair to interruptions.8. Agile Processes to Support a Consistent Development PaceThe Agile methodology aims at keeping the perfect work-life balance and never over exhaust the employees, thus keeping them happy. By maintaining close collaboration and being alert and creative, extended work after normal working hours is avoided, especially at the weekends, the time when people try to recover from their hectic lifestyle.9. Attention to Technical Detail and Design Enhances AgilitySelf-organising teams are the key to yield the best architectures, designs, and requirements. The team engages in retrospective meetings that hold discussions on the things needed in order to be more effective, after which a decision is made on the next course of action depending on the situation. This ensures that whatever is learnt during the project can be reapplied in the next iteration.10. SimplicityThis principle hints at the application of the Pareto principle or the 80/20 rule. It means that as a matter of fact, 80% of the results may be achieved from just 20% of your efforts. What actually needs to be done is to focus on the ‘20%’ that will yield the majority of the results. You need to focus on the things that are important to add value to the project and customers. Ignore the things that do not add value, such as components, process, etc.11. Self-organizing teams encourage great architectures, requirements, and designsIn Scrum methodology, the team has complete control and is responsible to meet the target of each sprint, and on deciding how to achieve the same. Cutting long story short, the team knows the best way to carry out the task, the interference of the project manager or even the human resources department is not welcome.12. Regular reflections on how to become more effectiveTo get the right results, it is imperative for teams to work as a cognitive unit by focussing on working out new plans to be more effective, checking the requirements, tuning in to the change, and adapting accordingly. Changes do happen most of the time, so you will never come to know what changes in the requirements might emerge until the software is looked at and tested. And the external conditions might have changed while you spent lots of time analysing and reviewing the requirements and designing a solution.Purpose of Agile ManifestoThe basic ambition of Agile is to deliver better software, and that is achieved by presenting a structure which is transparent and direct by emphasising on iterative development, team collaboration and embracing change.Really, it is difficult to imagine how Agile Manifesto has given rise to numerous software and activity. Before the emergence of the same, developing software was not as quick as it is nowadays. This led to the cancellation of many projects because of the continual changes in business needs and was quite unsettling for the software developing industry.The Agile Manifesto is the heart of the Agile movement. Its twelve core principles and four values aimed at changing the process, speeding up productivity with quality and development time. It was noticed that Agile has been implemented even on fields outside software development. Agile stressed on lean manufacturing, collaboration, communication and quick development of smaller sets of features under the guidance of an all-inclusive plan whilst always adapting to changes.Agile Vs Scrum and other methodologiesEven though Agile and Scrum go along with the same system, they do differ in some aspects when compared with each other.While Agile explains a set of principles in the Agile Manifesto employing interactive development to build software, Scrum follows a specific set of rules when practising Agile software development. Agile forms the philosophy whereas Scrum is the methodology to implement the Agile philosophy.Scrum is one of the ways to implement Agile, so there is no surprise when both are similar in many aspects. Both base on delivering software sooner and at regular intervals. Both are iterative processes and have scope for changes too, not to forget their transparency and constant improvement.Here are the notable differences and similarities between Agile and Scrum:AspectsAgileScrumPhilosophyYesNoAdds processNoYesMethodologyNoYesAccommodates changeYesYesConstant improvementYesYesDeliver software early and oftenYesYesIterativeYesYesTransparencyYesYesWhen it comes to Agile and Waterfall, it can be said that Agile is much more flexible and ever-evolving while Waterfall is a rigid and inflexible process.The chances of finding similarities between these two are remote. As a matter of fact, Agile was brought into existence because of the shortfalls of Waterfall and is its polar opposite although they both strive at delivering quality products efficiently.Here are the notable differences and similarities between Agile and Scrum:AspectsAgileWaterfallSequentialNoYesRigid processNoYesFlexibleYesNoAccommodates changeYesNoContinually evolvingYesNoDeliver quality productsYesYesDefined requirementsNoYesOn comparing Agile with Kanban, although the latter implements the former in a visual manner, there are numerous differences and notable similarities, which are:AspectsAgileKanbanIterationsYesNoContinuous flowNoYesPhilosophyYesNoVisualisationNoYesContinually improvingYesYesCross-functional teamsYesNoTransparencyYesYesFaster deliveryYesYesSplitting projects into smaller segmentsYesYesUpfront planning is not necessaryYesYesEqually beneficial to all industriesNoYesNo project management methodology is 100% foolproof all the time. Different methodologies are introduced in different situations and prove useful too. It depends on the type of change you want to bring in your team. For example, Kanban is a better option if you want to introduce something on the top of existing infrastructure with small but incremental changes. However, Agile would be a better choice if your goal is to go for a bigger change.ConclusionSo, here we are, at the end of the line of this topic. We have discussed a lot about Agile Manifesto, its values and principles, and focussed on the benefits of its applications, not to forget about how different Agile is from the various methodologies.You can freely implement the magnificent set of values and principles of Agile to your own business or organisation. It will work wonders if followed religiously.All the best for your future!
Rated 4.5/5 based on 1 customer reviews
17796
The Ultimate Guide to the Agile Manifesto

Are you interested in learning about what Agile Ma... Read More

Failures in Agile Transformation

With the increase in Agile adoption across the organization, the stories are piling up too. Now the question is, are these success stories or the failure stances. Usually, in the conferences or meetups, you get to meet people from various establishments, this is just another way of getting to hear what worked or what not. Even in your own organization, you can feel the pulse of the transformation. There are many reasons why we end up with messy transformation, I have tried elaborating few in the discussion today but there’s more to it. As you read, you might connect with some of the points, let’s start the digging:1. AIMING ON PROCESSES AND NOT PEOPLEThe inclination of Agile is more towards people or individuals, we talk about empowering team, making them self-organized. We even talk about creating high performing teams which can deliver maximum value by the end of every increment. With the adoption of Scrum, where the core values involve Focus, Openness, Respect, Commitment and Courage at the root level, the ‘people’ factor becomes important. Ultimately, it the ‘people’ who work at the ground level for client satisfaction, to achieve this, they adopt processes for smoother workflow. That’s it! Organizations, during their transformation, tend to overlook this critical piece. Their approach becomes more inclined towards processes and they start considering Agile as a process but in fact, Agile is more of a mindset change. Process starts getting priority over people or individuals, always remember, process is just for supporting or helping the individuals with their work. People are not for the processes, even one of the four principles in the agile manifesto says: “Individuals and Interactions over Processes and tools”. I was surprised to hear in one of the trainings’ that people in the same team are using mail to communicate around the stories/deliverables. Can we not give preference to face to face interactions?2. MICROMANAGING THROUGH CEREMONIESSelf-organization is one of entities in Agile, the core says, trust your teams. Micromanagement not only hinders creativity, but it also impacts the morale of agile teams. Management or the scrum master should refrain from getting into the minute details during the scrum ceremonies. Most of the times, it is observed that the daily scrum gets converted into a status meeting either for the scrum master or for the technical lead. As a Scrum Master, you should help the team getting self-organized rather than being directive. One of the principles from Agile talks about giving the space and trust: “The best architectures, requirements, and designs emerge from self-organizing teams.” This enables the team to find their own solutions, helps them with innovation and most of all, teaches them the value of being a team. Every ceremony has its own schema and none of the ceremony is to track individual chores. You must trust your teams, remember, trust can do wonders, believe me, if you trust your people, they will never let you down. Here comes another principles’ focusing on the same. “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.”3. Hastening the TransformationAny change, whether it is for the system or for an individual, takes time. When was the last time you promised yourself to change one of your habits, was that easy? Almost every individual at the start of the year takes so many resolutions, how many do you think gets accomplished! Same goes with the transformation, it takes time and you will have to give because it is not just about the individual, it is about the organization. When the transformation journey starts, the delivery teams take the maximum heat. They are the ones who are expected to be Agile BUT the management usually lags, they are still in need of mindset to support the change. Just by doing the agile ceremonies is not being Agile, it comes with a wide variety of shift, be it - culture, technical, management or team. You have to accept that it is going to be a challenging journey which will have its own milestones and you cannot skip those. Also, it is long journey with hiccups, be ready to accept the challenges, learn from the mistakes and come up with the action items to improve.4. Scrum Roles Getting a Back SeatWhen teams in agile are formed, some of the roles are asked to play dual. In such scenarios, scrum master roles can be played either by the team lead or by someone who is ready for that extra piece. Though the role gets played, but the essence of this position goes for a toss. The focus just stays on delivery without instilling the purpose.  The organisation needs to acknowledge that scrum master'sis a fulltime job that helps teams in staying on track, motivated and helps them see their own progress through information radiators. Anyone else playing a dual role might not do justice and end up walking on two different tracks - not able to reach the goal in both the positions. The team needs someone who can teach, mentor, train and be with them. Just forming the team is not enough if the organization doesn't follow the best practices, such cases tend to get trapped.5. Lack of support from Middle managementIn my past experiences with the organizations in transformation mode, usually the middle layer is where the problem brews. Transformations get a go ahead from the top layer, but it gets difficult for the middle management to adopt. It is important to ensure alignment among the leaders of the organization on the aspiration and value of the transformation is done before moving ahead with the approach. In another example we can see a project manager being insecure as most of the juggling is being handled by the scrum master. In such cases, to prove their existence, the middle layer starts getting into the little details, this impacts the team as half the time they are functioning as per the project manager. Due to this, we hear a lot about the role of scrum master being questioned on their responsibilities. They are assumed to be just sitting and watching, in other words, doing nothing! According to the research led by AgileTurkey.org in Turkey in 2018, the two major hindrances to agile transformation were found out to be the resistance to transformation and culture transformation. Existing managers have a lot to do in order to manage with these two major challenges, they should be part of the transformation beginning from themselves, their day-to-day actions, and should guide the whole company by being supportive of the process.6. Tools over mindsetWith the transformation comes the need to use fancy tools and abide by ‘laws of the tools. Some feel proud in using the costliest tool, some make it a point to introduce the tool being used by the competitor. But is it worth it? Transformation can be done using ‘MS Excel’, there is no set protocol for focusing on the tool. Though the tools play an important part, but teams should focus on Agility and Scrum framework first and then on tools. You certainly need to track metrics like velocity, burn-down, estimates. But with the right mindset, the goal can be achieved with no trouble. This doesn't mean tools are bad, but it means mindset should be given priority over the extensive use of tools.7. Transformation as a Destination (Thinking Your Transformation Is Done)Many a time, we hear ‘We are now agile, we transformed in so and so year’ and what not. But is agile a destination, NO, it a journey, a never-ending journey. Some teams think just by implementing a bunch of backlogs, doing the ceremonies and tracking metrics, they are Agile. No, they are not!Whatever way out we have today are based on our experience, knowledge and the situation we are in. If any of the factors change, our solutioning will be different. Both the values and principles of the Agile Manifesto point to the continuity of the process. Responding to change over following a plan relates appropriately as much to the processes as to our sprint outputs. We have to understand that process is never whole. You just have to continue reflecting what worked and how to fine tune the process whenever required.8. Misunderstood cross-functional teamEvery time I speak about the delivery teams, at least one of the participants from the audience ask this question “We say it's a cross functional team, but my tester is not ready to code!” Have we understood it correct? None of the processes are bad, it is about how we adopt them that makes a difference. “Cross Functional Doesn’t Mean Everyone Can Do Everything, a cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.”  – Mike Cohn. This interpretation of cross-functional imposes a pressure on the delivery team which breaks the team apart and is sometimes the cause of conflicts among the members. As per scrum guide – “Cross functional teams are groups consisting of people from different functional areas of the company. – it should be formed not only with technical specialists (Back-end, Front-end developers, QA engineers, etc.), but also consists of member like Business Analysts, Marketing and UX specialists or anyone else taking an active part in the project.”9. Scrum for AllJust because everyone is going that way doesn’t mean that way is for you too! It is necessary to understand the current and what exactly you want it to be once the journey starts.  Scrum is one of the frameworks to help with complex adaptive projects, but it is not for all the products or projects. If you are transforming your IT helpdesk department, scrum might come out as a failure, the support team cannot say that they will be delivering 10 high priority tickets after the end of sprint, where sprint duration ranges from two week to a month. Second scenario can be the team handling production defects. But this does not mean that Scrum is bad, no it is not. It is just that these scenarios are not meant for Scrum.Every story is different and so are the reasons, as said earlier as well, this is not just a complete list, there can numerous other details depending on the situation. I will be happy to hear your viewpoints on the misalignment and disorientation. Lastly, it is significant to focus more on the people, the mindset and the collaboration to get better results.
Rated 4.5/5 based on 5 customer reviews
8732
Failures in Agile Transformation

With the increase in Agile adoption across the org... Read More

Scrum Master Salary

How much does a Scrum Master earn? How prolific being a Scrum Master is? These are quite relatively simple and common questions but answering them is not that simple. Scrum Master was created around 1992 by Jeff Sutherland and his teams and is quite a new term. Nevertheless, it has not taken long to establish its importance to companies across the world. Scrum Master is currently one of the most promising jobs in the world.In this article, we will cover various aspects of a Scrum Master salary, such as how much a Scrum Master earns, what affects it and how, what the future prospects of a Scrum Master are in terms of salary structure and growth, and why Scrum Masters earn so much.How much does a Scrum Master Earn?According to Payscale, on an entry-level, Scrum Masters in India earn an average of Rs 723,565 per year, going up as high as Rs 1,486,991. In the USA, the average entry-level scrum master salary is $79,309 per year, the highest reaching a six-figure mark of $107,957. However, with more experience, the figures become interestingly better and here is how. Once again, Payscale search results indicate that an experienced Scrum Master in India earns an average of Rs 1,441,276 per annum with the maximum earnings going as high as Rs 2,078,905. Similar reports show that an experienced Scrum Master in the USA earns $103,566 per year on an average, earning as high as $134,203.Below mentioned are statistics from Payscale:Scrum Master Experience/CountryIndiaUSAEntry-Level Scrum MasterRs 723,565 p.a.(Rs 1,486,991 highest)$79,309 p.a.($107,957 highest)Experienced Scrum MasterRs 1,441,276 p.a.(Rs 2,078,905 highest)$103,566 p.a.($134,203 highest)The 2018 research by Glassdoor state that the Scrum Masters are one of the highest paid professionals in the USA, with the average salary being $98,239 and vacancies as high as 1,876. Cities such as New York, Atlanta, Charlotte, Columbus, and Richmond are considered to be the best and most prolific places for the Scrum Masters to work in.Evidently, the figures above are quite staggering and impressive, showing us how fruitful and career aspiring being a Scrum Master is.Here is a table of content for Average Scrum Master salary based on regions:Scrum Master Salary/RegionUSAINDIACANADAGBRAUSTRALIAAverage Scrum Master Salary/yearUS$93,2851,411,000CA$87,000£51,124A$110,000And here is the average salary based on various Scrum certifications:Scrum Master CertificationsSalary in US$/YearCertified Scrum Master (CSM)89,150Professional Scrum Master (PSM )91,000Agile Certified Practitioner (PMI-ACP)108,000Agile Scrum Master (ASM)115,000Scrum Master Certified (SMC)115,000SAFe Scrum Master114,546Salaries that Top Companies pay the Scrum MastersScrum has become so popular down the years that an incredible number of the major software companies adopt its methodology and ways of solving issues.According to the Scrum Guide, Scrum has been adopted by a vast number of software development companies around the world.Apart from being religiously used in manufacturing, operations, education, marketing and other fields, Scrum has been an important problem-solving tool for all the major software companies.Provided that you have the skills to deal with conflicts and are a proven facilitator, you have a great chance to join any of the top companies who are hiring skilled Scrum Masters like you.Glassdoor job search results in India reveal that the major companies hiring Scrum Masters are:Companies Hiring Scrum MastersAverage Salary in INR/yearCisco Systems2,200,000Capgemini1,487,461Amdocs1,279,001Tata Consultancy Services1,243,340Cognizant Technology Solutions1,242,530Wipro1,019,654Accenture1,000,975And in the USA, Scrum Masters are highly sought after by these major brands:Companies Hiring Scrum MastersAverage Salary in US$/yearTransUnion104,728Thomson Reuters104,130UnitedHealth Group97,904Ciber97,156IBM93,403J.P. Morgan91,786Capital One87,732AT&T85,977In the past few years, the pay structure for Scrum Masters has increased at a relatively quick pace. Although Scrum’s popularity status continues to get better, being a Scrum Master is undoubtedly a tough task because what a Scrum Master needs is more like servant leadership skills, and that is the primary asset a Scrum Master needs to possess. After all, it is all about following the Agile-Scrum tactics to finish projects on time along with keeping the quality of the end product intact.Factors affecting a Scrum Master’s salaryThere are many factors that determine how much a Scrum Master earns. Some of the key ones are:1. ExperienceThis is one of the most important criteria, if not the most important one. Like discussed in the previous section of this article, not only the salary of a Scrum Master increases with experience, the job role and position in an organisation gets better as well. Here are a few of the required skills/experience:In terms of landing a better Scrum master job with high pay package, it is recommended for a professional to have worked as a Scrum Master for a minimum of one year with a software development team, one that was diligently applying Scrum principles, practices, and theoryAdequate skills in and understanding of servant leadership, facilitation, situational awareness, conflict resolution, continual improvement, empowerment, and increasing transparency.2. The skills required by the job roleAnother important one. A Scrum Master’s role is not restricted to particular job designation. The more you know about the other Agile approaches in problem-solving, the better your job role and salary will be. By Agile approaches, we are talking about XP, Kanban, Crystal, FDD, etc3. Awareness of multiple Agile techniquesTo get better job opportunities, it is preferred to have knowledge of widely successful Agile techniques such as:User StoriesATDDTDDContinuous IntegrationContinuous testingPairingAutomated TestingAgile Games4. Applicable knowledge of the technologiesA particular organisation will pay you a better package for a Scrum Master if you have a sound grip over the type of technology they use to run their business. Why? It is simple. If you are aware of the system they work in, then they do not have to work on much in getting you in sync with the way they work in their organisation5. Knowledge of appropriate patterns and techniquesA progressive Scrum Master always thinks of using a variety of relevant well-documented patterns and techniques for filling in the intentional gaps left in the Scrum approach, such as Burndown technologies, various Retrospective formats, handling bugs and many more6. Location of the jobThe salary of a Scrum Master depends massively on where the job posting is. If the living standard of a particular city is high, so are the chances of getting a higher pay package. On the other hand, a city having a comparatively lower standard of living renders the Scrum Masters with a lesser salary range.Reason for Scrum Masters being so valuedWhy are the Scrum Masters paid so much? What do the Scrum Masters have to offer that makes them so vital to organisations? After all, in the past few years, Scrum methods have swiftly brought in a revolutionary change in project handling and problem-solving matters.We are living in times when software needs to be delivered on time after much feedback, changes, supervision. Collaboration with frequent updates and patches. To meet the delivery deadline, it is essential to keep the team members connected and in sync, preferably face-to-face. This is critical as the team working on the project should be well informed, collaborated and kept up to date throughout the project. Failure to execute any one of these steps would lead to a breakdown in software, the end result being loss of business, not to forget the reputation of the relevant organisation being tarnished.Nowadays, companies prefer the Agile workflow and are aware of the importance of a Scrum Master in an organisation. Converting a team into a productive one and self-organised by following the Agile practices without any fail, that’s what Scrum Masters do and that is what makes them special.
Rated 4.5/5 based on 8 customer reviews
38923
Scrum Master Salary

How much does a Scrum Master earn? How prolific be... Read More

Useful links