15. A Plan For The Next 24 Hours

Allen Holub on Deliver It, Jason Tanner on Drunken PM, Mary and Tom Poppendieck on Unlearn, Saron Yitbarek on Greater Than Code, and Dave Karow and Trevor Stuart on Deliver It.

I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [email protected].

This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting July 8, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers.

ALLEN HOLUB ON DELIVER IT

The Deliver It podcast featured Allen Holub with host Cory Bryan. Cory started out by reviewing an article by Ron Jeffries called “Story Points Revisited.” Allen’s take is that the negatives around story points are more than just the potential for misuse; he believes story points have no value at all. He says the most important thing is to narrow your stories, not estimate them. He says estimates exist because of fear. The software development process is opaque to certain managers and, as a result, they want estimates to alleviate their fear, but when you are delivering every day, you can eliminate the fear without resorting to estimates.

Cory asked Allen what product owners need to know about Agile architecture. Allen said that one of the mistakes that he sees product owners make a lot is they try to do a miniature up-front design and expect that to be implemented. When this happens, he says there is too much information captured up-front of what is going to be built during the sprint and not enough information captured during the sprint as a side effect of releasing code to users and getting their feedback. This leads to inappropriate architectures because when you do anything up-front, you start doing everything up-front. Your sprint planning starts involving architecture decisions, UI decisions, and UX decisions that may be wrong and you will not know if you are wrong until you release.

In Allen’s view, the most important thing a product owner does is answer questions that come up during the course of development. He uses a “two-minute rule”: if a question comes up during development, the product owner needs to be able to answer within two minutes.

Allen talked about how the constraints of a bad architecture can prevent you from ever being Agile. He says, “Agile has nothing to do with standup meetings and backlog grooming and all of those. The important thing is to get stuff into your user’s hands quickly.”

Allen says that the architecture has to be focused on the domain. Where systems that are wrong go wrong is that they don’t map to the domain but to the technology. A change at the story level, which is where the majority of changes come from, ends up touching all the modules or layers of your system when your architecture is mapped to your technology instead of your domain.

Allen says that when he does a workshop on Agile architecture, people raise their hands about halfway through and say, “All we’re doing is domain analysis!” The fact is, if the domain and code are matched to each other, domain analysis is architecture.

One of the questions Allen asks when he gets a bunch of product owners in a class is, “How many of you talk to multiple customers multiple times a day?” Maybe 5% raise their hands. So he says, “Who in the organization does talk to multiple customers multiple times a day?” This is often met with silence. He asks, “What about Sales? What about Tech Support?” He says that if you can’t respond to customer kinds of issues as well as a salesperson or a tech support person could, you don‘t know the domain well enough to be helpful to the engineering team.

Cory asked Allen what he thought of the distinction between regular stories and “technical” stories. Allen says that there is no such thing as technical stories. A story describes the users of your system performing some kind of domain level work to achieve a useful outcome. Fixing some technical thing like changing the color of a button in no way makes your end users’ lives easier; it does not help them do their work.

Allen says that the role of the architect in an Agile environment is very different from what we traditionally think of, just like the role of a manager in an Agile environment. In Agile environments, the job of people who are in a leadership position is to make sure that you can do your job, not to tell you what to do. They communicate a strategic requirement, provide support, and remove the obstacles. The same, he says, applies to Agile architects.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep90-agile-architecture-with-allen-holub/id966084649?i=1000441313352

Website link: http://deliveritcast.com/ep90-agile-architecture-with-allen-holub

JASON TANNER ON DRUNKEN PM

The Drunken PM podcast featured Jason Tanner with host Dave Prior. Dave started out by asking Jason why he believes the daily scrum is broken. Jason said that the daily scrum is broken because, first, most developers hate the daily scrum because most daily scrums take the traditional weekly project status review meeting and do it five times a week with the Scrum Master filling the role of the project manager. Second, he says, is that it is being done backwards. The center of attention should not be the Scrum Master, but the team and the sprint backlog.

