Agile Methods – Simple guide to agile methods, the different styles and practices, methods and tools and their practical application in business.
To help understand agile methods better, it is useful to understand the alternative, what we will call traditional predictive planning methods.
When we want to get something done we generally want to decide on our goal, define exactly what we want to do, develop that and then deliver it. We often try to do this as a linear process, deciding everything upfront before we design and build and achieving something as good as possible before releasing it.
These approaches are based on the assumption we can predict the solution we are building. That what is required and how we will deliver it can be pre-defined, the solution is predictable.
Predictable methods can be used when things are simple, or complicated. The what and how of the project are clear so we can take a linear, predictive approach like Waterfall.
Predictive methodologies are valuable when projects are Simple, or Complicated and the solution is agreed and certain.
These predictable approaches include the Waterfall method used in software development and other project management practices. This methodology is linear, the stages run sequentially, cascading from one stage to the next. (the original model proposed did contain feedback loops, but have invariably not been applied – see https://en.wikipedia.org/wiki/Winston_W._Royce)
Put simply, we Plan upfront, Do and complete the work, and then Evaluate at the end.
Imagine your project as a cake, each layer represents a stage in the project. With a predictive, linear, waterfall approach we eat our cake layer by layer until the project is complete.
The waterfall method assumes we have all the information upfront. This method works well if we know exactly what we are doing and how we will do it, we have a set process or procedure to follow. But if it is not clear upfront, or requirements are likely to change, this method leaves little room for change and adaptation. Instead the original project would be completed, and then a follow up project to make the necessary changes afterwards. These changes can be difficult to make if the solution has not been built in a way where it can easily be changed.
The optimist in us all likes to believe that we will get it right first time
Realistically when we are doing something we haven’t done before it will take us a few attempts at least to achieve the result we are looking for, it may be that we have to continue to revise the solution to get the benefits and value we require.
In order to achieve the best performance possible there is a cycle of practice and rehearsal that we must undertake to form the habit and allow ourselves to get used to doing things a particular way.
The more we do something the better we generally get at it, we are able to automate ourselves and even carry out tasks without any conscious effort, like driving a car or riding a bike, it becomes ‘second nature’ and easy to replicate without much effort.
Interestingly though, often the reason activities become ineffective or stuck over time is because we have gotten too habitual and not stopped to review and change our ways in order to maintain performance.
Each time we repeat the action we refine and hone it and get closer to success until we finally reach a point where we are satisfied with the result. In this sense, it’s not really failing if the result gets us closer to success and we continue to experiment until we reach a satisfactory outcome.
There is no such thing as failure if we choose to learn from it to be successful at a later date. The journey to success can feel like a game of snakes and ladders, there will be short cuts and setbacks along the way which we need to identify and respond to and we cannot predict them all. Agile provides a method to adopt a learning attitude which allows us to harness our natural ability to navigate a journey to success through reflection and learning
Agile is an adaptive method, to allow us to adapt and respond to change, agile takes the long linear process of planning, doing and evaluating and divides it into shorter smaller repeated cycles of planning, doing and evaluating.
Put simply we turn our line into a loop, this loop enables us to work iteratively. To share our work in progress early to gain feedback and create a minimum viable solution which we can then evolve and refine during later sprints.
If we take an agile approach, we eat our cake slice by slice rather than layer by layer, think of your project as a cake and tackle it by eating it in small slices.
Model the solution a little, define the way forward, build and develop a proportion of the solution and then delivery it for feedback before we decide what to do next and move through the cycle again defining activity, doing some work and then delivering this again for review and feedback and so this continues until we reach a solution that is fit for purpose.
If our work, project, solution is not viable we want to establish this as quickly as possible with the minimum of cost. Agile embraces the reality that we do not have all the answers when we start and the best solutions are developed when we can determine our actions real time as the environment evolves and changes.
Agile thinking knows the reality that a number of versions may need to be created before success is reached and it is a journey of learning that needs to be navigated and refined to find the best solution. By making changes incrementally rather than in bulk this limits the number of changes that are made at one time so that the impact of those changes can be measured and controlled.
We need to have a conscious acceptance that making mistakes is ok when we are trying to solve a problem. Understanding it will take a few attempts to get it right means we are willing to make mistakes to expand our knowledge and accelerate us towards the answer, or a better solution.
Agile works in small incremental cycles of action interleaved with time for reflection and learning. Improvement and change is embedded in day to day activity rather than as a separate activity.
Think about times when you have had to take a learning approach to a problem or challenge:
How did your first attempt at the problem/challenge you thought of differ from your second, third, fourth attempt?
The first time we do something is often very different to when we do it for the second, third and repeated times.
We often naturally take an agile approach to new challenges and problems because we have to. The only way to solve the problem, to meet the challenge, is to try, learn and persevere, and pivot when we find a better way. The second, third, fourth attempt is often much easier as we have a much better sense of what we are trying to achieve through our initial experience, which then helps us to work out how more easily on following attempts.
We call each cycle of work, or slice of our cake, a Sprint : a short timebox of activity. Usually a week is too short and a month too long, so many teams settle on sprints of 2-3 weeks. The length of a sprint is defined by the team. Ideally sprint lengths should stay as consistent as possible, however sometimes it maybe necessary to shorten or lengthen a sprint.
Sprint cycles are what enable us to respond quickly to changes in our project, or work. Because each cycle contains planning and reflection we are able to identify opportunities and challenges early and throughout:
When thinking about your project, rather than think of it as one long marathon, of planning, then building, then evaluating, think of it lots of short sprints. At the end of each sprint we release our work in progress, an increment of our solution, sharing our work for feedback we can review and learn from and use to plan, adjust and refine our next sprint of work.
When we run a project or develop something like a Marathon, the user, customer, stakeholders may not get sight of the solution until the very end, when very little can be done to change things.
As time passes things are likely to change, internally and externally that impact the solution, if we don’t account for these changes throughout then we may end up with a solution that is not fit for purpose, requiring large amounts of rework, extra time, budget and resources.
Releasing our work in progress early can feel counter intuitive, it’s valuable because it enables us to get feed-in earlier, therefore enabling us to build a better product in the long run.
If you are adopting agile methods in your team, book a 30 minute session below to discuss how we can help,.