Ted Talks (Book Review)

TED talks often get me intrigued and inspired about topics that I sometimes hadn’t thought about before. As someone who speaks to various audiences at work and at professional events, I’m always looking for ideas about how to be a better speaker, and TED Talks, The official TED Guide to Public Speaking sounded like a promising resource, and I wasn’t disappointed. The book provides some good guidance about everything from developing an idea to actually speaking on stage. Even if you never expect to speak on the TED Stage or any other, the book still has value. Anderson points out early and repeatedly that “presentation literacy” is an important skill for everyone. Even if you never present to a formal audience, learning how to organize and distill what you want to say is a valuable skill, and many of the concepts are relevant to writing as well. Keeping “presentation presence” in mind can be useful even if you are sharing an idea with a colleague. If you want to be a better presenter (in any context) this is a worthwhile book to read.

A key premise of the advice here is that an effective talk isn’t meant to convince or lobby, but to share your passion for an idea, and perhaps spread it to others. While this may sound like this book is not useful to those who are interested in selling ideas or convincing others, it may actually be. My first post-college job involved doing a bit of pre-sales technical support and the sales manager I worked with told me that “people told like to be sold to, they like to buy.” This resonates with my experience. If you can share well an idea that you are passionate about, you’ll find the people who are interested, and you avoid the discomfort that people often feel when they are receiving a sales pitch.

While reading I was both excited and saddened as Anderson explained why some conventions that you may have learned about presenting are a best not valuable, and at worst a distraction. I was excited because books such as Presentation Zen and Back of the Napkin helped me to understand that slides and other visuals are there to support your ideas, not be the medium for presenting them. But even with the popularity of TED and other approaches that get us away from the text heavy, read your bullet point slides approach Powerpoint presentations with dense bullet points seem to be an organizational standard that is hard to change. Even in elementary school, where powerpoint is a presentation option I cringe when I see the patterns that my son follows when doing a presentation for an elementary school class.

Anderson includes examples from a variety of good (and not so good) TED talks, which makes some of the abstract ideas more concrete. In some cases, he over does it, which makes the book longer than it could have been, but that is not a fatal flaw. When combined with the pointers to TED talks in the back, the examples make this book a bit of a “best of TED,” and a great way to learn more about the scope of TED topics if you have only seen a few.

Overall, this is a useful book that can inspire and guide you being a better presenter of ideas. Even if you don’t intend to present the first section will help you organize your ideas better. And the need to present may happen when you don’t expect it. The book ends with a survey of techniques to try and venues to practice. Even if you don’t expect to be a future TED presenter, this book can help you be a better presenter in any venue.

Starting and Closing Agile Retrospectives with People in Mind

One of the more powerful aspects of agile software development methods such as Scrum is that they acknowledge the importance of individuals and their interactions in delivering quality software. As much as it is important to review and adapt the product backlog by having sprint review meetings at the end of each sprint, it is also important to have retrospectives to inspect and adapt how the Scrum process works on a team. The Sprint Review is about the tasks and scope (the “What” of the sprint). The Sprint Retrospective is about the Scrum process (the ‘How”). Sadly, many teams miss out on some value by glossing over the parts of a retrospective that acknowledge the human elements of the scrum process. By using some simple techniques teams can improve their retrospectives by putting more emphasis on people.
Allocating time for a retrospective every 2 weeks (if you use 2 week sprints) can be a challenge. The 5 step structure that Ester Derby and Diana Larson describe in their book Agile Retrospectives is an excellent framework for making good use of retrospective time. The steps are:

• Set the Stage, where you introduce the plan for the retrospective, and help people move towards a mindset that will help identify problems
• Gather Data, where you collect information about what went on during a sprint. Some of the data collection can happen before the actual meeting, but people will likely think of information to add.
• Generate Insights, where you identify patterns and connections between events, and start to consider why things may have happened.
• Decide what to do, where you collect ideas for things to do going forward, and then focus on a handful to explore in detail.
• Close, where you review action items, appreciate the work people did, and perhaps discuss the retrospective.

