A Full Week of Leadership Activities at PMI

Posted on
Reply

I just finished a week of activities at the PMI Leadership Institute Meeting, here in Washington DC. It was an amazing experience that reinforced to me the amazing value of volunteering at PMI.

Leadership Masters Class is “High Class”

My first 3 days were spent participating in the PMI Leadership Institute Masters Class program. This is a year long selective program to build the skills of PMI’s volunteer leaders. This first of three face-to-face sessions featured a bevy of interactive exercises and table discussions, allowing us to dig deep into the leadership question of trust. We also took a personality inventory called Strengths Deployment Inventory (SDI), where I gained some very un-nerving insights into how I respond to conflict.

The program is very focused on facilitating learning through relationships. One of the features was the class broke up into groups of 5 “learning partners”. My learning partner group is committed to building the relationships needed to hold me accountable on my objectives.

learning-partners.jpg

One of the more impressive elements of the class was the participation of PMI CEO Greg Balestrero. He explained that his strategy to support and grow it’s half-million constituents includes a focused investment into its 10,000 volunteer leaders. For him, leadership has become a critical strategic competency at PMI. Greg is a very busy man, with a very busy schedule. So, when he spends a morning with a group of 30 volunteers, it means he believes what he says.

greg-at-LIMC.jpg

 

 

In truth, I came to this kickoff event with some initial concerns. Some of my colleagues had heard and experienced mixed results with this PMI program. But I can honestly say I walked away very pleased, having become a more self-aware leader after only the first part of the program.



 

A New Direction for the PMI Agile Community

I spent a significant amount of time with Mike Cottmeyer, Brian Bozzuto, and Dennis Stevens planning the 2011 direction for the PMI Agile Community of Practice. Indeed, we skipped several sessions and instead had talked through the whole agile PM space, what our members are looking for, and how we can really promote the discipline of Agile PM. Here are some of the key outcomes from that discussion:

  • Mike Cottmeyer will be the new Chair of the Agile Community of Practice. For 2011, the roster of our community leadership council will remain unchanged. I will continue to serve on the council along with Dennis, Brian, Ainsley Nies, Bob Tarne, and Mike Griffiths. However, MIke has generously agreed to take the chairmainship for 2011, allowing me a bit of a break. Also, 2011 will be the year we host our first community elections, and transition the community leadership to a new batch of members.
  • We have an operational plan in place. Yes, many of us are skilled agile practitioners, but our distributed virtual setup really prevented the kind of self-organization we tried to foster last year. This week, we realized on many fronts, that our community volunteers need much more detail around what needs to be done, and how to do it. So, here is the plan to address that:
    • 2010 Q4 – The council will do the homework of (a) identifying the key initiatives for 2011, (b) generating the detailed acceptance criteria for each initiative, and (c) researching the how-to-instructions for implementing those initiatives
    • 2011 Q1 thru Q4 – Then, we will complete the handoff to more and more volunteers to implement those initiatives on a quarterly basis during 2011.
  • This year is going to be BIG for PMI Agile. During the week, we had the chance to talk with the staff at PMI headquarters about the Agile community and Agile PM in general. Already I’m seeing signs at the Congress of PMI’s growing investment in the promotion of agile. Their members are begging for vetted content, and PMI is responding. Also, with a new chair and a new volunteer base coming into place, we have a new infusion of energy to deliver more momentum.

This week was about connecting with leaders. Mike Cottmeyer had similar relections here, and Derek Huether enjoyed happy hour the most. PMI is a great place to find passionate, dedicated leaders, who will partner with you on your mission. I made some very good friends this week, and I am finding that it is your friends that shape who you are. You should strongly consider getting involved yourself, either as a volunteer at your local PMI chapter or with the PMI Agile Community of Practice.

Use Innovation Games To Collaborate on Anything

Posted on
Reply

 

InnovationGamesLogo.png

Last week, I attended the most awesomest, super-cool, rock-my-world training class on collaborative problem-solving. Luke Hohmann of the The Innovation Games® Company taught a class of 20 consultants how to use his Innovation Games® approach to team facilitation. Not only was the class filled with some already very strong facilitators, but Luke was able to give us some concrete tools to go to the next level.

 

Seriously? Games at the office?

Luke talks about a sector of the game world called “Serious Games”. These “games” are actually interactive exercises designed to get work done and attack very real-world business problems. For example…

  • To understand what you need to improve, play Speed Boat.
  • To understand what features you need to build into your next product release, play Buy a Feature.
  • To understand new possibilities, play Product Box
  • To understand how & where your product fits into the market, play Spider Web

 

