Agile Principles and Mindset - Part 2 Tutorial

Hello and welcome to Domain I—Agile Principles and Mindset of the PMI-ACP Certification course offered by Simplilearn. This is the second part of this domain.

After completing this lesson, you will be able to: • Explain Agile methodologies, frameworks, and processes • Discuss Agile Project Management and its framework • Explain information radiators • Describe knowledge sharing in Agile • Define the characteristics of Agile servant leadership

A number of core Agile methodologies share the same philosophy expressed in the Agile Manifesto. However, they have different practices, processes, and techniques. While adopting Agile, it is not mandatory to follow a particular methodology. The best practices from different methodologies can be chosen and implemented in the project. Some of the key Agile methodologies are Scrum, Extreme Programming or XP, Crystal, Dynamic System Development Methodology or DSDM Atern,Feature Driven Development or FDD, Agile Project Management or APM, Lean Kanban, and OpenUp. These methodologies are discussed in detail in this lesson.

Scrum is one of the leading Agile techniques developed in the 1990s by Ken Schwaber and Jeff Sutherland. ) It is a term used in Rugby game and refers to an interlocked team working together to push a rugby ball into the hands of their team members, so they can move it down the field and score. Scrum is the most popular Agile methodology and more than 50% of the projects make use of this methodology. Some of the salient features that make Scrum popular are as follows: • Scrum offers simplicity and proven results • It encompasses other Agile engineering techniques • It emphasizes small teams and team empowerment • It welcomes changes to requirements • It allows working from a single source of prioritized work items • Scrum includes daily status meetings • It offers team commitment to a potentially shippable increment during a ‘Sprint’

There are three pillars of Scrum, such as Transparency, Inspection, and Adaptation. Click each pillar to know more. Transparency: • All aspects of the process or project must be visible to those responsible for the outcome. • Use Information radiators, through which key information like product backlog, sprint backlog, impediments, risks, and project progress are made transparent to all the stakeholders. Inspection: • The team regularly inspects their performance and progress towards the project goal. • They constantly look for problematic areas and deviations from the plan. Adaptation: • Based on the observations made during inspection, necessary changes are made to the process to avoid problem recurrence and improve the project delivery position.

The Scrum roles are important features of Scrum. There are three key roles defined in the Scrum guide. They are the Product Owner, ScrumMaster, and the Development Team; together they are known as the ‘Scrum Team’. The Scrum team comprises five to nine team members, which is seven plus or minus two. The roles of product owner and ScrumMaster are not included in this count unless they are directly contributing to the work of the sprint backlog. Product owner is a product visionary and is responsible for the success of a project by defining the project vision, requirements, and priorities. ScrumMaster is responsible for the team and removes impediments that will prevent them from achieving the goals set by the product owner. Development team is self-organized and cross functional. It works collaboratively to determine how the requirements decided by the product owner will be fulfilled. This team comprises people with a mix of roles to determine how best to meet the goals of the product owner.

Some key terms used in Scrum are Product Backlog, Sprint, Sprint Backlog, and Scrum. Click each tab to know more. Product Backlog: It lists all the work to be performed by the team, to achieve the product owner’s vision of success, in the foreseeable future. It contains both well-defined requirements and those requiring further definition. Sprint: A period of 30 days or less, within which a set of work will be performed to create a deliverable. Sprint Backlog: Requirement that is well defined and can be worked on with little change, over 30 days or less, resulting in a tangible, potentially shippable incremental deliverable. Scrum: A daily meeting attended by the Scrum team to review the progress and impediments.

There are four meetings defined by Scrum that happen over the course of a sprint. 1. Sprint Planning: This meeting is attended by all the members of the Scrum team. In this meeting, the development team identifies the stories from the product backlog for development and delivery in the current sprint. This meeting is timeboxed to eight hours for a monthly sprint, and proportionately less for sprints of shorter duration. Four hours for selecting stories and four hours for estimation is allotted. 2. Daily Stand-up Meeting: This is attended by the ScrumMaster and the development team, presence of product owner is optional. Each team member answers the following questions: “What was done yesterday?”, “What will be done today?”, and “What are the blockers?” This meeting is timeboxed to 15 minutes and happens daily at the same time and place. 3. Sprint Review: This meeting is attended by all the members of the Scrum team. The development team will demonstrate the developed features in the form of potentially shippable deliverables to the stakeholders and project sponsors. Feedbacks are noted down by the product owner, which will be converted into new user stories to be developed in the future sprints. This meeting is timeboxed to four hours for a monthly sprint, and proportionately less for sprints of shorter duration. 4. Sprint Retrospection: This meeting is attended by all the members of the Scrum team. The focus of this meeting is to retrospect how the sprint went by. Details pertaining to what went well, what did not, what needs to change, and what they would like to improve in the next sprint are captured. The team agrees on the improvement plans for the future sprints. This meeting is timeboxed to three hours for a monthly sprint, and proportionately less for sprints of shorter duration. As showcased in the image, all the meetings are repeated within each sprint.

Given on the screen is a graphical representation of an ideal Agile project that uses Scrum. The flowchart showcases the flow of events of a typical Scrum project. Product owner prepares the product backlog that has all the user stories documented along with their prioritization. The high priority features occupy the top of the product backlog. The team, based on their historical visibility and velocity, decides which of the user stories and how much of them can be delivered in the release based on the product roadmap. These user stories are moved into release backlog. During the sprint planning meeting, the team selects the user stories from the top of the release backlog, which can be completed within a two week period. Such user stories then become part of the sprint backlog. Once the sprint backlog is decided, the team breaks them into tasks—for the ease of tracking and reporting. Through incremental iterations, the development team starts developing the features. Daily stand-up meetings are held to discuss the progress and raise issues. Burnup and burndown charts are used to showcase the progress. At the end of the sprint, the working software with the new functionality is demonstrated to the stakeholders to get their feedback. Finally, the team conducts a retrospective on the sprint performance and agree upon the action requests. Further, the team captures its velocity, which will be used for planning future sprints. This cycle continues.

While taking up different Scrum roles, a few key points must be kept in mind. As a product owner, resist the temptation to "manage" the team or add more important work after the sprint is in progress. Product owner should be willing to make hard choices during the Sprint planning meeting. A ScrumMaster assists both the team and the product owner-- empowers the development team by facilitating creativity and guides the product owner on how to maximize Return on Investment or ROI. The team has the autonomy to choose how best to meet the goals, and is responsible for the same.

Extreme Programming or XP was developed by Kent Beck and Ward Cunningham in the 1990s to respond to the high cost of changing requirements and establish strong engineering practices to improve software quality. XP is a software development-centric Agile method and focusses on implementing the best software practices. XP emphasizes the same practices represented in the Agile Manifesto and reflected in Scrum. XP introduced many revolutionary concepts to software development that are now standard practices, such as Test Driven Development; Continuous Integration; Iterations; and User Stories. The aim of these practices is to ensure that customers receive what they need. XP allows developers to respond to changing customer requirements at any point in the project lifecycle.

