Section 7 is all about Maneuvering. Well, not completely about moving it is also about gathering disparate elements and blending them together into one, much like testing where you need to pull together different techniques and skill sets. This is the focus I am going to take, blending, much like coffee can be blended to improve the flavor (if you like coffee that is) or it can become bitter or overpowering if you have too much of one thing. Tea can be the same way, blend your tea one way and you have a nice calming beverage, another way and you may as well be drinking roots boiled in water.
Sun Tzu said: in war, the general receives his commands from the sovereign. Having collected an army and concentrated his forces, he must blend and harmonize the different elements thereof before pitching his camp.
Much like in a project, the Program Manager has sent commands to the Test Lead who now collects his team and concentrates them which requires blending and integrating them together into a cohesive unit. In a test team everyone has a different skill set, way of testing or may be a subject matter expert of different components or a product, blending the team together to get the best benefit requires skills that take time to learn in order to become proficient. Having a team that knows multiple test techniques, with some better in one type than another, gives a good balance but how do you make use of them to get the project done properly? That takes planning, if you have people who are strong manual and exploratory testers letting them use an early release can help find some of the test cases that may not have been thought of or bugs due to design flaws. Maybe there are automation folks on the team, having them sit with the Developers to help write, and perhaps review, test cases will give them an idea of what is coming and allow them to prepare a test framework for the test cycle. Perhaps there are some good analysts in the group, let them into the early design and spec review meetings, have them go over every spec and document carefully and get the design and functional issues out of the way. The best thing to be doing once you get your team is to know what their strengths are, plan to use them according to their strengths, putting the analyst who doesn’t know much Perl to work on the test framework written in Perl is a good way to make sure that you don’t meet a target.
Maneuvering with an army is advantageous; with an undisciplined multitude, most dangerous.
To meet your targets, and to be able to finish a project with a team, works when everyone is focused on the same goal. An army is a force that has a focus, a plan and an enemy that they are to face. A multitude is a group of people together for a cause, or even as a response to something, but they are not going to be focused. Always try to have an army under you, a group that will listen to your commands and be focused on the goals that the project requires, when the people under you are listening and following you can do plenty. The whole is more powerful than just the sum of its parts, and a team that is focused can do amazing things and meet deadlines that to others may seem impossible. Do not be at the head of a multitude, a group that is there just for the sake of earning a paycheck is not going to help you get your project accomplished, nor are they going to assist each other. Make sure that your team is working together, take them to lunch once or twice and talk to them outside of work, you can often tell outside of the company if there might be friction. If you see it, then take care of it as soon as possible, letting that sort of thing fester will cause trouble and eventually will come back and bite you.
We may take it then that an army without its baggage-train is lost; without provisions it is lost; without bases of supply it is lost.
Now that you have a group of people together to get work done, you need a place to get that work done, tools and equipment, maybe even someone needs that ergonomic chair to be able to sit at the desk to get work done. Find out what is needed and make sure its there, I have said it before, when you do not have an adequate environment to work within, then you only end up hurting yourself. Having a group of people who are trained and ready to go, working on one or two machines is not going to get your project done, make sure they all have the equipment they need, if you can’t get it then you need to be creative. If a machine needs to be signed out for each test, then make sure people know this and set up a common area for people to know and look to see if the Database Server is being used by the Functional Test group Tuesday; stepping on each others toes can not only invalidate tests but can cause bad blood between a team. While a well organized team will communicate constantly, it’s a good idea to have back up methods of communication, not only for people to make sure things are working properly but if there was an issue traced back to a previous test you know what that test was and can go through reproducing the issue. Also be sure you can get things repaired in a short amount of time, get images made of your lab machines when they are up and ready, that way if you encounter too many issues the machine can be re-imaged to a baseline and you can move forward and attempt to reproduce the issue. Taking time to rebuild test machines during a project is something that cannot always be afforded.
We cannot enter into alliances until we are acquainted with the designs of our neighbors.
If during a project there is a need in another group that only you can fulfill, perhaps only the test lab has a specific configuration or a certain server, and you need to help out make sure both sides understand the needs and what the “lease” will be. If a group wants to work with yours be sure you understand their needs, while I will never advocate being “political” in a company it’s good to not get into situations where you are part of someone being political. While I am not saying you need to distrust peoples motives, being sure what is happening is good for you and your team, if a group comes into help you or thinks they are, but are only impeding the project, then you need to stand firm and clear up the situation. Priorities will change in a company, even during “critical” projects, but make sure you understand what the priority change is, why it is happening and how you can get back to your project once it’s resolved as you now need to be creative for lost resources. Again, my view in working in some places is to always be sure you are covering your teams ass, document everything, be transparent and be sure that the Program Manager understands what is happening with your team; that way there can be no discussion or finger pointing later on as long as you have documented and shown the work you have done.
Whether to concentrate or to divide your troops, must be decided by circumstances. Let your rapidity be that of the wind, your compactness that of the forest.
Creativity with resources is another learned skill, at least to me; I have never really seen this as something that can be taught. You have to learn to anticipate changes in your projects, know what resources you can move around to resolve the issues, without losing too much against deadlines and milestones. This is usually something you can learn working for a manager who is really good at it, see how they do things, or if you work with someone who has encountered multiple difficult projects, talk it over with them. It might even be worthwhile to post it on an online forum, just make sure you describe the situation adequately and what you think might be a good solution, it eliminates unnecessary questions. There may come a point during a project where part of the team needs to work on a customer issue instead of on the upcoming milestone, don’t hesitate if meeting the customers need is vitally important to the company (and it usually will be) but let the Program Manager know this is happening and why. Again it’s a learned skill, make sure you are prepared to make a few wrong decisions, own up and if you get called on it you could try to explain your reasoning and try to move on. This is something that gets easier as time goes on and you encounter it more.
He will conquer who has learnt the artifice of deviation.
Anticipating, that is a very important ability to have. Once you learn that a project is spelling trouble, that something will not be there when it is needed or that something is going on with the team then you will be well on your way to many successful projects. Much of this does come from working on many and multiple projects so don’t be afraid if you get some things wrong, learning to see the mistakes we make so they are not repeated is one way of improving yourself and getting better. Failure teaches more than success at times.
7 down, more than halfway there! Thanks for reading.
