Somehow it is always a challenge to bridge the gap between what technology can do and what end users are actually using everyday even very technical teams. Development methodologies have been evolving from waterfall to Agile, Scrum, and Kanban; Microsoft’s Team Foundation Server (TFS) has been catching up with the trend by providing some very nice features; Teams are trained and working toward implementing with better methodologies and tools. However, levels of involvement, preferences of practices, and determination of the teams all vary between them. In summary, both vertical processes and horizontal components are not the same across the board. How can we implement it with TFS and still able to produce rolling-up common reports?
On the other hand, flexibility is the management’s big concern when adapting the new processes and tools. For business processing, the teams should have the freedom to pick either Scrum or Kanban for their projects and/or day-to-day support works when practicing them with TFS. Of course, in addition to the above, other consideration also being raised, including:
- One big team project with smaller teams or multiple separated projects?
- Separate permission between board access and source code access
- Restricted work items visibility (including queries) between teams (even under the same team project)
- Only development teams can have source code access
- Only use AD groups (not TFS groups) to manage source code access
- Only board Admin can customize the board
- Capture how unexpected work requests impact the planned delivery
- Capture estimated and worked hours for both Scrum and Kanban
- Capture work (activity) types for both PBIs and Tasks
- Color code blocked work items but leave their Kanban state current for easier to resume the work
- Multiple Technologies: platforms; languages; database engines; vendor applications; in-house development
- Different build and deploy methodologies: compiled and un-compiled code; direct and hand-over deployments; semi-auto and manual deployments; delta and whole system deployments
- Inconsistent release processes: Scheduled and on-demanded; formal release and patches
First, we inventory what we have by listing the custom fields, columns, states, and reports from current boards to see if anything standing out with good reasons. Then we used those templates and analysis to talk to other potential users to get more consensus. A committee was formed to be accounted for both technical feasibility and business requirements. The committee kicked the project off with some official group meetings and other one-on-one information exchanging meets. Knowing the current pain and wish lists of managers from various levels is very important at this stage. We also projected some milestones and high-level goals as well.
Iteration 1 – MVP
A Proof-Of-Concept (POC) project template along with some mockup reports are made to moving forward. Some concepts are based behind the scene for this Minimum Viable Product (MVP):
- Single big team project for all teams – same template, easier maintenance
- Leave existing team projects including boards and source code the current places – Easy implementation with less impact (this is more of an ALM process restructure than source code reorganizing).
- Use custom common TFS states for common reporting and leave the flexibility of customizable board columns to the teams.
- Make custom fields optional to accommodate different tracking needs
- Create links between TFS and external ticketing systems to maintain the linkage between service requests for auditing purpose
- Tracking both points and hours initially to gather more realistic samples for future iterations
- Use the same organizational structure (Manager-Supervisor-Team Lead)
- Use a pull-down custom field to capture unplanned work
- Combine both Scrum and Kanban data to a consolidated dashboard
- Aggregate different management levels data to roll-up and drill-down reports
- Provide practice-specific reports to support both Scrum (Burndown, burnup, etc.) and Kanban (Kanban state analysis, Lead Time, Cycle Time, etc.)
Pilot teams were identified, setup, and run in Development environment. Some questions, suggestions, additional requests, and decision points were raised during the piloting period and working sessions. Before the official Go/No-Go meeting, we had some more sub-group meet-ups to address the concerns and ideas with team leaders and sometimes his/her team members. In addition to some technical integration points, we also gather more training related needs for audiences from various technical and process levels.
- Provide training materials (self-study) and sessions
- Define templates and processes for requesting a new board
- Roll out one at a time
- Line up teams
- Develop reports
- Power Pivot w/ Excel
- Power BI
When working with managements (even development teams) about a new technology, things could get lost very easily. It could be a real challenge to maintain the flow of technical development in between those countless meetings. However, the beauty of use technology to solve business problems all reside in those back-and-forth business needs. After all, We are practicing Agile to implement other teams’ Agile practice. The confusion between ambiguous business processes and what the tools can automate and integrate for you always comes up again and again in those discussion. Microsoft has been doing a good job upkeep the industry trends by providing and improving more and more cool functionalities with TFS. Those features look convincing and always excite end users. But the road of implementing them to a corporation can get tricky and time consuming sometimes.