Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Saturday, August 16, 2014

Career Kaizen #7 - The Scrum Values

This week we'll explore the Scrum values a bit.

Monday - Courage

I share a story in my classes about courage. Some years ago, I and my family were visiting Yellowstone National Park. There are bears in Yellowstone, and when we first saw them, I was a bit nervous. I checked to make sure the car doors were securely locked and all windows were up. We were safe. But, just a few weeks later, an old couple came across a bear while on a hike in Yellowstone. It was a mother bear, and in between the couple and the bear was the cub. From 100 yards away, the bear charged. Now, some say that courage is the absence of fear, but I think you should be fearful of a charging bear. It's the appropriate response. I heard another definition of courage from Erwin McManus that resonated much more deeply - "courage is the absence of self for the sake of others". In that moment when the bear was charging, the man turned to his wife and said "Run!", but he stayed put. The husband was killed by the bear, but the wife had enough time to hide behind a log and play dead. The bear still found her. Actually picked her up by her backpack, but then dropped her, and walked off. The husband, in my opinion, was the perfect example of courage - absence of self for the sake of others.


Friday, May 02, 2014

Career Kaizen #6 - 5 Agile Sayings to Empower Your Team's Success

This week we'll walk through some common sayings in agile and explore their meaning a bit.

Monday - The Wisdom of And

Even if you are an expert, you'll benefit from hearing
and getting input from others.
When I worked at BigVisible, one of their coach's conference themes was "The Wisdom of And." This is drawn from Jim Collins work when he talks about the wisdom of "and" and the tyranny of the "or". The point is that there are often more choices available to just either/or choices, sometimes called "sucker's choices" or "false polarity," if neither option in its entirety or alone gives everyone what they're wanting. For example, "Well, we can either go over budget to build X, or we can lose all our best customers to the competition." That's a fool's choice. There's something in the middle.

If a group is sitting around a table, the best option doesn't lie with one person. It more likely lies somewhere in the middle of the table. Even if you are an expert, you'll benefit from hearing and getting input from others.

To get more input from a quiet group, ask questions such as "Anything else on this to consider?" "Are there other options?" "Any unanswered questions?" "What are we overlooking?" "What assumptions does this depend on?" "Is there another approach?" "How could this fail?" "Let's get at least two options on the board for this issue."

And you can control difficult people by replying to their solution with, "I'm sure that's a great option, I just want to hear what others have to say." or "Yes, and I'd like to just gather additional information and input."

Homework: Practice replying to positions and opinions with "Yes, and…" instead of "Yes, but…"


Tuesday - Art of the Possible

We often think things are impossible, but in actuality are possible and likely take a lot of hard work and a long time.

For example, for many of you, running a marathon might seem impossible. It might be if it were this weekend, but if it were six months away, and you started getting up in the morning and lacing up the shoes...given enough time and effort, you could do it. And if you did, what a sesnse of accomplishment that would be. It's a big deal. That's why people put the sticker on the back of their cars with 26.2. They don't put stickers that say "I walked around the block today." That's no big deal.

Most anything important, that's of value, takes some investment of time and effort. And that journey is actually part of what changes you, grows your character, and gives you a story worth telling, a story that others want to hear.

Homework: Watch the amazing transformation of a man who commits to running the Boston marathon:



Wednesday - No one of us is as smart as all of us.

Scrum depends on team. If the team isn't all in, if they're not involved in estimating the work, collaborating with the Product Owner on what, why and options in the requirements, and if they're not committing to the work, then we are missing a lot of the magic. When it comes to ideas, options on approaches, the architecture and more, no one person has all the answers. No one person is as smart as everyone else put together. One person might have more knowledge in a particular area, but others can learn that, too.  I've been amazed at how many times the new person on the team has had the best idea.

The same is true for us. On our own personal journey, on our own goals or challenges, we'll always benefit from hearing ideas from others, getting feedback, hearing their stories. We're built for community. Help yourself by getting connected in the local or online agile communities or coaching circles.

Homework: Do a quick search for local meetings or meet-ups for agile, Scrum, project or product managers, lean start-up or business sector you're in, and do the same for groups on LinkedIn, Yahoo, Facebook and other social sites. See anything interesting?


Thursday - Create your own Reality

We need to empower our teams, our team members, and
ourselves that we can create the reality we want
When I worked at Rally, this was one of their core values and sayings. And they lived it. If you felt that you needed something to do your job, if you wanted to grow into another role, they supported you in creating that reality.

I see my wife doing something similar with our two younger kids. When they say, "I'm thirsty," she replies, "So what are you going to do about that?" When they say they can't get ready because they don't have their shoes, she answers with "You can solve that problem."

We need to empower our teams, team members and ourselves that we can create the reality we want, we can solve our problems. I'm often met with the opposite in companies, a response of "Management won't let us do ____," but when I ask if they have actually asked for it, it's usually "No, but they know this is a problem." A particular training exercise I do highlights this. I do the ball point game, and the vast majority of the time, the participants don't move around to where the spacing works best for them. They just accept the circumstances or constraints without even asking me.

Homework - Think of the team, a team member, or yourself, and ask "What if..." and see what comes.


Video Fridays - What's the simplest thing that will work?


Breaking down life into what moves it forward today, not what's the best, comprehensive solution. A little like the debt snowball or weighted short job first.

To look at the entirety of the mountain to be climbed may seem overwhelming, but there is truth both in the saying that the journey of a 1,000 miles begins with one step and that the joy is in the journey.

About the big challenge or goal in front of you, what's one part of it that you can do today? Even better, what's something on it that you can do before noon? You might say that that one thing isn't the most important or highest priority. True, but also perhaps not true. It is a priority in the sense that you getting a "less important" task done actually gets the motivation and confidence going to tackle, and succeed, at the big thing.

Often our risk aversion, all the unknowns, take us out of the game of tackling big and challenging goals. But the very fact that the goals are big and scary are what make them worth doing, noble even. And through that challenge of tackling what is too much for us, we are transformed from someone who could not, before, into someone who can, afterwards.

