Defining ‘Agile’ with Iwona Winiarska

This is the first in a series of Agile business blogs by Iwona Winiarska, a renowned Agile Delivery Manager and Coach who we were delighted to welcome onboard at Automation Logic in January 2019.

An agile approach is an alternative to other project management methodologies such as Waterfall used for delivering projects and building products or digital services. It allows you to get user feedback and respond to the user needs as quickly and frequently as is possible.

It’s important to note that we shouldn’t talk about ‘Agile’ as a noun as it’s meaningless. We should instead use agility, agile project management or agile leadership which is associated with servant leadership and agile mindset of empowering teams, making them autonomous and being collaborative and adaptive to the changing environment. Agile leadership is exactly the opposite of a command-control approach and micromanaging teams.

Also, many people associate an agile approach with Scrum but Scrum is not the only method within the Agile umbrella. There are many other approaches like XP, DSDM which can improve your business agility.

Agile ways of working can be used for delivering software as well as non-software projects but usually, organisations use it for delivering IT projects, products and digital services. It should take into consideration an end-to-end user journey which starts with Discovery and continues through Alpha, Beta and Live phases when a solution is rolled out to a larger audience.

What it means to be agile

In business, the market is changing so rapidly that the products or services that met users needs a few years ago are obsolete today. Being agile from the organisation perspective means being adaptive to the changing environment and shifting priorities, such as technology or user needs which are becoming more demanding. Agile leadership is then about actively monitoring the environment, changing habits of the users and their motives in order to provide resources and organise them in the right direction.

Being agile also means delivering value quickly and frequently, so that users are not waiting (x) amount of time for a new product or digital service. When a new product or service is built in an iterative way, we can release the Minimum Viable Product (MVP) to our users without spending a long time thinking about the solution, doing analysis, designing it and building it running the risk that the end product may not meet the user needs. When building digital services it is crucial to understand user needs, as particular what goal they’re trying to achieve so that we can help them meet that goal and support an end-to-end user journey as opposed to the traditional way of working. The traditional way of working is a sequence process of doing extensive analysis, designing the service, building it, and handing it over to another department for testing, hoping that it’s going to deliver the expected outcome. In many cases using this method, the services we were building didn’t meet the user needs and the user experience was very poor.

On the contrary, in Agile project management, you do all the steps at the same time. For example, you find out what the user needs are, explore the problem area, then build a quick prototype and test it with the users to get their feedback. This process enables us to learn more about the user’s needs while building the service in order to minimise the risk of delivering a solution that wouldn’t meet their needs. Through ongoing user research and learning more about user needs at every phase of the service lifecycle, we use an approach: build, measure and learn to deliver what users want.

At AL we work in multi-disciplinary teams with DevOps engineers, Technical Architects, Product Managers, Agile Delivery Managers and other roles depending on a project. It helps us make sure we have all the skills needed in the team in order to deliver DevOps transformation programmes.
In addition, the multi-disciplinary teams have a representative from each discipline and they’re a self-organising team empowered to make decisions on how the DevOps transformation programme will be delivered.

In other words, we’re trying to reduce organisational silos and bring teams together so that they don’t work on their separate missions and work streams. There is no longer a large team of designers, developers and testers who build a product and project managers who write long documentation, do long-term upfront planning and create Gantt charts. This approach has proven to be inefficient in a complex, uncertain environment where changes happen often.

Differences in requirements and documentation

When using agile methods, we don’t create long documents that potentially do not match the effort put in with the value it adds to the project.

The Agile manifesto states ‘’Working software over comprehensive documentation’’ which means we value working software (*or solution) more than comprehensive documentation. This doesn’t mean that we don’t write any documents, we do. However, we prefer to ‘Show The Thing’ and demo it to the client or stakeholders rather than writing long documentation.

The challenge is that the clients often expect very detailed documentation, therefore we need to understand what exactly they need and how we can deliver it in a different way.

Usually, our clients and stakeholders need to know the project progress: if it’s still on track or if there’s any risk to it.  And agile ways of working enable us to make that happen. Although the teams don’t use the traditional way of working, we create an environment that allows everyone to be kept in the loop and updated on the progress or any changing requirements concerning the project we are delivering. In every agile team, there are agile ‘ceremonies’ which are a great platform to build collaborative working relationships, communicate feedback and show the progress on a project.  For example, we invite stakeholders to ‘show and tell’ with the whole team or teams from other departments to see what we are working on and give us feedback.

It’s really interesting to see how this practice can significantly improve collaboration among teams and with stakeholders and senior managers across the organisation. It’s one of my favourite techniques I start with when working with a new team as it’s very powerful and effortless so it’s a quick win.

Want to check out more related content? Click here