RememberTheFuture.jpg

Seriously? Any Office Problem Can Be Made Into A Game?

The full package of Innovation Games consists of 12 different interactive exercises, which you can read about here. However, that’s not all. What really blew my mind was the possibility to turn any graphic into a collaborative tool. Here’s an example. Let’s say you want to get a sense of what questions we need to answer at each stage of a project. On a large paper printout of the project stages, team members will post a sticky note to the left side of each stage. Then, team members post on the right side of the project stages a set of interactive exercises we can perform to answer those questions. So, if at the portfolio level, we want to know which projects to prioritize, we can play Buy a Feature.

 

CustomInnovationGame.jpg

 

As a management trainer and coach, I already had a number of collaborative exercises in my toolkit. But now, I have over a dozen more to choose from, as well as the foundation to create an infinite number of situation specific games. If you are a trainer, speaker, consultant, or team leader, then I strongly recommend you go sign up for this course (not an affiliate link). It will make you dramatically better at working with knowledge teams.

Bangalore India Talks About Scaling Scrum

Posted on
2

NewImage.jpg

This week featured the latest gathering of Scrum prapractitioners in Bangalore. This free event drew a solid 50 participants for the second straight time, and featured some really smart technology workers. The group was about 50% developers, 25% testers, and 25% managers. I did get to do my standard presentation on Agile Contracts, but the broader theme for the day was “Scaling Scrum”. This was of great interest to me, since RippleRock is helping a large dotcom implement Scrum across two strategic pilot programs using 4 teams on 2 continents. Needless to say, I took copious notes below

Scaling Scrum

First off was Vibhu Srinivasa from Solutions IQ. People laughed out loud as he facilitated a team dynamics game. But what people came to hear were his points about using Agile techniques on really large projects:

  • Understand Why You’re Scaling – The point is not merely to have an official standard for managing work. The point is to create alignment across larger projects, to make sure people are on the same page about delivering on a business objective.
  • Understand What Scale Means – To help bring alignment to our own large group Vibhu offered this definition of large-scale agile projects: “A group of teams working together on a common product or project or portfolio”.
  • Well groomed backlog is required to scale Scrum. For a single team of 7 people, a poorly formed backlog will only impact that team. On a larger project of a dozen teams working on the same poor backlog of project work, then you’ve just scaled the associated pain and errors.
  • There are several ways to nest Scrum teams. In general you can have nested backlogs of increasing degrees of detail, but there needs to be a clear, singular owner of each product backlog.
  • Charter a Product Owner team, responsible to keep the backlog groomed and prioritized. In larger organizations, the Product Owner role can quickly get to be too much work for one person. Have relevant stakeholders meet as required, above and beyond any other meetings with the Scrum team.
  • Align the sprint schedules. Namely, it helps if everyone is working to the same deadline.
  • Use the Scrum-of-Scrums only to coordinate dependencies. The overhead associated with the Scrum-of-Scrums is best utilized less as a status meeting, and more of an impediment removal meeting.
  • Relentless Automation – Just scaling scrum management is not enough. You need continuous integration, low-cost regression testing, and  ”touch free” deployment.
  • Rotate ScrumMasters – Spreads skill and awareness of Scrum and alleviates anxieties about career path.
  • Ambassador Pattern – Fly people to their distributed counterparts for key meetings or even for an entire sprint . This help preserve team dynamic,  when individuals return to their home base.

Vibhu Srinivasan

 

Globally Distributed Agile Teams

Then, Rini van Solingen. the CTO of iSense Prowareness, joined the group over skype. He started off with describing the “30 meters principle”: When teams are distributed more than 30 meters apart, the communication frequency drops to near zero. So, it doesn’t matter if your 3 time zones away or 3 miles away, the real limit is 30 meters.

