I am speaking this
week at the Projects to the Point (P2P) conference in Cairo, Egypt. The focus
of the conference is the book "How Successful Organizations Implement
Change" and the speakers (myself included) each wrote one of the chapters
of the book by the same title.
We have an
interesting approach for implementing change where I'm working, a technique
call Nemawashi. It's a Japanese term that literally translates to "digging
around the roots" but the meaning is much more than that. Nemawashi is
laying the groundwork for a change.
The work starts
before any formal meeting is conducted. Ideally, the person proposing the
change will have already worked on building the relationships with the people
who's support is needed. They will know the formal and informal organizational
structure so when it comes time to start informal discussions, they know who to
speak to.
When it comes time
for a change, the change agent determines who the key stakeholders are. The
change agent has informal discussions about the proposed change. It may be a
quick talk over coffee accompanied by a drawing on a napkin. The discussion may
include a history of the proposed change, others that have been consulted, and
options. The discussions are a way to solicit feedback and adjust the plan
before moving forward. In some cases, they may need to move backwards, having
follow-on discussions with stakeholders they've already talked to as the plan
evolves.
When it does come
time for a formal meeting, all the key stakeholders have already heard the idea
and provided their input. The formal meeting should just be a formality. If
someone hasn't been included in the nemawashi process, they may reject the
proposal just because they feel they were ignored.
This form of
consensus building may not be the fastest way to introduce a change but like
the meaning of the word, it will ensure that a new change gets to the roots to
improve the chance it will take hold.
Tuesday, December 05, 2017
Thursday, November 09, 2017
PMI Conference observations
The PMI Conference was held this past weekend in Chicago. They've changed the format a bit and even changed the name to reflect the changes. When I first started attending almost 20 years ago, it was the PMI Symposium, then Global Congress and now the PMI Conference.
They had 3 different keynote speakers (though I only saw 2 of them), one each day. On Saturday, the speaker was Sir Tim Berners-Lee, the person that developed the technology that made the world wide web possible, specifically hypertext transfer protocol (HTTP). He talked about how a goal was to make the web a "permission-less place" where anyone could put up a site.
The web developed first through creativity, then collaboration as the world wide web consortium evolved. He did highlight a point of complex systems, that the behavior at the macroscopic level is different than on the microscopic level. While I thought the talk was interesting, some of my non-IT colleagues had trouble following it.
Sunday's keynote was very interesting. The speaker was Nicholas Epley, author of Mindwise and professor at University of Chicago. His presentation was on communications, along the lines of this article he wrote for Huffington Post. He ended with 4 take-away's:
1) Be wary of any gimmicks when it comes to trying to understand others. Always ask for evidence.
2) Cut down your confidence in how well you think you understand what someone else is thinking, you understand them less than you think.
3) Learn to ask questions well, it's the best way to gain an understanding of what someone else is thinking.
4) To communicate well, be painfully clear. Don't assume the other person will easily understand your message.
The best session I sat in on was delivered by Ahmed Sidky. He talked about how the leadership structure of agile teams evolved at Riot Games. Rather than assigning roles such as scrum master or product owner to individuals, they identified 4 key leadership roles;
Team Captain - responsible for overall delivery
Product Lead - responsible for the direction of the product
Delivery Lead - responsible for development
Craft Lead - responsible for the engineering
Each team would associate key responsibilities with the four "hats" as they call them. A team member can wear more than 1 hat but the team decides all of this.This approach takes self-organizing teams to a new level.
I also took part in an interactive session on the new Agile Practice guide that came out with the latest PMBoK. It was led by Jesse Fewell and Mike Griffiths, both long-time agile names in the PMI community.The session was a good way to start understanding what is in the guide.
PMI tried to improve he quality of the sessions. As a speaker, I had to go through a few additional hurdles including creating a story board that was reviewed by an SME and practicing my presentation on the phone with a experienced speaker. I don't know if PMI got the results they wanted. There were regular speakers that did not speak because they didn't want to go through the additional steps. At the same time, I still had 2 sessions I walked out on because they didn't meet my expectations.
They had 3 different keynote speakers (though I only saw 2 of them), one each day. On Saturday, the speaker was Sir Tim Berners-Lee, the person that developed the technology that made the world wide web possible, specifically hypertext transfer protocol (HTTP). He talked about how a goal was to make the web a "permission-less place" where anyone could put up a site.
The web developed first through creativity, then collaboration as the world wide web consortium evolved. He did highlight a point of complex systems, that the behavior at the macroscopic level is different than on the microscopic level. While I thought the talk was interesting, some of my non-IT colleagues had trouble following it.
Sunday's keynote was very interesting. The speaker was Nicholas Epley, author of Mindwise and professor at University of Chicago. His presentation was on communications, along the lines of this article he wrote for Huffington Post. He ended with 4 take-away's:
1) Be wary of any gimmicks when it comes to trying to understand others. Always ask for evidence.
2) Cut down your confidence in how well you think you understand what someone else is thinking, you understand them less than you think.
3) Learn to ask questions well, it's the best way to gain an understanding of what someone else is thinking.
4) To communicate well, be painfully clear. Don't assume the other person will easily understand your message.
The best session I sat in on was delivered by Ahmed Sidky. He talked about how the leadership structure of agile teams evolved at Riot Games. Rather than assigning roles such as scrum master or product owner to individuals, they identified 4 key leadership roles;
Team Captain - responsible for overall delivery
Product Lead - responsible for the direction of the product
Delivery Lead - responsible for development
Craft Lead - responsible for the engineering
Each team would associate key responsibilities with the four "hats" as they call them. A team member can wear more than 1 hat but the team decides all of this.This approach takes self-organizing teams to a new level.
I also took part in an interactive session on the new Agile Practice guide that came out with the latest PMBoK. It was led by Jesse Fewell and Mike Griffiths, both long-time agile names in the PMI community.The session was a good way to start understanding what is in the guide.
PMI tried to improve he quality of the sessions. As a speaker, I had to go through a few additional hurdles including creating a story board that was reviewed by an SME and practicing my presentation on the phone with a experienced speaker. I don't know if PMI got the results they wanted. There were regular speakers that did not speak because they didn't want to go through the additional steps. At the same time, I still had 2 sessions I walked out on because they didn't meet my expectations.
Wednesday, October 18, 2017
Red Teaming
One of the things we talk about at work is eliminating group think and an approach to do this is using red teaming.
For those not familiar with the term, red team comes from the military and originally stood for a team that represented the opposition. It has since expanded to include any team that might challenge the status quo..aka, group think.
So how does this apply to the agile world? Even agile teams can get stuck in group think. A great example is during story estimating. If you don’t use planning poker cards, the senior developer might say “oh, that’s a 5” and everyone else agrees, they become anchored to his estimate. Someone else might have had a different opinion (that’s going to be a 21 because we have to create a new database table) and they may be right, but they succumb to group think and let the 5 point estimate go. The obvious solution here is to use planning poker cards but sometimes as a coach I need to point this out to teams.
Group think can happen during any agile activities. During retrospectives, I coach my teams on the approach of each person writing ideas on post-it notes in silence and then discussing them as a group.
This way, ideas can surface before group think can crush them.
Red Teaming can be applied elsewhere as well. Another place I like to use it is at the end of a planning session. The team has finished selecting stories to work on for the iteration, they have set their sprint goal and they’re ready to start. At this point I stop them and ask “what could go wrong with this plan?” This is another good place to inject “ think, write, share” and start a discuss about risks and responses to them. So be on the lookout for group think and bring in a red team if you need to counter it.
For those not familiar with the term, red team comes from the military and originally stood for a team that represented the opposition. It has since expanded to include any team that might challenge the status quo..aka, group think.
So how does this apply to the agile world? Even agile teams can get stuck in group think. A great example is during story estimating. If you don’t use planning poker cards, the senior developer might say “oh, that’s a 5” and everyone else agrees, they become anchored to his estimate. Someone else might have had a different opinion (that’s going to be a 21 because we have to create a new database table) and they may be right, but they succumb to group think and let the 5 point estimate go. The obvious solution here is to use planning poker cards but sometimes as a coach I need to point this out to teams.
Group think can happen during any agile activities. During retrospectives, I coach my teams on the approach of each person writing ideas on post-it notes in silence and then discussing them as a group.
Think, Write, Share
This way, ideas can surface before group think can crush them.
Red Teaming can be applied elsewhere as well. Another place I like to use it is at the end of a planning session. The team has finished selecting stories to work on for the iteration, they have set their sprint goal and they’re ready to start. At this point I stop them and ask “what could go wrong with this plan?” This is another good place to inject “ think, write, share” and start a discuss about risks and responses to them. So be on the lookout for group think and bring in a red team if you need to counter it.
Tuesday, September 26, 2017
Debriefs
I’m working on a new assignment as part of an agile coaching team leading a transformation at a large organization. One of my fellow coaches is also a former Navy officer. We’ve had a number of conversations about how many of the techniques developed by the military can be applied to make any team a high-performing one.
One particular tool is debriefing. I’ll admit, I didn’t do a lot of this in my military career, but the idea is to take time after any activity to review how it went. Kind of sounds like a retrospective, doesn’t it?
As an agile coach, I find this is a great tool. Just the other day I observed one of my teams run a stand-up. As soon as they were done, I gave them a debrief. It only lasted a minute. I highlighted what they did well and where they could improve. I have used the same approach with other teams on everything from iteration planning to retrospectives...sounds kind of “meta” but why shouldn’t you evaluate how effective your retrospective was? This technique is based on the approach of learning a new idea, practicing it, and getting feedback to reinforce the idea.
One key to debriefs, and I think this is important for a good retrospective, is to start by stating the goal of the activity. At the end of the iteration, can your team members state what the iteration goal was? How else can you evaluate how you did without thinking about what you set out to do.
One particular tool is debriefing. I’ll admit, I didn’t do a lot of this in my military career, but the idea is to take time after any activity to review how it went. Kind of sounds like a retrospective, doesn’t it?
As an agile coach, I find this is a great tool. Just the other day I observed one of my teams run a stand-up. As soon as they were done, I gave them a debrief. It only lasted a minute. I highlighted what they did well and where they could improve. I have used the same approach with other teams on everything from iteration planning to retrospectives...sounds kind of “meta” but why shouldn’t you evaluate how effective your retrospective was? This technique is based on the approach of learning a new idea, practicing it, and getting feedback to reinforce the idea.
Learn, Practice, Reinforce
One key to debriefs, and I think this is important for a good retrospective, is to start by stating the goal of the activity. At the end of the iteration, can your team members state what the iteration goal was? How else can you evaluate how you did without thinking about what you set out to do.
Monday, May 22, 2017
Estimating
I was flying home from a client visit last week at the airport getting ready to board the plane when the gate agent announced that the flight was gonna be delayed by ten minutes due to some unspecified mechanical issue. Ten minutes later they announcement another ten minute delay. They did this two more times.
So what was going on? Did the airlines not want to admit upfront that they had a 40 minute delay so they fed the delays to us ten minutes at a time? Or did the person who is doing the work really not understand how long it was going to take? I started thinking about how common it is for people to not be able to provide good estimates. Sometimes they underestimate the complexity, or maybe student syndrome sets in, or they're just overly optimistic.
It was ironic, but part of the work with my client that week was explaining the technique of relative estimates using t-shirt sizes and story points. The team I was working with was new to agile and used to the old way of doing absolute estimates, which as we all know are not as accurate because of things like student syndrome or Parkinson's Law.
So how do we get better at estimating? I think the real question should be how we recognize estimates for what they are. An uncertain prediction of a future event. Even when we use story points, we won't know our true velocity until after a couple iterations when the team has time to come together. At the beginning of the project, we need to recognize how much uncertainty we have. So instead of saying "that will take about 2 months" we should say "that may take 2 months, but it could take as long as 3 months." So we provide not only the estimate but some measure of the uncertainty that goes with it. Similarly, if we think a story might be 13 points, but there's a lot of uncertainty, we should state that and make the story 20 points (or 21 if you're being strict with your Fibonacci sequence). Now if only I could get the airlines to provide a more accurate estimate the next time there's a delay...or at least how certain they are!
So what was going on? Did the airlines not want to admit upfront that they had a 40 minute delay so they fed the delays to us ten minutes at a time? Or did the person who is doing the work really not understand how long it was going to take? I started thinking about how common it is for people to not be able to provide good estimates. Sometimes they underestimate the complexity, or maybe student syndrome sets in, or they're just overly optimistic.
It was ironic, but part of the work with my client that week was explaining the technique of relative estimates using t-shirt sizes and story points. The team I was working with was new to agile and used to the old way of doing absolute estimates, which as we all know are not as accurate because of things like student syndrome or Parkinson's Law.
So how do we get better at estimating? I think the real question should be how we recognize estimates for what they are. An uncertain prediction of a future event. Even when we use story points, we won't know our true velocity until after a couple iterations when the team has time to come together. At the beginning of the project, we need to recognize how much uncertainty we have. So instead of saying "that will take about 2 months" we should say "that may take 2 months, but it could take as long as 3 months." So we provide not only the estimate but some measure of the uncertainty that goes with it. Similarly, if we think a story might be 13 points, but there's a lot of uncertainty, we should state that and make the story 20 points (or 21 if you're being strict with your Fibonacci sequence). Now if only I could get the airlines to provide a more accurate estimate the next time there's a delay...or at least how certain they are!
Thursday, March 30, 2017
The Bullet Journal
I went back to using paper over electronic tools for notes over a year ago based on research that showed you remembered things better when you took notes the old fashion way. Even then, I wasn't sure of the best approach. For a long time I was using standard legal pads, but I didn't want to take them with me when I traveled. I had a small organizer that allowed me to put paper in and out. I had tabs for different projects and clients but I found I was flipping pages to much.
I've adopted a way to combine the legal pads and my bullet journal. I still keep a legal pad at my desk and write down about everything. At the end of the day, I review my notes and copy everything over to my bullet journal. This serves as a review, makes sure I don't forget any action items, and gives me a chance to jot down some reflections at the end of the day.
I am using a Moleskin 5x8.5 dot grid soft cover notebook and a set of Sharpie fine point pens in 4 colors. I use different colors when I change subjects or otherwise want to highlight an idea. I have pages to capture books/movies/music I want to get, a page to capture things I'm grateful for, and a page where I have a year-long calendar.
We'll have to see how long I keep this up. I've got the book "The Doodle Revolution" sitting on my bookshelf, maybe I need to dust it off so I can add doodles to my journal.
Wednesday, February 08, 2017
The Canvas Strategy
I’m making my way through the Tim Ferris' book Tools of Titans. It’s well over 600 pages but it has a lot of useful, interesting advice, though I'll admit some of it is a bit out there. He breaks the book up into three areas; Healthy, Wealthy, and Wise. The book is really just a summary of podcasts done over the years with some other advice added in.
One piece of advice I appreciated is what he called the canvas strategy. The idea really came from Ryan Holiday. The name refers back to when apprenticeships were common; a budding painter learns his craft by serving under a master and doing such things as preparing his canvas.
In today’s terms it’s about serving the people you work for…sounds like servant-leadership! Some examples he gives includes ideas such as giving your boss an idea you came up with and not looking for credit or finding out the job no one else wants to do and taking it on yourself.
This strategy will accomplish a number of things. It will keep your ego from getting to big. As you make those around you successful, you will also become more successful; the adage "a rising tide lifts all boats." Finally, if you're feeding ideas to your boss, or coworkers, then you will start steering the direction they are going.
Subscribe to:
Posts (Atom)