6 Ways Leaders Avoid Becoming Roadblocks


Whether you’ve been managing for a long time, you have a new team or are a new manager; include your own positive and negative contributions to the team when you evaluate the team’s overall success. There could be times where it’s you that may keep the team from growing.  You could be out of touch with the team, maybe you’re still using traditional methods that are no longer reaping the same results, or perhaps the pressure from senior leadership is driving your decisions in a different direction than where the team is going.  Whatever the reason, take some time to try some of the idea s below.

Rely on Experts
A very wise man once told me that he always surrounded himself with people that were smarter than he was.  At first pass, you may agree, but he was an expert too.  Remember that as a manager you are there to lead, motivate, mentor and, when necessary, even discipline.  The people on your team are there because of their expertise and every day that you rely on them to bring their very best to the rest of the team you allow them to make good decisions based on their expertise. Challenge them to grow further and then step back so they believe they are trusted experts.

Sit in the Pit
The best way to understand what motivates and runs a team is to take time regularly to be around them.  All too often, I see managers move further and further away from their teams for the office with the nice view and the big door.  You’ll be missing out on an abundance of non-verbal and verbal information that could help you understand how to manage the team and who might need the most guidance.  Anytime the source of truth is further than the mouth that speaks it, surely the message will be old, inaccurate or both.  (This is a great paragraph, it really reads so well.)
Publicly Praise the Team
It’s nice to hear when you’re doing a great job so think about the last time you praised your team.  If it’s sincere they will know and appreciate it.  If it’s not, they’ll see right through it. If you don’t know what to praise them about, it’s possible that their goals are not clear or maybe your expectations are too high. Sit down and consider what the team could do that you would consider praiseworthy and then share it with them.

Raise Individual Concerns Privately
It’s difficult to hear constructive advice and it’s just as hard to deliver it.  To build and retain trust within a team, corrections should be done privately, courageously, and with respect.  Use examples of what initiated the need to discuss it and offer a suggestion on what could have been done instead.  Doing this privately shields the rest of the team from unnecessary stress, defensiveness and confusion that may be uncovered while you work directly with the people that most need the help.

Allow the Team to Fail
We are told as children not to fear failure; it is part of learning and we should persevere with the courage to try.  Lanette Creamer, a writer and speaker, says, “If failure is not an option it is guaranteed.”  When teams are given the security to fail and still keep the respect of their manager and peers, they will keep trying.

Manage Up
Everyone has a responsibility to someone in the corporate ladder, so consider that while you are trying your best to stay out of the way while providing clear direction and support. Your boss may need the same advice. If you are having difficulty, allow the team to evolve and grow because of influences above you. Take the time to smooth the path for the teams by smoothing the path between you and your manager.

These are simple pointers to help you stay engaged with the current state of your team and how to encourage progress..Encourage your peers and leaders to consider these ideas and pass them along.  When we have better leaders, we have a better chance of having great teams. If you have other ideas, I would love to hear them!

Common Agile Practices That Sabotage Us


Sometimes we need help to improve our team and sharing insights into why some practices and behaviors can sabotage team progress.  Take a look at the following observations teams have made to see if your team can identify with them and take action before it becomes a bigger or longer term problem.

Observation:

We have a lot of stories that are closed by DEV and then new stories for QA testing are created to test what Dev hands over.

Impact to the Team:

  • Because the number of stories in the sprint steadily increase during the sprint, the burndown chart will likely look like the team is always behind schedule.
  • Individual capacity is extremely difficult to plan during sprint planning because the number of stories at the beginning of the sprint will be lower than reality.
  • Forecasting sprint plans and project schedules via velocity is useless here because the team velocity is not consistent each sprint.
  • Without the ability to forecast with solid data to prove the estimates are achievable, the team’s commitments aren’t reliable so the confidence of schedule estimates will be low or non-existent.

Options to improve:

  • Create a user story by including the user scenarios to help clarify the expected outcome and user experience of the story. This not only helps QA kick start the test automation earlier in the process but also helps Dev to understand how the feature will be used in different situations and they tend to have lower bug counts.
  • Keep a user story open until it has cleared QA.  A user story is NOT DONE if it hasn’t been tested and accepted by the Product Owner.
  • When logging bugs against a user story, keep the bugs as close to the story as possible. If your tool allows you to add the broken test cases inside the story, do that. Everyone should be able to quickly see which stories are not done and why.

Observation: We can’t seem to get our user stories done in a single sprint so we have the same story in several sprints.