Homework: Watch the amazing transformation of a man with a broken neck learning to walk again.




Weekend Warrior
Check out the story at the beginning of Habit. Read up on Jim Collins "Big Hairy Audacious Goals" and Dave Ramsey's Debt Snowball.

Saturday, April 19, 2014

Career Kaizen #5 - 5 Days of Leadership

Monday - Level 5 Leadership


Leaders help team members
solve their own problems.
Most agree leadership is important, but there are many definitions out there. Are you a leader? Do you have leadership in you? The ScrumMaster role is often described as a servant leader, so it's worth some focused time on it.

One of the classic business books is Good to Great. In the book, Jim Collins talks about Level 5 Leadership, the highest of all and a level few CEO's attain. There are good metaphors that describe that type of leader.

First, these leaders look out the window to assign credit, and look in the mirror to assign blame. Always try to deflect to the team when someone looks at the results and says "You've done a great job leading the team," especially if it's in a public situation, like a meeting. There are many ways to do this, for example, "It's not me. It's the team. Anyone could have done it if they had a team like this," or "Thank you, but really, the team is the one responsible. They have really put in a lot of time, effort and heart into this, " or even just point to some specific positive aspect of the team (perhaps from one of their retros), "The team really feels that _______ has been the key ingredient to the success we've had."

Second, these leaders want to make clock-builders, not be time-tellers. Rather than always have the answer, or be quick to solve someone's problem, Level 5 Leaders help team members solve their own problems or find their own answers. This builds their own abilities, ownership of the solution, empowers self-organization and makes teams faster. Many times making a clock-builder can be started by responding to a question with "What do you think?" I've been surprised how many times they already have an idea, they're just looking for feedback, support, or political covering. You can answer with, "Well, try that out and let me know how it goes," and watch as the team begins to solve more and more of their own problems.

Homework: Ask yourself: Does it feel good to solve people's problems? To be needed? Or to be able to help? Is your value based in part on how critical you are for things to get done? Are you okay with them figuring out everything by themselves?


Tuesday, Common Team Needs

Marcus Buckingham said that the difference between management and leadership is that management looks at what is unique among people, and capitalizes on it, while leadership looks at what is common among people and capitalizes on that.

Knowing what the common concerns are, or addressing a common need, is important. Vision, a key leadership trait, is pointing to a common goal or destination that enables a group to rally around and towards that - a common goal or challenge as they struggle, fail, win and journey together.

Homework: Look at the common felt needs of employees compared to what management thinks they need. What do you think the top three for your team members are? List them in the next retro and have the team dot vote them.


Wednesday - Positional or Influential Leadership

The challenge, and the blessing, of leadership in the ScrumMaster role is that you do not have authority over the team. You can't tell them or force them to do anything. Yet, traditional, authoritative leadership is actually the lowest form of leadership. People aren't as likely to truly be following you as a positional leader (for example, a manager). They are doing what you say, whether they like it or not, because they have to. In those situations, they're not giving the positional leader their best, but only the minimum required. Just enough to not get in trouble or fired or noticed.

Having people listen to you, follow you, as a servant leader means you must learn and grow in the powerful area of influential leadership. Forming relationships, understanding their needs and concerns, fighting on their behalf, protecting them, taking hits for them.

Homework: Looking back over history, who do you admire? Any heroes or people that you respect the work they did, the impact they had, or the challenges that they overcame? If so, in what ways can you apply lessons from them for your life and work now? What would they tell you?


Thursday - People Development Wins Championships

You must develop team members to win championships
John Maxwell wrote a very popular book on leadership. A few quotes from him:
"You can't lead people without liking them."
"At one level, you focus on becoming a change agent - focusing on productivity."
"Productivity wins games. People development wins championships."
"Besides the obvious competence, effort and skill, leadership also depends on intentionality."
"To succeed as a leader, you must help others move forward."

Homework: Pick one of the quotes you like (or another quote from the web page), print it out large to post on your wall at work, and small to put on your bathroom mirror or car dashboard. Keep it in front of you for a week. Don't start your computer or end your day without looking at it (even better to say it to yourself) or start your car or brush your teeth without the same.


Video Fridays

Stanton Complex - face the brutal facts, but don't let go of hope. In 1965, Captain Stanton was shot down and in a POW camp in Vietnam. While others kept believing any day that they'd be released, the reality was they weren't. These people ended up giving up, or worse. Stanton was hopeful, but not unrealistically so, and faced the reality that, also, they may never be released.

On your team, in your company, it may look grim. It doesn't help to believe things will magically change based on nothing other than your wishful thinking. And yet, we have to hope and believe that there is a chance, a chance worth fighting for, that they someday could.

Always respond positively. Don't join others in their complaining. Focus on solutions - what can you change, what experiment, what can you ask for, that might help. If you're not sure, ask yourself, "Is this noble or excellent?"

Homework: Watch the video of Jim Collins (or listen to his audio clips), or Patrick Lencioni.


Weekend Warrior: Review all of Jim Collins Hedgehog Concept items. List out the five levels of leadership.




Saturday, April 12, 2014

Career Kaizen #4 - 5 Ways to Make Real Change Happen

Monday, It wasn't easy - I had to change a LOT

The challenges you face are what make you better
Difficult days are rewarding. The challenges you face are what make you better, more than what you were last week or last year.

Imagine that you are observing some amazing team, better than any you've ever been around. You ask the ScrumMaster, "Wow - how did you help them get to this place?". He replies, "Nothing, they were like this when I showed up." What kind of inspiration is that?

Yet, when you feel challenged, maybe even too much at times, these are exactly the points that push you into responding in new ways, trying things you haven't before, becoming someone, perhaps, that you weren't before. So when someone asks, "Wow - how did you help them get to this place?" you smile, laugh and say, "It wasn't easy - I had to change a LOT. This is where it started…" and they will be all ears.