Extreme programing builds around five core principles. Communication: This principle focuses on ensuring that everyone in the team knows what needs to be done and what the other person is doing. There will be frequent collaboration between users and programmers. The team members communicate using simple designs, common metaphors, and application of patterns. Simplicity: The focus of this principle is to find the simplest solution instead of complicating the solution with unwanted features and functionalities. The team will take small simple steps towards the goal and mitigate complexities and failures, by refactoring. Feedback: This principle focuses on ensuring that the solution is demonstrated to the stakeholders early and regularly. Unit tests are conducted for feedback from the system; Acceptance Tests are conducted for feedback from the customer; and Planning Games are conducted for feedback from the team. Courage: This principle focuses on the courage required to showcase the work being done. The team should allocate sufficient time within the sprint to refactor the code. Refactoring makes future changes easier and removes obsolete code. The team should showcase the partially done work during Pair Programming. Respect: This principle focuses on giving and taking. This includes respect for others; self-respect; adopting the other four values; and respect gained from others in the team.

The XP Practices introduced a wide range of techniques that are accepted as standard practices. Some of the techniques are: • Fine-scale feedback, which includes Pair programming; Planning game; Test-driven development; and Whole team; • Continuous process, which includes Continuous integration; Refactoring or design improvement; and Small releases; • Shared understanding, which includes Coding standards; Collective code ownership; Simple design; and System metaphor; and • Programmer welfare, which includes Sustainable pace.

In the given XP process diagram, you can see the normal flow of an XP project. Architectural spike and user stories are taken as input for the release planning. The outcome of this meeting would result in the release plan, which would drive the iterations planned within the release. The outcome of each iteration would be compared against the acceptance criteria and upon customer approval, the code would be shipped to the live environment through small release. This cycle of release planning, iteration planning, development, testing, and customer acceptance repeats for the entire duration of the project. It is recommended to spend some time and go through the diagram for a better understanding of the concept.

The given image shows the problems faced during the development of a project named Phoenix, which is an Image-Processing Environment. To develop an Image Processing Environment, the Phoenix programming team had to outline the functionality of the system. The project was required to have 20 C Language modules, 5 Assembly Language (x86) modules, and 9 Executable Helper Applications. To see the result of this project, click the ‘outcome’ button given on the screen. The Phoenix Development Team consisted of two developers, who used most of the XP features. Before they began coding, they outlined the functionality of the system with their customers and established a common understanding. They coded most parts of the Image Processing Environment together for 10 to 14 hours per day, for a period of four months. This gave them complete command over the development process. They decided what had to be developed and why. Further, this approach was ideal for the Phoenix project that consisted of more than 40,000 lines of code. Despite the development process requiring 10 to 14 hours per day, for a period of four months, the project was completed on time because of the team work. Furthermore, the functioning software was almost 100% bug-free.

In Crystal Methodology, projects are categorized according to the size of the project, the number of people involved, and criticality. Crystal Methodologies, developed by Alistair Cockburn, are designed for projects ranging from small teams developing low critical solutions to large teams developing mission critical solutions. The different levels of criticality are Comfort, Discretionary Money, Essential Money, and Life.

Depending on the project span, Agile processes must be extended beyond face-to-face communications. Additional verifications, validations, and traceability measures can be introduced as needed, thereby improving project flexibility. Some of the key principles of Crystal Methodology include: • Frequent delivery • Reflective improvement • Osmotic communication • Personal safety • Focus • Ease of access to experts • Technical environment with automated tests, configuration management, and frequent integration

Crystal methodology can be categorized in different ways. The important categories are Crystal Clear and Crystal Red. Crystal Clear is for small teams working on projects with low risk to life and using discretionary monies. In the image, the projects that fall on the far left, with team size of one to six, belong to this category. These projects develop less critical solutions, and failure of which would result in low financial loss. Crystal Red is for a larger project that deals with life and death implications, which would have more governance, documentation, and control gates. In the image, the projects on the far right belong to this category. Failure to achieve the required results would result in significant loss to the organization. Hence as the team size increases, it is important to increase communications within the team using tools to help improve project delivery. Also, the crystal methodology moves on to Crystal Yellow and Crystal Orange as the size of the team and complexity increases.

Dynamic Systems Development Method or DSDM was developed in the 1990s to provide more discipline to Rapid Application Development or RAD. The latest version is called Atern. It is one of the earliest Agile methods and covers the entire project life cycle. This method is quite detailed and ensures the project does enough design upfront before any of the development activity begins. The features of this method are as follows: DSDM uses a prioritization technique called MoSCoW, which stands for Must, Should, Could, and Won’t to determine the requirements to be included in a release or iteration. The Atern methodology fixes the schedule, cost, and quality, while achieving contingency by varying the features. This ensures the delivery of Minimum Usable Subset (MUS) of features. This is also illustrated in the given image.

As listed on the screen, DSDM revolves around eight principles. They are: Focus on the business need: Understand the business priorities and clearly define the scope of the system. Establish a sound business case, seek continuous business sponsorship and commitment, and guarantee the Minimum Usable Subset of features. Deliver on time: Timebox the work, focus on business priorities, and always meet deadlines. Collaborate: Build a one-team culture. Involve the right stakeholders, at the right time, throughout the project and ensure that the team members are empowered to take decisions. Never compromise quality: Build in quality by constant review, and test early and continuously. It is important to see test-driven development for comparison. Build incrementally from firm foundations: Formally re-assess priorities and ongoing project viability with each delivered increment. Strive for early delivery of business benefit and constantly verify the solution being built. Develop Iteratively: Take an iterative approach to build all products, build customer feedback into each iteration, and embrace change. Communicate continuously and clearly: Run daily team stand-up sessions, use facilitated workshops, and communication techniques such as modelling and prototyping. Manage stakeholder expectations throughout the project, and encourage informal, face-to-face communication at all levels. Demonstrate control: Use an appropriate level of formality for tracking and reporting. Make plans and progress visible to all. Measure progress through focus on delivery of products, manage proactively, and evaluate project viability based on the business objectives.

The given image represents the phases of DSDM. Click each phase to learn more. In the Pre-Project phase, identify and select the right project for development that would deliver value. In the Feasibility phase, identify if a feasible solution exists for the project selected during the pre-project phase. In the Foundation phase, establish a strong foundation for the project from a business and technical front, and identify the necessary standards that the project needs to adhere to. In the Exploration phase, iteratively and incrementally develop the solution. The resultant solution is not expected to be production-ready as the non-functional requirements need to be developed during the Engineering phase. In the Engineering phase, iteratively and incrementally develop the non-functional requirements to make the product production-ready. The focus here is on factors such as maintainability, security, portability, response, and time. In the Deployment phase, deploy the solution to the live environment. In the Post-Project phase, assess the business benefits that are realized through delivery of the solution developed.

