Skip to main content

Author: Robert Galen

The Agile Project Manager—Voila: The Great Reveal

FEATUREJuly5thI remember the day as if it was yesterday. It was my first sprint review at a company I’d just joined as an agile coach. They’d been ‘doing’ Scrum for several years and I had gotten the general sense that they were well disciplined and mature agilists.

So when they scheduled a series of sprint reviews to expose the x-team efforts of their latest sprint cycle, I was understandably excited. I got into the room early to get a good seat and was eager with anticipation.

Gradually, the room filled and it became quite noisy, which only drove my anticipation higher. Then the first team took “the stage” and began their review. They popped up some PowerPoint slides and away they went…
Their deck was polished. They had lists of things they’d done, and downloaded pictures and jokes to lighten the mood at appropriate points. They marched through the work that they’d done…one slide at a time and at appropriate points the audience politely applauded their approval.

But it struck me midway through the first review that something was missing—something really, really important. There was no working software. How could this be, I thought. The whole point of the sprint review was to expose working code to stakeholders for review and feedback. Then I thought that this was probably an exception or special case, specific to just this team. Surely there’s working software coming up next.

But one by one, each subsequent team followed the same pattern—showing humorous slides and textual representations of effort, but no working code to be seen. Slowly and then more quickly my enthusiasm waned and I became quite frustrated. Not so much with the team, but with whoever had explained the purpose of a sprint review to everyone. Clearly, they didn’t “get it.” And neither did the stakeholders, as they continued to chuckle politely at the jokes and applaud each team’s efforts. It seemed as if the ceremony was simply there to check a box in the Scrum process list.

Never Again!

Needless to say, the teams never took quite this same approach again in their sprint reviews. While I truly honor the notion of self-directed teams, I immediately laid out some guidelines and goals for our future sprint reviews.

Some of them aligned quite naturally with the Agile Manifesto; for example, the notion of demonstrating working code at the end of each iteration or sprint. But some of the guidelines were unique to our organizational and cultural dynamics.

That’s actually the focus of this post…I want to share some of the guidelines, strategies, and the mindset we leveraged to turn-around our sprint reviews. Over time we move from:

  • Polite applause…to…enthusiastic cheers and aha moments
  • Polite applause…to…gaining congruent and constructive feedback
  • Selling and marketing our results…to…making them transparently honest
  • Small crowds…to…standing-room only and videotaping
  • PowerPoints…to…working software whenever possible
  • Entertainment…to…showing business value and exposing team effort
  • Going through the motions…to…intentional and congruent feedback
  • Selling and marketing our results…to…having them speak for themselves!

Surely it didn’t happen overnight and we continued to adjust and fine-tune our sprint reviews over time. However, we achieved a state in our reviews where they became the cornerstone for our agile adoption across the organization.

Let me share some of the things we focused on…

Guidance toward “Excellent” Sprint Reviews

In general, I like to consider the sprint review as a “big deal.” Why? Because it is.

An agile team has spent a focused period of time working on the most important stories on the planet, and is ready to deliver working software surrounding those features or stories. This stuff is hot off the presses and people should inherently care. They should be excited to see the results. Heck, you should have to beat them away at the doors.

It’s the team’s responsibility to REVEAL their efforts effectively. And I’m not simply talking about the software. No, they should be telling and showing a story surrounding their work. It should contain context and narrative. There should be a connection to the last sprint and toward future sprints.

So below I want to share some critical focus points and a sample review agenda for your consideration. I hope the specific ideas help you to improve your reviews, more effectively engage your stakeholders, and create a more energetic reveal for your teams.

