Rusty Divine

Live, Love, Learn, Teach

The Leader’s Guide to Speaking with Presence

“The Leader's Guide to Speaking with presence: How to Project Confidence, Conviction, and Authority”, by John Baldoni.

The Big Idea:

There are a few guidelines when creating a speech or presentation that will help make it worth the audiences’ time to attend. Keeping these in mind while creating, revising, practicing, and delivering a presentation will make the most impact for the message.

This book also briefly discusses tips for improving leadership through communication, mediation, and active listening.

Book Notes:

This guide is very concise – many of the ideas are covered with just a paragraph or two and some of the leadership advice isn’t much more than some bullet points. I do appreciate brevity and was not disappointed because the advice is quite good and makes a great reference.

Tips on Speaking

John describes what it takes to deliver an effective presentation. Here are some highlights:

  • Structure speeches like a composition - with opening (attention grabber), pitch (make music worth listening to), rhythm (pace), pause (if you do nothing else in your next speech, pause), closing.
  • Know well what you are going to say and what's coming next and the context so that you can diverge from the memorized script.
  • "Metaphorical handshake" - make personal contact with audience by smiling, relaxing, being at ease. Acknowledge them before you launch and break the ice with a brief personal comment.
  • Make the audience feel welcome, as if you have invited them into your home and want them to enjoy the evening - they want you to succeed. It's good to think of it like your home; you own the stage and can help them have a good time.
  • Good posture is important for conveying what you are saying is important to you and that you want people to consider it. Practice breathing regularly.
  • Don't undercut your message with self-effacing quips about poor quality of your slides or audio. Lead the presentation through any difficulty by being able to describe the message.
    • Don't read your slides - just show the concept on the slide through a few words or pictures and fill in the rest with your speech.
  • An entertaining speech can be more memorable, especially if you can wrap your main message in a summary that is humorous.
    • A story is a very good vehicle for getting a message across, too.
  • Tailor your optimism so that you consider the possibility for set backs so that you rebound gracefully
  • Consider what you would want your audience to think or do after hearing your speech when revising it.
  • Restate questions so everyone can hear. Handle objections by acknowledging their merit and it's ok to say you don't know, but will deliver an answer later. Always tell the truth.

Tips on Leadership

John also has some advice for leading teams. Two pieces resonated with me:

  1. Develop your elevator speech for every single key issue, and
  2. Refrain from voicing your opinion first because it may color the opinions of your team.

The first reinforces something I’ve been considering as an app that I could make to help keep short bits of information at easy recall with mnemonic techniques, and the second as part of my effort to encourage more participation on the software development team I’m a member of.

Related Material:

In addition to this book, I also recommend: speaking.io, How To Win Friends and Influence People, and JohnScott’s presentation and guides to technical speaking (also on Pluralsight).

Tools: impress.js, zoomit, onslyde, slideshare, animoto, archives

An Agile Principle for Hobby Software

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

That's the first of the twelve agile principles, and arguably the only one that stands heads-and-shoulders above the rest. The other eleven principles could be described as a mix of technical and practical guidelines with more or less the same importance as their neighbors.

The principles are targeted, yet generic at once in order to accommodate the various modes of software development. They are flexible enough to help us make decisions when building enterprise software, commercial software, open source software, line of business software, or hobby software.

The principles help guide decisions, but are there extreme environments where they begin to break down? What happens when a project's velocity, the number of features that can be produced in a set period of time, trends towards zero or grows towards infinity? Do some of the principles become more important than others? Do any principles become irrelevant, essentially falling off the list?

One could imagine other environmental extremes that may also affect the principles, like writing software without a customer in mind, writing software that no one will ever use, writing software with extremely short or expansive deadlines, software that is incredibly small or large, and  writing software where there is an absence or abundance of trust, just to name a few.

The disc golf app that Adam and I have been working on has been a bit challenging to manage with the agile process because our velocity so so low - we are doing good when we are able to dedicate 6 hours a week each to the project. Based on the few agile teams I've been on and their average hours-to-points (I know, that conversion can make a scrum master pucker) that could yield a 10-to-15 point velocity at a one-month iteration. It would be common for teams to do 70 points in an iteration of two or three weeks, so 10 points in a month is like a turtle's pace.

Our first iteration, which was the month of November, was just two stories. I set up the architecture and Adam did some user interface design and mockups. I don't think either of us were ready to close out our stories, so we probably didn't even burn down.

