Agile for IT infrastructure projects

Thank you Anca. As I expected you describe a phased delivery rather than a 'real' Agile project. Agile means adapting to changes in scope based on feedback from users. Incremental delivery is used since 1950s as an alternative to planned approach for software projects.
What I am really interested are projects were there is incremental delivery to end users and the scope changes between iterations. I will be very interested in an example of an infrastructure project that used iterative development, a major change of the previous deliverables based on feedback from end users.
Initiation, analysis, scoping, planning, execution, implementation are the phases of the planned approach, which in many cases is the best option for an infrastructure project like the one mentioned (data centre build/relocation, migration to cloud, IDAM).

An example of what I'm looking for will be changing the cloud hosting from AWS to Azure mid project, after some applications were migrated and released in production.

Hi John. Thank you for responding.
I agree that Scott is worth reading and DAD is an interesting approach. I am interested in Agil e only. Lean and Kanban are not Agile; they are quite the opposite in nature.
Many teams/organisations are introducing Lean practices, kanban is only ne of them, to put some discipline in the Agile chaos generated by the difficulty of adopting Scrum for other areas than product development.
I am in particular interested in how Agile values can be applied to infrastructure projects, where the scope is usually very well known and similar projects were implemented before.

Stelian,

Kanban and Lean are absolutely Agile methodologies, they're just not Scrum. Agile also doesn't require the scope to change or have unclear requirements - Agile just helps when those two conditions are present.

For your specific example of changing Cloud hosting platforms you could run that a couple of ways:
1) Scrum - make each app migration be an Epic and have aspects of configuration and testing be the stories that populate the backlog. If you use JIRA then a Release would comprise of x number of apps moving to the new platform. This method is preferred if you have a dedicated team.
2) Kanban - similar to scrum in that the configuration and testing steps are individual stories and a Theme or Epic would be the app but rather than running in timeboxed Sprints and Releases you only have to adhere to your ITIL Release calendar when apps are migrated. This method should work better if you don't have a dedicated team.
3) Modified Lean/Iterative - In test, migrate one app over to the new platform and document along the way what things need to be tweaked and that documentation populates your backlog/checklist for other apps as well as your migration plan in Prod. Depending on the types of apps (criticality) this could be the fastest way to migrate to the new platform. It can also be a jump starter to the other two methods if the team is struggling with populating the backlog because of too many unknowns. This method is not recommended if you have business or health critical apps.

Thank you for your feedback. I am not sure how much scope change between iterations can be applied in banking. When we started this process ING Bank was given to us as a reference in implementing projects in Agile. Recently I read an article saying that this was a failure on their side (without detailing this info).

Agile is not about values or principles. That is agile implementation for software if the Manifesto is following. About practices, any practice that best fit for the initiative can be used to achive Agile definition to gain into agility. As I mentioned, we are using Scrum framework then we have fill it up with the tools and techniques that best fit for our reality and environment.

Sergio, I personally agree with you but there is a whole community out there that believe that Agile started with AM and it is described by 4 values and 12 principles.
My view is that Agile is an attribute and any framework or methodology can be agile to a certain degree.

I also agree that Scrum, as the guide mentioned, can be augmented with other practices, as long as the roles and events are kept unchanged. I was looking for real examples of projects rather than an academic discussion.

Sorry John. I have to agree that we disagree on "Kanban and Lean are absolutely Agile methodologies"
Lean Six Sigma was a science when Agile was just an emerging approach. According to some practitioners Agile is a response to Lean. Kanban is just one of the many Lean practices to eliminate waste. One of the most important reasons to adopt Agile is to embrace change (see value 4 in the Agile Manifesto). In Lean the objective is to minimise or eliminate change usually by process standardisation. We can take the discussion on private if you are interested.

Thank you for your answer but it is not what I am looking for.

1. That example is not an Agile project. It is a phased approach where each application is treated as a phase of the project. There is no change based on feedback from users and there is a separate testing phase that make the whole approach a waterfall. Epic is not related to Scrum it is an XP concept.

2. Kanban has nothing similar with Scrum. It is a practice rather than a framework with defined roles, events etc. Stories, I assume that you speak about User Stories is another XP concept. ITIL is hardly an Agile framework. It is a very formal and planned approach to production release.

3. Lean, like Agile is a concept, not a methodology or a framework. Iterative delivery, not that it is the case when a whole application is migrated, is a practice used since 1950. It is used by Agile teams, usually in combination incremental delivery but is not exclusive to Agile. Iterative means that every iteration you are changing something, which again is not the case in applications migration.