The Agile Project Manager—Fail NOW as a Strategy

I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.

failureWe started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or pause for meaningful effect…a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant basing it on whether the team achieved their Sprint Goal(s).

He was visibly upset with my view. He said that they (he was working at a well-known Atlanta company) had never failed a sprint. Never! They could not nor would not use that WORD in their culture. I asked him point-blank – have you ever failed a sprint? He said of course they had. Many times. But instead of using the term fail, they used the term ‘challenged’. That way, stakeholders wouldn’t get the wrong idea and question the skills or motives of the team.

We went round-and-round for another 10-15 minutes in our discussion, but we never really settled our differences. We simply agreed to disagree. Although it wasn’t a terribly wide chasm between us, I distinctly remember walking back to my room shaking my head. I simply didn’t understand the big deal about failure. About using the word. About a team saying…we failed. In my coaching practice and in my “day jobs”, I’ve been able to steer and evolve our views so that failure is not a bad word. I.e. failure is good. Failure is ok. Failure leads to improvement. Failure is a part of life.

So in this post, I want to discuss failure from a few perspectives. The discussion isn’t intended to be exhaustive. Instead, I just want to share some thoughts and to get you thinking about failure…how you view it in your organization, what is your tolerance for it, and re-considering your normal reactions to it. I also think this leads you towards your risk handling as well, because I think the two are inextricably linked.

Coaching to Avoid Failure

In his blog post from June 20, 2011, entitled Coaching is Not Letting Your Teams Fail, Giora Morein makes the case that agile coaches should be leading or guiding their teams away from failure. He brings up the analogy of a Sherpa guiding mountaineers. And yes, in the mountain climbing example I will have to agree that failure is probably not the result we want.

However, in the non-life threatening cases I think I disagree with Giora. I wholeheartedly believe that failure can actually be good for a team. I also think the role of the coach is to help a team look at their performance through two lenses. The easier of the two is the success-lens. This is the lens where you give the team positive feedback; where you tell them that they need to repeat those practices that work for them. Indeed, what practices they need to amplify and do “more of” so as to achieve greater and greater results.

These conversations are clearly easier.

But what about the failure lens? As a coach, do you provide constructive criticism? Do you show a team where they miss-stepped? Both individually and as a team? I think so. But certainly not in a malicious or heavy-handed manner. I think if you’re effectively coaching a team you must explore their errors & mistakes with equal passion and energy to how you handle their successes.

And I don’t think you do this quietly, hiding behind doors and not externally acknowledging their challenges. No. I think you approach it in a completely transparent and matter-of-fact manner. Laying the groundwork that failure is appreciated and welcome. That from it, your teams look for improvement possibilities and move forward quickly towards delivering improved results.

Agile Exposure

In agile teams, there are two key ceremonies that are focused towards success & failure results from a team. In Scrum, that is the Sprint Review (demo) and the Sprint Retrospective (lessons learned). Typically, the sprint review is exposed to the world, so you might want to be careful in how you couch your failures – so that stakeholders don’t misconstrue the impact or the effort the team is putting forth. Nonetheless, I believe you should declare sprints either a success or failure as part of the introduction to the teams review.

In Scrum, it’s the Product Owners role to determine this—and it’s relative to the goal(s) the team committed to at the outset of the sprint. Hopefully those goals were flexible enough to allow the team to adjust their work focus to creatively attain it.

For example, I think a very poor sprint goal is something around the team delivering a set number of user stories—or other indicators of by-rote execution. I think this leads to potential sand-bagging on the part of the team to hit a numeric goal rather than thinking of the true problem they’re trying to solve. Instead, I think better goals revolve around achieving some sort of demonstrated behavior that solves a specific set of customer problems. So success is measured against how well the team met the spirit of the goal and how well they applied the agile principles in their execution.

For example, I’ve seen teams that commit to 10 user stories, but who had an extra 3 days at the end of their sprint of idle time, fail their sprint. Sure, they delivered to their commitment, but their commitment was flawed. They sandbagged and over-estimated. They also didn’t make their additional capacity available to their Product Owner and ask for more work within their sprint time-box. Instead they planned ahead or gold-plated their deliverables.