Feature Driven Development or FDD is an iterative and incremental approach to software development that was developed in the 1990s by Jeff DeLuca and Peter Coad. Features are small pieces of client-valued functions expressed in the form given on the screen. Through decomposition, domain models are broken down into subject areas, which are then expressed as business activities. The team using FDD method would first develop a prototype of the product, and then build a list of features to be developed. Next, they would plan on how the product would be developed using iterative and incremental approach. Each step in a business activity is a feature. FDD popularized the cumulative flow diagram and parking lot diagrams, which are useful for tracking and monitoring the delivery progress. Care needs to be taken to ensure that each feature does not take more than two weeks to complete; else they should be broken down into smaller pieces.

The book, Agile Project Management (APM) by Jim Highsmith, was one of the first attempts to broaden Agile techniques into a cohesive whole. APM introduced phases for Agile projects that aligned with the PMP phases applied by the Project Management Institute. As shown on the image, APM also modified the traditional “Iron Triangle” to emphasize Value and Quality, and created the “Agile Triangle.” The primary focus is to deliver value and quality within the constraints of cost, schedule, and scope. APM also states that while value is extrinsic and can be seen through the delivery of features, quality is intrinsic. Quality is defined as part of the requirement and later built into the solution by the team.

The Agile Project Management typically follows five phases. They are as follows: • Envision: Determine the product vision, project scope, project community, and how the team will work together. • Speculate: Develop a feature-based release, milestone, and iteration plan to deliver the vision. • Explore: Deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project. • Adapt: Review the delivered results, current situation, and the team's performance, and adapt as necessary. • Close: Conclude the project, pass along key learning, and celebrate.

Michele Sliger aligned the Agile Project Management Framework to the PMI Project Management Book of Knowledge or PMBOK. The given image shows the correlation between the two. Here, the Initiation phase is parallel to Envisioning, Planning phase is parallel to Speculating, Executing phase is parallel to Exploring, Controlling phase is parallel to Adapting, and Closing phase is parallel to Closing.

Michele Sliger aligned the Agile Project Management Framework to the PMI Project Management Book of Knowledge or PMBOK. The given image shows the correlation between the two. Here, the Initiation phase is parallel to Envisioning, Planning phase is parallel to Speculating, Executing phase is parallel to Exploring, Controlling phase is parallel to Adapting, and Closing phase is parallel to Closing.

Tom and Mary Poppendieck introduced Lean software development to the Agile community. Lean software development adopts the principles and practices from Toyota Production system or TPS. TPS was developed to address issues that affect manufacturing processes, like Muri (Overuse), Mura (irregularities), and Muda (waste). Muri is to cause overburden, such as unnecessary stress on the employees and processes. This is caused by Mura and a host of other failures in the system, such as lack of training, unclear ways of working, and wrong tools. Mura is the waste caused by unevenness or irregularity. Unrealistic demand results in unevenness in the processes, which leads to waste creation. Mura drives Muda. Muda is any activity or process that does not add value. This can refer to waste of time, resources, and money.

The seven lean principles are as listed on the screen: Eliminate waste: Anything that does not add value to the customer is considered waste (Muda). Unnecessary code and functionality, delay in the software development process, unclear requirements, insufficient testing, bureaucracy, and slow internal communication are a few examples of Muda. Amplify learning: Learning is amplified through short iteration cycles, refactoring and integration testing, and frequent customer feedback sessions. Each of these techniques shed more light on the problem domain and identify opportunities to improve. Decide as late as possible: The best way to manage uncertainty is by gaining information, minimizing assumptions, deferring commitment to the last responsible moment, and breaking dependencies between components. Deliver as fast as possible: Short iterations or small batches provide valuable feedback opportunities and allow effective decision making. Empower the team: Lean focuses on the team as the source of decision making and management turns to team to understand the best options and their costs. Build integrity in: Ensuring that quality is embedded throughout the system requires automation of testing through builds, installs, and continuous integration. Finally, think big, act small, fail-fast, and learn rapidly.

Kanban is a Japanese term for signal board. It was also developed in the Toyota Production System or TPS. Agile has adopted Kanban technique to reflect the throughput of a Sprint or iteration. It showcases the status of each user story within the sprint and helps gauge the cycle time and the throughput of the team. Kanban boards are also used in most Agile software products, which are useful for Agile distributed teams. Most Kanban boards are located in the team room and have user story cards or post-it notes distributed across different categories. Use of Story cards or post-it notes helps everyone in the team to understand the complete scope of work to be done. Kanban helps manage the throughput of a process by identifying bottlenecks, setting ‘Work In Progress’ limits, and displaying the status of the entire production system with one view. The sample Kanban board given on the screen showcases the various teams, which a user story has to pass through, to term a story as Release Ready. Also, notice that the WIP limits set at the top of the chart, which helps minimize the total amount of work done at any point in time.

Kanban is an evolutionary change for an organization. It helps increase the visibility of project progress throughout the company. It drastically reduces the time-to-market, development, and engineering time. The results of Kanban influence both the Web and the software development. It helps in organizing work. It also boosts communication among team members helping them solve problems quickly. The graphic shows the benefits of implementing Kanban in a company. Kanban reduced the lead time of a project from 22 days to 14 days, the development time from nine to three days, and the engineering took eight days instead of 11 days. It was found that these results could not be achieved using different methods.

Lean Kanban Method was established by David Anderson who saw the potential of both techniques in dramatically improving software development activities. Lean Kanban blends Kanban with Lean and other Agile principles to improve processes. The three principles of Lean Kanban and five core practices of Lean Kanban are listed on the screen. Click each tab to know more. The three principles of Lean Kanban are as follows: 1. Start with what you know: This method does not prescribe a specific set of standards or procedures; rather it insists on using Kanban along with the existing process or workflows. Following this principle helps reduce major changes and eases Kanban implementation. 2. Agree to pursue incremental, evolutionary change: Develop the solution incrementally and regularly get these changes compliant with the business. This leads to overall solution being developed slowly, thus avoiding sweeping changes being made with minimal resistance later on. 3. Respect current roles, responsibilities, and job titles: Kanban recognizes that there may be value in the existing process, roles, responsibilities, and titles. If changes have to be made, it needs to be introduced incrementally, as this will avoid the fear of progress getting impacted. Minimal changes are easier to implement than large system-wide changes. The five core practices of Lean Kanban are as follows: 1. Visualize: Visualizing the work flow through the system helps the entire team to know exactly ‘what happens next’. Such visual representations help to refine and optimize the current workflow and improve efficiency. 2. Limiting work in progress: Limiting the amount of work in progress helps to identify bottlenecks and run the entire process efficiently. It also helps to reduce the sunk cost and wastages that might result from changes later on. 3. Manage flow: Tracking the flow of work through the system helps the team identify issues that can be used to improve effectiveness. 4. Make management policies: Ensure all the team members clearly understand the policies and ground rules. This helps them make informed decisions and bring about improvements. 5. Improve collaboratively, using “safe to fail” experiments: It is better to fail-fast than fail later in the project, as this helps to prevent wastage of effort and cost. Through collaborative experiments, team should improve the processes it uses.

OpenUP is an open-source variant that IBM released to the public domain in 2006 and is a variant of the Rational Unified Process or RUP. OpenUP is a Lean unified process that applies iterative and incremental approaches within a structured lifecycle. It embraces Agile philosophy that focuses on the collaborative nature of software development. OpenUP is a tools-agnostic, low-ceremony process that can be extended to different project types. It targets small and co-located teams involved in Agile and iterative development. Small projects constitute teams of three to six people, involving three to six months of development effort.

Hello and welcome to Domain I—Agile Principles and Mindset of the PMI-ACP Certification course offered by Simplilearn. This is the second part of this domain.

As depicted in the given image, OpenUP has four phases across the project lifecycle. First is the Inception Iteration Phase. The initial idea or concepts are generated in this phase. The objectives of this phase are: • Understand what to build • Identify key system functionality • Determine at least one possible solution • Understand the cost, schedule, and risks associated with the project Next is the Elaboration Iteration Phase, where ideas are fine-tuned or elaborated. The objectives of this phase are: • Get a detailed understanding of the requirements • Design, implement, validate, and baseline an Architecture • Mitigate essential risks, and produce accurate schedule and cost estimates This is followed by the Construction Phase Iteration, where the solution is developed in line with the ideas generated in the earlier phases. The objectives are as follows: • Iteratively develop a complete product that is ready to transition to its user community • Minimize development costs and achieve some degree of parallelism Last is the Transition Phase Iteration, where the solution is moved into production. The objectives of this phase are: • Conduct beta test to validate that user expectations are met • Achieve stakeholder concurrence that deployment is complete

After completing this lesson, you will be able to: • Explain Agile methodologies, frameworks, and processes • Discuss Agile Project Management and its framework • Explain information radiators • Describe knowledge sharing in Agile • Define the characteristics of Agile servant leadership

Information radiators are important tools for communicating information on Agile projects. The concept of information radiators was invented by Alistair Cockburn. He defined it as: "An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don't need to ask any question; the information simply hits them as they pass.” Information radiators are most effective with co-located teams. Some of their features are as follows: They are intended to enable team members to view the current state of the project and its progress. Information radiators are also helpful to provide information to other non-project team members. Most Agile teams implement them to some degree in their processes. A few examples of information radiators are boards with swimlanes and status columns showing the progress of work items; Big Visible Charts including Burndown charts, showing team velocity across iterations; and Continuous integration build health indicators, which many teams choose to display using lava lamps and street lights. These information radiators improve project communication in a lightweight and easy to manage fashion.

A number of core Agile methodologies share the same philosophy expressed in the Agile Manifesto. However, they have different practices, processes, and techniques. While adopting Agile, it is not mandatory to follow a particular methodology. The best practices from different methodologies can be chosen and implemented in the project. Some of the key Agile methodologies are Scrum, Extreme Programming or XP, Crystal, Dynamic System Development Methodology or DSDM Atern,Feature Driven Development or FDD, Agile Project Management or APM, Lean Kanban, and OpenUp. These methodologies are discussed in detail in this lesson.

Effective information radiators should be: • Simple: Easy to understand • Stark: Errors should not be masked, rather they should be used to improve the work and performance • Current: Information displayed should be current • Transient: Once the problem has been rectified, it should be taken off from the chart • Influential: Empowers the team to take decisions • Highly visible: Easy to see and understand • Minimal in number: Key information must be emphasized Information radiators help in building transparency and a shared understanding of the success criteria, deliverables, and other key aspects of the project to align expectations, build trust among the stakeholders, and make informed decisions.

Scrum is one of the leading Agile techniques developed in the 1990s by Ken Schwaber and Jeff Sutherland. ) It is a term used in Rugby game and refers to an interlocked team working together to push a rugby ball into the hands of their team members, so they can move it down the field and score. Scrum is the most popular Agile methodology and more than 50% of the projects make use of this methodology. Some of the salient features that make Scrum popular are as follows: • Scrum offers simplicity and proven results • It encompasses other Agile engineering techniques • It emphasizes small teams and team empowerment • It welcomes changes to requirements • It allows working from a single source of prioritized work items • Scrum includes daily status meetings • It offers team commitment to a potentially shippable increment during a ‘Sprint’

Some examples of information radiators, such as Burndown Chart, Burnup Chart, Combined Burn Chart, and Risk Log are shown here. It is recommended to go through these images for better understanding. These examples are however discussed in the later part of this course.

There are three pillars of Scrum, such as Transparency, Inspection, and Adaptation. Click each pillar to know more. Transparency: • All aspects of the process or project must be visible to those responsible for the outcome. • Use Information radiators, through which key information like product backlog, sprint backlog, impediments, risks, and project progress are made transparent to all the stakeholders. Inspection: • The team regularly inspects their performance and progress towards the project goal. • They constantly look for problematic areas and deviations from the plan. Adaptation: • Based on the observations made during inspection, necessary changes are made to the process to avoid problem recurrence and improve the project delivery position.

Agile projects operate in a timeboxed manner. Hence, it is critical that the team is upskilled not only in the technical aspects, but also in the functional aspects. Some key points to remember are as follows: Knowledge sharing is an important mechanism to scale larger and mission-critical Agile projects successfully. When team members interact with their fellow mates during the course of the day, the knowledge sharing session needs to be scheduled with goals clearly defined. The team’s participation must be monitored to ensure knowledge transfer happens in a structured manner. The given image depicts the knowledge sharing happening on a one-to-one and one-to-many basis.

The Scrum roles are important features of Scrum. There are three key roles defined in the Scrum guide. They are the Product Owner, ScrumMaster, and the Development Team; together they are known as the ‘Scrum Team’. The Scrum team comprises five to nine team members, which is seven plus or minus two. The roles of product owner and ScrumMaster are not included in this count unless they are directly contributing to the work of the sprint backlog. Product owner is a product visionary and is responsible for the success of a project by defining the project vision, requirements, and priorities. ScrumMaster is responsible for the team and removes impediments that will prevent them from achieving the goals set by the product owner. Development team is self-organized and cross functional. It works collaboratively to determine how the requirements decided by the product owner will be fulfilled. This team comprises people with a mix of roles to determine how best to meet the goals of the product owner.

Agile involves several practices to share knowledge within the team. Knowledge sharing happens at multiple avenues. Some of them are: • Project Kick-Off Meeting, • Sprint Planning Meeting, • Daily Stand-up Meeting , • Pair Programming , • Facilitated Workshops, • Sprint Reviews, • Agile Games, and • Collective Code Ownership All the meetings between team members are not aimed at knowledge sharing alone. The team members also gain a better understanding of the business and product, which helps them become generalizing specialists.

