You don’t need to have iterative and incremental development practices, or even a project, to be Agile. Don’t focus on what the Agile frameworks say, focus on what is the best way. Iterative and incremental don’t always make sense – Agile doesn’t actually require iterative and incremental.

Even the Agile Manifesto does not state iterative and incremental development is required – the closest thing it states, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” (Agile Manifesto: Principles). That could imply incremental delivery, but it doesn’t have to be that way. I think the intent is more to create inspection points for the current product. (Be Adaptive, Not Necessarily Iterative and Incremental)

To be Agile, you must:

1. Practice Emergent Leadership

I think one important part is the emergent leadership that should develop. Defer to the leadership of the people below you. you don’t need to be in strict control. Get the team involved in decision making. Don’t tell them how to do things, let them tell you how they are going to do it. Only guide and help fill in the gaps. (Emergent Leadership Origins: Complexity Theory and What Most People Forget About Agile)

2. Be Transparent

Work to keep things as transparent as possible. Establish as many openly visual systems as you can with a constant stream of readily available reports. When managers want a report, you can send it to them easily – but you can also direct them to the location of your reporting system so they can view it whenever they want.

This also means that you should try to not misrepresent the current state of things to customers and leaders. Your project is having issues, don’t tell your customer everything is fine. It can be a hard thing to do. You may find you falter on that and your very normal reaction is to display confidence that all is under control. Fight against that.

3. Be Collaborative

Push and encourage collaboration among the team. But being collaborative also means more than that. It means recognizing when you don’t have the skill needed and (transparency) admitting it.

One downside of corporate projects is they often have strict time reporting requirements to projects. I know this helps with accounting and who to charge and what someone gets paid, but it can also create situations where people on different projects strictly adhere to time requirements and thus don’t communicate with each other. There is sometimes value in having multiple projects with multiple skilled people who communicate and cross-work with each other.

4. Focus on What You Need

Focus on what you need to do now. Make sure you have those details. Note any possible future red flags but don’t obsess over them until you need to.

In some cases though, project output is pretty clear and there is a low chance of future change. In those cases, plan to the level of detail you need. Waterfall planning isn’t bad or anti-agile, there can certainly be value in it – risk reduction for one if you are sure the project isn’t going to change drastically by the time it is completed.

5. Avoid Limiting Options for the Sake of Agility

The only thing that is really anti-agile is limiting your options for the sake of adhering to some sort of Agile framework or a belief that Agile “Must” be done a certain way. You need to pick the best path. Sometimes that path is a series of events defined in a process, and sometimes the answer is less clear. Just because Scrum says you should do something, doesn’t mean you have to do it.

6. Learn and Share

Learn something new. Learn a new skill, enhance or relearn old skills. Share that learning with others.

Learn about your own work. Spend time reflecting on your past work. Look for the work you did well and the work you could improve on. Find improvement areas and actually work to improve, implementing continuous improvement practices.

Agnostic Agile:

I seek to uphold the following principles, to the best of my ability and judgment:

1. To put my customer first, making them independent.
2. To do my best, complementing theory with practical experience.
3. To tailor agility to context.
4. To understand hindering constraints and work to remove them.
5. To share, learn and improve.
6. To respect frameworks and their practitioners.
7. To acknowledge unknowns and seek help.
8. To never mislead and to never misrepresent.
9. To remember that agility is not the end goal.
10. To acknowledge that dogmatism is non-agile.
11. To recognise that there is more to agile than agile.
12. To give to the community as it has given to me.

https://agnosticagile.org/