Summary of Agile Concepts from Agile Analytics Book by Ken Collier

This Agile analytics book includes practices for project planning, management and monitoring. Ensures technical excellence by the development team and effective collaboration with business customers and management stakeholders.

'Agile' word occasionally gets misused for adhoc, slipshod and lacking in discipline. Agile relies on discipline and rigour; however it is not a heavyweight or highly ceremonious process.

Agile manifesto emerged as a result of highly focussed group of motivated individuals freely sharing good ideas with one another during an effective face-to-face gathering. It probably would not have emerged without the level of trust and respect that the Agile manifesto authors had for one another.

Manifesto for agile software development

Uncovering better ways of developing software by doing it and helping others do it.

Manifesto for Agile Analytics Development

Uncovering better ways of developing data warehousing and business intelligence systems by doing it and helping others do it.

Tenets of Agility

• Just enough design
• Synchronise daily
• Timebox everything
• Colocating teams
• Attention to technical debt
• Plan to Capacity and Monitor Velocity
• Track daily progress
• Monitor story completion, Not task time

Key Characteristics of Agile Analytics

• Iterative, incremental, evolutionary
• Value-driven development
• Production Quality
• Barely sufficient processes
• Automation, automation, automation
• Collaboration
• Self-organising and self-managing teams

Envision --> Explore instead of Plan --> Do

This is Highsmith's APM framework. It is highly collaborative one that encourages frequent interaction between developers and stakeholders.

Types of Stories Prioritization

1. Value based prioritization
2. Purpose based prioritization
3. Capability based prioritization

Value based prioritization

• Complete the high-value, high-risk stories first, if the cost is justified
• Complete the high-value, low-risk stories
• Complete low-value, low-risk stories
• Avoid low-value, high-risk stories

Purpose based prioritization (Purpose alignment model)

• Prioritization is based on aligning project requirements with organizational strategy

Capability based prioritization

• For very large or complex projects with a high volume of user-stories it is often beneficial to group stories into themes or capabilities such as:

- customer profitability analysis
- operating cost analysis        

Self-Organizing Team

People are motivated by three factors (from the book Drive by Pink):

1. Autonomy : People want to have control over their work
2. Mastery : People want to get better at what they do
3. Purpose : People want to be part of something that is bigger than they are

High performing agile teams manage their own processes, techniques and outcomes; they seek to continuously improve; and they are excited about their contribution to greater good.

Self-organizing team requires:

1. Shared responsibility
2. Team working agreements
3. Honoring commitments
4. Glass-house development
5. Corporate alignment

1. Shared responsibility

• healthy team shares the sucesses, failures and challenges that occurs in the project
• effective team frequently resynchronize and revalidate their project visions, assumptions and expectations
• Self-organizing team makes a collective commitment at the start of each iteration
• when one team member fails to honor his or her commitments, the entire team shares responsibility for that failure

2. Team working agreements

• effective team collaboratively establish and commit to a set of core values and working agreements that establish the "playground rules" for the project
• core values establish the criteria for decision making and community behaviors
• working agreements are the rules established by a self-organizing team. They are set of specific guidelines and behaviors that the team establishes to be highly effective. And this should be published visibly in the team workspace

3. Honoring commitments

• team have the right to estimate the effort required to develop the desired features and they are encouraged to plan within their limited capacity
• dev team that fall short of their commitments soon loose the trust of stakeholders
• will create a pile of eleventh-hour work as in waterfall projects
• watchout for hangovers - backlog item that is scheduled into an iteration but remain unfinished at the end of every iterations
• healthy team develop processes and methods that minimize the hangovers

4. Glass-House development

• healthy agile team make extra efforts to operate in a glass house i.e. more transparent
• should provide access to work-in-progress items
• weekly status reports which conveys accomplishments, agreements, issues/risks, and other useful information

5. Corporate Alignment

• effective agile teams have a high degree of flexibility to determine the best ways to work within the boundaries of corporate governance and compliance mandates.
• effective teams posses a deep understanding of these governance and compliance guidelines so that they can satisfy the requirements as simply and efficiently as possible

Agile Modeling

An agile model is one that is minimally sufficient. It is an iterative, incremental, and evolutionary approach that calls for a repeating cycle of modeling in small increments. An agile model has following traits:

• It fulfills its purpose
• It is understandable
• It is sufficiently accurate
• It is sufficiently consistent
• It is sufficiently detailed
• It provides positive value
• It is as simple as possible

Agile modeling is the way for developers to collaborate and evolve excellent designs that meet the needs of project stakeholders. And it is the cornerstone of evolutionary design.

Agile Testing Framework

There are four key perspectives against which software and systems must be tested for overall acceptability:

1. Business acceptability
2. Product validation
3. Technical acceptability
4. System validation

The first two testing dimensions are business and user-centric and are aimed at critiquing the product. These dimensions ensure that we are building the right product.

The last two dimensions are technology and programmer centric and are aimed at reassuring developer that they are building the product right way.

-END-