OK, that was Agile - so what's next?

What prompted me to write this blog, is that I seem to be finding companies, or specific individuals within those companies, saying that Agile does not work. As a result, this creates resistance in the organisation to try it and often results in a half-hearted attempt – or worse used as an excuse not to change. I'm worried that with these bad experiences, Agile may go the same way of other past methods that have "gone out of fashion" and get replaced by the next silver-bullet. 

Has anyone heard of this new approach called Waterfall that is going to solve all our problems? (wait a few more years, and this could be the case 🙂 ).

I use a range of best-practices, methodologies, and frameworks (BPMFs), one of which is Agile applied as Scrum. Note: I don't claim to be an expert in Agile and Scrum; however, I do have experience in applying Agile principles, often in conjunction with other BPMFs, in "not-just-software" product companies. These companies do more than just develop software products and incrementally add features. They have a physical or hardware element as well, i.e. electronic devices etc. You may have heard the phrase "Hardware is Hard" which I discussed in a previous blog.

In this blog, I'm putting forward a number of possible causes for this perception. The points I make here apply to other BPMFs -- if you do not understand them or do not implement them properly, there's a risk that they will not work "as advertised".

Agile is not a Silver Bullet

Agile is not the right solution for all problems -- there are certain situations where Agile works well. However, there are other situations where Agile doe not work so well, so alternatives should be considered.

What I have found works best is a hybrid approach that combines Agile with a number of other BPMFs that are well-integrated. As part of working with my customers, I develop their The <insert name of customer> Way, which is their way of working including the BPMFs that suit their type of company, industry and maturity (which will change over time).

Context is Important

Scrum is most prominently used for software development, which it is ideally suited for. The reason for this is to do with the nature of software development and how it can be delivered and updated incrementally. At the end of an iteration (a sprint in Scrum), a new feature or version of the software is delivered -- because the software is essentially lines of code; a new version of the software is created by just changing one line and a new version of the software can be created in the blink of an eye.

So for the not-just-software companies, I work with developing physical products, it's simply not possible to deliver a new product/feature in such a short period of time, e.g., change to the electronics or mechanical parts of the product. Admittedly this is improving with the adoption of high-quality 3D printing, although many of these products can have a software component that can be updated quickly, as long as it doesn't require a change to the physical hardware.

Rather than thinking, you need to deliver a product version or feature in each iteration, you focus on delivering value ("deliver value early and often"). Value doesn't necessarily need to be the product/feature, but other forms of value such as building knowledge or mitigating risk. While making a change to the electronics or mechanical parts of the product cannot be done in one iteration, there are valuable aspects that you can do in each iteration. This can include sending the updated hardware design to a partner for review, a 3D printing a mechanical part for testing, both of which deliver value in terms of developing knowledge and reducing risk.

I am currently working with companies who use Agile outside of product development teams. This includes sales, marketing and customer support teams. What Agile looks like in those teams is different in certain ways than what it looks like in a product development team.

It comes down to understanding the principles of Agile in order for it to add value.

No Cutting-Corners or Cherry-Picking

Agile is made up of a number of interdependent principles. The risk is that if you don't understand those principles and simply cherry-pick what you want, leaving out parts and modifying the remainder, you are losing many of the benefits. And you may be worse than when you started. For example, one of the core principles of Agile is having a regular cadence, which in Scrum are called sprints, e.g: each sprint is 2-weeks and the length doesn't change. This impacts many parts of Agile in terms of getting the team working efficiently ("in the zone") and being able to accurately estimate what can get completed in a sprint. If the sprints start becoming variable lengths, then you will lose most of those benefits.

Agile is Simple to Understand, but Difficult to Master

A colleague of mine introduced me to this phrase when I was learning about Agile, and I am constantly reminded of it. The beauty of Agile is that it is simple, making it easy to understand. But to really understand the principles and be able to apply them effectively, it takes practice.

Unfortunately, because it appears to be simple, people assume that it's going to be easy for the team to learn and use, expecting that all of the problems will be solved. People try to imitate what it looks like and then wonder why it doesn't work.

This is recognised in Agile and there is a key role of the Agile Coach (or sometimes called the Scrum Master). This person, as the name suggests, coaches the team in the adoption and use of Agile. I have found that the most effective way to learn and adopt Agile is by building experience in using it, supported by a coach.

In addition, continuous improvement is baked into Scrum - for every iteration, the team performs a retrospective to identify what parts of the process are working well (i.e.: keep doing them!) and what parts are not working. The team can then propose an alternative approach and can then try it out in the next iteration, by what point they will find our whether that alternative approach works.

Note: The Agile Coach/Scrum Master and the retrospectives don't just exist while the team is learning Agile - they continue and this is a key part of the adaptive nature of Agile is that the process can adapt when things change. As they say, "the only constant is change!".

Roles not defined in Scrum

One of the disadvantages of Scrum is that it has such a short timeframe, e.g: one or two sprints into the future. In the context of software that is fine -- software features can be delivered incrementally in a short period of time. Things change so quickly that if you plan any further into the future, you are going to be wrong anyway! 

But in the "not-just-software world", it can take 6 -12 months to deliver the product and there are other considerations to factor such as; manufacturing and supply chain that must be planned and timelines met to ensure everything comes together at the right time. So longer-term planning and the role of a Project Manager is important.

It's not all about the Tool!

For those of you that know me or have worked with me, tools are often a part of the work I do with companies and I have written blogs on them. However, I still see a lot of companies that think that all they need to do to solve their problems, or change the way they are working, is to install a tool. A good example of this is Jira, which is a market leader in supporting Agile practices (Kanban and Scrum). So companies install it and then tell the teams to start using it.

Hopefully from this blog you are recognising there's a lot to Agile to get it to work effectively. The best way to learn Agile and understand it is using physical index cards, sharpie pens, post-it notes and a whiteboard/ This stops the tools getting in the way, there is something magical about the tactile nature of writing cards and sticking them on the board. Once the team is up and running with Agile, they can then transition to digital tools.

Summary

If you are in an organisation that is struggling to make Agile work "as advertised", or you are thinking of applying Scrum in your organisation but are getting resistance to it, this blog will give you some things to think about.

If there is just one thought you come away with as a result of reading this blog, is that there's a lot more to make it successful than you imagined. But please don't think it's all just too hard, because then you will miss out on all the benefits if you do it properly.

What is critical is if you don't have the experience internally (ie, someone that has implemented Scrum in a number of organisations), then try and find someone outside. 

If this is something you think your organisation could benefit, then feel free to reach out.