I recently had the privilege of attending the Scrum Gathering in Rosebank, Johannesburg. This was my first proper Agile conference and it was quite an eye-opener for me. In this post, I would like to share with you some of my observations and comments. Mainly as a way for me to internalise the content, but hopefully so that you can find some aspect of it useful and thought provoking too.
Where are all the Woman in Software?
In Agile, of-course!
One of my most pleasant surprises from the conference was how many active, passionate and inspiring woman I saw at the conference. Speakers AND attendees. Not as software developers, but as scrum masters and coaches
[NOT project manageresses]. The fact that I find this surprising is a sad reflection of the software development industry but I was excited to take part in an event that really show-cased thinking with a female touch. Both Keynote sessions that I attended were presented by ladies (Thato Kgatlhanye and Cara Turner). I must say that I haven’t been this inspired in a long time. They really packed a punch. Good on them! Thank you!
It’s as if any male-dominated influence in the software development world hasn’t yet had a chance to dominate, leaving a much welcomed gap for women to take the lead. It makes sense, because the agile movement is still relatively young – as in youthful, not infantile. Everyone started on an equal footing so there hasn’t been a chance for the vacuum to be created.
This transformation is one of the unsung heroes that the agile movement has enabled!
It often seems to get forgotten when mentioning agile. It wasn’t explicitly said anywhere in the conference (unless I missed it), but I feel it should be.
Another interesting thing that struck me at the conference is how segregated the various communities seem to be. I am making a concerted effort to attend as many user groups, events and gatherings as I am able to (and I thank my wife for giving me the space to do that), but I was surprised at the lack of familiar faces from the other groups. You almost expect to see some familiar faces that are always present in certain gatherings, but this group seemed completely new to me. During the sessions I realised why this was… most of the people attending were NOT developers… they were Scrum people. That made me think how segregated the groups actually are. I felt lucky to be part of the conference because I felt like I got to find out some “inside information” that I otherwise would not have been able to get access to. It does make you wonder why more developers don’t attend agile conferences. I would really recommend this for any developers that need to better understand business, their users and working in a team (and that should be all of them). It also makes me realise how valuable the culture is at my work (Synthesis). It’s a culture worth protecting because it emphasises the need for this multi-faceted thinking. Agile seems to have that covered.
Lightning Talk: Saving the day by starting today
Tjaard du Plessis
My colleague, Tjaard, was asked to present a lightning session within a window of only 10 minutes. This means that the speaker really needs to think carefully how best to get the their message across effectively. True to Tjaard’s style, he managed to pull this off flawlessly. I felt that his session was just as impactful as any of the longer sessions.
In his talk, Tjaard introduces 2 important principles that often relate to each other:
- Parkinson’s Triviality Principle
- We have a tendency to focus on trivial problems and ignore complexity… because it’s easier to do so.
- We tend to digress into solving the simple cases.
- Therefore we shouldn’t spend most of our time focussing on a trivial problem.
- Pareto 80/20 Principle
- 80% of the land is owned by 20% of the people.
- 80% of the value in our system is due to 20% of the functionality/features.
- Engineers and Entrepreneurs see the world as a problem to be solved.
- The problem of trying to get all the “What-Ifs” is: “What-if I haven’t thought of all the what-ifs“?
His realisation is that both 1 and 2 are related.
“We tend to digress to the trivial because we can’t think of all the what-ifs.”
The solution is to “JUST START!”
So how do we define “Start”? Well, in engineering, the process is well defined: Analyse -> Design -> Develop. In software, the process of development is part of the analysis.
A start in software is NOT something you do AFTER you have certainty. You gain the certainty only after you have started.
Delivery is the best way to gain certainty. While you are gaining certainty, you are delivering. We need to be in the correct arena to solve the complex problems.
I imagine that Tjaard had this picture in mind (which he shared with me during a break).
This highlights how the traditional waterfall model fixes the features at the expense of uncertainty on time and cost. Agile on the other hand insists that the cost, time and quality be fixed and the features that will be delivered are the unknown.
Tjaard then proceeded to show a photo of their user story map, highlighting how stories that are important are placed above a release line (20% features that give 80% benefit), while other items are captured below the line. This technique breaks the tension usually experienced because thoughts by team members at random times are acknowledged and captured but they are placed below the line so that they don’t distract from what is important.
Tjaard’s challenge to all of us is the following:
How is it that your team is obtaining certainty?
… and START there!
There was definitely a lot more covered in the conference that I have not captured above. I intend on completing my notes over the next few days.