Search

Deliver High Business Value With Agile Opportunity Canvas

I would like to start this blog with a question. Business case, quite commonly used term in Project Management. Do we agree?It is a document explaining the justification for a project and expected outcome. Let us have a look at Project, Program and Portfolio Management in the image below.Every single initiative or project within an Organization is aligned to Organizational strategy.In an Enterprise level, we tend to see a lot of ideas and requests emerging from stakeholders, clients, internal teams, outcomes of market research. These ideas and requests will convert into a Project, if we see a potential opportunity. In traditional approach or Agile approach, every idea or request should be validated to ensure the right investment is made. Agile is a widely used terminology in IT industry. People often stumble upon understanding Agile and Lean. Lean Methodologies focuses more on value, elimination of waste and delivering the product in small batches. Agile is a subset of Lean thinking. Agile movement was formed in 2001, Outcome of which is Agile Manifesto and 12 Principles for Agile Software development. Agile is an umbrella term covering different methods and frameworks such as Scrum, Scrumban, XP, FDD etc. All Agile approaches/frameworks emphasizes more on Agile Manifesto and 12 Principles.Agile Model:Demand Management in Traditional Approach/Waterfall model: In the traditional approach, a project is selected over another project through Project evaluation tools such as Cost-Benefit analysis, Decision Matrix etc. A project charter will be created during the initiation phase of the project which captures business case, high-level requirements, timeline/milestone, risks, costs and other constraints. A detailed scope in the form of "Statement of Work" is approved during the planning phase. Planning is one time in a Waterfall model and will take a considerable amount of time in the project. Scope(Feature) is Fixed, Time and Cost is flexible in Traditional approach. Any changes to the scope will be difficult to handle in Waterfall model. There are a lot of risks involved in Traditional approach, as planning is one time.                                                                                                       Fig: Iron triangle- Traditional Approach Demand Management in Agile Approach: In the Agile approach, planning is continuous. Planning is done at different stages. This reduces risks.Strategic PlanningPortfolio PlanningProduct PlanningRelease Planning – Quarterly by entire teamIteration Planning – Bi-Weekly by entire teamDaily Planning – Daily by entire teamFrequency and required participants for Strategic, Portfolio and Product planning will differ across organizations.                                                                                                         Fig: Agile Estimating and Planning In the Agile approach, Feature remains flexible, Time and cost are fixed. Agile approach is incremental and iterative in nature. In the Agile approach, we do not have a detailed scope slated during the start of the project. As we evolve during the development phase, there might be new features or enhancements identified by the customers.                                                                                                          Fig: Iron triangle- Agile Approach In Agile Demand Management Cycle, an idea/requirement/enhancement is chartered in an Opportunity Canvas which gets reviewed by Investment cabinet. As per agile manifesto # 3- Customer collaboration over contract negotiation and Agile Principle # 1: Satisfying the customer is of highest priority: "Agile opportunity canvas" creates more visibility to the customer and the product owner to prioritize new requirements or enhancements over others. (Enhancements which needs a development effort of minimum 2 months would be considered to be chartered in an Agile opportunity canvas). Demand Management process is followed in both Traditional and Agile approaches. In Traditional approach, since the scope is clear it will be a one-time activity. But in Agile, as we do Rolling wave planning on shorter time span to deliver customer value, we would need a robust demand management process to ensure the right requirements were approved and investment is made for right product or feature.                                                                                              Fig: Opportunity Canvas & Demand Management Agile Opportunity Canvas: Agile Opportunity Canvas also referred to as Agile Project Charter is used to ensure whether the business value is captured in the right format, which gives visibility to higher management and decision makers to ensure the investment is made to the right effort. An opportunity canvas is similar to a lean business case. It will help us capture the essential fields. Drafted opportunity canvas will move through the approval process before any project work is initiated. Sample Agile Project Charter template:There are different elements in an Agile Project Charter. These elements are customized according to the Organizational needs.  Opportunity Canvas is a living document and it should be in One page.In a nutshell, we should have the required elements populated to move it across the Demand Management. Generic elements to be part of the Opportunity canvas are listed below:Current Problem Statement – Why do we need to implement this idea? What is the Problem statement?Strategy/Value Justification – What is the value proposition this idea provides and what strategy are we adopting.Scope – In scope and Out of scope details for the generated idea/ enhancement.Sponsors and Stakeholders – This could be internal or external to the organization.Financials – What are the costs and benefits associated?Success Metrics – SMART Metrics towards the investment. (Specific, Measurable, Achievable, Realistic, Time related)Resources -  Who are the resources going to be engaged? What are the procurement needs? What are the infrastructure needs? Etc.,Agile Project Charter Benefits:Agile Opportunity Canvas creates transparency across the entire organization.Provides a rational route and logic of purpose to the entire team from the beginning to the end.Product Portfolio is maintained and prioritized effectively.It helps avoiding duplicate efforts.It also helps in identifying, if the idea/project/ feature is the latest trend in the market.Agile opportunity canvas can be updated during the planning phase and execution phase. During evaluation or closure phase, the project or solution is validated against the success metrics scripted in Opportunity canvas. Success Metrics in Opportunity canvas does not need to be Objective (directly related to Monetary benefits) all the time, it can be subjective (related to value achieved) as well, depending on the nature of the solution and project.
Rated 4.5/5 based on 1 customer reviews

