Search

Progressing From Agile Practitioner To Agile Coach- A Perspective

Introduction: -With Agile becoming a norm in the current world, enterprises that want to be in the forefront of transformation typically focuses on an adoption strategy that involves hiring Agile practitioners. This hiring is expected to create and foster an Agile culture by coaching employees who may not have any prior Agile experience.I had an opportunity to lead one of the high profile enterprise Agile product development in my organization for a US client. It was a multi-year program with more than 60+ team members distributed geographically across 4 locations (India & US). The program was highly visible and had all tight constraints in terms of budget, timeline, and quality. The client’s engineering teams were too slow in adoption and were not supported by strong engineering practices and focusing only on management aspects.The hope was that my 'extreme programming and engineering practices' background would bring light at the end of the tunnel! Also, since I had spent a considerable amount of time as a practitioner and had attended internal training on coaching, my manager was confident about my accrued experience.I took on all these challenges one by one and also in the meantime I learned that coaching involves three simple stages, as follows. Let’s see these 3 different stages of Agile Coaching that will help you to move from an Agile Practitioner to Agile Coaching.Three Stages/Phases of Agile Coaching: -First is the Assessment Stage, where I observed existing processes and interaction with the team members, gauging them on technical and non­-technical considerations. I evaluated some of the baseline metrics and assessment reports.I was able to identify some of the key improvement areas that could help the team and client progress towards the goal quickly and deliver value. I had devoted a lot of time in listening actively to the team members on multiple occasions. This gave lots of insights into various processes and standards followed by the team and its dynamics. Some of the key challenges that existed were,Non-standardized approach by the team leading to the suboptimal solution.Unwilling to share the best practices or knowledge.Lack of cross synergy and cohesion thereby decreasing overall velocity.Losing focus on the big picture leading to silo working modelThe second is the Active coaching stage where I started encouraging the team members to set specific goals and provide accountability and followed-up to improve the performance. More often I would have open conversations like “What can I do to help you improve?” and create awareness around the problem or issues.I was able to change or influence the behavior patterns of the team on retrospectives during stressful times by not attending the ceremony. This provided freedom to the team members and allowed them to express freely on the pitfalls and improvement areas.I noticed a few things..The build took almost 2 hours, potentially delaying deployment across multiple stages. I probed the team to come up with new ideas to reduce the build time and team was able to explore multiple options and with maven scripts, the team reduced the build time to 45 minutes (60% reduction).The personal characteristics and attitude are most difficult to change as they are built from childhood. I would often leave it to the individual to resolve if there is a need to change and why it would benefit them personally.The key was to actively listen to their opinions, ideas and most importantly to empathize and motivate the team members. I realized as a coach, that influencing or changing behaviors of the team cannot be done overnight and provide immediate results but was always a gradual and long-term process. Over a period of time, the team became self-sufficient and I observed well-enabled retrospectives and well maintained Jira boards.  The difference between completed and accepted story points came down to 3-5% from 8-10%. The team had started realizing their potential without much of an active involvement from me. Team dynamics often created unpredictability (low motivational levels, low performance, poor standards etc.) and I was careful particularly in not providing any directions and specify the outcomes rather understood the working ways of the team and coached them to overcome all of these challenges by themselves.The final stage is Sustainability, which is to continue to perform better indefinitely while I stepped back and enjoyed the results and performance of the team. In some iterations, the results were excellent and few iterations stayed flat.I reviewed the qualitative and quantitative metrics from time to time just to make sure the fundamentals were being followed and as long as there is a harmony in the team, I didn’t interfere. I also learned to identify the quick learners, star performers and nurtured them as they were the ones who would eventually become the team’s influencers and motivators and made them as the internal coaches to continue this endeavor forever. I fostered a healthy relationship with multiple units in the team, for the team to function more effectively.Responsibilities of an Agile CoachPlays a mentoring or coaching role in the organization without being a part of the Scrum teamMost often this person is not a part of the Scrum team and an outsider (from outside the organization)Guides the team members, without personal or political considerationsThe person is an Agile expertIs experienced in implementing Agile techniques in different cultures and environmentsAble to run the complex and different sized Agile projects successfullyA Roadway from Agile Practitioner to Coach:-The coaching experience gave me a sense of fulfillment as I would see mostly the team smiling and brimming with ideas for improvement constantly in the journey of self-reliance. This has helped me improve my personal traits to a greater extent and I feel that I’ve made a sincere attempt to embed myself into my organization towards enterprise agility.Despite the resistance from the team members to change, I was able to win and influence them through my communication, empathy and logical reasoning skills. I truly believed coaching focuses on helping another person learn in ways that let him or her keep growing afterward. It is based on asking rather than telling, on provoking thought rather than giving directions and on holding a person accountable for his or her goals.
Rated 4.0/5 based on 0 customer reviews

