Answers: <p>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.</p>
  
  <ol>
  <li><p>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.  </p></li>
  <li><p>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.  </p></li>
  <li><p>Break up monolithic repositories, then break up monolithic applications.  Smaller applications again mean smaller batch sizes and reduced risk.  </p></li>
  <li><p>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.  </p></li>
  <li><p>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.  </p></li>
  <li><p>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.  </p></li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-28T02:16:22.327Z
Answers: 2017-10-28T02:16:22.327Z
Answers: esoterydactyl
Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>Our team and environment is as follows.</p>
  
  <p>Applications/Sites</p>
  
  <ul>
  <li>ASP.Net Websites</li>
  <li>SQL Server 2012 databases</li>
  <li>SQL Server Integration Services</li>
  <li>SQL Server Reporting Services</li>
  <li>Vendor Supplied 2-tier fat client application (has inbuilt customisation ability, all changes have to be manually migrated)</li>
  <li>Vendor Supplied Silverlight Web application (has inbuilt customisation ability, all changes have to be manually migrated)</li>
  </ul>
  
  <p>Team</p>
  
  <ul>
  <li>4 dedicated developers</li>
  <li>1 first level support member (probably 15% dev work)</li>
  <li>1 application support member (probably 30% support, 50% dev, 20% analysis)</li>
  <li>1 DBA\Team Leader (probably 15% support, 60% dev, 25% analysis)</li>
  <li>1 Department Manager (probably 20% dev work)</li>
  </ul>
  
  <p>Definite Microsoft shop (mandated from head office)</p>
  
  <ul>
  <li>TFS 2017 (TFVC)</li>
  <li>All source code is in one TFS collection with no branching</li>
  <li>Visual Studio 2015 (planning to upgrade 2017)</li>
  <li>Multiple solutions/projects with some cross project dependencies</li>
  <li>We have control and buy-in for server setup and configuration</li>
  </ul>
  
  <p>Current Workflow methodology</p>
  
  <ul>
  <li>Developers work directly against individual TFS Work Items</li>
  <li>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. </li>
  <li>Management and Administration of processes needs to be very, very minimal</li>
  <li>Source code needs to remain on-premises (for the short term at least)</li>
  <li>All deployment should be as hands-off as possible (with the exception of the vendor applications)</li>
  <li>When an item of work is ready for next environment it should be deployed.</li>
  <li>Deployments into production environment requires sign off from Dev team and Business team.</li>
  </ul>
  
  <p>Open to all suggestions on how we can best re-structure things to allow us to deliver what's required.</p>
  
  <p>Cheers
  Phil</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-07-17T22:29:58.460Z
Comments: You may find [this question and answer](https://devops.stackexchange.com/q/1486/2845) helpful. I am a bit concerned however by the ideas that your developers should not be protected against context switching. (`The developers were assigned the work items to they had to work on to the exclusion of other work.`) you seem to see this as an issue working against good customer service, but do your programmers view it as useful in generating quality code? Context switching [costs your business](https://goo.gl/bSEBwe) a lot and [this comic illustrates why](https://goo.gl/MCJ7mi) very aptly.
Comments: James Shewey
Comments: CC BY-SA 3.0
Comments: 2017-07-18T04:11:29.037Z
Comments: @JamesShewey Sorry, that line is shortened from what I was originally planning to post. I meant to say that they were not allowed to work on anything else other that the single item they were assigned. The approach we're taking at the moment is assigning a bunch of work to the devs, then if they need a break, there's other items that they can work on.
Comments: philcart
Tags: <deployment><continuous-delivery><methodology>
Title: Process guidance for new development team leader
UserDisplayName: philcart
ThreadText: # Process guidance for new development team leader
  
  (Asked by: username_0 on 2017-07-17)
  
  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
  
  **Tags:** deployment, continuous-delivery, methodology
  
  > **Comments:**
  > **username_1**: You may find [this question and answer](https://devops.stackexchange.com/q/1486/2845) helpful. I am a bit concerned however by the ideas that your developers should not be protected against context switching. (`The developers were assigned the work items to they had to work on to the exclusion of other work.`) you seem to see this as an issue working against good customer service, but do your programmers view it as useful in generating quality code? Context switching [costs your business](https://goo.gl/bSEBwe) a lot and [this comic illustrates why](https://goo.gl/MCJ7mi) very aptly.  
  > **username_0**: @username_1 Sorry, that line is shortened from what I was originally planning to post. I meant to say that they were not allowed to work on anything else other that the single item they were assigned. The approach we're taking at the moment is assigning a bunch of work to the devs, then if they need a break, there's other items that they can work on.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-10-28. Score: 2 | Accepted answer
  
  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.
  
  
  ---
  
  