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.

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.

Agile Team Performance

Basic Information about AGILE  Team Performance

Agile Team Space
Collocated Teams
Collocated vs Distributed teams
Osmotic communication

Team Space

Teams are important in Agile and therefore, the space where they work is important too. Team Space, also known as ‘War Room’, refers to the environment in which the team performs their everyday work. Team space also has other names such as ‘team room’, ‘project room’, or ‘delivery room’.
Establishing a team space involves gathering an entire team in one room. Agile emphasizes a number of important factors to improve the effectiveness of team space that foster communication and motivation, leading to higher productivity.


Signs of Bad Team Space

Bad team spaces can lead to chaotic and unproductive team output. Often, lack of communication is cited as the single biggest cause of project failure.

As depicted on the image, some signs of bad team space are:

Minimal or poor interaction among the team members
Seating arrangement by job description
Stale artifacts on the walls
Team members wearing headphones
More focus on the furniture layout than on creating team space
Lack of information radiators in the workspace
Unattractive spaces

The focus should be on reducing distractions to avoid communication gaps, thereby consistently delivering the predicted outcome and value.

Co-Located Teams

Co-located teams work together in the same physical location. Each team will have all the skills required. Collaboration and coordination is easier in the co-located teams. However, usually, co-located team would be independent and be able to work on its own.
The image depicts a co-located team in Location A.


Distributed Teams

In Distributed teams, the team members work in geographically dispersed locations. Some of the characteristics of these teams are:
Individuals in different cities work together as one team.
Each location has people with different skills. This reduces the need to collaborate across geographies or time zones.
In case the co-located team does not have all the required skills needed for a project, distributed teams can be used to fill such gaps.
It is cost-effective to leverage distributed teams.

Co-Located vs. Distributed Teams

One of the myths around Agile is that it only works on co-located teams. Agile can work on both distributed and co-located teams. A co-located team is an advantage regardless of the methodology, because it makes coordination and collaboration easier. An Agile team, like any other team, can work around these difficulties and make the methodology work even on a distributed team.
The differences between the co-located teams and distributed teams are listed here.

In co-located teams:

The team members are seated together in a room, creating a “war room”
Issues are resolved informally in a timely manner
Incidental interaction leads to productivity
Team decides the roles to adopt based on sprint goals
They follow ‘Caves and Commons’ pattern:
Caves—For phone calls, short meetings, or for team members to concentrate
Commons—Open, shared workspaces for the team where osmotic communication occurs

In distributed teams:

Teams are distributed geographically
Formal logging of knowledge occurs
Structured use of processes is ensured
Explicit role definition is done via tasks
Exploit technology for collaboration
Use live video conferencing
Use group chat Instant Messaging
When sending mail, choose the recipient, and CC the rest of the team
Have forums or corporate information hubs

Osmotic Communication

Osmotic Communication refers to the information that is overheard in the background of the team room and some of it is absorbed. It is one of the benefits of having co-located team.
As depicted in the image, there are no impediments that impact the flow of information across the work area. Therefore, in such environment, osmotic communication happens naturally.

Collaboration and Coordination

Collaboration and coordination are required for a project.
Collaboration is the process of bringing together the knowledge, experience, and skills of multiple team members to contribute to the development of a new product. It requires some level of coordination between the team. The act of collaboration enables the team to achieve potentially a lot more than the “sum of the parts”. Coordination is the act of sharing information among the team members. Collaboration and coordination requires some level of interaction.
A few guidelines for using the interaction modes to foster greater collaboration and coordination are as follows:

Understand and make use of the various interaction modes that are available. For example, e-mail, instant messaging, video conferencing, and in-person meeting.
Match the interaction mode with collaboration practices. For example, brainstorming may require an in-person meeting, whereas a status update can be done by e-mail or conference call.
Use lower-cost interaction methods as much as possible.
Highly effective methods must be used for critical, higher-risk activities.

Source: Contribution from RAVEENDRAN RANGANAYAGALU

AGILE Team Performance

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.

Agile Myths

Agile Myths:      Some myths about Agile are debunked

All of the below are false

