A Plan For The Next 24 Hours

The Agile architect’s job, the purpose of the daily scrum, giving engineers problems to solve, teaching as a conversation, and business-to-business experimentation.

Monday, July 8

On Monday, July 8, I shared a link to an episode of the Deliver It podcast featuring 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 is 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 hand 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 hand. 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 applies to Agile architects, as he says in the quote in the image above.

Wednesday, July 10

On Wednesday, July 10, I shared a link to an episode of the Drunken PM podcast featuring 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 he says should not be the Scrum Master, but the team and the sprint backlog.

He says that the purpose of the daily scrum is misunderstood as he describes in the quote above. 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.

Friday, July 12

On Friday, July 12, I shared a link to an episode of the Unlearn podcast featuring 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. This led to the quote above.

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.?

Monday, July 15

On Monday, July 15, I shared a link to an episode of the Greater Than Code podcast featuring 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. It takes persistence and it takes you believing in yourself even when you’re not getting that external validation to do something great.

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 that 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 back in the January 21 – February 1, 2019 Fortnight In Review.

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 as he says in the quote above. 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 hand 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.

Wednesday, July 17

On Wednesday, July 17, I shared a link to an episode of 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.