I have also seen teams that commit to 10 stories, but deliver 7 have a very successful sprint. In it they work hard against complexity and adversity. They’re incredibly transparent and engage their Product Owner in making daily adjustments on priority vs. their new understanding of capacity. And as a team, while they didn’t deliver the originally perceived quantity, what they did deliver aligned with their goals and met the spirit of the Product Owners intent.

Both of these cases should be discussed in the teams’ retrospective and ways to improve discussed. Not small ways and not ignoring the first teams’ behavioral problems. No. All of it—the good, the bad (mistakes & failures), and significant improvement ideas will be discussed in order for the team to decide what points are worthy of their improvement focus in the very next sprint.

But is Failure Embraced?

Continuing with my earlier coaching example, I remember not that long ago I was talking to a group of our Scrum Masters at my “day job” iContact. If you don’t know about Scrum, the Scrum Master is the primary coach & guide and agile leadership voice within the agile scrum team. They’re also responsible for maintaining core agile values within the team and for the teams’ overall performance. What I mean by that is—guiding the teams improved performance over time. Continually asking questions like—is their team improving in their overall performance? Is their velocity improving? Is their work quality improving? Is their teamwork and collaboration improving? And, is their focus on delivered customer value improving?

So my point to the Scrum Masters was I felt we hadn’t failed in quite a while. I defined failure in this case as a sprint failure or a stop-the-line incident where a team basically ran into an impediment and needed to re-plan or re-align their sprint.

They all agreed with me that things had been going smoothly. And I received more than a few questioning stares as to why that was a problem. I tried to be careful in my reply, but my concern was that we might be playing it too safe. That we were becoming complacent in our agile practices and that we weren’t stretching ourselves enough. We weren’t taking chances. And we weren’t taking risks.

I explained that these traits are fundamental to the growth and advancement of agile teams. And the fact that we weren’t seeing failures indicated that we’ve plateaued in our growth and performance. I felt this was a problem…and I asked if they could drive more failures from the teams.

Can you imagine the remainder of this discussion?

Here I am the Director of R&D at a successful company talking to my team of Scrum Masters and asking them to drive more failure—to influence their teams towards more risk-taking and inspire more stretch goals. The point I’m trying to make is that I truly embrace failure. That I’ve learned to view it as a critical success criterion and that its absence is a problem for me. I wonder how many organizations and leaders have the same view.

The Notion of “Failing Forward”

One of my favorite authors is John C. Maxwell. He’s relatively well known as a leadership coach and he’s quite a prolific author—having written more than 50 books on various leadership topics. He’s got a strong Christian background to his life and writing, so if you’re not so inclined, don’t let that put you off. He’s mastered the art of leadership. A few years ago he published a book entitled Failing Forward—Turning Mistakes Into Stepping Stones to Success. In it he emphasizes failure as a truly transformative factor in our personal, professional, and team-based lives. But he carefully frames failure with a leaning forward posture. That is—instead of viewing failure as a negative end-state and feeling sorry for ourselves, we should embrace it as a positive learning experience. That you would be “leaning forward” in your failure—leveraging the lessons learned to improve.

I don’t think Maxwell is simply blowing positive smoke in our direction here. History is clearly littered with examples of successes that were inspired, forged, and hardened in the fire of failure—Thomas Edison being a famous example as he persevered to invent the light bulb.

In my agile coaching I consistently use the terminology “fail forward” when I discuss team-based failures. Yes, I want a team to be honest with themselves and acknowledge they failed. But I also want them to embrace their mistakes instead of getting defensive, blaming others or denying it entirely. And I want their posture to be leaning forward. Eager to try something new that will drive different results. Not afraid of failure.

I find that using this terminology helps teams to ‘get’ the nature of failure and to behave appropriately. But beyond terminology, project and functional leadership need to fully support the idea too—meaning the entire leadership team needs to be supportive of failure. There…I said it.

Wrapping Up—But, I’m a Bit Strange

All of that being said, I wonder if I’ve got a strange and largely minority view towards failure? I wonder if the right response is to indeed be fearful of it. To deny its existence. To spend countless hours trying to predict it. To never mention it in public. Are those and similar actions the right responses?  I really think your insights will be helpful here. I’m trying to get to a root understanding of acceptance and also the root cause for those views. While I’m particularly interested in agile teams, don’t let your lack of agile experience prevent you from responding.

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
PM-Agile

