The Importance of Asking for Feedback

Over the past year or so, Management at my company has been emphasizing the importance of giving feedback to ones peers, Team Members and Managers. And rightfully so. The act of making yourself vulnerable and mustering up enough courage to say what you sincerely feel is in the best interest of another cannot be overstated.

So, if giving feedback is so important, why is it so difficult to do? Well, Erika Anderson puts it this way, “Most often, we’re worried about the other person’s reaction: What if she gets angry?  What if he cries?  What if she tells me I’m an idiot?  What if he gets super defensive and starts blaming me? Another thing that makes it hard is not knowing what to say.  “I can’t actually tell that person I think he has a bad attitude,” we say to ourselves.  “He’ll just tell me he has great attitude, and that I don’t understand/like/respect him, and it will go from bad to worse.”

You can find many posts like Erika’s doling out tips and tricks on how to improve the giving of feedback. But, today, I’d like to flip this concept on its head a bit. I strongly believe that we should be laying the foundation for the feedback that we give in the future by asking for feedback Today.

Let’s delve a little deeper into this thought – the benefits of asking for feedback are quite vast:

  • It demonstrates that you value the opinion of your team mates. Even if you don’t put his/her recommendation(s) into action, the mere act of showing your peers that you care enough to ask their thoughts of you will go a long way in improving your working relationship.
  • This should go without saying, but asking (and receiving) feedback gives you some continuous improvement areas to consider. We all have blind spots – your team mates can help you identify them.
  • Asking for feedback almost always immediately opens the door for you to give feedback. 9 times out of 10, after your peer shares your requested feedback, he/she will turn right around and ask you for yours.

And this door remains open. The more frequently that you ask for feedback now, the easier it will be to give feedback down the line when necessary. You’ll find that you no longer need to psych yourself up for the event like you’re preparing for battle nor have a couple of glasses of Moscato after the deed is done. Giving (and receiving) feedback will have become second-nature for you and your team and you’ll soon find that you’ve created a culture of openness, transparency and Continuous Improvement all around you. And this is the ultimate goal.

So, where do we start? Here are few simple thoughts to get us going:

  1. Seek out a close peer.
  2. Tell him/her that you value his/her opinion and that you’d like to know an area where you perform well and one where you can improve.
  3. Smile when you acknowledge the look of shock on his/her face and encourage him/her to be honest. 🙂
  4. Listen.
  5. Be prepared to share your feedback on his/her performance as well!


What has been your experience in giving and receiving feedback?


Our Journey to #NoEstimates

For some time now, my boss has been dropping not-so-subtle hints about the evils of estimating:

1. They are almost always inaccurate. As Ron Jeffries puts it, “Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. If we had done it before, we’d just give it to you.”

2. They are a form of waste. The team puts time and energy into an effort that produces the aforementioned inaccurate information.

I got his point. In theory. But I was seriously struggling with putting it into practice. Plus, I’ve noticed lately that I have difficulty in doing something simply because it is suggested (and may actually dig in my heels a bit) – there will be another post on this. So, my team kept right on estimating.

Then, it happened. After a few Sprints of throwing story points, I pulled some metrics to see how accurate our points were. What I discovered was enlightening. All of our story point estimates were severely out-of-line save our 5-point estimates. Those were pretty close!

story points

This told us that we pretty much knew what a 1-2 day story looked like. So, we went with that.

During our Refinements, instead of playing Planning Poker, we sized our cards down to a “5” (whenever possible). Theoretically, we were still estimating but our focus was starting to shift.

For a few Sprints we continued this practice. It felt a little funny at first. Then it started to become natural. Our conversation subtly changed from “How much effort is required for this card?” to “Do we need to break down the work?” We organically moved from calculating our Velocity to measuring our Throughput and Cycle Time. This simple change was pushing us into a much more Lean direction.

Now, a few months later, we aren’t focused on sizing our cards to a “5”. Instead we ensure that our cards are “right-sized”. Our Throughput is much more predictable than our Velocity ever was – We consistently deliver 36-39 cards a Sprint and spend much less time nit-picking over if a card is an “8” or a “13”. I’ve also noticed that we relentlessly examine our Cycle Time and have begun embracing other Lean principles as well.

Sure, we could’ve simply moved to #NoEstimates when probed, but there was tremendous value in the journey. When a team is allowed the freedom to explore what works best for them, the lessons are much more likely to stick. And now each team member has a story to tell that can be shared with other teams along their Agile journey.


