I'm a bit behind on blogging due to duties last week, but I'll catch up by throwing the third week of practice alongside the first game. In our league the third week of practice heralds two things, first the last practice before our first game, and the arrival of our team rosters and uniforms. On this particular day, the 'head coach' of the league, who has been helping out with our Kindergartners had to distribute the uniforms to all the different divisions. This left me alone to do a lot of work with the kids on my own.
This worked out fine, and as I always try to keep the kids moving it worked out great. The Third practice is where we honed in on basic shooting skills. For most introductory soccer players, the more advanced steps are not always easy to pass on. At this practice I focused in on keeping their eye on the ball and following through as they shot. Also, as with most practices I got and kept them moving as much as possible.
I started by having them stand next to the ball and shoot it stationary. After each player had tried this a few times, I had them try shooting the ball by first running up on the ball and then kicking it into the goal. Afterwards, I made it more difficult by having the players dribble the ball and then kick it into the goal.
On many development projects I've seen a similar step by step building up to completion. A feature might start out very simplistic, or it may seem that way so we start by taking our first shot at it, just as my players might in their third practice. Sometimes we may not understand some of the nuance to a requirement. It may appear simple, just like striking that ball, but there are intricacies and un revealed flavoring that needs added for the code to really pull off what is intended. So as a team maybe you work up to these features, adding a little more speed, a bit more control, and higher accuracy in its calculations.
I've found similar patterns in testing. The first time through, you may just be poking around in an exploration of the application under test. You may not have a full grasp of the features, how to activate or use them, or the intent, but you build a bit of confidence and then take another test run at the software. Then you might discover that this type of software is documented to have a particular susceptibility to one kind of fault, and begin tailoring your exploratory testing to hit those weaknesses.
The first game of a soccer season is always exciting. Its the first time the kids are in their new uniforms, and you just never know how much the kids have absorbed from the limited practices you've had thus far. Each year is a little bit different. One year, one team may have a very good grasp of the game and create a lot of goals in that first game. Others might find it difficult to juggle defending the approaching ball, redirecting it to the goal they are attacking, or they may even get a little winded as they aren't used to moving so much at one time.
The first year I coached, an older coach told me, "You'll see the most improvement between the Second and Third games." I wasn't so sure how to take that, but later I realized what he meant. Suffice it to say, many kids may not listen early in the practice. Until they see how they can apply it in a game situation, they just may not realize the advice you are giving them. I've seen this happen on development teams too. A tester might make a suggestion about how to improve a process or function within the application, and might be ignored, because its simply not their job, or because the developer is too much ' in the zone' to stop and see what is being said. There might even be, as is common in our first game of soccer, a lot of stops and starts as you build to a sustainable pace for development.
Bottom line though, remember it's just the first game. A lot can change over the course of time on a project. Change is inevitable in many projects, and how we handle and respond to it sets a strong light on our teams and how we cope with that change.
No comments:
Post a Comment