He says that the purpose of the daily scrum is misunderstood. The three questions don’t result in a plan but result in just an exchange of information. For what real daily planning looks like, he uses an analogy of driving down the road and seeing a bunch of plumbers’ trucks from the same company parked outside of a McDonald’s. Inside, they’re planning things like, “We’re going to the Johnson’s house at noon. Can you come over and meet me because it’s going to be a two-man job.”

Jason says he hates the three questions. He says the subject of the sentence is not helping us in collective ownership of the sprint backlog. “I have my user story. I have my Jira ticket. I have five team members and we each have a ticket.” Shifting the subject of the sentence to “we”, he says, changes the behavior dramatically.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum/id1121124593?i=1000441958371

Website link: https://soundcloud.com/drunkenpmradio/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum

MARY AND TOM POPPENDIECK ON UNLEARN

The Unlearn podcast featured Mary and Tom Poppendieck with host Barry O’Reilly. Barry asked Mary and Tom what we may need to unlearn since the Agile movement began. Mary says that Agile started as a reaction to what was going on at the time. The vast majority of people doing software engineering today weren’t around back then. One of the things Agile has to do is grow up to be not a reaction to bad things that happened in the past, but to be something that talks about, “What does it take to do good software engineering?”

She contrasted the software engineers she speaks to today that expect to be handed a spec with the engineers she worked with early in her career who treated engineering as problem-solving.

Tom talked about how many who are working to make organizations more agile attempt to solve problems with process. This assumes that the organization’s problems are process problems but they are actually architectural problems. This includes problems with the architecture of the applications they are evolving, problems with the structure of the organization, and problems with the structure of the relationships between the supporting groups and those who are benefitting from said groups.

Mary talked about how Amazon AWS was one of the early organizations to understand that you need to give teams of smart, creative people problems to solve. As a result of having this insight, they organized the company in such a way as to optimize for this, such as by eliminating a central database which was heresy back in 2005. She called out AWS Lambda in particular because this product did not optimize for short-term shareholder value and would never have been approved at most companies because it reduced what Amazon was charging customers by five times. She attributes this ability to self-disrupt as being essential to Amazon AWS’s success.

Tom talked about the fact that when you attempt to scale things up, you reach a point where complexity dominates any future gains and wipes them out. He says you instead need to de-scale: figure out how to do things in little chunks that are independent and don’t require coordination. He says that this is how cities have been organized for thousands of years.

Mary said that she has been doing software since 1967 and has never seen anything last two decades and still be current. Agile is two decades old and cannot be current unless it is constantly adapting to what is current today. She brought up continuous delivery as a fundamental change in agile thinking. It changed the way we thought about how we structure organizations and teams and what kinds of responsibilities we should give to them.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/solving-problems-safely-with-mary-and-tom-poppendieck/id1460270044?i=1000442018979

SARON YITBAREK ON GREATER THAN CODE

The Greater Than Code podcast featured Saron Yitbarek with hosts Arty Starr, Rein Henrichs, and Chanté Thurmond. They talked about the annual Codeland conference Saron is running and how it offers free on-site childcare this year. Saron says free on-site childcare at conferences today is where codes of conduct were a few years ago. She says that if her conference wasn’t making it easier for parents to attend, it wouldn’t be living up to their promise for inclusion.

Chanté asked Saron what she learned in her transition from being a code newbie herself to the present day where she is running two podcasts, a software job, and a conference. Saron said she learned that it is important to be consistent in all your efforts, whether it is community work, your personal projects, or a project at work. Nothing gets built overnight and, for a while, nobody will care what you’re doing. If you want to do something great, it takes persistence and it takes you believing in yourself especially when you’re not getting external validation.

Arty asked about what expertise in “newbie-ism” might look like. Saron says that it is about being comfortable in a state of frustration. She pointed to a study on the difference between those who finish a computer science degree and those who quit. The study said that those who finished the degree were comfortable being in a state of confusion: they knew that things were not going to make sense for a while and they were ok with that.