Not for operations
Not for regulatory projects
Not for Mainframe projects
Not for all projects
Not for BIG projects
Only for techies
Scope Creep
Lack of control
High risk
No discipline
No design
No planning
No architect needed
No documentation
No estimation
NO PM's needed

Distributed Agile!-   How do we do this distributed
1. Agreements
2. Standards
3. Tools
4. Processes

7 Rules of successfully distributed teams

1. Don't
2. Don't treat remotes as if they were locals
3.  Dont treat locals as if they were remote
4. Latitude hurts, longitude kills
5. Don't always be remote
6. Invest in the appropriate tools and environments
7. Establish standards and agreements


The DNA of success
1. Agile exposes capability gaps
2. Awesome Capability
3. Attitude
4. Aptitude

Agile helps create a great working culture

You don't want a toxic brilliant team not a happy dud one!
High performing teams are happy and highly capable!


Agile Pitfalls

1. Environment
    Wrong physical environment
    Lack of proper tools
    Funnel not managed - too much WIP
    Resources splintered and working on multiple projects

2.  Leadership
    Leaders don't walk the talk
    Wrong leadership style - command and control instead of servant leadership
    Lack of a clear shared purpose and strategy
    Lack of trust

3. Knowledge
    Lack of training or inaccurate material
    Teams don't know what Agile really is
    Leaders not trained and aware
    Lack of sharing
    No access to coaching
4. Capability
    Poor core capability
    Lack of capable Agile PMs and IMs
    Lack of critical thinking for problem solving
    Can't do attitude

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

Why change? Why Agile?

1. Happy people
2. Reduced risk and cost
3. Faster time to market
4. Improved quality
5. Increased Revenue
6. Happy customers

Increased Profitability and happy shareholders

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

7 Key impacts of going Agile

Resource allocation
Team structure
Work environment
Work prioritization
Leadership style
Making time to collaborate
Authentic Transparency

Agile Program Pattern & Agile Operations Pattern

Agile Program Pattern

Program pattern used to launch and execute programs and projects

Strategy

1.  Idea
    Strategic initiative
    New requirement
    Enhancement
    Problem
    Opportunity
2.  Discover
    Understand and strategize
3.  Deliver
    Governance
    Funding Gates
    Iteratively build
    Test and Deliver

Again goes back to the 5 phases
1. Mobilize
2. Understand
3. Explore/ Strategize
4. Build/ Test/ Implement (Prototype)
5. Manage/ Evolve


Leaders to evaluate and check the funnel management
Write a 'discovery brief'

Program Pattern - used to launch and execute programs and projects

Discovery Pattern:
1. Problem
2. Desired Outcome
3. Blockers
4. Epics
5. Solution Strategy
6. Estimate
7. Plan
8. Cost/ benefit

Collaborate to Elaborate
Iterate until done
Identify the cone of uncertainity-  Discovery or Delivery

Estimate- Solution Strategy - Epics  (Iterate till done)
Demand is always more than supply..so it is very important for proper funnel management


************************************
Agile Operations Pattern

Agile lifecycle of delivery
1. Discovery
2. Discovery (Optional)
3. Deliver (R1)-  Release or Phases

leads to
Iteration 0 -  is the set up iteration
Iteration 1 - Work
Iteration 2....n

At Start of Iteration
1. Iteration Planning
2. Daily standups
3. Work
4. Showcase
5. Retrospective (At the end of iteration)

Scrum

