Last week, we took a closer look at how the Agile Software Development methodology and its concepts could be used to manage your IT estate the Evergreen IT way. Recently, we have been getting some questions about Agile in general and how to use Dashworks in that context. Since Juriba's IT Transformation and Evergreen IT Management platform is specifically designed to find the optimal path of maximum velocity to accelerate deployment in enterprise IT environments, Agile is a natural fit.
To walk through the process using an example, let's say we are migrating to the latest version of Windows 10. Since we are already late in the game, this migration has to serve as a preparation for future upgrade cycles as well and needs to be managed as tightly as possible to make repeatable and industrialized.
To follow along, it is helpful (but not required) to download the WaaS project plan. To put this process into a bigger context, check out our Ultimate Guide To Evergreen IT Management.
Generally, an Agile process has a planning, building, testing, and reviewing component before launching into the next iteration. The exact names and number of steps depend on which Agile concept you choose. The graphic below visualizes an enterprise Evergreen IT deployment process using Dashworks and the Agile methodology.
(Please note that the process described below be used for Windows 10 to Windows 10, Office 365 migrations and upgrades, hardware refreshes, application roll outs, and many other transformation projects — one at a time or in parallel.)
Most Agile projects start with a project initialization and set-up phase before launching into an iterative, looped process. Your Evergreen IT Management is no different. Before we start our reccurring upgrade cycle, we will have to go through:
Project Planning & Mobilization. To start any project you will need to create a sound business case, get stakeholder support and executive buy-in, have approval for funds and resources, and create a solid documentation framework, including the management of your scope, schedule, costs, and such. Once you have done that, you will need to mobilize your service.
Technology, Tools, and Process Design & Build. In the second step of the conception phase, we turn our attention to how we are physically going to manage the process: what technologies, tools, and processes do we currently have in place, what would they ideally look like and where is the delta, what can be adjusted, and what needs to be procured. Now you will need to build your service design team, including your technology, process, and tooling. Next, you design your platform by evaluating and documenting the current and target state of your platforms, and engineer your core image. Then you design your process: how you will manage the service itself (e.g., what are your T-30 activities or what does your post-migration process look like), the application management including app packaging and testing, how you will manage your hardware logistics, and much more. Once that is completed, you will need to design and build your supporting tooling to ensure the maximum efficiency for your rollout processes..
(For more detailed recommendations on the optimal tooling, please read our article "Tool Requirements For Optimal Windows-as-a-Service Management" or download our Buyer's Guide.)
Now that your technologies and processes are defined and your tools are set up, you are ready to enter the iterative part of the upgrade cycle. At this point, things start becoming agile. I won't go through the entire process in great detail, as we already have done so in our article How To Accelerate Windows 10 Upgrade Rollout With Dashworks.
Dashworks Analysis component. After identifying your data sources (e.g., SCCM, HR feeds, Upgrade Readiness, and others), you gather all relevant data regarding your in-scope users, applications, devices, and other relevant objects.
In the following Assessment & Rationalization phase, you go through a hardware, software, and organizational compatibility assessment before deciding which applications or hardware components can be rationalized or retired. The final assessment gives you a clear understanding of the scope involved. Undergoing this exercise every six to twelve months will not only keep your estate tightly managed, but will minimize your application and hardware spend.
Following the Microsoft-recommended deployment methodology for accelerated upgrades, Windows 10 Deployment Rings, the next step is to prepare, build, rollout, and test your upgrade for a very small group of initial testers (called Ring 0). For very large deployments, the pilot can be broken out into several increasingly broader pilots. Once the pilot is reviewed and declared successful, you are ready for broad deployment.
Depending on the number of seats you need to upgrade and the involved risks, you might want to break down your broad deployment into separate tranches that can be staggered and then run in parallel to save time. Of course, you need to have a disaster recovery plan and constantly keep track of improvement opportunities, e.g., watch the volume and type of support tickets. Equally, you may prefer a more dynamic approach, deploying the upgrades automatically as assets turn Green for migration.
Once you have completed your upgrade, you need to shut down the project in order to initiate another one. This is crucial as it presents valuable opportunities to learn, adjust, and improve — a key tenet of Agile! This can include identifying outstanding action items as well as producing high-level reports on goal vs. actual with regards to budget, resources, and timeline, as well as creating a lessons learned document that should be shared with the entire team.
Before I wrap up, I want to share with you some of my own lessons learned from helping dozens of enterprises get ready for this: