Search

Agile Transformation In A Financial Company: A Case Study

In today’s digital economy, Agile is not just confined to the IT and Development domains. Today, Financial sectors even made a headway towards implementing the Agile methodology. At the point, when any financial service decides to go Agile, it bodes well for the progress to be executed in stages.    According to one recent study made by the Harvard Business Review (hbr),  around four-fifths of the respondents said that they are successfully executing Agile methodology in the crucial part of the vital business frames. Below image will specify those crucial business functions-   Discussed below is the case study on ‘Agile transformation in a Financial services company’. It is a story of how Agile practices and principles helped a global financial company towards achieving better business agility. Company Profile The client is a global financial institution with offices spread across Asia and US. Inspired by the success stories that Agile Transformation brought, and with an objective to improve time-to-market for applications delivered this company attempted in bringing added value to both business lines and clients. They chose the Agile framework for the purpose.  While the company showed a lot of interest to bring in change, they also realised that achieving benefits with Agile Transformation would be no small deal, given the complexities of their organization structure, product management, budgeting and the existing waterfall practices that were thriving within the teams! The company realized very soon that in order to have an Agile transformation, at first, they need to build an Agile mindset!  So, the company decided to introduce some external coaches who can help in the journey of transforming to Agile ways of working. Our expert coaches worked with them to address this tricky situation using a multi-pronged, organization-wide approach to help the client teams build their positive experiences, step by step.  Engagement Type Process and Technical Coaching. Business Challenge Finding a way to respond to an increasingly changing competitive landscape, including a much larger direct competitor. Technical Challenge To find the ways to overcome the industry-related challenges with practices that help deliver high-value applications faster and frequently, leading to improved time to market. The Burning Platform Slow-down in making releases and lack of innovation. Key drivers for slow-down are- Detailed Document Requirements  Complex Quarterly planning Domain bottlenecks Developer Context Switching Phase-gate approach to Software Development Integrating Testing Cycles Goals of Transformation Frequent high-value releases, faster speed to market, sustainable transformation, Better follow-through on execution, higher quality.   Proposed Solution “Big Bang” enterprise transformation to address business imperatives for increasing customer focus and pace of innovation. This decision was due to the high degree of interdependence between the teams and the need to establish an enterprise operational framework for staffing, delivery, and governance. Sprint Cadence was common for all the Scrum Teams Common ALM Tool for all the Scrum teams Setting up the Agile Coaching Office External Coaches – Initially Coaches were mapped to BU’s and later the Coaches were assigned at the Program level which resulted in better ROI from Coaches Assess the current situation and rally leadership around an organization-wide change roadmap. Design a plan leveraging Scrum, XP, Lean Startup and other change approaches and techniques and begin execution. Started with Scrum then introduced XP in the teams. Lean startup approach was taken for Product Management which helped only in building features for which the customers were interested in the product. Adjust the plan as needed, scale out small successes, and offer recommendations for sustaining results. Help client initiate culture shifts throughout the organization Setup the Enterprise Transformation Dashboard to assess the progress and monitor the ROI from Transformation Internal Coaches Competency Development Program – To develop internal coaches for sustaining the transformation effort Launch interactive community practices within the organization for teams to learn by sharing Benefits (What Client Got) Our expert coaches worked with them to address long-standing issues delivering high-quality products to the market quickly and consistently. With our guidance, they finally saw the positive and long-lasting effects of a successful Agile transformation that enabled them to visualize— and hopefully, achieve—a nearly limitless future. Together, the Director of IT and our coaches looked at high-level strategies for reducing cycle time, improving the quality of both the existing and future code base, eliminating silos of information, demonstrating what Agile leadership looks like, and ensuring program leadership participated in the decision-making regarding changes on the technology side. A comprehensive assessment of the client’s cultural and business baseline, from which to work toward an organization-wide culture, delivery, and leadership shift Increased visibility into product delivery obstacles Drastically decreased delivery cycle time, removing an “integration window” Workflow and technical training and coaching to stand up high-performance teams Program coaching to ensure leadership decisions supported transformation goals and objectives Visible improvement in the overall quality of production code as well as test code Coaches partnered with software engineers to blend roles and set teams on a path toward becoming more cross-functional—a key ingredient in all high-yield software teams. Software Craftsmanship by using Agile Engineering Practices Delivering high-quality consumable value quickly before the relevant market opportunity is past Advising leadership and helping lead the transformation program, implementing just-in-time changes so that the company could excel in a rapidly changing business landscape Looking for opportunities to align people and processes to ensure continuous improvement Leading the coaching community in the execution of the change management program by involving company’s leadership in Coaching office operations Restructuring the thinking and organizational execution patterns so that portfolio planning and execution is used to manage key initiatives Teams also started delivering monitoring and automation frameworks that implemented continuous integration and automated deployment. Created a portfolio leadership team to manage and implement one Product Backlog with multiple Product Owners Working with HR to define the roles Facilitating conversations between business and IT helping them visualize the work being done Limiting team work-in-progress to help them focus on the products that are most important to the bottom line All parties were able to see the release from a program point of view and to truly understand that the goal of every department is to satisfy and delight customers. Our coaches also delivered several Lean Startup workshops to the product strategy innovation group. These one-to-two-day sessions are designed to help company leaders choose future products and investment opportunities. One of the biggest initial wins for the systems teams was a shortened delivery cycle. What used to take months now took weeks. Quality improved too. One of the was our coaches helped the team in accomplishing this was by introducing teams to continuous integration. Fruit of the Transformation In the wake of executing the Agile technique in the financial territories, organizations started experiencing: Delivery cycles tremendously reduced Teams implementing continuous integration, continuous deployment and some teams working toward continuous delivery Teams releasing consumable value in smaller increments of better quality faster Improved alignment between teams and between department groups Transformed company culture, extending Agility beyond software teams This, exactly, is what we achieved through our Agile transformation. This is not to say that we helped the team eliminate their existing limitations completely. Our Agile efforts essentially made every impediment visible and helped the team to work in unison towards a common goal.  Is your team ready for a similar Agile transformation?
Agile Transformation In A Financial Company: A Case Study
Sandeep
Sandeep

Sandeep Kshirsagar

trainer

Sandeep is an Agile mentor with more than 12 years of experience as a Developer, Test Engineer, Automation Engineer, Scrum Master and an Agile Coach. He is presently working as an Agile Coach at Knowledgehut Solutions Pvt Ltd. Up until this point, he has prepared 800+ programming experts and trained more than 450+ programming experts in Agile journey at different organizations.
 

Posts by Sandeep Kshirsagar

Agile Transformation In A Financial Company: A Case Study