This is a bit of an obsession for Rini, who is working a research project at TUDelft called “Creating the virtual 30 meters”. In this research, he has found some best practices:

  1. If a single roof is possible, do it! Don’t distribute if it’s not absolutely necessary.
  2. First, deploy Scrum locally and effectively before working distributed.
  3. Assign Scrum roles explicitly. The Product Owner and proxy roles becomes even more critical.
  4. One team in one rhythm. Staff your regional teams with people from all other locations. This is the “ambassador pattern” described above.
  5. Meet. Teams are not built by themselves. You need to actively establish relationships by traveling to each other’s sites.
  6. Impediment removal and retrospectives are even more crucial. In fact, meet collectively for retrospectives (see previous item).
  7. Work at the customer location at least between 10-20% of the time.
  8. Personal mindset is crucial: “what did *I* do wrong? what can *I* do different? how can *I* help?”.
  9. Don’t focus on tools: discussion and interaction are more important.
  10. However, communication and awareness don’t happen automatically. Here, tools can help, but only if implemented with the right purpose in mind.
  11. Fail fast: improve empirically. Both success and failures are sources for learning.

 

Open Conversations

The day wrapped up with an open space session. A number of topics were suggested, but the top two were two key topics:

scrum-bangalore-open-space.jpg

 

  • Estimation: In this conversation, there was a lot of discussion about the expectations around estimates. Managers expect your estimates to be internally consistent, when in reality they aren’t. They also expect your actuals to match those estimates exactly, but in reality they were really just estimates. One suggestion was to begin using the word “forecast” instead of “estimate”. Doing so may emphasize the fact that the numbers are rigorous, but not iron clad.
  • Careers. Here, there was concern about the impact Agile roles and responsibilities have on your career. For example, if a developer takes the risk of helping lower-paid testers learn code-based automation, will that make him less needed? If a BA takes the risk of not writing all the details for all the requirements up front, how will her skill be judged? If we take the risk to move in the professional direction of Agile skills, is there a job market for those skills? The answers are not easy. If you work for bad managers, then they may punish you for doing the right thing. But then again, they’re probably already doing that. And really, the your career should not be based on a choice between Agile jobs or non-Agile jobs. Your career should be based on what makes you and your team most successful.

 

It was an eventful day. iSense does a really good job of organizing this. I look forward to the next one at the end of September.

Bad Requirements? Actually, That’s Your Fault

Posted on
8

This is a reprint of my column in this month’s PM Network magazine. Click here, and then search for “The Agile Project Manager”

I’m growing weary of project managers whining about bad requirements. The truth is, no one can possibly be surprised. From research studies to high-profile disasters, we hear over and over that incorrect requirements and poor scope management are key reasons projects fail. If we know this is a recurring problem in our profession, why do we mindlessly continue engaging in the rote repetition of what doesn’t work? I’d like to share some suggestions to keep us from stumbling over the same mistakes:

Surrender the pipe dream of complete requirements.
There’s always going to be one dependency missed, one stakeholder we didn’t interview, one nuance hidden, one more thing we wished we had known. Don’t fall into the trap that more is better or you’ll never get started.

Always assume the initial requirements are wrong.
Sometimes the scope is inappropriately slanted toward one stakeholder or hasn’t been properly vetted. Sometimes the bulk of the requirements are actually “nice-to-haves.” Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure that you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with the sponsor to refine it.

Accept that all requirements change.
Traditional project management culture portrays change as a necessary evil, like traffic laws: If drivers did everything right, we wouldn’t need them. To mitigate the “risk” of change, we install intimidating change-control boards and financial penalties. But what if the scope you’ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your sponsor continue paying for what is now
essentially a useless deliverable? Not in my estimation. If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) warns: “Because of the potential for change, the project management plan is iterative and goes through progressive elaboration throughout the project’s life cycle.”

Simplify your change-management approach.
Agile project managers explicitly embrace the value of responding to change and institute project policies accordingly. Start by implementing a contract structure that supports authorized change rather than penalizes it. At the start of each iteration, mandate a high-level yet thorough revision of scope priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, re-baseline earned value metrics at least every three to four iterations to match the latest scope. And while you’re at it, proactively communicate the latest scope to all stakeholders.

If you consistently find your requirements getting you into trouble, do something about it. It’s your responsibility as the project manager to be adaptable to your sponsor’s needs. Stop taking the requirements for granted and start equipping your sponsor to make the right scope choices.

Agile Co-Founder Issues a Call to Action: Stop Bickering

Posted on
10

oath-of-non-allegiance-badge-large.png