Five Tips for Drupal Newbies

The attendee list at this week’s Atlanta Drupal Meetup group ran a wide gauntlet. There was a mix of business owners, newbies, marketers, and even someone with a Drupal.org ID under 1000. We broke up our normal presentation format and had informal talks about Drupalcon Denver, the job market, and trends. As usual, we went around the room and allowed for introductions and announcements. When one of the attendees, we’ll call him “Jack”, was in the hot seat, he gave a typical hello, but then broke the introduction format and asked a question back to the crowd. He asked, “I’ve only been working with Drupal for a few weeks, what tips do you have for those that are just starting out?”

Drupal drop

You should have seen the room light up with excitement. I saw the same look on my wife’s face when she converted a friend into a Hunger Games fanatic–the look of “let me tell you how wonderful this is.”

Below is a summary of the tips the group provided to this new Drupal’er:

Read Planet Drupal – A great aggregator site for all things Drupal. They have a content upload policy, so you know all the material you will be reading is “the real deal.”

Dig through Drupal.org – Where all Drupalers go to gather information, review modules, themes, groups, etc. Also, when looking through modules on Drupal.org, one tip provided by Kent Lester, was look at the number of downloads. The larger number of downloads usually correlates with a better quality module.

Start with Drupal 7 – This answer came when Jack asked if he should start a new site with Drupal 6, or just begin with 7. The resounding answer was start with Drupal 7.

Read Pro Drupal Development – According to the group, immerse yourself in the book. It teaches you how to create modules, develop themes, and produce filters. It also covers the inner workings of each key part of Drupal, including user management, sessions, the node system, caching, and the various APIs available to you.

Watch DrupalCon/DrupalCamp Session videos – There are videos all over the web from previous DrupalCon’s and DrupalCamps. You can watch all of the 2012 DrupalCon Denver’s videos online. In addition, many of the past Atlanta DrupalCamp videos are hosted on the Mediacurrent site.

Lastly, here’s a personal tip I offer to all of you that are new. Get involved in the Drupal community. There are hundreds of Meetup groups, Co-working days, Camps, Cons, (I even heard someone through out a Drupal Paintball day) that you can participate in. Absorbing what others say and listening to experts in the community will grant you a great knowledge of this powerful open source platform. What other tips do you have for those that are new to Drupal? Leave a comment and help us compile a comprehensive list.

About the Author: 

Adam Waid is the Director of Marketing at Mediacurrrent, an industry-leader in helping organizations architect custom Drupal websites. Adam is also a MATRIX Alumnus, where he worked closely with the Sales and Recruiting organizations to develop differentiation strategies, create content, and drive CRM and social media initiatives with a single goal in mind - build stronger, more meaningful relationships with our clients. Leveraging new technology, the latest social media trends, and a good mix of traditional marketing, Adam grows online communities.  

Follow Adam on Twitter and Read his Social Media Blog.

Posted in: 
Development

IT Labor Shortage: What To Do About It Part 2