Progressing From Agile Practitioner To Agile Coach- A Perspective

142
Progressing From Agile Practitioner To Agile Coach- A Perspective

Introduction: -

With Agile becoming a norm in the current world, enterprises that want to be in the forefront of transformation typically focuses on an adoption strategy that involves hiring Agile practitioners. This hiring is expected to create and foster an Agile culture by coaching employees who may not have any prior Agile experience.

I had an opportunity to lead one of the high profile enterprise Agile product development in my organization for a US client. It was a multi-year program with more than 60+ team members distributed geographically across 4 locations (India & US). The program was highly visible and had all tight constraints in terms of budget, timeline, and quality. The client’s engineering teams were too slow in adoption and were not supported by strong engineering practices and focusing only on management aspects.

The hope was that my 'extreme programming and engineering practices' background would bring light at the end of the tunnel! Also, since I had spent a considerable amount of time as a practitioner and had attended internal training on coaching, my manager was confident about my accrued experience.

I took on all these challenges one by one and also in the meantime I learned that coaching involves three simple stages, as follows. Let’s see these 3 different stages of Agile Coaching that will help you to move from an Agile Practitioner to Agile Coaching.

Three Stages/Phases of Agile Coaching: -

Three Stages/Phases of Agile CoachingFirst is the Assessment Stage, where I observed existing processes and interaction with the team members, gauging them on technical and non­-technical considerations. I evaluated some of the baseline metrics and assessment reports.

I was able to identify some of the key improvement areas that could help the team and client progress towards the goal quickly and deliver value. I had devoted a lot of time in listening actively to the team members on multiple occasions. This gave lots of insights into various processes and standards followed by the team and its dynamics. Some of the key challenges that existed were,

  • Non-standardized approach by the team leading to the suboptimal solution.
  • Unwilling to share the best practices or knowledge.
  • Lack of cross synergy and cohesion thereby decreasing overall velocity.
  • Losing focus on the big picture leading to silo working model

The second is the Active coaching stage where I started encouraging the team members to set specific goals and provide accountability and followed-up to improve the performance. More often I would have open conversations like “What can I do to help you improve?” and create awareness around the problem or issues.

I was able to change or influence the behavior patterns of the team on retrospectives during stressful times by not attending the ceremony. This provided freedom to the team members and allowed them to express freely on the pitfalls and improvement areas.

I noticed a few things..

The build took almost 2 hours, potentially delaying deployment across multiple stages. I probed the team to come up with new ideas to reduce the build time and team was able to explore multiple options and with maven scripts, the team reduced the build time to 45 minutes (60% reduction).

The personal characteristics and attitude are most difficult to change as they are built from childhood. I would often leave it to the individual to resolve if there is a need to change and why it would benefit them personally.

The key was to actively listen to their opinions, ideas and most importantly to empathize and motivate the team members. I realized as a coach, that influencing or changing behaviors of the team cannot be done overnight and provide immediate results but was always a gradual and long-term process. Over a period of time, the team became self-sufficient and I observed well-enabled retrospectives and well maintained Jira boards.  

