Retrospection for Personal Growth (Continuous Introspection)

Retros for Your Life

It's easy for us to get caught up in life, and by the time we realize we are unhappy at a job or with a situation, it's too late to do anything. We get to feeling like we're unsuccessful or could've done more. What we forget to do is look within ourselves to find where we should be going or doing to improve ourselves, which ultimately will improve our situations.

I choose internal retrospectives over doing goal/vision boards for the main reason that vision boards can seem to limit you. I've never looked at my life and said this is where I will be in 5 or 10 years because if I had, I wouldn't be where I'm at now. I'd be blinded by what I thought was in front of me instead of what could be in front of me.

But, I digress. Below are some tips for how I do personal retrospectives to help me grow, that I hope you can find useful.

Choose the right frequency for you to retrospect (day, week, monthly...)

I found that every week is great for me. I have so much that happens in a week that it allows me enough to retrospect on, while being able to focus on something to improve for the next week.

Personal Experience: 

I used to do every two weeks, but unless I write down everything I do and how I feel about it everyday (which would defeat the weekly retrospective), then it was hard to remember those feelings. I also tried to retrospect everyday, but I found that it was harder for me to actually take the time to improve one thing in a day.

Look to improve yourself, not your job or your situation

It's easy to get caught up in the belief that it's the job that is making us unhappy or that our situation is to blame. Instead, we neglect to take a look at what we've done to allow us to be in a place where we don't want to be. Ask yourself the following as you retrospect:

• "What made me feel successful this week?"
• "How did I feel after [insert activity, meeting, session you did/attended]?"
• "What would have make me feel better/successful about such activity, meeting, session, etc.?"
• "How am I holding myself back from making such activity successful?"

Personal Experience

I have learned from retrospecting this way that in the past, it wasn't the job or the situation that made me unhappy. It was either the way I dealt with it or the inability to allow myself to move forward/past a fear. What is it that is holding you back because it's not the job or the situation you're in; we can get out of those.

Praise yourself!

This is the most important thing to do! It's easy to criticize ourselves, but it's harder to give praise for things we did good. We are our own worst critics I hear. So, drop that mentality and give yourself a pat on the back for the good things you did that week. What successes did you have; big and small?

Personal Experience

I grew up with nothing a lot of my adolescent life sleeping under overpasses, in children's homes, in halfway houses, or homeless shelters. Because of that, I always told myself I won't go back there. It's always been important to me to strive to be my best, which also meant being very hard on myself. What I ultimately learned was that I can be hard on myself while still making sure to recognize my small successes. By acknowledging my small successes, I was able to build on those and recognize what I did good so I can continue doing those things. Many small successes will equal to bigger successes.

Choose one item to adjust during your "life sprint" and take action

We can't fix it all! But, we can choose one item to work on between now and the next time we retrospect. Choose that one item that you can realistically do before your next retrospection and come up with the Acceptance Criteria and tasks that will help you reach your personal Definition of Done.

Personal Experience