7 Key Focus Points for your Sprint Reviews

  1. Ownership

    We established that the Product Owner ‘owns’ the overall pattern for the Sprint Review. Sure, it’s a “whole team” thing. But at the end of the day, external communication, showing planned-delivered value, and gathering and adjusting to feedback are primary aspects of the PO role.  They’re also responsible for getting people in the review—so if attendance is spotty, they’ve got work to do to figure out why and to change your patterns to get the “right people” in the room.

    Very often I think of their role as one of Master of Ceremony—where they are conducting all aspects of the review. They are certainly not doing everything themselves, but guiding the overall quality, focus, and results of the review.

  2. Format

    We put a lot of thought into the scheduling and timing for the review (or reviews if you’re part of a multi-team initiative). You’ll want to get into a regular tempo (day and time) for your reviews. Within the context of the review, you’ll want each team to follow a consistent flow (see potential review agenda below).

    In our case, we had multiple teams demoing on the same day—as our sprints were synchronized. So our format was really a cross-team agenda that sliced a three-hour time slot into appropriate stages for each team. Not only did we plan each review, but our Chief Product Owner took a stab at conducting overall flow across the teams.

  3. Sprint Goals

    I personally like the view where the review is “hinged” on the sprint goal(s) that the team(s) signed up for. Quite often I tell teams when they’re crafting their goals to think about the e-mail invitation they’ll be sending out for the reviews. The ‘story’ of the sprint is then tied to the goal and how the team reacted to meeting the goal.

    And you should be honest about how the team delivered to their sprint commitments, so “Call It” as a success or failure. But never, ever let the term ‘failure’ be used to browbeat the team. Failure is a part of teams’ learning and the organization needs to adopt a “Fail Forward” attitude.

  4. Whole Team View

    As I said, I like the view where the Product Owner is the Master of Ceremonies, the Scrum Master is the facilitator (if needed) and the entire team gets a chance to “show off” their results in each review. This whole-team approach serves to give your team transparency and the chance to shine—so round-robin your demo individuals and give everyone (person, role, etc.) a chance to show off their work and results.

    And no, don’t ‘force’ introverts to speak uncomfortably in a large forum. Make it encouraged and optional. Very often these folks can serve as the ‘driver’ for the demo—so quietly participate. But do engage the whole team!

  5. Preparation

    If there’s a key to a solid sprint review, it’s preparation—somewhere safely between “way too much” and “totally winging it.” You should put some thought into what work is relevant for the review, in what flow should it be demonstrated, and how it connects to previous and upcoming sprint work.

    Quite often someone with a QA background will develop a review ‘script’ that helps the team expose their efforts in a cohesive way. Ultimately, the Product Owner should have the strongest voice into what gets exposed and why—setting the stage for the ‘reveal’ with the stakeholders.

    If in doubt, reserve sufficient time in sprint planning for review preparation and DO prepare.

  6. Execution & Demonstration

    The review demo needs to be smooth, thoughtful, polished, and ultimately the software needs to work flawlessly. Dry-running the demo and having everything pre-setup is a must. You should also do timings to ensure your demos fit into your allotted time. And don’t forget about Q&A time.

    Beyond the demo, you need to tell a story that encompasses your feature workflows. I’ve seen teams in their first sprint show an architectural diagram that reflected the work they planned for the upcoming six sprints. Then in each sprint review, they “filled in the boxes” as they began to flesh out the application architecture. I thought this approach was an outstanding way to “connect the dots” for the audience.

    From my perspective, ALL WORK that a team took on in a sprint is a candidate for exposure. That might include features, enhancements, bug fixes, refactoring, documentation, testing infrastructure, virtually everything. Sure, some things might require some finesse to demonstrate or illustrate, but if it’s work the team did—it’s a candidate for the review.

    And finally, be ready to explain things sufficiently so your audience UNDERSTANDS what you’ve just shown, its significance, and the level of effort behind it.

  7. Wrap-up

    Finally, we always wrapped up reviews with a general request for feedback—both on the software itself, but also on our review dynamics. Were the transitions well made? Did we explain what we did? Do you know how to send us your feedback? And what can we change to make the next review even better?  We usually only spend a few minutes here, but it’s time well spent. If you’re familiar with the notion of a Fist-of-Five, we usually leveraged that technique for closing feedback.

Sample meeting agenda

Consider the following as a healthy template for your team’s sprint review agenda:

  1. Introduction
  2. Team Chart
    • who’s-who: names, roles, and location of team members
    • external folks who helped with the sprint
  3. Acknowledgements – Appreciations
    • certainly shout-outs for team members
    • but also a good time to recognize “external folks” who were instrumental in the sprint
  4. Sprint Goal
    • articulate the Sprint Goal, speak to any adjustments that were made during the sprint
    • call it: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?
  5. Strategy? Success? Efforts? Discoveries? Results?
    • share any relevant strategies the team used to deliver the work
    • explore the effort behind the sprint
    • were there any discoveries that were unexpected; any critical results?
    • all of this is to give the audience a “behind-the-scenes” look at the team’s sprint
  6. Demos, Q&A
    • demo the selected set of user stories / features—allow for Q&A
  7. Coming Attractions
    • speak to progress to release goal(s) and upcoming work in future sprints
  8. Fist-of-Five Toward Improvement
    • engage the audience in review-performance feedback
  9. Close

Wrapping up

I simply can’t tell you how good it feels to have a high-impact sprint review. And while I put a lot of pressure on the Product Owner and team for the results of the review, as an Agile Project Manager you play a central role as well.

Teams often get “caught up” in the work of the sprint and short-shrift the review preparation. In fact, this is a common anti-pattern. You can turn this around in sprint planning—asking the team to plan for and allocate sufficient time toward the review, while also reminding them as the end of the sprint approaches to consolidate their work.

Remember, the review is also a “QA checkpoint” for the team. There’s nothing like pulling things together and demoing them—to bring a healthy dose of reality to a team’s sprint efforts. You always shake things out—environments that don’t work, integrations that weren’t made, and interactions that were forgotten.

So Agile Project Managers, I hope this post has inspired you to take charge of your reviews and make them the most powerful event within your agile teams. While it is certainly the team’s responsibility to prepare and deliver, you can influence the attitude and approaches. You can also amplify the positive feedback you’ll get as you improve.

Thanks for listening,

Bob.

BTW: a presentation of this material was shared at the 2012 Atlanta Scrum Gathering. You might find it interesting as it complements this article.

