Agile Transformation: A Step by Step Guide | Jimmy Mathew | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Agile Transformation: A Step by Step Guide

teacher avatar Jimmy Mathew, Agile Consultant

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

12 Lessons (54m)
    • 1. Course introduction

      9:50
    • 2. Step 1 Understand the Organisation, Culture and Practices

      3:52
    • 3. Step 2 Understand the drivers and set goals

      5:05
    • 4. Step 3 Define Road map

      7:03
    • 5. Step 4 Make Agile visible

      3:39
    • 6. Step 5 Agile training

      3:35
    • 7. Step 6 Align Organization structure and high level processes

      3:41
    • 8. Step 7 Start with Agile Practices

      4:22
    • 9. Step 8 Team level transformation

      3:53
    • 10. Step 9 Inspect and Adapt

      2:48
    • 11. Bonus Lecture Agile Manifesto

      5:28
    • 12. Outro Our Courses in SkillShare

      0:55
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

25

Students

--

Projects

About This Class

Agile Transformation: A Step by Step guide for Agile Coaches”.

This course introduces a step by step approach for Agile Transformation.

**************************************************************************************

  • A Step by Step approach for transforming teams to Agile ways of working

  • Simple and ready to use templates, resources (attached to the class project session)

  • Course designed by Certified Agile Coach with extensive experience

  • "To the point" training, less duration, more value

****************************************************************************************

***************************************************

*Updated as per the latest Scrum Guide, Nov 2020. We have updated the course content as per the changes made in the latest version of the scrum Guide(TM)

***************************************************   

Coaching, Agile Coaching, Transformation, Agile Transformation, Agile Coach, Transformation Coach…. Lots of combinations we hear in everyday life. We are discussing about agile transformation here.

The approach we follow in this training is “Agile Transformation with an Agile Coaching Mindset”.

The word agile is repeated here. The first “Agile” represents two concepts. First, we are transforming to agile ways of working and second this transformation itself done in an agile way. The second Agile is used as an attribute of Coaching, coaching with an agile approach.

Meet Your Teacher

Teacher Profile Image

Jimmy Mathew

Agile Consultant

Teacher

Around 15 years in IT, 7 years of Agile experience, playing various roles of Agile Coach, Scrum Master, Trainer, etc.

Publications  

Book: - Scrum Tales: Stories from a Scrum Master's Diary  

Book: - Agile Life: Understanding agile in a non-software context  

Certifications

 

.      ICP-ACC - ICP Agile Coaching   

·      CSP – Certified Scrum Professional  

·      CSM – Certified Scrum Master  

·      SAFe - Scaled Agile Framework-Agilist  

·      PSM1 – Professional Scrum Master  

... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Course introduction: Hello, welcome to this training Agile transformation, a step-by-step die. We are discussing various steps in Agile transformation journey. Each of these steps are discussed in detail from the next lesson. There are a few resources, artifacts, templates attached to this course. These are simple and easy to use. Before starting transformation journey, let's analyze the title of this course on Zhao transformation, a step-by-step guide, coaching, Agile coaching, transformation, Agile transformation, Agile coach, Transformation Coach, lots of combinations we have in everyday life. We are discussing the Agile transformation. Hey, the approach we follow in this training is Agile transformation. Within Agile coaching mindset. The word agile is repeated here. The first, Agile represents two concepts. First, we are transforming to agile ways of working. And second, phase transformation itself is done in an agile way. The second agile is used as an attribute of coaching. Coaching with an agile approach. Let's define this before going further. This is how the word transformation is defined. It is a malt change in the form, nature, or appearance. It is a change. This change can be applied to any attribute of an object. The attributes under consideration changes from state a to state B. That is from an initial state to a new state. We are not using the word final state here because we believe change is the only constant in the world and the state may change again. There are three constructs here. Initial state, new state, and the change itself. If we don't know the destination, we can take any route. But it is not our intention. If we don't know where we are, no framework, approach or experience can help us. Change itself has its attributes. A change can be permanent or temporary. A change can be a result of internal desire, will external pressure? A change can be well-reasoned or forced in. Now, I dodged transformation. The next word in the dictionary, meaning for Agile is able to move quickly and easily. Also, a much talked about attributes on Agile Alix flexibility, ability to respond to changes. The Wikipedia definition says, agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self organizing and cross-functional teams and their customers or end uses. Advocates adaptive planning, evolutionary development, empirical knowledge, and continual improvement. And they encourages rapid and flexible response to change. Many characteristics I mentioned here cross-functional, self, adaptive, evolutionary, empirical, continuous improvement, flexible, et cetera. Let's not reinvent the wheel here. There are many proven agile methodologies like Scrum, Kanban, Extreme Programming and scaling frameworks like safe, less, Scrum of Scrum, nexus, etc. Our aim is to transform the existing teams to one or a combination of these methodologies or onboard a new team or teams in an Agile project. How job plan Agile transformation? In our approach, we believe the transformation itself must be agile and must be an empirical process within the adaptive plan, which is flexible enough to accommodate new learnings occurred during the transformation journey. We keep improving every moment and the agility evolves as we progress through this journey, the coaching mindset, the next key element, coaching is defined as partnering with clients and a thought-provoking and creative process that inspires them to maximize their personal and professional potential. Coaches facilitate the thought process. They are not coming with a magic stick with off the shelf solutions for all the problems at the coachee face. The coach enables a teams to understand and maximize their potential and channel it towards great results. Many attributes of Agile law applicable in coaching as well. This makes Coaching approaches adaptive, flexible, empirical, and brings in continuous improvements. Summarizing our discussion so far, we believe in agile transformation with an Agile coaching mindset. We believe if the transformation is enforced on a team is, we'll come back to its original state once the external force is withdrawn. Many times, Agile is rolled out without a consensus in the team. Teams should be convinced that there is a genuine need for transformation. One step back. That should be a genuine need fast. They must be aware of the agile ways. A clear understanding of what Agile is. Agile is not, are essential and should be a clear understanding of the current state and the transformation goals. In simple words, we should be aware of where we are and where we should go. If not, even the best map in the world cannot help us. Coaching is for the coachee, not for the coach. In the same way. It is the team, not for the transformer who transforms the agent. The coach, may learn and enhance his or her skills. But it is not the measurement of success. Avoid Agile transformation. Yes, you heard it right? Avoid unnecessary, misfit logical transformation initiatives. There must be a valid reason, a strong driver for this effort. Yes, we improve, adapt, and re-plan throughout all transformation journey. But that should be a valid reason to start this journey. Let us try to list down various phases. A typical transformation journey goes through these steps and negotiable. Based on the organization, team, and the environment. These steps may change, replaced or removed. The team may go through phases like understand the organization, culture and practices, understand the drivers and set goals. Define roadmap, make Agile visible. Establish agile training. Align organization structure and high-level processes. Start with agile practices. Team level transformation, inspect and adapt. There was not any specific order for executing many of these steps in our journey. These may even go in parallel or in a different order based on the situation. In a traditional process change. The consultant, the agent carries the team through this process. He or she analyzes this situation, comes up with a plan and commands the team towards the end goal. But not an agile approach for transformation. Hey, the coach enables the team to take a journey on their own. The rest of this training, we will discuss each phase in detail. I've stated and non-belief slide. Agile need not be the right answer in every situation. These steps can be executed in a traditional way, may reach the desired state. But we believe when we are transforming to Agile, the transformation itself should be agile for better sustainable results. With this note, we can conclude our discussion on Agile transformation. For the next module, we will start our discussion on various phases of any transformation journey. 2. Step 1 Understand the Organisation, Culture and Practices: Understand the organization, culture and practices. We are starting with a new assignment. Where do we start? As a rule of thumb, make sure the coaching is for the coachee, not for the coach. You need data to start with. But more important is to design this activity as a mirror shown to the team for their self-realization. Understand general facts about the organization. If you have not done already. Size of the organization, the nature of products, services domain, Global Atlas, local presence and leadership, targeted market, organizational structure, etc. Understand the organization structure. Key people that interests and influence. Again, be agile here. Tried to get an initial scope of your silent first. And an idea or stakeholders go a couple of levels up, down, left and right. For rest of the organization have a high level overall picture. There can be many tools that help you in capturing this data. Go for a simple one that is easy to maintain. Capture only minimal set of data that makes sense. As simple template for maintaining this stakeholder list is attached as a resource for this lecture. What else must we understand depends on the initial information on scope that we have captured in the first step. It varies a lot based on a task in hand. The rest of this chapter give some indicators that help you in selecting the relevant data points. Understand the scope of work, including the size of unit in scope, main products, value streams, key people in scope. Understand the processes, ways of working. How are we managing the delivery? What is the current workflow? How the teams are organized? What our existing roles and responsibilities more important? Take this question to the team. What information that they think can help us in this transformation journey. A template for collecting this team level and delivery level data is attached as a resource for this lecture. The main outcome of this step is not a set of documents. It is an initial alignment, understanding and agreement to proceed with further steps. So the methods used are equally important. Give more preference to face-to-face interactions. And sending a questionnaire over email. Bow for a workshop with their leadership within the scope. Give them moccasin stickies. Let them create the organization on a whiteboard. Who knows? Maybe there will be some surprises. New knowledge, at least for a few. In the same way, let the delivery teams draw their workflow and stick their images. I kind of RoleMapping on the whiteboard. So in this step, we have got some initial information on the organization and the organization has visualized its current state. We will inspect and improve them both these aspects as we go along. This is based on what is known so far. 3. Step 2 Understand the drivers and set goals: Understand the drivers and set goals. Why do you want to transform to agile ways of working? This question must be asked at the early stages even before you are hired as a coach for this transformation. If you are here for a study and the decisions are still open, that you can start from the basics. But most of the cases, a decision is already made and minds have happened or not. We don't have any control over the post later than never. This must be a-ks. Now, maybe we are reinventing our own existence. It may be as a result of a fact-driven decision taken by the organization or the unit that you assign to. They might have analyzed the challenges that they are facing and the desired state they want to be. They might have analyzed various options and came to a conclusion. Or on the other end, a decision and Organization Initiative has come from the top. Like by the end of this fiscal year, 50% of our projects will be transferred. Congratulations, you are one of them. These are two extremes and the reality lie somewhere in between, told to the decision-makers and understand what drives them towards adopting Agile. There are a variety of reasons that drives organizations towards agile. A recent survey lists down many drivers as listed here. You can visit the website given below for more details. A few of the drive is our ability to change, changing requirements. More visibility, more productivity, better Tang into market. It's a business alignment, etcetera. There is nothing wrong in reinventing the wheel here. If the wheel exists, this will help us in confirming it is in proper shape. Make them understand the challenges they are facing. And the expected states conduct brainstorming sessions with leadership and with these teams. Let them come with these points individually. Then these can be grouped and discussed. Let's not try to draw a one-to-one connection with issues and expected states. Every issue need not have a solution and every expectation need not come from a related issue. Unexpected state can be an optimization, need not be solution for a problem. Well, these challenges and expectations, participants will find areas where they expect to change. The areas of focus. For example, the units may be concerned about the delayed delivery. They are unable to meet the deadlines, or they wish to deliver more frequently. Similar issues will result in many data points. A few CAN BE on-time delivery, delivery frequency, shipped, defects, etcetera. We have a list of focus areas. Now it's time for prioritization. The team will prioritize and decide the areas that we concentrate on. The rest, we will keep a watch list, facilitate an assessment of current state for these areas, and identify and our d old state. Now we have enough information to set our goals, help the team define the goals as improvements based on outcome. For example, take the case of delivery frequency. At the present, that team may be delivering once in three months. And the ideal states can be automated multiple deployments in a day. The ideal state need not be this dramatic. Go for something that makes sense for the team. Defined various states in between and base the goal on improvements through the states. A template with example for these goal-setting exercises is attached as a resource for this lecture. Let the goals be smart, that is specific, Measurable, Achievable, Realistic, time-related. 4. Step 3 Define Road map: Define roadmap. How do you bring in changes? We are changing a working system. It may be at various levels of success, but there is a system in place. It is more complicated as it is an ecosystem of human beings, not machines. We can't easily replace, reorder few components and make a new system, we should plan it properly. Bringing the changes with a clear understanding of its impact, maintain transparency on the changes. Unexpected impact. Team should consider all the factors that will be impacted by the change and come up with a transformation approach. Team may have many options to go left to right, top-down or bottom-up, or a combination of all these. In a top down approach, we started the enterprise or portfolio level and go towards the team level. This will ensure better buy-in foam. The leadership and management support process on alignment will be easier. We have the authority, but this may tend to be a transformation by fools. I may go to Agile as directed by my boss. There will be less agility and transformation and will be a command and control approach. In a bottom up approach, we will start with the development teams and it bubbles up in the organization. Team owns the decisions. And this will be more participatory approach. There will be more innovation and more adaptive towards team specific characteristics. But teams may find it tough negotiating organizational processes. This will be less leadership support. It is recommended to take a path in the middle. Instead of three dimensions. The leadership processes and teams. Onboard the leadership within the scope. Without Zhao, understand their views and set the expectation, make it very clear as to what they can expect and what is expected from them in trust on them, the responsibility to get buy-in from the higher levels, if exists. With this mandate on board, the process owners in the organization do the required analysis and help them in adopting the process framework. The processes should be flexible enough to support the agile ways of working. With these emplace, identify pilot teams and onboard them in Agile. Make a plan to add more teams programs to this. As teams start working on agile ways, many challenges will come up. Many gaps get exposed, and we have to visit the previous two steps again. Pilot team or teams should be hand-picked with care. They are torch bearers. The impact they create should reach the breadth and depth of the organization. The considerations will include size, product leadership, value, visibility, team. The pilot project should be overwrite size, not too small or too big. A project of two to six months duration will be ideal. It should have the right product ownership. Agile methodologies advocate close collaboration between business and developers. Make sure that those who represent business to the team, available, knowledgeable, and empowered to take decisions. The pilot project should overwrite value so that it has good visibility within the organization. I repeat, they are pioneers and their success would attract more teams. Agile. We should select the right teams of the right size, preferably seven plus or minus two. With the right skill sets, a group of committed, motivated professionals. A very simple template for selecting pilots is attached as a resource for this lecture. Selection of agile approaches can be a part of this step. It will be a good idea to defer this decision to lower levels, but it's in many scaled environments, this decision will be taken at a higher level. In such cases, trying to provide some flexibility at the team level as well, where the team can have more than one option to select from within os scaling framework. Now we can come up with a rollout plan. This will serve as a guideline for different phases in our transformation journey and activities involved. This shows where we stand as on today. We might have already done a few of these steps. Two very important points here. One, keep it as simple as possible so that we can easily maintain it. Point number two, this is not a frozen plan. We will inspect and adapt this plan at regular intervals. A sample rollout plan is shown here. This represents three-dimensions, the core activities, training dimensions, and the team level adoption. We need a home to support this rollout plan. We need a coaching framework as well. Based on the size of the organization or the unit under consideration, we must define the coaching requirements. What did the team coaching and requirements? When and where should we onboard them? How do we establish the synchronization among the coaches? What phi the requirements and establish an improved, realistic on boarding plan. These are not frozen blends. Plans will change as we start moving along the transformation path. All the plans must be inspected and I adapted as more knowledge is available. 5. Step 4 Make Agile visible: Make Agile visible with the organization's C here and talk about agile. Let the word agile be there in the air so that it can get into people's heads at the right moment. We have done our groundwork and now it's time to get started. We need proper opening to conquer the organization. The best strategy is creating an army within the organisation. They will clear the way for agile creator call group. A step towards establishing agile Center of Excellence. Finds a group of influential people, preferably those with prior experience in Agile. Mentor them, release them to the crowd. These will be the torch bearers. They will spread the gospel in the organization. There are many activities this group can get involved. I've drawn awareness sessions and full moon sessions to get the first field of Agile. These are very short, maximum of 13 minutes sessions. Participants will be engaged in activities, games that explains the Agile philosophy and values. This should not turn into a formal training session. Let this beam. Formal, fun-filled sessions. Agile four rooms discussing groups can be established and can conduct ongoing discussions on Agile topics. These can be online discussions in the company. Intranet and scheduled events bring in some regularity to these events. Like the interest in members must know there will be an event happening every Wednesday at 04:00 PM. Also encouraged people to participate in external agile groups, chapters, gatherings, et cetera. Participation in organizational events with the intention of spreading the word of Agile. This can be opening an agile booth and a department event. Making an agile corner in your cafeteria, organizing Agile expert talks and experience sharing sessions, etc. Information radiators embarrass physical forms. And we put in key places within the organization. This can contain agile values, captions related to Agile, quotes, cartoons, and so on. This can be used for effectively communicating the above activities. Email communications can be another effective way to attract crowd to the events. Ouzo plan for other email communications like agile bytes, thought for the day, details on the different activities going on the Agile front. This step is not as easy as it looks. This is an important step in adopting and sustaining agile. So we make it a separate step in our journey. It is not an easy task to get people out to their daily routine and bring them to these events. Once we are successful in creating the interest and enthusiasm for agile, that will bring seamless support for our endeavors. 6. Step 5 Agile training: Establish a Zhao training. Training is one of the main activities and a transformation journey. Please note, it is one of the, not the only activity. Many times, coaching is misinterpreted as training and training used to hijack the coaching training approach is very important. There are initial set of training and ongoing training activities are appropriate assessment and planning must go into this. We must collect data on the trainings that the people has already taken up when they have completed the training. It is also very important. For example, if someone has attended an agile awareness training a few years back and never in touch with any of the Agile initiative, then it is of little relevance. This will help the team in deciding the training requirements, the agile methodologies selected or shortlisted, and the engineering practices that we intend to follow. We'll have a say in our training plan. A very simple training assessment sheet is attached as a resource for this lecture. There will be trainings or different duration and at various levels. A few examples can be agile induction sessions. This will be at a basic level, usually conducted at the initial days. They sue introduces the Agile concepts and gives the overview of values. In principle, this can start with some team activity before going into the details. Usually of hot day duration, detail team training. These are detailed training as an Agile and specific agile methodologies. For example, agile and scrum trainings. This can be a Dale to, based on the Agile approaches selected. A number of activities in simulation exercises are integrated into this. Leadership trainings. Support from leadership is very important for the success of Agile. The top management must be aware of what they can expect in the future and what is expected from them. This brings in transparency and ensures buy-in from management. Row-based trainings. These are focussed trainings for people performing specific roles in the organization. For example, in Scrum, there are defined roles, product owner and Scrum Master. We can empower these roles with rho specific trainings, simulation exercises. This focus is on different meetings and activities within Agile methodologies. For example, we can have a session on Sprint Retrospectives alone with assimilation of the same refresher sessions. Training is an ongoing activity. It should support continuous learning. Keep the momentum we refresh our sessions and full moon events, discussions, et cetera. Training is an ongoing activity. References can be found in other steps as well. It is an enabler for each step in the transformation journey. 7. Step 6 Align Organization structure and high level processes: Align organization and high level processes, alarming existing processes and policies with agile ways of working will be one of the toughest jobs in the transformation journey. And any traditional organization, there will be a strong process framework which served as a backbone. And the company's operations. Employees will be highly aligned to it. Again, walking system. We should understand the existing processes, policies and procedures, and bringing changes incrementally. Don't be in a mindset that the entire world is an anti-pattern. That will be items that are in line with the agile ways and items that support agile with minimal tailoring. Stopped with the current processes. Understand the current processes. This includes setting the stage for future changes. We should set the house in order first, creates a big picture of the process framework. We show the merit to the organization, helped them in understanding what they are doing currently. Clean up the processes, go link with the existing processes. Find out any waste existing the process Web. Find the minimum required sets of processes that caters to all needs. So we have a set of well-defined processes to walk on. We are not changing anything so far. We have just gather the required data, identify the processes or process steps that block the team from moving towards agile ways for working. For example, in Scrum, we do design code, test all in a single sprint. Sprints or iterations for one month or less duration. Many occasions a week or two. So and a couple of weeks we are doing all these activities. It has short, optimal delivery cycles that operates with cadence. What's if the organization has a rigid quality gates like requirement freeze, design, freeze, code, freeze, which need sign-off and approvals. Definitely, these will slow down the pace and impact the cadence. So for the Scrum to what we need to remove or dilute a few of these gates. Organization structure has to be redrawn. Many roles in the organization will ceased or migrate to new roles. Many managers will transform themselves or give way for servant leaders. These changes and must be supported with a strong training and mentoring support. These changes were required artifacts and in templates come up with clear definitions for new roles. A few examples can be row definitions, Scrum Master toolkit, definition of ready, definition of done templates for user stories, product, backlog, sprint, backlog, et cetera. A few samples are attached as a resource for this lecture. 8. Step 7 Start with Agile Practices: Stopped with agile practices. The best way to introduce Agile to team level is via agile practices. These can be introducing with minimal disruption. Find out the areas in existing processes where these practices can help. These need not be engineering practices defined in extreme programming. These can be anything that helps the team defining the requirements from an end user perspective, using user stories. In that doing a retrospective of the delivery cycle, coming up with ground rules and definitions of W1. Along with extreme programming engineering practices as applicable. User Story, team can start capturing requirements in the form of user stories. A user story describes functionality that will be valuable to either a user, will purchase of a system or software. These are written in their perspective of the customer. It reflects what the customer expects or wants to do with the product. This can bring in a change in the way that team members approach a problem. They will start thinking from a user perspective. This will change in mindset when they start working as an agile team. Refactoring. This can be implemented independent of current processes. This will introduce the concepts of continuous improvement. Code refactoring is the process of improving code, making it easier to understand and extend. It improves readability, maintainability, extensibility, and reduces complexity. This is dumb when there was a scope and need. This can happen in many occasions, including not limited to while fixing bugs. Pots of code review. When we found a duplicate. When we found the code is complex or unreadable, et cetera. Test-driven development. Test-driven development is an approach where Developer first rights test case, which describes new function or improvement, and then create smooth codes to pass that test and later refactored a new code to meet the acceptable standards. The steps are involved at the test of a new functionality running fail at a minimum cone for passing the test running PaaS, we factor to improve code and repeat the steps. Definition of done. Definition of done for a user story is it sets a pre-established conditions for confirming the same as done. It is not the same as acceptance criteria, but meeting the acceptance criteria will be an automatic selection to the list. It considers many aspects like organizational processes, standards, legal requirements, etc. Teams might not have started working with user stories or sprints, but defined definition of dumb for their work items and milestones. This we'll introduce the concept of done shippable product. It will be inspected in regular intervals and improved. It's not a frozen document. It can be defined for a phase and release as well. Checklists confirming if the phase or releases done in all of the aspects. Other practices that helping includes pair, programming, continuous integration, simple design, coding standards, et cetera. Introduction of these practices may show some immediate results. The most important result, it create an interest and more acceptance for the agile adoption. 9. Step 8 Team level transformation: Team level transformation. Transformation at team level, team adoption is a crucial step. Agile methods are built on team of motivated people who delivers an iterative, incremental way. They're the basic building blocks in an Agile ecosystem. Onboard the team level coaches as a required and as planned in the previous steps, established a coaching organization. Activate the sink points to make sure that all share the same vision and have clarity on the transformation goes. One, adopting Agile, teams will pass through all of the above steps. In other words, all the steps are repeated for each of them, but with a different scope, size, and focus. Understand the team culture and practices. A focus on the current ways of delivering products by the team. Understand the nature of work. What is the delivery workflow that they follow? Gets a clear picture of team level processes and how they implement the organizational level policies and processes. Understand the drive is insect goes. Understand the current issues and expected states. What does the team want to achieve? Helped the team in translating these points to smart goals at the team level, define roadmap, make a plan for agile adoption, make it transparent and visible. Most important step here, decide on the agile methodology or methodologies to follow. Select the practices that will help the team to create an initial plan and keep it updated. Select the right tools that can help the team make a Zhao visible. Stopped talking. Agile in a team, participate in organization or unit level initiatives in this direction. If they don't exist, volunteer to stop those activities. Establish our job training, analyzed the existing expertise and identify the training needs, give input to the organizations or units. Training initiatives, execute the plan. Aligned team structure and high-level processes. Understand the new processes in the organization. Plan for introducing them to the team. Decide on the team specific tailoring of these processes. Introduce Team specific processes as required. Decide on the roles and responsibilities based on the selected methodologies and processes, create team level artifacts. Definitions of done. Definitions are ready. Extent SRA, sought the Johnny, introduce engineering practices, stopped with the selected engineering practices. Retrospect their effectiveness. Revisit that selected list of practices to add, delete, change, execute the plan, iterate at team level, jumped into the water, starts swimming, start walking as Agile teams stopped early so that the issues and challenges are visible. And then later, this gives us an opportunity to address them at the earliest. Inspect and adapt. Our Zhao plans are not frozen. Clean Trucks. Inspect the effectiveness and make corrections periodically. 10. Step 9 Inspect and Adapt: Inspect and adapt. Agile principle says at regular intervals the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. There is talk about the inspect and adapt aspects. Team evaluate their performance, retrospect and comes out with ideas to improve. What should we inspect? What are the metrics to look for? What are the basic features of Agile metrics. We should go for only the minimum number of metrics that will provide all information necessary to meet our goals. We should not measure just for the sake of doing it. There shouldn't be a value and benefit from it. Metric should measure outcomes, no outputs. They must measure results, no activity. There are two dimensions. How we progressing with a transformation in how Agile Ali, sound the same? I will say we are looking from different angles. The first one can be measured in terms of the number of teams on boarded in Agile, essentials of trained employees, completion of organization and processes, alignment, etcetera. These metrics are important. They help us in adjusting our transformation plans. A gel focuses on the value created. So I will be more interested in the second question. Team has decided on the focus areas and identify the different states at the earliest steps of this journey. Now it is time to evaluate where we are. We have decided on the focus areas at organizational unit level and we visited them at team level. Revisit this list focused areas and states, and come up with an assessment framework. Concentrates on the trends, not the snapshots. A sample assessment sheet is attached as a resource for this lecture. This can be conducted at Team, unit or organizational levels to access how Agile we are. This discussion is not complete without refreshing basic values of Agile and endorsing our commitment towards them. 11. Bonus Lecture Agile Manifesto: In 2001, a group of 17 lightweight methodologist met in the Salt Lake Valley. The meeting included representatives of different methodologies existing at that time, like extreme programming, Scrum, D, SDM, adaptive software development, et cetera. They have come up with something called Agile Manifesto. H was written in the format a over b. It says, we are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan. Now the last sentence is very important. This is a point that will clear many of our questions shins. That is, while there is value in items on the right, we value the items on the left. More. Agile is not against process, documents, contracts, or plan. But there are other items that we value more. Let's discuss these items in detail. Individuals and interactions over processes and tools. Processes are good, but we should not underestimate the power of interactions and face-to-face conversations. We are not doing any factory work where a machine can produce n items in a given time. We are in a knowledge industry. Hey, the focus should be on empowered, self-managing, cross-functional teams. This doesn't mean that Agile is against a process and tools. They are required, but they should support these interactions. They are not for replacing the interactions. Working software over comprehensive documentation. Traditionally we rely on and lots of documentation. We have a requirement phase where we created and sign off the requirements. Then a high-level, low-level design which create a detailed design document. All these are part of Wall project execution and have weightages associated. So we say that percentage of work is done, but we have not actually delivered anything that can be used by end-user. Our aim is to deliver value to the customer, not a big load of documents. Working software should be our primary output and the measurement of our progress. It doesn't mean that we shouldn't not document. We should have the minimum required documents. Another issue is maintaining this huge sets of documents. We have a detailed design specs and many times towards the end of the project, we find it to be obsolete because we don't maintain it. So go for minimum documentation, which is properly maintained..net code talk for itself as much as possible. Customer collaboration over contract negotiation. What do we do? Traditionally? Customer gives as the requirements and we give them the product. In other words, customer throws the requirements over the wall and we throw the product back. In Agile, customers become part of a development process. Customer and vendor together tried to serve the end user. Agile never say that we should not have a contract. It is very important in facilitating everything. It gives us the authority to work and it guides us. But it should be flexible enough to, to support collaboration among all parties. Responding to change over following a plan. What we do traditionally, we have a big project. We plan it through completion. We have sequence of top. We have the critical path, leads and lags, early start date, late finish dates, and so on. We start analyzing variants. And we consider changes as an exception, but not in Agile. In Agile changes are expected. We don't create such long detailed plans. We have a roadmap, an overall plan for your own time, and detailed plan for short future. We don't create a plan on suddenly that we are not sure about. It is like we walked from a small distance, stop, look around and cover another distance. We plan. And the last responsible moment, we do plan but follow kind of a rolling wave planning. So we have covered the core of the Agile Manifesto. Let's have a relook individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan. 12. Outro Our Courses in SkillShare: We would like to provide an overview of our course is on the the the the the the, the opinions.