Impact to the Team:

  • Because the feature that is represented in the user story is not done for several sprints, the team’s work cannot be “potentially shippable” at the end of each sprint.
  • Because the user story is not uniquely defined each sprint, it may not be clear to everyone what is expected to be done by the end of each sprint.
  • The work for the user story keeps “sliding” to the next sprint and it’s unclear whether the feature is on track to be completed by the last user story that was extended.

Options to improve:

  • When reviewing a user story during sprint planning, identify stories that are too large to get all of the work done; that means development as well as cleared by QA. Break up those stories into more than one by grouping a set of user scenarios that CAN be done in a single sprint and “rebranding” the user story to reflect those scenarios so that when you look at each story, it’s clear what will be delivered in each new story. They should be uniquely identified.
  • Remember that at the end of any sprint, the Product Owner should always have the option to request all stories that are DONE be “shipped to production.”  If your team cannot do that, then the user stories weren’t really “DONE” in the sprint(s).

Observation: We have people that are on more than one agile team.

Impact to the Team:

  • Team members that are on more than one team become less efficient because they are attending multiple sprint planning sessions, daily stand ups and working sessions.
  • Individual capacity planning is more difficult because the team member must be consistent in the time that they commit to each team so that they are able to commit to their work and keep each team’s velocity consistent.  For example, I am on 2 teams and I will consistently commit my time 50/50 between them so that team velocity and my individual capacity is reliable and consistent.
  • Scheduling sprint planning and daily stand ups become more difficult to schedule because of team members that have more than one to attend.

Options to improve:

  • This situation should be temporary.  There should be a transition plan in place so that teams have the ability to continue taking on new work and their velocity can stabilize and continue to improve.
  • If people have a unique skill set and transitioning is not an option within a few months, determine which agile team has the most work for that skill set and put them on that team.  Any new work that requires that skill set is assigned to their team, becomes part of their velocity and capacity planning metrics.
  • Ensure that when new projects requiring that person’s unique skill set come up, they are invited to the release planning and the user stories are appropriately written and part of that team’s sprint planning.

Observation: We have people that get moved from one agile team to another throughout the year based on projects that come up.

Impact to the Team:

  • Team velocity is useless because the aggregated capacity is not constant and each team’s velocity cannot stabilize.
  • Individual capacity planning is more difficult because the team member must be consistent in the time that they commit to each team so that they are able to commit to their work and keep each team’s velocity consistent. For example, I am on 2 teams and I will consistently commit my time 50/50 between them so that team velocity and my individual capacity is reliable and consistent.
  • Scheduling sprint planning and daily stand ups become more difficult to schedule because of team members that have more than one to attend.
  • Forecasting sprint plans and project schedules via velocity is useless here because the team velocity is not consistent each sprint.
  • Without the ability to forecast with solid data to prove the estimates are achievable, the team’s commitments aren’t reliable so the confidence of schedule estimates will be low or non-existent.

Options to improve:

  • Consider that teams that are able to stay together over time become more efficient as they learn to work together, improve together and their individual skills increase.
  • When building an agile team, ensure that the type of people and their skill set is appropriate for the backlog of work they will receive.  A healthy balance of development, testing and operations on a single agile team is key.
  • Rather than sending people to projects, keep the same people on the same teams and send the appropriate project work to the team.  This is where Release Planning for a project will ensure that each team identifies which user stories from the project are “theirs.”

What options do we have to integrate a UX/UI team into our Scrum process?


Although this question doesn’t come up all the time, it certainly comes up enough that sharing how our team made the decision to keep the Design team work outside our scrum team’s sprint could be helpful to others.
 
Just to give you some background, this team has been focusing on the intake of new projects, how we define new projects and what information is needed to ensure we make good business decisions in the future.  And, since this post references some processes in a previous post, you may want further clarification, so check it out here.
 
Our team has had many organizational changes over the years so we decided to take time to evaluate our agile practice and our teams to see how they were doing.  During our reviews, we heard that our design team wanted to understand how they would participate in our scrum practice and previous attempts weren’t going well.  So, to keep our discussion simple and make a decision quickly, we had leads from Product, Design and Tech review two options that we could use to plan and execute with consideration for how design/UI/UX is integrated into the process we continue to evolve.  Take a look and come prepared with your input on which option you believe works the best for your team.
 
Each option assumes…
 
…for each new project that is approved and moves to the “COMMITTED” status, we will have release planning with all teams invited (product, design, tech, ops, etc.) before we begin so that everyone understands the goal of each release (if there is more than one per project) and what high level features are being requested.  
…at the end of the release planning session, each team comes up with their estimated schedule to complete the project and each release/milestone along the way. This is the way we create the CPE (Concept Phase Estimate) and projected completion date and the project moves to the “READY” status in our Intake workflow.
 