In today’s digital economy, Agile is not just confined to the IT and Development domains. Today, Financial sectors even made a headway towards implementing the Agile methodology. At the point, when any financial service decides to go Agile, it bodes well for the progress to be executed in stages.    According to one recent study made by the Harvard Business Review (hbr),  around four-fifths of the respondents said that they are successfully executing Agile methodology in the crucial part of the vital business frames. Below image will specify those crucial business functions-   Discussed below is the case study on ‘Agile transformation in a Financial services company’. It is a story of how Agile practices and principles helped a global financial company towards achieving better business agility. Company Profile The client is a global financial institution with offices spread across Asia and US. Inspired by the success stories that Agile Transformation brought, and with an objective to improve time-to-market for applications delivered this company attempted in bringing added value to both business lines and clients. They chose the Agile framework for the purpose.  While the company showed a lot of interest to bring in change, they also realised that achieving benefits with Agile Transformation would be no small deal, given the complexities of their organization structure, product management, budgeting and the existing waterfall practices that were thriving within the teams! The company realized very soon that in order to have an Agile transformation, at first, they need to build an Agile mindset!  So, the company decided to introduce some external coaches who can help in the journey of transforming to Agile ways of working. Our expert coaches worked with them to address this tricky situation using a multi-pronged, organization-wide approach to help the client teams build their positive experiences, step by step.  Engagement Type Process and Technical Coaching. Business Challenge Finding a way to respond to an increasingly changing competitive landscape, including a much larger direct competitor. Technical Challenge To find the ways to overcome the industry-related challenges with practices that help deliver high-value applications faster and frequently, leading to improved time to market. The Burning Platform Slow-down in making releases and lack of innovation. Key drivers for slow-down are- Detailed Document Requirements  Complex Quarterly planning Domain bottlenecks Developer Context Switching Phase-gate approach to Software Development Integrating Testing Cycles Goals of Transformation Frequent high-value releases, faster speed to market, sustainable transformation, Better follow-through on execution, higher quality.   Proposed Solution “Big Bang” enterprise transformation to address business imperatives for increasing customer focus and pace of innovation. This decision was due to the high degree of interdependence between the teams and the need to establish an enterprise operational framework for staffing, delivery, and governance. Sprint Cadence was common for all the Scrum Teams Common ALM Tool for all the Scrum teams Setting up the Agile Coaching Office External Coaches – Initially Coaches were mapped to BU’s and later the Coaches were assigned at the Program level which resulted in better ROI from Coaches Assess the current situation and rally leadership around an organization-wide change roadmap. Design a plan leveraging Scrum, XP, Lean Startup and other change approaches and techniques and begin execution. Started with Scrum then introduced XP in the teams. Lean startup approach was taken for Product Management which helped only in building features for which the customers were interested in the product. Adjust the plan as needed, scale out small successes, and offer recommendations for sustaining results. Help client initiate culture shifts throughout the organization Setup the Enterprise Transformation Dashboard to assess the progress and monitor the ROI from Transformation Internal Coaches Competency Development Program – To develop internal coaches for sustaining the transformation effort Launch interactive community practices within the organization for teams to learn by sharing Benefits (What Client Got) Our expert coaches worked with them to address long-standing issues delivering high-quality products to the market quickly and consistently. With our guidance, they finally saw the positive and long-lasting effects of a successful Agile transformation that enabled them to visualize— and hopefully, achieve—a nearly limitless future. Together, the Director of IT and our coaches looked at high-level strategies for reducing cycle time, improving the quality of both the existing and future code base, eliminating silos of information, demonstrating what Agile leadership looks like, and ensuring program leadership participated in the decision-making regarding changes on the technology side. A comprehensive assessment of the client’s cultural and business baseline, from which to work toward an organization-wide culture, delivery, and leadership shift Increased visibility into product delivery obstacles Drastically decreased delivery cycle time, removing an “integration window” Workflow and technical training and coaching to stand up high-performance teams Program coaching to ensure leadership decisions supported transformation goals and objectives Visible improvement in the overall quality of production code as well as test code Coaches partnered with software engineers to blend roles and set teams on a path toward becoming more cross-functional—a key ingredient in all high-yield software teams. Software Craftsmanship by using Agile Engineering Practices Delivering high-quality consumable value quickly before the relevant market opportunity is past Advising leadership and helping lead the transformation program, implementing just-in-time changes so that the company could excel in a rapidly changing business landscape Looking for opportunities to align people and processes to ensure continuous improvement Leading the coaching community in the execution of the change management program by involving company’s leadership in Coaching office operations Restructuring the thinking and organizational execution patterns so that portfolio planning and execution is used to manage key initiatives Teams also started delivering monitoring and automation frameworks that implemented continuous integration and automated deployment. Created a portfolio leadership team to manage and implement one Product Backlog with multiple Product Owners Working with HR to define the roles Facilitating conversations between business and IT helping them visualize the work being done Limiting team work-in-progress to help them focus on the products that are most important to the bottom line All parties were able to see the release from a program point of view and to truly understand that the goal of every department is to satisfy and delight customers. Our coaches also delivered several Lean Startup workshops to the product strategy innovation group. These one-to-two-day sessions are designed to help company leaders choose future products and investment opportunities. One of the biggest initial wins for the systems teams was a shortened delivery cycle. What used to take months now took weeks. Quality improved too. One of the was our coaches helped the team in accomplishing this was by introducing teams to continuous integration. Fruit of the Transformation In the wake of executing the Agile technique in the financial territories, organizations started experiencing: Delivery cycles tremendously reduced Teams implementing continuous integration, continuous deployment and some teams working toward continuous delivery Teams releasing consumable value in smaller increments of better quality faster Improved alignment between teams and between department groups Transformed company culture, extending Agility beyond software teams This, exactly, is what we achieved through our Agile transformation. This is not to say that we helped the team eliminate their existing limitations completely. Our Agile efforts essentially made every impediment visible and helped the team to work in unison towards a common goal.  Is your team ready for a similar Agile transformation?
1494
Agile Transformation In A Financial Company: A Cas...

In today’s digital economy, Agile is not just co... Read More

Simple Techniques for Transforming to a High-Performing Agile Team