Are you willing to invest time in going above and beyond as you plan for your future staffing requirements? Hit or miss recruiting is a promise of failure. And once you have the right people in place, you have to consistently respect, recognize and reward them for their contributions. It’s the “oxygen” that employees need to maximize their potential. Here are some specific tips for attracting and retaining IT professionals who are difficult to find and worth keeping:

  • Before you develop a strategic recruitment plan to increase the number of highly qualified IT applicants, conduct a self-assessment to compare your recruitment approach to the universe of known recruitment strategies. Also determine what takes the least amount of effort, but still yields good results.
  • Evaluate your recruitment strategies and hire the right people for the right jobs, rather than trying to fit square pegs into round holes. Broaden your search beyond your immediate city or state. Search nationally and even globally for hard-to-fill positions.
  • Make sure your job ads differentiate your company from others. Constantly focus on what makes you unique.
  • Selectively screen resumes and applications. Many job applicants are using the “dart approach.” They’re sending out dozens or even hundreds of resumes even when they are not qualified for the position (s) as advertised. Screening these documents is an enormous waste of your time.
  • Do your homework by completing the necessary market research to determine the levels of compensation expected by highly sought-after job applicants.
  • Remember that nobody is a “perfect ten.” You may have to accept less than “fully qualified” job applicants and train them. Technical knowledge can be learned by most people if they already possess a certain level of skills and are motivated.
  • Develop a partnership with colleges, universities and technical schools in getting students to consider majors where jobs are immediately available upon graduation.
  • Offer college scholarships or partial scholarships in return for a 3-year commitment to your company upon graduation.
  • Create and support a networking club for IT professionals who have retired from your company, and for keeping them motivated to stick with you for the long haul.
  • Learn how to efficiently transfer knowledge from senior members of the team to new or entry-level employees.
  • Make use of HR’s abilities and resources in improving the skills and education of your current staff.
  • Consider job-sharing and part-time work opportunities for valued employees who cannot work a 40-hour week.
  • Embrace the “fun factor” and make sure that your work environment is enjoyable and a place where your employees like to work.
  • Do your employees take your referral plan seriously? What’s in it for them if they refer job applicants to you that you ultimately hire? If there is little or no incentive to make the effort to refer qualified difficult to find potential employees, why would employees do it?Don’t miss valuable opportunities as an employer and automatically look to the outside to hire, bypassing your current employees who, at the very least, would like to be considered for a promotion, special training or new challenge.
About the Author: 

Carol Hacker has been a passionate instructor, engaging speaker and independent business consultant for over 25 years. As president of Hacker & Associates, headquartered in Atlanta, GA, she works with organizations to help managers, supervisors, IT professionals, team leaders and business owners meet the leadership challenge. Over 500,000 participants have benefited from her customized seminars on the topics of recruiting, retention, evaluating employee performance, change management, handling troublesome workplace issues and much more.

Posted in: 
Hiring Manager

Changes in Platitude, Changes in Attitude

Social commentators often say that ‘Words matter’. Often, this phrase is used within a conversational framework denouncing unpleasant language that is somewhere between insensitive and abhorrent. In Cliché Land, this little two word axiom pops up in every movie or tv script dealing with legal or moral concerns triggered by inflammatory words. Well, I’m a little bit tired of the phrase ‘Words matter’ always having a negative connotation. I want to turn this topic around, and start to use the phrase ‘Words matter’ in a positive, educational, or even humorous way.

Duck billed platitude

For instance, when I was about 10 years old, my father told me that I should "never throw away bread to look for cake." I didn’t really understand what he was trying to tell me at the time, but it seemed important, so I took note it and held on to the words. It wasn’t until I was older, in the middle of an important career decision, when the words came back at me like a bolt out of the blue. Suddenly, these words mattered.

There are other, less critical, times that familiar words can leap to mind as well. As a self-confessed pop cultural trivia buff, I have a storehouse of random movie lines, song lyrics and other quotes on the tip of my frontal lobe, ready at a second’s notice, like:

 

“You keep using that word. I do not think it means what you think it means.”

“Meet the New Boss, the same as the Old Boss.”

“You don’t understand. These go to 11.”

“Hello My Baby, Hello My Honey, Hello My Ragtime Gal...”

“And… I'm also gonna need you to go ahead and come in on Sunday, too.”

These words are fun. They all come from various sources, and they are touchstones for my peers in the technology vertical. (While I don’t want to go into full blown Trivia mode here, hopefully you recognize at least two of them…)

Unfortunately, the following group of phrases is nearly as famous in technology circles, having been uttered time and again on projects, but for all the wrong reasons. See how many of these famous phrases you are familiar with…

“I’m 90% done with code.” – What this really means is that the developer has completed the initial pass of development, but hasn’t compiled, desk checked, or unit tested their work. The outstanding effort needs to be understood by the PM in some detail, and simply accepting this statement at face value can be dangerous. It is amazing how long that last 10% of work can drag on and on and on.

“Oh yeah, it can do that.” - This phrase is often uttered by Product Sales folks during the Vendor Selection process when describing the flexibility of their company’s software. However, what they are not telling you is the level of effort required to make the software ‘do that’. Does it support the functionality in question out of the box, does it require a configuration change, or is a customization needed? The devil (and the impact) is in the details.