As a project manager, a member of the PMI, and an Agile Project Management practitioner, I get yelled at a lot. PMP-certified project managers call me irresponsible for advocating the Agile approach to projects, and Agile practitioners call me a turncoat for collaborating with members of the PMI. It’s understandable that people who are used to one way of doing work are skeptical of another way of doing work. I get it. But does get tiresome. Last year, a fellow Scrum trainer called me a placator, akin to Neville Chamberlain, and it was not meant in a lighthearted manner. However, I am not the only recipient of that kind of vitriol. The Agile PM community is riddled with factions and in-fighting. In the pursuit of truth, many of our so-called thought leaders have taken rather inflexible positions of “No matter what you say, I’m right and you’re wrong.”

Well, today I’m in a collaboration session today with technology management thought leader Alistair Cockburn. In our chat today, he introduced me to his latest initiative, The Oath of Non-Allegiance. It is a web page that challenges Agile practitioners to formally sign and ratify the following:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

Finally! Someone has taken a stand to hold these Agile thought leaders accountable to the core value of “Collaboration” they all advocate. As a co-founder of the Agile Project Management movement, Alistair has been dragged into many of these philosophical feuds. I’ve always appreciated him for advocating the Scrum alongside his own Crystal methods. It’s a strong statement to say your thing is good, and this other thing is also as good, and you’re willing to teach them both.

QUESTION: What do you think of these Agile factions? Do you think this Oath will help the issue?

 

Scrum Gets Going In Bangalore

Posted on
Reply

This past Sunday, May 31, 2010 saw the kickoff event for the Scrum Bangalore user group (photos available here). It was a 6-hour mini-conference that featured 2 speakers, and open-space, networking, and several prizes. Also in attendance were the Agile Bangalore user group, an online community led by Vinay Krishna.

Rahul Sah Kicks Off The Event

Scrum Bangalore is the product of Rahul Sah of the Dutch company iSense Prowareness. He started the event by setting a vision: there is a huge gap between the demand and the support for Scrum in Bangalore. He said that he was charged by Jeff Sutherland to start something, when it was observed that the most Google searches for “Scrum” originate in Bangalore, more than anywhere else in the world. Before this month, there were no formal user groups supporting the local Agile practitioner community in Bangalore; now there are two.

rahul-sah.jpg

 

 

Pete Deemer Wows the Crowd.

The headliner was long-time South Asian Scrum trainer, Pete Deemer. He shared with us his 19 keys to successful agile adoption. It was a great talk with lots of energy and insights. At the end of the talk, he amazed the group with several giveaways, including a copy of Mike Cohn’s latest book for *everyone*. A very generous gesture indeed. 

 

pete-deemer-book.jpg

 

The “Amriki Gaura” Gives it a Go

In the afternoon, I got up and introduced myself to the crowd, sharing my story of starting an Agile consultancy in India. I then facilitated a group discussion about how to overcome key challenges with Agile Adoption. We used the “12 Key Objections to Change” from the NY Times bestseller Switch (a great book I will discuss later). Both Pete and the group offered some excellent points:

  • Change is like a rebirth
  • Many agile teams are technically proficient, but behaviorally are still stuck
  • Driving in Bangalore is the essence of a self-organized system
  • Scrum is a paradox: we offer specific guidance on success, but must encourage the team to choose its own direction
    • 

facilitating-discussion.jpg

Agile India Moves Forward.

Afterwards, I had some drinks with the new leadership team of the Agile Software Community of India (ASCI). We talked about the 2010 spike of activity in India around Agile projects, such as:

  • Agile Coaches camp in Goa earlier this year
  • Launching of 2 user groups in Bangalore
  • Four (4) scrum trainers offering classes in India, instead of Pete Deemer being the only one
  • The forthcoming announcement of the Scrum Day India event in August

It is an exciting time to be a part of this community. And I’m looking forward to an eventful remainder of 2010.

QUESTION: What other signs of increased interest & momentum around Agile engineering or Agile project management are you seeing in India ?

 

The 19 Keys to Successful Agile Projects

Posted on
6

nineteen.png