Deliver High Business Value With Agile Opportunity Canvas

175
Deliver High Business Value With Agile Opportunity Canvas

I would like to start this blog with a question.
 
Business case, quite commonly used term in Project Management. Do we agree?
It is a document explaining the justification for a project and expected outcome.
 
Let us have a look at Project, Program and Portfolio Management in the image below.
Every single initiative or project within an Organization is aligned to Organizational strategy.

In an Enterprise level, we tend to see a lot of ideas and requests emerging from stakeholders, clients, internal teams, outcomes of market research. These ideas and requests will convert into a Project, if we see a potential opportunity. In traditional approach or Agile approach, every idea or request should be validated to ensure the right investment is made.
 
Agile is a widely used terminology in IT industry. People often stumble upon understanding Agile and Lean. Lean Methodologies focuses more on value, elimination of waste and delivering the product in small batches. Agile is a subset of Lean thinking.
 
Agile movement was formed in 2001, Outcome of which is Agile Manifesto and 12 Principles for Agile Software development. Agile is an umbrella term covering different methods and frameworks such as Scrum, Scrumban, XP, FDD etc. All Agile approaches/frameworks emphasizes more on Agile Manifesto and 12 Principles.

Agile Model:
Demand Management in Traditional Approach/Waterfall model:

In the traditional approach, a project is selected over another project through Project evaluation tools such as Cost-Benefit analysis, Decision Matrix etc. A project charter will be created during the initiation phase of the project which captures business case, high-level requirements, timeline/milestone, risks, costs and other constraints. A detailed scope in the form of "Statement of Work" is approved during the planning phase.
 
Planning is one time in a Waterfall model and will take a considerable amount of time in the project. Scope(Feature) is Fixed, Time and Cost is flexible in Traditional approach. Any changes to the scope will be difficult to handle in Waterfall model. There are a lot of risks involved in Traditional approach, as planning is one time.
                                                                                                       Fig: Iron triangle- Traditional Approach 
Demand Management in Agile Approach:
 
In the Agile approach, planning is continuous. Planning is done at different stages. This reduces risks.

  • Strategic Planning
  • Portfolio Planning
  • Product Planning
  • Release Planning – Quarterly by entire team
  • Iteration Planning – Bi-Weekly by entire team
  • Daily Planning – Daily by entire team

Frequency and required participants for Strategic, Portfolio and Product planning will differ across organizations.
                                                                                                         Fig: Agile Estimating and Planning 