For instance, I just recorded an agile podcast last week, which is still to be edited (shoutout to Rick Waters with http://agilechicagostyle.com/ for even considering me), and it was part of my retro this week. After retrospecting, it was the one thing I didn't feel I was successful at this past life sprint. I felt that I wasn't genuine as I was trying to say the "right" thing. Those that know me, know that I value genuineness and never want to be anything less. Now, I can't go back and redo the podcast since that's a lot of work for them. What I can do is determine why I felt that way and work this next life sprint to make sure I don't fall into that trap again. I'll spend this life sprint making sure that this need to say things right doesn't impede who I am in the future.

Most importantly, once you've focused on an action item and improved, keep it as part of your life. Changes shouldn't be temporary. Feel free to keep a backlog on the action items you chose to work on and improve.

Would love to hear your comments!

Remove the Impediment of Trust

Just Trust!

Somehow it has been ingrained in us, as a society, that we should be wary of trusting anyone.  Sure, that may sometimes make sense when we initially meet someone. However, why at work is it so hard to trust the people who make up the organization?

Lack of trust impedes the forward movement every organization should be striving for.

We take the time to pre-screen candidates, have them speak to multiple people, possibly take a test of some sort, and so on... Yet, we have the hardest time trusting the people we hire. The result is an organization that is built around micromanagement, dictatorship, and fear.

Lack of trust in our employees is a main factor in impeding progress when transforming to being Agile.  There's even an Agile principle that calls out,

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."



So, why is it so hard to trust the people we hire? Is it that we don't want to give up the "power" associated with micromanaging, being constantly involved in details we don't need to be involved in, being constantly "heard", and so on.
Is it that we are so insecure in our ability to hire the right people? Is it that we are scared of small failures, not realizing small failures are the only way to prevent large failures?

I ask these questions to challenge us to think why we cannot trust the people we work with to get the job done. From management's point of view, it would seem a simple thing to do.  Why not trust the people you hire?  You did hire them for a reason.

So, let's drop our egos and our need to be "right", and trust the people around us to have grandiose ideas, to think outside the box, to be innovative, and to be allowed to do their job.

As Simon Sinek put it,

"When we tell people to do their jobs, we get workers. When we trust people to get the job done, we get leaders."  

Value in Stand-ups

Tips for creating more value in your stand-ups

 **Yes, this topic is overdone and there's many blogs, articles, and the such about it, but I still find that teams struggle with getting value out of stand-ups**

Team answers the following 3 questions in order:

• What is impeding my work from being done?
• What did I complete since the last stand-up?
• What will I complete before the next stand-up?

Why: 

1. Puts emphasis on the team collaborating on getting rid of impediments which also affects the team's work

2. By stressing what was completed, it puts emphasis on the fact that things should be completed each day and allows for collaboration to help each other get tasks completed. 

*One way to verify tasks will be completed each day is to write tasks that are a day's length of time (this removes the need to put hours and stresses that tasks should be moved daily).

Centered around the task(s) being worked on

Why: Team focuses on the work that they assigned themselves. This is extremely useful for teams who take longer than the recommended 15 minutes.

A parking lot is used and reviewed daily

Why:  Parking lots are useful in that they are places to "park" conversations that do not necessarily apply to the 3 stand-up questions. Put items on a post-it note that need to be talked about after the stand-up and place who needs to be involved in the conversation. After everyone has participated in the stand-up, review the parking lot items that need everyone in the discussion, then talk about those that do not apply to everyone. People can stay and listen, but it is not mandatory. This helps with conversations that do not need everyone and impedes others from getting work done.

Noise/Impediments from the previous day are reviewed

Why: Noise/Impediments from the previous days can be reviewed before the stand-up. Have a section where these are placed on the board (the team's information radiator). By putting them in front of everyone, the team does not lose sight of them, and others, including the team, can see where the team may need assistance clearing impediments. If the same impediment is staying too long on the board (you can mark the date it was added), then how different types of impediments should be reviewed.

Transparency is the key to success!!!!

Using Agile Techniques in a Public High School!

In my childhood days, I (might have) pretended my stuffed animals were my students as I handed out tests, wrote out lesson plans, created team projects and so on. So, think of my excitement when I got the opportunity to teach high school kids how to use Agile techniques to run their team Biology projects.

In the beginning:

Teacher sees a need to have teams become better at

• organizing their work
• working better as a team
• determining if/when teams will be done by the deadline

It continues with:

An Agile Transformation Coach who loves to work with kids (and used to teach her stuffed animals…oh yeah, that's me)

It continues with:

The Teacher and Coach come together to determine if teaching Agile techniques will provide value by assessing the

• current situation and needs
• willingness of the students
• support of the principal

It's determined that YES, even a Biology High School class can benefit from Agile techniques!

Let's Start:

We have teams!

There are 2 classes with each class broken into 4 teams of 2-3.

We have a Product Owner!

The Teacher becomes responsible for the backlog: writing user stories, prioritizing, ordering, accepting stories, etc.

Students reviewing the stories the Product Owner created

We'll use a mixture of Agile Techniques!

• Scrum Activities (Product backlog refinement, Sprint planning, Daily Scrum, Sprint review, Sprint retrospective)
• Scrum Artifacts (Product increment, Product backlog, Sprint backlog)
• Scrum Roles (Development Team, Product Owner, ScrumMaster)
• Kanban Principles (Visualize work with cards, Limit Work in Process, Continuous Improvement)
• XP Rules (User Stories, Pair Programming, Spikes usage, XP Values: Simplicity, Communication, Feedback, Respect, Courage)

Now What:

See the flashtalk I presented at the Global ScrumGathering Shanghai where I presented about the what was done at this school: https://www.slideshare.net/secret/pYx2gSCyqhq9Lt

Empowering Offshore Contractors on an Agile Team

Agile isn't just about doing ceremonies, it's also about being agile by changing the way we think and work together. One of the main changes that agile techniques advocate is empowering the team to make decisions, plan and estimate their work, resolve conflict, and so on.

However, how can that apply to offshore contracting teams who are used to working in an environment where they are told what to do, and not asked how? Let's cover some ideas.

Set their goals to align with what agile stands for                                      

• Don't reprimand offshore team members for speaking up
• Write their contract with the same goals that the client and/or onsite employees have (as a team, everyone should be working toward the same goal)

Remember, no matter the location of the individuals, they all make up a team that should be working together.

Make the offshore team feel like they are just as important as onsite team members

• Don't only communicate to the onsite team members; always include everyone on the team, even if they are on the other side of the across the globe
• Ask for insight and questions from those who are not onsite
• Hold meetings where video conferencing is used
• When treating onsite team members, try to also arrange for the offshore team members to partake in something fun (for instance, in many of my meetings, I provide snacks. In that case, arrange for someone to expense snacks at the other location(s))

Allow for mistakes and continuous improvement             

• Give offshore team members the same freedom you give onsite team members
• Coach offshore team members in the same way coaching is given to onsite members
• Ask for and follow through on advice given in retrospectives

There is no doubt that a mature agile team works at their best, not simply because of the ceremonies, but when they are empowered and have support behind them to truly be Agile. Offshore contractors deserve to have that same work environment, and if they do, I can guarantee you that they will get just as much done as if you micro-managing them. The best part is that quality will rise. Team happiness for all the team members will raise (as everyone on the team communicates instead of onshore team members telling offshore team members what to do). Most importantly, because the entire team is empowered, the project will have a much better chance of being successful.

Summer Softball takes Teams through Storming

Intramural Softball Means it's Time to Take a Look at Our Teams

It's summer time again, and for me, that means one thing... Softball!

Each summer, the teams I play on get new team members as others move to different leagues or levels, and sometimes we even get new coaches. Or, I may be the one to move to a different team or league.

Through it all, there are important ways that softball teams should function through these changes that directly apply to how teams at work can function better.

1. Start Over at the Forming Stage When Changes to the Team Happen

With new team members, new coaches, or the creation of an entire new team, it is vital to the team health to start at the Forming stage of Tuckman's stages of group development. The goal is to have a team that is able to reach the Perform stage.

The issue with most teams is that they try to immediately Perform, skipping the Forming, Storming, and Norming stages that are so important.

"Why do we need to go through all the phases? We've all played softball before. Let's get out there and start Performing now!"

What is missing is that it takes time for people to understand their roles and purpose on the team, and get to know each other on a personal level (Forming Stage).

After the team is through the forming stage, the team should storm. The outcome of the Storming stage is a team that knows how to resolve their conflicts and is focused on the goal at hand (in my softball team, it is when we are able to work together to play the best we can).

Let's Norm together next. Now, the team wants to work together towards that one goal with mutual agreement and a strong sense of unity.

Unfortunately, management (just like softball coaches) want to disrupt teams, change them around, and expect them to immediately perform without the realization that there are steps that need to be taken in order for any team to get to the Performing stage. Or, it is easy to join a new team and expect that since they were in the Performing stage, you can join right in. In this case, it is important for the entire team to start at the Forming stage with you and go through all the stages.

The time needed for either of the above mentioned scenarios will vary based on the people's backgrounds and expectations, as well as the coach who is helping them get to the Performing stage.

2. Allow Teams to Self-Organize and See the Positive Results

One major thing that happens when a new softball coach comes onto a team, or when I join a new team with a directive coach is that he/she wants to assign you to a position. This is especially true in the more competitive leagues (but, it still happens in the leagues I play in, which is only recreational. I never said I was a great softball player...).

What happens when the coach says you are going to play infield, even though you despise infield because you know you're not good at it (or vice versa with any position)? You now have to play a position that you don't like, know you're not good at, and most likely will not excel at which will set you up for failure.

Think of the opposite scenario. The new coach comes in and asks people what position they like to play, and as a team, they decide who will play where. There may still be conflict between two people if both want the same position, but by now the team is into the Norming stage where team members work together towards their common goal. Maybe there's compromises to be made, or maybe someone decides to try a new position. Now it is the team who is empowered to make decisions, and thus in return, will want to work harder for the common team goal. Each individual now feels accountable to each other because they chose their own positions and now will want to show why they thought they were best to play in that position. When someone directs you to play somewhere you don't feel comfortable, the intrinsic need to show how well you can play in that designated position is not as strong. "Why should I care?"

The same goes with teams at work. A team that is self-organizing and empowered, feel a stronger sense of team, want to accomplish more, and feel more accountable for what they are delivering.

3. Domination is for those Teams who Stay Together

There is one team we play against that has somehow managed to keep the same players year after year (at least for the past 5 years I've been playing in one specific league).  You may think that this team has gotten bored of each other, or that they're not growing as players since they're around the same people. However, these assumptions are farthest from the truth. This team continues to dominate, and it's not because they're that much better players individually.  It's because they're that much better players as a team. Since they have been playing together for so long, they know how each other plays, they support one another, they listen to one another, they know how to quickly deal with conflict, and they grow because they trust each other and are allowed to grow as players.

They are in the Performing phase, and every season it shows.

Teams at work that stay together, even as they work on different projects, will show this same domination. A dedicated team has a rhythm, knows how to resolve conflict properly, feels accountable to each other, has better quality, and most importantly, they work as a team to get the product delivered.

Conclusion

Admittedly, my softball skills may not be the best, but one thing I do know is that I play so much better when I am on a team that doesn't force its players to rush into the Performing Stage, allows for self-organization, and stays together as the seasons go by. This is the team I want to be on, and stay on!

(Oh, and I don't mind being on a team that knows what fun is; see the below comic...)

   

Agile, Art, and the Combination with other Disciplines

Combining Art in a Story with Engineering and Test??

In a traditional development company, there are engineers and testers with other parties (such as Architects, UX, etc.) that can be a part of the team or be used as SMEs. 

Now, imagine a creative project, like a video game, that has artists who also contribute to the product. It would be easy to create Art as a silo and have them create the look of a game, hand it off to engineering to implement the art, then hand it off to testing to test it. 

Artists create, polish, and polish some more. So, how do you combine art with the other team members into one story if there is constant polishing that needs to be done? And, why is it important to include art in the team?

Agile builds products in an Iterative, Incremental, and Concurrent Fashion; so does Art

Art can and should be iterative, incremental, and concurrent with engineering and test. Stories can be broken down iteratively by creating a skeleton, then a prototype version, then a final version. Too many or too few passes? Break it down to what makes sense for your game, as long as the user story still delivers valuable functionality and is sized appropriately within an iteration's time frame.

Some user stories will not have art included, and that is A-OK

There are times when the story deals with backend functionality, and art is not included; it's okay. The goal is to include art at times where engineering and test can also be combined to deliver a valuable piece of functionality.

Write titles of User Stories to reflect who is included

I coach that when Art is included in the User Story, the word, "Create" is used. If engineering is included, use the word, "Implement". A story that reads, "Create and Implement the LAP Attracts" tells me that art and engineering are both involved in this story (testing should always be involved).

Combining disciplines into one user story provides Collaboration, Accountability, and a Sense of Urgency

By combining disciplines into one user story, people start working as a team and collaborate more. Everyone knows what is going on at all times in the project. Handoffs are minimized. People feel accountable to their team members, and thus work to get more work done.

This is a high level finding on combining art with other disciplines. If you'd like to know more on how to do this at your organization, leave a comment, and I'd love to get your thoughts and/or provide feedback on struggles I deal with as well.