Agile - Extreme Programming

Extreme Programming

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.

Five Core Principles of XP

Extreme programming 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.

XP Practices
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.

Agile - Crystal Methodology

Crystal Methodology
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.

Crystal Methodology—Key Principles

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—Key Categories

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.

Basic Information about AGILE

Dynamic Systems Development Method

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.

Principles of DSDM Atern

As listed, 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 reassess 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.


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 delivery of the solution developed.

Agile Project Management

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.
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.

Feature Driven Development

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.

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.



Lean Software Development

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.







Kanban

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 Kanban board 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.

Introduction to Agile Leadership

According to the Forbes Magazine, “Leadership is a process of social influence, which maximizes
the efforts of others, towards the achievement of a goal.”  Leadership is being thought of here as
“doing the right thing”.

The discipline of Agile leadership encompasses other disciplines like Leadership theory,
traditional project management, and Agile methods. The illustration also indicates some of the well-known traits of leadership that include servant leadership, empowerment, and
risk management. It is recommended to take a thorough look at the image and understand the
different facets of leadership.

Agile leadership encompasses other disciplines, such as:
Servant Leadership
Modeling the way
Empowering the team
Visioning, and
Risk Management

Note that the Agile leadership is essential to guide the team through the Team Formation stages.


Leadership Best Practices

The best practices followed by a successful Agile leader are as follows:
 Model desired behavior: A leader should follow the four most highly valued characteristics of a leader: Honesty, forward-looking, competency, and inspiring.
Create and communicate a vision: A Leader should define clear goal or a vision for the future in accordance with the organizational goals.
Enable others to act: A leader should foster collaboration by building trust, and strengthen others by sharing power.
Challenge the status quo: A leader should search for innovative ways to change, grow, and improve by experimenting and taking risks.
Involve the right people and encourage them: A leader should recognize contributions of the team and appreciate individual excellence.

Adaptive Leadership

Adaptive leadership is a practical leadership framework that helps individuals and organizations
adapt and thrive in challenging environments.

‘Inspect’ and ‘Adapt’ are the two common themes in Agile project management. Agile leadership can accelerate and sustain organizational agility.

Adaptive leadership has the following two aspects:

1. Doing Agile drives the organization towards gaining agility not just in project management, but also at strategic and business levels.
2. Being Agile requires leaders to be adaptive; inclusive, exploring, and adopt facilitative leadership style.

Adaptive Leadership—’Doing Agile’ Tools

Agile leaders should use the following execution levers to achieve the business goals of responsiveness, agility, profitability, market share, and customer satisfaction.

Quality: It is managing technical debt which, if not addressed correctly, leads to high cost and risk.
Doing less: The project teams should do the simplest thing possible that delights the customer.

Engage or Inspire: Agile leadership should encourage and promote the concept of self-organizing teams that have autonomy, mastery, and purpose.

Speed-to-value: The three components of the Agile triangle, such as quality, value, and constraints, need to be managed properly to realize business value.

Management vs. Leadership

An Agile leader has to embrace the Agile principles of being flexible and adaptable, and also motivate others to follow it. Management and leadership are often believed to be synonymous with each other,
but they are not.

The differences between the focus of management and that of leadership are as follows:

Management focuses on tasks or things, leadership focuses on people.
Management focuses on control, leadership focuses on empowerment.
Management focuses on efficiency, leadership focuses on effectiveness.
Management focuses on doing things right, leadership focuses on doing the right things.
Management focuses on speed, leadership focuses on direction, and
Management focuses on practices, leadership focuses on principles.

AGILE Coaching and Mentoring within Teams

Coaching and Mentoring Within Teams

In the context of Agile, guiding a team involves a dual approach of Coaching and Mentoring. Each aspect has its own focus and skill set to nurture the team and deliver results.

A coach helps the team members to accomplish specific tasks and goals. Coaching is about aligning the individual’s goals with the organization’s goals and helping the person to reach the next level.