A Great Team is all about “People” Incorporating team values, especially in Agile teams is critical to creating a work culture that is collaborative in the first place. It forms the bigger roof that brings together all team members and fosters unity.  In an Agile teamwork environment-  People realize that thinking, planning, decisions, and actions are most effective when done in a cooperative manner.  People strongly support the notion- “none of us is as good as all of us." Everyone in the team takes care of each other’s needs Members plan better things to make the team superior Individuals keep the needs of others ahead of theirs. Culture of team can be transformed completely Each team member can help in making team better Organizations spend on sending teams to Team building events and expect greater results from the team by sponsoring to the team building events which is not true. I would like to share few simple techniques from my experience which does help teams become a high-performing teams (which is a goal of a Scrum Master or an Agile Coach). Technique 1 – Serving each other in the team In one of the Agile teams I coached, there was an individual who always used to ask this question “How can I help you?” very frequently. The question kind of became viral in the team and as a result, there was a massive change in the behaviour of the team. Industry-wide research has revealed that when team members are supportive and motivated enough to help their peers, such teams are automatically high-performing. It has also been observed that the members stay in such teams for longer periods.  The act of serving others is further strengthened by persistent cooperation among team members and eventually transforms to a productivity cult. It is the role of the management to build positive relationship amongst the team members and serving each other in the team helps in building positive relationships. The role of an Agile servant leader is worth mentioning in this context.  This serving cult leads to an effective collaboration of roles, which benefits Agile teams in the long run.  How to build the culture of serving each other in a Team? When teammates serve one another, the level of caring and trust in teams increases dramatically. As an Agile lead, there are two important questions you need to ask to gauge this potential in your team.  What are you currently doing to serve others in your team?  Who in your team can you serve at this moment? STEP 1 – DISCUSS If we all started actively serving each other, what kind of difference would it make in our team? What does or would service look like in our team? How does service affect others?  STEP 2 – ACT Start getting your team to serve each other. Challenge them to do one nice thing today for a teammate. Give them a few minutes to reflect on what they might do after giving them the challenge. STEP 3 – PLAN Have your team create a service plan. In the table below, create a “Service Plan.” List each of your teammates that you can serve now. Next to each name, write an act of service they would appreciate. Include the date on which you will complete the service.  STEP 4 – FOLLOW UP In your meetings to follow, set a few minutes aside to talk about what the service looked like that week in your team. Note: Without follow up you won’t keep the momentum you have gained through the service effect. So, it is important that you ensure this becomes a regular part of your meetings. STEP 5 – ENJOY and WATCH Enjoy watching the service effect take place. It is an amazing thing! Technique 2 – Appreciating, Encouraging and Complimenting Each Other in the Team  Here is one interesting story that has been doing the rounds on Facebook for quite some time.  Too many times a perfectly good day is ruined by someone else’s negativity . You wake up in a great mood because you get to spend me entire day a a job that you absolutely love and then  BOOM you walk into the office and you get an uneasy feeling. You may start feeling drained, unproductive, and unhappy in that job you love so much  - Nicole Tinkham How to Create a Positive Environment in the Team? Take the time to get to know your teammates personally Work through problems together Recognise when personal problems are impacting the work culture and talk them through Be generous when rewarding merit but don’t give it out for everything Take time to explain any changes you implement to avoid anxiety Appreciate each other’s contribution to the work Remain positive (You always have a choice, develop the mindset required to remain positive) Always Smile Don’t become the problem Show gratitude Following activity can be used in building the Positive Environment within the team (either Co-located or Distributed (by making little modifications))  Give everyone in the team an index card and a piece of masking tape. Instruct the team to tape the card to each other’s backs. Once everyone has a card taped to their back, instruct them to think about something they really like or admire about each person, and write it on the index card taped to that person’s back. What you write needs to be something that is genuine and thoughtful. When everyone is done, have each team member find their own space and read what is written on their card. Bring the team back together when done. When you have the team back together, ask the following questions: How did it feel to read positive things from your teammates? Going forward, what can we do to be more positive and encouraging to each other? Note: For Distributed Teams, use Email instead of Index Card for the same activity In the preceding sections we have already seen the significance of “How teammates treated one another” has great impact on team becoming a high-performing team. Following are few more techniques, which can help the team in transforming to a high-performing team -  Technique 3 – Giving and Receiving Feedback in a Team The wrong reasons to give feedback :    The right reason to give feedback:     Defend / excuse your own behaviour To demoralize / condemn You're in a bad mood To  appease a third  party. To make  yourself seem superior / powerful. Commitment / concern for another. Sense of responsibility. To guide / mentor. To support / enhance.   While giving the feedback – Reflect on the purpose of feedback being given Focus on the behaviour, not the person Lead with questions Intent Positivity How to give Feedback? One well known strategy for feedback is the “criticism sandwich,” popularized by Mary Kay Ash.   For preparing to receive the feedback – Ask for feedback often Ask for time to reflect on what you’ve heard, one element at a time Cultivate a growth mindset  Take credit for your mistakes and grow Feedback is truly a gift. You can’t become a great teammate without it. Your teammates have the combination for unlocking personal performance barriers you aren’t even aware of. All you have to do is ask, listen, acknowledge, act, follow up, and repeat. Following activity can be used in creating the culture of giving and receiving Feedback within the team- Create an action plan for getting honest feedback from the members of your team in the next month. The action plan should include your approach to scheduling your one-on-one meetings and follow-up on the feedback you receive. Technique 4 – Establishing Psychological Safety Helping the team succeed is the most meaningful work I’ve ever done.  You need a psychological safety for getting people to open up and discuss anything that is critical for a team to be transformed to a high-performing team. Conversational turn-taking and empathy are the behaviours that create psychological safety.  In some of the best teams, the team members are sensitive and empathetic about their teammates. This fosters an environment of psychological safety. It allows for moderate risk-taking, speaking one’s mind fearlessly and most important- “sticking out your neck without fear of having it cut off”. These are nothing but the types of behaviour that result in major market breakthroughs.  How can you increase psychological safety for your own team? When team members think that their expertise is valued, good things happen Make everyone feel included and important Encourage failure Allow people to ask a lot of questions and think about new ways of working  Everyone on the team isn’t scared to speak their mind or do things like take time off if they need it. Make sure the team is working towards a common goal Share your experiences (mostly the project mistakes you committed in the past) and help people understand that it is safe to talk about mistakes and learn from them Support your team in a manner so that they can rely on you for their problems  An activity called “Johari Window” can be used to increase psychological safety on your own team.  Closing thoughts A high-performing team takes time and effort to build. The most difficult part is to maintain the productivity level in such teams. It comes through team engagement and collaboration. Establishing psychological safety is the key to success in every high-performing team, not just the Agile teams discussed in this article. It is essential on the part of the team members as well as the leads and project managers to instill positivity and encourage reflective thoughts, which are the productivity fuels that help a team grow endlessly.  Transform your Agile teams today!  
Simple Techniques for Transforming to a High-Perfo...

A Great Team is all about “People” Incorpor... Read More

Facts and Facets of Agility and Devops Assessment in Organizations