Have you explored #NoEstimates? How did it work for you?

How much freedom do you think teams should be given in determining what works best for them? Where do you draw the line?


Does Scrum welcome Change?

In my last One-on-One with my Fearless Leader, I mentioned the challenges that my team is currently facing with getting out in front of unknown impacts. Lately, we’ve been hit with unexpected work: from minor feature requests and enhancements to new applications to support – it would be great it we could get a bird’s eye view of these anticipated items so that we can fit them into our Roadmap and Sprint Plan. Our company divides work across several Portfolios – there is a many-to-one relationship between Teams to Portfolios. Our team manages to get a decent heads up when work within our Portfolio is going to hit us – what we are struggling with is the work that initiates outside of our Portfolio. So, I brought this concern to my Manager and, as usual, he flipped the script on me.

He relayed that, while it’s always great to try to get better visibility into the unknown, it’s even more important to welcome it. He went on to note that our company is particularly change averse and that THAT is the true opportunity for improvement.

Let’s dig into this a little. I have been taught (and therefore practicing) that, as a Scrum Master, I should fiercely protect Sprint Boundaries – Meaning that once my team undergoes Sprint Planning and sets the Sprint Goal, we should closely analyze any proposed changes to the Sprint with a questioning eye – like this:

1) Does this proposed change fall in line with the Sprint Goal?

2) Does the team have capacity to absorb the change? If not, Mr. Business Stakeholder, if this change is sooooo important, what do you propose that we REMOVE from the Sprint to accommodate it?

In hindsight, this behavior is not quite one of a team who is welcome to change. So, have I been missing a critical component of Agile and Scrum, in particular? Let me check the rule books.

The second Principle of the Agile Manifesto states, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Well, snap.

What about the Scrum Guide? It states, “During the Sprint: No changes are made that would endanger the Sprint Goal;”

It goes on to indicate that the best course of action, if a substantial change is proposed that would jeopardize the Sprint Goal, is to cancel the Sprint altogether:

  1. Any completed and “Done” Product Backlog items are reviewed.
  2. Deploy any potentially releasable work.
  3. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog, realizing that the work done on them depreciates quickly and must be frequently re-estimated.

My initial reaction is that this is a much more rigid interpretation of the spirit of the Agile Manifesto – and frankly, it doesn’t seem to welcome change much. The undertone is more negative and leads one to believe that any change to the Sprint is an undesired behavior. But digging deeper, there is subtlety in the words of the Scrum Guide. It places more weight on the Sprint Goal itself – if the Goal is crafted with thought, it is quite possible that the unplanned work will fit nicely inside. And if not, the next iteration should be right around the corner. This all means that it should be a rare occasion where the team should have to resort to canceling the Sprint.

All this being said, there is no denying that the Scrum Guide has a bent on NOT changing the Sprint.

For what it’s worth, our team hasn’t been following the Scrum Guide in this regard. When significant change hits us mid-Sprint, we’ve:

  1. Panicked
  2. Estimated the work at a story-point level
  3. Pulled the new cards into the Sprint
  4. Removed the same number of story points from the Sprint in descending priority order
  5. Moaned and groaned throughout the remainder of the Sprint about how our Sprint was thrown off-course.

I do believe that there would have been value in following the steps to cancel the Sprint, if the proposed changes wouldn’t have jived with the Sprint Goal (and in our recent examples, it wouldn’t have). Canceling the Sprint would have:

  1. Given the team a chance to reset and absorb the new work mentally.
  2. Showed the business the impact of the unplanned work on our team so that we could, potentially, make different choices next time. Or not.
  3. Allowed us to deploy the potentially-releasable work that we have completed, giving the team a sense of accomplishment in what was done during the Sprint.

So, where do we go from here? Continue to fiercely adhere to the Scrum Guide although it seemingly conflicts with the spirit of the Agile Manifesto? Do away with the Scrum Guide in this regard or altogether? (After all, Kanban has been softly knocking at our door for some time now) Let’s not be so drastic. Perhaps a simple mind-shift is all that is needed. I propose a three-pronged approach:

  1. Talk to the team about the Spirit of the Agile Manifesto where change is concerned. Ask them what we can do to become more open to change. Talk openly about the Scrum Guide and it’s bent towards “protecting the Sprint”.
  2. Reiterate the importance of the Sprint Goal and choosing it PRIOR TO the selection of the Sprint Backlog.
  3. When unplanned work hits the team, Cancel the Sprint with a positive attitude!
  4. Continue to work with Leadership and the Business to get better visibility into cross-Portfolio Roadmaps to plan for work that could potentially impact our team.