In the Agile approach, Feature remains flexible, Time and cost are fixed. Agile approach is incremental and iterative in nature. In the Agile approach, we do not have a detailed scope slated during the start of the project. As we evolve during the development phase, there might be new features or enhancements identified by the customers.
                                                                                                          Fig: Iron triangle- Agile Approach

In Agile Demand Management Cycle, an idea/requirement/enhancement is chartered in an Opportunity Canvas which gets reviewed by Investment cabinet.
 
As per agile manifesto # 3- Customer collaboration over contract negotiation and Agile Principle # 1: Satisfying the customer is of highest priority:
 
"Agile opportunity canvas" creates more visibility to the customer and the product owner to prioritize new requirements or enhancements over others. (Enhancements which needs a development effort of minimum 2 months would be considered to be chartered in an Agile opportunity canvas).
 
Demand Management process is followed in both Traditional and Agile approaches. In Traditional approach, since the scope is clear it will be a one-time activity. But in Agile, as we do Rolling wave planning on shorter time span to deliver customer value, we would need a robust demand management process to ensure the right requirements were approved and investment is made for right product or feature.
                                                                                              Fig: Opportunity Canvas & Demand Management

Agile Opportunity Canvas:
 
Agile Opportunity Canvas also referred to as Agile Project Charter is used to ensure whether the business value is captured in the right format, which gives visibility to higher management and decision makers to ensure the investment is made to the right effort.
 
An opportunity canvas is similar to a lean business case. It will help us capture the essential fields.
 
Drafted opportunity canvas will move through the approval process before any project work is initiated.
 
Sample Agile Project Charter template:
There are different elements in an Agile Project Charter. These elements are customized according to the Organizational needs.  Opportunity Canvas is a living document and it should be in One page.

In a nutshell, we should have the required elements populated to move it across the Demand Management. Generic elements to be part of the Opportunity canvas are listed below:

  • Current Problem Statement – Why do we need to implement this idea? What is the Problem statement?
  • Strategy/Value Justification – What is the value proposition this idea provides and what strategy are we adopting.
  • Scope – In scope and Out of scope details for the generated idea/ enhancement.
  • Sponsors and Stakeholders – This could be internal or external to the organization.
  • Financials – What are the costs and benefits associated?
  • Success Metrics – SMART Metrics towards the investment. (Specific, Measurable, Achievable, Realistic, Time related)
  • Resources -  Who are the resources going to be engaged? What are the procurement needs? What are the infrastructure needs? Etc.,

Agile Project Charter Benefits:

  • Agile Opportunity Canvas creates transparency across the entire organization.
  • Provides a rational route and logic of purpose to the entire team from the beginning to the end.
  • Product Portfolio is maintained and prioritized effectively.
  • It helps avoiding duplicate efforts.
  • It also helps in identifying, if the idea/project/ feature is the latest trend in the market.

Agile opportunity canvas can be updated during the planning phase and execution phase. During evaluation or closure phase, the project or solution is validated against the success metrics scripted in Opportunity canvas. Success Metrics in Opportunity canvas does not need to be Objective (directly related to Monetary benefits) all the time, it can be subjective (related to value achieved) as well, depending on the nature of the solution and project.

sayee

sayee krishna

Blog Author

Leave a Reply

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

