Appropriate Structure to Manage Diverse IT Sustainment & Development Projects?

Question

I am a consulting manager leading over 25 personnel to manage the infrastructure on a Navy Base. The team is currently segmented into Scrum Teams with:

• 5 SW Devs doing bug fixes and rewriting apps
• 2-3 Cyber security personnel
• 8-9 System Admins performing IT duties and installing new apps
• 4 personnel doing Network Admin, debug & new apps and
• 5-6 providing Level 2 Help Desk perssonnel handling inputs, and making system upgrades.

As Government Contractors many of the Scrum artifacts and methods are useful in the sustainment effort well suited for Kanban. Each team uses a Product Backlog, weekly Sprint Planning and Customer demos. I enforce the weekly demos, though most teams have incomplete products, to ensure each team makes weekly commitments and we get weekly customer feedback.

Maybe Kanban boards posted to the walls or in JIRA would provide sufficient transparency and commitment. I would appreciate feedback from folks in a similiar IT support situation. I may be too much of a micro-manager.

Respectfully, Greg

Answer 1

From reading your question and the comment from Tiago Cardoso i reckon your problem isn't How to structure our organization and define agile teams in a multiple concurrent projects context? as you also have a specific structure and things seem to be working fine.

Instead, you're searching for guidance to maintain control of the project (and increase productivity) and be able to communicate that to the stakeholders. To create this sense of ownership, i suggest two things

• Use a Kanban Board, which is a tool for organizing work in progress (WIP). The work is represented on cards, post-its, plates or magnets. Each of these objects represents a working component. Objects are then organized into lists that represent the production process or product development. An example of organizing lists is "Not Started", "In Progress" and "Completed". This allows visibility about work and work progress helps also each team member feel responsible for the whole.

• If you're building an application and you're using a version control like Git, you can place the content from the master branch in a private location for them to see. Every time the branch is updated, you'll update what that content location has. If it's a web application, you can provide them also with a list of users with different permissions for the case they want to test themselves or show to loved ones (which i find to be often the case).

Answer 2

In a few of my projects, I have always struggled with weekly sprints. Unless they are precisely planned it leaves the team high and dry. Weekly sprints leave very less time span for any risk mitigation. The chances of weekly sprints missing sprint goals are high. What I have found helpful, is to have weekly client meetings to set client demo expectations (not exceeding 20 minutes) with biweekly sprints ending with client demo aligned with the expectations previously set.

It is always good to have the client added to the Jira board, this will make sure that the team gives their 100 percent.

I personally prefer KANBAN for maintenance and sustenance projects.