With a velocity so low, I argued that we shouldn't task out our stories. I didn't want to allocate time to think about breaking out our user stories into hourly tasks like we would normally. Our process was starting to bend to our new circumstances, but I think that's OK considering two important tenants of the agile philosophy: 1) Do only the what you need to get well designed, working software delivered, and 2) Use the periodic evaluation of what went well, what could have been better, and how you are going to improve to tweak your process.

After our first iteration, we decided that we did need to put a little pressure on ourselves in the form of a goal to strive for. Each year in February there is a tournament here in Lincoln called the Ice Bowl where you play no matter the weather conditions. You may need snow shoes or chemical heating packets in your shoes and extras in your mittens, but you play. We are going to have a working scorecard for the 2014 Ice Bowl. It will give us something to work towards and help us follow the simplicity principle - only do what is necessary, no more.

Our scrum master friend and sometimes boss Keil wondered at my use of the term "near-zero-velocity" when talking about our starting to abandon parts of our process. He wrote, "it makes me wonder what the point of any project is if you aren't willing or able to put more effort into it than is necessary to keep it on life support. Assuming we never have enough time to get it all done, does it make sense to say we're 'working' on a project where we never make progress towards completion? Maybe we should just shelve the project for a later time when it becomes a higher priority than the other attention grabbers that surround us."

I wonder if he'll be right or not, if we'll end up shelving this project because of lack of momentum. With family and work, it's hard to stick to a system of working on a side project. Adam and I both have young children that we don't want to sacrifice our family time with to spend time on this project. On the other hand, we both need an outlet for trying new technologies because we are both, at separate jobs, working with code that is several years old. If we want to stay fresh, we have to find a project to work on outside of 8-to-5. My primary reason for working on the Disc Golf App is to learn new technologies, build my portfolio, and share ideas via blog posts to help other developers looking to learn. I told Keil that even if this app never gets finished, I will consider it a success if I can use it to learn some new tricks and share them with the community. It is a principle that falls outside of the agile principles, but it trumps the twelve other principles for me for this project:

Strive to hone your craft by learning and applying new techniques and sharing that knowledge with others so that they may benefit.

Installing Ghost on Azure is now easy!

ghostThere used to be many, many steps to get Ghost running in Azure, but now it is available as a free website from the gallery on Azure.

After installing Ghost from the Gallery, navigate to the new website and tack /ghost/signup onto the end of the URL. You will be added as the administrator and taken to the blog post editor.

Checkout the docs for information on creating your posts and using markdown.

Agile Principles Exercise

Earlier this week our project manager, Keil, asked us to review the Agile Principles and pick one that we felt was most important to our project at this time, then justify our choice. We emailed him our results without talking to each other.

Today the development team (9 of us, including Keil) met to talk about what everyone picked. Our choices were scattered, but our rationales converged on the importance of getting working software in front of the end users to get quick feedback and promote trust between our two groups.

It was interesting that similar justifications could be made for so many of the different principles. Keil then showed the responses from the end users* and there was only some overlap with their choices, and their rationale converged on the importance of trust between our two groups – trusting us to deliver quality and expected functionality.

One of the dev team remarked that the end users’ chosen principles were less technically focused overall than the developers. I hadn’t realized it, but some of the principles do seem to be more technically focused while others are people-or-process-focused.

The only principle that more than one of the devs picked, “Simplicity--the art of maximizing the amount of work not done--is essential,” was not chosen by any of the end users. Coincidentally, we’re currently hashing out a new feature request from the end users that the dev team feels may be over-complicated while the end users are persistent in the request for it. There’s a related post about this on Keil’s blog.

I’ve been thinking about the agile principles and how to apply them to the disc golf app Adam and I are working on. It’s been a struggle to tailor the process that is appropriate for a project where we can apply 8 hours a week between us to it. I’ll post something on that later, along with some of the input Keil has on what we’re doing now.

 

*We’re fortunate to be able to work with our end users every day because they are directly down the hall from us, so getting feed back is very quick and relatively easy for our team.

Remember to set the Target Framework

This is the second time in a few weeks where I have had a wtf? moment caused by not setting the Target Framework for a new project to the correct version.

Today it was missing an EmailAddress data annotation from the System.ComponentModel.DataAnnotations reference. I know the EmailAddress annotation should be part of that library, and my reference showed the correct library version (4.0.30319), but the EmailAddress just sat there with that red squiggly line mocking me.

