Thursday, April 6, 2017

Retrospectives



http://theprogrammingbutler.com/blog/archives/2016/12/05/ten-years-a-software-engineer/
This blog post is a result of reflecting on the past 10 years so I figured talking about my process for retrospectives would be fitting. Consistent retrospectives are probably the largest contributing factor to who I am today compared to 10 years ago.
Taking time every day, week, month, and year to analyze decisions I’ve made, actions I’ve taken, and the actual outcomes versus my expectations is how I learn what I need to change who I am into who I want to be.
A retrospective goes something like this:
  1. Set aside distraction free time.
  2. Think about something that has happened, whether it was something I did or that happened to me.
  3. Consider the situation, how I feel about it, what I can do better the next time I’m in that situation.
  4. Follow up homework if needed. This could be anything from repeating the situation so I can get better at handling to reading about the subject to learn how other people think about it.
Setting aside time is the hardest part for me, so I’m always keeping an eye out for these distractions:
  1. Social media
  2. Entertainment (TV/movies/podcasts/audiobooks)
  3. Speeding through life
Likewise these are opportunities for reflection that I’m constantly looking for:
  1. After personal devotions (or meditation)
  2. After receiving feedback (good or bad)
  3. After pretty much every conversation
  4. After reading, watching, or listening to something (entertainment made both lists!)
  5. The end of the day, week, month, and year
I like to write down the things I’ve learned through my retrospectives and I often use frameworks like Start/Stop/Keep or a SWOT analysis to help me organize my thoughts and find patterns.
http://blog.zuehlke.com/en/help-my-retrospectives-have-become-boring/
Retrospectives help a team to continually improve their processes so that they are happier and more productive. I think retros are definitely the first thing I would introduce at companies where agile development practices are not often used. Regularly scheduled retrospective discussions are a great first step to introducing change. Ask what’s going wrong and what suggestions people have, and then try to make a change

In our one hour long retrospectives, we usually silently write items on sticky notes with the following categories: “Things that went well”, “Things we could do better”, and “Things that puzzle us” (+, -, ?). 



Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts