Unit 2
Unit 2
Verified by : Approved by :
What is Lean?
Lean is about developing a project smartly by focusing on what the customer wants and eliminating the non-
value adding activities in the process. In other words, the lean methodology emphasizes on excluding the
features that are not valuable to the customers and then prioritize & deliver them in small batches.
• Eliminating waste
• Increased learning
• Delivering end product as soon as possible
History of Lean:
In the 20th century, a manufacturing giant called Toyota faced issues with its long production and
manufacturing chains. Hence, a solution called the Toyota Production System was devised, which focused
on eliminating waste activities from the manufacturing cycle. Later, it got renamed to Lean manufacturing.
In 2003, its implementation happened in the Software industry. Its leading proponents were Mary & Tom
Poppendeick, who compiled the principles of Lean in a book called “Lean Software Development”.
Principles of Lean:
The main principle of Lean is to deliver high-quality products in minimum time with the least wastage of
resources.
• Optimize the whole – To be effective, you have to look at the bigger picture and develop a system
that focuses on individual parts of a project along with the smooth functioning of the entire system.
• Eliminate waste – Waste (as discussed later) can be understood in “Lean terms” as the non-value
adding. Hence, the focus should be on intentionally reducing the non-value adding & unnecessary
activities.
• Build Quality In – This means developing an automated and standardized system that foolproofs it
from any human error.
• Deliver Fast – The faster we deliver to our customers, the quicker we will get the feedback and work
upon it.
• Create Knowledge – This means all the learnings and findings learned during a project should be
documented so that they can be shared with others as well.
• Respect People – This boils down to understanding that each entity is equally essential in the
success of any project. One should treat customers, colleagues, employees with equal respect.
• Defer Commitment - This is a basis just in time philosophy, i.e., teams should responsibly wait and
collect enough information before making any decision.
Lean Artifacts-
• Value-Add activities –are all the activities that physically improve a product or a service for
customers. Which, in turn, means they are those activities that add value!
• Non-Value Add (NVA) activities – are activities that do not add value but undergo execution. The
Customer has to bear the cost of NVA, and since it is not a value add, a customer doesn’t want to
pay for it.
• Waste: Anything that doesn’t bring value to the table is referred to as waste & eliminating it is the
core of Lean thinking.
Toyota Production System’s forefather Shigeo Shingo identified seven major wastes in the manufacturing
process. Which, in turn, were later translated into 7 Wastes of Software Development, by Mary & Tom
Poppendick.
They are:-
• Lean is not a time-bound approach, unlike Scrum, where you have to finish an iteration in 2-4
weeks.
• Lean is a philosophy or a mindset, whereas Scrum is a framework.
Scrum:
What is Scrum?
Scrum is one of the most commonly used Agile methodologies. Scrums have gained popularity within the
Agile software development community because they are simple and have a proven productivity rate.
Scrum focuses on Team. It is a method that concentrates specifically on how to manage tasks within a team-
based development environment. Scrum believes in enabling & empowering the development team and
suggests working in small teams (say- 7 to 9 members).
Principle of Scrum
The fundamental principle of Scrum is that by dividing time and projects, you can enhance an organization's
effectiveness and productivity.
Scrum makes the process of development less complicated by making the information transparent. Which,
in turn, helps the team to overcome the disadvantages of waterfall model like
Scrum Artifacts:
We will try to comprehend it with the help of an example. If you have to construct your house, what would
be your strategy? First, we will make the list of all requirements as below-
Now, the architect confirmed that they would come over for the discussion on Week2, Day 1 from today so
you will start prioritizing your tasks from the above list and put some timeline around it. e.g. -
• Week 1 – Finish the purchase of the land, registry, considering legal formalities, etc.
• Week 2, Day 1 – Meet architect, list your design requirements.
o Day 3 - finalize the design, suggest modifications
o Day 5 - pass the map
• Week 3, Day 1 - hire contractor, share the house design
You may like to capture these activities along with timelines in a separate document. Which, in turn, will
ensure the timely completion of all the activities. This document is known as "Sprint Backlog". Whereas,
the process of defining objectives to achieve is known as "Sprint Goal" or "Increment" in Scrum. For
example – for Week 2, Day 1, you kept an objective to meet the architect & finalize the design. It is
Increment.
Scrum Master:
The Scrum Master is responsible for making sure that the Scrum Team adheres to the values and principles
of Agile methodology. Additionally, the scrum master ensures the adherence to the processes and practices
that the team agreed they would use. The responsibilities of a Scrum Master include:
• Clearing obstacles
• Establishing an environment where the team can be effective
• Addressing team dynamics
• Ensuring a good relationship between the team and the Product Owner as well as others outside the
team
• Protecting the team from outside interruptions and distractions.
Product owner:
The Product Owner in a product development team is responsible for managing the product backlog to
achieve the desired result that a team seeks to accomplish. Key activities to accomplish this include:
The creation of the Product Owner role as part of the Scrum framework happened to address the challenges
that product development teams faced. For instance, multiple & conflicting directions or no direction at all
concerning what to build.
Scrum Team:
Scrum Team is also known as the “Development team”. It usually consists of Developers. Testers,
Designers, etc. They are the ones who work on Product Backlog items. According to the Scrum Guide, the
scrum team should be between three to nine people and should have all the skills necessary to deliver the
product. Below are some of the main characteristics of the Scrum Team:
Process of Scrum:
By now have a fair bit of understanding about Artifacts of Agile methodology as well as various roles in the
Scrum process. Therefore, let’s try to familiarize ourselves with Scrum Process Flow.
1. Product Backlog- Here, the Product owner meets the client and takes down all the requirements. A
document referred to as Product Backlog captures these requirements.
2. Sprint Backlog – Now, the Product Owner shares this Product Backlog with the Sprint team (consists
of Scrum Master, Developers, and testers) in a meeting referred to as the “Sprint Planning” meeting. In
sprint planning, the entire team agrees to complete a sub-set of product backlog items. This agreement is
called the Sprint Backlog & its basis the team’s velocity/ capacity & the length of the sprint. The vital
point to note here is, once the team has finalized the Sprint backlog, they cannot change it within the
Sprint. If any change is required, it either goes to the next sprint, or the cancellation of the current sprint
happens.
For instance, the team may decide to release software in 3 iterations (each iteration is referred to as
“Sprint” in the world of Scrum)
Applicability of Scrum:
In the complex situations where the outcome is unknown at the beginning, and the approach should be to
adapt & evolve in the process. Scrum works on a time-boxed iterative approach. The main focus of this
approach is working incrementally rather than all at once.
Crystal
What is Crystal?
Alistair Cockburn defined Crystal as, “Crystal is a family of human-powered, adaptive, ultra-light,
‘stretch-to-fit’ software development methodologies”.
The Crystal agile framework focuses on individuals & their interactions within a system over process &
tools; which is also one of the agile manifesto statements.
History of Crystal:
Alistair Cockburn developed the “light-weight” methodology called Crystal for IBM in 1991.
Cockburn interviewed & researched numerous people who did not follow the traditional/ formal approach
but still delivered practical, successful projects. Therefore, he realized that different team size & dynamics
lead to varying procedures to carry on the projects.
Characteristics of Crystal:
As stated earlier, Cockburn defined Crystal as a family of human-powered, adaptive, ultra-light, ‘stretch-to-
fit’ software development methodologies
• Human Powered – Means the people involved in the project are the most crucial entity & that the
entire project process flow should adapt around them.
• Adaptive / Stretch-to-fit - This means crystal has no fixed process or tools. Instead, they are
stretched to fit the ever-changing needs of a project & adapt to different business requirements.
• Ultra-light – It is a lightweight methodology that focuses on transparency & open communication. It
does not go heavy on documentation.
Cockburn discovered that the properties of a project depend on the number of people involved in the project.
The way smaller teams work inside a project can be different than the way bigger teams work on a large-
scale project. In other words, the criticality & the complexity of the procedure to carry on the project is
directly proportional to the size of the team.
Therefore, there is no one single Crystal method. In other words, there are different Crystal methodologies
for different types of projects which depends upon the following factors:-
Generally, different colors represent different team sizes. Which, collectively, in turn, is the Crystal
Family. They are:-
Apart from these, Crystal Diamond & Crystal Sapphire apply when there is a large amount of risk posed to
human life.
Four Levels of Criticality refers to the possible amount of risk posed by a system if it does not perform as
expected. They are –
• Comfort
• Discretionary Money
• Essential Money
• Life
The above diagram depicts that the larger the project gets (in ascending order of complexity) the darker the
color becomes. In other words, it is illustrating the criticality of the project. For example, the L40 project
refers to a project having 40 team members developing a Life-Critical project.
The Crystal methodology can be related to the different facets of a gemstone crystal. Which, in turn, means
different faces of a crystal refer to the different underlying core principles & values in a crystal
methodology. These facets are a representation of techniques, tools, policies & roles; which differ in
different project conditions.
Applicability of Crystal:
To conclude, Crystal methodology applies to various project/team sizes. For instance, if there is a team of
six developers, then Crystal Clear is more appropriate. On the other hand, if there is a bigger team of say
more than 20 people, then Crystal Orange is suitable. Similarly, Crystal Sapphire or Crystal Diamond
methods apply in large projects that involve potential risk to human life. To sum up, the determination of the
magnitude of the Crystal methodology happens by the project environment and the team size.
Following are the main differences between Crystal & Scrum methodology:-
What is FDD?
FDD is a design-oriented Agile process developed by Jeff De Luca & Peter Coad.
As the name "Feature Driven Development" suggests, it is the features that are nothing but small-sized
projects which are in a complete state. Features in FDD are just like User stories in Agile methodology.
Principle of FDD:
FDD also works on the principles of the Agile Manifesto. It focuses on delivering client-valued features in
the <action>``<result>``<object> format. e.g., register (action) the account (result) of a user (object) is a
form of a feature that the FDD method uses.
Roles in FDD:
Following are the leading roles in the FDD process - Project Manager, Chief Architect, Development
Manager, Chief Programmer, Class Owner, and Domain Expert.
Process of FDD:
There are mainly five steps that this process uses. The below diagram depicts the procedure followed in the
FDD methodology.
1. Develop an Overall Model -The client team and development team develop an overall model. Chief
Architect guides this.
2. Build a Feature List - Shortlist the features for the implementation, from the client requirements given in
the first step. Each feature should complete within two weeks.
3. Plan By Feature - This means planning the features which require implementation and deciding which
team will be responsible for doing it. Teams are selected & given different feature sets.
4. Design By Feature - The chief programmer designs the feature by drawing sequence diagrams.
Sequence Diagram is the vertical diagrammatic representation of the sequence of different activities
carried out at different times. Its objective is to track the progress.
5. Build By Feature - The Chief programmer writes the code, tests it, and checks. After that, if it's ok, it
gets the approval.
Advantages of FDD:
1. Risk Reduction - FDD helps in reducing risks using shorter iterations of designing, understanding of the
requirements, and the system without any ambiguity.
• Unlike Scrum, each iteration has to complete within two weeks. If it is not possible, then it further
breaks into smaller pieces until it meets the limit of two weeks.
• FDD chooses the best of the different methodologies in the Agile Scrum, XP, etc. & applies them.
A feature team consists of a project manager, chief architect, development manager, domain expert, class
owner, and chief programmer, unlike Scrum, which has only three roles. Namely, Product Owner, Scrum
Master & Scrum Team.
• Speculate
• Collaborate
• Learn
These three phases reflect the dynamic nature of Adaptive Software Development. The Adaptive
Development explicitly replaces Determinism with Emergence. It goes beyond a mere change in lifecycle to
a deeper change in management style. Adaptive Software Development has a dynamic Speculate-
Collaborate-Learn Lifecycle.
The Adaptive Software Development Lifecycle focuses on results, not tasks, and the results are identified as
application features.
Speculate
The term plan is too deterministic and indicates a reasonably high degree of certainty about the desired result.
The implicit and explicit goal of conformance to plan, restricts the manager's ability to steer the project in
innovative directions.
In Adaptive Software Development, the term plan is replaced by the term speculate. While speculating, the
team does not abandon planning, but it acknowledges the reality of uncertainty in complex problems.
Speculate encourages exploration and experimentation. Iterations with short cycles are encouraged.
Collaborate
Complex applications are not built, they evolve. Complex applications require that a large volume of
information be collected, analyzed, and applied to the problem. Turbulent environments have high rates of
information flow. Hence, complex applications require that a large volume of information be collected,
analyzed, and applied to the problem. This results in diverse Knowledge requirements that can only be
handled by team collaboration.
Collaborate would require the ability to work jointly to produce results, share knowledge or make decisions.
In the context of project management, Collaboration portrays a balance between managing with traditional
management techniques and creating and maintaining the collaborative environment needed for emergence.
Learn
The Learn part of the Lifecycle is vital for the success of the project. Team has to enhance their knowledge
constantly, using practices such as −
• Technical Reviews
• Project Retrospectives
• Customer Focus Groups
Reviews should be done after each iteration. Both, the developers and customers examine their assumptions
and use the results of each development cycle to learn the direction of the next. The team learns −
• About product changes
• More fundamental changes in underlying assumptions about how the products are being developed
The iterations need to be short, so that the team can learn from small rather than large mistakes.
Speculate - Collaborate - Learn Cycle as a Whole
As you observe from the Speculate-Collaborate-Learn cycle, given above, it is obvious that the three phases
are nonlinear and overlap.
We observe the following from an Adaptive framework.
• It is difficult to Collaborate without Learning or to Learn without Collaborating.
• It is difficult to Speculate without Learning or to Learn without Speculating.
• It is difficult to Speculate without Collaborating or to Collaborate without Speculating.
What is XP?
Kent Beck developed this, and it has evolved as a highly disciplined method of continuously delivering
high-quality software. XP methodology works on five core values as discussed below:-
• Simplicity – First is Simplicity. Which in simple words means avoiding the waste and only doing
what’s needed & asked.
• Communication – Second is Communication, which means having face-to-face communication to
clear any doubts. In other words, it means to be on the same page.
• Feedback – Third is Feedback, which means providing constructive feedback, which is workable for
future improvements. One can achieve this by focusing on the changes needed & implementing them.
• Courage – Fourth is Courage, which means adapting to the changes & not making excuses for the
failure. In addition to this, being truthful about the estimates & progress of the project.
• Respect- Fifth is Respect. This means everyone deserves respect as an individual team member.
Practices of XP:
The below image depicts the 12 practices on which XP works. These are mutually inclusive of each other
meaning all these practices work in conjunction to deliver effective & efficient products.
1. Pair Programming – It implies two team members sit on the same computer & work together. The driver
writes the code & the observer reviews each line of code when it's written. This, in turn, helps in quick
identification of areas of improvisation.
2. On-Site Customer – The XP customer is highly engaged with the team & is available on-site to provide
regular feedback.
3. Test-First – Implies testing the code first & then running it later after fixing the bugs. It helps in reduced
effort & less number of errors during the production.
4. Iterative Development – It is also known as incremental design which means doing work in small
increments & building it up further.
5. Refactoring – Its primary focus is to remove the duplication of various processes.
6. Simple Design – Keeping the system design as simple as possible will ensure the smooth running of the
process.
7. Planning Game – The stories are used to describe end-user requirements & the planning process.
8. Coding Standards – Establishing standardized rules of code for all of the team members.
9. Continuous Integration – This means testing of small codes happens immediately before adding them to
a more significant project. It ensures that error detection happens early on.
10. 40- Hour week – As the name suggests, every team member is required to work for 40 hours a week.
Therefore, maintaining a work-life balance.
11. Collective code ownership - This means everyone owns the code in the team & that everyone is allowed
to exert a "positive" duty to make the changes to the code as necessary. Hence, it reduces the dependency
on any one developer.
12. Metaphor – This means a simple layman explanation of how the code works, i.e., the ability to explain
the system to the new people without flooding them with technical terms.
Process of XP:
• Planning – The first stage of the process is to start collecting the requirements from the customers
in the form of user stories. The value of each user story is then estimated, which should roughly help
the team to understand how long it will take to implement a story. XP practices used here are:-
o Planning Game
o On-Site Customer
• Design – Second is Design. Having a simple design of a system ensures fewer dependencies & early
deliveries. The addition of any extra functionalities can happen later as well. Additionally, if some
stories need more research in terms of technicality, a short time-boxed period is assigned
called Spike. XP practices used here are:-
o Refactoring
o Simple Design
• Coding – Third is coding. This is the core of any process. The actual coding of software starts here.
In other words, the team sits together & starts working incrementally to deliver the end product. XP
practices used here are:-
o Pair programming
o Collective code ownership
o Coding Standards
• Testing – Towards the end, the code is tested first & run later, after fixing the bugs. Following
practice supports it
o Continuous integration
o Test first
o Iterative development
• Release – Finally, the customer valued product is released & project velocity is computed to keep a
tab on the progress. Measurement of Project velocity happens, which is a quantifying criterion of the
amount of work accomplished in a project.
Advantages of XP:
1. Time-saving - Firstly, it allows the organizations to save time required for project execution because XP
focuses on the timely delivery of final products.
2. Cost-Effective - Secondly, XP saves a lot of money because they don’t use too much documentation.
They usually solve problems through discussions inside of the team.
3. Simplicity- Thirdly, the developers create a straightforward code that they can improve at any moment.
4. High Visibility - Finally, the whole process in XP is visible and accountable. Developers commit what
they will accomplish and show progress.
1. Scrum works on iterations which are 2-4 weeks long whereas XP iterations are 1-2 weeks long.
2. Scrum doesn't allow changes in the sprint once started. Unlike XP, which enables the introduction of
new features. These features can replace a feature on which the work is yet to begin.
3. XP works on strictly high priority, unlike Scrum.