If a Development Team doesn't have the skills or tools to create a “Done" increment, are there techniques that can be used immediately that will allow progress on the increment to be easier to track? I am thinking the team could immediately use TDD, ATDD, or implement a physical board to visualize work.
What else might improve the team's ability to complete work?
Transparency of the process is the result of practices and artifacts that create visibility, and leverage the inspect-and-adapt cycles of the framework. However, transparency and visibility will not intrinsically help the team complete an increment. For that, you will need to identify the process issues that are getting in the way. This ongoing process improvement work applies the principles of emergent design to your workflow, and is essential to effective agile adoption.
If your team is routinely struggling to complete an increment, that's often a sign of poor estimation and scope management. The following practices can help you surface the problems and allow the team to start adapting its processes to resolve them.
Manage scope with a Sprint Goal.
Ensuring the team has a clearly-defined Sprint Goal is not only required by the framework, but also helps to manage the scope of the Sprint and the complexity of the Sprint Backlog.
Manage scope of Product and Sprint Backlog Items.
Writing backlog items that meet INVEST criteria will assist with the complexity and scope of work planned for the Sprint. In particular, writing user stories that are (reasonably) independent, small, and testable will make the work more goal-driven.
Decompose Sprint Backlog Items into tasks of 1/2 to 2 days each.
The Daily Scrum is a daily coordination meeting for the Development Team, but part of its value comes from having work that's broken up into tasks of less than one day each. Long-running tasks are inherently harder to estimate and track, so decomposition is key.
Shorten your Sprints to 1-2 weeks each.
Shorter Sprints trade reduced capacity for faster inspect-and-adapt cycle times. For example, by reducing the length of each Sprint to one week, you are forced to accept less work into the time box (which often encourages swarming and pairing), focus your Sprint Goal more narrowly, and think more iteratively about the work planned for the project. It's generally better to predictably get some amount of work completed each Sprint than to routinely fail to achieve your Sprint Goal by setting your targets too high.
Reduce work-in-progress (WIP).
Reducing WIP improves flow; reduces productivity drains such as multitasking, communications overhead, and dependency-management; and improves the focus on state transitions during the Daily Scrum. It also makes it much more likely that each unit of work can meet the Definition of Done and integrated into a potentially-shippable increment before the end of the Sprint.
The list above is generally a good top-5 list on which to build additional capabilities. Unless you're already doing all the things listed above, all you'd be doing by injecting test-first practices into a process that doesn't already support or require them is adding complexity to the development process. What you actually want to do is simplify the workflow until bottlenecks and necessary process improvements become self-evident.