The difference between completed and accepted story points came down to 3-5% from 8-10%. The team had started realizing their potential without much of an active involvement from me. Team dynamics often created unpredictability (low motivational levels, low performance, poor standards etc.) and I was careful particularly in not providing any directions and specify the outcomes rather understood the working ways of the team and coached them to overcome all of these challenges by themselves.
coaching difficulty & resistance in agileThe final stage is Sustainability, which is to continue to perform better indefinitely while I stepped back and enjoyed the results and performance of the team. In some iterations, the results were excellent and few iterations stayed flat.

I reviewed the qualitative and quantitative metrics from time to time just to make sure the fundamentals were being followed and as long as there is a harmony in the team, I didn’t interfere. I also learned to identify the quick learners, star performers and nurtured them as they were the ones who would eventually become the team’s influencers and motivators and made them as the internal coaches to continue this endeavor forever. I fostered a healthy relationship with multiple units in the team, for the team to function more effectively.

Responsibilities of an Agile Coach

  • Plays a mentoring or coaching role in the organization without being a part of the Scrum team
  • Most often this person is not a part of the Scrum team and an outsider (from outside the organization)
  • Guides the team members, without personal or political considerations
  • The person is an Agile expert
  • Is experienced in implementing Agile techniques in different cultures and environments
  • Able to run the complex and different sized Agile projects successfully

A Roadway from Agile Practitioner to Coach:-
The coaching experience gave me a sense of fulfillment as I would see mostly the team smiling and brimming with ideas for improvement constantly in the journey of self-reliance. This has helped me improve my personal traits to a greater extent and I feel that I’ve made a sincere attempt to embed myself into my organization towards enterprise agility.

Despite the resistance from the team members to change, I was able to win and influence them through my communication, empathy and logical reasoning skills. I truly believed coaching focuses on helping another person learn in ways that let him or her keep growing afterward. It is based on asking rather than telling, on provoking thought rather than giving directions and on holding a person accountable for his or her goals.

Ramkumar

Ramkumar Armugam

Blog Author

Ramkumar is an experienced Program Manager with 13+ years of success in leading all phases of diverse technology IT Projects in retail, e-commerce, insurance and pharma market research industries. He has more than 7+ years of experience in leading and executing projects and programs using agile and lean methodologies. He is currently working as Senior Manager in Cognizant Technology Solutions India Pvt Ltd and holds multiple certifications including PMP, PMI-ACP, CSM, CSPO, CSP and ICP-ACC. He has a zeal for project and program management and his current endeavor includes leading a large scale distributed product development team in delivering a world class product features in the area of Finance and HR domains for a large US retailer. He is a regular contributor to projectmanagement.com.

Join the Discussion

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

Suggested Blogs

Common Challenges Faced By First-Time Agile Organizations