This past Sunday saw the kickoff of the Scrum Bangalore User Group in Bangalore, India (more on that later). At the meeting, Scrum expert Pete Deemer gave us these 19 nuggets of wisdom from his many years as an Agile coach for organizations across the world.

  1. Do it for the right reasons: Like Harry Potter, when evil wizards use good magic for evil purposes, they get destroyed.
  2. Start with teams that want to try it: It’s counter-intiutive, but don’t force a pilot effort onto resistors. Have the teams pick themselves. Then, set their expectations: “Are you sure you want to try it? It’s really dangerous. You can try it, but only for 1 sprint”.
  3. Set realistic expectations for Scrum: Don’t go in saying, ”Scrum will save our disaster project”. Force a project restart & give the team 3-5 sprints of breathing room. That’s how long it takes to get to all cylinders/cruise control.
  4. Call it a pilot program for as long as possible: People assume a pilot is messy, and nor will a pilot threaten their long term career.
  5. Change is scary to many people: Humans aspire, in an unfriendly world, to protect ourselves with some stability and predictability. Introduce your changes gently: “Scrum may not be right for us, but we won’t know until we’v tried it. So let’s do it all-in, correctly, for 1 sprint. Did we see any benefit? If so, let’s do it one more sprint. It’s one way of working. It’s not the final way of working, but it might help us get a little bit better”
  6. Patience is a virtue: - Start with 1 team and grow gradually from there. You don’t want 20 teams all struggling with the same issue we’ve yet to figure out.  Instead, it’s better to have one trailblazer fix that issue so others don’t have to.
  7. Find the Scrum middle path: In some ways, my job is a purist advocating the dramatic change, speaking hard truth, but then encouraging teams to tailor the practices to their situation. Be careful though; many organizations respond to the pain of change by diluting the change.
  8. Scrum is hard: it surfaces your nasty, accumulated junk. If you’re not prepared to deal with the issues that Scrum reveals, then it will be very hard to continue.
  9. Get experienced help: Consultants are not afraid of getting sacked, nor do they have a departmental agenda.

pete-deemer-scrum-bangalore.png

  1. Get high quality training: Often, adoption failures are associated with the initial training provided by someone who was told to read a book over the weekend. Better to send 1 person to really good training, than to send 20 people to bad training.
  2. Your enemy is your friend: Spend the most time with the people that like Scrum the least. Put your chief resistors on the Scrum steering committee. If they’re not engaged, they’ll miss how it works, and feel marginalized.  Also, those resistors will help you understand the key roadblocks to successful adoption.
  3. Be prepared to use Guerilla tactics: Namely, if management won’t solve your problems, sometimes you solve them yourself. One example: get your own screwdriver and change the cubicles over the weekend.
  4. Find your guardian angels: You need senior managers who “get it”. When you need to bend a corporate rule or special budget funding, your guardian angel. Indeed, many executives are eager to try an Agile approach, because they’ve worked on so many project train wrecks over the years.
  5. Make good information more accessible than bad information: There is a ton of bad information on the internet about what an Agile approach is or isn’t. Establish a steady flow of good information with email updates, brown-gab lunches, staff meeting talks.
  6. Measure the results early and often: Publicize the good and the bad results. Have both business and technical metrics. Use surveys to measure both the customer’s satisfaction and the team’s satisfaction.
  7. The urge to tinker is great: To illustrate the difference between tailoring and compromise, Pete described a game of “CricketBut”. We play Cricket, but instead of a pitch, we’ll use my living room. Instead of a wicket, we’ll use my dog. Instead of a ball, we’ll use a brick. Instead of a bat, we’ll use my head. After a few overs, you will have bloodshed, just like at the office.
  8. Choose your tools carefully: Don’t ask “which tool should we use”, but ask “What problem are we trying to solve that makes us think we need some software tool?”
  9. Don’t stop with just the members of the Scrum team: Scrum is an organization framework. Often a team can be successful on a localized level, but the organization is stuck in bad habits and the success is not fully realized. You as a team might be able to deliver results, but if it doesn’t get out to the end customer, who cares?
  10. Scrum will always be messy: The Agile movement is fundamentally about people and what they do. If people aren’t perfect, then our projects will never be perfect either. You will always have conflict, mistakes, and challenges. Simply ask yourself, “is it better than it was last month”.

It was a lively talk, that yielded some good points. Pete has a witty energy about him that made the talk even more enjoyable.

QUESTION: what have you seen to be the keys to successful Agile projects?

3 Steps To Keep Just About Any Manager From Yelling At You

Posted on
2

Given that I’m in the midst of a major career transition, I’ve been reflecting back on the highs and lows of my years as an IT professional. It’s been a rewarding exercise, and I’d like to share some of it with you here in the next couple of posts. And what better way to start than with one of the worst days of my life.

angry manager

The Blowup

In my first job out of college, I was a computer programmer on a large government project. After about a year or so on the job, a senior team member (let’s call her Terry) was promoted to manager. With that promotion, our relationship changed from senior-junior colleagues to superior-subordinate. What I didn’t realize was that she brought into her new role some initial impressions and expectations of me as a professional.