Some key terms used in Scrum are Product Backlog, Sprint, Sprint Backlog, and Scrum. Click each tab to know more. Product Backlog: It lists all the work to be performed by the team, to achieve the product owner’s vision of success, in the foreseeable future. It contains both well-defined requirements and those requiring further definition. Sprint: A period of 30 days or less, within which a set of work will be performed to create a deliverable. Sprint Backlog: Requirement that is well defined and can be worked on with little change, over 30 days or less, resulting in a tangible, potentially shippable incremental deliverable. Scrum: A daily meeting attended by the Scrum team to review the progress and impediments.

Different kinds of knowledge get shared based on the context of each meeting. During Release and Iteration Planning, knowledge on system requirements and the business domain between the on-site customers and the developers are shared. During Pair Programming and Pair Rotation, knowledge of various kinds, some explicit but mostly unstated, is shared between the pair. This includes task-related, contextual, and social resources. During Daily Scrum Meetings, team members report their work progress since the last meeting. Such meetings provide visibility of one’s work to the rest of the team. The premise is to create an environment of continued learning. This can be done by providing opportunities to people to develop their skills, lower risks around knowledge silos, and reduce bottlenecks.

There are four meetings defined by Scrum that happen over the course of a sprint. 1. Sprint Planning: This meeting is attended by all the members of the Scrum team. In this meeting, the development team identifies the stories from the product backlog for development and delivery in the current sprint. This meeting is timeboxed to eight hours for a monthly sprint, and proportionately less for sprints of shorter duration. Four hours for selecting stories and four hours for estimation is allotted. 2. Daily Stand-up Meeting: This is attended by the ScrumMaster and the development team, presence of product owner is optional. Each team member answers the following questions: “What was done yesterday?”, “What will be done today?”, and “What are the blockers?” This meeting is timeboxed to 15 minutes and happens daily at the same time and place. 3. Sprint Review: This meeting is attended by all the members of the Scrum team. The development team will demonstrate the developed features in the form of potentially shippable deliverables to the stakeholders and project sponsors. Feedbacks are noted down by the product owner, which will be converted into new user stories to be developed in the future sprints. This meeting is timeboxed to four hours for a monthly sprint, and proportionately less for sprints of shorter duration. 4. Sprint Retrospection: This meeting is attended by all the members of the Scrum team. The focus of this meeting is to retrospect how the sprint went by. Details pertaining to what went well, what did not, what needs to change, and what they would like to improve in the next sprint are captured. The team agrees on the improvement plans for the future sprints. This meeting is timeboxed to three hours for a monthly sprint, and proportionately less for sprints of shorter duration. As showcased in the image, all the meetings are repeated within each sprint.

Servant leadership is a relatively new concept that was originally coined and defined by Robert Greenleaf. Servant leadership style lends itself to the participatory style of management that is encouraged in self-organized and Agile teams. Servant leadership positions the leader as the enabler—one who helps the team, removes obstacles faced by the team, and gives them the required tools and skills

Given on the screen is a graphical representation of an ideal Agile project that uses Scrum. The flowchart showcases the flow of events of a typical Scrum project. Product owner prepares the product backlog that has all the user stories documented along with their prioritization. The high priority features occupy the top of the product backlog. The team, based on their historical visibility and velocity, decides which of the user stories and how much of them can be delivered in the release based on the product roadmap. These user stories are moved into release backlog. During the sprint planning meeting, the team selects the user stories from the top of the release backlog, which can be completed within a two week period. Such user stories then become part of the sprint backlog. Once the sprint backlog is decided, the team breaks them into tasks—for the ease of tracking and reporting. Through incremental iterations, the development team starts developing the features. Daily stand-up meetings are held to discuss the progress and raise issues. Burnup and burndown charts are used to showcase the progress. At the end of the sprint, the working software with the new functionality is demonstrated to the stakeholders to get their feedback. Finally, the team conducts a retrospective on the sprint performance and agree upon the action requests. Further, the team captures its velocity, which will be used for planning future sprints. This cycle continues.

Some of the characteristics of a servant leader are as follows: Listening: One needs to be a good listener to be an enabler. It is important to understand what the team needs to be helped with. Empathy: This refers to understanding the issues of the team members from their point of view. Healing: This is the ability to help team members recover from a traumatic situation, such as unsuccessful iteration or project and conflict with team members. Awareness: This refers to being aware of the issues faced by the leader and the team. Persuasion: This refers to the ability to persuade the team members to consider other’s points of view, encourage them to raise their issues, or to let others help them. Conceptualization: Being able to paraphrase and break down the issues into parts and handle them. Foresight: Being able to forecast and predict issues even before they arise. Stewardship: Being able to lead the team, assist the team members, and make them feel comfortable. Commitment to the growth of people: People will be comfortable when they are confident that the leader is genuinely interested and committed to help them grow. Building community: This means a leader must nurture other servant leaders. The best way one can scale up is by developing successors.

While taking up different Scrum roles, a few key points must be kept in mind. As a product owner, resist the temptation to "manage" the team or add more important work after the sprint is in progress. Product owner should be willing to make hard choices during the Sprint planning meeting. A ScrumMaster assists both the team and the product owner-- empowers the development team by facilitating creativity and guides the product owner on how to maximize Return on Investment or ROI. The team has the autonomy to choose how best to meet the goals, and is responsible for the same.

Servant leadership is valuable on all projects, regardless of methodology; however, it is necessary in Agile. This is because Agile believes in self-managing teams, which need no help with task management. But they need help in forming, building, and nurturing. Agile leaders adapt their behavior to meet the needs of the team, and are willing provide all help to achieve its goals. Values that would be cherished in such a team include trust, empathy, collaboration, and ethical use of power.

Extreme Programming or XP was developed by Kent Beck and Ward Cunningham in the 1990s to respond to the high cost of changing requirements and establish strong engineering practices to improve software quality. XP is a software development-centric Agile method and focusses on implementing the best software practices. XP emphasizes the same practices represented in the Agile Manifesto and reflected in Scrum. XP introduced many revolutionary concepts to software development that are now standard practices, such as Test Driven Development; Continuous Integration; Iterations; and User Stories. The aim of these practices is to ensure that customers receive what they need. XP allows developers to respond to changing customer requirements at any point in the project lifecycle.

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

Extreme programing builds around five core principles. Communication: This principle focuses on ensuring that everyone in the team knows what needs to be done and what the other person is doing. There will be frequent collaboration between users and programmers. The team members communicate using simple designs, common metaphors, and application of patterns. Simplicity: The focus of this principle is to find the simplest solution instead of complicating the solution with unwanted features and functionalities. The team will take small simple steps towards the goal and mitigate complexities and failures, by refactoring. Feedback: This principle focuses on ensuring that the solution is demonstrated to the stakeholders early and regularly. Unit tests are conducted for feedback from the system; Acceptance Tests are conducted for feedback from the customer; and Planning Games are conducted for feedback from the team. Courage: This principle focuses on the courage required to showcase the work being done. The team should allocate sufficient time within the sprint to refactor the code. Refactoring makes future changes easier and removes obsolete code. The team should showcase the partially done work during Pair Programming. Respect: This principle focuses on giving and taking. This includes respect for others; self-respect; adopting the other four values; and respect gained from others in the team.