How does your company/team handle change? How do you view this perceived conflict between the Agile Manifesto and Scrum Guide? Does Kanban lend itself to more flexibility in this regard?

The Sprint Goal

The Sprint Goal is one of the most fundamental, yet overlooked and misunderstood components of the Scrum framework. As a matter of fact, the Scrum Guide hinges on the Sprint Goal so much that it states, “A Sprint would be cancelled if the Sprint Goal becomes obsolete”! I sheepishly admit that I’ve not been a good steward in this regard – most, if not all, of my recent Sprints have had watered-down or meaningless Sprint Goals.

So, let’s get back to basics and take a few minutes to study the  Who, What, When, Where and Why regarding this often disregarded concept.


So, who should set the Sprint Goal?

According to the Scrum Guide, “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal”. This indicates that the ENTIRE team is responsible for creating the Sprint Goal.

So why does there seem to be so much confusion about this in the Agile community? One blogger writes that, “The product owner can choose the goal beforehand to help her order the backlog according to the goal. Alternatively the whole team can phrase the goal at the end of planning, when they know which stories will be part of the sprint.” Clearly, the Scrum Guide says otherwise. This glossary also states, “A high-level summary of the goal the product owner would like to accomplish during the sprint.” Again, not true.


And, what is the Sprint Goal anyways? Good question! Once again, let’s refer to the Scrum Guide. “The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog…The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”

So, the Sprint Goal is the higher purpose that over-arches the Sprint Backlog. Put simply, it is the most important deliverable during the Sprint – it should be top of mind throughout every facet of the Sprint. One blogger even noted that it’s often possible to deliver the Sprint Goal WITHOUT completing all of the Sprint Backlog items.



Alright. We now know What the Sprint Goal is and Who sets it, but When is this done? The Scrum Guide says, “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal”. This seems to indicate that the user stories for the Sprint are first chosen and THEN the Sprint Goal, which ties them all together, is derived. But does that make sense? Is it wise to choose your path before you even know where you’re going? This blogger agrees with my logic, “I first select the goal. Then I explore which epics have to contribute to it, and I break out small detailed stories from the epics. Finally, I order the new ready stories based on their contribution to the goal.” This makes sense to me. As Ebenezer Ikonne (eikonne) so wisely queried over HipChat, “Which comes first, Goal or Tactic? 🙂 ” But UrbanTurtle disagrees, claiming, “It is best to define a sprint goal after all the stories have been selected for the sprint. It’ll be easier for the team to craft the sprint goal together since they have a better understanding of the work to be done.” Le sigh. This is actually the topic of the next Scrum Master forum meeting at my company – I’ll let you know where we land.



An easy one. So, where are you when you’re busy creating this Sprint Goal? You’re in your Sprint Planning meeting. That’s where.


Most importantly, Why set a Sprint Goal? Focus and Flexibility. The Scrum Guide puts it this way, ” It [The Sprint Goal] provides guidance to the Development Team on why it is building the Increment…The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.” It allows the Scrum Team to inspect and adapt throughout the Sprint to ensure that it’s working on the right stuff.

This is why during the Daily Scrum, the following 3 questions are asked:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

We tend to often trim the “meet the Sprint Goal” from the end of these. Let’s add it back 🙂


So now that we have a better understanding of the purpose and implementation of the Sprint Goal, I encourage us all (myself included) to put and keep this concept front of mind. I also urge us to revisit the Scrum Guide to (re)discover any hidden goodies – and share what you find!



Introverted and Proud!

I remember it like it was yesterday.

I was in my 5th grade Science class when I asked my teacher a question. She thanked me for my inquiry and began answering it for the class. While she dove into her boring diatribe, I turned around and began chatting with my classmate.

Then it happened. She called me out! “Adria, it is rude for you to ask a question and not bother to listen for the answer”. GASP! I could’ve crawled under my desk. That’s when it all began – my introversion. Never again would I speak in front of more than a few good friends (forget about strangers).

