I gave a class on how to use Specialists to fill gaps and also help agile teams become more self-sufficient. As teams grow, organizations often draw a distinction between feature teams, which deliver the visible business value to the user, and component teams, which manage shared work. This distinction can help organizations be more productive and scale effectively, but he recognizes that not all shared work fits into this model. Some work is best handled by “specialists,” that is people with unique skills. Although teams composed entirely of T-shaped people is ideal, certain skills are hard to come by and are used irregularly across an organization. Since these specialists often need to work closely with teams, rather than working from their own backlog, they don’t fit into the component team model. The use of shared resources presents challenges to the agile planning model. I share how teams such as those providing infrastructure services and specialists can fit into a feature+component team model, and how variations such as embedding specialists in a scrum team can both present process challenges and add significant value to both the team and the larger organization.
Although agile principles sound simple, adopting agile is often extremely difficult. Some teams adopting agile start by making changes and tweaks to prescribed processes, which can cause problems. This class explains how following the recommended practices of your chosen agile method for a time will help you internalize the process and leverage the experiences of those who developed the method. Premature customization can lead to more problems and eventually to failure.
Agile software development relies on feedback, and the best feedback on the state of the project comes from seeing working software. Good version management, build and quality assurance are the technical practices that allow you to understand how far developed your system is and what needs to be done. We'll talk about the role of build, scm an QA in laying the foundation for a successful agile team, and discuss the role of DevOps in helping a team keep the agile contract of ready to ship code.
Many conversations about Agile Software Development focus on development and project management. Since feedback is essential to transition to agile software development and to maintain the values of an agile team, build, configuration management, and QA practices are essential factors in determining how agile a team will be. In this tall you'll learn how QA, and release management practices can help an team be more agile, and how these roles can change once a team is embracing agile software development.
I gave a tutorial November 10-14 2008 in Orlando, FL. Version management, build, and release practices are a key part of an effective agile software development environment. Many teams are puzzled by how to translate standard SCM “Best Practices” to an agile environment. In a effort to move more quickly some teams ignore basic software configuration management practices with the result they hit stumbling blocks down the line. Others maintain many of their old practices with the result that their teams are less agile. This tutorial will start with an overview of key SCM concepts, including codeline management,, build and release, and branching. We will them discuss how basic SCM principles apply to an agile team, and how you apply SCM Practices can help make your team more or less agile, and how they can ease the transition to agile when you have a legacy code base to work with. We’ll discuss questions such as when branching makes sense, when how using Scrum or XP affects how you think about version management, and the importance of simple but effective SCM practices to agile software development. Attendees should be familiar with some basic version management tools like CVS or subversion. This tutorial will focus on practices, not tools, but will reference tools such as ant, maven , subversion in examples. Developers, team leads, project managers and release engineers will find this class useful.
I gave a class, at the 2008 Agile Development Practices Conference November 10-14, 2008 in Orlando, FL. Applying agile methods to legacy code is challenging. You have to live with code that is not as testable, or as modular as you’d like, and you have to manage support concerns that disrupt your iteration plan, Even if your project is agile, you may have dependencies on legacy projects that are not be delivering at iteration boundaries. I explain how to be agile with a legacy code base using design, testing, build, and software configuration management practices so that you can be agile when your code is not while managing the flow of change required to support released code. At the end of the class you will better understand how to balance the requirements of working with an existing code base with the desire to have a more agile development environment.
Roundtable on deciding how dogmatic to be about practices.
SD Best Practices 2008, Boston, MA October 2008
I lead a roundtable at the 2008 October 30, 2008 in Boston, MA. Agile Methods discuss practices teams should follow, however, not all teams can, or should, follow every practice to the letter. It's hard to understand what practices you can compromise and which ones are important. Do you really have to test first? Or is soon OK? Can you adjust sprint boundaries mid-iteration? Some compromises to the agile dogma can be made while still staying in the spirit of your method. Some compromises make it harder to benefit from agile practices. In this session, you will learn how to make pragmatic decisions about how to practice -- and benefit from -- agile software development.
On March 27, 2008 I spoke about Developer workspaces and agility. Workspace Management is often an afterthought for teams, agile or not. For teams to work effectively developers need machanisms to help ensure that their changes will integrate well with others' work. Good workspace practices also improve team productivity by avoiding works for me conversations and by decreasing ramp up times when people start new projects. This talk will discuss some of the patterns and practices for workspace management that you can apply to help developers be more effective.
On March 18, 2008 I presented. Workspace Management is often an afterthought for teams, agile or not. For teams to work effectively developers need machanisms to help ensure that their changes will integrate well with others' work. Good workspace practices also improve team productivity by avoiding works for me conversations and by decreasing ramp up times when people start new projects. This talk will discuss some of the patterns and practices for workspace management that you can apply to help developers be more effective.
I taught a class. All teams can benefit from more rapid feedback, agile teams more so. Many teams struggle because their software configuration management and build practices don’t help them or worse, get in their way. Teams often struggle the questions of when to branch, how to create developer workspaces, and the role of testing is in an SCM process. In this presentation participants will learn how to create an effective development environment that allow for rapid change by using the right build, version management and testing practices. Participants are invited to come with questions relevant to their own situations