These steps create an environment where people can feel safe, and help the team to explore the really impediments to improvement. Often teams skip steps, merge steps, or don’t consider whether the exercises they use at each stage move the process forward. Using structured exercises like those in Derby and Larsen’s book help keep the retrospective focused. Another common tendency is to problem solve too early, combining the Gather Data, Generate Insights, and Decide What to do steps. These mistake is often self correcting, as teams discover that they come out of retrospectives with actions that address superficial problems.
A bigger problem is when teams skip the steps that address the humans on the agile team. For example, particular, some facilitators skip over Setting the Stage, or Closing, in an effort to allow time for the “significant” parts of the meeting. While only a small part of the meeting time, the Setting the Stage and Closing steps, are quite valuable in terms of impact.
Setting the Stage for the retrospective can take just a few minutes, and can improve the effectiveness of the entire meeting by creating an environment where people feel comfortable collaborating. There are many reasons people may not contribute, including simple shyness or lack of attention, or even concern about getting blamed for something. Setting the Stage correctly can help engage the team more fully in the process by bootstrapping participation and emphasizing that the retrospective is about improvement not blame.
I often start a retrospective with an exercise that involves going around the room and giving people a chance to say a word or two about something, for example “one word about how they feel the sprint went”, or “how they feel about the retrospective ”, or even “one thing about yourself that you’d like you share with the team.” This often helps people step out of a spectator role. Note: Always give people the option to say “Pass,” since forcing people to reveal something about themselves is counter to the values of a retrospective; even saying “Pass” gets people engaged in the process.
To reenforce the constructive goals of the meeting, teams I work with sometimes start retrospectives by having someone read The Retrospective Prime Directive, and ask everyone if the agree. While some people initially feel like this process is a bit silly, may teams find it valuable, and make an effort to rotate who reads the Prime Directive.
The other part of the retrospective that can help maintain connection is the Close. I encourage teams that I work with to incorporate appreciations into their closings. Appreciations are a structured way of acknowledging the work someone did during the sprint. A quick appreciation can really help people feel engaged and valued, and the process helps the team consider the value each brings to the group.
By setting the stage and closing your retrospectives well you can help your team get more value out of retrospectives, and help form a stronger, more effective team. Inspect and Adapt isn’t just about the tasks, it’s about the how the team works too.

Grit with the Nuances (Book Review)

The headline version of what Grit is and how it is important to success doesn’t do the concept justice. That hard work and persistence are as much, if not more, important to talent for success is both appealing on the surface and simplistic. Many subtle details get lost in the elevator pitch, and reading Grit answered many of my questions, and gave me some guidance on how to be more successful in reaching my goals, and how to give my child tools to do the same.

Duckworth draws on the work of people like Cyzmenthaly (Flow), Seligman (Learned Optimism), Carol Dweck (Mindset), Adam Grant (Originals, Give and Take ) . I’ve followed the work of all of these people in my quest to better understand how to help teams be more effective, and also how to be a better parent. These concepts are more widely applicable than you might initially think. Flow first came to my attention via Kent Beck, and Learned Optimism via a reference in a book by Jurgen Appelo (Management 3.0) Team and family dynamics have a lot in common.; Gerald Weinberg often refers to the work of Virginia Satir in his writings on quality management.

Through a combination of summaries of her research, stories, and discussions of things to do Duckworth both helps you understand the nuances of grit, and give you ideas for ways to understand and improve the level of grittiness for yourself and those in your charge. Parents, managers, and leaders will find this book an inspiring read. Well written and easy to get through quickly, and you will find yourself wanting to refer to your notes and bookmarks often.

My favorite line from the book is “before hard work comes play” which summarizes the concept that to be gritty you really need a goal that engages you, and it may take some time to discover that. While some of the headlines on grit left me wondering about were how much torturous hard work was involved in being gritty as opposed to just having fun, Duckworth’s use of the phrase “play before passion” was both comforting and intuitive to me. It takes a while to understand what gets you interested, and only once you find those things can you apply yourself in a way that doesn’t totally wear you down.

If you’ve read Mindset, Originals, or Give and Take, there will be some familiar moments. Flow, Learned Optimism, Growth Mindset, and Grit compliment each other; one can lead to another. That I’ve read many of those books over the years in my quest to better understand motivation and engagement (and thus try to be a better manager and parent) may speak to my “Grittiness”