Red text represent the variance between options
 
Option 1 = Design iterations of a user story are done prior to team sprint planning
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team that will be part of the next engineering sprint planning session
  4. Iterate with Design until each user story from the first set is ready with all required information for engineering to begin
  5. Product Owner presents the user stories along with lead Designer at the engineering sprint planning session
  6. Sprint commitments are made on which stories engineering can complete in the sprint
  7. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  8. Design and Product continue to work on the next set of user stories during this sprint that will be presented at the next engineering sprint planning session
  9. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance
 
Option 2 = Design and Dev of a user story is done in same sprint
  1. Features and scope from the approved project are prioritized within each release by the Product Owner
  2. The first set of features (highest priority) are broken down into user stories by the Product Owner focusing on the “what” and “why” but not the “how”
  3. First set of User Stories are presented to the Design team and the Tech at the same time during the sprint planning session
  4. Sprint commitments are made on which stories Design and engineering can complete in the sprint
  5. Product and Design are available to the scrum team for questions and tweaks to the design during the sprint
  6. Design and Dev are done in parallel on the same stories during the sprint
  7. Product Demo is held the last day of each sprint to demonstrate each completed story and gain Product Owner acceptance

Early in the discussion, most people were already on board with Option 1 but we continued to discuss examples so that we all understood how it would play out in the day to day ceremonies that our teams already had such as Release Planning, Sprint Planning and daily stand ups.  We agreed that leads from Product and Design would continue to attend the sprint planning and daily stand ups as needed by the team.

Agile Ceremonies


NOTE: Since this post references project workflow and you may want further clarification, check out my other post regarding project workflow here.
Please take a look at the summary below which explains the type of meetings and practices throughout the lifecycle of our projects that we’ll be focusing on improving and adjusting as we grow as an agile organization.  Remember that every team and organization customizes things to match how they work so this is not meant to be prescriptive. Use it as a guide and go from there with your team.SAM_1313

Yes, We’re Agile but we still Plan, right?


Yes, of course you still need to plan – even when following some type of agile method. It still amazes me that so many organizations stop doing this. Some don’t it because they believe that agile means no planning and some don’t it because … well, there are so many other reasons. Is it really worth repeating?  Maybe I’ll do another post about that, but for now, let’s look at one team established an intake process for new projects and made it simple yet effective.

000 Blog Agile Topic Photos - 10

 

Before our teams begin working on new projects, we need a way of ensuring that there’s a solid business case to do it and a clearly defined scope of features or benefits.  Sounds like planning right? Well, you could say that but, actually it’s before we even start really planning; we’re evaluating, we’re justifying, we’re using the ROI (Return on Investment) model to ensure we are pursuing the right project in the right order (priority).

Let’s look at the scrum model for a moment.  Each sprint starts with a fully formed group of user stories in the backlog that are “ready” for the team to start working on them right?  Well, how do you know that those stories are really the right ones to pick up next?   We started by tracking backwards from the backlog to build a process the supported how we were working and kept us in an iterative learning state of mind.  The image here shows the process or workflow that we are using.

The Product Owner is constantly evaluating current progress against the backlog of new ideas.  Once they have something to present, they prepare a proposal that includes key data points of their research and ideas in the form of business justification and benefits to the company and our consumers. We ask for 1-3 sentences describing the end result of the project.  It should address questions like “Why are we doing this?”, “What is current problem statement or potential improvement and what is the expected outcome at the end of this project?”  Along with this justification, we also ask the Product Owner to detail the benefits to the company and/or our consumers by providing either target or concrete goals for the project that fall into categories like Cost Reduction, Revenue Generation, UV Lift, PV Lift, Brand Lift or Efficiency Gain.

This provides everyone reviewing the proposal a clear understanding of the why they may want to approve the project to be approved and funded.

Image

If a proposal is approved, it is moved to a “Committed” state where the teams involved do a release planning session so that all the impacted teams (internal and external) are able to evaluate the size of the work and the interdependencies between team as well as other projects that my have higher priority to agree on a projected start date, completion date and estimated cost.  Those data points are provided back to the approvers to ensure that the ROI is still positive.  If everything still looks good, we move the project to “Ready” and each team picks up user stories from the Product Owner for their sprint planning sessions.