Fast-forward a few years…Being a Developer in the 2000’s was perfect for me. I got to sit under my headphones and code the day away, interacting with no one. SCORE! After a few years, I became a manager in my small company. But my introversion didn’t manifest itself at that time since I was still working with a small group of folks, friends really, that I’ve known for years – no issues speaking in front of that tiny, amiable group! It actually wasn’t until I switched companies that I began to notice some challenges creep in – not too bad since I joined as a Sr. Test Engineer and made friends before moving back up to a Management position. Once again, I was able to lean on my friendships and was only mildly uncomfortable when speaking in front of them and others. But then, I switched companies again. Now, I was a Senior Manager at a large corporation. I quickly found that the one thing that was expected of a Senior Manager was the same thing that I was uncomfortable doing – speaking in front of strangers. HELP.

There was considerable flailing. I was seen as a meek leader, someone without a strong point of view. I gained respect in the work that I delivered, but my quiet words often fell on deaf ears. The need to change was obvious. I began furiously researching how to overcome my short-comings and quickly – here’s what helped me:

  • Over-prepare. If you are facilitating a meeting, get your agenda ready days in advance and know it backwards-and-forwards. Know who will be at the meeting, their personalities and think of worst-case scenarios so that you can be ready if things go off the rails. Take a facilitation class – I highly recommend The Effective Facilitator.
  • Be early and speak first. If you will be attending a meeting, arrive early so that you can become comfortable in the environment – chat with the facilitator and attendees as they arrive. The more relaxed you are, the better.
  • Change your way of thinking. This is most important, in my opinion. Society teaches us that being an introvert is a weakness. This is not true! Being an introvert is simply different than being an extrovert – and being different is totally OK. As a matter of fact, there is a need for both extroverts and introverts in Corporate America. This article highlights that, “listening, focus, making one-on-one connections, introspection and establishing safety all lead to increased transparency and communication”, values that are critical to a successful work environment.
  • Find the root cause. Once I realized that the source of my introversion was a lonely incident that happened decades ago, a weight was lifted off my shoulders. There is power in knowing root cause. I encourage you to take a journey back and pin point when your introversion manifested itself. Dig in and seek to understand why this happened. Try to make sense of it. You might be surprised to find how something that happened years ago is ferociously shaping who you currently are.

Here’s another nifty article that gives some great tips on how to make us introverts more successful:

By no means have I conquered my fear of speaking in front of others, but that’s OK as long as I’m continuously improving in this regard. It’s all about the journey. And while I grow, I’m just as focused on retaining the strength in my introversion – not forsaking the “good” while trying to overcome the “bad”.

Any introverts out there? Share your tips and journey!

– Your self-proclaimed introvertedagilist 🙂

Assessing an Agile Team

The last few weeks have been a whirlwind! I began shadowing the existing Scrum Master on my new team about 6 weeks ago and have officially been in her shoes for 2 weeks. It was fantastic having those 4 weeks to slowly ramp into my new role and ramp out of my previous one – totally recommend this approach for anyone who has the opportunity! This buffer time also gave me the chance to sit on the sidelines and assess where I could start offering value – in due time! I definitely didn’t want to jump right in and start making changes. The rule of thumb I was recommended:

  • Observe the team for 4 weeks while previous Scrum Master is in place
  • Continue to observe for 2 weeks once I’m in the role
  • Work with the team to discuss and prioritize areas for improvement (remembering that the TEAM must drive all improvements – these are not MY improvements to force!)

So, how do you go about assessing a team? I did some research on this topic and had a few conversations with some peers. What I found that it really boils down to? The Agile Manifesto. If you’re a seasoned Scrum Master, you’re familiar enough with The Agile Manifesto to sense when something just isn’t jiving with it’s spirit. And if you’re not, you’ll get there. But the key tenet is that when you notice that thing that is out-of-whack, don’t sweep it under the rug – jot it down and digest it.

Need something a little more tangible? So did I 🙂 My mentor shared this handy checklist with me:

Scrum-checklist (Kniberg)[1]

Here’s how it might look once completed:


So, now you’ve got yourself a nice little list of potential improvement areas. Remember, these belong to the team – NOT YOU. In the next post about Retrospectives, we’ll chat about how to work (or not work) these items into a prioritized list of actionable items.

Happy Scrumming!

The best laid plans…

So, I had my interview strategy nailed down, right? I was supposed to do the following:
  • Review the sample interview questions that I found online.
  • Eat well, drink lots of water and get a good night’s sleep! 