Homework: Do your own speedboat exercise. Draw a boat on a sheet of paper (yes, really - drawing connects with a different part of your brain). Now, draw three or so anchors off the boat that are slowing you down. For each anchor, write three actions that might help with each area. Now, choose three, and either add them to your personal kanban board, or calendar them.


Tuesday, If Nothing Changes, Nothing Changes

Yes, you really can change. I've wanted to learn to play guitar for years. In fact, I have one. I've had it for 16 years. Up until several weeks ago, I hadn't played more than a song within any given season for at least 8 years. Maybe picked it up once in a month or two.

But now I've played it every day for weeks. I've caught up to where I was a decade ago and passed it. I've learned new songs and notes. I have callouses on my fingertips again. Not only am I playing, but my family is often joining in singing as they walk in and out of the room. Wonderful repercussions.

Why the change? It's something that I really wanted for a long time, so not a lack of desire. Well, it's habit. I added it to one of several daily check-off items on an app I use. Just wanting to flip it to green - done - has made me stop and do it. And now that I've gotten used to just finding a moment to do so, I'm finding more moments and connecting that decision with the reward of the feeling while I'm playing.

It may or may not work for you. It actually took me a couple of weeks, and some tweaking (I had to set a goal of having at least one day where I did ALL items on the check list). But, do something, and inspect and adapt. Because, if nothing changes, nothing changes.

Homework: If you have a smart phone, check out some of the habit-building apps. Start with one positive habit you'd like to build. If you don't have a smart phone, try an online version, or try adding it to your calendar or daily to-do's via Outlook or even good old paper.


Wednesday, Help the Elephant

What specifically needs to happen to turn the elephant?
What is an intermediate achievable turn for the elephant?
The elephant and the rider. You may already be familiar with the story. Elephants can be guided by a rider down a path, but if the elephant really wants to go somewhere, it's going to go there. Same with us and our desires and goals. We may want to go somewhere, but we're often taken somewhere else by the elephant - our emotions. I may want to lose weight, but on a stressful day, I'm much more likely to eat chocolate (true). Or I can want to go running in the morning, and so set the alarm, but once it goes off at 5:30 AM, I don't feel like getting up very much. It could be the same for wanting to speak, get into training, go back to school or a certification program.

Help turn one of your goals into a reality by helping the rider. Look for bright spots - times or situations that things did go well, or you did have some progress. What was happening in that? Script the critical moves - don't inundate yourself with too many choices. What, specifically, needs to happen? Point to the destination - is there an end goal that the habit lines up with or supports?

And help the elephant, too. Shrink the change by lowering the bar so that you can get some success. One habit I had was popping my knuckles. Rather than trying to go all day, my first goal was just not to do it before 10 AM. Then it was 1 PM. Now it is all day. Studies were done that showed that people were 40% more likely to return to a car wash if they were given a 10 punch card with two punches already done, versus an 8 punch card with none.

Homework: How can you help the rider? What are the critical moves to successfully achieve the task? How can you help the elephant? What is a small starter goal to incrementally move toward success?
Share your ideas in the comments below...


Thursday, The Growth Mindset, or the Fixed Mindset

People generally fall into one of those two categories. The fixed mindset believes that we have a certain amount of abilities and that if we do or don't do well at things - subjects, jobs, life, it's because we don't have what others have. If we did, we'd do well, naturally. The growth mindset believes that we can learn, grow and change in these.

Homework: Answer the questions:
1. People are born with a certain intelligence that stays fixed throughout life. True or False?
2. Choose one: Do you demonstrate your ability or increase your ability?
3. When you fail, what does it tell you?


Video Friday:

Watch the TEDx video The Power of Belief


Weekend Warrior:
Check out Linda Risings YouTube videos on the Agile Mindset


Watch Carol Dweck's Mindset video or check out the book or audio book.



Monday, April 07, 2014

Career Kaizen #3 - Your Culture

Monday - Your Cultural Context

team meeting in  circle
Culture eats strategy for breakfast.
What is your company culture?
This week we'll be looking at your cultural context. A mentor once told me "People trump process, but politics trumps people", and for the business, "culture eats strategy for breakfast." So, what is your company culture? And what does that mean to you?

The technology innovation adoption curve is a model adapted by Geoffrey Moore that plots the relative number of people who fall across a continuum of their response to new technology. There are innovators, early adopters, early and late majority, and laggards.

This matters for you because agile is, in the same way, new. IT changes how many people in the organization work, aspects of their roles, what's expected of them, and even deeper and more importantly, it changes what's expected of people's mindsets and what the values are.

An agile survey showed that the number one reported problem with agile adoptions was management resistance.

Homework: Read up on the curve, plot where you are, where your team is and where you think your company is.


Tuesday - Lead with Vulnerability and Transparency

You are part of a team. Even more so with agile, we can't find our success outside of that. Like a relay race, you may claim a fast time for your segment, but if the baton is dropped, you still lose the race.

Patrick Lencioni wrote about what makes teams healthy, and what holds them back. The common problems are absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. Many teams asking for help are stuck at the first two levels, so let's focus on how you can help with those.

To help with the absence of trust, first, lead with vulnerability and transparency. Tell them how you blew it (they usually already know anyways), when you were stressed or worried. Affirm them for what they do that you can't do so well. Be the first one to share, ask the difficult question or talk about the elephant in the room. Model transparency. Affirm them when they do it.

Second, look for conflict, don't avoid it. We should cultivate environments where it's okay to disagree, and passion is okay. No personal attacks, of course, but freedom to speak your mind and have opinions.

Homework: Look at the documents on Five Dysfunctions of a Team.


Wednesday - Get your Team's Perspective

What does the team think? Schedule a meeting, or include it in the next retrospective, to have them say what they think they have, both on the curve, and with dysfunctions.

Homework: Schedule the meeting (unless it will be part of the next retro) and review the documents with the team.