Suggested Blogs

Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum implementation in an organization. The entire effort of transforming teams with Agile ways of working is bound to fail if the role of a Product Owner is not understood clearly. Listed below some of the anti-patterns seen while the person is playing the role of a Product Owner in a team- Busy or Missing Product Owner, not being part of the development team Working software demo to the PO during Sprint Review Expressing the backlog in Technical user stories instead of focusing on business-related user stories Writing detailed user stories (no scope for negotiation) Questioning the estimates given by the Dev Team Not having a clear acceptance criteria for every story Too large user stories Not questioning the customers while collecting the requirements Not allowing the Dev Team to work on Technical Debt Not validating the customer’s idea before implementing the idea Not allowing Development Team members to talk with the Stakeholders directly Not empowering the Proxy POs Lack of vision on the product being developed Delivering more features than valuable features Not having well-defined prioritization mechanism in delivering user stories Changing priorities or requirements during the Sprint No single Product Owner, required governance missing in case of multiple POs Missing in Scrum Ceremonies Relying on mail communication for answering queries from Dev Team No emphasis on Quality Treating estimates as deadlines Instructing team on what needs to be done, acting as a Manager Expecting user stories to be created by team, considering SM and PO to be there only to review the stories Pushing team to do extra work for finishing everything forecasted during Sprint Planning Holding the team responsible for any rework post feedback from stakeholders during Sprint Review  Not showing interest in answering team queries for clarifications after Sprint planning Task monitoring Not coachable by Scrum Master Unable to prioritize the work Consistently changes priorities during the Sprint Accepting partially completed PBI’s Allowing dev team to change the Story points of a user story post implementation Not saying “No” to the stakeholders and allowing the product backlog to grow in size   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.  #MostPopular in 2017: "Product Owner Anti-Patterns — 31 Ways to Improve as a PO" https://t.co/sryCdoxVKu pic.twitter.com/q5Sxj9kF6F — Stefan Wolpers (@StefanW) 22 December 2017 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 clearness 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 its 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 worthful modeling techniques. Actually, the PO has an idea about when to apply a specific model. Based on the model application he/she drives the project success.  Shares experiences: A great Product Owner offers experiences with peers. This may be inside the organization, and outside it. Additionally, courses and meetings are the great approaches to share experiences and garner information. Furthermore, recording your lessons can be significant for other Product Owners. 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 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 his domain. A product should be built with a clear idea of every aspect being dealt with. This not only entails understanding the organization and paying for the development 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 available. A great Product Owner is characterised by his availability 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 always makes sure that his availability never becomes the bottleneck of the progress of the development team.  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 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.  Concluding Thoughts: A Product Owner is indispensable for a functional Scrum team. He not only bridges the gap between the development team and the client but also ensures a 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 a clarity of PO roles and a proper understanding of the end-to-end Scrum processes. 
Rated 4.0/5 based on 7 customer reviews
Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the su... Read More

Challenges & Recommendations To Be A Successful Agile Coach

