When training in martial arts, one comes to learn that one of the most powerful tools one has in dealing with an adversary is to control distance and time. One can either increase distance in order to give one more time to analyze and deal with an adversary's attack or one can reduce distance and/or time to limit your adversary's options and ability to develop an attack.
Similarly on a project, surprises are seldom a good thing. However one cannot know everything which is going to happen. Change management strategies have evolved to try to deal with this, however, traditionally these have been largely reactive... like a novice at Close distance flailing wildly to block each attack. So how do you control time/distance to problem fallout on a project?
This is done via the use of feedback loops of varying frequency. Feedback loops of lower frequency can give you the time to "step back" and assess changes before rushing in. This can called a Distance/Time giving action since they give you more time to assess a developing problem, but that means they may also allow the problem to develop further. Feedback loops of higher frequency allow you to address issues immediately, preventing them from ballooning into larger problems or even implementing proactive solutions to stop the problem in its tracks. These are Distance/Time takers, since they shorten the time allowed for a problem to develop. The number and roles of individuals who receive and deal with the feedback initially also plays a part in whether a technique is more giving or taking in nature. Generally, lower number of individuals whose roles are closer to the source of the problem will be a taking action, while the converse is more of a giving action.
Some Distance/Time giving techniques (lower frequency loops):
- Daily scrums/standups
- Iterative development/delivery
- Regular demos
- Regular retrospectives
- Pairing
Taking a step back to gain distance and time is one of the simplest defense moves. Appreciation of the different threat levels each distance presents and the ability to back-out to a safe distance is something which is taught to beginners. Similarly, the techniques for gaining Distance/Time in Agile Development are simple enough that any team can begin to use them right away.
For example, a team is following a more traditional project management approach with few touch points across the team. Perhaps the PM only reports to a board the status of things as dates for delivery of milestones occur. At this point, it is usually too late and if a problem has occurred, the PM is delivering the surprise bad-news. Even worse, a milestone is delivered only to have the product owners report all the surprise deficiencies. Obviously, both of these are uncomfortable for all involved and panic may often set in. By establishing short, frequent and regular meetings with the team including all stakeholders, a team can get the opportunity to see the problems coming and properly deal with them. They are effectively giving themselves the time to deal with the problems rather than rushing headlong into the fray.
A recent client complained that historically, every time they tried to do a deployment the tools the development team used seemed to create surprise errors. Moreover, items were added to the new environment without the client's prior knowledge. These would not necessarily break anything, but they did add confusion and wasted time. In order to address this we established regular meetings with tech leads, the deployment lead, the clients and testing. At the meeting, proposed pending changes were discussed. A draft-deploy was reviewed for surprise dependencies which might be pulled in by the deploy tool. Team members who previously never spoke to one another now communicate regularly around a problem they were all experiencing from different perspectives. Out of this, the team has developed a much more rigorous deployment practice, surprises have been eliminated, and all parties have gained a much better understanding of their deployment tools and an appreciation for each others difficulties in deployment. It is not as much a typical Change Management/Approval board as it is an opportunity for the interested parties to communicate. Meetings never last more than half an hour and usually are about fifteen minutes, but we meet at least once a week. While not one of the traditional Agile Team Meetings, it follows the spirit of frequent cross-communication which is so vital to the Agile Approach.
Some Distance/Time taking techniques (high frequency loops):
- Automated Testing
- Test Driven Development
- Acceptance Criteria/Tests
- Test First Development
- Pairing
- Continuous Integration
- Daily scrums/standups
Distance/Time taking techniques are usually more advanced in Martial arts as they require a bit more training and discipline to do safely. So too in software development. Most of the ones I listed here obviously employ development practices which software engineers will need to hone if they have not done them before. However, once proficiency is obtained in them, these practices can be life savers and even keep at bay the dreaded pager. Utilized well, these operate as a means of clinching problems by stopping them well before they develop into much larger problems in a more devastating environment. Use of Automated testing with a modern CI server can not only identify problems in with new code early on, it can also help make sure that once a bug is fixed, it stays fixed. One of the mantras on a team I was on was "Find a Bug, Write a Test." Basically, whenever a bug was reported, the developer wrote a test for how the solution was supposed to behave. Of course, until the bug was fixed, the test would continue to break. However, the bug would likely never resurface again since our test coverage of our code had now improved. This of course requires the developer discipline of running tests before committing, as well as a Test-First mentality. Without those disciplines the team is back to reactive flailing.
These techniques do not always stop problems from occurring, but like the clinch, they can prevent the problem from developing into a more lethal one. A team with good CI, TDD, and Acceptance testing practices for instance, can deal with and minimize the impact of major architectural changes or even severe problems introduced by changes in third-party software. They can tackle the severe problem in manageable chunks at a level of relative safety.
I listed daily scrums and pairing under both because depending upon the situation these techniques can act both to give time to deal with potentially developing problems as well as to stop problems from starting in the first place through open communication. The latter is usually the case where someone either states what they are working on or having difficulty with and someone else on the team either gives them a solution or can help them avoid pitfalls they have experienced before. As it happens at such a frequent schedule, the time for problems to develop is often completely eliminated - effectively clinching the problems. Scrums and Pairing as time gaining operate in the sense that by approaching problems as a team tends to prevent us from making rash decisions.
A final note: you will notice that I do not say Pair Programming... while I like Pair Programming, many of my colleagues have noted that pairing is a powerful tool for all team members. I have seen PM's, BA's testers, even Product Owners pair on deliverables with great results.
No comments:
Post a Comment