Duckworth also speaks to the issue of practicality. Some passions aren’t practical pursuits, but she gives examples of people who incorporated seemingly impractical passions into their more pedestrian careers to be both successful and helpful. Likewise she relates stories of people who do seemingly mundane things (managing a subway system, managing a janitorial company) and find it extremely rewarding. Since you can only have so many goals that you can focus on, finding commonality between goals is also helpful. For example, many of the things I learn about being a better parent are applicable in people management, and vis versa.

Along with a non-academic description of the theory of Grit, Duckworth discusses how you can better understand and develop your Grittiness and help your children develop it. This book goes into more detail about what Grit is, resolving many of my questions about what Grit really meant and how to improve it (possible) and measure it (not simply). This is a very clear discussion of what Grit is, and is not, and also a pragmatic guide to finding your passion, and develop your skills. If you are a parent, a manager, of just someone trying to master a skill, Grit will inspire you and give you much to ponder.

---

_ _ _

Recent Reads: Leadership, Use Cases

Here are a few articles I’ve read recently that I though were worth sharing. The first two are by Kate Mastudaira, who’s ACM articles on people management are always well written and often seem to be consistent with things I’ve learned from reading and speaking with Jerry Weinberg. The third is from the person many most associate with Use Cases, Ivar Jacobson, about an update to Use Cases that seems to align more closely with agile methods.

Delegation as Art by Kate Matsudaira

A good discussion about what it means to be a “senior engineer.” in particular, “senior” implies leadership, which implies teaching. This quote hits the highlights, but the article is still worth a read:

Being a senior engineer means having strong technical skills, the ability to communicate well and navigate ambiguous situations, and most important of all, the ability to grow and lead other people.

Nine Things I Didn't Know I Would Learn Being an Engineer Manager by Kate Matsudaira

This article explains why being a good engineering manager is not all about technical skill, but also (more so?) about communicating, coordinating, and listening. Kate Mats also shares links to resources about techniques to use to improve your non-technical skills. Whether you agree or not with what she says, her points can get you thinking.

Use Case 2.0 by Ivar Jacobson

This article goes into an updated view of use cases, adopting a few ideas from agile planning. Since Use Cases are the canonical way people like to talk about requirements on traditional projects, knowing about this might be a good way to bridge the gap between “waterfall” and “agile” projects.

Giving, Taking, and Being Successful

I’ve been making good use of my commute time recently, catching up on reading, and in particular, the stack of physical books on non-fiction topics that are somewhat relevant to my work. I was making good progress, only to have new, interesting stuff cross my path. One Sunday morning in December I caught part of an interview with Adam Grant on On Being. I wasn’t familiar with Adam Grant before this, but I’m extremely glad that I caught the show. I soon got a copy of Give and Take by Adam Grant, and I read his next book Originals shortly after it came out. In the spirt of giving, and of the serendipity that led me to learn about Adam Grant, I’ll also mention some of the other books Give and Take brought to mind.

I read Give and Take by Adam Grant as last year ended. This is was a great book to end one year and start another with, as it got me thinking about the value of generosity, not just to others, but also to your self.

Grant explains how givers (as opposed to takers and matchers) get ahead in the long run and also help their teams succeed. Teams which have people who have a positive attitude towards helping others in small ways often do better in the end, and in the long run the helpers are more successful too. This goes contrary to the idea that the way that you make progress is to focus on what you need to do. The reality is that for most complex knowledge work, you can’t do it all yourself. As Austin Kleon’s Steal Like an Artist says, the best creativity is inspired by the work of others. Helping others both enables the larger unit to make forward progress, as well as making it easier for you to get help with your work when you need it.

The idea of people who make the team better, even when their short term contributions don’t seem as significant brings to mind "Catalysts" as mentioned by Tom Demarco in Peopleware.( Slack, another book by Demarco, also came to mind because of it’s discussion of the willingness of volunteers to contribute to efforts). This book also brought to mind another recent book, Invisibles, which discusses the “invisible” people who make things happen, and who are happy to be out of the spotlight. I don’t know if I can say that all invisibles are givers but I would not be surprised if that were true.

