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.
- 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)
- 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.