A mentor shares the Agile experiences and ideas to guide the team members to grow and develop.

Agile Coaching

Agile coaching can be done by an internal or external coach. The coach has to:

Maintain a balanced perspective while working with different teams. Each team progresses at a different pace and may face constraints and impediments that require help to overcome.
Stay true to the team members’ values.
Understand the social and psychological aspects, as well as the complexity of the team.
Use an approach that makes sense to people, and address the problems faced by the team.
Develop methods for designing non-intrusive interventions for changing team dynamics, and
Learn what is really needed to get people to work as a team.

Coaching at Levels

The focus of coaching changes at different points in a sprint or iteration:

At the beginning of the sprint, the focus is on the team
In the middle of the sprint, the focus is on the individual, and,
Towards the end of the sprint and at the time of release, the focus shifts again to the team.

Skills of an Agile Coach

The three primary skills that an Agile coach must possess are ability to work with people, facilitate change, and use systems thinking.

Ability to work with people includes listening to the team and stakeholders; giving feedback; asking clarifying questions; and building trust and rapport with the team.
Ability to facilitate change includes enlisting support from the team and other stakeholders; reaching agreement about the changes needed; implementing the changes; and learning from failure to drive change in the right direction.
Ability to use systems thinking includes being able to see the “big picture”; identifying the levers for change such as, what can really help in bringing about the change; and communicating danger signals.

AGILE Team Performance & Motivation

Agile Team Motivation
Maslow's Theory
Herzberg's Theory
McClelland's Theory

Agile Team Motivation

One of the Agile principles states, “Build the team around motivated individuals; give them the support and encouragement they need.”
An Agile leader needs to motivate the team. Some of the well-known motivation theories are:

Abraham Maslow's Hierarchy of Human Needs
Motivational Factors by Boehm
Frederick Herzberg's Two-Factor Theory
David McClelland’s Achievement Motivation Theory

Agile Team Motivation—Maslow’s Theory

Abraham Maslow's ‘Hierarchy of Human Needs’ is depicted as a five level pyramid.
The four lower levels represent the most fundamental needs, called ‘Deficiency needs’ or ‘D-needs.’ The fifth level is self-actualization, where people reach their full potential.
Maslow indicates that the lower level needs have to be satisfied before one can move to the higher level needs.

Agile Team Motivation—Frederick Herzberg’s Theory

Frederick Herzberg established a theory based on the two factors, Motivators and Hygiene factors.
Motivators are those factors that give immense satisfaction, arising from intrinsic conditions of the job, such as recognition, achievement, or personal growth. Examples of Motivators are challenging work, recognition, and responsibility.
Hygiene factors are necessary, but do not give motivation; although the absence of these will result in dissatisfaction. Examples of Hygiene factors are status, job security, salary, fringe benefits, and work conditions.
An Agile project team requires hygiene factors to establish a minimal level of team performance. Also, motivators determine if the team can achieve high performance.

Agile Team Motivation—McClelland’s Theory

David McClelland's ‘Achievement Motivation’ theory is based on ‘Maslow’s Hierarchy of Needs’ theory. McClelland’s theory describes three types of dominant motivators, which are Achievement, Affiliation, and Authority or Power.
People with ‘Achievement’ motivators are characterized by the following traits –

A strong need to set and accomplish challenging goals.
Willing to take calculated risks to accomplish goals.
Likes to receive regular feedback on progress and achievements.
Often likes to work alone.

People with ‘Affiliation’ motivators are characterized by the following traits –

They want to belong in the group.
They want to be liked, and will often go along with what the rest of the group wants to do.
They favor collaboration over competition.
They do not like high risk or uncertainty.

People with ‘Power’ motivators are characterized by the following traits –


Want to control and influence others.
Like to win arguments.
Enjoy competition and winning.
Enjoy status and recognition.

NAPOWRIMO 2017: Day 24: Poems on Erotica

#UmasreeRaghunath