After one particularly bad month, she called me into her office, and started unloading. I can’t remember the exact words, but they went something like this…

Jesse, you really messed up that last software module. Because you weren’t able to figure out the solution, your team lead had to come in and finish it for you. Consider the impact of that, Jesse. Because he spent so many hours helping you, his own assignment was late also. Remember the last time this happened?

…um, no I don’t. When?

It was the file manager. Remember how much trouble you had with that? Don’t you realize there is a pattern going on here, Jesse? Now, I’m left wondering if I can give you anything substantive to work on, or if we’ll just end up having to send someone else bail you out of the next problem. In fact Jesse, I simply can’t believe you spent so long on the module without getting anywhere. I think you knew your team lead would be there to bail you out and so you didn’t try as hard as you could have.

…are you saying I messed up on purpose?

That’s what it looks like. I don’t know what to do with you, Jesse. But whatever your issue is, you need to fix it, FAST!

Step 1: Get expectations out in the open.

Yeah, it was that bad. But when I look back, the root cause of her blowup was simple human disappointment and frustration. From her perspective, I was the key issue. But the real problem was that I had no idea.. She was viewing my previous difficulties as a liability, and had put me on a secret probation. Instead, the two of us should have known way ahead of time what was expected of me.

  • For managers, you need to be 100% positive your team members know what you expect of them. When you move into a new leadership position, you should have both private and group discussions about what people understand their roles to be, what the team expects of you, and what you expect of them. Obviously, Terry didn’t do that, so I was left to continue my current work style, setting me up to fail.
  • For team members, just because you’re not a manager, that does not mean you’re not off the hook. Expectations are a two way street. Namely, if Terry didn’t initiate the expectations chat, then I should have. I learned this from the One Minute Manager books by Ken Blanchard. If you as a team member don’t know where you stand with your boss, supervisor, or manager, then it’s up to you to fix that problem. Ask for a meeting with your boss to ask “how can I best help the team? What skills do you want me to focus on?” If your boss doesn’t give you the for that conversation, then at least send her an email spelling out your own understanding of where things are (heck, email is formal written documentation, so if anything you’ve generated some positive input for your next performance appraisal).

Step 2: Vent first, then confront

Because of Terry’s delivery I couldn’t hear her message. Instead, I internalized it by posting this little self-pity manifesto on my cubicle wall:

incompetent unreliable untrustworthy

  • For managers, no matter how frustrated you are, don’t confront your team members in the head of the moment. Let’s say you are boiling with frustration over a team member, someone who gets you so enraged that you know you can’t control yourself right now. If that’s the case, then right now is not the best time to confront him. Instead, go to a peer or to your own manager, ask for permission to vent, and then vent. If there isn’t anyone good to vent to, then go vent in the bathroom mirror. But whatever you do, don’t go to your people, with full engines revving and unload on them. 
  • For team members, this is NOT how you deal with an unreasonable boss. First, it tells her that yelling at me is okay. Second, I allowed the intensity of the message to drown out the critical feedback that could have made me better. Looking back across the years, I really wish I had done some venting myself. If I had confided in a co-worker to get some additional perspective, I could have gotten past the episode. But I didn’t do that. Instead, I let the emotions get the better of me, and I held a grudge. In fact, some 8 years later a very similar situation came up, and I did confront my manager about a tirade. This time, because I took the risk of first venting, then confronting we were able to get underneath some stuff, and build a much better working relationship.
Step 3: After You Confront Well, Follow Up
Eventually, Terry found out about my self-pity document, stepped into my cubicle and said,

“I’ve been meaning to talk to you about that”

At this moment, Terry was taking a risk. She’s in a rational state now and wants to follow up after the poor confrontation. And my epic response was

“Don’t worry about it. It’s an inside joke.”

Yes, I know. That was really wimpy. After my response, she smiled and left, and that was the end the conversation, and our working relationship. I soon started looking for a new job and turned in my notice a few weeks later.

  • For managers, even if you or your manager exert the emotional discipline not to blow up, even if you take the risk of a rational confrontation, there is still the need for ongoing follow up. Terry did just that, but gave up when I made it hard for her. As a manager, you can’t take no for an answer. Yes, I wish I had responded better, but I also wish she said: “Well Jesse, regardless, I’d like to have coffee with you this afternoon to work through our last conversation. Meet me at Starbucks at 3pm”. This is what is expected of leaders; this is why you are chosen for the role of a manager. Because Terry didn’t go that extra mile, she lost me the opportunity to steer me into a productive team contributor.
  • For team members, if your manager follows up with a peace offering, then it’s your obligation to accept it. Furthermore, if she never does follow up after yelling at you, then you need to initiate that. I held onto the grudge, and I lost the chance to grow through the experience.