The fast and developing organizations are now mostly on Agile wheels! Even some of the biggest corporate giants have realized that “Agile begets Agile” and have kept no stone unturned to achieve complete agility. The first and possibly the biggest milestone was integrating DevOps into the Agile fabric to fully utilize the values of both the technologies. Yet, for the longest time, there existed innumerable constraints that were weighing down these Agile teams.  They finally understood that the first big step to attain speed, performance and synergy in Agile projects was a proper Agility Assessment. This was the foundation and the very basic formula that kept an Agile team up and running.    Gauge Your Continuous Deployment Maturity and Assessment now available https://t.co/GlTB870y4m via @forrester #DevOps #ContinuousDeployment #Agile — Robert Stroud CGEIT CRISC (@RobertEStroud) 11 December 2017 What is the purpose of assessment? The primary aim of assessment is to understand the current state of agility in delivering working software in the organization at all levels. Agile Coach will work with you to develop a shared understanding of conditions, strengths, and weaknesses in relevant technology and business areas, including organizational arrangements and processes, leadership and management, teams, Agile implementation readiness, infrastructure, and other areas. Assessment is based on interviews with key stakeholders, survey tools, review of documentation and records, published guidelines, wiki sites, and so on. Agile Coach will observe teams in action and inspect code assets and artifacts as appropriate. The primary objective of assessment is to develop an understanding of where the organization stands with Agile implementation strategy and recommendations which could help them in getting better. Assessment readout is a collaborative activity facilitated by Agile Coach in which your leadership and key stakeholders develop a shared understanding and ownership of the transformation program.   What shall be done as part of assessing the Organization Agility and DevOps?     The outcomes of Agility and DevOps assessment are as follows: Initial findings, observations, major risks or impediments, and recommendations for an Agile transformation backlog, including the following topics: Team design Tool use (e.g., Jira) Workflow recommendations for Kanban, Lean Startup, or Scrum Backlog items for improving the organization Agility and DevOps practices Recommended metrics and key performance indicators appropriate to inspect, adapt and monitor ongoing improvements. Areas and Process of Assessment Leadership Schedule a meeting with the IT leadership team to introduce the team, discuss the outcomes, and initiate a process of Assessment. Discuss the various aspects of Agile transformation such as- What are the business drivers for Agile transformation? What are the priorities? What is the level of support? How involved will each leader be in the transformation? Who will lead and who will support? What risks does leadership foresee and how might those risks be mitigated? How is the alignment between IT and business? How does IT communicate with other business units? What are the leadership styles being exhibited in the organization and its impact? Organization Design and Policies Schedule a meeting with those responsible for managing people to visually depict roles and responsibilities, reporting structures, assignments, and team organization (composition, location, and number). Here are a few points to consider- How are teams created, modified, and directed? What is the organizational or management culture? An organization chart for IT and its business stakeholders, with names, managers, and roles Some of the organization policies Product Management Schedule a meeting with product management or product ownership to discuss the value delivered to Client: Product visions, roadmaps, and release goals and plans in the next year Budgeting Requirements gathering Who are the business stakeholders? What are the products, services, or user experiences delivered by IT? What are their product visions, roadmaps, and release goals and plans? Visually depict how requirements flow into IT. Delivery Schedule a meeting with program and project management and have clarity on the following points- How do requests or ideas turn into projects? How are projects prioritized, funded, and assigned to teams? What governance or lifecycle requirements do projects have? Is any work capitalized? How is software quality maintained? How is process governed? What compliance is required? How are deliverables, schedules, and milestones managed? What does IT deliver iteratively? How long are the iterations? What does IT deliver on demand? How long is the required lead time? High-level service description—the big picture view of the results of IT’s work Effectiveness of different roles being performed in the teams Product Engineering Schedule a meeting with system and application architects to visually depict APIs, integration points, platforms, source control systems, and technologies used by IT. Below is a rundown of the essentials to take care of- A list of technologies (programming languages, software stacks, databases, major 3rd-party components, etc.) Major code bases and tools Delivery pipeline and release frequency Release-level manual testing timeframes, participants, and strategies Automated testing frameworks, environments, and data Automated build practices and frequency Branch and merge practices An additional agenda item for this meeting will be determining the feasibility of collecting the following data: The number of unit, integration, acceptance, UI, and performance tests and what percentage of each type is automated Code coverage and any other static or dynamic codebase metrics The number of open defects categorized by severity and whether they are post-release (i.e., end user impacts) The time it takes to create and deploy a full build in a separate test environment The percentage of release time spent on integration, regression, stabilization, performance, load, and security testing, etc. A list of tools for automation, build, coding, defect tracking, design, requirements, source control, testing, etc. Arrange one or more sessions with representative teams. Include developers, testers, technical writers, usability engineers, architects, analysts, business people—whoever is involved in delivery. The outcome will be a visually depicted interview providing context for the team’s areas of pain, pleasure, and desired change. Assessment Readout Schedule a discussion with leadership after collecting the data to provide the details on what was done as part of the assessment and a set of recommendations which would help in improving the organization Agility and DevOps practices.  Takeaway  That fairly brings us to the end of Agility assessment, combined with DevOps assessment in Agile teams. Together, Agile and DevOps can work wonders in organizations, only if supported by proper assessment techniques. The role of the Agile leaders in such evaluative processes is crucial. They should familiarize themselves with all the key processes in Agile and DevOps assessment and spearhead their teams efficiently. 
8811
Facts and Facets of Agility and Devops Assessment ...

The fast and developing organizations are now most... Read More

Top Product Owner Anti-Patterns & How to avoid them