Not every project begins immediately after the release planning is completed but we try not to allow too much time between the session and the project actually starting.  There are cases where a proposal is approved but it’s low enough on the project priority that it could be months before we are able to start working on it so we delay the release planning to be closer to the start date. We move the project to “In Flight” once work begins and place it in “Deferred” status when and if the project is put on hold.

Notice that even after a project is moved to “Complete” it’s not all the way through the project workflow.  This was an important step in  iterative learning and decision making that we added after a few months running the projects through the workflow.

Some of our project leads were reporting that even when the final production installation was completed, the benefits that were expected from the project would not be true until several weeks or months afterwards.  And no one was going back to evaluate the results of the completed projects to verify that the benefits had actually been achieved and to what degree.  That was the beginning of our Project Retrospectives.

If you think about how Scrum teams do team retrospectives to determine what changes were working and which ones weren’t it makes total sense that as a business, you’d want to do the same with projects.  Every month, we began retrospecting about each project that was completed in the prior month.  The team members were encouraged to present the results and we started to see improvements in several areas not just in the new project submissions but also in the cross pollination of product knowledge across the organization that did not have a venue in the past.  People were curious about why we were doing certain projects and now they had a space to hear the results, see the bigger picture and feel how each of them were part of the overall goals.

Once we completed the retrospective for a project, we move it to “Benefits Realized” adding the results so that we can reference it in future project proposals. Here is a template that was used for each project retrospective.  Note that our company uses the capitalization accounting practice so it’s also evaluated.Image

Agility is about the ability to react quickly when necessary and appropriate.  So yes, we plan and we are still Agile.  We use the intake workflow to keep us in the cycle of learning and adapting.  We’ll likely make adjustments as we evolve as a team but for now, this is reminding us to keep watching if we’re going in the right direction and allow the agility of the teams to respond as we learn and adjust our business roadmap.

Chocolate Bread with a hint of Banana


Revised a recipe I found today and it’s really yummy!

Ingredients

  • 2 large bananas very ripe
  • 8 tablespoons unsalted butter
  • 1/4 cups raw sugar
  • 1/4 teaspoon salt
  • 2 large eggs
  • 1/2 cup plain yogurt
  • 1 teaspoon vanilla extract
  • 1.5 cups all-purpose flour
  • 1/4 cup unsweetened coco powder
  • 1 teaspoon baking soda
  • 1/2 cup chocolate chips

Instructions

  1. Preheat to 350 degrees F .
  2. Grease and flour a 9″ loaf pan
  3. Microwave the bananas, butter, sugar and salt for about 3 minutes. Stop it for a few seconds if it tries to boil over. Let this mixture cool to luke warm.
  4. Sift the all-purpose flour, coco powder and baking soda to remove any clumps. Add the chocolate chips and then whisk/mix the mixture together.
  5. Put cooled bananas in a blender/food processor along with the eggs, yogurt, and vanilla extra until smooth
  6. Combine banana mixture into the flour mixture,  but no need to over mix.
  7. Pop it into a loaf pan and back for 40-50 minutes.
  8. Cool the  bread on a wire rack for 15 minutes, then eat!

Carrot, Beet, Berry Juice


Ingredients:

3 beets
6-8 carrots
2 lemons
10-15 strawberries
About a 1/2 inch nugget of ginger

Directions:
Wash all ingredients. Cut the rind off the lemons. Cut the greens off the tops of the beets and chop the beets if they’re too big to fit in your juicer. Save the beet green tops for something else if you’d like. I don’t like juicing them. They’re really bitter. Juice according to manufacturer’s directions. Chill and enjoy.

Original Post with fantastic photos are “Make it Naked” http://makeitnaked.com/2013/07/16/carrot-beet-berry-juice/

Seeking Your Own Personal Tipping Point


I’ve been a seeker for most of my life now and I find wonderful things in many different places.  One of them is from The Daily Love; a daily blog by Mastin Kipp.  As part  of his blog, he provides quotes pertaining to his blog.  I find that these quotes are meaningful to me in a way that it puts me in a state of mind that I need for the day so I began making it my morning ritual to read his blog before I lifted my sleepy head off the pillow.  Sometimes, the message is selfishly mine and it reads as if it was written just for me but today I find the message is for everyone.

“You must constantly ask yourself these questions: Who am I around? What are they doing to me? What have they got me reading? What have they got me saying? Where do they have me going? What do they have me thinking? And most important, what do they have me becoming? Then ask yourself the big question: Is that okay? Your life does not get better by chance, it gets better by change.” - Jim Rohn, is an American entrepreneur, author and motivational speaker. His work has been influential in launching or furthering the careers of many others in the personal development industry, including Anthony Robbins, Mark Victor Hansen, Brian Tracy and Jack Canfield.