Let us summarize the topics covered in this lesson: • A number of core Agile methodologies share the same philosophy expressed in the Agile Manifesto. However, they have different practices, processes, and techniques. • In Crystal Methodology, projects are categorized according to the size of the project, the number of people involved, and criticality. • Dynamic Systems Development Method (DSDM) was developed in the 1990s to provide more discipline to Rapid Application Development (RAD). The latest version is called Atern. • Agile Project Management introduced phases for Agile projects that aligned with the PMP phases applied by the Project Management Institute. • Alistair Cockburn defined Information Radiators as, "An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don't need to ask any question; the information simply hits them as they pass.” • Knowledge sharing is an important mechanism to scale Agile projects. • The concept of servant leadership was defined by Robert Greenleaf. This leadership style lends itself to the participatory style of management that is encouraged in self-organized and Agile teams.

The XP Practices introduced a wide range of techniques that are accepted as standard practices. Some of the techniques are: • Fine-scale feedback, which includes Pair programming; Planning game; Test-driven development; and Whole team; • Continuous process, which includes Continuous integration; Refactoring or design improvement; and Small releases; • Shared understanding, which includes Coding standards; Collective code ownership; Simple design; and System metaphor; and • Programmer welfare, which includes Sustainable pace.

This concludes Domain I, Agile Principles and Mindset. The next domain is ‘Value-Driven Delivery.’

In the given XP process diagram, you can see the normal flow of an XP project. Architectural spike and user stories are taken as input for the release planning. The outcome of this meeting would result in the release plan, which would drive the iterations planned within the release. The outcome of each iteration would be compared against the acceptance criteria and upon customer approval, the code would be shipped to the live environment through small release. This cycle of release planning, iteration planning, development, testing, and customer acceptance repeats for the entire duration of the project. It is recommended to spend some time and go through the diagram for a better understanding of the concept.

The given image shows the problems faced during the development of a project named Phoenix, which is an Image-Processing Environment. To develop an Image Processing Environment, the Phoenix programming team had to outline the functionality of the system. The project was required to have 20 C Language modules, 5 Assembly Language (x86) modules, and 9 Executable Helper Applications. To see the result of this project, click the ‘outcome’ button given on the screen. The Phoenix Development Team consisted of two developers, who used most of the XP features. Before they began coding, they outlined the functionality of the system with their customers and established a common understanding. They coded most parts of the Image Processing Environment together for 10 to 14 hours per day, for a period of four months. This gave them complete command over the development process. They decided what had to be developed and why. Further, this approach was ideal for the Phoenix project that consisted of more than 40,000 lines of code. Despite the development process requiring 10 to 14 hours per day, for a period of four months, the project was completed on time because of the team work. Furthermore, the functioning software was almost 100% bug-free.

In Crystal Methodology, projects are categorized according to the size of the project, the number of people involved, and criticality. Crystal Methodologies, developed by Alistair Cockburn, are designed for projects ranging from small teams developing low critical solutions to large teams developing mission critical solutions. The different levels of criticality are Comfort, Discretionary Money, Essential Money, and Life.

Depending on the project span, Agile processes must be extended beyond face-to-face communications. Additional verifications, validations, and traceability measures can be introduced as needed, thereby improving project flexibility. Some of the key principles of Crystal Methodology include: • Frequent delivery • Reflective improvement • Osmotic communication • Personal safety • Focus • Ease of access to experts • Technical environment with automated tests, configuration management, and frequent integration

Crystal methodology can be categorized in different ways. The important categories are Crystal Clear and Crystal Red. Crystal Clear is for small teams working on projects with low risk to life and using discretionary monies. In the image, the projects that fall on the far left, with team size of one to six, belong to this category. These projects develop less critical solutions, and failure of which would result in low financial loss. Crystal Red is for a larger project that deals with life and death implications, which would have more governance, documentation, and control gates. In the image, the projects on the far right belong to this category. Failure to achieve the required results would result in significant loss to the organization. Hence as the team size increases, it is important to increase communications within the team using tools to help improve project delivery. Also, the crystal methodology moves on to Crystal Yellow and Crystal Orange as the size of the team and complexity increases.

Dynamic Systems Development Method or DSDM was developed in the 1990s to provide more discipline to Rapid Application Development or RAD. The latest version is called Atern. It is one of the earliest Agile methods and covers the entire project life cycle. This method is quite detailed and ensures the project does enough design upfront before any of the development activity begins. The features of this method are as follows: DSDM uses a prioritization technique called MoSCoW, which stands for Must, Should, Could, and Won’t to determine the requirements to be included in a release or iteration. The Atern methodology fixes the schedule, cost, and quality, while achieving contingency by varying the features. This ensures the delivery of Minimum Usable Subset (MUS) of features. This is also illustrated in the given image.

As listed on the screen, DSDM revolves around eight principles. They are: Focus on the business need: Understand the business priorities and clearly define the scope of the system. Establish a sound business case, seek continuous business sponsorship and commitment, and guarantee the Minimum Usable Subset of features. Deliver on time: Timebox the work, focus on business priorities, and always meet deadlines. Collaborate: Build a one-team culture. Involve the right stakeholders, at the right time, throughout the project and ensure that the team members are empowered to take decisions. Never compromise quality: Build in quality by constant review, and test early and continuously. It is important to see test-driven development for comparison. Build incrementally from firm foundations: Formally re-assess priorities and ongoing project viability with each delivered increment. Strive for early delivery of business benefit and constantly verify the solution being built. Develop Iteratively: Take an iterative approach to build all products, build customer feedback into each iteration, and embrace change. Communicate continuously and clearly: Run daily team stand-up sessions, use facilitated workshops, and communication techniques such as modelling and prototyping. Manage stakeholder expectations throughout the project, and encourage informal, face-to-face communication at all levels. Demonstrate control: Use an appropriate level of formality for tracking and reporting. Make plans and progress visible to all. Measure progress through focus on delivery of products, manage proactively, and evaluate project viability based on the business objectives.

The given image represents the phases of DSDM. Click each phase to learn more. In the Pre-Project phase, identify and select the right project for development that would deliver value. In the Feasibility phase, identify if a feasible solution exists for the project selected during the pre-project phase. In the Foundation phase, establish a strong foundation for the project from a business and technical front, and identify the necessary standards that the project needs to adhere to. In the Exploration phase, iteratively and incrementally develop the solution. The resultant solution is not expected to be production-ready as the non-functional requirements need to be developed during the Engineering phase. In the Engineering phase, iteratively and incrementally develop the non-functional requirements to make the product production-ready. The focus here is on factors such as maintainability, security, portability, response, and time. In the Deployment phase, deploy the solution to the live environment. In the Post-Project phase, assess the business benefits that are realized through delivery of the solution developed.