Finally, you have decided to implement Agile. After a lot of deliberation on whether Agile is right for your organization, and fighting the demons of doubt you have taken the plunge. Maybe you have hired or decided to hire an Agile coach, sent your employees for Agile training, or hired a consultant to rewrite your operations manual. Now you are gearing up to reap the benefits of Agile. But somewhere in a corner of your mind, there is a nagging skeptic asking you whether your organization is ready for Agile. And truly, implementing Agile for the first time can prove to be a herculean task. But as they say, well begun is half done, or the forewarned is forearmed. So gathering information about things that could go wrong or challenges you could face while implementing Agile for the first time may make the difference between failure and success. So here are some things that you need to look out for as an organization implementing Agile for the first time.Expectations from Agile: This is the most common and often the biggest challenge while implementing Agile. It is very important to know what are the expectations from Agile or why has your organization decided to implement Agile. Agile is a project management methodology, and more importantly, it is a philosophy that prioritizes delivery over paperwork. However, one thing that Agile is not, is a cure-all remedy for all maladies. If there are deep-rooted problems in the organization which cannot be helped by Agile then implementing Agile might lead to more frustration. For example, if your organization is struggling to recruit or retain quality developers, or if your sales team is used to making excessive promises to close the deals, then Agile might not be the answer you are looking for. And it may be better to put the house in order before inviting Agile in.Resistance to change: As with anything new, the inertia of established routine is the biggest hurdle. People develop certain habits and practices around their way of work. This is a natural phenomenon which makes work easier and customized to people’s pace and ability. For example, a program manager may be used to conduct an hour-long meeting every day with team members from all teams present. This gives him a confidence of being in control of the projects and peace of mind that there are no unpleasant surprises around the corner. If this manager is told that he has to do away with this practice and rely on the daily standups or Kanban boards for overview, it may not be the most welcome suggestion. Here it is important that the employees are not just given a training in Agile methodologies but also an understanding of the Agile philosophy. Employees need to be explained why the organization has chosen to implement Agile and their fears and anxieties addressed.Residue from old methodologies: Similar to resistance to change but not quite the same. They say old habits die hard. And sometimes people may truly understand the importance of adopting Agile and genuinely try to implement it. But the spirit of old processes stays with them. So the retrospective is used to track the status of the tasks, instead of looking for challenges and learnings. Sometimes, teams may take ages to create product backlog and move into construction iterations because they are waiting for the requirements to finalize (remember, Agile is geared to handle changing customer requirements). Or sometimes, design documents are added as deliverables instead of treating them as artifacts and sprints are planned around design documents due to poor understanding of Agile.Too much focus on ceremonies and artifacts: When organizations implement Agile, the first thing they do is train some of their employees in Agile, that is one of the many methodologies in Agile. Most often it could be Scrum, Kanban or Lean. But it is important to understand that Scrum, Kanban, Lean or any other methodology are just a part of Agile. A way to implement Agile. And while ceremonies and artifacts are important in each of the methodologies, they do not define Agile. Just like knowing the rules of tennis won’t make you a better tennis player or knowing how to operate a vehicle, does not make you a better driver, knowing the ceremonies and artifacts of a certain methodologies does not make you a better Agilist. The real danger is of the core philosophy of Agile, of giving more value to delivery over processes and documentation, can be easily forgotten in the enthusiasm of implementing Agile. And a new methodology just replaces the old methodology without any gain in efficiency.Evaluating Agile implementation: Another challenge faced by organizations implementing Agile for the first time is evaluating the success of their Agile implementation. It is required to define parameters of success for Agile implementation and most often, very erroneously, companies choose form over content in this matter. Thus companies measure how many teams have moved to Agile, or how many projects are following the new methodology. They evaluate whether all ceremonies are being followed correctly and measure the number of stand-ups or retrospectives held. However, it would be ideal if companies rather evaluated how the implementation of Agile has helped them achieve the original goals of Agile implementation. For example, maybe reduction in the number of delayed deliveries or reduced customer escalations.Customers’ understanding of Agile: It is, without doubt, a necessary step in the implementation of Agile to let the customers know about the organizational changes taking place. And while the seamless transition is every organization’s dream, there are bound to be some hassles and slip-ups, as the teams adjust not just to a new routine but to a new mindset altogether. But more important than forewarning customers about the possible teething problems, is knowing whether customers understand what the implementation of Agile means to them. Do they still expect you to provide work plans and Gantt charts? Do they think Agile means a free pass to change the requirements as many times and as often as they wish? While Agile is geared towards adapting to changing customer requirements, financial and contractual constraints should be kept in mind and Agile has a very specific way of handling fixed cost contracts with a prioritization or elimination of story points. It is important to not just train the employees but also the customers in this process.While implementing Agile may be a step forward, it involves a lot of work and emotions and passions run high as people and processes collide. Hiring an Agile coach may help you maneuver these challenges but not without an effort from the entire organization, from the executives and senior management to the rookie programmers. As with any good harvest, the yield from Agile depends on the efforts that go into implementation.
Rated 4.0/5 based on 0 customer reviews
Common Challenges Faced By First-Time Agile Organi...

Finally, you have decided to implement Agile. Afte... Read More

How to Launch Your 1st SAFe Agile Release Train