Our society has been on this spiral of selfishness and popularity for a long time.  Every network has reality shows or talent shows where bad behavior and celebrity seekers are glorified.  Having a visible “healthy balance” of entertainment and education is a struggle for anyone channel surfing.  We are, like the dog in UP, constantly distracted by the loud voices and drama rather than focusing on our own reality.  We constantly seek approval, affirmation, self-worth from others and rarely take a moment to take ownership of our own self worth and take responsibility for where we are right now. Why aren’t we paying attention to what we do, what we say, who we surround ourselves with and what situations we allow ourselves to be part of – these all make us who we are.

“The privilege of a lifetime is being who you are.” – Jack Canfield

I’m putting myself with people that are closer to a tipping point to turn away from these sensational influences.  I’m surrounding myself with the people that represent who I want to be, who I admire, who appreciate my journey as much as they enjoy their own.  It has made a difference; I can feel it.  I’m seeking other seekers who have found something I want to know more about.  I fill my ears and my eyes with things that make me a more caring, compassionate and knowledgeable person and hopefully someone who others want to spend time with because they feel valued and important when we’re together.

I’m a work in progress with a lot of mistakes to prove that I’m still learning.   I accept that part of me that fails as much as the part of me that accomplishes greatness.  Having the faith to keep trying and not accept failure sounds too much like a Hallmark card that I’d roll my eyes at but Mr. Einstein made a much more acceptable observation of his own attempts towards greatness.

“I have not failed, I have just found 10,000 ways that don’t work.” -Albert Einstein

No Scrum Master? Is it still Scrum?


What happens when the team gets all the training about Scrum, begins to kickoff the process but they don’t have a Scrum Master?

There are arguments (some legitimate and some not) to justify why Scrum will work without a Scrum Master. First, let me say that a Scrum Master is a role not a title so there really shouldn’t be any restrictions on who can fulfill the role.  Second, someone should take on the role and really dedicate time and energy to give the team the support they deserve. Check out Mike Cohn’s blog about Rotating the Scrum Master Role.

SAM_2306So what work does a Scrum Master do that now needs to be covered by someone else or the team as needed?  There have been a number of response to this question all over the internet and books so you’ve all probably heard that standard answers of remove impediments, champion the process, shields the team from outside interferences, etc. but I’d like to take it a step forward or maybe sideways.

Scrum Masters are champions for the team, their decisions, their delivery and even their failures. They are constantly looking at how the team operates from both an internal and external lens; one that the team members are very rarely able to use because they are in the thick of things and may not have the objective eye.  When a Scrum Master is able to identify things that are impeding the team and help them discover it rather than point a finger, jump up and down and demand they fix it, a bond is developed between the team members that gives them the confidence and trust that someone is looking out for them and is there to help them achieve their next level of expertise.

Eventually, a Scrum Master should find that the team needs their guidance less and less over time.  There are a few exceptions to that.  Teams that are dispersed  teams that gain new team members, teams that experience growth and then split (scaling scrum) will need more time and attention from their Scrum Master during these times.  They may have been experts at their process and become self managing but anytime the dynamic changes, there will be more to talk about, more to decide on and generally shakes the team for a time.

Another thing to note is that Scrum Masters are not Project Managers or even Tech Managers in their primary role.  There is a tendency to do this and it’s a dangerous thing because it can taint decisions and imply a level of power and control that should be absent from a Scrum Master.  Members of a scrum team should continue to rely on their managers and peers to improve their level of skill and professional growth whereas a Scrum Master may notice and relay recommendations about team members to their manager as a way of keeping the health of the team and growth of the team moving in a positive direction.

Hope this helps some of you!

Kiss Me I’m Irish’ish


For years, I’ve believed that I was Irish; mostly Irish, at least, with a little Scotch and English I was sure. But after using a DNA kit from a Groupon, I found out I’m actually Belgian, among many other European flavors. So despite this scientific evidence, my trip to Ireland is still on and I’m very much looking forward to meeting a few dashingly Irish men.

Here are the places that my single troop will be trying out:
Heritage Golf & Spa
Fitzpatrick Castle Hotel
Muckross Park Hotel & Spa
Dromoland Hotel & Country Estate
Faithlegg House Hotel & Golf Club

So after this very posh trip, I’ll have to check out the Belgian vacations for 2013!

Follow

Get every new post delivered to your Inbox.

Join 59 other followers

%d bloggers like this: