Process guidance for new development team leader

Question

I've just recently taken over leadership of a small team of developers within our group. The previous Team Leader was very much into micro-management and ran the development stream in a six week waterfall approach. The developers were assigned the work items to they had to work on to the exclusion of other work. He was very controlling in that aspect. Needless to say, this didn't really meet the required objectives from the business users.

Moving forward, we want to change this work process. The applications being supported are very mature, with only small to medium feature improvements. The focus needs be much more agile in the delivery fixes/changes whilst allowing for the feature development in parallel.

Our team and environment is as follows.

Applications/Sites

• ASP.Net Websites
• SQL Server 2012 databases
• SQL Server Integration Services
• SQL Server Reporting Services
• Vendor Supplied 2-tier fat client application (has inbuilt customisation ability, all changes have to be manually migrated)
• Vendor Supplied Silverlight Web application (has inbuilt customisation ability, all changes have to be manually migrated)

Team

• 4 dedicated developers
• 1 first level support member (probably 15% dev work)
• 1 application support member (probably 30% support, 50% dev, 20% analysis)
• 1 DBA\Team Leader (probably 15% support, 60% dev, 25% analysis)
• 1 Department Manager (probably 20% dev work)

Definite Microsoft shop (mandated from head office)

• TFS 2017 (TFVC)
• All source code is in one TFS collection with no branching
• Visual Studio 2015 (planning to upgrade 2017)
• Multiple solutions/projects with some cross project dependencies
• We have control and buy-in for server setup and configuration

Current Workflow methodology

• Developers work directly against individual TFS Work Items
• No "Sprint" or Release date limitations. There would be significant resistance against this. From a business point of view, that as one of the main restrictions to the timely delivery of fixes/changes in the past.
• Management and Administration of processes needs to be very, very minimal
• Source code needs to remain on-premises (for the short term at least)
• All deployment should be as hands-off as possible (with the exception of the vendor applications)
• When an item of work is ready for next environment it should be deployed.
• Deployments into production environment requires sign off from Dev team and Business team.

Open to all suggestions on how we can best re-structure things to allow us to deliver what's required.

Cheers Phil

Answer 1

I suspect I'm late to the party, but I've survived a few similar scenarios and might have some tips for you. It sounds like your team has been over-managed and has grown hostile to process or rules in general.

1. Do not go directly to Agile and sprint based development. Consider going with Kanban, and link work items to an epic/larger context. Sometimes that context will be "break/fix" and sometimes it will be features. Linking will help you make it clearer where time is spent. Kanban is preferable because it's likely the absolute minimum process necessary to get work done - it won't require you to bludgeon your team with buzzwords, burndowns, estimates, and other distractions. It WILL allow you to limit the amount of work in progress - I suggest you start with 3-4 things per team member and try to whittle it down until you can reach a state of continous flow. Lead your standup using this kanban board.

2. Look for opportunities to incentivize smaller delivery batches, and run them through an automated testing process. Use this process to gradually improve the code base and build trust with the release managers who currently introduce friction to your delivery process, which causes an increase in change/batch size, which causes increased risks, which "validates" the need for an outside gate to production.

3. Break up monolithic repositories, then break up monolithic applications. Smaller applications again mean smaller batch sizes and reduced risk.

4. LISTEN a lot. Your team has been traumatized by a toxic manager, and you have damaged goods on your hands. If you come in too hot, you'll break trust. ESPECIALLY through the early phases of this transition, building trust and rapport are the keys to you ever getting a devops practice off the ground.

5. DO NOT switch tools simply because other people, who seem to be better at this than your team, are using them. Do I think there are better workflows than your team has? You bet! But don't switch for superstitious or personal reasons. Understand WHAT your current toolchain prevents you from achieving and make sure that the underlying concepts are understood by every single member of your team before you begin.

6. Be prepared for this to take a year or two to really turn around. You will need to apply slow, predictable, steady pressure on the organization in order to drive meaningful or longterm change.