The Product Owner plays a very critical role in the success of Agile/Scrum implementations in an organization. The entire effort of adopting and scaling Agile across teams is bound to fail if the role of a Product Owner is not understood clearly.  Anti-patterns are practices that go against the spirit of the Scrum Guide, which unfortunately many Product Owners unconsciously fall into. These patterns are in violation of the core principles of Agile, and while each of them seems harmless on its own, in the long run meaningful progress will be hindered.   If you’re a Product Owner and are seeking to improve yourself, you should be aware of what other POs have done wrong, in order to avoid making the same mistakes. This list of some of the most common Product Owner anti-patterns—and the solutions for each—could help! Product Owner Anti-Patterns Busy or Missing Product Owner Product Owners should always make themselves available to the stakeholders, customers, development team and most important, the Scrum Master. This helps important questions to be answered quickly and valuable information to be provided on time. The Product Owner’s availability should never become the bottleneck of the progress of the development team.   Calling the Sprint Review a Sprint Demo During the Sprint Review, the Development Team, PO and Scrum Master figure out whether they are on track and are progressing well toward sprint goals. It is the best time to reaffirm the priorities on the Product Backlog and ensure that value and productivity are being maximised. At this time, a Sprint Demo does not match the importance of the review, and may be out of context.  Expressing the backlog in Technical user stories instead of focusing on business-related user stories While technical functionalities are also important, the User stories should be focussed on business-related aspects. The technical aspects will follow as a natural result of enforcing business requirements. The PO must always prioritise business-related user stories.  Writing detailed user stories When the user stories are too much in detail, there is no scope for negotiation. User stories will evolve over the period of subsequent sprints, and if there is too much of detail in the initial user stories, flexibility is sacrificed. If the user story looks like it is already complete, the development team will not spend time on suggesting improvements, and the stories will not be refined further. They should always be left open ended to increase team engagement.  Questioning the estimates given by the Dev Team The Development team knows their capabilities best, and will be able to provide reasonable estimates of how much time each task will take. A Product Owner who interferes with the estimation is likely to be overstepping his or her boundaries.  Not having a clear acceptance criteria for every story  If there are any user stories that are not defined with the acceptance criteria, it will not be possible to efficiently close out task completion. It would be far easier to make tangible progress if the user story is defined at the start of the refinement cycle, or as close to the start as possible.  Too large user stories As a rule of thumb, a user story should be completed in a maximum of a week or it could become too large to handle. When user stories are too big, the flow of work will be affected and feedback loops will be delayed. User story mapping can be used to slice each story into smaller components.  Not questioning the customers while collecting the requirements It is very important to involve the customers during the process of defining the requirements. They are the end users for whom the product is ultimately intended. When the customers are not included in the conversation, their needs may not be fulfilled. It’s also important to note that in an Agile project, the requirements could evolve over the course of the project, so it’s important to keep the stakeholders in the feedback loop.  Not allowing the Dev Team to work on Technical Debt When dev teams prioritize speedy deliveries over perfect functionality, at a later time the code may need to be refactored. This technical debt needs to be worked on in parallel with sprint deliveries, as otherwise it could pile up toward the end, causing delays in the final product release. A Product Owner should always be mindful of the technical debt and allow the team to iron it out alongside new deliveries.  Not validating the customer’s idea before implementing it While the customers may have specific ideas about what functionalities they need, they are not the experts. The Product Owner, who has sufficient knowledge of the product, should validate their ideas, discuss what is possible and what is not, and then implement the idea if it seems feasible.  Not allowing Development Team members to talk with the Stakeholders directly While the PO is in constant touch with stakeholders, Scrum encourages collaboration. The 4th Principle in the Agile Manifesto explicitly states that “Business people and developers must work together daily throughout the project.” Development teams can also talk to stakeholders to get more clarity, if required. In the spirit of transparency, all such discussions should be made available to everyone so that there is no misunderstanding on any aspect. This is an aspect that should be decided at the outset by individual teams.  Not empowering the Proxy POs In some projects, a Proxy PO is a role created to act as a middleman between the stakeholders and developers. If there is any gap between the PO and the Dev team, the proxy PO steps in and focuses on current features in development. It is important that the proxy PO is sufficiently empowered to be able to perform these tasks effectively, when the PO is unable to do so themselves.  Lack of vision on the product being developed It is the responsibility of the Product Owner to create, manage and own the Product Vision. Unless the PO has clarity on the vision, the product may not turn out to be built as per customer needs.   Delivering more features than valuable features The PO must be aware of which features are the most valuable. If there are too many features being developed, but the most valuable ones are not given importance, then the product will not be as successful. The PO must be aware of which are the most valuable features, and should prioritise quality over quantity.  Not having well-defined prioritization mechanism in delivering user stories It is the PO who, in conjunction with the Scrum team, grooms and prioritises the product Backlog. The Product Owner moves the most important items to the top of the list, and should have a clearly laid out mechanism in place for doing so.  Changing priorities or requirements during the Sprint  If the PO suddenly changes priorities during the middle of the sprint, the development team may have tasks that are unfinished and will lose the momentum of completing them. Considerable time and progress will be lost. While it is a given that Agile is flexible enough to take on changing requirements, unless the circumstances are very exceptional, the priorities should never be changed in the middle of the Sprint.  No single Product Owner, required governance missing in case of multiple POs In the case of a complex project, there could be multiple POs working together. This leads to loss of governance as there could be too many people making important decisions. To be effective, the team should have clear knowledge of who is the PO and who are the proxies.  Missing in Scrum Ceremonies While it is the Scrum Master who facilitates Scrum ceremonies, for complete transparency and smooth communication, it is important that the Product Owner should also be present. The PO should make time to be available at all important ceremonies and events.  Relying on mail communication for answering queries from Dev Team While email communication is always good for complete clarity and maintaining a record, when the PO relies only on emails to communicate with the Dev team, valuable time is lost. Instead, the PO should always be available for urgent queries from the team, and if necessary the responses can be later recorded over email to ensure that there is no misunderstanding.  No emphasis on Quality It is the Product Owner who maintains the Product Vision and should ensure delivery of high quality products. When there is not enough emphasis on improving quality, the Dev team will also lose the required engagement and could churn out substandard work.  Treating estimates as deadlines The core principle of any Agile project is flexibility. When a Product Owner starts to treat an estimated time as a firm deadline, there is loss of flexibility. At times the Dev team may require some extra time to create features with high quality, or the requirements could also have evolved over the course of the project, necessitating an extension of time. The PO should be flexible with respect to time estimates.  Instructing team on what needs to be done, acting as a Manager The Scrum team works in collaboration with each other, and with the PO and Scrum Master to deliver the features during each sprint. There are no managers in Scrum, and the whole team takes ownership for product delivery. If the PO acts as a manager then the spirit of Scrum is lost.  Expecting user stories to be created by team, considering SM and PO to be there only to review the stories While anyone can write user stories, it is the PO’s responsibility to ensure that they are well formulated and organised into a Product Backlog. The Scrum Guide states that it is the PO who is responsible for “ clearly expressing Product Backlog items”, and if user stories are the primary expression of these Backlog items, then it is the PO who must take the ownership of these tasks.   Pushing team to do extra work for finishing everything forecasted during Sprint Planning Agile is nothing if not flexible. During the Sprint Planning process, the team estimates how much work can be completed during the sprint. However, despite best efforts some of these tasks may be rolled over to the next sprint. Pushing the team to complete all the forecasts could reduce quality and increase technical debt, and it is not advised to do so.  Holding the team responsible for any rework post feedback from stakeholders during Sprint Review When there is any feedback from stakeholders asking for changes, it is most often the responsibility of the Product Owner who may have miscommunicated the requirements to the team. In such a case, the team should not be held responsible for the feedback, but the PO should own the responsibility and ensure that there is amicability all around.  Not showing interest in answering team queries for clarifications after Sprint planning A PO should always be available for answering doubts and settling queries after Sprint planning. Failure to do so will cause delays in work, and could necessitate some unnecessary rework.  Not coachable by Scrum Master The Scrum Master is required to act as a teacher, mentor and coach, and in cases where the PO or the team are not aware of the Scrum framework and principles, he or she is required to step in and guide them. If the Product Owner is not conducive to being coached, the project will suffer.  Unable to prioritize the work It is the Product Owner’s primary responsibility to prioritize the work, in conjunction with the stakeholders, customers and Scrum Master. He or she must groom the Product Backlog and move the more important items to the top of the list for the next sprint. If the PO is unable to perform this task the way it should be done, then the work will not be executed as per plan and on time.  Consistently changes priorities during the Sprint In an Agile project, it is possible that priorities could change during the course of a Sprint. However, if this happens too often, it is possible that focus will be lost and the team velocity will suffer due to items that are left unfinished. Wherever possible, the PO should change priorities only at the end of each Sprint, rather than in between. Accepting partially completed PBI’s A Product Backlog Item that is partially completed should never be accepted by the PO at the end of the sprint. Instead, it should be re-estimated on the Product backlog to reflect the amount of work left pending, and should be added to the top of the next Sprint Backlog. Work that is left undone creates confusion and uncertainty. It is important that the Definition of Done should be met, before a PBI is mentioned as ‘done’.  Allowing dev team to change the Story points of a user story post implementation Once the team starts work on the user stories, they could be tempted to re-estimate stories. This is a practice that the PO should not encourage. The story point is just an estimate and accuracy is not required. With experience, the team will become more efficient at more precise calculations.  Not saying “No” to the stakeholders and allowing the product backlog to grow in size It is inevitable that customers or stakeholders will, over the course of the project, keep checking up on the competition. They may want to change the features, add new ones or redefine the product entirely. A Product Owner who is unable to say No when needed will cause the project to go off track.  There's nothing more paralysing than a Scrum team with a bad Product Owner!  The characteristics stated above lead to nothing but a Product Owner “Fishbowl” where new ideas and innovative thoughts pertaining to Scrum processes find no entry at all. The Product Owner is.. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. It’s a one-person role that brings the customer’s perspective of the product to a Scrum Team.   The Product Owner is responsible for:   Developing and maintaining a product vision and market strategy  Product management   Ordering and managing the Product Backlog   Involving stakeholders and end-users in Product Backlog refinement and backlog management   Alignment with other Product Owners when needed from an overall product, company or customer perspective. A GREAT PRODUCT OWNER…   Grasps, shares and spreads the product vision: A great Product Owner acts as the client's voice (also called a proxy-client at times) and makes a product vision together with the stakeholders. Each choice is taken on account of the product vision. This guarantees sustainable product improvement, gives clarity to the development team and expands the chances of product success definitely.  Understanding the customer’s goals:  A great Product Owner truly understands the customer’s goals with the product and is able to outpace their expectations. After all, pleasing the customer is the ultimate goal. Is a good decision maker: A great Product Owner is an authorized person to take product-related decisions. It may take some time to support his/her decisions, but this is an essential condition for an economical pace of the development team Manages the product backlog: A great Product Owner comprehends that the product backlog should be in sequence. Priority, risk factor, quality, getting to learn and dependencies are all considered and balanced with each other. Prefers one-to-one communication:  A good Product Owner believes in one-to-one communication to convey information. User stories are used as a medium of conversation. Knows modeling techniques:    A great Product Owner has a knapsack full of workable modeling techniques and knows when to apply a specific model. Based on the model application he or she drives the project success. Shares experiences: A great Product Owner offers experiences with peers. This may be inside the organization, or outside it. Conferences and meetings are great approaches to share experiences and garner information. Furthermore, recording lessons learnt can be significant learning opportunities for other Product Owners.  Is present: To be effective, the Product Owner should always be available for discussions with the stakeholders, customers, development team and the Scrum Master.  Claims user story mapping: A great Product Owner should ace the idea of user story mapping. It is a method that enables you to add a second dimension to your backlog. The visualization empowers you to see the master plan of the product backlog. Keeps an eye on functionality: A successful Product Owner keeps an eye on functional as well as on the non-functional aspects of the product. The motto of the Product Owner is to exceed the quality expectations of the customer and enabling functionality that provides value to the product. So, the functionality is the main focus of the Product Owner.   Is knowledgeable: A great Product Owner has a deep product knowledge and comprehends the technicality. Larger products might be difficult to understand and scale. In this case, the PO should know the formula to solve the large queries. Comprehends the business domain:  A great Product Owner knows the ins and outs of the domain. A product should be built with a clear idea of every aspect , not just an understanding of the development needs but also being aware of the current market trends. No matter how great your product is, shipping it after the window of opportunity closes is a waste of time and barely of any value. Acts on different levels: A great Product Owner is capable of acting on different levels. These levels are popularly denoted as- strategic, tactical and operational. At the board level, a PO should know how to demonstrate the product strategy. Thereafter, he should create a strong support at middle management and facilitate the development team to cope with their daily challenges. Knows the 5 levels of Agile planning.   Within Agile, planning is done continuously. Every product needs a vision (level 1) which will provide input to the product roadmap (level 2). The roadmap is a long-range strategic plan of how the business would like to see the product evolve. Based on the roadmap, market conditions and status of the product the Product Owner can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team's progress towards realizing the Sprint Goal. Is able to say 'no'. A great Product Owner knows the best time and way to say “no”. This indeed is a difficult trait to master. While it is easy to give any new idea or feature the nod, there is a flip side. Good backlog management necessitates creating a manageable product backlog with items that will mostly get realized. Appending non-productive items to the backlog will only create false expectations. Acts as a "Mini-CEO". A great Product Owner basically is a mini-CEO for his product. He or she has a sharp eye for opportunities, focuses on business value and the Return On Investment and acts promptly on all possible risks and threats. Every growth aspect such as size, quality, market share of the product is taken into consideration. Knows the different types of valid Product Backlog items. A great Product Owner can clarify the fact that the Product Backlog consists of more than only new features. For example, technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account. Takes Backlog Refinement seriously. A successful Product Owner spends sufficient time refining the Product Backlog. Backlog Refinement is essentially the act of adding detail, estimates and order to items in the Product Backlog. The result should be a Product Backlog that is granular enough and easily understandable. On an average, the Development Team spends no more than 10% of their capacity on the refinement activities. There is no such prescribed approach. The Product Owner can also involve stakeholders and the Development Team in backlog refinement, each for a valid reason. The stakeholders are given the opportunity to state their expectations. The Development Team can clarify functional and technical implications. This will ensure a holistic understanding and enhance the quality of the Product Backlog considerably. Consequently, the opportunity to build the right product with the desired quality will also increase. Common FAQs A product owner is noticing that overall quality is starting to degrade. What might they do to address the problem? Discuss it with the rest of the team in a retrospective. The Scrum Master who facilitates the retrospective should then help the team to identify the underlying causes and help on how to improve. A possible outcome can be that the Definition of Done needs to be improved, for example a code review can be included. What should happen if the product owner does not accept a story by the end of the iteration? The Product Backlog Item (‘story’) goes back to the Product Backlog. The Product Owner can decide that it needs to be finished in the next Sprint. In the Retrospective at the end of the Sprint, the Product Owner can discuss with the rest of the team on how to prevent this from happening again.  Concluding Thoughts: A Product Owner is indispensable for a functional Scrum team. Not only is the PO the bridge between the development team and the client, but he or she also ensures streamlined product delivery. Ill-defined Product Owner roles and some of the critical PO anti-patterns are some of the impediments many of the Agile organizations are battling at present. The only long-term solution to such persistent issues is clarity on PO roles and a proper understanding of the end-to-end Scrum processes.
2442
Top Product Owner Anti-Patterns & How to avoid...

The Product Owner plays a very critical role in t... Read More

Top 32 Anti-patterns a Scrum Master Should Look out For

The Scrum Master (SM) plays a very critical role in the success of Agile/Scrum implementations in an organization. Agile transformations are bound to fail if the role of a Scrum Master is not understood clearly.  However, many Scrum Masters do not follow the spirit of the Scrum Guide, and these violations—called Anti-patterns—hamper progress and slow down the achievement of goals. While these Anti-Patterns may seem like a quick fix to the problem at hand, in the long run they will impair team work and cause the Scrum Master undue stress.  Listed below are some of the Scrum Master anti-patterns that should be avoided-   Inability to coach the Product Owner  Scrum Master following a Command and Control Leadership Style   Scrum Master taking updates from the development team during Daily-Standup, as opposed to the actual purpose of a Daily-Standup  Allowing the spillover of work to subsequent sprints  Taking partial credit for the unfinished work in the current sprint by splitting story points  Allowing for burn out of the Development Team  Playing the role of Scrum Master without believing in Agile/Scrum values and principles  Always conducting Sprint retrospectives in the same fashion   Playing the role of SM without understanding the behavioural aspects needed to play the role  Solving all impediments for the team, without allowing them to participate   Demonstrating the working software during the Sprint Review to the stakeholders  Not creating awareness on Agile Engineering Practices in the team   Not following Timeboxing  Allowing Managers to attend Sprint Retrospectives  Assigning tasks to Dev team members  Trying to  influence the team estimates  Forcing the team to make commitments for Sprint deliverables  Doing the planning for the team instead of facilitating the plan  Playing favourites, showing differences and bias among dev team members  Being authoritative  Lack of knowledge on implementation of Agile/Scrum  Providing solutions for the team  Allowing dev team members to work on items other than what has been committed during the Sprint Planning  Hiding information from the dev team members  Scrum Master playing the role of a Manager  Not listening to the team issues during Sprint Retro and being biased and pushing his/her viewpoints  Providing explanations for each point during Sprint Retro  Micro-managing the team  Creating poorly organized Minutes of Meeting for daily standup  Ill-management of the Triple Constraints (Scope, Cost, and Schedule)  Playing the role of Scrum Master for multiple teams despite not having the bandwidth  Playing the role of Scrum Master in spite of not understanding the role of a Coach in the team Exactly what does a good Scrum Master do? As indicated by the Scrum Guide, the Scrum Master is in charge of guaranteeing that the Scrum principles are comprehended and followed correctly. Scrum Masters do this by ensuring that the Scrum Team sticks to established Scrum ideas, practices, and guidelines, and helping them to do so.   In other words, the Scrum Master is a Servant-leader for the Scrum team. Also, the Scrum Master helps the team to understand the gist of an outside conversation, and summarise it into useful points to be followed.  A Scrum Master is required to wear many hats and take on multiple roles. A great Scrum Master is someone who knows which role to play at which time, and  is capable of helping the team to apply Scrum effectively and efficiently in any given scenario.  In his/her daily life, the Scrum Master acts as a:   Servant-Leader - Keeps focus on the necessities of the team members and on the client’s requirements, with the aim of achieving business objectives  Facilitator- Facilitates by providing clear requirements so that the team can work collaboratively  Coach- Trains the Scrum team to follow the Scrum principles appropriately  Conflict negotiator - Resolves conflicts to manage unproductive mindsets and uncooperative behaviors  Manager- Manages the impediments and facilitates Scrum processes, removes wasteful procedures, confining limits of self-organization, and follows the Scrum culture   Mentor- Transfers  Agile knowledge and experience to the team  Teacher- Helps teams to understand and follow Scrum methodology and principles  A GREAT SCRUM MASTER  Let us first take a quick tour of the daily life of an ideal Scrum Master. The above infographic pretty much sums up the daily activities of a great Scrum Master. A successful SM essentially is one with the following traits-   Includes the team when setting up Scrum processes  A good Scrum Master ensures the entire team adheres to the chosen Scrum process and understands the value of every Scrum event. Therefore, the Scrum meeting is always planned according to the convenience of all the team members. A common concern behind engaging all the team members in the meeting is to plan the processes, decide upon future steps and discuss the desired output.  Comprehends the stages of team development As per the renowned psychologist Bruce Tuckman, there are five distinct stages of team development- forming, storming, norming, performing, and adjourning. A Scrum Master who clearly understands these five stages and is able to guide the team to achieve high performance by following these stages, is able to achieve success.  Understands that principles are more crucial than practices A team with internal conflicts will never be able to work well together. A Scrum Master should be able to understand the reasons behind team friction at an early phase, and sort out the issues by applying appropriate conflict resolution strategies.   Is aware of the organizational activities A great Scrum Master can have a profound impact on the culture of the organization so that Scrum teams can perform to their best potential. He understands that changing people's behavior isn't all about changing people. He/she must be aware of the activities happening in the organization i.e. should be aware of the climate and culture.    Does not always protect the team While the Scrum Master, through experience, knows when a team is about to fail, he or she will sometimes allow the team to make mistakes as experience is the best teacher.  Encourages ownership A great Scrum Master motivates his team to assume complete ownership of the tasks they are mapped to.   Should be self-organizing A good Scrum Master comprehends the importance of a self-organizing team. They should be able to make their own decisions, manage their own work, and cooperate with each other to achieve project targets.  Knows the power of silence A great Scrum Master is always aware of the three levels of listening-   Level 1- internal listening  Level 2- focussed listening  Level 3- global listening   A great Scrum Master does not simply hear, but listens!  By being aware of all the three levels of listening, a Scrum Master knows how to make the best use of them. They listen carefully to what is said, and also to what isn't said.   Notices The Daily Scrum is arranged by the team for the team. The Scrum Master just observes the session, keeps a clear view of what is being discussed, and notices how the team members played their roles in the session.  Shares experiences One of the unique traits of successful Scrum Masters is that they always share experiences and relevant information with their peers. This might be intra-organizational or through seminars and conferences, which are great platforms to share experiences and garner knowledge. Undoubtedly, noting down and sharing the lessons learned is also a highly commendable trait on the part of an SM. Has a knapsack loaded with numerous retrospective designs  A great Scrum Master has a repertoire of numerous retrospective designs, knows which to refer to according to the team’s situation, and can make sure that the retrospective is functional and valuable for the team. While he or she acts as a facilitator, they will allow the team to host their own retrospective.   Can guide professionally  A Scrum Master is required to be an expert guide and coach, who knows how to steer people in the right direction without explicitly telling them what to do. By empowering team members to understand themselves better, the Scrum Master helps them to benefit as much as possible from their potential.  Has influence at an organizational level A successful Scrum Master always motivates and influences team members at tactical and strategic levels. Team members often face difficulties at these levels, and it is important that a Scrum Master knows how to act at all levels within an organization.  Prevents impediments A great Scrum Master resolves impediments and mitigates risks. Based on his/her past experiences, the SM reads the situations and acts on them proactively.   Is always available An extraordinary Scrum Master is always accessible, even though he or she does not breathe down the necks of individuals and micromanage their tasks.  Forms an incredible pair with the Product Owner An incredible Scrum Master has a remarkable pairing with the Product Owner. The Product Owner 'pushes' the team while the Scrum Master secures them. This strong partnership is very significant for the Development Team, as together they can achieve incredible product success.  Allows leadership to grow A great Scrum Master allows leadership within the team to develop as a natural progression of team work. They believe in the mantra "leadership isn't just a title, it's an attitude". This is something every single member of a Scrum team should follow.  Knows about gamification A Scrum Master can infuse the spirit of fun by incorporating gamification into project-related tasks. By encouraging and motivating team members to carry out their commitments, the Scrum Master can help them to outperform  and achieve success.  Comprehends all things Scrum An incredible Scrum Master is skilled in XP, Kanban, and Lean, and knows the qualities, shortcomings, and risks of each technique/framework and how and when to utilize them. Whenever the situation requires it, he or she is able to comprehend what the team needs to accomplish and suggests the most viable technique from an Agile viewpoint.  Leads by example A great Scrum Master is somebody that team members need to emulate. He/she does this by motivating them to maximise their inner potential and leading by example . The Scrum Master always follows industry standards and best practices, and quietly shows the path that must be followed.    A good leader tells, a great leader leads, a Scrum Master sets examples.  Is a great facilitator An incredible Scrum Master is a born facilitator. Scrum events are conducted in a fun and engaging manner, and all meetings are arranged beautifully, offer value and achieve the desired results.  Concluding Thoughts  It is, unfortunately, all too easy to fail as a Scrum Master. The absence of organizational support, unsuitable team members, and internal conflicts that are hard to resolve, are common challenges that Scrum Masters have to face on a daily basis. It is important that the team stands by the Scrum Master and offers sincere support, as this is not an easy role to execute! After all, Scrum, in the end, is a group activity. 
9727
Top 32 Anti-patterns a Scrum Master Should Look ou...

