Had a work meeting this morning, so needed to skip the 9am session and had a nice leisurely morning. Did some yoga, had breakfast and enjoyed the California sunshine.
Development Practices, Explained – Llewellyn Falco
In this session, Llewellyn shared tips, techniques and practices that one can implement to make the cost of making mistakes cheaper. As humans, we’re going to continue to make mistakes, so the goal isn’t to eliminate mistakes, it’s to make them cheaper.
He walked through a brief history of software development, and how with each planning methodology, the cost of mistakes goes down. No methodology prevents mistakes, and we need to acknowledge that. It’s not about perfection.
He shared the story of a friend’s family member who needs the help of a wheelchair when going on mid-to-long walks. One year, there was a trip planned to go to South Africa (a long distance from home), and when she left her house, she forgot to take her wheelchair. When she got to the airport and used an airport wheelchair, she didn’t realize that she hadn’t brought hers, and then when landing in South Africa, it became a problem.
The cost of fixing this mistake got higher and higher at each point. Had she detected that she didn’t have her wheelchair when she was leaving the house, the cost would be a few minutes. At the airport, the cost of a return cab ride and some time. The cost in South Africa was the most expensive.
The earlier we detect mistakes, the cheaper they are to fix. Agile provides practices to reduce the cost of mistakes.
In addition to detection, the other two ways to make mistakes cheaper include 1) making it easier to change and 2) reducing the area of impact/effect.
For reducing the area of effect, Llewellyn shared the story of when he was working on a dev database, which he took offline for about an hour. When he brought it back online, he started to hear cheers from the other side of the dev floor – “it’s back up!” He checked with his teammate and learned that everyone was using the same instance. His work impacted the work of 50 developers for an hour, the equivalent of one man-week! Think about the area of impact/effect and how to reduce it.
Llewellyn then shared a story of when he was working for a company building a Point of Sale system for the customer (with a really sweet hook for Llewellyn’s company that they could keep the license to sell to other customers), which included six mistakes:
- Mistake #1 – Misunderstanding the Requirements
- Everything started out great, they got strong requirements from the customer and then started building. They built for about 3-4 months and having a really great time. During the first demo four months later, the customer is liking what they’re seeing, and someone asks, “what about purchase orders?” Llewellyn and team said, “in the requirements, it was stated that purchase orders are never done.” The individual responded, “right, we never do purchase orders, just once or twice a month.”
- Llewellyn and team needed to throw away most of their code and design a new system that could support purchase orders.
- The learning is that it’s not about removing the misunderstanding – we’re usually going to have misunderstandings, it’s more about making it cheaper when those misunderstandings happen. We need to start understanding what we misunderstood as early as possible.
- The agile practice that can help with this is the Onsite Customer. One customer will give you feedback, and it can be you. However, it can’t be the Business Analyst, which Llewellyn likens to when his Mom chooses his dates for him. Lots of positive intent, but not coming from someone who is going to be using the product. There also needs to be trust, which can be terrifying when talking with customers and being transparent. We also need to be mindful to not have tunnel vision.
- Mistake #2 – Knowledge Silo
- Llewellyn then shared as they were almost done with the rewrite and within a couple of weeks of the next demo, their DBA was no longer available to work on the project. They needed to find a substitute, which they did at a really high price, and when that person came on board, there was a very long ramp-up time to understand the scripts and what did what.
- The mistake was not backing up that knowledge.
- Some companies have a “Bus #” or a “Truck #;” Google has a “Retire Wealthy #” – basically what number of folks are single points of failure that would cause a huge disruption if they were no longer working on the work.
- The agile practice that can help mitigate this issue is Pair Programming and Mobbing. Llewellyn equates RAID 1 to Pair Programming and RAID 5 to Mobbing.
- When implementing, start small with just thirty minutes a day (don’t overwhelm), and when Pairing, he recommends the Strong style. Also be on the lookout for when a person in the pair is just “watching,” which is not only a waste of time, it’s boring.
- As someone who doesn’t get a lot of exposure to the topics, I appreciated the deeper dive into Pair Programming and Mobbing. I really liked how he explained that when we work as individuals, both our best and our worst shows up, and we pay the cost for the worst aspects. When working with others, the best and worsts from all of us are combined, and we pay the least cost of the less worst of the group. It also produces the best quality of the members of the pair/mob. For example, if you’re drafting an email, and you ask someone to read it over, fixing any typos are cheaper before its sent vs. after its sent.
- Mistake #3 – Changing Requirements
- Llewellyn then shared that during this project, the Windows Phone launched, and the customer wanted a version of the software to work on the Windows Phone.
- They pulled the code apart to work on the phone, and eventually, it stopped compiling. They found that what they were building for wasn’t what they needed later.
- The agile practice to help solve for this is refactoring. If it’s hard to get new things in your code, refactoring will make it easier. Refactoring is very small changes over time; it is not rewriting (rewriting is deleting and rewriting). There are also tools that can help automate refactoring, such as Eclipse. He then speaks to how we as humans get used to the paths we’ve created – whether it’s the tools that we use or the paths we take when walking around the conference.
- Mistake #4 – Integration
- At this point in the story, Llewellyn shares that there are three teams working on various parts, a front end team, a back end team and a Windows Phone team. They were working separately, and surprise, things didn’t come together smoothly at the end.
- The last 5% of the project just kept dragging on, and everyone wished that they could have detected integration point differences sooner and figure out ways to make integration cheaper. In the example of shaking hands, if one person shakes with their right, and another shakes with their left, they can work it out early if they detect there is a difference.
- He spoke about Continous Integration (CI) and Continous Delivery (where the customers see it). With Continous Integration, the area of effect/impact is a lot smaller, and it’s easier to understand when and where the error occured. CI will alert when things are not in sync, and avoids “killing the messenger.” Also, we need to keep in mind that the value of the test is when it fails, not when it passes. It needs to detect errors.
- Mistake #5 – Bugs
- We’re at the point in the story where everything is integrated, and QA is running the final tests. The first report showed 10 bugs. The team celebrated, 10 bugs – that’s nothing, we can knock that out in a week.
- The team knocked out the 10 bugs, then 5 bugs showed up, no problem, we’ll take care of them this week. This continued where the team stayed 1 week away for 3 months.
- The lesson is not to eliminate writing bugs, but making bugs cheaper to find and fix, it’s a detection issue. The cheapest point is at the time the bug is written, and detection needs to be enabled right then.
- The solution for this is Test Driven Development (or Behavior Driven Development), which is a fluency and skill that needs to be learned, and during that learning period, things will slow down. TDD and Refactoring are the hardest to become fluent in, but are powerful.
- One needs to be conscious of not making the mistake of writing the test after the code is written, it needs to be written before.
- Mistake #6 – Built Something Users Didn’t Like
- The team finally got through the bugs and had a working production system that they delivered to the customer. What followed was then a sad tale of how they found that users didn’t like the product, and because people at companies talk with other people at companies, it impacted their sales. They eventually had to shut the product down.
- This was a detection problem, and the agile practice that could have helped was Iterative Development, which means goign to production, not just demo’ing. When the customer has it in their hands, they have a difference experience.
- He brought up the Coke/Pepsi Challenge where there was a sip test. Pepsi is sweeter than Coke, and on a sip test, it performed better. Coke responded with New Coke, which matched Pepsi’s sweetness level, and it was an epic fail because when someone is at dinner and has a full glass, it can be found to be too sweet. When a product is used in the real-world circumstances, it’s different than just a demo or a sample of the product.
- A/B testing is also a great method to test out assumptions and validate/invalidate ideas. There is usually a big game of what customers say they like vs. what they actually like.
- He doesn’t like the term failing fast because it’s not very inspiring and prefers the term “steering.” We all have a goal that we’re aim for, but just the aim is not enough, we need to steer and course correct along the way.
He closed with “Accept that people make mistakes, make those mistakes cheaper.”
Let’s Stop Making Each Other Feel Stupid – Claire Sudbery
Claire opened her session with a really powerful story of her experience in technology and how our judgements of one and other about our cleverness are so damaging and prevalent. About how we can laugh, get angry, frustrated about the level of someone’s cleverness.
We’ll judge someone for their level of knowledge around how to make widgets, when they’ve gotten to where they are not having to know about widgets. Maybe knowing about widgets isn’t that important (instead of widgets insert new cool tech thing).
We judge each other really harshly about our levels of knowledge and intelligence and see these as a premium. When others overhear these judgements, they usually naturally think “I hope they’re not saying similar things about me.” Then, we start to judge ourselves, we start to struggle and believe that we’re really stupid.
She explains that we have a problem of Intellectual Ellitism – some are really clever and they are the ones that really matter, and then there is “everyone else.” We have this even though we have a huge problem of getting enough people in the industry; people are scared. Not only do we alienate our current team members, but we also cause the general population to feel inadequate to enter a career in technology. We make people feel insecure by using shorthand such as PEBKAC, and they know we do it – why would they want to join the industry?
The other thing that we do that makes each other feel stupid is that we talk in jargon because we want to be understood. People likely think we’re special because of all the cool jargon that we use, and it proves that I’m not stupid by using that jargon – all we’re trying to do is prove how clever we are.
This stiffles teams because instead of a team member asking what the jargon means, they’ll stay silent for fear of looking stupid.
Claire also covered Imposter Syndrome, which she attributes to keeping up this appearance of cleverness, but there’s a fear that deep down one is actually stupid. This leads to people telling you what you want to hear for fear of judgement, and that effects the ability to have diverse and inclusive teams.
She also covered the Stereotype Threat, where if there’s a particular stereotype of what/who success looks like in the group that you’re involved in, it will impact you. She also mentioned the impact that priming can have, where even just calling out that stereotypically girls don’t do as well as boys on math, will impact girls’ performance on a math test.
Eagerness to please and say the thing that the questioner is looking for also came up. For example, she shared a story of when she was at the hairdresser and wanted a style where she didn’t have to do anything to it in the morning (she doesn’t like to deal with it and doesn’t have any of the tools), and she thought she had made this clear to the hairdresser. Well, the hairdresser asked her mid-style if she had a flat iron at home, she agreed!
A tip for how to ask for understanding, but not phrase the question in a way that generates a “go-along” answer is “I told you that in my own words, could you please repeat it back to me in yours?”
She covered the concept of Rock Star devs, and how she doesn’t agree with that term because it calls out the cream of the crop, and then calls the rest of the majority stupid. It reinforces the terrible tendency to rank people – e.g. those who are good at maths and those who are not. People who can, people who can’t – back to that elitism. It also creates a self-fulling prophecy. They’ll also remember the feeling of failure and not want to experience it again.
When you assume good things, people will usually live up to those things. When hiring, look for people who can ask questions and have a thirst for knowledge. Encourage and praise this thirst for knowledge. One can’t learn if they fear being judged.
When sharing ideas, be aware that people may not understand what we’re saying, so make yourself understandable. And, if you find that you can’t explain it (simply), then you don’t understand it fully yet. One needs willingness to admit ignorance and believe that you have the right to know more.
She closed with the concepts of the Stupidity Manifesto that she’s working on, and the XKCD comic above about how there are always people learning something for the first time. In that vein, I’m so glad that she covered Imposter Syndrome and the Stereotype Threat to create further awareness as these are also things that I speak about.
Calendars for Humans – How to Undo the All Day Cram – Dominica DeGrandis
Full candor, I wanted to like this session, and I did get a good amount out of it; however, I struggled to see how the prioritization exercises directly tied into the calendar suggestions (which were awesome) – other than a way to prioritize work and visiblity show the impact of unplanned work, I’m not sure what value they had to “undo’ing the all day cram,” especially since it wasn’t about prioritizing one’s time. There were some helpful tidbits, but I couldn’t understand how it all fit together so I probably missed whatever the ephiphany moment was meant to be – who knows, maybe I’ll wake up at 2am with a giant “Aha!”
I’ll focus on my takeaways regarding the calendar suggestons. Dominica shared three types of common calenders: The 30 Minute Jam, The All Day Cram and the Triple Booked Wham.
- The 30 Minute Jam is where one has 10-12 meetings a day that are usually 30 minutes with tiny breaks in between. It creates a perpetual stop and go and exacerbates context switching. It’s a challenge to get meaningful work done, and usually it impacts Managers who have a number of 1:1s.
- The All Day Cram is where meetings are back to back and there isn’t even time to go to the bathroom and zero flexible time. This usually leads to people being dissapointed and wasted time rescheduling meetings.
- The Triple Book Wham causes problems because a person can’t be in three places at once. There is cost in rework because if that person is a decision maker, and they can’t make a meeting, the decision is delayed, or the team makes a decision that is changed, or work that went into the presentation/material becomes stale.
- She covered the Five Time Thieves and how they can steal our time.
- When talking about WIP, she described that the reasons we’re unlikely to say no, include:
- we like the people who are asking; it’s hard to say no to them
- we don’t want to let the team down
- we can have “shiny new object syndrome” and optimize for fun
- things can take longer than we expect because we don’t know how complex they are
- the “boss asked me” – as managers we need to make sure that we’re not overloading our team because they will say yes.
- She also shared some great calendar tips:
- For a Maker Calendar (those who are creative/makers like developers, designers, writers), there needs to be blocks of time chunks of 90 minutes to two hours for people to do deep and meaningful work. Suggestion is to try to schedule meetings earlier or later in the day to create space before and after lunch.
- For a Manager Calendar, managers can meet with other managers during those windows of time that the Makers are focused on their creative work. She recommends leaving unstructured time after department meetings in case there are any questions after the meeting. Managers can also hold Office Hours for team members to book time/stop by.
- Create Do Not Distrub times and make them visible by showing times that you’re “open” and “closed” for business by putting up a sign, using headphones, Slack status messages and/or any other indicator that you’d prefer not to be distrub unless it’s an emergency. However, you need to let people know when you will be available.
- Pomodoro Model, which is another interruption buster, which creates time-boxes for work that are separated by short breaks. You can set a timer for 25-30 minutes to have intense focus time.
Agile Tonight w/Paul Hammond
This year’s Agile Tonight focused on diversity and inclusion topics, stories, quiet reflection and learning and tactics for how to deal with the real world situations that were shared. I got quite a bit out of the session and really appreciated the stories that everyone shared, which I found very courageous.
The stats from the experiment were also interesting, espeically the breakdown of the percentages who had seen both sides of the narrative vs. those who had only seen one side (always or never).
I didn’t join the group when they continued the hallway conversation and built on the empathy wall, but I’m curious to see what was added tomorrow. Kudos to the crew for holding a large group session on such an important topic.