Don’t forget to leave your comments below.

The Agile Project Manager—There Can Be Only One!

drew1I hope I’m not the only reader who remembers the Highlander movie & television series. Duncan McLeod was an immortal amongst others who was fighting to be the last remaining immortal. In each episode, there was inevitably a decapitation or two as the immortal population was reduced to the final one.

I use the symbolism of the Highlander to remind me of several aspects of agile project management. The first relates to focused teams and our earnest effort to reduce all levels of multi-tasking.

The second reminder is what I want to explore here—the notion of investing in a single team to create a working model for your agile adoption efforts.

This isn’t just any team. It’s your example team; a high performance agile machine that illustrates sound principles and delivers on the promises of agility. It’s a role model to other teams and proof that you can be agile in your specific organization & culture.

I have a bit of “mad scientist” in me and this is the team you experiment with in trying out new and novel approaches for your domain. It’s the first team that moves from Scrum to Kanban. Or it’s the first team that tries out Cucumber as a Behavior Driven Development mechanism, while including the whole team in crafting acceptance test driven automation.

Let’s explore some of the characteristics of this singular example agile team—

Let’s first explore what the team isn’t…

The team isn’t composed of special developers, the “best of the best”, or full of themselves ego’s. Yes, you might have some more seasoned folks on the team, but in ratios that are representative of your other teams and overall population.

The team isn’t paid a premium wage or compensated in some special way. In many ways they represent a cross-section of your teams in experience levels and compensation structures.

The team isn’t isolated from challenges such as interruptions, multi-tasking or dealing with unkempt legacy code. They have an equal dose of the challenges facing every other team.

And finally, the team isn’t placed on a pedestal for everyone to see. Yes, it’s your example team and the one that illustrates the best properties and practices of your agile adoption and progress. But, they’re also just another team and virtually equal to everyone else.

drew2

What the team is…

If you buy-into creating a model team, it’s sort of hard to figure out what that might “look like” in the wild. While I don’t want to give you a prescriptive list like, do these five things and a magical event will occur creating a perfect model team, there are some hints I want to provide for some behaviors and practices that you might want to model for.

Locale

The team is co-located and cross-functional. If at all possible, they sit together at one large table and work around and across from each other. Their room has white boards and plenty of wall space for information radiators that are meaningful to the team

The team has some privacy—being located in a conference room or other walled in area. They’re insulated from random noise and interruptions that might result from too open a space. I’ve often used the term “Team Room” to describe the room dynamics.

The quarters are relatively tight—in that everyone in the room is working closely together. Everyone can hear every conversation that is going on in the room. If someone is working remotely or on the phone, the room can hear the interactions.

I often get the question of whether you can leverage distributed or remote team members as part of your model team. I think the answer is normally yes. But what you want to do is allow budget for travel, training, and tooling that supports bringing your distributed team together as much as possible—both physically and virtually.

For example, when you’re initially forming your team, it’s a really good idea to bring everyone together for some initial introductions, training, and team-building. How else would you form a high-performing team?

Smells

An often used term is ‘smells’ with respect to agile teams. These are patterns or trends that one observes when collaborating with the team. Here are a few examples—

There’s a buzz in the room, it’s rarely the case where everyone is quietly working. Instead, team members may have headsets or earphones that allow for a sense of quiet if they need to “get away” for some private work.

Work is done primarily in pairs. Not restrictive rules such as—you MUST pair at all times. Instead, it’s a more natural and organic level of pairing—as it makes sense, in small groups, based on the dynamics of the work. And everyone on the team pairs in one way or another!

There’s quite a lot of dynamic discussion going on in clusters. A lot of white board conversations. And every conversation ends up moving over “working code” as the final arbiter of discussion and progress. So—hovering around screens and talking about software design, behavior, adjustments, failing vs. passing tests, bugs, etc.

A final smell might be chaos. I like to describe agile methods as being an “uncomfortable” methodology. They are quite strict focused towards specific practices and there’s an overwhelming sense of “controlled chaos”, especially if you’re part of a well-performing agile team. Point being—it’s not totally scripted. Discoveries happen. Plans change. Adjustments need to be made. And everyone quickly adjusts and moves on. The goal that the team has committed to for the iteration or sprint is the thing that keeps the train on the tracks, with everyone focused towards meeting that goal.
drew3

 

Throughput & Swarming

I get asked this question all of the time—can the developers move ahead of the testers on the team during a sprint? This question implies a distinct separation between development vs. testing work and aligns work done-ness along skill & functional boundaries.

My answer is always the same—no!

The team shouldn’t get “partial credit” for development-done work. In fact, they should only get credit for done-done-done features & stories that are complete, meet acceptance criteria, and are completely demonstrable. Given that definition, then teams would be better served to swarm around their work, limiting their stories in-progress (Work in Progress or WIP) and getting their work done as soon as possible.