Giving can have limits. Many people struggle with how to balance the idea that being helpful and generous is good, while not overcommitting themselves. Grant explains how to be a giver and not overextend yourself. Likewise, givers often have a hard time taking care of themselves by leveraging their tendencies to advocate for others. Both approaches involve an an “otherish-strategy,” which is one of the more interesting (of many interesting) concepts in the book.

To those familiar with Jerry Weinberg, this will seem related to the Airplane Mask metaphor in Secrets of Consulting. Grant gives a more detailed model of how to think it through. Weinberg’s metaphor is still good to keep in in front of mind though.

This book resonated with me on many levels. There are lessons here that will help me in my roles an agile software developer, manager, member or my town community, and member of my UU church community. The information here resonates with, and explains, many things I've learned from Gerald Weinberg, about technical leadership (as in the book Becoming a Technical Leader, and Gil Broza about the agile mindset, and many other useful things I've read about how to be an effective team member.

This book will help you to understand why that's true, how you can be a more effective giver, and how to encourage others to give, so that you can be part of a more effective team or community. As Adam Grant says, we need more givers.

update March 28, 2016: Fixed reference to the correct Tom DeMarco book. I mentioned Slack. I meant Peopleware.

---

_ _

How Mindsets can Help or Hinder Learning (Book Review)

It was inevitable that I would read Mindset. Having recently read two books Give and Take by Adam Grant, and How Children Succeed by Paul Tough) which referenced this book, and having heard mention of it in other contexts as well. As promised on the cover, Mindset provides advice that you can apply whether you are a manager, worker, parent, teacher, or some combination. Carol Dweck does a great job of explaining an idea with a lot of research behind it in a popular book, without glossing over too many points. There were a few places where I thought the book dragged a bit, but those sections were brief and far between, and on net it was a quick enjoyable read.

The point of Mindset is that people have one or two mindsets: fixed mindset which is premised on the idea that you abilities and qualities are carved in stone, and the growth mindset which is based on the belief that your basic qualities are cultivated through effort. The 2 mindsets in Dweck’s model provide a powerful framework for understanding how people approach challenges. Those who approach situations with a fixed mindset are likely to see failure as a reflection of their value. Those with a growth mindset are more likely to see a set back as an opportunity to learn and improve.

People can have different mindsets in different aspects of their lives (work, relationships, artistic, technical). Dweck also explains that mindsets are “just beliefs” so you can change them if you want. Mindsets are not just a way people are. From the names you can guess that the growth mindset is the one that can lead you to better things. The most interesting parts of the book for me were the discussions about you can develop (in your self) and nurture (in others) a growth mindset.

While the fixed mindset v growth mindset concept seems simplistic at first glance, it is seems extremely powerful. While reading I found myself thinking “so maybe that is why I do that…” or “maybe I should consider the mindset model when dealing with a colleague.” Since the book wraps up with a focus on education, it led me to consider my approach to encouraging an motivating my (as I write this) third grader .

Since mindsets are not innate, one might ask why anyone would stay in a fixed mindset. The discusson of why that happens lie the most interesting lessons for self-improvement. Your mindset can be re-enforced early in life, and like all things that connect back to childhood experiences, the messages you get early in life are hard to get past, even if they are slowing you down. Dweck shares both data and anecdotes of how various mentors tried to help students ended up moving from a fixed to a growth mindset, with various degrees of success. That all of the stories are not “fairy tale” success stories grounds the concepts in reality. All change is hard, and not everyone can success absolutely. But you can benefit from trying.

Dweck discusses the application of mindsets in many realms, including business, relationships, and education. The book ends with an explanation of a program for elementary schools to help develop growth mindsets, which is appropriate given the focus of Dweck’s research and the value of improving mindset early on. The area that is most interesting to me professionally is how the mindset model relates to leadership approaches.

We often think of leaders in terms of raw ‘talent’ … and that “effort” is for those who don’t have talent. In reality it takes both effort and talent to be continually successful. Dweck explains that more often than not great leaders are the people who were constantly trying to improve, and who don’t have all the right answers starting out. What leads to success is willingness to make a effort to improve. Raw talent helps, to be sure, but it can’t sustain success.