Thursday - The Change Agent

Healthy things grow. Growing things change.
Lead by embracing change.
How and why do people change? What motivates them? What motivates you?

There's a saying - healthy things grow, and growing things change. But we can't make people change. Just look at corrective institutions, rehabilitation centers or many marriages.

But we can lead by embracing, and living out, change. Although I may teach and coach about change, I'm surprised how often I'm actually resisting it. For each of us, this is true for many reasons, but the point is to be mindful that we all struggle with it, not just others. Is there a habit you haven't broken, a goal you haven't attained?

Two reasons that change is hard are emotion and habit.

Homework: Look at the summaries for Switch and Habit. Note three points or items that stuck out to you.


Friday - You, Your Team, and Your Response to Change

By now I hope you have some feel for both the culture around you, your team and your own response to change.

Homework: Watch these Switch and Habit videos on YouTube. 



Weekend Warrior: Do a force field analysis of what changes are supposedly wanted by the company and what is hindering them.

Wednesday, November 20, 2013

Product Owners Caught in the Middle

In my Certified Scrum Product Owner class yesterday, the top question on people's minds - agile adoption. The PO's want to know what's expected of them because often it's IT or top leadership dictating (but not always leading) the agile efforts, not the product group. And Irvine, Anaheim or all Orange County is not that different from most of the US. We're in the Late Majority segment of adoptees and its just harder. 

Perhaps the Scrum Alliance needs a class on just adopting and scaling, like the Scaled Agile Framework (SAFe) or other proven patterns. In the meantime, I reply with "Its hard. It takes a long time. There's options. You'll needing coaching. And there are very, very few good coaches. Good luck to you."

Friday, November 01, 2013

The Unanswered Offshore Question, Pt 2

So, how do you know if your offshore team is as productive on onshore, and therefore saving money (as is typically the primary reason for offshoring)?

Work from one backlog (combine backlogs if working from more than one). Without specifying which team would do which story, have both onshore and offshore teams participate in sizing, or estimating, from one larger pool of user stories. You may do it together, or start by doing a few together and the rest separately. In the end, sample enough of the stories that both teams agree on how many story points various stories are.

At or before the planning meeting(s), randomize the stories or alternate each team getting whatever story is the next one pulled. At the end of the planning meeting, you'll have an estimated amount of work for each team, which gives you an idea. At the end of the sprint, you'll know for sure. Even with various issues (no product owner, newer/smaller/etc team), you'll have a number.

If you can't have both teams estimate and pull work without upfront planning or designating due to resource, knowledge, or other silos or barriers, I think you have other problems that Scrum will fix (if you want it and let it).

Thanks for all the great feedback from the first offshore post (and all the spam comments for offshoring ;-)

Wednesday, September 18, 2013

The Unanswered Offshore Question

Student: "But how does agile work with offshore team members?"

Me: "Well, let's start by asking another question - 'Why are you offshoring?'"

Student: "It was a management initiative."

Me: "Why?"

Student: "To save money. The hourly rate is lower."

Me: "But agile depends on high team interaction and collaboration. This change in how work is done might have changed the economics of the decision. How do you measure how productive those offshore teams are? That is, how do you confirm that you are indeed saving money?"

Student: "Ummmm…I don't know."

I've asked this question dozens of times. Always the same answer.