Feature Driven Development or FDD is an iterative and incremental approach to software development that was developed in the 1990s by Jeff DeLuca and Peter Coad. Features are small pieces of client-valued functions expressed in the form given on the screen. Through decomposition, domain models are broken down into subject areas, which are then expressed as business activities. The team using FDD method would first develop a prototype of the product, and then build a list of features to be developed. Next, they would plan on how the product would be developed using iterative and incremental approach. Each step in a business activity is a feature. FDD popularized the cumulative flow diagram and parking lot diagrams, which are useful for tracking and monitoring the delivery progress. Care needs to be taken to ensure that each feature does not take more than two weeks to complete; else they should be broken down into smaller pieces.

The book, Agile Project Management (APM) by Jim Highsmith, was one of the first attempts to broaden Agile techniques into a cohesive whole. APM introduced phases for Agile projects that aligned with the PMP phases applied by the Project Management Institute. As shown on the image, APM also modified the traditional “Iron Triangle” to emphasize Value and Quality, and created the “Agile Triangle.” The primary focus is to deliver value and quality within the constraints of cost, schedule, and scope. APM also states that while value is extrinsic and can be seen through the delivery of features, quality is intrinsic. Quality is defined as part of the requirement and later built into the solution by the team.

The Agile Project Management typically follows five phases. They are as follows: • Envision: Determine the product vision, project scope, project community, and how the team will work together. • Speculate: Develop a feature-based release, milestone, and iteration plan to deliver the vision. • Explore: Deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project. • Adapt: Review the delivered results, current situation, and the team's performance, and adapt as necessary. • Close: Conclude the project, pass along key learning, and celebrate.

Michele Sliger aligned the Agile Project Management Framework to the PMI Project Management Book of Knowledge or PMBOK. The given image shows the correlation between the two. Here, the Initiation phase is parallel to Envisioning, Planning phase is parallel to Speculating, Executing phase is parallel to Exploring, Controlling phase is parallel to Adapting, and Closing phase is parallel to Closing.

Tom and Mary Poppendieck introduced Lean software development to the Agile community. Lean software development adopts the principles and practices from Toyota Production system or TPS. TPS was developed to address issues that affect manufacturing processes, like Muri (Overuse), Mura (irregularities), and Muda (waste). Muri is to cause overburden, such as unnecessary stress on the employees and processes. This is caused by Mura and a host of other failures in the system, such as lack of training, unclear ways of working, and wrong tools. Mura is the waste caused by unevenness or irregularity. Unrealistic demand results in unevenness in the processes, which leads to waste creation. Mura drives Muda. Muda is any activity or process that does not add value. This can refer to waste of time, resources, and money.

The seven lean principles are as listed on the screen: Eliminate waste: Anything that does not add value to the customer is considered waste (Muda). Unnecessary code and functionality, delay in the software development process, unclear requirements, insufficient testing, bureaucracy, and slow internal communication are a few examples of Muda. Amplify learning: Learning is amplified through short iteration cycles, refactoring and integration testing, and frequent customer feedback sessions. Each of these techniques shed more light on the problem domain and identify opportunities to improve. Decide as late as possible: The best way to manage uncertainty is by gaining information, minimizing assumptions, deferring commitment to the last responsible moment, and breaking dependencies between components. Deliver as fast as possible: Short iterations or small batches provide valuable feedback opportunities and allow effective decision making. Empower the team: Lean focuses on the team as the source of decision making and management turns to team to understand the best options and their costs. Build integrity in: Ensuring that quality is embedded throughout the system requires automation of testing through builds, installs, and continuous integration. Finally, think big, act small, fail-fast, and learn rapidly.

Kanban is a Japanese term for signal board. It was also developed in the Toyota Production System or TPS. Agile has adopted Kanban technique to reflect the throughput of a Sprint or iteration. It showcases the status of each user story within the sprint and helps gauge the cycle time and the throughput of the team. Kanban boards are also used in most Agile software products, which are useful for Agile distributed teams. Most Kanban boards are located in the team room and have user story cards or post-it notes distributed across different categories. Use of Story cards or post-it notes helps everyone in the team to understand the complete scope of work to be done. Kanban helps manage the throughput of a process by identifying bottlenecks, setting ‘Work In Progress’ limits, and displaying the status of the entire production system with one view. The sample Kanban board given on the screen showcases the various teams, which a user story has to pass through, to term a story as Release Ready. Also, notice that the WIP limits set at the top of the chart, which helps minimize the total amount of work done at any point in time.

Kanban is an evolutionary change for an organization. It helps increase the visibility of project progress throughout the company. It drastically reduces the time-to-market, development, and engineering time. The results of Kanban influence both the Web and the software development. It helps in organizing work. It also boosts communication among team members helping them solve problems quickly. The graphic shows the benefits of implementing Kanban in a company. Kanban reduced the lead time of a project from 22 days to 14 days, the development time from nine to three days, and the engineering took eight days instead of 11 days. It was found that these results could not be achieved using different methods.

Lean Kanban Method was established by David Anderson who saw the potential of both techniques in dramatically improving software development activities. Lean Kanban blends Kanban with Lean and other Agile principles to improve processes. The three principles of Lean Kanban and five core practices of Lean Kanban are listed on the screen. Click each tab to know more. The three principles of Lean Kanban are as follows: 1. Start with what you know: This method does not prescribe a specific set of standards or procedures; rather it insists on using Kanban along with the existing process or workflows. Following this principle helps reduce major changes and eases Kanban implementation. 2. Agree to pursue incremental, evolutionary change: Develop the solution incrementally and regularly get these changes compliant with the business. This leads to overall solution being developed slowly, thus avoiding sweeping changes being made with minimal resistance later on. 3. Respect current roles, responsibilities, and job titles: Kanban recognizes that there may be value in the existing process, roles, responsibilities, and titles. If changes have to be made, it needs to be introduced incrementally, as this will avoid the fear of progress getting impacted. Minimal changes are easier to implement than large system-wide changes. The five core practices of Lean Kanban are as follows: 1. Visualize: Visualizing the work flow through the system helps the entire team to know exactly ‘what happens next’. Such visual representations help to refine and optimize the current workflow and improve efficiency. 2. Limiting work in progress: Limiting the amount of work in progress helps to identify bottlenecks and run the entire process efficiently. It also helps to reduce the sunk cost and wastages that might result from changes later on. 3. Manage flow: Tracking the flow of work through the system helps the team identify issues that can be used to improve effectiveness. 4. Make management policies: Ensure all the team members clearly understand the policies and ground rules. This helps them make informed decisions and bring about improvements. 5. Improve collaboratively, using “safe to fail” experiments: It is better to fail-fast than fail later in the project, as this helps to prevent wastage of effort and cost. Through collaborative experiments, team should improve the processes it uses.

