Agile Principles:
What is Agile?
Agile is an iterative process in which you deliver value through a solution [Cloud based software] and then enhance it over time. You deliver quickly and you deliver often. And throughout the whole process you have constant communication and interaction with your customer to ensure he is happy with every product release.
Agile is also:
- A Project Management Methodology.
- A way of delivering products and services faster.
- A culture based on structured rituals and principles
Agile Values
Why Agile is great for Cloud Project Delivery!
SPEED TO MARKET
Agile lets you get your concept to your users as quickly as possible. During every sprint an agile project delivers something of value. At any point, you may determine you want to launch what has been delivered and start building a user base or testing your hypothesis.
FLEXIBILITY
Agile is based on accommodating change. and you heard it here first…
Cloud projects consistently change.
As a cloud product functionality is introduced, internal business processes change, integration points grow, new customer markets require niche functionality [ to be customised in the PaaS cloud] – your company or professional services organisation should be able to react and update the product accordingly. Agile also realises that great ideas manifest any time during a project [ usually near the end] and being locked into a scope doesn’t let you take advantage of these innovative ideas.
RISK MANAGEMENT
Incremental releases means that the product can be used early in the process by stakeholders and users. This lets you identify issues and feature deficits early in the process. Being adaptable to change means it isn’t a problem to change the scope midway through the project, something that would be impossible in a waterfall style project.
COST CONTROL
Unlike a fixed budget project, agile is flexible with regard to scope. More often than not, our clients realise features they originally requested are no longer necessary. This allows them to launch sooner and pay less. Agile isn’t about paying a lot with uncertainty, it’s about:
Paying for only what you need.
Need to stick within a budget? No problem! We can rearrange the product backlog so that critical new features are implemented at the expense of less important features, not your budget.
QUALITY
Agile integrates testing throughout the cloud migration/implementation/development/testing/handover process. Consistently delivering tested software means higher overall quality and less time spent on “quality assurance testing” the full application.
RIGHT PRODUCT
Incremental releases let you test your Cloud solution early and often. Even if you don’t release it to the public, it’s much easier to locate flaws and things that can be improved when you have an actual product to play with vs a series of designs.
TRANSPARENCY
Agile lets you see, feel and use a project consistently throughout the project. You don’t see things in compartmentalized silos; you see how things work together.
Our Agile Lifecycle Approach
The Agile Cloud Delivery Lifecycle!
There are many different flavours of Agile [We prefer SCRUM, SaFE or KANBAN]. Ultimately, it is up to your team to come up with the best process for you. Generally they all follow a short life cycle, which repeats during each iteration. This article focuses on Scrum, but many of the features are universal.
Scrum projects are broken down into short iterations (generally 1 – 3 weeks) called sprints. The lifecycle of each sprint includes:
The Agile Lifecycle for a Cloud Project
Kickoff and Sprint Planning
Each scrum project begins with a kick-off meeting. The first meeting is generally the most extensive as the initial project backlog needs to be created and the project team introduced. Additionally, before each of the future sprints there is a sprint planning meeting.
First, the kick-off meeting. The kick-off meeting’s goals are:
- Overview of the project and the goals.
- Who will be working on the project – Roles and Responsibilities
- Determining the point person for client sign-off.
- Creating the project backlog.
- Determining which features to work on.
- Getting on the same page in terms of expectations, timelines, deliverables, scope
Project Backlog
Behind every project is a project backlog – which is a list of all the product features generally defined by “user stories”. User stories define everything potential users want to do on the site.
They are defined for each of the user groups on the site and are structured like:
- AS A [type of user],
- I WANT TO [do this thing],
- SO THAT I CAN [accomplish this goal].
There are many tools to keep track of your project backlog, both analog [Blackboard, Post-It notes, Excel/Word/Powerpoint docs – Nb cloudarchitects.net.au has a large inventory of our own customised artefacts that can be used for each customer if required.] and digital [Jira, Trello, VivifyScrum etc] options…
See here for a recent listing: Agile Software Tools
The important thing is that the backlog should always accessible and easy to track. In its most basic form it might be post-it notes on a wall. In fact, one of the best ways to create the initial project backlog is to write all of the user stories on post it notes during the kick-off meeting. Post-it notes are easy to rearrange so make a perfect analog solution to creating a backlog.
After all the user stories have listed – they are ranked in order of priority. Part of this ranking is also grouping stories together. Some stories will naturally lend themselves to being built with others, which will expedite the process.
Remember that the project backlog is always fluid and never locked in. The project lead will be in charge of reprioritising the backlog between sprints. And if new features are dreamed up or requested by users, they are encouraged to be added to the backlog. The one exception to the fluid backlog is during a sprint.
While the sprint is in session, it is important to not add features -this keeps the team focused and makes sure that the project can be properly tracked.
Feature Estimation
To be able to estimate what can get done per sprint and how long the full project will take, it is necessary to estimate how long each user story will take. Because one of the major challenges in development is accurately predicting how long things will take to get done, agile uses relative estimation.
Features are rated on a 1, 2 or 3 point scale [ or a standard that you agree on and use internally consistently]. More precise estimation is more challenging and ends up less accurate. It is easy to compare things relatively on a scale of 3. And if something is particularly challenging that you don’t think it fits within the “3 point” bucket, it should be broken down into smaller features that can each fit into the respective buckets.
There are a number of ways to handle feature estimation. It can be as simple as just talking about it or it can be slightly more complex using “planning poker”.
It’s also important to determine the sprint velocity of the team working on the project. That is how many “points” the team can complete per sprint. This velocity is averaged over time. And in typical average time value- the more sprints you do, the estimates and velocity become more and more accurate. That is to say that in some sprints you may not hit your goal number and other sprints you may exceed it. Over the course of a standard project, this averages out.
The Sprint
Agile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
They can be as short as a few days and generally are no longer than 3 – 4 weeks.
We typically work in 1 – 3 week sprints depending on the extent of the overall project. During a sprint there is a dedicated team that includes designers, architects, developers and business people working together.
Before each sprint, there is a sprint planning meeting (often combined with the sprint review meeting). This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added and the sprint goals don’t change. The only exception to this is if the team finishes a sprint early. Client communication is generally limited to the daily standup results, but some firms allow for an open dialog via a chatroom.
The Daily StandUp:
Every morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project. Everyone stands up for the meeting to keep everyone focused and to keep the meeting short. Often a timer is set so that the meeting does not run long.
Each person on the team is tasked to answer 3 simple questions:
What did you do yesterday?
What are you going to do today?
Do you need any help or are there any blockers in the way?
These three questions allow for complete transparency. Everyone on the team is in the loop, and the answers make people accountable for what they say they will deliver. The results of this meeting are typically shared with the client. This daily communication makes sure that if something is holding up the team, they can get a response quickly.
Sprint Review Meeting
At the end of every sprint something of value is produced. Something that theoretically could be launched. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.
The sprint review always starts with a functional demo. A conversation then takes place on how it can be improved and if there needs to be any reprioritising of the project backlog. Then the team collectively plans out the next sprint.