When I am coaching clients, and ask management about this, and most of the replies are essentially "It was the VP's decision, and it's not to be questioned or challenged." Considering that the VP lobbied for it as a good decision, it may not be something most would like to look into and find that they were actually wrong about that $6,000,000 decision (multi-year deal given the resources I've seen). 

The only hard numbers we traditionally had to make a ROI decision on offshoring was the hourly rate, typically somewhere from $40 - $60 for developers, and I've seen as low as $20 for testers. Seems like we're saving money, given the typical $100 - $120 rates I've seen for US developers. But what if those developers don't get as much done due to the fact they can't talk to the subject matter experts and other team members in the U.S. (at least not much of the time, and not without delays, and rarely face to face)? If agile depends on that kind of collaboration, aren't we setting the offshore team member up for frustration and failure? 

Add to this the aging of the decision data. A senior manager in India recently told me, "Those CEO's in the U.S. made the decision to offshore based on very old data." Ten years ago, he told me, you could get a ridiculously brilliant 5 Star engineer in India for 1/10 the cost of the same in the U.S. Many companies rushed into India to take advantage of this - taking all the 5 Star/One Tenth engineers (Such a deal!!), then moving quickly to the 4 Star/Three Tenths engineers (Pretty good business decision). Then large outsourcing shops and system integrators rose up to take advantage of the great staffing and consulting business opportunity. By bundling long term, large team deals, they smoothed out the bumps that they were starting to run into with 3 Star engineers and a moderately lower rate. Now, my friend said, it is very hard to find good to great engineers, so the U.S. is being offered 2 Star (and sometimes even 1 Star!) engineers for a rate that might look like a deal on paper, but these engineers are often not as good as most U.S. company's own developers, AND we using agile. 

A year or two ago, I was coaching a team that was waiting to start their project after they go the resources from the offshore partner. But there weren't any. We waited several weeks before they got one potential to be interviewed. The interviewee didn't pass the technical interview. Not even close. Nor the second, third or fourth. Finally, nearly three months into the original project schedule, the team compromised for fear of either having the reschedule or cancel the project.

If don't get the benefit from the cost/benefit analysis, is this truly best for the company? If we extend the team to realize the value for a project, because it takes 50% - 100% longer due to communication exchanges, the value itself is diminished. And the hidden cost of the quality of resources is certainly higher than the information and stories based on 5 - 10 year old projects. 

And if a company is saying that going agile is a strategic decision, we have to look at the offshoring decision to see if that is best for the teams and therefore the success of agile.

My next post will be on how to objectively, quantitatively and qualitatively evaluate the productivity and cost effectiveness of the offshore teams.

Monday, April 22, 2013

3 Things To Do Today To Add Agile to Your Project

One morning at a client site, I came across a small group of people standing up around a table in a conference room.
"So you guys are using Scrum, too?" I asked." 
"No, we're not using Scrum at all. Our project has a deadline coming up to deliver, and we thought it would help if the team just met each morning for a few minutes to talk about what got done yesterday, what's on tap for today and if anyone was having any problems."
Whether using Scrum or not, you can apply these action items below to add some agility to your project. Keep in mind that when I say agility or being agile, I mean activities and attitudes that reflect the values listed on the Agile Manifesto.

1. Meet with your project team (those doing the work) each morning for 15 minutes. Ask someone on the team to facilitate each person answering these three questions:

  • What did I accomplish yesterday?
  • What do I plan to accomplish today?
  • Is anything blocking me from getting my work done?

Interactive displays and interesting conversations at EWEA 2013


If any problem solving or discussions beyond these three questions come up, the facilitator should ask that they be held until after the meeting when others who are interested can stay and continue the conversation. This is called a daily scrum or daily stand-up meeting. It's not a status meeting, but a collaboration touchpoint for folks doing the work.

See the thorough article It's Not Just Standing Up for a deep dive.

2. Use simple collaborative tools. Especially given that most individual contributors in IT are introverts, tools such as fist-to-five (or fist of five), dot-voting, using stickies to brainstorm or provide feedback provide an amazingly different amount and type of feedback. Anytime I just ask for ideas, or what people think, I'll get a third of what I would if I asked the group to write down their ideas, or give me a fist-to-five.

The Fist-to-Five: When you're in a group deciding on something, such as where to go to lunch, you can simply have everyone hold up fingers representing where they stand: 5 means they love the idea, 4 means they like the idea, 3 means they're not that happy but they won't get in the way, 2 means they have some questions or concerns that if answered they can get onboard, and 1 means no way ever never. Fist of five is a great way to hear everyones voice and quickly see who's not in agreement and why (and then work to get them in agreement).

3. Estimate together. Estimate without bias.

I used to go to each of my team members individually and ask them to estimate the effort for their or their people's tasks. What works much better is to bring all the team members together and have them do a blind vote on what they think the estimate is. I commonly hear of only the leads or architects being asked for estimates, but whenever I ask the team if they would like for someone else to estimate their work, they say know. I think it disenfranchises them, eliminates real commitment, and therefore hurts motivation and productivity.

In the big picture, it's best if the work to be done is defined in terms of small units of working software (user stories) and using relative estimation (points) to derive when the work will be done. But that's a big shift, and if your team or company isn't going to okay using Scrum or other agile approach anytime soon, you can still use some helpful aspects of this approach.

Describe the work to be done. Ask if there are any questions. After there are no more questions, have people write down the amount of effort they think it will entail. Pick the persons with the lowest and highest numbers and ask them to explain why they thought so.
Vote again.

Although I hope they'll agree on the same number, they probably will only get closer. It's best to let the team decide the final number. Regardless, I've found that the conversation and team member engagement was so much greater in regards to the requirements and the estimates than I ever had before, and this thoughtful, focused exercise will yield much better understanding and therefore estimates.

These are just some things you can do today to improve your project with collaborative practices that shift focus towards agile values such as individuals and interactions over processes and tools.


Tuesday, October 16, 2012

Listening to Your Team


Sometimes for a retrospective, I'll have a team play the ball point game. I do this because it let's be see the team dynamics as a whole in only 20 minutes. Is someone dominating the rest of the team? Is this a team afraid to take risks? Is this a team that innovates? Is this a team that has trust, is close and works well together, or are they a group of individuals who begin to blame and finger-point when the pressure is on?

Recently I had a picture of a team that was unique to me, but perhaps common to others. It was a team that I would give an A+ to for effort and energy. They were trying as hard as the possibly could, and that was part of the problem. They were so intense, so focussed, trying so hard that they weren't listening and giving weight to everybody's ideas. Instead, in the craziness and loud voices, it seemed they found themselves guided (or more appropriately, driven) by the energy and passion of a few.

After several iterations, and even my sharing with them the performance I've seen from the vast majority of other teams, they were beginning their next iteration with exactly the same approach as before, yet committing to significantly more work. "What changes have you made since last sprint?" I asked. "We are going to be more focussed!" they said emphatically. I wish you could have seen the situation - these guys had been giving more effort and energy than a playoff team, yet were saying the missing key to success was focus? Essentially, they were saying they were going to try harder, but make no other changed and more than double their productivity.

In the quiet moment while I had their attention, I asked if anyone on the team had any ideas that hadn't been tried yet. Immediately, one then two then three people shared great ideas that would enable the team to hit their goal. Now, these people sharing their ideas were not the loud, gregarious, driving leaders. They were more likely introverts. Just like the ones that statistically make up the majority of your technical team.

Often, I'll lead retrospectives by having everyone write down their thoughts one what's going well, not-so-well, and any ideas. This ensures that I hear the voice of even the quietest (or newest or youngest) team member. Our agile teams do not succeed based on the old, traditional approach of a project manager in charge who, often, is expected to make all decision (and therefore often the only person trying to solve all problems). Agile teams rely on collective intelligence. The same way that Google has come up with great products such as AdWords and Maps, or the way that Barrick Mining found fresh approaches to find where to mine based on contest submissions from around the world (as described in Mavericks at Work). 

No one of us is as smart as all of us, so make sure that you're creating space to hear all voices and great insights of your team.

Tuesday, January 31, 2012

Recommended Reading for January


John Deere's agile success story - Not mentioned is that they have 105 teams all on two week sprints and 8 week release cycles. In one year, warranty expenses are down 50% and there's a 20% increase in first-to-market features. Read more on the blog of their agile transformation lead, Chad Holdorf. Dean Leffingwell helped John Deere, and his enterprise approach is covered in his great Scaling Software Agility session at Agile2011.

The SOPA and PIPA protests were impressive and effective, but there's more. Noted author and technologist Joel Spolsky writes about what's next. Also, we may see the birth of something truly transformative as crowdfunding becomes a platform for the common people to be heard in Washington. And in case you're wanting something to have a voice about, here something from the NY Times on how we have not taken care of the least among us.

Photos of dozens of agile team rooms. Great for ideas of how to improve your teams' areas.

Almost a dozen helpful agile tools (burndown charts, Kano analysis, checklits) available on Paul Hodgetts' site.

For those into strengths, here's a great review comparing Marcus Buckingham's new strengths assessment StandOut to StrengthsFinder, and a great interview of Marcus on StandOut, his strengths assessment and strengths in general on Drucker on the Dial.

And, on a related note, the 360 performance review is flawed because it, as a relative assessment, only says if the person getting surveyed is more or less compared to the preson asked.

Lots of interesting things coming out of Agile Leadership Europe. I particularly like the fun idea of Bathtub Conferences. Bit of info on ALE, and a rant, from Jurgen Appelo.

Need some recommendations for reading? Here's a nice, commented list of best business books in many categories for 2011, 2010, and on.

And last, do you know anyone who pair programs 40 hours a week? What if it was remote pairing? Videos, slidedecks and more on pair progamming, along with great presentations (and presentation surveys).

Sunday, December 11, 2011

Agile Presentation - Dear 31 Year Old Me

My session was "Dear 31 Year Old Me - 10 Things I Wish I Had Known Before I Dove Into Agile"
What agile practices were most important? What tools were most helpful? What books? How did you succeed? Where did you fail? What helped your career the most? If I could go back 10 years, there's a lot of things I wish that I could tell the 31-year-old me. Some lessons go counter to conventional wisdom, some are just not highlighted much. This session will cover what distilled, core lessons have helped me and teams that I've coached the most as we moved into agile.

Deck available here - 


There were some great questions during the Q & A session at the end of the day, including "If process doesn't save us, what does?" and "What's the best way to start up new teams in an agile adoption?"

Thursday, December 01, 2011

Three Simple Tools for New Teams

When I am delivering Certified ScrumMaster classes or starting up new agile teams, I share three simple tools that really help collaboration: creating a working agreement (also called team agreement), the art of the possible, and the fist of five. Based on feedback, these three items are often some of the important tools that team members take back and use immediately. Below is a simple way to introduce these by facilitating creating working agreements with your team.

Photo by Greencolander via Flickr.

Before you kick off your new team, get the team together and let them know the goal is to come up with some team agreements so that we all agree on how we’re going to work together. You might have some ideas, but first go around and hear others first. If you’re in a large group, pair up, otherwise each person can individually write down one statement about how their time together should be – everything from working hours to working conditions. Now collect these and put them on the wall, under the title “Working Agreements.” For general work, I often hear: take personal calls out of the working area, headphones on for music, keep your chat program on, put a flag or sign up if you don’t want to be interrupted (for less than an hour), shower regularly (seriously), no eating fish at your desk (yep, that too). Some common ones for meetings that I’d recommend are: one conversation at a time, start and end on time, electronics by exception (that is, no cell phones or computers unless it’s an emergency and everyone understands that), and have an attitude of the art of the possible.
The art of the possible means keeping an open mind that something covered here could work ormight be true, even if you disagree, instead of an attitude of “that could never work here” (even if that is your experience). There’s always a first time, and the difference of our attitude, effort and approach differ vastly when something “just might be” possible, rather than impossible. MacGyver believed in the art of the possible.
Now that we have everyone’s recommendations, decide on what the final working agreement list will be. My preferred way of collaborating on quick yes/no group decisions is with the technique called the “Fist of Five.” When you’re in a group deciding on something (such as where to go to lunch that day), you can simply say the recommendation and then have everyone hold up one to five fingers. The number of fingers represent where they stand: 5 means they love the idea, 4 means they like the idea, 3 means they’re not that happy but they won’t get in the way, 2 means they have some questions or concerns that if answered they’ll get on-board, and 1 means “No way, ever, never!” (and make sure the one finger is the index finger…) Fist of five is a great way to hear everyone’s voice and quickly see who’s not in agreement and why (and then work to get them in agreement).

I hope these tools help your team get off to a great start.

(This post also published on the BigVisible company blog at http://www.bigvisible.com/2011/11/three-simple-tools-for-new-teams/)

Sunday, July 31, 2011

More Information or More Change?

I have choose where to spend my time in August. The biggest conference in agile is coming up, as well as the most impacting leadership conference. Was I going to spend time learning more about agile, or was I going to spend time at the conference that had changed my life more than any other? The latter is The Leadership Summit - where I first heard Marcus Buckingham, who's work on strengths was the catalyst for change in what I was doing as a manager. It was where I heard Ken Blanchard, and then hunted up a copy of The One Minute Manager. I heard Colin Powell, Colleen Barrett (previous President of Southwest Airlines), USC President Steven Sample, as well spiritual leaders Erwin McManus and Bill Hybels.

While there's a lot that I've learned about agile principles and practices at conferences, more importantly I've been changed by The Leadership Summit. A parallel is that much of my coaching comes from a mix of business and faith-based (not agile) books I've read. As Seth Godin (speaking this year at The Leadership Summit) recently wrote, there is no such thing as business ethics, only personal ethics. I find myself at a loss when talking about Scrum values such as Courage, Openness, Respect, Commitment when there is no agile book or talk that I know of that coaches people on how to grow in these areas. Even getting agreement on what it means to coach at all is subjective.

I feel a responsibility to let others know that each of us needs to know where our roots are in these areas, and with conviction and confidence that goes beyond opinions and trends but can stand up to the challenges we have and will encounter when trying to introduce change in the jungle of the business world. In the end, I decided that I needed to fill up the personal leadership tank, and decided to leave the Agile 2011 conference early so as to not miss any of The Leadership Summit.

Tuesday, July 26, 2011

How to Select an Agile Consultant

How to pick an agile consultant to help your company? I've learned a bit after helping a number a dozen or so companies and working alongside another couple dozen agile coaches. I started this post to describe the types of people I see out there, but what seems more helpful would be to provide guidance for those looking at bringing someone in to help them. Here's a cheat sheet of questions.

  1. Have they been a ScrumMaster on a team?
  2. Have they been the ScrumMaster on a project in Scrum from inception to completion?
  3. Have they worked in 1, 2 and 4 week iterations?
  4. Have they been the ScrumMaster on a  project with distributed team members or with a vendor?
  5. Have they introduced Scrum or agile to an organization where it was new? Specifically:
  6. Did they train team members on Scrum? 
  7. Were the teams fully-dedicated, cross-functional teams?
  8. Did they work with department managers on team composition, managing team members and other changes?
  9. Was there a PMO in the organization? Did they work with them on the agile roll-out?
  10. Did they initiate and facilitate release planning?
  11. Have they lead a multi-team roll-out? 
  12. Have they coached other ScrumMasters?
  13. Have they facilitated multi-team release planning?
  14. Have they collaborated with company leadership on crafting an agile adoption plan?
  15. Have they worked on an implementation of a new product?

Transitioning a small company (< 50) to agile is generally much easier than large companies. I've found more people who are there for career security and corporate ladder climbing in large companies than small. And these people see the fear, uncertainty and doubt in agile more than the gain (for the company, but more importantly, themselves). I've also fond more people in large companies who can get away with lower performance, and the visibility of agile can be scary. The approach, therefore, for large companies needs to be much more than the principles and techniques of agile. It needs to be strategic in determining who is influential, understanding how they feel and what are wins for them personally, as well as doing your best to make sure there are clear, early wins for agile in the company so that everyone can relax a little and get behind this thing. In some ways, this is no different from any change to an organization, and it's a bit like sales.

If you work at a large company, you'll need help. Going to the Certified ScrumMaster class is only the beginning, not the end, of finding out the how and why. There are now a lot of people out there who will sell you something that looks like help. In order of visibility...

  • Agile Networkers. Connected with a lot of agile coaches, trainers, thought leaders and businesses. As far as what you need, they may not be, but they might know people who are. Networkers may not have the agile experience to vet their connections on a professional level, or the depth and length of a personal relationship to vet the character, so the people that they recommend to you should still be evaluated independently. Keep in mind that often the main goal of the agile networker is looking to get connected with people and activities (training classes, conferences) that can help themselves, and hopefully help others. 
  • Agile Consulting Companies. They might have polished materials and perhaps a list of training classes, webinars or speaking events, but look at the questions above to evaluate the substance behind the materials.
  • Agile Trainers. Due to the popularity of Scrum, there are a lot of Certified ScrumMaster classes, but only a few who can do the training. Besides the CSM, there are a lot of other trainings out there, most of which I think are valuable. You might love the class, but someone being a great trainer and great coach involve very different skills and abilities, and I don't know that all the people can (or even want to) be both.
  • Agile Coaches. There are several different kinds of coaches, and you likely need some aspect of all. Most coaches can get a team going with agile and work through the people and team issues that arise. There are times when the business needs a level, though, that works with getting the executive team on board, working through strategic planning and political issues. This is much more about listening, building rapport and trust, patience, staying persistent and positive and selling by influence. Another key aspect of coaching is technical or software craftsmanship - being able to guide programmers and other team members, with hands on the keyboard, into the new world of test-driven development, continuous integration, pair programming and other agile practices (and hopefully you know how critical these areas are to the success).
In the end, nothing beats experience, and preferably a team of experienced people.

Friday, June 10, 2011

Introducing Scrum at Your Organization


A Bad Prescription
I am often asked for advice on how to either introduce Scrum and agile at an organization, or how to roll-out from a given implementation of a team or teams to a broader level, such as program or division level.  While there is much to be said on this topic, it is best to start off with the imperative that there is no prescriptive approach that will work for everyone. There are many approaches, some successful despite being counter to standard recommendations. There are important contextual variations, such as company culture, personalities, recent experiences and history, project storyline and product market space that may all play an important part in how to roll out agile in your organization. This section will review some of those aspects, tools you can use, and then get to general recommendations.

Simply, here are the most important points that I have seen be effective:
1.     Ask why management wants to go agile. What is the win for them? Define success together. Rally co-creates Agile Success Plans at the beginning of customer engagements.
a.     Look at Geoffrey Moore’s adoption curve and mark where you think the company sits. Based on that, what is that group’s standard view of risk?
2.     Looking for the natural law win for those involved. Whether backers, decision makers or influential, be sure that you’re aware of or find out what would make this transition a win for each person. Along the way, you should find out, or uncover, what their concerns are (fear, uncertainty and doubt).
a.     Take a look at George Schlitz’s presentation on Mapping the Agile Battlefield for a deeper look at this area.
b.     The book What Got You Here Won’t Get You There is a coaching-view towards helping managers succeed in change situations like these.
3.     Remember that your agile roll-out plan and effort in itself should be agile. Plan it, and then routinely assess what’s working and not working in it, and adjust.
a.     Organization change is not complicated, it’s complex. Look at the Cynefin model and remember to gather data, especially people and process narratives and then determine what to do next.

If your company isn’t agile yet, but you want management to consider adopting agile, consider selling it based on the success of other well known companies. That might lighten their risk.

Monday, February 28, 2011

One Month to Live

My friend Brad asked a question last week that struck me so hard that I lost track of the conversation for a bit, lost in my thoughts. What if I only had 24 hours left on this earth? For most of us, it's fairly similar - going and letting all those we care about how much we love them, maybe forgiving some people or asking forgiveness. As powerful as that is, in my friend's opinion, how much more powerful if the question was "What if you had a month to live, or a year?" That question is richer, deeper, because you had time to do something, other than just communicate. You can change. And you can change lives.

Brielle Murray has changed a lot of lives. Barely 13 years old, she has touched many, many lives as she faced RMS cancer for the last three years. She passed away on Friday, February 17 at 9:45 A.M. In her room were still thank you cards and valentines that she was making for others. Brad's question had me going over and over Brielle's short life - here she was thinking of others while facing unbelievable challenges. Perhaps that question is part of the answer.

In our culture of Me First, we don't often think of what's left behind when the Me is gone. And yet, that's what's lasting. Recently, I was talking to a key person in one company's agile adoption and he kept referencing how one executive had made such a difference. When I went on LinkedIn to find out more, I saw that the executive had moved on to another opportunity years earlier. But you wouldn't know it from the way the agilist was talking - it was like the executive was still there. In some ways, he was. That exec was still making a difference through how he had impacted this agilist, and now how that agilist was coaching his ScrumMasters, QA folks, developers and others on the teams he was over.

You can make a difference. You can change lives - the way people view challenges, believe in themselves, respond to failure, treat others. But it doesn't start later. It starts now. It's starts with the focus, resolve and passion you would have if you were just told that you only have months or a year to live.

Below are some resources on how others responded to the same question -

Technorati Tags: , , , ,

Tuesday, March 23, 2010

Goals for Agile Teams

When working with companies who are trying to adopt, or correct, an agile approach to their projects or product development, usually using Scrum, the situation, needs and specific problems vary. But the core needs, and root cause of problems, doesn't typically vary that much.

With that in mind, I have a few goals that help me stay focused on the "main and the plain" of agile, and begin with the end in mind (to borrow from Steven Covey).

My Goals for New Agile Teams :
  1. That they know, understand and practice the Scrum framework
  2. That they are aware of where they aren't, the possible consequences, and the limitations (domain) of Scrum
  3. That they know, understand, and are living the agile principles, Scrum values and self-organization
  4. That they are aware of other agile methods and the pros and cons
  5. That they are connected to community and learning sources
  6. That they gel and are moving forward as a team
  7. To understand why management wants Scrum/agile here
  8. To know their definition of success
  9. To understand what they see as their opportunities and challenges
And my personal goals when coaching agile teams:
  1. That I set and meet expectations each week
  2. That goals are stated and progress visible
  3. That goals clearly align with my customer's goals
  4. That I understand what it means to meet and exceed expectations
  5. That I understand what will help them move forward, and have contributed to that
Technorati Tags: , , , , ,

Monday, March 15, 2010

Kanban Book Review

I just finished reading Kanban and Scrum - making the most of both, by Henrik Kniberg and Mattias Skarin. You can download it for free. I was very impressed by this self-published book, enough so to place an order today on Lulu for a paperback version.

Despite my readings of blogs and listening to podcasts on Kanban, it still wasn't clear to me. Knibert and Skarin broke it down so clearly for me that I finally got it. They took a simple approach, used lots of drawings, as well as comparisons to Scrum that helped related it to something I did know.

Here are some of my favorite quotes from the book:

As teams evolved from individuals to self organizing units, the managers realized they were facing a new set of leadership challenges. They needed to deal more with people issues – handling complaints, defining shared goals, resolving conflicts, and negotiating agreements.
...
The WIP limits are there to stop problems from getting out of hand, so if things are flowing smoothly the WIP limits aren’t really used.
...
The only thing that Kanban prescribes is that the work flow should be visual, and that WIP should be limited.
...
What should the Kanban limits be?
When the Kanban limit for “your” column has been reached and you don’t have anything to do, start looking for a bottleneck downstream (i.e. items piling up to the right on the board) and help fix the bottleneck. If there is no bottleneck that is an indication that the Kanban limit might be too low, since the reason for having the limit was to reduce the risk of feeding bottlenecks downstream.
...
If you notice that many items sit still for a long time without being worked on, that is an indication that the Kanban limit might be too high.
•    Too low kanban limit => idle people => bad productivity
•    Too high kanban limit => idle tasks => bad lead time

...value stream map. It’s basically a visualization of the value chain and provides insight into work states, flow and time through the system (cycle time).

Over time, managers learned that if they kept number of concurrent projects low, they didn’t keep stakeholders waiting.
The need to project delivery date was no longer a big issue. These lead managers to stop asking for up front estimates. They only did if they feared they would keep people waiting.

And I particularly loved this approach with management, and of course their results overall:

But keeping traction on complex, infrastructure type issues was a harder ordeal. To deal with that we introduced the ability for teams to assign up to 2 “team impediments” to their managers.
The rules where:
1. Manager can work on two slots at any single point of time.
2.    If both are full, you can add a new one as long as you remove the less important one.
3. Team decides when issue is solved.

Three months after introducing Kanban, the system administration team was awarded “best performing team” in the IT department by the management. At the same time, the system administration team was also voted as one of top three “positive experiences” in the company retrospective. The company retrospective is a company-wide event that happens every 6 weeks, and this was the first time that a team turned up on the top 3 list! And just 3 months earlier these teams had been bottlenecks that most people were complaining about.
For those trying to learn about Kanban, or those responsible for leading, coaching and/or training Scrum in your company or for clients, I highly recommended this book.

Technorati Tags: , , ,

Sunday, January 31, 2010

Agile Leadership and Management Presentations

From my two Code Camp presentations on agile, leadership, management and strengths, I've linked the handouts and made a list of the books referenced. Great conversation and shared learning with everyone. Several additional resources that I mentioned are Pragmatic Learning and Thinking, Mavericks at Work and What Got You Here Won't Get You There. I added those books to a list of leadership and management books on Amazon to make it easier to track.

Here are the links to my presentations on Leading a Team and Developing Team Members - management and leadership and Scrum and Agile - People and Problems: Teambuilding with Agile and Strengths.

Technorati Tags: , , , ,