After many failed attempts to get him on the podcast, Craig finally catches up with Dan North at YOW! Conference on his way out the door to the airport and in a quick chat they cover:
BDD – developing an application by looking at its behaviour from the perspective of its stakeholders (people who’s live you touch)
Given When Then – “given” is setting up the world in a well known way, “when” is me interacting with the application as a stakeholder and “then” is what I expect to happen
Craig is at YOW! Conference and catches up with Anne-Marie Charrett who is well known in the testing community as a trainer, coach and consultant but also for her support of the community:
Speak Easy – Speak Easy is a voluntary program designed to increase diversity in tech conferences through dedicated conference spots, mentoring and events
Testing challenges include microservices (the risk of bounded context and breaking things down and missing the whole) and working together as developers and testers
Craig and Tony are at YOW! Conference and are privileged to spend some time with Don Reinertsen, who is considered one of the leading thinkers in the field of lean product development and author of numerous books including “Principles of Product Development Flow”
Taiichi Ohno, the father of the Toyota Production System, hated math and thus preferred to sit on the factory floor and tweak processes, hence it was not a theory driven approach but rather empirically driven
Need to understand why things work so you can transfer it to other domains, a big shortcoming in lean manufacturing is that they don’t have much of a mathematical view on what they are doing
You can use magic in manufacturing because it is highly repetitive
People understand iterations are good to do but do not understand why
“Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better” (Nassim Nicholas Taleb)
Agile software people are doing a better job at lean product development because software people have already crossed the chasm of inspect and adapt
There are many sources of variability other than just people, such as the Internet and the fact we are constantly doing things people have not done before
To get management to listen about cost of delay you need to benchmark what you are doing today
Agile eliminated the economic gene, hence it works well bottom-up
Easiest way to introduce quantitive based decision making is to find a project manager who wants an economic model (as they will be fighting for resources and the guy with the numbers will end up winning because they can communicate their needs)
Lifecycle pretax profit is far more useful than ROI
Start with Chapter 1 in the book – describes what is wrong with what we are doing today, then look for the tree that is ready to be pushed over in your organisation as there is no one way of approaching this
The low hanging fruit is: visual control boards, economic model, batch size reduction and WIP constraints
The first knob to turn is batch size reduction
It is 175 principles in small little batches that add value, it is not the ten commandments!
Craig and Tony sit down for a conversation at YOW! Conference with Betty Enyonam Kumahor (stands for good for me, on the way there) who is a technology leader in Africa:
Tony and Enyo are mutual members of the Alistair Cockburn fan club
Software engineering uptake in Africa is very low, need more technologists because it is is not an industry it is an enabler
Lots of diversity challenges in Africa – lees than 1% of the South African IT industry is women, but also diversity in languages, education and belief systems
Diversity is a multi-pronged issue, need to be patient but not complacent to move the needle forward, give girls the confidence to be competent and to push the boundaries
Frugal innovation in Africa – building technology in a space of constraints such as inadequate power, everything happens by mobile feature phones, needs to be built fast and cheap
Agile in Africa – need to make communities more aware of Agile practices, share what developed world has learnt but also what needs to adjust for the context of the continent
Growth of techpreneurs, expensive to do business in Africa, focus on local market rather than off-shoring to Europe
Andela program – train to be a software engineer, become a fellow and work for offshore clients
Successful conversions from tech hubs to startups is below 5%
Biggest issue is lack of access to expertise in Agile / Lean practices as well as lack of people to adapt it for the continent
Business and architecture isomorphism – if you look at your architecture you should be able to see your business represented in it and vice-versa
Disruption is causing organisations to think about organisational design as well as architectural design
Microservices is a style that is applicable for certain circumstances, it is not one size fits all – follow the 16th rule of Unix programming “distrust all claims for one true way”
For microservices, Amazon and AWS was the game-changer
If you are not building software using the Agile practices these days, you have probably gone down “the wrong trouser leg of history”
Lean Enterprise is an evolution and description of current thinking
Agile methods need to focus on flow rather than scaling and structure
ThoughtWorks Technology Radar – point in time snapshot on what is going on in current projects, throw systematic darts at the wall, vote on over 300 items to whittle down to 100 items,
Agile as a word has become meaningless, don’t follow the off-the-shelf processes, apply small corrections to move forward
Story of Stone Soup is like Agile consultancies, the hard work is done by the companies
Scrum is a good starting point due to its simplicity
Raccoon is a noun, so not a good replacement name for Agile, because you can buy a pound of it
1,000 working on one thing can never be Agile, you have to make enterprises agile before you can run an agile project
The values in the Agile Manifesto hold up well, would have been nice to have had more diversity, had no expectation they were going to create something so significant
The Agile Manifesto was a reaction to the problems in development at the time, maybe something new is required, it would be a tragic mistake to create Agile Manifesto 2.0, we need to ask what is more relevant today to express our frustrations
Agile is a fundamental way of thinking about doing stuff, that’s why it’s important to understand why we are doing it
The Pragmatic Bookshelf was accidental by saying the dreaded words “how hard could this be”, the strength is knowing nothing about publishing, everything was automated unlike traditional publishers and still runs with 2 main employees, now storyboard books like a movie as the reader is on a learning journey
Ruby has a future, but it needs to distinguish itself as a fantastic general purpose programming language, the community is still very friendly and innovative
The emphasis and dogma around testing is off-putting, the amount of effort around many tests are not moving people forward
Craig is at the YOW! Connected conference and talks to Mark Pedersen, the CTO at KJR, and they talk all things quality and testing:
the changing role of a tester in an Agile environment, it clarifies the role rather than making it blurrier
in an Agile environment it does not make sense to have a Test Manager role anymore
the number of dedicated testing roles are decreasing, but becoming more important and valuable
most organisations say that they use both waterfall and agile frequently
build your skills in either a quasi analysis / product owner / acceptance criteria role or get up to speed with sensible technical automation tools for your tech stack
TDD – good idea but not many organsations practicing it in a dedicated way, unit testing in most industries is a luxury
BDD – does not make TDD obsolete, defining acceptance criteria upfront helps understand what we need to code
pair programming – does not deliver much benefit from a test perspective, unless the tester has technical expertise, adoption is still very low
mobile testing is challenging and IoT will take it to another level – customer expectations are higher for these devices, they are thought of more like traditional mechanical devices
mobile and IoT is driving the demand for testers to become more technical – more API and distributed technology tests
Management science says that the problem of business performing highly and being profitable and people having a life at work are highly at odds with each other, Agile has challenged that
Organisational Agility and self organising teams have been around since the late 80’s / early 90’s
The Responsibility Process is a naturally occurring pattern that occurs in our mind that shows how we respond to upset or frustration in ways that we either cope with it or take responsibility to learn and grow
Correlation between The Responsibility Process and the 7 stages of grief
You go through each stage, even if it is for a microsecond
The mental state of responsibility is available to you all the time
Listen for yourself saying “I have to…” then catch it and change it to a statement you are willing to own like “I am…” or “I choose…”
The Responsibility Process Game – each day score yourself for when you heard it, said it or caught it
Research started in 1984 and collected through participant observation and interaction
“The first job of a leader is to define reality” Max De Pree
First principle of leadership of The Responsibility Process – “No group in an organisation will consistently operate at higher levels of responsibility than the people to whom they report”
Craig was apparently the first client of GreenHopper that was built in a basement, now JIRA Agile is the most popular JIRA add-on with over 500,000 users, used by more than 80% of JIRA users
the idea was to have a tool that brought bugs into software management
the name GreenHopper represented the Green company branding at the time, and Hopper was for cards hopping between columns
a shout out to our friend Nick Muldoon (who is now writing Atlassian plugins at Arijea)
Tempo Folio plugin is about supporting cost management, including time sheeting, estimation, forecasting and allocation
time and dedication and about three months is all it takes to create an Atlassian plugin (and JC challenges Renee to write her own WSJF plugin)
hippies, not EP’s!
versions on frameworks are good, means feedback changes are coming
Spotify have shared a lot of the things that have worked well, but they do also have challenges as well – one is alignment across teams as the organisation gets bigger so they have been working on visualisation and prioritisation
use microservices to ensure that the organisation can work in the way they want to work – great autonomy but a challenge in keeping a consistent design language and customer journey
Agile culture is spread throughout Spotify, use what works rather than one particular approach