One thing that the book didn’t address for me, though perhaps the answer is obvious, is the question of sustainability. If a growth mindset is good, and is all about meeting challenges, would a growth mindset lead to you overextend your self? Is what we might call “knowing your limits” a manifestation of a fixed mindset? I suspect that the answer is no. There’s a difference between having a perspective that obstacles can be overcome, and having the energy or bandwidth to meet all challenges head on.

There are number of lessons I felt that I could apply immediately to understanding my personal life, helping my (as I write this) third grader, and understanding how to work with teams and people at work. Mindset can inspire you to meet challenges with more confidence, and help you to better understand your interactions with others.

---

Books mentioned in this article:

Team of Teams: An Unexpected Source of Agile Inspiration

One can find insight in unexpected places. Team of Teams by General Stanley McChrystal et al is a book about dealing with organizational complexity, written by a general, which uses the war against Al Queda as a common thread. I was somewhat skeptical that I could find information here about software teams that I'd find immediately useful, regardless of how interesting it was. I was wrong. In addition to the advice I was expecting to read about team dynamics, I gained some insights that I thought would be immediately applicable to scaling Scrum Teams.

Fairly early into Team of Teams the authors explain that this is not a war story. While it's true that the common thread in the book is how General McChrystal worked to get the army more able to adapt to a decentralized, agile enemy, there are are also stories from commercial aviation, NASA, and corporate America. While there is a fair amount of military history in this book, there is also a discussion of the history of manufacturing process improvement, office space, and even personal stories about gardening.

The message in this book is that command and control structures don't work in complicated, information rich environments that deal with complex problems. He defines complicated as "having many parts" and complex as having many interactions. To get things done in this kind of environment you many need to cast aside what you are used to thinking of an efficient approach.

McChrystal draws a contrast between being resilient and being robust: The more you optimize a complexy system for a specific goal, the less resilient it becomes. Likewise efficiency isn't always better than adaptabilty: you can build a system that is good at doing things right, but is too inflexible to do the right thing. Redundancy and overlap can enable adaptability; an efficient system that does the wrong thing doesn't add value.

Had McChrystal been delivering this message in the context of a corporate enviroment, you might dismiss this as another instance of someone who is in an environment suitable for agile singing the praises of agility. That he's talking about battle command situations, the canonical top-down environment, gets your attention. As with Turn the Ship Around this provides evidence that an "agile" approach can work in more circumstances than you might guess.

At the core of the book is the philosophy that too much control of information and decision making slows down a group's ability to react to situations. The situations described in the book were ones where the risks of acting too slowly are higher than the risks of competent peope making judgment calls. Automomous decisions are usually good as long as they are visible and shared. While most business decisions don't have the same life or death implications of those made in a war zone, slow decision making can have a business cost, and potentially a morale cost if people feel undervalued and micromanaged.

McChrystal advises us that it's not enough to "empower" people in name only. Automony and delegation only work with a clear understanding of a common purpose. Communication channels and shared information are important to both sharing the common purpose and giving people the tools to act in a manner consistent with that purpose. One technique he used was to provide for open office spaces. McChrystal acknowledges that open office space only improves team productivity when everyone is working on related problems, and that open office space as a way to be "space efficient" is productivity inefficient. Video conferencing for his troops was also important, as his teams needed to communicate with others in remote places. As someone who works in a company with people in multiple locations, the stories of the challenges of setting up video conferencing sounded all too familiar. That they were successful in a low bandwidth war zone situation was encouraging.

The book also had some insights about scaling teams that had an implication for scaling Scrum. While it's appealing to think of projects at scale as hierarchical, each level of hierarchy hides information. That can be fine when everyone knows what other teams need to know and not know. But that kind of knowledge is rare. McChrystal's approach to scaling is that everyone needs to know someone on every team so that information will flow organically.

I found both inspiration for seeking ways to improve, and practical advice about how to structure teams and be an effective manager in this book. While not about agile per-se, I think that there are lessons here that apply to those trying encourage agile adoption in a non-agile situation, and also for those looking to scale agile.

---