OpenUP is an open-source variant that IBM released to the public domain in 2006 and is a variant of the Rational Unified Process or RUP. OpenUP is a Lean unified process that applies iterative and incremental approaches within a structured lifecycle. It embraces Agile philosophy that focuses on the collaborative nature of software development. OpenUP is a tools-agnostic, low-ceremony process that can be extended to different project types. It targets small and co-located teams involved in Agile and iterative development. Small projects constitute teams of three to six people, involving three to six months of development effort.

As depicted in the given image, OpenUP has four phases across the project lifecycle. First is the Inception Iteration Phase. The initial idea or concepts are generated in this phase. The objectives of this phase are: • Understand what to build • Identify key system functionality • Determine at least one possible solution • Understand the cost, schedule, and risks associated with the project Next is the Elaboration Iteration Phase, where ideas are fine-tuned or elaborated. The objectives of this phase are: • Get a detailed understanding of the requirements • Design, implement, validate, and baseline an Architecture • Mitigate essential risks, and produce accurate schedule and cost estimates This is followed by the Construction Phase Iteration, where the solution is developed in line with the ideas generated in the earlier phases. The objectives are as follows: • Iteratively develop a complete product that is ready to transition to its user community • Minimize development costs and achieve some degree of parallelism Last is the Transition Phase Iteration, where the solution is moved into production. The objectives of this phase are: • Conduct beta test to validate that user expectations are met • Achieve stakeholder concurrence that deployment is complete

Information radiators are important tools for communicating information on Agile projects. The concept of information radiators was invented by Alistair Cockburn. He defined it as: "An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don't need to ask any question; the information simply hits them as they pass.” Information radiators are most effective with co-located teams. Some of their features are as follows: They are intended to enable team members to view the current state of the project and its progress. Information radiators are also helpful to provide information to other non-project team members. Most Agile teams implement them to some degree in their processes. A few examples of information radiators are boards with swimlanes and status columns showing the progress of work items; Big Visible Charts including Burndown charts, showing team velocity across iterations; and Continuous integration build health indicators, which many teams choose to display using lava lamps and street lights. These information radiators improve project communication in a lightweight and easy to manage fashion.

Effective information radiators should be: • Simple: Easy to understand • Stark: Errors should not be masked, rather they should be used to improve the work and performance • Current: Information displayed should be current • Transient: Once the problem has been rectified, it should be taken off from the chart • Influential: Empowers the team to take decisions • Highly visible: Easy to see and understand • Minimal in number: Key information must be emphasized Information radiators help in building transparency and a shared understanding of the success criteria, deliverables, and other key aspects of the project to align expectations, build trust among the stakeholders, and make informed decisions.

Some examples of information radiators, such as Burndown Chart, Burnup Chart, Combined Burn Chart, and Risk Log are shown here. It is recommended to go through these images for better understanding. These examples are however discussed in the later part of this course.

Agile projects operate in a timeboxed manner. Hence, it is critical that the team is upskilled not only in the technical aspects, but also in the functional aspects. Some key points to remember are as follows: Knowledge sharing is an important mechanism to scale larger and mission-critical Agile projects successfully. When team members interact with their fellow mates during the course of the day, the knowledge sharing session needs to be scheduled with goals clearly defined. The team’s participation must be monitored to ensure knowledge transfer happens in a structured manner. The given image depicts the knowledge sharing happening on a one-to-one and one-to-many basis.

Agile involves several practices to share knowledge within the team. Knowledge sharing happens at multiple avenues. Some of them are: • Project Kick-Off Meeting, • Sprint Planning Meeting, • Daily Stand-up Meeting , • Pair Programming , • Facilitated Workshops, • Sprint Reviews, • Agile Games, and • Collective Code Ownership All the meetings between team members are not aimed at knowledge sharing alone. The team members also gain a better understanding of the business and product, which helps them become generalizing specialists.

Different kinds of knowledge get shared based on the context of each meeting. During Release and Iteration Planning, knowledge on system requirements and the business domain between the on-site customers and the developers are shared. During Pair Programming and Pair Rotation, knowledge of various kinds, some explicit but mostly unstated, is shared between the pair. This includes task-related, contextual, and social resources. During Daily Scrum Meetings, team members report their work progress since the last meeting. Such meetings provide visibility of one’s work to the rest of the team. The premise is to create an environment of continued learning. This can be done by providing opportunities to people to develop their skills, lower risks around knowledge silos, and reduce bottlenecks.

Servant leadership is a relatively new concept that was originally coined and defined by Robert Greenleaf. Servant leadership style lends itself to the participatory style of management that is encouraged in self-organized and Agile teams. Servant leadership positions the leader as the enabler—one who helps the team, removes obstacles faced by the team, and gives them the required tools and skills

Some of the characteristics of a servant leader are as follows: Listening: One needs to be a good listener to be an enabler. It is important to understand what the team needs to be helped with. Empathy: This refers to understanding the issues of the team members from their point of view. Healing: This is the ability to help team members recover from a traumatic situation, such as unsuccessful iteration or project and conflict with team members. Awareness: This refers to being aware of the issues faced by the leader and the team. Persuasion: This refers to the ability to persuade the team members to consider other’s points of view, encourage them to raise their issues, or to let others help them. Conceptualization: Being able to paraphrase and break down the issues into parts and handle them. Foresight: Being able to forecast and predict issues even before they arise. Stewardship: Being able to lead the team, assist the team members, and make them feel comfortable. Commitment to the growth of people: People will be comfortable when they are confident that the leader is genuinely interested and committed to help them grow. Building community: This means a leader must nurture other servant leaders. The best way one can scale up is by developing successors.

Servant leadership is valuable on all projects, regardless of methodology; however, it is necessary in Agile. This is because Agile believes in self-managing teams, which need no help with task management. But they need help in forming, building, and nurturing. Agile leaders adapt their behavior to meet the needs of the team, and are willing provide all help to achieve its goals. Values that would be cherished in such a team include trust, empathy, collaboration, and ethical use of power.

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

Let us summarize the topics covered in this lesson: • A number of core Agile methodologies share the same philosophy expressed in the Agile Manifesto. However, they have different practices, processes, and techniques. • In Crystal Methodology, projects are categorized according to the size of the project, the number of people involved, and criticality. • Dynamic Systems Development Method (DSDM) was developed in the 1990s to provide more discipline to Rapid Application Development (RAD). The latest version is called Atern. • Agile Project Management introduced phases for Agile projects that aligned with the PMP phases applied by the Project Management Institute. • Alistair Cockburn defined Information Radiators as, "An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don't need to ask any question; the information simply hits them as they pass.” • Knowledge sharing is an important mechanism to scale Agile projects. • The concept of servant leadership was defined by Robert Greenleaf. This leadership style lends itself to the participatory style of management that is encouraged in self-organized and Agile teams.

This concludes Domain I, Agile Principles and Mindset. The next domain is ‘Value-Driven Delivery.’