So, you are excited to organize and launch your 1st SAFe Agile Release Train. Understanding the importance, structure, and deployment of ART (SAFe Agile Release Train) is the central of SAFe Agile implementation to scale & successfully implement the complex projects, deliver maximum business values and complete the project on time well under the budget. Just like a train carries its passengers to deliver at set destinations within pre-estimated time at defined cost, ART also helps you carry out the projects successfully; however, before starting the journey with an efficient ART, you must know the principles that govern Agile Release Train.    10 Steps to Launching your First SAFe Agile Release Trainhttps://t.co/dNWUfCwMBd pic.twitter.com/rT8FDhqcoj — Yves Mulkers (@YvesMulkers) 27 January 2018 5 Governing Principles for SAFe Agile Release Train:  ART is the self-organised team of Agile Teams. It is composed of Agile teams engaged in development, security, DevOps, Enterprise Architecture etc. ART plans. It commits & executes the processes following a specific timeframe often called - PI (Program Increment). ART must follow a value delivery model for periodic planning and timely release.  ART must follow a common iteration length within the PI.  ART must know the clearly-defined objectives & benchmarks. ART must follow the culture of continuous system integration. The works completed by different teams must be integrated at each sprint to keep the developments in releasable state. ART must respect customer previews, internal reviews, and system level QA.    Roadmap to Launch SAFe Agile Release Train:  1.Train the SAFe Program Consultants (SPCs): Train your SPCs properly, the change agents responsible for transformation and connecting the Scaled Agile Framework (SAFe) to your organization. SPCs teach all the stakeholders & leaders to drive the ART to its destination.  2.Train the Lean Agile Leaders: Lean Agile leaders are expected to understand and implement the principles of SAFe Agile framework. Lean Agile Leaders are also responsible to lead & facilitate SAFe adoption for improved outcomes. And for smooth transition, you need to train the Lean Agile Leaders up to the best standards.   3.Identify Value Streams and ART:  SAFe Agile Release Train is a procedural system; therefore, you should make all the responsibilities of solution defining, building, validation, and deployment etc clear.  4.Organize ART and Agile Teams:  The roadmap to organize the ART and Agile teams contains different millstones including:   Well-defined ‘product’ with features/components Leadership support Collaboration Minimized dependencies Integration Well-managed DevOps activities 5.Define and Fill All The Roles Of ART Members:   The critical roles of ART members must be well defined to help the Release Train Engineer, System Architect, Product Managers, Scrum Masters, Product Owners perform the best at par with customer’s expectations.     6.Prepare the Program Backlog:   The practice of using launch date as the forcing function makes it more urgent to determine the scope and vision of PI. The scope of ‘what is built’ or PI is defined by ‘Program Backlog’ informing about the upcoming features, architectural work, and NFRs. The gained vision about the future behaviour of system helps you create short stories for Agile teams.        7.Train the Teams Train the teams properly to deliver the maximum values at each sprint. It is the key part of ART readiness to ensure the on-the-time best quality ‘product’ delivery. 8.Conduct PI Planning  PI planning is a face-to-face meeting event; it empowers the Agile Release Train to align all the SAFe Agile teams for the shared mission & vision.  9.Set the Program Calendar & Launch Date  Now you have ART definition. The next task is scheduling your 1st PI Planning event focused on the forcing functions and ‘date-specific’ launch with PI calendar. The PI calendar shows the scheduled activities including PI planning, System demos, ART sync, Inspect & Adapt (I&A) workshop etc.  10.Execute Innovation and Planning Iteration:  Now, you are almost at the destination. Innovation and planning iteration is conducted to absorb the variances in estimates, allot time for innovation, refine backlog and to plan ‘Inspect & Adapt’ workshop.  Conclusion: Launching SAFe Agile Release Train (ART) for the first time can be a challenging and complex task; therefore, before going ahead, you should acquire the expertise by joining short-term SAFe 4 Release Train Engineer certification training designed to guide you through for efficient ART launch. .   
Rated 4.5/5 based on 7 customer reviews
How to Launch Your 1st SAFe Agile Release Train

So, you are excited to organize and launch your 1s... Read More

Agility In QA Mindset Is A Key To Success In The Agile Era