So, when it comes to managers losing their cool. It’s a two-way street. Prevent it with open expectations. Control it by venting first. Resolve it with intentional and determined follow up.

QUESTION: Have you experienced similar conflicts? What worked or didn’t work for you?

I’m Opening an Offshore Agile Shop in India

Posted on
20

Okay gang, some big news here: I’m teaming up with the gang at Ripple Rock to start an Agile consultancy in Bangalore, India.

Fewell Family in India

The Dream
Many of you know that I married into a first-generation family from India. Well, shortly after we started having children, we started wondering out loud:

“What if we spent a couple years abroad, expose the kids to their grandparent’s heritage, maybe help them pick up the language? What if we then come back to the U.S. in time for the oldest to start high-school, and he’s already set up as a global citizen?”

After 10 years of marriage and 3 kids, we finally made it to India…and we fell in love. Since then, we started getting gradually more intentional about making it happen. We did some research and some praying, and came down to this: we need a stable pipeline of work in India before we can make the move.

The Deal
Earlier this year, I was networking with other Agile Project Management people at the 2010 Scrum Gathering in Orlando. While there, I met Colin Bird and Tom Reinsel from Ripple Rock. We discovered we both knew similar people, so I shared with them the dream. Colin looked at me with a stunned expression:

“Really? I have a client that needs boots on the ground in Bangalore ASAP. If you’re serious, then let’s talk.”

We started talking and came to the conviction that this made sense on so many levels: We had a client need, a corporate vision, and a collective family dream that all pointed to India. As a result, we decided that I would begin building a fully operational Ripple Rock office in Bangalore, offering two key services:

  • Offshore Software Process Improvement: If you’re a large Global 100 that moved your IT operations offshore, and it’s not going as smoothly as you want, send me an email.
  • Agile coaching, training, and certification for professionals across South Asia: If you are a South Asian professional in the technology field, and you’ve of Agile Engineering or Agile Project Management, but have not yet been able to get access to good resources, send me an email.

The official press release was posted minutes ago: “RippleRock recruits PMI Agile Community Founder to launch India Practice”

The Transition

Jesse Fewell moves to Ripple Rock

On one hand, this is obviously very exciting. On the other hand, it means a bittersweet departure from Excella Consulting, and the team of a very talented group Agile practitioners there. I’ve been at Excella for 4 years, and have grown immeasurably as a direct result of their corporate culture. If there’s one company in Washington DC that exhibits the virtues of Dan Pink’s “autonomy, mastery, purpose”, it’s Excella. I love the people there, and I’m going to miss them tremendously.

Also, I’m going to miss DC. Seema and I have built incredibly strong friendships here in Washington DC over the last 15 years. We plan to live abroad for only a few years, but going so long without those friendships will be tough.

Still, some things will remain the same. I will be as active in the PMI Agile Community as ever, if not more so. I will also continue to promote Agile Project Management at conferences across the world. But I’ll be doing it from a completely different locale, which means new faces and new challenges.

It’s an exiting time, and I’ll be posting updates here early and often. I’m eager for you to join me in this new adventure…

Question: How many of you are based in Bangalore or familiar with commuting to India? What advice or tips to do you have.

Agile Project Managers in Illinois this Tuesday Night

Posted on
Reply

illinois regional agile user group

This coming Tuesday night, April 27th, I’ll be presenting at the Illinois Regional Agile Users Group in Bloomington, Illinois. I will be continuing my series on “What is an Agile Project Manager Anyway?”, where we deep dive on the role of an Agile Project Manager on both traditional and agile projects.

I’m really excited about this crowd. From what I hear, IRAUG is the hottest new Agile networking group in the country. If you’re in the area this week, I’d love to have you come check it out and join the conversation.

  • Topic: “What is an Agile Project Manager Anyway?”
  • Date: This Tuesday night, April 27th @ 6:00PM
  • Venue: Holiday Inn Express, 1031 Wylie Drive, Bloomington IL 61701
  • Details: http://www.meetup.com/IRAUG-ORG