Skip to content
Matthew Hall edited this page Jun 22, 2018 · 47 revisions

[DRAFT] A Guided Approach for Agile Development Teams

Purpose

The purpose of the this wiki is not to recreate the many good sources of documentation on the various aspects of Agile development. Rather it is meant to answer the many questions that a new Agile Development team will have as the make the transition from doing traditional waterfall projects over to an agile approach.

Team self assessment questions
Frequently Ask Questions
Background Material
Features of this Guide
Behavioural Changes

Behavioural Changes

This guide should support your efforts to:

  • Improve the maturity of your team in Continuous Service Improvement
  • Speed up the time for on-boarding new team members
  • Enable the team to achieve the desired the level of discipline
  • Make transparent the approach for implementing Agile Development projects
  • Support the hypothesis and experimentation to evolve the approach for implementing your agile project

Maturity Framework

Maturity Framework

For the Organization as well as the Product team. Separate assessment of the maturity will help.

Level 3 Advanced 2 Mature 1 Evolving 0 Basic -1 :(
Backlog
User Focus
Transparency
Inspection
Adaptation
Culture
DevOps
Planning
Review
Lean

Conduct Service Design

Purpose

To research the user journey towards a given outcome, examining both digital and non-digital touch points.
Please review to the BC Government Service Design website: <www.gov.bc.ca/servicedesign/>
Outputs from these activities may be used to work on a digital service or do a Lean start-up. Service-Design

Behavioural Insights

There are trained staff who can assist in conduct specific behavioural research to identify opportunities to improve services through various behavioural modification techniques and monitor the improvements.

Conduct a Lean startup project

Purpose

Use this activity as a guide for lean product design, definition of success metrics, conduct the first few iterations of your product development, and determine the "go/no-go" exit points. Lean-Start-Up.JPG

Lean Product Design

Success Metrics

  • Behavioural Insights Findings
  • Continuous Improvement Target (nudges)
  • Metrics for measuring success
  • Analytics

First Iterations

  • Scrum Team Building
  • Scrum Sprints
  • Produce an MVP / Highest Value Delivery
  • Plan your releases / epics

Go/No-Go Planning

  • Events the allow you to pivot and refocus
  • Decide early to stop building the wrong thing

Outcome

To define the business opportunity and quickly produce something of value

Tools

  • 5S Plan,
  • Paper or digital mockups
  • User Stories
  • Journey Map
  • Personas
  • Research Plan
  • Scrum Ceremonies
  • Product Backlog
  • Issue Tracker
  • Project Principles
  • Product Roadmap

Project Sponsorship

Purpose:

  • Garnering project support
  • Project funding
  • Form the Agile team

Agile DevOps Processes and Tools

Purpose: Artefacts:

  • Establish Team Collaboration channels (e.g. Slack channel on https://devopspathfinder.gov.bc.ca)
  • Set up Documentation Repository (e.g. Public: Github Wiki on your code repository, Private: Confluence, SharePoint)

Determine the initial architecture

Purpose:
Artefacts:

Architecture Strategy

Continuous Integration and Continuous Deployment

Purpose: Prepare a Development Environment that supports CI/CD

CI/CD Features

Feature Notes
Merging Pull Requests a github webhook notifies jenkins of a commit
Code Compilation oc build is called by jenkins
Integration Tests code written that is run during the build phase of the deployment pipeline
Deployment oc deploy called after the built image is tagged
Functional Tests each test scenario template will be run, each having many test permutations
Code Testing Coverage Report will show what lines of code the tests are activating
Code Complexity Analysis an assessment of the code
Code Security Scan displays bugs and errors to be adressed
Data Model Inspection shows reports of the tables, columns, relationships, constraints

Deployment Pipeline Tools

Tool Purpose and Usage
Jira or Trello Manage Product Backlog and Task completion status
Github, Git or Stash, Bitbucket Manage Source Code, documentation of code changes
Jenkins Control the pipeline flow
BDD Stack Functional Testing
Gradlew or Maven Builds the software
Sonarqube Scans code for various testing purposes like test coverage, code complexity or code quality
Schema Spy Graphical inspection of the physical database as implemented

Estimate

Purpose

  • To refine the Roadmap timelines
  • Be able to report on changes to Scope and/or Budget
  • Understand the definition of done

Tools

  • Backlog of User Stories with story points
  • An initial range estimate of team velocity
  • Burn down chart using the gross and net velocity to give a date range

Construction Iterations

Design

Purpose

Each feature needs to be visually and technical designed so that you can collect early feedback from users and adapt to their needs.

Development

Purpose

Features that will provide value to users are broken down into small user stories, coded, documented and reviewed in order to ensure that the team is delivering high quality working software.

Integration

Purpose

Developed software is continuously integrated with the rest of the system using automated testing, static code analysis, and functional testing.

Deployment

Purpose

Features are deployed as soon as they are done to Production to get rapid user feedback. If the Product Owner doesn't want a feature to be made available to users, the code is still deployed to Production with the feature toggled off.

Construction Tools

  • Behavior Driven Development
  • Low Fidelity Mockups for rapid user feedback and design
  • Description of the Data, logical data model
  • High Fidelity Mockups to clarify the Definition of Done for a feature
  • Data Model Development (Spreadsheet for logical model)
  • Behavior Driven Development (BDD) Scenarios, (Tests)
  • Automated Code Generation
    • CRUD operations for all data objects
    • API to calls on the CRUD operations
    • Physical Database Models
  • Custom API Specification & System Functions development
  • Automated Integration Tests (ensure that APIs function)
  • Functional Tests

Retirement (It's not what you think!)

Purpose

To find redundant, duplicate, or low value features of the system that based on user research should be retired.

This may result in the retirement of an entire system, however that is not the ideal situation. A system that is retired in its entirety likely had many features that could have been removed previously.

Instead try regularly adapting to users needs and frequently retire the features that users no longer value. This strategy keeps your system as focused as possible on the high value effort and will extend its life by allow teams to spend time ensuring that it stays secure and functional.

How is it done?

  • Talk to real users and get their feedback
  • Use website analytics to monitor the usage of product features,
  • Collect and resolve bugs & defects quickly to ensure that those features continues to provide value to the users.
  • Once that feature reaches a point where it is shown for various reasons to no longer provide value, then that feature can be retired.
  • The retirement phase should be ongoing from the moment you build your first mock up.

A feature having lots of bugs and defects should not be the reason you retire a feature. Sometimes your features just need a little care and feeding.

Reference Materials:

  1. Agile-Resources