In fact, this isn’t an ‘option’, but the way in which well-performing and mature agile team should naturally behave. They understand that throughput (the time it takes to move a story from start-to-finish) matters. And that team collaboration around getting small sets of stories done as soon as possible (swarming) is the best way to do this.

In my experience, it’s a whole lot easier to talk about this than it is to deeply instill these behaviors in agile teams. This is why you’d want to “get it right” in your example team—to discover the best ways to influence this wonderful behavior.

Quality

It’s hard for me to explain the myriad of ways that quality activity needs to change in order for a team to truly become high-performing. The first characteristic might be everyone on the team understanding that you don’t test-in quality…you build it in.

Just the other day a colleague asked me what I thought were the highest value quality practices that influenced agile high performance. Perhaps sharing my reply would help. Here is the list of high-impact practices that I sent him and that I think are reflective in an outstanding agile team—

  1. Fostering a whole-team view towards Quality—moving testers to the front of the line in that they collaborate on the requirements and getting the solutions ‘right’.
  2. Pairing in general: pair-programming, pair-testing, triad-pairing (developer + tester + product owner), paired code reviews, etc.
  3. Having the ability, willingness, and aggressiveness to stop-the-line and apply corrective action(s) immediately.
  4. Test planning on an iteration & release basis while initiating whole team collaboration around strategies for what & how to test.
  5. Applying exploratory testing in a paired fashion, leveraging session-based (charter driven) exploratory testing across teams.
  6. Performing active agile release planning so that teams gain a broad view towards dependencies & integration—including a DevOps mindset or continuous deployment (CD) view.
  7. Naturally applying Unit Testing / TDD (Test-Driven Development) techniques within teams.
  8. Naturally applying ATDD / BDD (Acceptance Test Driven Development / Behavior Driven Development) – driving Triad collaboration & conversations around. The focus here should be collaboration first and automation second.
  9. Properly preparing for and conducting powerful sprint reviews or demos that engage stakeholders and customers to provide active feedback.
  10. The Mike Cohn / Agile Test Pyramid strategy works…so leverage it; includes the notion of multiple tools and layered approaches

The list is in priority through the first three quality differentiators. Beyond those, they’re not in any particular order. You might not need to apply all of these approaches to achieve high-performance, but the list does imply some of the breadth and depth to a set of effective quality practices. And I hope that I didn’t imply that “testing” was equivalent to “quality”.

Micro-Adjustments & the Stand-up

One of the most misunderstood aspects of agile team is the nature of the teams’ commitment to a body of work in their sprint and then gathering daily to discuss their progress in the daily scrum. You quite often see teams look at their sprint plan as being a fixed set of user stories and their associated tasks. They commit to these ‘cards’ and work diligently to execute to their plan.

Many teams allow their traditional planning instincts rule too much within their sprints. You see the tasks and stories should only be a means to an end. The Sprint Goal is what the team commits to and in the daily stand-up they should be discussing progress-to-goal. And anything that comes up that—

  1. Impedes or blocks achieving the goal
  2. Provides new information that adds, changes or removes work to support the goal
  3. Leads to discovery that influences interpretation of the goal—refactoring, under/over estimation, interruptions, skill gaps, etc.

should be the real focus of the team. And in the daily stand-up, the discussions should surround what I’ll call the micro-adjustments that an agile team makes each and every day.

These adjustments are goal-based discussions between the team and the Product Owner surrounding goal achievement. Often, they require thinking around changing or jettisoning agreed upon scope within either the sprint or ultimately the release.

These are healthy discussions that get to the root of the agile methods “just enough” and “simplest possible solution” lean principles. Moving from a follow-the-plan focus towards a collaborative, micro-adjustment focus is one of the hallmarks of a high-performance team—an agile team that focuses on solving customer problems via their goals.

Wrapping Up

One of my personal improvement reflections in many coaching gigs is not establishing a ‘model’ or ‘example’ team quickly enough. It’s usually driven by my need for an example that illustrates good agile practices from the same context that we’re initiating agile adoption—one that I can “point teams towards” so that they can view an approach or technique beyond my just talking about it.

Brian Marick is a well-respected agile testing consultant & coach. Brian often speaks about the power of an “Example” and will often ask for one—an example for a User Story, an example of an Acceptance Test, an example reflecting the customers problem, an example of a design you’re discussing, etc. He even has gone so far as to name his website www.exampler.com. Brian is a firm believer in examples being a wonderful communications device to focus dialogue towards solutions. I agree.

So is the point of this post to create an example team and then be done with it? NO!

It’s to create a model team as part of your agile transformation and then leverage the knowledge gained from them to improve your overall adoption approaches, techniques, and tools so that your consistently raising-the-bar and improving. A team that you can adapt with and learn from, one that is strongly embedded in your organizational culture and problem domain, and a team that can help guide your evolution…simply by example.

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

The Agile Project Manager “The Secret Sauce: Team Appreciation”

Feature May3 25616213 XSI was attending a session at the Agile 2011 conference where Jean Tabaka from Rally Software was talking about some generic agile coaching tools & techniques. Jean happened to mention a few times that Rally had been internally focused on some organizational change models that happened to focus on strengths, positive recognition, and appreciations.

