The Challenge of Practice in Software Development

October 8, 2010

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!


I agree with the gist of your post. I guess that if companies spent more time training and conditioning their muscle, they would fare better in reality.

I guess poor organizational fitness must be one of the key reasons for project failures. At least such a finding would not surprise me.

Are there standard ways for measuring fitness (ie. something like Cooper's test but for teams)?

October 9, 2010 at 12:02 AM
Dave Moran said...


Keeping an eye on organizational fitness, as you put it, is essential. (I like the term!)

I'm not aware of any one, standardized test to measure business teams, nor do I believe that it exits. Concepts of teamwork can differ -- command and control project teams vs. self-organizing teams, for example, will have very different assessments because what they value is different.

I have come across tests that are intended to help teams improve, such as the agility assessment by James Shore for agile development teams:

Other tests exist to assess individuals on characteristics such as technical competencies, professional competencies, etc. and can be helpful to assess whether someone will be a good fit for a particular team. These tests can be tailored for your unique circumstances and needs: -- I do like to make the final determination myself, using tests as input, with the notion that they are providing additional, unbiased input.

I'll touch on this a little more in my next post.

October 9, 2010 at 4:43 PM
Faria said...

our ought to distinguish points which support your thesis declaration of one's essay. Just about every point ought to after that end up being famous to spellout whenever you in fact write your current essay. Its also wise to locate appropriate cases which obviously describe your current point. Review of for ones existing learners the exact producing HELP incorporate some extra help by using some others HELP suppliers.

May 19, 2015 at 12:35 AM

Post a Comment