Until I remembered to update my Target Framework from .NET Framework 4.0 to .Net Framework 4.5.

TargetFramework

Team Geek

Team Geek: A Software Developer's Guide to Working Well with Others, by Brian W. Fitzpatrick and Ben Collins-Sussman.

The Big Idea:

Humility, Respect, and Trust – HeaRT – are what it takes to be a great person and team member, in fact, it’s what is going to make or break your career.

Humility: Be open to self improvement and being wrong. Seek out other opinions and treat them fairly. Lose the ego – don’t comment on every discussion, be willing to conform some so that you don’t spend energy struggling against the system, and learn to take criticism.

Respect: Care about other people and their emotions. Appreciate their abilities and accomplishments.

Trust: Lead with believing people will do the right thing and want to do it well. Let yourself be vulnerable and trust that your team will not harm you.

Book Notes

Gone are the days of the Genius Programmer in a private office churning out code or technical specifications isolated and uninterrupted. Today we expect our teams to communicate continuously, be open to alternative ideas, and to put the code before themselves – you are not your code.

The authors state that “Almost every social conflict can ultimately be traced back to a lack of humility, respect, or trust.”

A manager needs to make it obvious that she trusts her employee and the employee will feel positive pressure to live up to that trust.

“The best advice we got when we first became engineering managers at Google was from Steve Vinter, an engineering director. He said, ‘Above all, resist the urge to manage.’” The authors believe the most important thing a manager can do is to serve her team.

Managers, don’t:

  • Ignore low performers
  • Ignore human issues
  • Be everyone’s friend
  • Compromise the hiring bar
  • Treat your team like children

“The engineer asking for advice typically doesn’t want you to solve his problem, but rather to help him solve it, and the easiest way to do this is to ask him questions.” Knowing the right question can be better than knowing the answer.

Managers need to shield their teams from chaos. Keep the second guessing, power struggles, budget concerns, and other external drama away from the team. This can be very difficult if you have a good relationship with your team, but it’s important to separate your responsibility to protect the team morale from your urge to be transparent with them.

“If you have six kids and give each one the same amount of water, light, and fertilizer, they’ll all get equal treatment, but the odds are good that none of them will get what they actually need.”

Engineers crave autonomy, mastery, and purpose.

On difficult team members

Try not to think in terms of bad apples, but in bad behaviors. It’s the behaviors you want to filter out, not the people. “If, after repeated warnings, the behavior doesn’t change, only then does it makes sense to consider formal rejection.” Will the project still benefit in the long run with this person who exhibits bad behavior?

Managers need to be intolerant of destructive behaviors, and explicit about the team approaching each other with HRT.

On Communication

A good email is short. If you need something from the reader, it should be three bullet points or less and one – and only one – request.

 

OWASP - Lincoln

Interested in learning more about making your software secure?

 

Drop me a line if you’d like to be invited to an OWASP meeting in Lincoln early next year.

 

OWASP is a global community that drives the visibility and evolution in the safety and security of the world’s software.

 

Rob Temple leads the Omaha chapter of OWASP and we would like to explore the interest level in Lincoln by coordinating a lunch-time meeting early in 2014.

 

Some example meetings topics from the Omaha chapter:

•Thu Jun 6, 2013 - Web Application Security - So many tools, so little time

•Thu Sep 12, 2013 - The OWASP Way: Understanding the OWASP Vision and the Top Ten

•Thu Dec 5, 2013 - Advanced Mobile Penetration Testing

Try, then Ask Rule

Matt’s “You Must Try, and then You Must Ask” rule reminds me of why I love working on a team.

I have worked remotely before, for a stretch of 4 years, and not only was I working from my house, but I was the only developer on a project most of the time. I also have good friends who are doing well as sole proprietors in software consultancy and have considered whether I should follow their lead.

I know I could do it again, but I would prefer not to. I enjoy talking with my team and having someone around to jolly me out of a funk. Learning is accelerated by seeing how my other team mates are structuring their code and talking about what frameworks they are interested in. Not being the only person on the hook if a deadline is missed or a customer is unhappy is an incredible relief.

At work, we’ve often repeated the mantra that if you get stuck, make sure to ask someone. We have a stand up each day that should bring anything seriously blocking to light – it forces us to be accountable to each other. What I really like about Matt’s post though is that he has dug deeper than the surface to give some solid advice:

  1. If you’ve hit a point of giving up, give it another 15 minutes.
  2. During those 15 minutes, you must document everything you’re doing so that you can tell someone else.
  3. After that, you must ask someone for help.