Focusing in on appreciations, she stated that it started in team retrospectives. That Scrum Masters would ask the teams to share their appreciations of each other as a startup or entry ceremony for each retrospective. But then it caught onto other organizational meetings. She mentioned that many of their company wide, all hands meetings began with appreciations.

And that it began to change the tenor of the culture, influencing the collaboration, teamwork, and overall energy & results of the company. I came away thinking that I’d been a bit lax in reinforcing “appreciations” in my coaching and she inspired me to renew my focus.

Before I talk directly about appreciation dynamics, there are three trending & related areas that I want to mention. I think they help support this post and will help you explore this area.
Bob Sauce1

Positive Psychology & Flourishing

First up is positive psychology. Martin Seligman is considered the father of Positive Psychology and the focus on flourishing and wellbeing. Two areas of flourishing are of interest in agile teams, or at least they’re the components I’ve chosen to share in this post.

First is a focus on positive emotion. This can be “tuned” by everyone writing down three positive things that occurred during each day. You can do this via journaling or some other method of capturing team events. It’s best to do this at the end of the day, to focus your mind towards positive outcomes and successes.

The second area is engagement. This can be “tuned” by preferentially using ones highest strengths to perform tasks which one would perform anyway. Here you’re leveraging your strengths in your role. The agile methods endeavor to maximize positive emotion and engagement as part of the essence of a self-directed team.

Seligman and others have also emerged the term flourishing to represent the embodiment of positive psychology in one’s life.

Bob muscles2

Strengths-Based ‘Movement’

This leads quite nicely into the strengths based and coaching movements. A popular analysis tool is StrengthsFinder from the Gallop folks. It’s now at a 2.0 level and it assesses and finds your strengths as they align with 34 core areas.

Part of the tool, once you’ve identified your strengths, is to guide you towards leveraging your strengths in your day-to-day work and personal lives. It’s my view that you can change (improve) weakness, but do it painfully and slowly. The impact won’t be felt for quite some time. But if you reinforce or amplify and leverage your strengths, you’ll accelerate your growth and impact within your organization.

You’ll also be happier and more engaged.

Appreciative Inquiry

Appreciative Inquiry or AI is an organizational development technique that I’ve been aware of for quite some time. And it aligns incredibly well in agile team coach as do all of these techniques.  The central force in AI is running an AI Summit where you focus on what’s “right” about an organization vs. what’s wrong and trying to fix it.
By reframing your group questions towards strengths, you try to:

  • Discover: the things that are currently working beautifully in your organization
  • Dream: or envision what processes or approaches might work well in the future
  • Design: plan or prioritize those process or approaches that would work best
  • Destiny (or Deliver): the proposed design the group has envisioned

Nowhere in this did I use terms like “root cause analysis” or fixing a problem. This is all about amplifying your strengths towards even more innovation and results.

Applying AI to Agile Retrospectives

It’s a very common practice in agile teams to do a retrospective that follows a prescribed format of answering the following questions:

  1. What did we do well?
  2. What did we do poorly or badly?
  3. What would we like to try?

If we were to take an AI approach to retrospectives, we’d drop question #2 entirely. We’d amplify #1 to include individuals, the team, and even the organization. Leading the discussions towards strength amplification – or how do we do even better.

The third question is interesting. Very often I find teams coupling #3 to #2, for example: “we really struggled with estimation in this sprint, so why don’t we try this technique”. While on the surface it sounds like we’re considering positives or strengths, we’re really not.

I’d either like to drop the question entirely or reframe it to something like this:

What creative and innovative new ideas or approaches can we try that will amplify our strengths and increase our overall results?

I know, I know, I can get a little wordy. But in this case, I think the question reframing focuses the team towards appreciation, strengths, positive improvement, and innovation. A fairly powerful cocktail if you ask me.

But let’s get back to the original point…

Bob thx3

Now back to Appreciation

Now that I’ve established a bit of a research and study baseline for you to explore, I want to get back to the original thesis of this post. The point Rally Software was emphasizing is a whole team view towards appreciating each other. Here are some of the characteristics of their appreciation:

  • It was given from one individual to another, directly
  • The sender and the receiver made eye contact
  • It was specific, so a specific act or incident that you are thanking the other person for was acknowledged
  • It’s done openly or in public
  • The receiver acknowledges the appreciation directly, with a “you’re welcome”
  • And you do this until you run out of appreciations amongst the group

Quite often, this is a kick-off or initial ceremony, meaning it’s done at the beginning of a retrospective or a meeting. It has the wonderful effect of warming everyone up.

Snowballing

Another observation is that it snowballs over time. In the beginning teams are often shy or reluctant to recognize each other. They’re often afraid to call someone’s positive behavior out. Not sure why that’s true, but it often is.

But as this practice is instantiated into each teams or your organizational fabric, it gets easier and easier to recognize each other, to simply say “Thank You” for your efforts in a public and meaningful way.

It also seems to change the culture. People start thinking about each other as team mates and not simply co-workers. They begin to be more observant and thankful for each other’s efforts. The daily stand ups become a bit more positive, results-oriented, and energetic.

I’ve even seen the case that, now that the shyness is wearing off, that the team’s ability to ask for help increases too. So no longer do team members “hold onto” work too long before raising their hands for help. They realize that they’re “appreciated” even when they’re struggling. That their team “has their back”.

Wrapping Up

I think solid Agile Project Managers sort of get a visceral feel for when and where to appreciate their teams. They make it situational and appropriate. They also make it immediate or time sensitive, because nothing makes a worse impression than thanking someone for something a year after it happened.

Beyond the personal appreciations though, I think they setup an “appreciative environment” where their teams are kind, gentle and thankful to each other, where they leverage strengths whenever possible while influencing the teams work.  An environment that is infectious in its positive energy and can do spirit.

I’d encourage everyone reading this to invest time in your personal and team-based “appreciations”. I’m positive you’ll see a difference!

I appreciate your listening,

Don’t forget to leave your comments below.

The Agile Project Manager—There is no ‘I’ in Team

Feature_Apr_11_36585587_XSA couple of weeks ago I was teaching a group new to agile some of the basics surrounding Scrum and related agile practices. It was going well. And, as is sometimes the case, I was getting full of myself and feeling over confident. Things were going smoothly, the attendees were “getting agile”, and life was very good.

Then it happened—from left field and without warning.

We were talking about the nature of a self-directed agile team. I was trying to paint the picture of group-based accountability and responsibility. How empowering it was and how it led to the best results. How teamwork, well basically ‘Rocked’, and how agile teams truly collaborated around the customer to deliver creative and high-quality solutions. I asked if there were any questions and someone from the front of the group raised their hand. He said something along these lines:

We can’t work as a team. Our company incents us individually. We’re measured as individuals and I get my bonus paid to me because of my individual accomplishments. All of us do. How in the world are we going to work as a team, if we’re being paid to only care about ourselves?

I was sort of frozen in my tracks. At least from my perspective this was a really hard question to answer. It went to one of the more challenging adjustments facing agile organizations. How do they shift, or even do they shift, from an individual-focused system to a team-focused system.

I’m going to share with you exactly how I answered the question. I’m not sure I’m satisfied with my answer, but it was the best I had at the time. Once I get through my answer, I’m going to ask all of you for help in crafting alternative responses and to weigh-in on this important topic.

Apr11_Bob2

Without Further Ado—The Answer Is…

So, when I’m under pressure as a coach, I often pull a sports analogy or example out of my pocket. It’s a pretty lame response on my part and not everyone likes sports, but it’s often the best I can do. And certainly team sports aren’t the worst analogy one could come up with.

It turns out that the Los Angeles Lakers were having some organizational problems a few days before my class. I’d been watching ESPN and became aware of it. Lakers management had put Pau Gasol on the trading block and there were trade rumors flying about. Pau is a center / power forward on the team and a very good complimentary player to Kobe Bryant. They won an NBA Championship a few years ago together and he’s one of the anchors of the team.

It seemed he was getting distracted by his own trade rumors and it was affecting his play. He was also getting quite emotional about it within the locker room. Kobe came out in defense of Pau and blasted management for not taking a firm stand—either declaring their intent to keep Pau or trading him immediately. He reminded management that keeping it ambiguous was simply cruel.

As a further response, Kobe gathered the team together in a closed-door meeting. Reports said that in it he encouraged them to:

  1. Ignore all of the distractions of their confused organizational leadership
  2. Ignore any rumors or other things outside of their control
  3. Asked them to trust each other and to re-commit to the team
  4. And focus on working as a team, leveraging their strengths, and focusing on winning games

I felt that this news was a fortunate coincidence and took the opportunity to share it with the class as a segue into my true answer below—

Apr11_Bob3

A Choice

I went on to say…
I think agile teams within most organizations are still measured primarily as individuals. It’s taking HR and Organizational systems time to catch up to the different, and in my opinion, more effective team-based reward and performance measurement models. So I think that challenge and reality is “out there” for most agilists. The question is, and this is where I think Kobe was going, we still have a choice in how we respond to these dynamics.

Blue pill

So, do we…
Behave as an individual—solely working for our own benefit? Caring only about ourselves and avoiding helping others because it’s not in our best interest. Being self-centric in everything we do and measuring our worth against everyone else’s contributions.  In a word, are we nuanced towards self?
Or do we…

Red pill

Embrace the reality of individual measurement and rewards, but chose to work as healthy, collaborative, and self-directed teams? Do we embrace our team and throw ourselves into attaining shared goals? Do we help each other and challenge each other to deliver excellence and continuously improve?

Do we supplement our personal performance measure against how we deliver as a team? And finally, do we count innovation and creative solutions as part of our deliveries and not simply count lines of code or executed test cases as a means of performance? In a word, are we instead nuanced towards team?

