Agile, Mushrooms and Tibet
You probably wonder how these three words can possibly be connected.
Hold on to that curiosity, as I will be sharing some learnings based on my past decade of coaching experience from the trenches, from large and small organizations, from legacy to innovative products, from telecom, banking, insurance, automotive, marketing and e-commerce industries, from North America, Asia Pacific to Europe.
Our discussion will cover topics around transformation strategy, agile leadership, technical practices, product architecture, distributed development and scaling, while the connections among Agile, Mushrooms and Tibet are revealed.
#NoFrameworks: How We Can Take Agile Back!
A fundamental philosophy from the early days of Agile, and particularly of XP, is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).
This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 18 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.
We had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.
Programming in the Extreme: Finding a New Largest Known Prime
More than just a mathematical curiosity, the quest to discover a new largest known prime requires the development of advanced computational techniques and the development of fault resilient software. These computational techniques benefit a wide variety of applications from seismic analysis to large scale fluid dynamics. The fault resilient methodologies benefit a wide range of application such as cryptography and deep space probe design.
The search for a new largest known prime has been ongoing for centuries. In 1952, primality testing entered the realm of digital computers. Computers have been used construct proofs of primality for these enormous primes. We have come a long way since the 1970s when the speaker, Landon Noll, as a high school student discovered a 6533-digit prime. Today’s largest known prime is almost 25 million digits long! Those seeking to break the record for the largest known prime have pushed the bounds of computing. The development of these extreme primality testing programs offers important lessons today for those who must write code which must work correctly, even in the face of hardware errors, from the very first implementation.
The search for the largest known prime requires writing and running code that must run to completion, without any errors, throughout the entire proof of primality! A significant quality effort is required to write 100% error-free code. The calculations required to test extremely large numbers for primality must be fault resilient. One must overcome compiler and assembler errors, errors introduced by the kernel, and hardware errors such as memory errors and CPU calculation errors. The world record goes neither to the fastest coder nor to the person with the fastest hardware but rather to the first result that is proven to be correct. The reason for such extreme programming is that the length of the calculations exceeds the mean time to error of the calculating system. The motivation for such extreme care lies in the fact that a slow and correct answer is infinitely preferable to a fast but incorrect answer.
Knowledge of advanced mathematics is NOT required for this talk.
The Human Side of Agile
Much of the agile manifesto emphasized the importance of the human aspects of software development. In practice, however, even as agile methods have become ubiquitous, human aspects are often overlooked. For example, studies show customer collaboration is often avoided, and interaction designers seldom work together with programmers. New approaches such as DevOps too easily ignore the possible to better connect the people involved. Of course, human behaviour is challenging: complex, subtle, and only imperfectly understood. However, applying what we do know can lead to important opportunities. This presentation will review experience in studying the human side of agile methods, examining areas of success and failure, and identifying principles to support improvement.