Part 3 of 3 on “Becoming Cloud Native: What to do when your public sector organization WASN’T born in the cloud”.
In the third and final of a 3-video overview which is specifically focused on addressing the unique cloud and automation goals and challenges of state/local agencies as well as higher education, Red Hat Inc. systems integrator partner Level Up Technology covers Pro Tips 11 and 12, in which Chief Architect Daniel Goosen walks through a typical Ansible proof of concept as well as outlining how Level Up ensures success in Red Hat product-based professional services engagements using Agile/Scrum methodologies.
PRO TIPS (11 & 12):
11.) Ansible POC Overview
12.) Engagement Overview
11. RED HAT ANSIBLE POC OVERVIEW
Step 1: Identify the Key Roles for POC Success (see also: https://www.cio.com/article/2395825/project-management-how-to-design-a-successful-raci-project-plan.html)
Responsible: Typically anyone tasked with executing any plans, changes or verifying expected results.
Accountable: Level Up Architect.
Consulted: Typically all key stakeholders who will be approving all plans, changes and results.
Informed: Typically any other internal customers or teams who should be aware of the POC, but do not need to approve changes or results.
Step 2: Identify the Best POC Use Case -Provisioning -Configuration Management -Application Development -Continuous Delivery -Security Automation -Orchestration
Step 3: Execute the POC (3-Day Onsite Continuous Delivery Use Case Example)
Day 1: Work with main technical point(s) of contact -Discovery -Design -Tower Installation
Day 2: Invite Dev and Infra teams to learn and collaborate -Add Your First App Workloads -2-4 Hour Ansible Tower Workshop
Day 3: Bring all sponsors, stakeholders together to review outcomes -Optimize -Retrospective -Begin planning next steps
Note: Longer POC’s will typically focus on additional app workloads.
*Ansible Tower Workshop*
-Title: “Ansible Tower 101” -Audience: Dev, Infra, other teams -Formats: L&L or Half-Day -Learning in your (pre-prod) environments -(Public cloud lab environment can be provided in lieu of client environment upon request) -The use case and attendees will ultimately drive the training delivery
12. ENGAGEMENT OVERVIEW *Engagement Framework Overview* -Level Up generally organizes engagements around four (4) basic phases.
-The Discovery phase is the starting point with new clients. Discovery is generally not repeated within the same client organization business unit in less than 2 years.
-The Design and Implementation phases are required for each engagement. The Implementation phase is generally done across one or more 2-week sprints. Scheduling of Implementation phase sprints may or may not be consecutive– upon the client’s request and Level Up resource availability.
-The Support phase is optional but recommended following each engagement.
*Engagement Framework Phases – Key deliverables
* Discovery: Sprint Backlog (User Stories) Design: All Design Views and Prototypes Implementation: Code, Self-Service endpoints, Documentation Support: Scheduled (feature requests) and on-demand (SLA-based support)
*An Overview of Agile*
(see also: http://agilemanifesto.org/)
*Upfront Assumptions*
1.) Your requirements may change over time.
2.) Daily progress reports are better than waiting until the very end to show you everything we did.
3.) Communication is key.
4.) Your processes, your tools, your rules.
*Why Work in Sprints?*
(see also: https://www.scrum.org/)
-Genuinely welcomes changing requirements -Promotes a culture of collective commitment -Enables the team to be largely self organizing -2-week sprints mean shorter release cycles for faster feedback
*Who’s Involved With Each Sprint?*
-Product Owner +Helps the team understand the requirements, should have the authority to decide what features the team builds. (Typically someone on your leadership team)
-Scrum Master +A servant leader who helps the team understand and execute the sprint. (This is usually the Level Up lead architect.)
-Team Member (Optional) +(Often composed of other Level Up consultants. May also include your internal team members.)
*What Happens During Each Sprint?*
-The Sprint Itself -Sprint Planning Session: 2 hrs/sprint
-Daily Standup: 15 min/day– the team shares with each other: “Yesterday, Today, Blockers”
-Sprint Review: 1 hr/sprint, the team demos what was “Done” for the Product Owner and any other stakeholders
-Sprint Retrospective: 1.5 hr/sprint, the dev team uses this to determine what went well and what they can do better next sprint
SUBSCRIBE to our YouTube channel to get more info on all things cloud native!