It’s a choice.
As for me and the teams I coach, I try to influence them towards the red pill. And that was my final point to the student’s question. But that’s just me…

And In Teamwork…Often Everybody Wins

The other implication to the “red pill’ is that if you’re part of a high-performing team—then your individual performance will shine along with your team. You should minimally reap what you would have done by working alone and it should be easier to achieve as a team.

I would even say you stand a better chance of being recognized and rewarded as an individual IF you complement your team members and embrace the team. I can’t think of a single exception to this in my experience—when I reflect on the agile teams I’ve coached.

And remember, you’ll get the chance to help others on your team. If you’re truly more experienced or more skilled, you’ll have the wonderful opportunity to grow and mentor others. You’ll get their thanks and team recognition in addition to your more formal performance recognition. I don’t know about you, but I think peer level recognition matters a great deal.

Wrapping Up

I believe an effective agile project manager has to set the tone for their team. They can continuously emphasize and reward outstanding teamwork. They can discourage Lone Rangers and Fire-Fighting, instead emphasizing solid engineering practices, careful craftsmanship, quality focus, and cross-team collaboration.

Sure, they deal with individuals and their performance. But they can establish a firm grounding of team-focus and team-work. I think you first do this by example, blending your own role into the team and gaining your own rewards through and within the team concept. So as to become a role model that talks about the team, but also walks with the team.

Now for my challenge…I still feel less than satisfied with my answer. I know there are far better ones “out there” with better perspectives that don’t include sports analogies. So, please share how you would have handled my situation.

Don’t forget to leave your comments below.


The Agile Project Manager—Listen to your Spider Sense

Spider-Sense_1_Bob

Spiderman_2_BobI was working with an organization a few weeks ago on a coaching assignment. They’ve been experiencing quite a bit of attrition within their technology teams and the discussion inevitably went to root causes. Several leaders at the client were confused about the drivers behind it.

One of them said that they had sat down with several developers before they left and everything seemed fine. They talked about the developers concerns and tried to address every one. They felt that there were “tuned into” the team and were trusted. They just couldn’t understand why folks were leaving without giving them an earlier warning…and more importantly, a chance to address their concerns.

Here’s another interesting ‘twist’ to the plot.

They had recently run an employee survey and the entire technology team seemed happy with their salary levels—generally feeling as if they were competitively compensated. So, everyone within the general management structure of the company took that “off the table”.

However and here’s the “Spider Sense” part, the technology leadership team at the company knew the following:

  • Local hiring for software talent was ‘hot’ and the company was an attractive target because of the talent of their engineers. The company was viewed as a high-growth startup.
  • Several key ex-employees had poached multiple engineers to their new organizations. This had been significantly on the increase over the past year.
  • In all cases when departures were made, it was heard through the ‘grapevine’ that money was a significant factor.  And the staff, while fairly paid, were not paid at a “premium rate” sufficient to compete in the hot local compensation market.

So as not to belabor it, the teams were telling leadership that compensation was not an issue. Yet, team members were leaving for significant compensation increases. Was compensation an issue? 

From a raw, surface level data perspective, no. 

From a an astute technical leader reading the landscape and their local environment perspective, leveraging their observations, knowing their teams, and finally…using their spider sense, the answer is a resounding YES!

The company will continue to lose people until it does something about their lack of compensation competitiveness—amongst probably other adjustments. It may not be the only challenge they face, but it’s certainly one of the “root causes” related to attrition.

Where was I going with this?

So what’s the point and how is it relevant to the Agile Project Manager?

Many naïve and inexperienced agile project managers react to the surface data that they are exposed to in their projects and teams. There’s usually plenty of it going on and it usually keeps their day filled with escalations, follow-ups, actions, and goals. It often is hectic and ‘feels’ as if you’re well-supporting your team & project.

And there’s nothing inherently wrong with this. However, what if the “surface data” isn’t telling you the whole story or the truth. What if there are other undercurrents that you should be paying attention to.  And what if those undercurrents are the “root cause” of your team & project challenges and success barriers? Or they are the very things standing between your team’s ultimate improvement, execution excellence, and delivery success?

I liken this sensitized listening to project undercurrents as developing your spider sense. It requires you to read the landscape, listen to the pulse of your team and project, and ultimately putting the pieces together based on your experience and judgment. It requires you to hear the unspoken and see the invisible and sense danger wherever it lurks.

It requires boldness and courage, because often the data isn’t supporting your investigations—so you’re often going it alone on your instincts. So, what are some of the things you can do to develop your own spider sense? I’ll explore a few areas here, but surely the list isn’t intended to be exhaustive.

Dog_Ears_Bob

Listen to what’s NOT being said…

Your team is working incredibly well together. Everyone gets along and is quite nice to one another. During every sprint the team struggles, but within each retrospective nothing crucial comes out for improvement. From the teams’ perspective and from the immediate surroundings, nothing strikes anyone as needing adjustment or repair.