The Scrum Master (SM) plays a very critical role ... Read More

Is Servant Leadership Part And Parcel Of A Scrum Master's Daily Life?

Each of us is always a part of some group whether we are at home or at work or wherever we are and I believe that the results are maximized when we work together in achieving our project goals. Quite the same is the case of a Scrum Master, who is also known as the “Servant Leader”. A leader who leads and serves at the same time. This article mostly revolves around the different aspects of a servant leader’s role. The first and the most essential step is to understand the “serve” model followed by a Scrum Master.  Go through the SERVE model provided below, which was created by the author and renowned management expert Ken Blanchard. This model will let you execute Servant Leadership practices in the organization. SERVE is an acronym for: S – See the future,  E – Engage and Develop Others R – Reinvent Continuously V – Value Results and Relationships E – Embody the Values  The term “Servant-Leadership”  was first coined by Greenleaf (1904–1990) in 1970, in his essay titled "The Servant as a Leader." What does a Servant Leadership mean? ‘The servant-leader is a servant first’. The motto behind the philosophy is to stay focused on the needs of others, caring for people, providing an environment where the competent and impotent support each other to build a good community.  Servant leadership is most likely associated with the participative leadership style. The definition of Servant Leadership can be put as a lifelong journey that includes the discovery of one’s self, an enthusiasm to serve others, and a commitment to lead, keeping a focus on the satisfaction and the performance of the employees Servant Leaders lead with others in mind. -Skip Prichard In modern days, you’ve got to produce more for less, and with greater speed than you’ve ever done before. The only way you can do that in a sustained way is through the empowerment of people. And you will get empowered through the high-trust cultures and encourage, support, enable subordinates to unfold their full potential and abilities. 9 qualities required by a Servant Leader         Ten characteristics required for a Servant Leader as suggested by Robert Greenleaf are as follows: 1.Listening: Servant Leader needs to have a long way commitment to listening attentively to others.  The ear of the leader must ring with the voices of the leader. -Woodrow Wilson      The following 10 guidelines, adopted from Thill and Bovee’s book, will enable you to improve as an audience- Minimize both internal and external distractions Adjust your listening to the situation Show that you are listening through your non-verbal communication Determine the pivotal points and plan a procedure to recall them Show your concern Do not jump into giving advice Do not interrupt Do not prejudge an individual’s message by his appearance Stay focussed on the subject Remain clear headed even if the topic is emotional.  2.Empathy: Servant Leader needs to accept and recognize people for their special and unique spirits. Empathy is- “Seeing with the eyes of the another, Listening with the ears of another, and feeling with the heart of another”.  Here are a few hacks to develop empathy- Imagine you being the other person;  Practice caring behavior Converse with people with no personal expectations or goal of fixing them Identify with their experiences by relating to a similar situation which you have been through Heal past damages. 3.Healing: Robert K. Greenleaf in 1970 proposed servant leadership as a way of life in which the focus is on the betterment of others.  Healing yourself is connected with healing others.  -Yoko Ono Following are the few ways that will help you to build healing capabilities- Learn how to deal with difficult situations in terms of serving the common goods Recognize an opportunity to complete those people and organizations you are professionally associated with Care for people and their welfare Choose your words wisely as people may be suffering from lots of personal and professional disturbances on a daily basis Respond to other’s needs Seek feedback. 4.Awareness: Servant leaders need to be aware of their strength and weaknesses. Awareness aids understanding the issues like ethics and values. It lends itself to being able to view most situations from more integrated and holistic position.  Let us not look back in anger, nor forward in fear, but around in awareness. -James Thurber The following are the few ways to develop awareness- If you are not perfect at anything, still you can perform at a high level Make wise and fair decisions without getting influenced by self-emotions and biases Identify your strengths and accept your weaknesses Build the strengths and accept the weaknesses of others Encourage people instead of judging them. 5.Persuasion: An efficient Servant Leader builds group consensus smoothly, clearly, and persistently. The servant leader does not exert group compliance through position power.  The following are the ways to develop persuasion capabilities-  Utilize personally, instead of applying power to influence followers and achieve the organizational objectives Build the culture of consensus for group decision making Be friendly and always be ready to guide others Believe in learn-error-learn (try and error method) Make people believe that they are accepted and trusted.  6.Conceptualization: There is nothing worse than a brilliant image of a fuzzy concept. -Ansel Adams The act of conceptualization is an act of thinking through, seeing beyond the existing, and discovering something new. Servant leaders keep up a delicate harmony between conceptual thinking and an everyday-centered approach. The servant leader must have a dream and an ability to portray it in a vivid language. For any great things to happen, there must be a great dream. Dreams raise the thinking power of the people. The greatest leaders are those who are able to put their dream clearly to the listeners, keep up a fragile harmony between calculated reasoning and an everyday-centered approach. 7.Foresight: Foresight is an attribute that allows the servant-leader to grasp knowledge from the experiences, the present facts, and the likely effect of the future decision. One can have only as much preparation as he has foresight. -Jim Butcher Here are the ways to build foresight- Identify the changing trends, its cause and impact Explain the vision to the team to engage themselves in achieving the vision; Identify different scenarios and check if anything can be done today which can help them tackle future scenarios. 8.Stewardship: Servant leadership is like a stewardship, which assumes commitment as a foremost part to accomplish the need of others. It additionally stresses the utilization of receptiveness and influence instead of control. Stewardship as a leadership behavior leads to successful organizational performance.  Whatever you are, be a good one. -Abraham Lincoln Go through the following ways that will help you to develop Stewardship qualities- Leader’s success always depends on the team’s success Committing to the organizational goals that will help you achieve success Help organizations to become a center of learning and collaboration; Being responsible and accountable for results;  Utilizing and managing all resources. 9.Commitment to the growth of the people: Servant leaders trust that individuals have an inherent value beyond their unmistakable commitments as workers. Therefore, the servant leader is profoundly dedicated to the development of every individual inside the organization.  Stay committed to your decision, but stay flexible in your approach. -Tom Robbins  Following are the ways to develop commitment to team- Appreciate the ideas and suggestions given by the employees Encourage team involvement in decision making Identify growth opportunities for the team members Encourage and motivate people in achieving organizational goals Be committed to helping the team members grow Connect to the others’ developmental needs and actively find ways to meet those needs. 10.Building Community: Servant leaders believe that organizations need to function as a community. A servant leader instills a sense of community spirit in the workplace.  Strength lies in differences, not in similarities. -Stephen R. Covey By following ways you can build the community- Develop the culture of knowledge sharing Develop a learning community Treat everyone equally Build the team to support each other Socially connect with each other Care for each other Appreciate each other’s success Always be there for each other Summing it up: At last, Leadership is a choice. Before trying to become a servant leader, you should remember that an effective Servant leader always understands every aspect of the business deeply without distracting in attaining long-term goals.
Is Servant Leadership Part And Parcel Of A Scrum M...

Each of us is always a part of some group whether ... Read More