2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- July 31, 2019
- Collaborate
As hard as it can be sometimes to convince managers to let their teams try pair programming and see if it improves their overall productivity and quality, sometimes I have the exact opposite problem and I have managers who want to force teams to do pair programming, even when the teams don’t feel it’s right for them. This can be a real issue.
I know many software developers who prefer not to pair and that should be just fine for everyone. Pair programming should not be a forced activity. There’s a lot of us who would just rather work in solitude and that’s not necessarily bad. We do need to collaborate and share ideas but there are many venues for doing that. Pair programming is not the only way to propagate knowledge across a team.
I find that in matters like these that the team should decide what works best for them. It’s good to have a guide or someone who can help the team try different practices but then leave it up to the team to decide how they want to implement them. Forcing developers to do pair programming against their will can be seen as an invasion of privacy and no one wants to go there. Instead, give people the space to discover what works for them. It’s natural that some people will want to engage in some practices more than others and so when we let the team find their own equilibrium then these things can often resolve themselves.
Teams probably shouldn’t be trying pair programming without also trying other new practices. Pairing works best when you’re learning a new set of skills because you have your pair partner to help reinforce those skills as you’re doing development. This is actually one of the quickest ways I know to go from the learning phase into the proficiency phase—do it with another person.
But when I say to let teams decide on the details of how they want to implement these practices they also need to have some level of guidance and support from management. They need to be aware of what resources they have available to them and I find that many teams aren’t aware of these things.
Scrum says to let teams self-organize and that’s a beautiful idea in principle but I rarely see teams have the skills and ability to self-organize around the right technical practices and that is because this is not common knowledge in our industry.
So we have to let teams decide on the details and also make sure that they have access to knowing what their options are and that comes from understanding the practices of software development by doing it or working with people who have done it. Books, blog posts, conferences, and training can also help. Software development is complex and we are constantly learning new and better ways of doing it. It’s a lot of effort to keep up but there are many rewards to be reaped if you can stay on the leading edge of developing software.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « Try All Configurations
Next Post: Track Progress »