A second thing, she says, that helps you become an expert newbie is realizing that almost all problems in coding are solvable. By contrast, in writing, there is no perfect essay. In journalism, there is a search for truth, but is truth attainable? In life sciences, we study nature all around us that we may never fully understand.

She also says to keep your frustration external, avoid internalizing your failures, and she says to distance who you are from your work and the things you produce.

Saron’s comment on being comfortable in a state of confusion triggered a Virginia Satir quote from Rein: “Do you know what makes it possible for me to trust the unknown? Because I've got eyes, ears, skin. I can talk, I can move, I can feel, and I can think. And that's not going to change when I go into a new context; I've got that. And then I give myself permission to say all my real yeses and noes, because I've got all those other possibilities, and then I can move anywhere. Why not?”

Rein asked what Saron learned about teaching. Saron says that teaching is storytelling in disguise. She says that if we frame teaching opportunities as storytelling opportunities we can be better teachers. This reminded me of Josh Anderson’s comment on the Meta-Cast podcast that I referenced way back in episode 3, “Taking The Blue Pill Back To Sesame Street.”

Rein brought up a theory of learning called conversation theory. In conversation theory, teaching happens as a conversation between two cognitive entities. You have to come to agreement and build a bridge with that other cognitive entity. It deconstructs the teacher-learner binary. The teacher themselves has to be a learner too.

Chanté asked about the ethos at Code Newbie for being a learner and a teacher. Saron says they look to the community to pitch in. When someone asks a question, they encourage the community to answer. She contrasted Code Newbie with Stack Overflow. Code Newbie attempts to teach the learner from where they are and avoid the condescension that is common on Stack Overflow.

She said that to create an environment where people are not afraid to ask questions, we have to be unafraid of being vulnerable ourselves. Go first, share your vulnerability, and share what you’re struggling with. The moment you start doing that, other people will be much more likely to raise their hands as well.

Chanté asked Saron what resources she recommends for code newbies to learn to code. Saron said that the hard part isn’t finding resources but sticking with them when things get tough or boring.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/135-intentional-learning-with-saron-yitbarek/id1163023878?i=1000442022293

Website link: https://www.greaterthancode.com/intentional-learning

DAVE KAROW AND TREVOR STUART ON DELIVER IT

The Deliver It podcast featuring Dave Karow and Trevor Stuart with host Cory Bryan. They talked about running experiments to learn about your customer. Cory asked how people can run such experiments at scale. David pointed out that having a way to run the experiment is one thing, but you also need to be able to rapidly make sense of the results in a repeatable, authoritative way. Trevor says it is all about assumptions, hypotheses, and documentation. Before you even start your experiment, you need to understand why you are running it in the first place. In other words, you need to establish what is going to change as a result of the experiment.

Trevor says that much of the market is already doing experiments and they don’t know it. They just call it “using feature flags” and rolling things out incrementally. They just need to move one step further to slice and dice their user populations, roll things out for longer time periods to those users, and bring the resulting data into a form that facilitates decision-making.

David talked about dog-fooding by starting your rollout of new features with your employee population, giving examples from Microsoft, where it takes a few weeks to go from the employee population to the full customer population, and Facebook, where it takes about four hours for the same kind of rollout.

Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep91-product-experiments-with-trevor-and-dave-from-split/id966084649?i=1000442844631

Website link: http://deliveritcast.com/ep91-product-experiments-with-trevor-and-dave-from-split

FEEDBACK

Ask questions, make comments, and let your voice be heard by emailing [email protected].

Twitter: https://twitter.com/thekguy

LinkedIn: https://www.linkedin.com/in/keithmmcdonald/

Facebook: https://www.facebook.com/thekguypage

Instagram: https://www.instagram.com/the_k_guy/

YouTube: https://www.youtube.com/c/TheKGuy

Website: https://www.thekguy.com/

Intro/outro music: "waste time" by Vincent Augustus