When I was first introduced to Agile, I was thrilled. I knew it was a buzz that was starting to become popular, but haven’t worked in a proper agile process before. I learned what it was, why it was good, and how it was implemented in our company. I looked forward to working with an agile team.

But when I started I realized that it wasn’t that great. I was still learning, so I assumed the team that had already been working like that for a while knew better, and tried to catch up. But after a couple of months, I still wasn’t quite there.

We were about to start working on a new initiative that was one of the most strategic we had. I remember going on the holidays vacation and instead of relaxing and enjoying time with my family I kept thinking about how I could lead such a strategic initiative when the process didn’t work. I knew that if nothing changed we were going to fail.

I decided that prior to letting everyone know that we are not going to continue with this Agile thing I will read some more about it, and find out why people think that it is a good idea.

I’m not talking about the Agile manifesto and the general idea that you cannot plan in advance with great accuracy so you should better accept the fact that things change. I knew that, and still, it didn’t work for me. I kept reading and got to another document that explained the principles and motivation in great depth, and I immediately realized that we were not implementing many of them. 

The principles made perfect sense, and I wanted to enjoy the benefits that came with them. I talked to my engineering counterpart, who also liked the idea and realized that we were not doing it right, and adopted a new process. This time it was a great success.

Those real benefits and principles are not as common knowledge as one would think.

I see them missing primarily in two cases: first, with managers who feel – much like I did at first – that Agile is an excuse for lack of planning and commitment to outcomes, usually because they saw a bad implementation of it. And second, with teams who think agile indeed means no planning and think their managers are old school and don’t understand the new reality. 

Usually, both are wrong. There is a reason Agile was invented to begin with, and there is a need for planning nonetheless. These two don’t contradict each other, but to find your way you must first understand the real benefits that we are seeking.

As Marty Cagan explains in Transformed, a great product culture prefers principles over process. I trust you that once the principles and benefits are clear you can do your own analysis and identify gaps in the process you currently have.

Agile Company vs. Agile Development

Two weeks ago I published an article about remaining agile with non-agile stakeholders. This gap seemed to have resonated with many of you, and many people shared with me that in their company Agile is a development methodology limited to the product and technology teams.

The beauty about the benefits that I’m about to share is that they go beyond the dev teams, and if applied properly can help you get some broader support for an agile mindset. 

On the other hand, even if you can’t, and your organization is non-agile (sometimes for good reasons), you can still benefit from them even if implemented solely for product development.

In other words, even if your stakeholders are not convinced and you cannot work in full agility outwards, don’t give up on your agility inwards.

So the playbook should be:

• Implement these internally
• Use it to build trust externally
• Gradually find the balanced approach that works for everyone

Principle #1: The Best Plan, for All You Know

This is a key concept that connects  the inward front and the outward one and is important if you want to build trust.

Many teams and managers think that Agile means no planning. While teams typically love it and managers typically hate it, it’s simply not true.

Agile acknowledges that plans will change. It doesn’t mean that plans shouldn’t exist.

Planning in itself is an important way to make sure you agree on the strategy and priorities, as well as the values and principles. Planning when done right means that you agree on the problems you want to solve and the way you believe you are going to solve them.

Moving the conversation to that dimension also helps you establish that things might change. If you put everything you do in the context of which problem it needs to solve, it’s clearer that delivering that is simply a means to an end, and it could be that you release something great but it didn’t solve the problem. It could also be that after you started developing you realized that it was not going to solve the problem, and therefore it’s best to change what you are doing.

When done right, the discussion isn’t about whether or not we are changing priorities and whether or not we are agile (which could be an almost religious debate), but rather on what’s the right thing to do. It’s much easier to convince people this way, and having a plan helps the entire organization to trust you and manage their own work.

Principle #2: Assess as You Go

Once you have a plan, it’s much easier to assess if you are on track or not. 

One aspect of being on track is solely within whether or not you deliver what you said you would deliver by the time you said you would deliver it. But real agility means much more than that. It means assessing whether you still believe that the plan you defined is the right one and will get you to where you want to be, and also assessing whether your goals are still the same or not.

When you have these discussions, make sure to have them at all three levels. Think about the trust that is built if you are able to have a meaningful discussion about where you should be going and not just what you would like to do. 

With Agile, you can make the discussion about the priorities themselves and not about the fact that they change. A proper agile process will support you in making sure the change is as painless as possible for everyone involved.

Sometimes, you will understand your goal was incorrect, or maybe a closer goal seems good enough now that you are almost there.

Don’t expect everyone to understand that without saying. To help people adapt to an agile mindset you will need to repeat these time and again. Depending on the culture in your organization, you might need to avoid using the phrase Agile altogether since that would only irritate people. But can someone tell you that it’s a bad idea to assess whether or not you are on track to reaching the goals you agreed on?

Much like in the agile implementation itself, stick to principles when you communicate and not to a specific vocabulary.

Principle #3: Valuable Working Product

The obvious reasoning for this principle is that you know nothing until your product meets real users. Everything is an assumption until then, so you want that to happen as quickly as possible.

But there are other ways that having a working product can help you, even if you can’t release everything you do immediately to real users.

Having a working product, even internally, allows you to see things for yourself, which is always better than seeing them in wireframes and on paper. Note that the Agile manifesto values “ working software over comprehensive documentation”, not “released software”.

Before you go to users to get feedback, look at the product yourself and see what works and what doesn’t. Make sure the product actually delivers the value you planned for it at the beginning of the iteration.

Note though that the idea is to have a working product that can deliver value, not just pieces of the eventual software. It’s really hard to do it right and break down the full product not just to little pieces, but to little valuable pieces. But that’s where the magic happens: if something delivers value, it’s much more tempting to release it if possible and not wait any longer.

The other side of the magic happens when you apply this time and again. I’ve seen it many times: you have a grand plan and a fancy vision. You go down that path. But if done right, you might find out that it wasn’t needed. That phase 2 was good enough, or that the market wasn’t ready for the following phases. In some cases, your priorities change.

If you deliver value frequently enough (and it doesn’t have to be every two weeks for that magic to happen), everyone benefits: your customers get what they need sooner, and are not left with nothing in case your own priorities change.

You see, to be truly agile you too need to feel comfortable where things are not defined all the way. One of those things can be whether you are working in agile or not.