Whenever it comes to Agile software development methodology, there are a few Manifesto and Agile Principles that comes to the mind.As we can see, Agile completely believes in“Customer Satisfaction, feedback loop, team collaboration, quick delivery, embracing change request, trust and support, face to face communication, working software, sustainable development, continuous attention, mentioning the simplicity, self-organizing team, reflect and adjust.”The intent behind coming up with Agile looks quite interesting.A quick view on Waterfall modelLet’s talk more from a QA standpoint. As we know, traditionally, in the Waterfall model of Software development workflow would typically look like this.In the traditional software development approach, the complete software development process is splitted into different phases. The output of one phase is acting as a Input for the next phase. This indicates that any phase is incomplete if the previous phase is not completed. That is the reason, the waterfall model is called a sequential model. In sequential approach, the phases flow towards the downward direction through the phases of Requirements, Design, Implementation, Verification, Maintenance as shown in figure above.  In traditional software development process, requirement would be frozen during the initial phase followed by which development of software would begin. Hence, Software testing life cycle will typically look like this-So a Qualitative Analyst (QA) would follow the below workflow-Requirement understanding -> Brainstorming -> Writing Test Scenario -> Writing Test Cases -> Verification -> ReTesting of defect (if any)The above workflow makes sense in the world of Waterfall model. However, with high Agile acceptance in the industry, a shift from Waterfall to Agile Mindset is required. In case of implementing QA Mindset for achieving Agile Manifesto, more of a ‘Shift-Left’ testing is embraced. The entire team is highly involved right from the  Requirement understanding phase to Delivery/Maintenance phase.So the bifurcation between the Software Developer and QA is not there in a team which truly follows Agile. The entire team works together towards a defect tracking instead of finding them and verifying during the verification phase.Steps Towards Developing QA Mindset for Successful Agile ManifestoLet’s talk more from Ground 0 now.During the Grooming phase, Developer and QA pair up with each other and come up with their set of understanding and discuss among themselves around the requirement. Once the brainstorming is done, a list of Open questions are posted to the client for clarification around the same.Post Grooming, the Sprint planning phase kicks in, wherein, based on the answers given by the client, the teams have a better visibility around the requirement. Hence, realistic estimates are given for the User Stories inclusive of Development/Quality Analyst/Business Analyst pairing.Post Planning, the QA starts with writing Test Scenarios/Cases activity. During the course of documentation, QA and Developer team collaborate with each other to ensure they are on the same page. In case of any scenarios that were missed by either of the team, they take care of the same during the Coding/Documentation phase itself. It helps in eliminating the late defect cost.Once the developer is done with Coding and is about to get started with dev testing, a QA member pairs up with the Developer to ensure things are working as expected at a high level.Once the Code is ready and is deployed to QA environment, QA starts with the end-to-end verification of the story. Hence, the possibility of discovering a defect decreases exponentially.QA in Waterfall vs. QA in AgileIn the Waterfall model, QA used to get appreciated based on the number of defects that were found during the verification phase. As a result, somehow teams use to work in a silo which would result in the change of the entire codebase, sometimes the architecture itself. As a result, cost of project would go up significantly as described in the below image.On the contrary, in case of a team which follows Agile truly, a Developer/QA gets appreciation based on Minimal code changes and less number of defects found. There is a high acceptance of Shift-left testing in the industry because of the amount of benefit it has brought in terms of effort saving for rework.So, Agile Testing is not a unique way. It needs to integrate successfully QA Mindset into Agile Manifesto. It is a kind of change in the mindset which does not happens overnight. Along with that, it requires knowledge, skill-set, and proper coaching. Hence, a shift in the Agile QA mindset is required to ensure a high throughput from a team. This article is focused on changing a mindset to Agile by providing the tips for implementing QA Mindset into the Agile Manifesto.Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, it would be great if you’d help it spread it to your connections on LinkedIn or other channels.
Rated 3.5/5 based on 2 customer reviews
Agility In QA Mindset Is A Key To Success In The A...

Whenever it comes to Agile software development me... Read More