I like that the second step is to document what you need to do to explain it clearly. Often, I get wrapped up in something I didn’t expect and just confuse myself. When I call someone over to explain it, I end up figuring out the problem myself just by talking through it logically – so, this step can often save my team’s time because often it will be enough to solve the problem.

Disc Golf App’s Base Stories

We’ve created 20 user stories for our Disc Golf App, some of which will need to be broken down into smaller stories.

We’ve agreed that the solution should be a mobile website instead of an app. I need to do another post to justify this more, but in a nutshell: app stores take 30% of what you make and cost $100/year to keep open, and a large percentage of the proceeds go to a small percentage of very successful developers, and developing once and working everywhere is sometimes possible with tools like Phonegap, but maybe you should just learn objective C, etc.

We’re working on Iteration 0, which includes loading the product backlog, deciding on an architecture (Now researching SPA with Breeze, Angular, WebAPI on Azure), and doing some mockups (Balsamiq). I’ve even done a few Lean Canvas plans, which helped me think about the app from different angles.

The duration of Iteration 0 is open-ended at this point, but we’ve agreed to each put in 4 hours/week.

We’ll need to do some prioritizing of the backlog, which we’ve done conversationally, and then point some of it so that we can fill out Iteration 1. We’ll probably time box the iterations, but will need to discuss how long they should be. We’re used to spending about 60-70 hours between us on an iteration, which would be something like 9 weeks at our hobby pace – so maybe we’ll cut that in half and do one iteration per month. We’ll need to figure out our velocity, but having worked together on many projects before, that should be pretty smooth.

Costenvine

I recently changed jobs. The upside is that I am really enjoying the team I am working with and the project we’re working on. The downside is that I no longer work with my good friend Adam.

Today, I am happy to say, we have decided to embark on a side project so that we can continue to work together. Of a list of 15 or so ideas, we came back to the one idea we each separately had when we started working together a year ago – a Disc Golf app.

Approach

It’s funny that when thinking about a project done on my own time, my first tendency is to disregard any formal process and just git ‘er done. Why waste time on user stories and mockups – I know what I want, right? Do we need iterations, daily stand ups, and burn down charts?

Back at our former employer, we honed our process for gathering requirements and prioritizing them. We called this an Agile Assessment. For a nominal fee – enough to discourage anyone who wasn’t serious, but not enough to actually break even – we would meet with all the stakeholders we could in one 4-hour meeting. First, we’d lay out the agenda and ground rules. We’d then spend about 20 minutes to define a project objective that could be concisely written on our wall board. From there, we discussed some of the obvious users, and then started brainstorming features and recording them in the form of user stories with a title and conditions of acceptance listed for each one. Each of the titles would go onto a yellow sticky note, and the rest of the story would be recorded in a spreadsheet. When we had 20 minutes remaining, we’d ask all the stakeholders to take the sticky notes and order them from gotta-have to would-be-nice. After agreeing on the order, they would draw a line to separate what had to be there to make the most basic solution from the rest – everything above that line was in our Core Feature Set. Adam and I would then spend a fair amount of time researching and designing the solution (30-40 hours) and present the customer with a set of design documents and a fixed-price quote for the solution.

When we won a project, we broke it into two-week iterations and managed the stories and burn down using TFS. Each day we’d have a 5-10min discussion of the project and include the product owner via a phone call. There was a daily burn down chart emailed out to the team, and at the end of each iteration a demonstration of production-ready code was shared with the customer followed by a retrospective that drove continual improvement of our process.

We learned to love running projects this way and saw how product quality and team communication improved.

Going Forward

How much of this process should we bring forward into our side project? I don’t think we’ll be doing daily meetings – we both have young children and will be doing very well to spend 8 hours a week on this project. Having a product backlog and burn down seem like a good idea to me, but having a time-boxed iteration will need to be tested. We’ll need to find a new process that works for us, so we should definitely keep a periodic retro schedule.

Why are we doing this project? We both enjoy Disc Golf and we both enjoy learning and working together. This project will give us the chance to try some new technologies and approaches, and keep us interested in learning.

What’s next? My next step will be to look into opening up an account with Team Foundation Service to see if we can use an environment that we’re both accustomed to. We’ll create a product backlog and plan out our first iteration. Who knows where it will take us!