“We’ve got to get something in the field. Let’s go with the 80/20 rule.” – This saying is usually applied to a situation where expedience is required over completeness. It assumes that an 80% solution will be good enough for the time being. However, before agreeing to this seemingly harmless approach, understand exactly what remains outstanding and quantify the potential business and project impacts. Don’t be afraid to ask the hard questions, as short-term thinking can betray long-term goals…

“We can make up the time in QA.” – This phrase loosely translates to development is lagging behind schedule, we need more time to complete the code, and we cannot move the Go-Live date. So, the cliché happens – the testing schedule is crashed, forcing the QA team to prioritize its test scripts and compensate for its reduced timeline by performing a subset of tests that provide ‘functional coverage’ for the solution. Similar to ‘let’s go with the 80/20 rule’ comments above, but more localized to the testing portion of the project.

So, I believe I have proven that ‘words matter’ can be used effectively in different contexts. I also like to think that I may have provided a warning to at least some of you about commonly uttered phrases within an IT project context. But, remember, if you hear someone say “Cinderella story, outta nowhere, a former greenskeeper about to become Masters’ champion” odds are, it’s not about a system implementation…

About the Author: 

Willard Woodrow, Senior Project Manager and BI Champion at Genuine Parts, has 15+ years of information technology experience in the utilities, retail, recruiting, telecom, and insurance verticals. His professional expertise includes business consulting, system implementation, project management, application operations, and client relationship management. Follow Willard on Twittter @willardwoodrow.

Posted in: 
PM-Agile

The Agile Project Manager—The Cost of Transparency

As I learn and grow my agile experience, I continue to find value and power in the notion of transparency. It’s one of the softer of the agile tenets and one that gets mentioned, but rarely emphasized as a critical success factor.

So what is transparency? Let me give you an example. In many agile instances teams and structure don’t simply come into being. Usually functional managers or other leaders put some serious thought into the composition of teams:

  • What should be the team size?
  • What is the most effective ratio of skills, for example developers to testers?
  • How much experience does the team need? Specific leaders?
  • How many developers of what sort (Front-end, Back-end, Middle-tier) should be on each team?
  • Does the team have the requisite skills to get their work (as defined in the Product Backlog) done?

software development transparency

Usually team composition involves trade-offs. For example, some team members simply don’t want to work on or in some areas. Individual strengths come into play—as do their professional and personal preferences. Some of the trade-offs might even be considered private or confidential.

When you expose this team composition to the organization, explaining your rationale and trade-offs, you’re practicing transparency. Why do it? First, it serves to expose things to the much broader team. It forces you to articulate your rationale and field questions or challenges. You’ll also field suggestions and alternatives—which will encourage you to consider them in your thinking.

So two advantages is that decisions are made out in the open—subject to wider-team scrutiny. It also provides you feedback on alternatives, which usually creates or fosters stronger decisions—in this case on eventual team composition.

But…there’s a danger

Your level of transparency is dependent on the level of maturity of the receiving organization. In a perfect world, you want to be fully, 100% transparent. But what if you live in an organization that to use Jack Nicholson’s words – “Can’t Handle the Truth!”?

Or what if your colleagues in other functional groups don’t reciprocate the same level of transparency that you do? Now you’ve exposed the inner workings of your organization and decision-making processes or the real reasons behind things, but others still remain opaque. Worse—they take advantage of your transparency in challenging your decisions or poking holes in your logic or using the information against you in open debate.

But in the same breadth, they haven’t shared to the same level themselves and don’t have the thickness of skin to defend their own decisions. Thus creating a transparency imbalance that is unhealthy and unfair. You might argue that this is ok. That transparency as a rule is the right thing to do. I don’t think so. I think organizational transparency needs to be balanced, congruent, reciprocal, and is based on maturity and open trust.

Let’s explore a couple of examples to drive the point home…

Lack of Honoring or Trusting Role Boundaries

An important part of transparency is individuals understanding the fundamentals of their roles and responsibilities. Let me use a Scrum example to make my point.

The Product Owner is the role in Scrum that is responsible for defining a backlog that meets the demands of the customer. A backlog that is ordered in priority—trying to deliver the highest value features first to the customer. So that they get valuable features front-loaded; delivered early and often.

