Agile 101. It’s not just for development teams.

And it’s not only for [insert whatever here].

Undoubtedly, we live in a digital age. And sure, rather than merely projects, we are living in a time of products. That is all accurate.

The good and the ugly of agile have all become mainstream. Agile is excellent when done well. However, when done poorly, it is terrible. A corporation may be destroyed as a result. and the reputation of Agile in the process. But that warrants its own post entirely…

We have Agile HR, Agile Marketing, Agile for Personal Agility, Agile for Hardware, and Agile for every other purpose you can think of. Frameworks, programs, and certifications follow it. So far, so good.

Returning to IT now, shall we? Usually, when we discuss Agile, we are referring to software development. It used to refer to “conventional” software applications, but today it refers to everything that uses software, including websites, mobile apps, AI, the Internet of Things, and home appliances, as well as vehicles, buildings, airplanes, and other objects.

As a reason, we frequently associate Agile with the process of implementing or creating a piece of software. And most frequently, this entails working with a small cross-functional team, a coach of some kind, and a backlog, independent of the framework or tool. And all of this is excellent. But we also frequently forget there is so much more to Agile than just support writing a piece of software (I’m intentionally oversimplifying; pardon me if this offends you). In fact, it’s easy to see that what is typically portrayed as Agile is only a small part of the picture if you stand back and consider the entire process — from the very beginning to the very end — for any sort of code.

The best way to look at this topic is to evaluate a typical product life cycle. The typical phases used to describe this are development, introduction, growth, maturity, and decline. And we see Agile as a tool we employ during the development stage. But it’s not quite that straightforward.

First off, there is always a team somewhere performing maintenance work until a product is killed off and/or removed from the market. Even after this, there may be a time when support is offered in some form. This indicates that Agile practices will likely be used. It may be anything, often with a board of sorts.

The largest fallacy is the idea that Agile begins when a team starts working on a project. But how do they decide what to develop? According to what the world of Agile states, you may not have the complete list of requirements for a product before you begin an Agile development cycle. However, you do have a vision of that product.

Let’s take it a notch higher. Imagine that your company is currently developing a number of these products. What will they create initially? And how can they tell if they are creating the best solutions if there isn’t yet a full set of requirements at the outset? I basically highlighted the holy grail of business agility in this paragraph. It takes a lot of agility for a company to match its vision with its strategic planning, portfolio management, and effective discovery practices. If you give it some serious thought, you’ll reach the same conclusions I have: Organisations usually lack proper top-to-bottom alignment; they spend in product discovery insufficiently; and all I just said won’t matter if nothing is done propely.

Finally, it should be noted that Agile is much more than teams working in tiny iterations and continuous delivery, frequently with board support (virtual or otherwise). It goes well beyond the entire Product Life Cycle (the same applies for services, projects, etc). Furthermore, it involves much more than just having a vertical organizational structure that communicates top-down strategy and goals. Agile is all of that, but only when it is done perfectly, multidirectional, with everyone’s complete commitment, alignment, and transparency.

This entails an awareness that we are only human, that the world and the market both undergo daily change, and that what we believe to be true today may not be so tomorrow. Plan accordingly, not annually, but daily. You may have a sense of purpose and direction, as you should, both personally and organizationally, but what will make you agile is shifting your focus from fixed targets, fixed requirements, and fixed milestones to high stakes objectives, measurable ways of assessing progress, a loose culture of blame, learning from mistakes (and embracing failure as a natural, human thing), growing every day, and doing all of this while believing in what you are doing.

And, as we all say, Agile is not the end, it’s the way.

Published initially here.