In the real world, there are many versions of Agile implementation which are tailor-made to fit into existing organization’s AS IS hierarchy and operating patterns. Top leaders and managers understand that Agile coach’s role is pivotal to make Agile transformation feasible and possible in their organization. Let us consider different scenarios under which Agile coach is hired for transformation purpose on a project or in the organization:  When an Agile coach is hired as an external contractual consultant for a specific duration to make people aware of Agile principles/values for the first time and help in transitioning for one or two releases When an Agile coach is hired as full-time employee - after initial awareness is created by external consultant but practices were not followed, so now the organization wants to get implementation done through full time Agile coach When an Agile coach is either hired as full time employee or taken from a pool of Agile folks available to the organization - to generate  awareness from scratch and own the responsibility of Agile implementation on a specific project or account There are pros (which serve as strength to the coach) and cons (serve as a challenge) in each of the scenarios mentioned above for an Agile coach. Based on these pros and cons the recommended approach has to vary dynamically. Scenario 1:  Agile Coach is hired as an external consultant for a specific duration (3 to 6 months) – to create awareness & lead implementation by handholding for one or two releases. Pros:  Strong support from SPONSOR OR Top management (Be it hierarchical or flat hierarchy-based organization) Middle management for e.g. Project managers or Technical leaders agree and accept the change due to decision made by top management Cons or Challenges:  Project Managers or Technical leaders attend all awareness sessions due to top management’s pressure but do not completely accept or understand the benefits of agile implementation. This leads to GAPS leading to incorrect IMPLEMENTATION  Project Managers or Technical leaders send selected members for awareness of their preference. Rest of the team members are interested in understanding Agile too but they mostly woder “WHAT IS THIS AGILE STUFF really?” I would also like to know.. as I am going to do coding & testing in Agile way too”. This leads to a low awareness spread across the project or organization  Recommended Approach: Conduct stakeholder analysis: Identify stakeholders and prepare Stakeholder analysis graph – Power/influence vs Interest in implementing Agile transformation. Sponsor (High Interest, High Power), Project Managers (Interest variable, Medium Power), Product Owner (variable interest, Medium to high power). Make sure to enlist every individual role’s name with role in this quadrant at least for one or two major projects If this is organizational change. Set expectation to each role based on Agile Roles- Identify and set expectation for each Agile Role verbally and in written by agreeing in the expectation management meeting– Product Owner(who may be a current Business analyst), Scrum Master(who may be a current Tech Lead or Team Lead), Future Agile coach(within organization), Project Manager(though is not a role in SCRUM but is needed to oversee the entire transition and collect metrics and remove project level impediments and client management ensure success of a process and product delivery) Make batches of 15-30 participants & Conduct Coaching session for tailored different target Agile roles identified in point no. 2.  Ensure that Project Managers understand their role in terms of supporting transformation and how success factors need to be measured and monitored at specific intervals to ensure their engagement. Conduct tests or quiz at the end of each session and share the results of each role group with top management to show the awareness of knowledge transferred Call randomly one person from each role group to present their understanding to the top management. For e.g. Chief Product Owner must ensure whether Product Owners understand the importance of backlog grooming & refinement, whether they can write crisp user stories to support INVEST criteria. Similarly, Scrum Master & Project Managers should also be called upon to present their implementation approach and how they will successfully carry out transformation on ground Also, team members should be provided tests and called upon randomly to present their understanding about basic Agile overview, values and principles, roles and responsibilities. Coaches should guide all the roles with usage of Agile life cycle tools & managers to check metrics and reports from those tools.  Coach can be present for one or two releases, to see if the implementation by attending Agile ceremonies or meetings for each team randomly to see if everything is falling in place and help managers by guiding about how to measure and demonstrate metrics with transparency, inspection, and adaptation. Once all falls in place which takes around 3 to 6 months (based on acceptance from all leads) window for a project or organization of about 100 -150 people then external Agile consultant can move on to another assignment. Coach should share Agile learning reference manuals and templates on a shared repository so that everyone remains Agile aware even after he/she leaves at the end of a contract. Manager’s support is pivotal to keep Agile best practices going on after an external coach leaves the project or organization. Scenario 2:  Agile Coach is hired as full-time employee – lead implementation after external coach leaves Pros:  Strong support from Top management (in case of hierarchical organization) Middle management for e.g. Project managers or Technical leaders agree and accept the change due to decision made by top management( in case of hierarchical organization) Cons or Challenges:  Low to medium support from  Top management (in case of flat or less hierarchical organization) Middle management for e.g. Project managers or Technical leaders may not agree and challenge every decision and create hindrance at every step (in case of flat or less hierarchical) as they have rights to make decisions at their project level Recommendation:  Conduct Stakeholder analysis as described in pt. 1. In scenario 1 to keep handy the stakeholder map and create a strategy to handle each set of stakeholder differently based on their power and interest Be in observational mode for a couple of iterations :- Attend all Agile meetings to check if all meetings/ceremonies are followed as per the methodology suggested  Take a note of GAPS in Agile practices not being followed. After a couple of iterations, start recommending corrective actions formally during Agile meetings or ceremonies verbally.  If specific set of stakeholders do not follow recommendations despite verbal & written reminders then escalate it to the project manager. Project manager generally supports in hierarchical organizations to close the gaps formally in case there are is no ego problem. In case of non-hierarchical organizations support from managers is less or non-existent which leads to an approach wherein building personal rapport with non-collaborating stakeholders like Tech leads or Team Leads is the only way to get implementation through Also, refresh the Agile basics of team members and leaders by sharing good articles or videos on various Agile topics.  As per stakeholder analysis and gaps found in Agile implementation per role, group coaching should be targeted to fill the gaps.  For e.g. if  product owners do not break epic into stories and technical team enters technical tasks instead of user stories in every iteration, then there is a need for the Product Owner to be trained on backlog refinement or breaking epics into user stories OR breaking bigger stories into smaller ones then coach them by sharing examples of doing it by one-to-one coaching OR YouTube videos OR articles present on internet sources or publishing self-written white papers or videos or presentations to educate the product owner about writing user stories in Agile. Ensuring inter-team meetings (for e.g. scrum of scrum) to happen where team leads can highlight dependencies and find resolutions to mitigate risks related to schedule slippage. Such meetings also aid sharing lessons learnt  across teams to ensure consistency in implementing best practices. Conduct coaching presentations – One presentation topic to address entire project at least once in a week to ensure everyone is on the same page and also to ensure consistent application of Agile implementation. After essential coaching sessions are conducted as a refresher awareness sessions tests should be conducted in the form of quizzes to check if everyone is aware of Agile practices. Check at regular intervals - sprint or release - If Agile lifecycle management tool like JIRA or RALLY etc. reflect the progress of the project as it is on ground thereby maintaining transparency to ensure that metrics get collected to review if milestones are reached as per schedule and devise strategy to mitigate risks to close gaps or slippage well in advance. Ensure Project managers measure metrics suggested and monitor project health at specific intervals to ensure their engagement. Help Project managers to maintain a log of Agile practice gaps or impediments – backlog, open and closed along with start and end date and actions taken to monitor progress of all gaps closed in a particular duration and the actions taken can help other projects in future implementation Present a milestone chart to the SPONSOR or top management along with the project manager about how transition happened with the gaps found initially and actions taken to close them and how Agile transformation was successfully achieved. Once the project is established in Agile practices after a couple of releases, an Agile coach can move onto another project or account. Scenario 3:  Agile Coach is hired as a full-time employee – create awareness and lead implementation   Looking for a Full time position as an Agile Coach?! You've come to the right place... https://t.co/7RXWV1AMxp #Scrum #Jobs #AgileCoach — AgileCareers (@agilecareers) April 12, 2016 Pros:    Strong support from SPONSOR OR Top management (in case of hierarchical organization) Middle management for e.g. Project managers or Technical leaders agree and accept the change due to decision made by top management(in case of hierarchical organization) Cons or Challenges: Project Managers or Technical leaders attend all awareness sessions due to top management’s pressure but do not truly accept or understand the benefits of Agile implementation. This leads to GAPS leading to incorrect IMPLEMENTATION (in case of hierarchical organization) Low to medium support from  Top management (in case of flat or less hierarchical organization) Middle management for e.g. Project managers or Technical leaders may not agree and challenge every decision and provide hindrance at every step (in case of flat or less hierarchical) as they have rights to make decisions at their project level Recommended Approach: Combination of recommended approach for scenario 1 and 2  Note:  These approaches are subjected to how they are carried out by an individual coach. There might be many other successful approaches based on the challenges faced in a real world which is full of multiple diverse surprises.   
Rated 3.5/5 based on 4 customer reviews
Challenges & Recommendations To Be A Successful Ag...

In the real world, there are many versions of Agil... 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.   Check out this Meetup: Practicing Mindfulness in an Agile Environment with @mameghji https://t.co/rlRHvVkJfl#Meetup#MK138PP#Agile#mindfulness#Scrum#Lean#Innovation#servantleadership via @Meetup — Matthew Moran (@moran_matthew) 9 January 2018   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.  
Rated 4.5/5 based on 5 customer reviews
Is Servant Leadership Part And Parcel Of A Scrum M...

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