One of my favourite subjects of the parallelism between sport and leadership is about the methods. Look at the stories around the methods:
- I had a trainee in the Gym, who was very well prepared on theoretical level and was looking for the Holy Grail in training: one method, that works better over any other. He had doubts, which works better: pyramid system or flat weight series. We did a simple test: 6 weeks pyramid (focusing on the heaviest series): resulted in increased strength and better built body. Switched to flat weight series (have not got tired while reaching higher weights): again growing in strength and muscle. There was a progressive load increase in both methods.
- What if, if we do this in software development: in a smaller private project, we did old school waterfall: got the requests for the development, rather clear ones, strict deadline: development was done exactly as requested, in time, no complains about the delivered product: got paid. In another request in the same project: clear specification, delivered in time, Client requested adjustments that have been delivered a week later: finally got what they requested – happiness. In a big agile (scrum) project, multiple User Stories has been developed, very short stories, 2 weeks sprints, development checked during development, feedback is given in time – the right features has been delivered during the multiple sprints: again, happiness. (Note: this second project is way much bigger)
- A trainee tried a workout method called HST. He was progressing rather well during the routine. This workout has a closing phase, called strategic deconditioning, to regenerate yourself to start the next round (with higher load) – this phase was ignored: result was a disappointing workout plateau. Having a holiday enabled him to have a rest and step further, when he came back.
- Our first attempt applying scrum was not so good: we had releases at the end of every sprint (that everybody liked), but we have not discussed the stories deep enough to give correct estimations and our self revision was limited to certain parts of the process: with the story in point 4, it was not a great success: without learning enough about what has went wrong and without trying to fix it all level, was hard to step further.
- A talented trainee was executing a method, but never stopped evaluating what adjustments he needs to do. His strength and overall condition was athletic, but far from perfect. He asked my advice, if he is good enough: I told, well your posterior deltoid is just far behind, like your upper legs – his disappointment was incredible. He was focusing on these areas a bit more and had a better physics. Then he asked my opinion and I mentioned the imbalance in his upper arm, again disappointed. We discussed it over and suggested a self check method: finally he made photo shots about his development after finishing each workout cycle, where he could identified the 2 critical areas he needs to improve in the next workout cycle, and iterated this – he became pretty outstanding!
- We used to build the software on a way, that testing mostly was done after a release, documentation as well. This did not help in responding quickly on a change, as we had to do the step-by-step processes, between the steps if there was a waiting as the other department had anything else to finish that caused some further delays that was all added up at the end. At applying scrum in our organisation, we built in quality improvement into the process itself; also the steps were combined, while the retrospective became natural part of the process: this guarantees continues improvement, focusing on 1-3 key areas in each sprint, where the Team decides on the focus.
- A trainee came to me, which supplements he should take. I asked: what do you think, what is your bottleneck protein or carbohydrates, what do you eat, how many times a day: the answer was shocking: being awake since 5am, till 5pm he took 3 sandwiches, that he evaluated “as a decent good food”. Instead of deciding on any supplements, we agreed, that first he had to stick to have regular meals a day, and later we can turn back to the topic. Training is just a trigger, having rest and healthy food are the enablers.
- Again about our first attempt applying scrum: the whole company was not aligned to this method: we dragged many development items from one sprint to another as we were not able to protect the development team from incoming ad-hoc requests, so not every planned in/promised items were delivered – finally we decided to stop it. Later we restarted it, with the support of the whole company, sprints were delivering again and sprints started to succeed.
Conclusion, my principles about methods:
- Whatever method you use, can work: (assuming you are able to adopt it) it is almost unbelievable, but also methods which are almost opposite of each other, will do work (let me note here, that knowing the circumstances a method can give better results at a time, while another method can give better results if circumstances or the environment changes)
- If you do not apply the method fully, you take an enormous risk of failing: it is so tempting to enjoy the benefits of a method (like the possible frequent releases of a product) while it completely can be blocked if the sprint is not respected and management tries to file new requests into the development
- If you use the same method, same way, without adjustments or improvements, again, you will fail: everything can work, for a while, but the circumstances, the environment is in a continuous change, if you do not respond to these changes, you will not reach the next level
- You need a stable ground and discipline to make a success with the method: you need an environment that supports your goals and you need to stick to the rules as much as possible: you (slowly) also can change the environment keep repeating yourself and sticking to your rules (as you can push back the unhealthy food, in software development you do can survive breaking sprints or avoid disabling your development potential)