I’m often asked if there’s anything different about managing a roadmap in an agile environment. I don’t think so; since agile is (just) a methodology for delivering software, I don’t think having a roadmap and being agile are mutually exclusive. Let me know if you disagree.
Over the past few quarters, we’ve refined how we manage our marketing automation platform’s product roadmap (which we develop using agile methodologies). As of today the platform has 525 Users, so the volume of feedback and demands is rapidly increasing.
Here are a few things we’ve found about managing a roadmap in this type of environment:
1. Creating a detailed roadmap for more than 1 quarter at a time seems to be a waste of effort. Read more of this post
Colin Powell: Lots of leadership lessons and tactics
In line with yesterday’s post about handling problems as a leader, I thought it appropriate to share how Colin Powell instructed his staff to bring him problems. Being a retired four-star general in the United States Army, and having served as the 65th U.S. Secretary of State (under President George W. Bush) from 2001 to 2005, Mr. Powell definitely knows a thing or two about running organizations at scale and getting the best from those around you.
First, tell me what you know. He advises asking your team to give you the facts of the situation, as objectively as possible. He doesn’t want personal interpretation. He’ll often probe to see how the facts were obtained to ensure that the data are as accurate as possible.
Second, tell me what you don’t know. As important as communicating the known facts, Colin advises asking for clarity around what is unknown. If you have the right people in the right positions, they’ll most likely realize what they don’t know. Colin feels that getting people to articulate these things is as important as getting the facts. The unknowns give way to follow-up actions to obtain that information (if possible).
Then, tell me what you think. This is where the person is asked to add their interpretation of the data, provide insight based on experience, and/or anything else they think is relevant given the situation. This is where he allows people to use the facts to build an argument, or offer an opinion.
And remember: Always distinguish one from the other. Colin suggests that it is imperative to ensure that you are clear in asking that people provide you information and clearly distinguish which type of information they’re giving. If they’re telling you what they think, don’t allow them to misconstrue that as a representation of the facts.
I think #4, while subtle, is brilliant and essential. Especially when situations are stressful, I notice that people tend to add color to a situation by incorporating their personal perspectives, which in some cases is wrong or biased. I know I do the same and wrestle with trying to keep these things separate in my own head; perhaps it is human nature to immediately draw conclusions (did I just jump to a conclusion there?).
What do you think of Colin Powell’s 4 Rules? Do you think they are helpful in communicating information and getting to the point?
One area that we spend a lot of time thinking about (and working to improve) is our ability to communicate our company’s direction in a way that aligns everyone.
We use the word “alignment” a lot around the office, and we’ve made a number of changes that have helped us improve in this area, like daily stand-ups (video example here). Alignment is critical for start-ups and companies going through rapid growth.
In “Behind The Cloud“, Marc Benioff (co-founder of Salesforce.com), shared the V2MOM planning process he and his team used to grow Salesforce.com into the largest SaaS company in the world.
The acronym stands for vision, values, methods, obstacles, and metrics. The purpose of V2MOM is to create alignment, from the leadership team out to every team member.
A way of thinking and living that I’ve been trying to cultivate is the idea that our positions (meaning our beliefs about an issue), and who we are as people (our ego, for lack of a better word) — are two separate things.
In other words, if I allow my ego to become tightly coupled to an idea or position, it is easy to lose objectivity and the pursuit of the higher truth or reality. This can look like trying to prove you’re right just because you’re the one with the idea. We’ve all been there.
Further, if your position is later refuted or proven wrong, it’s easy to become emotional and feel a lack of worth as a person. These feelings can haunt us and further corrode our ability to think clearly.
Decoupling ourselves from our positions is much easier said than done. Here’s what I’ve found helps in these types of situations:
Foster a culture where ideas are the things that may be right or wrong, not where people are good or bad because of their ideas. Don’t attack the person, but rather seek to understand why they believe the idea is true. Instead of going after the person, keep in mind that it is likely they have reasoning that seems perfectly logical to them, and that you need to uncover those reasons in order to fully understand the idea.
Be open to the idea that your position may be flawed. Lead by example in actively seeking input from a variety of sources to gain perspective. Don’t attach your personal ego to the position, but float the idea as a thing of itself. You may begin to see others doing the same.
Build a culture where the data are used to get at what is true. Otherwise, you may run the risk of succumbing to your own weaknesses and blind spots, or the opinion of your HIPPOs (Highest Paid Person’s Opinion). Data can become the great equalizer, helping you get to what is true and beyond personal biases.
What else? Do you believe that keeping our egos and positions separate may help us make better decisions? If not, why?
I’m not a negative person, but here’s something I’ve noticed: projects fail at an alarming rate. One reason seems to be that people are afraid to speak up during the planning phase. Unless you’ve fostered a safe environment that encourages people to raise issues, concerns may fester in silence and only become evident when its too late.
Screencasts are very helpful for communicating ideas, features, and information about your product. We’ve recorded a number over the years, and I have experimented with a variety of methods to produce the best results in the shortest amount of time. I’ve found there are some processes that make preparing, recording, editing, and sharing screencasts easier. (I’ve included an example at the end of the post which uses the tips contained here — let me know what you think.)
In this post, we’ll focus on preparing a script — although I have found there are situations where extemporaneous recording works well too.
Here’s what we’ve found helpful in preparing a script:
Create a document with two columns: the column on the left contains the words you intend to use for your video, and the column on the right contains short descriptions of what you intend to show on the screen, like “Show Login Page” or “Show the user searching for a widget”. If you create this document using Google Docs, it makes it super easy to share with people you want to get feedback from.
Create a rough outline of the major thoughts you want to communicate. Don’t worry about the specific words; just create an ordered flow of ideas you want to communicate. Try to put them in a logical order.
Sit in a quiet place; using your outline, start speaking as if you’re talking to someone sitting next to you. I’ll often record what comes to mind, and then create my first draft by transcribing the recording. At this stage, don’t worry about making it perfect – you just want to capture the spirit of what you want to say.
Read your draft out loud, and refine it so that there are no major errors. Check to see if your ideas still seem to be in logical order.
After creating a first draft, I’ve found it helpful to review it with a group of 2-3 people who have subject matter insight or are clear thinkers. Inserting this step into my process has dramatically improved the end result.
Here’s how I use this feedback and review session:
I ask everyone to read the script in advance. If they don’t, I’ve found that their input seems more limited and less helpful, so try to give everyone enough time to prepare.
Do a read through. I’ll usually read the script out loud from top to bottom, and ask for general feedback about the flow. Does it make sense? Are the thoughts in a logical order? How’s my inflection?
If necessary, we’ll make changes to the flow, and then begin to work on each sentence, one at a time. I’ll ask if each word is the best choice to communicate the idea. I’ll also try to cut out as many words as possible. This is an iterative process and can be a lot of fun if you have a good group!
After you’ve revised your draft, let it sit for a bit. Maybe wait a day, and then go back and re-read it (out loud — not in your head) and see if it still makes sense. With a clear mind, you can make additional changes you think are appropriate.
At this point, you should have a relatively good draft to record from. Get your vocal cords ready! In another post, I’ll cover some of the things we’ve found helpful in recording a screencast.
What about you? Have you found any tips that are helpful in recording screencasts? If you’ve recorded them in the past, which part of the process is most difficult for you?
Here’s a 3 minute example that used the methods described in this post. Enjoy!
Here’s how we run the engineering stand-up meeting:
1) We start promptly at 9:00 AM. We experimented with having the meeting at 4:00 PM, but meeting towards the start of the day seemed to work better. I personally enjoy the buzz from getting everyone together in the morning, hearing the prior day’s activities, and charting the day’s course.
As I walk into the meeting, I make it a point to greet everyone, shake hands (or a quick fist-bump), and look everyone in the eye and smile. I don’t always succeed at this, but I like to try and give everyone a good start to the day. I feel it makes a difference.
2) We time-box the meeting to 12 minutes. We use an iPhone timer to keep us honest. These days, we usually finish with about a minute to spare. We used to get lazy and go for 20 or 30 minutes, but now that we stand up and use a timer, we’re good. I check the timer from time-to-time during the meeting and sometimes call out the number of minutes remaining. Even though each person only has a few minutes, you’ll notice that it doesn’t seemed rushed; everyone has plenty of time.
3) We go in the same order each day, cycling through 7 people. The people involved are:
The Product Owner (me). I report on both my product-related tasks, as well as whatever I’m working on with the Leadership Team or any other part of our company. If someone listens carefully, they can get a pretty good sense for what’s going on elsewhere in the company.
Our QA lead, who also is involved with our Professional Services. He goes first, and you’ll hear him mentioning working from home the prior day. We do this from time-to-time to improve focus.
Our senior architect and 3 engineers, each of whom are responsible for a different sub-system.
A member of our Support Team, responsible for communicating Clients issues, escalated cases, and any other meaningful data (we use SalesForce.com to track all cases). We added this person to our daily stand-up just recently, and we’ve already seen it pay dividends.
Even though we go in the same order each day (and it is written on the board!), I often forget. Senior moment!
4) We stay fairly disciplined. If something comes up during the meeting that requires additional discussion, we’re disciplined about putting it in the “parking lot” and discussing it later. I have to resist asking a lot of questions; you’ll see me ask a few quick ones, but I try to keep us focused and moving forward. If anyone is blocked, it’s my job to make sure that I do what I can to move them forward. You’ll hear me ask about blocks after some of the updates.
5) We update the Sprint board. We usually start updating User Story status (as a percentage towards completion) a few days into the Sprint, once we’ve started making progress. We recently changed what we display on the board, and it seems to have made an improvement. We can cover that in another post.
The meeting runs well if everyone is prepared (which is most often the case). Some come prepared with a summary of what they worked on, others seem to have great memories and can recite their work without notes. Personally, I write everything down in a Google Doc, and just reference this document during the meeting; otherwise, I’d never remember anything — maybe I’m getting old!
Here’s the video from one of our recent Scrum meetings; excuse the brief interruption around 1:45. Enjoy!
The next time you’re talking with someone in a position of authority or responsibility, try this: Count the number of times they say “we” or “us” — versus “me”, “my” or “I”.
For example, imagine you work at a company that makes gizmos. You’ve worked hard with a group of people to create the gizmo, and someone in a leadership position relates a story about meeting with a potential Client and says: “I want them to see the value of my product.”
Oh really, it’s your product?
Or, are they more inclusive, and instead say something like: “We want to show them the value we can provide.”
I would argue that in certain situations, leaders who use words that are inclusive (like “we” or “our”) resonate more strongly with the people around them than those who make things about themselves.
Personally, I am put off by a person who makes it all about them. I’m sure this is much more about me and my issues than them and their words, but I often wonder how people would respond to their leaders if more inclusive words are used. I’m sure there are studies that have looked at this.
So the next time you’re thinking about how to communicate to your team (or listening to someone in leadership), consider measuring your (or their) we-we factor (not wee-wee, come on kids!), and see if you notice any difference when inclusive words are used.
What do you think? Are you turned off by people who make things about themselves? Does it make any difference in how you feel? Or, are people like me just too sensitive?
Akathisia: Life In Motion -- David Rosendahl 