The need for speed in agile

Fast feedback, valuing speed of delivery and rapid iteration seems to be the norm today in agile. Is speed over-emphasized in agile?

With complex systems, changing the pace of feedback can cause resonance, that can bring serious disturbance to an otherwise stable system. A faster pace can also drive teams to burn out. Requiring stakeholders to make up their mind and provide feedback at speed about for example a feature implemented in the last sprint may not get the team those well thought out comments that will improve on the final outcome. Forming a well thought out comment require time. Communicating the thought clearly takes time. Considering diverse views take time.

According to modern theory, those that can go trough a OODA loop (OODA comes from Observe, Orient, Decide, Act) most rapidly, will obtain advantage over those progressing slower. In areal combat this is likely to hold true, but in a collaborative environment this mind set seems foreign.

Obtaining reliable high quality feedback is crucial in agile development, but does the need for feedback to be "rapid" actually cause problems?

In my view the need for speed should be carefully considered and not just taken as the absolute undisputed truth.

Thinking, testing, practicing and reevaluating

The traditional view of learning, ie picking up a new skill from someone else and applying it to a problem, is somewhat out of date in our complex or even chaotic world. 

Firstly, if you are part of an organisation delivering training, make sure the learning works for your audience. If unsure, solicit feedback. Show that you care about the people in the audience. Consideration for different learning styles should have no place in any of todays trainings. See https://www.psychologicalscience.org/journals/pspi/PSPI_9_3.pdf for a closer look on why. Everyone can learn, and people have a diverse set of preexisting experiences that can be taken into account but traditional learning styles is not one of them. Bad training will demotivate people and put a break on innovation.

Everyone should have a mental model of the problem domain they experience. If not, take a step back and form an initial model,  acknowledging that the model will have flaws. Training would be most useful when evolving this model. Training could for example help people question the underlying assumptions of their models, reach new conclusions and verifying what is known. Evolve the model step by step by testing and verifying what is known and probing what is unknown. Cause and effect may still not be deterministic, but this can be a lesson and a property of the model too. Ensure that your model stays up to date with what you learn. 

There are also old practices or features of your model that will not make sense anymore as conditions change over time. These will need to be unlearned. Unlearning is also learning.

Learn to question what is taught. Ask why. Stay up to date by reading, listening to podcasts and discussing with colleagues. Don't rely on a single source. Teach others what you learn, and stay curious.

For problems that are simple or for problems where cause and effect can be analysed by an expert to solicit a single highly constrained solution that is likely to work, traditional training still can have its role. For problems where no known solution exists something above this is required.

The efficient and high performing engineer

There was lots of discussion regarding 10x engineers.  You may also recognize the 10x engineer concept as similar to "rock star developers", "ninja coders", and the "lone wolf" saving the day for a system.

Frankly I find the concept unsettlingly stupid.

If there was to exist a real 10x engineer, what characteristics would such person display? I would argue that the most important aspect would be helping others, mentoring and ensuring that fellow humans are as productive as possible. This include communication, teaching, and generally being human, which is very far from what engineering managers consider critical skills. Another critical aspect is that high performers should know when to unlearn aged practices that are not useful anymore.

Having engineers with high impact implies that there is a team around the engineer. Most of leadership practice however revolve around individuals, not teams. I consider it essential for leaders to unlearn traditional management/HR practice and focus more on teams if promoting high performance engineering is something they wish to promote.

Return of test investment

During a recent discussion the question was raised on how to make investment in test automation pay itself back. How do we know its worth the effort? Implementing automated acceptance tests can require quite big effort.

Theoretically there are two alternatives to automated tests. You can either test manually or you can disregard testing altogether. Having no testing today should be considered a breach of ethics in IT. As a presented at USENIX OSDI 14 by Ding Yuan et. al. most catastrophic failures could be avoided by testing error handling without any understanding the underlying software design.

Manual testing is time consuming, subject to testing procedure errors and require lots of attention. As manual tests take time to execute, the manual test procedure can easily slow down the release deployment and cause delay. With a manually executed procedure the results will also not be as reliable as with the automated tests. The variation can naturally be beneficial, but most likely the test result may be compromised.

When calculating how much benefit automated testing can bring, the main consideration is often how much effort and time can be saved by the automation. Less emphasis is typically placed on reliability aspect. Freeing up testers time to do more thorough explorative testing must also be considered. Secondary effects are also of importance. Having automated tests cause code and features to become more easy to test. Having automated tests also enable faster releases. Taking secondary effects into account when calculating benefit of test automation can change the equation.

Additionally there is also the consideration on which side do you want your estimate to side, on the side of promoting improved testing or on the side of limiting quality...

Null results

Presenting novel ideas is seen as valuable in our scientific culture today, but investigations of what the boundary conditions or side effects are more hard to find. Research programs are started to find and establish new theories, but not too much appear on under what conditions those teories does not apply any more.

Nassim Nicholas Taleb states it quite well: "you cannot do anything with knowledge unless you know where it stops, and the costs of using it".

In IT not much effort is put into understanding the down sides the "improvement" will have. One way of seeing this is that it is not in the interest of the IT staff or managers to know the limits, since that could mean less work since if side effects were well understood, the people making the investment may not be all that willing to back a number of projects any more.

Cost control

IT is not the only area where projects are in trouble according to an article in the January 2009 edition of Scientific American that arrived in my mailbox.

NASA also seems to have trouble with the Mars Science Laboratory project. According to the story costs were underestimated and unrealistic, and there seems to have been a lack of will to keep costs under control. In contrast to normal projects where you calculate a return of investment and you can find a limit to how much you should invest, i don't think it matters what the cost is in the case of the Mars mission.

With IT projects there is often no abort button easily at hand for projects going over budget. In NASA however i would guess that the situation is a bit different. When promising the moon, or Mars as in this case you may end up having to deliver at any cost. Wherther it will succeed to deliver on the promise or not we will have to wait and see.

Understanding management

According to a study management is struggling to get their message across to the people working for them in their organization. Among the around 200 mid level managers interviewed 87 % feels that the strategy is not being understood. Obviously this cause problems for the organizations probably impacting even the profitability.

One other way of interpreting this is that 13 % of the managers use normal language in stead of the normal jargon filled talk that management consultants and managers use. The study however did not present any data from which we could guess if the managers themselves understood what was being communicated. Still another possibility is that the 13 % or more of the managers have misunderstood how their people understand them and just describe the worst.

Seems like this should be a good research subject for further inquiries. For improving efficiency of management this could be useful. However, I don't think that the managers will change the way they communicate, even if this was shown to be the cause.