The term practice can take different forms. It can be a customary way of operating or acting, such as, “It is our practice to give annual raises in January.” It can be the pursuit of a profession, such as “practicing law.” It can be about putting an idea or concept into action, such as “putting a theory into actual practice.” And practice can be about repeating some activity with the goal of improving a particular skill.
Athletes have long periods of practice and short (relatively speaking), intense moments of competition where they apply what they have practiced. The contest is the moment. Practice for us professionals working in software development is more of a continual, real-time activity.
The exception is formal training. This is a form of practice, but it is only a first step. Except for those times when the instructor has been so poor that I came away feeling like I didn’t learn a thing, I’ve always felt that training equips me with new knowledge and insight, pointing me in a direction and providing solid guidance. Training means that I’ve been coached and instructed on the basics so that I can truly begin to put something into the actual practice of my day-to-day work.
If I want to become truly proficient, it’s up to me to take the ball and run with it. And I may need refresher or additional instruction once I’ve gotten some real experience under my belt to polish some rough spots or to take me to another level.
When it comes to software projects, here’s the challenge: Most businesses have a heavy bias towards planning and execution. It’s a, “Here’s what we’re planning on, now get me my results – and fast!” mindset. Practice and learning can have the appearance of poor execution. And sometimes it is poor execution.
Practice and learning come in different forms on a software project. For a start, we’re not writing the same applications over and over again (well, most of us aren’t). We’re contending with ever-changing business requirements and the continual advancement of technology, which provides uniqueness in every project. In the process, we’re learning new things and putting that knowledge into practice or we’re reinforcing what we already know through continued use and adaptation.
Since we’ve adopted Scrum, the emphasis on teamwork skills has increased, and now we all need to understand how to contribute both technically and collaboratively. Furthermore, and in support of Agile development, teams must strive to be autonomous, self-organizing, continuously improving entities. Needless to say, there’s a lot of learning and growing involved!
One origin of poor execution is management.
Poor alignment of the skill set and team assignments relative to the complexity and difficulty of the project. Assigning junior-level programmers to tackle projects that can and should have at least some more experienced, senior programmers is begging for trouble. Sometimes, assignments get made too casually. Take the time to understand the nature and needs of a project before making an assignment, and don’t just assign people because they happen to be available.
Equally poor execution in an Agile context can come from anointing a team as “self-organizing” without the proper training and preparation to be so. Make sure the teams have training and coaching to implement Agile development successfully. And it is certainly poor execution on management’s part to stand idly by while watching a team as it runs straight into a brick wall and fail miserably. Part of the organizational learning process is to assess where individuals and teams are at and given them the appropriate guidance and space relative to their preparation and track record – avoiding putting people into situations where they are over their heads.
Failures and problems will always plague us, but through proper staffing and preparation, the impact can be minimized and reduced to small affairs that can be recovered and learned from, not colossal failures that are highly visible, miserable experiences.
Finally,once proper team assignments and training are in place, continue to talk with your people at both individual and team levels. Make sure that you’re in tune with the work that they’re about to undertake and talk through the major points. Making an investment in people means they need to learn and grow, to stretch themselves and perhaps make some mistakes along the way. Keep in touch and make sure that they’re equipped and able to tackle the challenges they face. And don’t let a train wreck occur unless you are very prepared to make that investment!