Application Lifecycle Management

Application Lifecycle is everything we do to translate Customer Needs into Delivered Software.

Application Lifecycle embodies the Culture, Processes, Tools of the organisation.

As the name implies, an Application Lifecycle Management (ALM) system integrates tools for managing different aspects of the lifecycle to take advantage of the administration and management benefits that integration brings.

ALM systems come in ‘off the shelf’ variants such as HPE ALM, or custom integrations of individual tools such as JIRA and GIT

By

Scrum

Scrum is a process framework is a framework within which you can employ various processes and techniques.

It consists of roles, events, artefacts, and rules, all of which serve a specific purpose and are essential for success.

The rules of Scrum bind these together, governing their relationships and their interactions.

Scrum Theory

Scrum is founded on empirical process control theory, that asserts that knowledge comes from experience, and then making decisions based on what is known. Scrum employs an iterative, incremental approach to optimise predictability and control risk.

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Transparency

The process must be visible to those responsible for the outcome, to provide a shared understanding.

Inspection

Scrum users must frequently inspect Scrum artefacts and progress toward a Sprint Goal to detect undesirable variances.

Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, adjustment should be made as soon as possible to minimise further deviation.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

The Scrum Roles

Product Owner, the Development Team, and Scrum Master.

Scrum Teams deliver products iteratively and incrementally, maximising opportunities for feedback, and to ensure a potentially useful version of working product is always available.

The Product Owner

The Product Owner is responsible for maximising the value of the product.

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint

The Scrum Master

The Scrum Master is a servant-leader for the Scrum Team, who helps maximise the value created by the Scrum Team.

Scrum Events

The Sprint

The heart of Scrum is a Sprint, a time-box during which a usable, and potentially releasable product Increment is created.

Sprint Planning

The work to be performed in the Sprint is planned as the collaborative work of the entire Scrum Team.

Daily Scrum

The Daily Scrum is a time-boxed event for the Development Team to synchronise activities and create a plan for the next 24 hours.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

By

Agile Manifesto

The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximising the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organising teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The definitive version of ‘The Manifesto for Agile Software Development is maintained by The Agile Alliance. The manifesto is reproduced here for ease of reference.

By

Extreme Programming (XP)

Extreme Programming

Background

Goals

High Quality

Reduced Cost of Change

Principles

Embrace Change

Assume Simplicity

Activities

Listening

Designing

Coding

Testing

Values

Simplicity

We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.

Communication

Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.

Feedback

We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.

Respect

Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it’s simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.

Courage

We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes when ever they happen.

Practices

Primary

Team Environment

Sit Together
Whole Team
Informative

People

Energised
Paired

Planning

Stories
Cycles
Weekly
Quarterly
Slack

Integration

10 Minute Build
Continuous

Design

Test First
Incremental

Corollary

Customers

Real Involvement
Negotiated Scope
Pay Per Use

Deployment

Incremental
Daily

Team

Continuity
Shrinking

Code

Shared
Include Tests
Single
By