This tutorial is about ‘Agile Methodologies and Frameworks- Kanban and Lean Management’ of the PMI-ACP Certification course offered by Simplilearn. We will learn the basics of Agile and also learn about Kanban Methods and Lean Management.
After completing this lesson, you will be able to:
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 Agile methodology. The best practices from different agile methodologies can be chosen and implemented in the project.
Some of the key Agile methodologies are:
Let us discuss these Agile methodologies in detail in this lesson.
Scrum methodology 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 methodology popular are as follows:
There are three pillars of Scrum methodology, such as Transparency, Inspection, and Adaptation.
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 an inspection, necessary changes are made to the process to avoid problem recurrence and improve the project delivery position.
Let’s discuss about Scrum Roles below.
The Scrum roles are important features of Scrum methodology. There are three key roles defined in the Scrum guide.
They are the Product Owner, Scrum Master, 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.
The 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.
The 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.
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 methodology that happen over the course of a sprint.
As showcased in the image, all the meetings are repeated within each sprint.
Given below 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. The product owner should be willing to make hard choices during the Sprint planning meeting.
A ScrumMaster assist 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.
Interested in learning more about Agile Methodologies? Check out the course preview here!
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 focuses 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 programming builds around five core principles.
The XP Practices introduced a wide range of techniques that are accepted as standard practices.
Some of the techniques are:
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. 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 teamwork. Furthermore, the functioning software was almost 100% bug-free.
In Crystal Agile 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:
Crystal Agile 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 a team size of one to six, belong to this category.
These projects develop less critical solutions and failure of which would result in a 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 lifecycle.
This method is quite detailed and ensures the project does enough design up front 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.
DSDM revolves around eight principles. They are:
The given image represents the phases of DSDM.
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 the 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 below.
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.
Willing to know more about scaled Agile Framework and practices? Click here!
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 the 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:
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.
Let us go through Lean Software Development below.
Tom and Mary Poppendieck introduced Lean software development to the Agile community. Lean software development adopts the principles and practices of 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 below:
Let’s understand about Kanban and Kanban Methods in detail below.
Kanban is a Japanese term for a 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 below 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 to 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 below.
The three principles of Lean Kanban are as follows:
The five core practices of Lean Kanban are as follows:
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 the 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.
Inception Iteration Phase
The initial idea or concepts are generated in this phase. The objectives of this phase are:
Elaboration Iteration Phase
Here ideas are fine-tuned or elaborated. The objectives of this phase are:
Construction Phase Iteration
Here the solution is developed in line with the ideas generated in the earlier phases. The objectives are as follows:
Transition Phase Iteration
Here the solution is moved into production. The objectives of this phase are:
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:
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 time-boxed 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 with the team. Knowledge sharing happens at multiple avenues.
Some of them are:
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 continuous learning. This can be done by providing opportunities to people to develop their skills, lower risks around knowledge silos, and reduce bottlenecks.
Let’s understand about Servant Leadership below.
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:
Servant leadership is valuable for all projects, regardless of methodology; however, it is necessary for 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.
Your search for PMI-ACP certification starts here. Click to know more!
Let us summarize the topics covered in this lesson:
This concludes ‘Agile Methodologies and Frameworks- Kanban and Lean Management’. In the next domain, we will learn ‘Value-Driven Delivery- Kano Model.
Name | Date | Place | |
---|---|---|---|
PMI-ACP® Certification | 6 Feb -27 Feb 2021, Weekend batch | Your City | View Details |
A Simplilearn representative will get back to you in one business day.