Now the Scrum team itself contributes to the discussion on prioritization, work items, and value. They collaborate heavily with the Product Owner and driving healthy debate about the organization of the backlog. In many cases, their opinions and feedback factors in quite heavily into the backlog.

But at the end of the day, the ultimate responsibility resides with the Product Owner on backlog organization and the team needs to align with them after passionate discussion and debate—fully supporting their decisions. Trusting them to do their job and honoring their role and its inherent responsibilities.

But what if the team continues to second guess the Product Owner—both within the teams’ context and in public? What if when the Product Owner shares their rationale for decision-making, the team uses these transparent insights against the PO to undermine their credibility? Or they constantly challenge the decisions over and over again—based on the detailed insights they gained by the Product Owners’ transparency?

This sort of behavior will eventually undermine the Product Owners trust in their team. Sure they’ll collaborate with them and share information. But they’ll begin to filter information from them when they view it as volatile or controversial. They will start to add opaqueness to their decision-making rationale. And you know what? I can’t blame them.

I think transparency needs to be earned in both directions. Both the sender and receiver need to be able to trust each other…otherwise filtering will occur. And within agile contexts this can be a very serious impediment.

Lesson #1 – Transparency has equity as its underlying element; that and a fundamental support of team-based trust.

Another Example - Maturity

Let me try another example. I once was the project manager in a traditional team. We were in the endgame of a project, trying to winnow down software changes and bug fixes as we hopefully approached a much needed customer release point.

It came to my attention that a particular component of our application was not stabilizing from a quality perspective. When we asked the development team if they needed any help or what was specifically wrong, they would deflect. They would get defensive and tell us that they had the software under control and that this was only a temporary glitch.

Initially, we simply trusted them. However, several iterations went by and the software didn’t improve. In fact, some of the newer bugs that were surfacing were not only regressions, but they were more severe than their previous instantiation. Clearly things were getting worse.

I asked members of our testing team if they had any additional insights as to what might be going on. I probably should have asked them much earlier. Sure, they replied. We know what’s wrong. It’s Bill and Eddie’s changes that are de-stabilizing the component. And they have been for two months. Bill was one of our more seasoned engineers and Eddie was a college intern who was working with him.

It turned out that Bill was working overtime. Way too much overtime—around 70 hours a week and he was seriously overloaded on the project. This was one of three components assigned to him and Eddie and he were losing ground on being able to support them all.

Unfortunately, instead of asking for help, Bill was defensive about his capacity and the quality of his work. And his boss fell into the trap of supporting him—all at the cost of delays in the project. Once we got through the opaque defensiveness and immaturity, we adjusted the load across the team and brought in some help for Bill and Eddie. Almost immediately quality began to improve in that component and we were in a release position in two weeks.

If we had a regret it was that we hadn’t forced transparency sooner so that we would have understood root cause better and been able to make a much quicker adjustment! You see it wasn’t about Bill or Eddie. It was about the team getting a project out to their customers.

Lesson #2 – Transparency needs a level of maturity and trust; the realization that early exposure is always best.

Wrapping Up

Transparency turns out to be a bedrock of the agile tenets. It serves as the foundation to many of the activities of a good agile team—daily stand-ups, information radiators, sprint & release planning, sprint demos, and retrospectives. Virtually all of your teams’ agile ceremonies need to be transparent. However, in many contexts, transparency must be earned.

There needs to be congruent and fair play across all aspects of your organization—leading to consistent levels of transparency. A baseline for this is trust. Everyone needs to be on a level field as far as trusting each other’s roles and responsibilities and honoring each other’s skill, ability, and efforts.

If there is inequity, I advise that your transparency level be normalized at the minimal level that everyone is operating at. Otherwise, it will foster incongruent and odd cross-team behaviors that will often continue to reduce your transparency. Inconsistent transparency will also heavily impact your decision-making as you’ll be getting different levels of information from different groups.

There needs to be fair play when it comes to information. No “I told you so’s”. Instead, you need to foster a fair, equal, and level ground for information sharing. One that will allows the core nature of your agile teams’ to flourish as they face their challenges and adjust towards improvement and success.

Agile Project Managers—are you up to the challenge? I can’t see your answer…

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
PM-Agile