Yet you get the sense that folks are unsettled. Team members are often frustrated with each other and have a general lack of attention to quality or detail across the team. In meetings, only parts of the team engage—usually only 1-2 of the loudest individuals. Everyone else is simply along for the ride. The team also doesn’t seem appreciative of one another—never thanking each other for help or their efforts.

In this case, the team probably lacks the trust and courage to confront their own performance and hold each other accountable.  So what’s not being said is—congruent feedback and passionate debate. As an agile project manager, you’ll need to look for ways to improve the teams trust and engagement—perhaps levering your retrospectives as the place for crucial conversations.

Lack of Continuous Improvement

It’s a strong potential anti-pattern in many agile teams that they stop improving. Sure, when they’re just beginning or converting to agile they often show significant improvement and results. But over time, they flatten out and simply start mailing in their results.

Don’t get me wrong, they’re still a very high performing team that is delivering on their promises. But they’re not improving, nor are they ‘stretching’ in their sprints or taking risks. Often these teams show very little quality, execution, throughput, or innovation improvement over time.  But they’re not regressing either.

So you need to look for complacent teams and try to look under the covers to see what might be the root cause. Often I see leadership mucking things up in teams—subtly taking away some of their empowerment. Burnout is another frequent cause and yes, you can burn out agile teams!  Another factor might be the product organization not providing inspiration aligning the teams work towards business goals. Regardless, you spider sense is tingling and you need to explore further and devise adjustments.

Product Organization Dysfunction

Too often organizations expect teams to simply “suck it up” and give it their all for a paycheck and for the company. Today’s brilliant technologist and engineers are not motivated solely by the money. They want to work on compelling products that delight their customers. They are attracted to product visionaries that are inclusive of their teams. They want to work on great products and they want to be part of the organizations overall success. In a word, they want to work on things that…matter.

In this case your spider sense should focus on how compelling the business is within your teams. If they’re treating your teams like commodities, then you must challenge this complacency and pull someone in to inspire the team by explaining why what they’re doing is important.

One aspect of this sense is looking inside yourself as the measure. Are you excited about your projects, the potential, the meaning, and the impact they will make within your company? Are you excited about the difference they will make to you customers? Do you find yourself jumping out of bed in the morning and impatient to get to work? If your answers to these questions are less than stellar, then use your own feelings as a guide on what needs to be done.

Management Dysfunction or They’re not listening…

One of the more insidious patterns that I’ve seen in teams is that leadership is not effectively listening to the team nor taking action. It is perfectly feasible in my entry example, that team members early on shared their compensation concerns with management.  But what did management do with that information? If they didn’t respond quickly enough or significantly enough, then the teams would feel that “leadership” wasn’t taking their concerns seriously.

You see, it’s not just about effective listening. Nor is it about taking small actions or providing excuses. It’s really about those and then taking “appropriate action – fast, timely, well-apportioned, and impactful” that tells your teams that you are truly listening to their concerns AND that it’s worthwhile top them taking the risk to communicate them.

So you’ll want to pay attention to how leadership ‘listens’ to your teams and across the organization. Do they truly listen deeply? Do they plan actions to address impediments and concerns with the team? And do their actions, by and large, align with the needs of the team? Meaning they’re appropriately significant.

I’m not implying that every team-raised issue needs to be attended to. But by and large, your teams need to feel as if the organization cares and is listening—or they will simply stop telling you the truth.

Pig_Bob

Trust your “Gut” & your “Common Sense”

These final two areas are my guiding light when it comes to my spider sense.

I often go with my gut feelings in decision-making. They’re based on my experience and pattern matching abilities to team and project dynamics that I’ve seen before. They often focus what I’ve been observing and condense it into a singular sense or feeling.

For example, I’ve made three catastrophic hiring decisions in my career. And in all three cases, my ‘gut’ was telling me no, but my head was caught up in bringing them aboard to ease my burden. In all three cases, I ignored my gut feelings. I’ve never done that again.

And then there’s common sense.

There’s an expression in the southern United States regarding pigs. I’ll paraphrase it—if it looks like, sounds like, and smells like a pig…it’s probably a pig. Too often we complicate things. We try to gather too much data and create a too complex landscape. The company I alluded to in my opening was doing that. When they analyzed their attrition, they thought they had between 10-15 factors that were driving it. And that the factors were independent or unrelated.

But when you peeled through the data and got to an honest root cause, there were only 3 primary factors that were driving attrition—money, the technical challenge of the work, and the company’s product vision. And I strongly suspect their common sense and gut feelings aligned with those three areas.

Wrapping Up

As an agile project manager, I want you to start leveraging your instincts, experience and skill in gathering the ‘smells’ within your teams. Just because they’re self-directed, it doesn’t mean they don’t need your experience and help in guiding them through challenges.

Quite often you’re in a unique position to see the forest for the trees and sort of pull things together.

But as I alluded to earlier, it will often be risky and take courage. Everyone will be off barking in the direction of obvious challenges, while you’re guiding them to look in another direction. But don’t be deterred. As that old “Web Slinger” learned long ago…you need to trust your Spider Sense!


Don’t forget to leave your comments below.