Well, up until the moment that I turned the corner to my house, I had forgotten that Monday was the Atlanta Falcon’s season opener. But the 20-odd cars in and around my driveway immediately made me aware. Yep. The hubby invited everyone that we knew over for the game. There would be no healthy eating. Unless you count the celery that comes standard with the greasy hot wings that he ordered. And a good night’s sleep? Yeah, right. The game didn’t end until around midnight and our house guests didn’t depart until 1am. And, remember those interview questions that I was supposed to review? Well, those didn’t get glanced at until 2am and was abruptly cut short by the coughing fit that my 1-year-old suddenly launched into. Turns out that what I thought was simply seasonal allergies at 6pm quickly morphed into a full-blown cold. Of course, after I drugged her appropriately, the last thing on her mind was going back to sleep. She finally conked out at around 4am. In my bed. With one foot on my belly and the other on my face. And it gets worse. Had I known that little Alex was coming down with a cold, I would have been much more diligent with my hand-washing practices. As a result, around 8am (with only around 4 hours of sleep), I was awakened by what felt like a Mack truck rolling back-and-forth across my body. I was at a crossroad. Do I cancel the interview that took forever to get scheduled? Or do I plow ahead although I’m the epitome of unprepared?
Long story short? I got the job 🙂

So, I have an interview…

After lots of “Hurry up and…WAIT!”, this glorious day is now upon me. So, now what? I personally believe that we’re most successful when we’re confident. And I’m most confident when I’m prepared.

  • Intangibles
    • What to wear? Yes, I’m still a girl 🙂 And there’s some truth behind the notion of you DOING your best when you’re FEELING your best. This also encompasses making sure that I eat well the day before the interview, drink lots of water and get a good night’s sleep!
    • Get your mind right! <peptalk> Remember, YOU are interviewing THEM! You are in a perfectly fine job right now. You don’t NEED this job, you WANT this job. </peptalk> This should be freeing! Here’s an article I found that brings this concept home:
  • The Good Stuff
  • Now, relax: You’re prepared and you’ll do fine. It is what it is. If it’s meant to be, it’ll be. If not, there’s a larger plan at play. I’m a full-believer in 1) doing your part 2) letting God do His. Now, it’s His turn 🙂 I’ll keep ya’ll posted.

Sprint 0 – Setting the stage for Success

So, what’s keeping me up at night lately? Trying to figure out where to begin. Although I don’t even know if I’ll get this job (I just officially applied for it this week, supposed to interview soon), it’s almost all that I think about! So, assuming that I do land the gig…Where do I begin? Well, as Lewis Carroll so elusively put it, “Begin at the beginning”, and in Agile, the beginning is Sprint 0.

It’s interesting how some folks are opposed to planning. They just want to get down to the “real work”. But what they don’t understand is that, if you don’t start with a good framework, you’re doing like the Good Book says and building your house on sand: Yes, God is the ultimate Agilist. He  knows that right-sized planning will save you a ton of future headache.

So, what IS Sprint 0? In a nutshell, Sprint 0 is doing what is necessary to prepare for Sprint 1. It sets the framework for how the team will operate and remain healthy. There’s lots of opinions on what belongs in Sprint 0, and, in my opinion, as with most things, there is no right answer. It depends on the team makeup, personality, Agile maturity, etc, etc, etc. But, I did meet with my mentor and come up with a good starting list. Each of these really deserve their own blog post – don’t worry, it’s on my Product backlog 🙂 –

  • Team Charter
  • Team Name/Marketing
  • Team Values
  • Roles
  • Who are our Customers?
  • Team Working Agreement (internal)
  • Team Working Agreement (external)
  • Meeting Ground Rules
  • Ceremonies
  • Definition of Done
  • Definition of Ready
  • Sprint Length
  • Initial Product Backlog

This may seem like a lot to bite off at one time. But, man, I’ve reviewed the list several times and I can’t find a single item that I’m willing to table – I whole-heartedly recommend starting off right. “But,”, you might say, “what if my team has already formed and moving along?” Get these conversations into your Product backlog ASAP. Make them User Stories like all of your other work. Even assign Business Values to them and see how they rise to the top. It’s never too late to set the stage for success. As a matter of fact, without discussing these items, one might argue how you even know what success looks like…

Create a free website or blog at

Up ↑