Agile Project Management and Methodology
The Agile Approach
At Quvex we approach our projects with the Agile project management and development approach which allows us to deliver quality on time and allows the client to enjoy full visibility of our progress throughout the project's lifecycle.
The concepts of release and iteration allow the project team to get the right mix of feedback, frequent delivery, reasonable planning time horizons, and protection from changes.
Traditional project management approaches are not well placed to work in the fast paced and dynamic world of web development and do not offer tangible results until much later into the process. Traditionally project management methodologies are task based. This means that the user is often forced into grouping these tasks into phases. The end result is that the product itself does not take shape until well into the project so we would usually have to establish a substitute measure to provide stakeholders with an idea of how the project is progressing like percentage of tasks completed.
Our agile approach allows us to deliver value to the stakeholder as it is available which can be as often as every 1 or 2 weeks (one iteration or sprint). This gives stakeholders a much better idea of the state of the project because you can see and use the end results as soon they are available.
We have detailed some of our core agile methodologies below:
1. Pre-production environment
The pre-production environment serves as a location to try out newly developed software in order to provide feedback to our development team members. The development team can also use the pre-production environment to test the integration of all of the software intended for delivery to the production environment in the next release.
The preference is to release running tested features to end users as quickly as possible and the team seeks feedback, which influences our planning in future iterations, and could lead us to evaluate our release plan.
A feature may be planned for delivery in a different release based on better understanding of the need for the feature or a better picture of how the team is progressing.
2. Feature-based planning
Instead of organising work based on the tasks to be completed (for example, analysis, design, development, deployment, testing, and implementation) our agile planning organises work based on feature delivery.
The team determines which features will be delivered in which release, and identifies when those release points occur. This focus on feature delivery instead of task completion assures that the team is paying attention to the truly important information, when they will be providing value-producing features to the business, rather than to when tasks are completed.
3. Performance tracking
Tracking performance to the feature based plan through keeping a close eye on completed features also provides a more reliable and understandable measure of progress for all of the stakeholders than task completion.
Having a picture of how many and which features have been completed and are being used or are ready for use is much more meaningful to product owners, stakeholders, and users than an understanding of what tasks are completed.
4. Iterative planning
Our agile planning organises work into 1-6 week periods called iterations or sprints. During those iterations, all of the necessary work to take features from an idea to a working product is completed, without artificial dependencies that prevent work from being done in parallel.
The end result is that portions of the product are delivered on a regular, frequent basis, giving stakeholders a much better idea of the state of the project because they can see and use the end result as it becomes available.
5. Team planning
The team is responsible for our agile planning, so they are the ones that work with you to decide which features to deliver in a release, and in each iteration, and what tasks are necessary to successfully deliver the planned functionality in the upcoming iteration.
A preliminary part of this process has been started by the team in order to estimate your project schedule and cost however another session(s) will be required to complete the planning phase.
Once the features and tasks are identified, the team members self-select the tasks that they will complete and update the status accordingly. Our team is responsible for these because, as the people who are doing the work, they are best positioned to know what needs to be done.
6. User stories
We use user stories as a way of capturing requirements and features. This would be conducted with the project team including project stakeholders in order to get a well thought out feature that provides value to the project.
The format for the user story is as follows:
AS A [User Type]
I WANT [Functionality, Feature, Characteristic]
SO THAT [Value provided]
AS A [User Type]
This portion of the requirements statement provides context to the requirement by describing who will actually use the functionality. To make this portion of the requirement as meaningful as possible, we define a list of user types in the form of personas, so they will be as consistent across requirements as possible.
I WANT [Functionality, Feature, Characteristic]
This is the portion of the format that mirrors the traditional "The System Shall" or "The Solution Shall" statements that are used so often in requirements lists. Prefacing the statement with "I Want" focuses more on what the user is hoping to accomplish using the solution, instead of specifying what the system should do. This may seem like a subtle difference, but it keeps solution design options open by focusing on desired outcomes rather than descriptions of an approach.
SO THAT [Value Provided]
This portion of the statement answers the question "Why?" and is often the part that is missing from typical requirements statements. We will describe the anticipated value the user will receive from being able to use the expected functionality.
7. Personas
We use personas which can be imaginary representations of the real users or a sample of the real users to enable us to consider the users of the application, their personality, needs and wants. We will detail name, age, gender, professional and personal roles, families and friends, hobbies, education and major challenges for example. We then use this to identify specific kinds of concerns and options that may not have been apparent without.
8. Planning at different levels of detail
It is completely reasonable to expect the team to be able to identify what they will be doing at a relatively detailed level for the next 2 weeks. Outside of that time frame, things become less clear because of changing business conditions, learning from the previous work, changes in the team, etc.
Our team practice agile planning at 3 levels: Release Planning, Iteration Planning, and Daily Planning.
Release planning identifies which functionality the team is planning to deliver for the next several iterations. Often this is based on the prioritised feature list and the number of features that a team can produce in an iteration, which we referred to as velocity.
For the most current iteration, out team performs detailed planning when they identify the tasks needed to deliver the planned features.
This multi-level planning provides our team an opportunity to adjust our approach to account for changes in priorities, changes in the team, and better approaches and techniques learned during previous iterations.
9. Release planning
Release planning starts with our team identifying the features they wish to deliver in the project and we use user stories to create the feature list based on functionality needed to support a particular business process.
The feature list can be added to and subtracted from as the project proceeds, based on better understanding the of the problem the project is trying to solve, the business process it is trying to solve, or the product that is being built.
Once the feature list has been established, the team then sets about prioritising the feature list based on relative value delivered by each feature.
Features on the list are ordered in decreasing order of relative value; features producing the most value are placed are the top of the list.
Adjustments to feature order are made based on technical considerations, such as moving some lower value producing features up the list if their completion will provide information useful for other features and moving high value producing features down if they are reliant upon features that are contained lower on the list.
Our team determines the appropriate feature release points, which dictate the length of a release. Feature release points are those times when features are released into a production environment for use by the ultimate end user.
10. Team velocity
Our team's velocity is the number of features that we can complete within an iteration. We use the measure of story points per iteration as a measure of our velocity.
Story points are the units of measure of feature size that we use to quantify relative cost of features. We also use our velocity to determine how many features can be completed within an iteration.
Then, based on how many iterations are included in a release, we can identify the features that will most likely be delivered within a particular release.
11. Iteration planning
The iteration is the point where the list of features is converted into actual work to do. This takes place in an iteration planning meeting, which can be divided into two parts.
In the first part, we work together to determine what features should be tackled in the iteration. One approach that successfully balances the priorities of the business and the capacity of the team without requiring a great deal of extraneous estimating and analysis is Commitment-based.
We find this approach is effective for a variety of reasons. The team members themselves are making the commitment to complete certain features, so they are more likely to live to those commitments than when they have commitments thrust upon them. Also, the team is continuously evaluating their workload as a whole, rather than as a collection of separate items.
The tendency when evaluating work in isolated bits is to ignore the small little pieces that are quickly adding up into a very large list of things to do.
Once the team has determined the features to deliver in an iteration, we then determine what tasks are required to realise those features.
This is the first time the team determines the relevant tasks involved in realising a particular feature, allowing us to incorporate the most current information about design approach, process, risks, assumptions, and constraints.
Using this approach allows the team to identify patterns in various features, allowing them to learn from previous features and apply those approaches to their current list of features.
12. Daily planning (Standup/SCRUM)
We have a daily stand-up meeting, or SCRUM, which is the crux of daily planning. The stand-up meeting is a short gathering of 15 minutes max in which we coordinate our activities for the day. We do this by discussing three main points:
1. Progress - "What did I do yesterday?"
2. Plans - "What am I going to do today?"
3. Problems - "What is getting in my way?"
The daily SCRUM is of course not the only time when the team coordinates. In fact we are coordinating and planning almost constantly which is the benefit of our agile approach. The team needs a specific time to get together and discuss where they are at, where they are going, and what seems to be in the way.
The daily layer and the iteration layer of planning are the only places where task status is tracked. At every other point, the means of progress measurement is feature completion. The daily and iteration levels provide a reasonable place to check on task status because the time periods are short enough that tasks are meaningful divisions of work.