Inputs -  From customers, team, managers, execs
> Product Owner
> Product backlog -  A priortized list of what is required, features, bugs to fix
> Team -  Sprint Planning meeting
- The team commits to as much high priority backlog as can be completed by the end of the sprint
> Sprint Backlog (Task breakout)
> Scrum Master
> 1-4 week Sprint (Sprint end date and deliverable do not change
> Daily Stand up meeting (15-30 minutes)
Sprint Review
> Finished Product (product increment)
> Sprint Retrospective

The Operations pattern used to effectively run and optimize any business process

The Business Canvas includes
1. VSM Practice (as-is)
2. Customer
3. prod services
4. process
5. People
6. Inputs/ Outputs
7. Metrics

Test Hypothisis for Agile Projects and
Manage / Evolve - Roll-out to all areas and evolve in Agile Project

Agile Strategy

Agile as a way of working can be used everywhere...in HR, Managements, Projects, Sales etc

Across any business process:

Core Processes

Applying agile as a way of working at all levels
Used in project work and Operations work

Three Patterns

1. Strategy and Governance pattern
2. Program Execution Pattern
3. Operation Execution Pattern

Each pattern follows Five phases

1. Mobilize
2. Understand
3. Explore/ Strategize
4. Build/ Test/ Implement
5. Manage/ Evolve

The patterns interchange and rework as needed on iterations.

Managing the funnel helps tune strategy

1. Learn and adapt strategies
2.  Planning cycles become small
3.  Iterations after iterations for completion of work


Strategy Pattern :  Used to craft and execute organizational strategy
1. Strategy formulation
2. Strategy Execution

1.  Where are we now?
    Business model canvas
    Existing strategy
    Business metrics
    Work in progress
    Market Factors
    Current problems
    Root cause analysis
    SWOT
2.  Where do we want to be?
    Vision (Distant mountains)
    Mission (Purpose)
    Objective (Hills)
    BHAG (Big heavy ambitious Goal)
    SMART goals
3.  How did we get there?
    Design workshops
    Top 3-5 blockers to achieving the goals
    Foundational beliefts
    Strategic options
    Strategic choices
    Strategic initiatives
4.  What do we need to do?
    High level time line
    Short term (next 3 months) top 3 priorities
    Budget- Strategy alignment
5.  How do we execute?
    Strategic pipeline
    Start-Stop- Continue
    Integrated WIP
    Strategy Modality


Iterate through all levels down
Collaborate to Elaborate

Business Canvas:  The business model canvas

1. Key Partners
2. Key Activities
3. Key Resources
4. Value proposition
5. Customer Relationships
6. Channels
7. Customer Segments
8. Cost Structure
9. Revenue Streams

Created by 450 people from 45 countries ...

Using Agile Practices to 'Cascade' Strategy
1. Group Level
    Vision/ Mission
    Objectives/ Goals
    Strategy
    Plan
2. Business Unit/ Profit Centre Level
3. Support functions - HR/Finance/ Legal etc

Source:  IBM Agile Academy

Agile for Leaders

Agile for leaders

What leaders have to do to enable, promote and support an Agile way of working-
and to ensure that teams are 'doing the right work'.

Challenges of today

1. Too  much work
2. Pressure to deliver
3. Stressed and/or disengaged teams
4.  Missed targets
5. Sub optimal results

''Growth is controlled not by the total of resources available but by the scarcest resource'' -  Dr. Liebig

''Every Organization has at any given point in time at least one constraint which limits the system's performance relative to its goal''- Dr. Eliyahu M.Goldratt
You can only deliver as fast as the slowest part of your process

Little's Law

Increase throughput by demand and production leveling

Work in progress (Reduce WIP)/ Average Completion rate (Increase completion time)= Total Cycle time (Managing the on-ramp / remove constraints/  Don't overburden

Minimize WIP-   Backlog, In Progress and Done

Switching loss-  productivity reduces when focus is shifted in multi tasking

Doing the right work:
1. Mission and Value
2. Strategic initiatives
3. Objectives and Goals
4. Manage the funnel of work
5. Visualize the work in progress
6. Program Delivery practices/ Strategic practices and Operations Practices
7. small, stable cross functional teams

Work and team structure fundamentals:

1. Small batch size
2. Single prioritized funnel of work
3. Pull work to match WIP limit
4. Small, stable cross functional team
5. Multiple teams are loosely coupled and tightly aligned

Work:  enhancements, new project work, bug fixes, 3rd line support
PM  - Product Owner
Team :  IM, BA, Designer, Customer SME, Dev, Tester, Cross functional core team

Work smarter than harder!  To do more and have fun while doing it..it gets better


Customer-facing, end to end teams, as far as possible

1. Front end/ Bankend infrastruture
2. Analysts/ Designers/Developers/ Testers/ Compliance
3. Content Designers, Actuaries and Delivery support

Loosely coupled, tightly aligned!


Leaders or Managers:-

Organizing a group of people to achieve a common goal - Definition of leadership - wikipedia

1.  Clarity of purpose -   clear strategy
2.  Inspire purpose -  Mission, Vision and Goals
3.  Strategy is about choice.  Best choice comes with colloboration

Set up for Success:
1. Structure teams
    Right Resources/  Right Place and Right time
2.  Small and empowered teams
3.  Optimize value flow
    Remove bottlenecks
    Eliminate Waste
4. Leaders -visit the teams, see the walls and visualize the value stream mapping
5. Stop watermellon projects-  Green outside and Red inside.
6. Govern for greatness
    Doing the work right
    People management and guidance
7.  Drive innovation
    Sharing/ Learning / Innovate/ Improving
    Create exciting work environment

Summarizing Agile leadership
1. Inspire purpose
2. Set up for success
3. Optimize value flow
4. Govern for greatness
5. Innovation

Source:  IBM Agile Academy

Agile Principles, Values and Behaviours & Practices

1. Begin with clarity about the outcome and let it guide every step along the way
2. Listen, iterate, learn and course correct rather than wait until its perfect
3. Encourage self direction for teams to unleash innovation, instead of concentrating leadership in the hands of a select few

• Focus on the customer and business value
• Iterative and Fast
• Flexible, adaptive and continuously improving
• Collaboration and teamwork
• Empowered and self directed teams
• Don't control too much
• Cant hold it total tight or too loose, and lose on innovation
• Leadership is in the hands of everyone

Foundation Belief's and Values

1. Respect
2. Openness
3. Trust
4. Courage
5. Culture


Values are the values we walk past-   Australian General
Absence of trust leads to invulnerability
Fear of conflict -  Artificial harmony
Lack of commitment - Ambiguity
Avoidance of accountability - low standards
Inattention to results -  Status and Ego

Agile/ Lean/ DevOps/ Design thinking based on
1. Agile Practices
2. Agile Principles
3. Agile Values

leads to change in behaviors

1.  Do a standup
2. Retrospect

*********************************************
Agile Practices
-  an overview of some core agile practices, as well as the Japanese learning concept of Shuhari

Source:
Phil Abernathy -  Agile transformation coach

1. Social contract
team gets together - write short sticky notes on the acceptable and unacceptable behaviors of the team, that we go to live by
Social contract is owned by the entire team/  everyone is accountable
Gives the flavour of the culture, and changes needed
Penalties if you break the social contract
2. Scale of expectations
worst thing that you can give someone you love is trust
Trust is a box of expectations
Talk about the expectations to each other, be clear
what can you do and what you cant do
3.  Mood marbles
Red one's and Green One's-  Put the marble based on the mood in a jar
based on the color in the jar, we identify the mood of the team
Keep it simple...Agile is about simplicity
4. Stand up
Talking to the issue and not the person
Identify solutions for any problems or any blockers
Ask if you can help, tremendously supportive in agile
5. Retrospective
little action - 3 pieces of the emoticons on the board..
what is working well
what is not working well
I don't understand
-  Group the issues based on the 3 questions

As time, how are we going to fix the issue as a team
In the next iteration
In the next cycle

6.  Set of measures
a. Discovery +VSM
b. story cards
c. Wall of work
d. Showcase
e. Burn - up charts
f. Issue Bulls Eye
g. stand-up
h. Risk matrix

Practise name-  Scale of Expectations

More Blame-worthy towards More Praise-worty

1.  Deviance - deliberate violation of selfish purpose
2.  Inattention -  Inadvertent deviation
3.  Process in adequacy -  Faulty process
4.  Uncertainty- Lack of clarity
5.  Hypothesis Testing - Experimentation for the good of the company
Sanctions  leads to Rewards....


Failures are the way we learn
Fail fast is the new way of learning and recover
Intention should be good
Put up the prioritized list on the portfolio wall
Change the wall and columns of the notes - based on the situations
Visualize the process, the work and everyone to understand what is going on

Release plan -  has Release wall and Iteration Wall
Plan - Develop- Test-  deliver
Visualize the trends and mood marbles..to understand the team work


The practices are like a buffet-  laid out to allow people to pick what suits them.
These practices ensure behavior is aligned to the values and principles
1.  Leadership Practices

Agile strategy pattern
Portfolio walls
Backlog prioritization
social contract
Kanban Board
Team environment
Team rotations
Leader Smashes

2.  Collaboration Practices

Agile discovery practice
Stand ups
Retrospective
Showcases
Backlog grooming
Planning Poker
Team of teams
Design thinking practices

3. Delivery Practices

Agile Program/ Operations Patters
Automated Test-driven development
Burn down chart
Continuous integration and deployment
Design thinking practices
Dev-ops practices
Story cards
Value stream mapping


Documentation:
We don't use documentation to achieve shared understanding
We document shared understanding
Agile takes a lot of emphasis away from documentation.
It even gets the incorrect reputation that it is anti-documentation that doesn't provide value
More importantly, Agile recognizes that documentation isn't the best way to gain a shared understanding


In Agile, we talk, we converse and then we document the understanding

The Japanese concept of Shu-Ha-Ri

If you can make a curry, but cant make French pastry and someone asks you to make French pastry, what do you do?

You find the recipe, buy the ingredients and follow the recipe
You don't decide, without understanding the recipe, to boil the pastry instead of baking it in the over as instructed

It's the same with Agile or any new way of working.  In order to learn, we must follow the process as described.
Then once we have practiced it is a couple of times, we can adapt the receipe to make it better and finally when we are well
practiced and experienced, we can write our own recipe

Shu-  Follow
Ha-  Break
Ri-  Transcend


Source:  IBM Agile Academy

Introduction to Agile Principles and Human Values

Agile Challenges-  Does anyone have a pencil?   

Principals of Agile

• measure the process
• thinking
• practiced
• borrowing brilliance
• learn and watch
• focused on outcome
• listen and discuss
• agreement on the process
• self directed
• self adjusted
• Teams wisdom to do the things together
• wisdom of crowd to get best solutions
• show leadership by anyone in agile
• leadership can be a first follower
• all forms of leadership-  shared leadership
• observed
• between the iterations, evaluated results
• How can I get better?
• Iterated
• ideas bounce in the group and innovation happens
• having fun at work as well

Human values showed to each other
1. Respect
2. Trust
3. Courage - mother of all values
4. challenge processes and procedures
5. evaluate what helps or stops in getting better?
6. Openness and transparency

Agile - set of human values, practice at home and same values practiced at work

Agile Principles and Human values make Agile possible

Set of practices- behavior changes -  live the values- that becomes a habit and culture

Keep practices makes possible innovations

Create a great place to work and great culture


Source:   https://agileacademy.mybluemix.net

Agile Way of Requirements Management

Need for Agile Concepts

1. Shifting from the traditional way of software development
2. Avoid huge cost of poor or misplaced requirements
3. Stop creating artifacts that mean nothing to the project in reality
4. Make recommendations on solutions during requirements
5. Optimum Utilization of all available resources with iterative approach
6. Create requirements that are on priority first
7. Cost advantage balanced with technology availability
8.  Managing reasources spread across the globe
9.  Avoiding wastage of time, efforts and resources
10. Do only what is good enough!

Agile Principles in Requirements Management - as defined by Forrester Research

1. Be Lean

Add Value, Eliminate Waste, Fit-to-Purpose

2. Iterate

Breakdown Work products,  Progressive Definition, Just Enough!

3. Use Pictures

Less Text and more visualization, flow charts, wireframes and prototypes

4. Collaborate

Team Orientation, Business and IT coordination and Trust.

5.  Accept Change

Anticipate, Accept, Involve and  Proactive Management


Challenge is

Having the experience of having handled requirements that need huge documentation and process effort, and also having practised the Agile way of handling requirements in a more leaner, progressive development, interim user reviews, fixed and simple templates, change control and collobrate multi-cultural, multi-regional teams, I find doing the second one, makes not only better sense, but also a practical approach going forward.  But the challenge is to make this a practice and people at large accepting the framework.   This provokes a change in the Organizational DNA having the traditional ways of handling software delivery.