Category: Learning

Reflecting on the Tech Lead Skills for Developers Course in Brazil

Earlier this month, I visited our Brazilian offices to run some internal training, called Tech Lead Skills for Developers. The trip felt a bit full circle as I had visited Brazil several years ago for the same reason and needed to develop the material. Instead of the handful of people I coached, I ran two full classes with a mix of people currently playing the Tech Lead role and those who might be stepping into the role.

The course I run uses a mix of training styles (short presentations, lots of time for story sharing, discussions, interactive exercises, brainstorm and lots of time for question time). In general I’m really happy with the overall result with a good balance of covering lots of material, making it personalised and relevant, and giving people an opportunity to practice, gather feedback and have a go at applying it. The feedback for the course was quite consistent with those in the past, telling me that the balance was just about right.

One of the great opportunities I have had, running this course in different places is seeing some of the cultural implications and differences between continents. I learned, for example, that Brazil (traditionally) has a higher Power Distance Index (PDI on the Hofstede Dimensions), which means that, at least compared to the United Kingdom or America, authority is viewed a bit more strictly. In practice, this meant that a lot of the developers, working in more collaborative environments seemed to almost take an extreme anti-leadership position, where any mark of authority was viewed poorly, or that there was a reluctance to be seen taking on a title.

I also discovered that the word delegate in Portuguese had a negative association. As we discussed how effective leaders scale themselves through effective delegation, it was almost interpreted as a manager telling people to take care of the bad tasks – which, of course, wasn’t the intent! In the end, I tried to express effective delegation as a way of ensuring that all important responsibilities were being taken care of.

I am running this course again later this year in both Thailand and Singapore and look forward to seeing some more of the cultural differences that emerge during the discussions.

We can do better

I’m proud that many people are actively addresing diversity issues. Research shows that diversity leads to better problem solving and often, more creative solutions. Unfortunately the results of history lead us to where we are today, but we can always do better. I’m proud to be part of ThoughtWorks, where we are also trying to do our part to address diversity issues, and our work was recently recognised as a great company for Women in Tech. And yes, I do realise that diversity goes beyond just gender diversity.

As a fairly regular conference speaker this year, I have been disappointed by some of the actions of both conference organisers and speakers that have been, in my opinion, rather unhelpful.

At a conference speaker’s dinner earlier in the year, the topic of diversity came up where someone calculated that only 4 out of almost 60 speakers were women. I was truly disappointed when one of the conference organisers responded with, “That’s just the industry ratio isn’t it? It’s just too hard to find women speakers.” Of course not all conference organisers have this attitude, such as The Lead Dev conference which ended up with 50% women:men speaker ratio or like Flowcon which achieved a >40% ratio women:men as well. Jez Humble writes about his experiences achieving this goal (recommended reading for conference organisers).

At another conference, I saw a slide tweeted from a talk that looked like this below (Note: I’ve found the original and applied my own label to the slide)

Bad slide of stereotypes

My first thoughts went something like: “Why do all the developers look like men and why do all the testers look like women?” I was glad to see some other tweets mention this, which I’m hoping that the speaker saw.

We all have responsibilities when we speak

I believe that if you hold talks at a conference, you have a responsibility to stop reinforcing stereotypes, and start doing something, even if it’s a little thing like removing gendered stereotypes. Be aware of the imagery that you use, and avoid words that might reinforce minority groups feeling even more like a minority in tech. If you don’t know where to start, think about taking some training about what the key issues are.

What you can do if you’re a speaker

As a speaker you can:

  • Review your slides for stereotypes and see if you can use alternative imagery to get your message across.
  • Find someone who can give you feedback on words you say (I am still trying to train myself out of using the “guys” word when I mean people and everyone).
  • Give your time (mentoring, advice and encouragement) to people who stand out as different so they can act like role models in the future.
  • Give feedback to conferences and other speakers when you see something that’s inappropriate. More likely than not, people are more unaware of what other message people might see/hear, and a good presenter will care about getting their real message across more effectively.

What to do if you’re a conference organiser

I’ve seen many great practices that conferences use to support diversity. These include:

One thing that I have yet to experience, but would like as a speaker is a review service where I could send some version of slides/notes (there is always tweaking) and get some feedback about whether the imagery/words or message I intend to use might make the minorities feel even more like a minority.

Reviewing the latest blinks August 28

Brain Rules: 12 Principles for Surviving and Thriving at Work, Home and School by John Medina – A description of rules with how our brain works and how we learn. Our visual senses tend to trump our sense of smell. We need sleep to restore our energy and to help us concentrate. Spaced repetition is important, but assigning meaning to new words and concepts are also important to learning. Since I’m fascinated with learning and how the brain works, I’ll add this to my reading list.

Getting Things Done: The Art of Stress-free Productivity by
David Allen
– Although I never read the book, I felt like I follow a similarly described organisation system. The GTD method is almost like a cult, but requires a lot of discipline for it. Unlike keeping a single list of things to do, they have a systemised variant for keeping long-lived projects and ways of managing tasks to help you focus on getting through actions. Probably a good book if you want to focus more on breaking things done into smaller steps.

The Checklist Manifesto: How to Get Things Right by Atul Gawande – With lots of examples from the healthcare industry, a reminder that useful checklists can help us avoid making simple mistakes. For me, the idea of standardised work (a lean concept) already covers this. I agree with this idea in principle, but I’m not so sure the book covers the negative side effects of checklists as well (people getting lazy) or alternatives to checklist (automation and designing against error/failure demand to be begin with).

Connect: The Secret LinkedIn Playbook to Generate Leads, Build Relationships, and Dramatically Increase Your Sales by Josh Turner – Either a terrible summary or a terrible book, this blink gave advice about how to use LinkedIn to build a community. Although the advice isn’t terrible, it’s not terribly new, and I didn’t really find any insights. I definitely won’t be getting a copy of this book.

Start With Why: How Great Leaders Inspire Everyone To Take Action by Simon Sinek – A nice summary of leadership styles and rather than focusing on how something should be done, and the what, is starting with the why. I liked the explanation of the Golden Circle with three concentric circles draw within each other, with the Why being the starting point that leads to the How that ends in the What. It’s a good reminder about effective delegation and how powerful the Why motivator can be. I’ve added this book to my reading list to.

Panel for Tech Leads: “Navigating Difficult Situations”

I recently moderated a panel in our London ThoughtWorks office aimed at developers leading technnical teams as a follow up from the Lead Developer conference.

Leading development teams can be a challenging prospect. Balancing the needs of the business with those of your team requires a number of different skills and these situations are often very difficult to prepare for.

This panel session will provide a platform for a group of tech leads to come together and share their experiences, insights and advice around the topic of managing conflict and overcoming difficult moments within your teams.

Our panelists are all at various stages of their own leadership journeys and will be offering a range of perspectives and viewpoints to help you on your way.

Tech Lead Panellists

The panelists shared their experiences around situations like:

  • Having a tough conversation with a team member or customer;
  • Sharing how they have dealt with overtime (weekends, later work);
  • How they resolved a technical disagreement within a team; and
  • Handling a particularly aggressive person, or being aggressively threatened;

The audience also threw in a few questions like:

  • Dealing with office politics;
  • Finding access to key influencers/stakeholders;
  • Where you draw the line with a person on a team; and
  • Dealing with a technical stakeholder who is too involved, because they seem to have too much time;

We also had some great sound bites in relation to the topics being discussed.

To deal with angry people:

Be the adult – Laura Paterson

or just:

Let them vent – Jon Barber

Managing stakeholders is hard, and you sometimes need to take a stance:

It’s easy to say no – Priya Samuel

People in teams need feedback to both strengthen confidence and improve effectiveness. However:

Frank feedback is really hard. Give the person a chance. – Mike Gardiner

Lastly when thinking about people and teams:

Have empathy. Pairing is scary & exhausting – Kornelis (Korny) Sietsma

I’d like to thank Amy Lynch for organising the panel, Laura Jenkins and Adriana Katrandzhieva for helping with the logistics, all the panelists who contributed their experiences and shared their stories (Priya Samuel, Kornelis (Korny) Sietsma, Mike Gardiner, Laura Paterson and Jon Barber) and all the people who turned up for the evening.

Workshop outputs from “How Architects nurture Technical Excellence”

Workshop background

Earlier this week, I ran a workshop at the first ever Agile Europe conference organised by the Agile Alliance in Gdansk, Poland. As described in the abstract:

Architects and architecture are often considered dirty words in the agile world, yet the Architect role and architectural thinking are essential amplifiers for technical excellence, which enable software agility.

In this workshop, we will explore different ways that teams achieve Technical Excellence and explore different tools and approaches that Architects use to successfully influence Technical Excellence.

During the workshop, the participants explored:

  • What are some examples of Technical Excellence?
  • How does one define Technical Excellence?
  • Explored the role of the Architect in agile environments
  • Understood the broader responsibilities of an Architect working in agile environments
  • Focused on specific behaviours and responsibilities of an Architect that help/hinder Technical Excellence

What follows are the results of the collective experiences of the workshop participants during Agile Europe 2016.

Examples of Technical Excellence

  • A set of coding conventions & standards that are shared, discussed, abided by by the team
  • Introducing more formal code reviews worked wonders, code quality enabled by code reviews, user testing and coding standards, Peer code review process
  • Software modeling with UML
  • First time we’ve used in memory search index to solve severe performance RDBMS problems
  • If scrum is used, a good technical Definition of Done (DoD) is visible and applied
  • Shared APIs for internal and external consumers
  • Introducing ‘no estimates’ approach and delivering software/features well enough to be allowed to continue with it
  • Microservice architecture with docker
  • Team spirit
  • Listening to others (not! my idea is the best)
  • Keeping a project/software alive and used in prod through excellence customer support (most exclusively)
  • “The art must not suffer” as attitude in the team
  • Thinking wide!
  • Dev engineering into requirements
  • Problems clearly and explicitly reported (e.g. Toyota)
  • Using most recent libraries and ability to upgrade
  • Right tools for the job
  • Frequent availability of “something” working (like a daily build that may be incomplete functionality, but in principle works)
  • Specification by example
  • Setting up technical environment for new software, new team members quickly introduced to the project (clean, straightforward set up)
  • Conscious pursuit of Technical Excellence by the team through this being discussed in retros and elsewhere
  • Driver for a device executed on the device
  • Continuous learning (discover new tech), methodologies
  • Automatic deployment, DevOps tools use CI, CD, UT with TDD methodology, First implementation of CD in 2011 in the project I worked on, Multi-layered CI grid, CI env for all services, Continuous Integration and Delivery (daily use tools to support them), Continuous Integration, great CI
  • Measure quality (static analysis, test coverage), static code analysis integrated into IDE
  • Fail fast approach, feedback loop
  • Shader stats (statistical approach to compiler efficiency)
  • Lock less multithreaded scheduling algorithm
  • Heuristic algorithm for multi threaded attributes deduction
  • It is easy to extend the product without modifying everything, modularity of codebase
  • Learn how to use something complex (in depth)
  • Reuse over reinvention/reengineering
  • Ability to predict how a given solution will work/consequences
  • Good work with small effort (efficiency)
  • Simple design over all in one, it’s simple to understand what that technology really does, architecture of the product fits on whiteboard 🙂
  • Systems’ architecture matches team/org structure
  • Self organisation
  • Ideally separated tests, Automated performance testing, automatic front end functional testing with selenium, unit testing done for the first time 10 years ago, constructing new performance testing cases takes minutes, after refactoring unit tests are passing (majority of them – hopefully all!)
  • Constant curiosity for new technologies/approaches
  • Good knowledge of software patterns (when to use and when not)
  • Learn from mistakes

Examples of Technical Excellence

Definition of Technical Excellence

  • (Technical) Excellence is an attitude to be better than yesterday
  • Technical Excellence is the holy grail that inspires teams to stay on the path of continued improvement
  • Technical Excellence is a process that continuously improves product design and the development team. Examples: Automation, knowledge sharing, culture. Synonyms: Dream
  • Technical Excellence is an ability to consciously apply tools and practices to solve and continuously improve over complex problems in a sustainable way and within constraints (e.g. time and money). Examples: Continuous Delivery

Definition

Activities of an architect

  • Explains decisions
  • Able to choose the right solution amongst many possibilities (awareness of consequences and limitations)
  • Being able to justify technical decisions made
  • Thinking (find time to think about the product, structure, technologies used, etc)
  • Helps resolve interdependencies, helps to identify/minimise external noise (i.e. technical dependency change with negative impact), co-ordination of integration with other teams working on the same project
  • Start and moderate discussions on design, longer term consequences of decisions, etc
  • Requirements definition, making sure ‘nothing’ is omitted during analysis/design
  • Questions decisions to encourage thinking about wider picture amongst developers, asks questions (non obvious especially), Asking difficult questions about work being done
  • Listens to others
  • Encourage people to bring ideas, encourage idea sharing
  • Setup backlog for achieving technical excellence
  • Challenge old decisions
  • Business decision support (IT, 3rd party)
  • Make sure we don’t bite more than we can chew – incrementally/iterative
  • Ensure architecture is visible, understood and accessible to the team, keep the technical cohesion, helps team consider the bigger picture and interdependencies, helps team define the system and diagram it
  • Detailed knowledge of technologies/protocols used
  • Forward thinking
  • Proposes solutions to complex problems
  • Diagrams/presentations
  • Wide view of situation/projects, look what other teams are building for things to reuse or interface to
  • “Main” test scenarios definition
  • Definition of components structure and interactions
  • Guard technical vision (dialogue with stakeholders)
  • Focus on project goal
  • API specification
  • Verification of current design vs planned use
  • Ad hoc just in time consulting to feature teams when things get complex
  • Teaching teams, sharing technical knowledge (and expertise) with the team
  • Coaches team. Gets buy-in from the team for change they are about to trigger, coaches dev team
  • Identifies technical skillset gaps in the team
  • Pro-active thinking
  • Gaps identification
  • Mitigates the risks
  • Out of box ideas
  • Research for solution, helps team identify areas for experimenting, exploring new territories
  • Creating proof of concept (POC)
  • Learns new things, research and try new tools, ideas, technologies, etc
  • Gains an in-depth understanding of a system before attempting to change it
  • Reviews teams’ system design, performs code reviews and coding standard support, reviews code

Architect Activities

Architect Activities

Behaviours that support Technical Excellence

Active

  • Gives team rapid and timely feedback
  • Patiently explaining all the tiny details responding to simple questions
  • Be there whenever needed
  • be the safety net whenever devs need you
  • Set communication for knowledge sharing
  • Explain the reasons behind the design
  • Raising the visibility of good developers
  • Do pair programming, works with the team
  • Explain technical excellence value for business
  • Encourage team to think and work towards Technical Excellence
  • Growing people, mentoring developers to improve tech skills, training the team, educate actively – organise coding dojos, etc
  • Set up backlog for achieving Technical Excellence
  • Raising the team spirit and motivation
  • Waking up with 3am to connect with a team on a daily basis (for a distributed team)
  • Discussing discovered problems with the team
  • Sat down with the team to teach and record architecture training for future use
  • Keeping an eye on new things on the market and bringing them to the team
  • Staying current in technologies, tools, concepts, etc.
  • Being a visible role model in terms of pursuing Technical Excellence
  • Encourages experimentation
  • Support team in collaboration with other teams
  • Helps team identify blindspots
  • Active Encouragement

    Passive

  • ability to change contexts between projects
  • Lets the team make decisions
  • Take a step back and make room for technical advancements of the whole team
  • Not doing stuff from actively discourage column
  • Team makes decisions
  • Passive Encouragement

    Behaviours that discourage Technical Excellence

    Active

  • Dictatorship, have to do it my way, will to control (every small detail)
  • Blaming and shaming
  • Making arbitrary decisions, especially without explaining the reasoning behind it
  • Rejecting too complex C++ code
  • Using ambiguous, complex, uncertain English vocabulary
  • Shutting down emergent ideas from the team
  • Discouraging ideas “I couldn’t care less about your sophisticated C++ SPT initialisation”
  • Created ugly prototype for a demo and forced team to clean up afterwards
  • Imposing BDUF (Big Design Up Front) over the development team
  • Created non-viable design (i.e. could not be implemented with current constraints)
  • Enforcing old known technologies, etc out of inertia/ignorance, sticking to the “old ways”
  • Active Discouragement

    Passive

  • Doing too many activities to follow through – not focused on any (and no time to encourage Technical Excellence)
  • Invited but never attended meetings
  • “I don’t meet with the Architect”
  • Software Architect with poor development skills
  • Not working with the team
  • Leaving obsolete information in documentation
  • Getting involved in design only if prompted
  • “I don’t know how, so I won’t define it”
  • Passive Discouragement

    Stories

  • Developers supporting software (getting email feedback)
  • Anti-Story: “Let’s *NOT* sit together” – Person leaving showed them how it was done
  • “Let’s sit down together” (solving a memory leak problem)
  • Group Problem (Security problem)
  • Stories

    If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

    12 years, 12 lessons working at ThoughtWorks

    I’ve been at ThoughtWorks for 12 years. Who would have imagined? Instead of writing about my reflections on the past year, I thought I would do something different and post twelve key learnings and observations looking back over my career. I have chosen twelve, not because there are only twelve, but because it fits well with the theme of twelve years.

    1. Tools don’t replace thinking

    In my years of consulting and working with many organisations and managers I have seen a common approach to fixing problems, where a manager believes a tool will “solve” the given problem. This can be successful where a problem area is very well understood, unlikely to have many exceptions and everyone acts in the same manner. Unfortunately this doesn’t reflect many real-world problems.

    Too many times I have witnessed managers implement an organisational-wide tool that is locked down to a specific way of working. The tool fails to solve the problem, and actually blocks real work from getting done. Tools should be there to aid, to help prevent known errors and to help us remember repeated tasks, not to replace thinking.

    2. Agile “transformations” rarely work unless the management group understand its values

    Many managers make the mistake that only the people close to the work need to “adopt agile” when other parts of the organisation need to change at the same time. Co-ordinating this in enterprises takes a lot of time and skill with a focus on synchronising change at different levels of the organisation.

    Organisations who adopt agile in only one part of their organisation face a real threat. As the old saying goes, “Change your organisation, or change your organisation.”

    3. Safety is required for learning

    Learning necessitates the making of mistakes. In the Dreyfus model, this means that particularly people in an Advanced Beginner stage, need to make mistakes in order to learn. People won’t risk making mistakes if they feel they will do a bad job, lose respect from their colleagues or potentially hurt other people in that process.

    As a person passionate about teaching and learning, I find ways to create a safe space for people to fail, and in doing so, make the essential mistakes they need to properly learn.

    4. Everyone can be a leader

    I have written about this topic before, but it is such an important observation. I see a common mental model trap where people feel the need to be given the role of a leader, in order to act like a leader. People can demonstrate acts of leadership regardless of their title and can do so in many different ways, simply by taking action on something without the explicit expectation or request for it.

    5. Architects make the best decisions when they code

    In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding. Spending time with the code helps build trust, respect and a current understanding of the system. Making architectural decisions without regard for the constraints of the current system are often bad decisions.

    6. Courage is required for change

    I miss people talking about the XP values, one of which includes Courage. Courage is required for acts of leadership, taking on the risk to fail and the risk/reward of attempting something new. Where there is no risk, there is often little reward.

    7. Congruence is essential for building trust

    Beware of the old age maxim, “Do as I say, not as a I do.” In reality, regardless of what you say, people will remember how you act, first and foremost. Acting congruently is making sure that your actions follow your words. Acting incongruently destroys trust. Saying “no” or “not now” is better than promising to do something by a certain time, only to not deliver it.

    8. Successful pair programming correlates with good collaboration

    Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict.

    I consider (navigable) conflict a healthy sign of collaborative teams. Deferring feedback, such as is the case with code reviews on long-lived branches tends to lead to more resentment because it is delivered so late.

    9. Multi model thinking leads to more powerful outcomes

    One of my favourite subjects at University, was Introduction to Philosophy where we spent each week in the semester studying a different philosopher. Over the course of my career, I have come to appreciate the value of diversity, and to see a problem through multiple lenses. Systems thinking also recognises that facts can be interpreted in different ways, leading to newer ideas or solutions which may be combined for greater effect.

    10. Appreciate that everyone has different strengths

    Everyone is unique, each with their own set of strengths and weaknesses. Although we tend to seek like-minded people, teams are better off with a broader set of strengths. A strength in one area may be a weakness in a certain context, and teams are stronger when they have a broader set of strengths. Differences in strengths can lead to conflict but healthy teams appreciate the differences that people bring, rather than resent people for them.

    11. Learning is a lifelong skill

    The world constantly changes around us and there are always opportunities to learn some new skill, technique or tool. We can even learn to get better at learning and there are many books like Apprenticeship Patterns and The First 20 Hours which can give you techniques to get better at this.

    12. Happiness occurs through positive impact

    The well known book, Drive, talks about how people develop happiness through working towards a certain purpose. In my experience, this is often about helping people find ways to have a positive impact on others, which is why our Pillar 2 (Champion software excellence and revolutionize the IT industry) and Pillar 3 (Advocate passionately for social and economic justice) values are really important for us.

    Conclusion

    The twelve points above are not the only lessons I have learned in my time at ThoughtWorks but they are some of the more key learnings that help me help our clients.

    Making Change Stick

    A gym instructor told me yesterday that it was the day that most people statistically give up their new year’s resolution. Whether or not it is true, it got me thinking about what works when changing behaviours, whether individually or in an organizational context. What follows are some of my favourite approaches to making change stick.

    1. Keep it small

    In my experience, the bigger the change is, the more likely it is to fail because old habits come back, or the change hits too many barriers. A more significant change means less chance of success because it requires more time, energy and motivation to accomplish – all of which can easily run out.

    Five years ago I was unsure about whether I could be a full-time vegetarian. Rather than commit to being full-time vegetarian, I kept it small by deciding to trial it for an entire month. In this time, I made myself experience as many activities I enjoy in the trial period (eating out, traveling) to work out being full-time would not suit me. In the end, I decided a 2-day per week vegetarian habit would work instead.

    If you want to make a change, find smaller steps towards the end goal.

    2. Build on an existing habit

    I have a friend who gave up smoking but took up a running habit instead. After talking to him, I realised a lot of his success was described in the book, “The Power of Habit.” In this book, they describe how we often build responses to stimulus as rewards, which eventually becomes a habit. Our first approach to change is to simply stop the response but habits make that difficult because they are automatic.

    The book explains that stopping the habitual response hard. However replacing the response with a different response can be a lot easier.

    3. Keep it social

    One of the many reasons fitness websites like Runkeeper want to connect you with your friends it that social pressure and acknowledgement from family and friends is a really powerful mechanism for instituting change. Websites like Runkeeper fail because they treat every connection the same, even though we have different types of relationships with people. Acts such as making a commitment to a group of close friends, or training regularly with the same group of people is great motivation to maintain a new change.

    I saw this most recently when a bunch of friends and I signed up for a Tough Mudder. Before the event, a friend of mine didn’t regularly train. They knew the event would be a challenge so hired a personal trainer and went regularly several times a week. In the course of six months until the event, they built up the fitness, strength and skills required by Tough Mudder and finished it brilliantly.

    4. Visualise the end state

    One of the wonders of our human mind is our ability to influence the future simply through belief (or what’s commonly known as the Placebo Effect). In organisations and in personal coaching, I find the Futurespectives activities of the most powerful practices because it helps people imagine what the future state could be like.

    All too often people fail at change because they focus too much on what is blocking them rather than focusing on what they can do to move towards this end state. An exercise I know used by a few friends is the Letter from the Future to visualise their desired end states.

    5. Celebrate, celebrate, celebrate

    With my experiences using appreciative inquiry, I have found that celebrating the small achievements for what is working is often a more powerful motivating factor than focusing on what didn’t work. It leads into a positively reinforcing loop that can establish new habits and make lasting change as pictured in the diagram below.

    Cycle of celebration improving motivation

    Conclusion

    There are many other opportunities to make change stick I find that these five steps are the techniques and practices I draw upon the most. Books I have found useful on this topic include

    What do you do to make change stick?

    Running a Personal Retrospective for 2015

    It’s the end of yet another year and a great time to reflect and put your Personal Retrospective hats on. I mention using Personal Retrospectives in my book, “The Retrospective Handbook: A guide for agile teams” because I find them powerful tools to celebrate the past year and to establish new goals for a new year.

    This year, instead of simply stepping through questions on paper or on the computer, I decided to use sticky notes and activities I would use with a larger group. In order to keep flow, I wanted to prepare appropriately. This meant I:

    1. Made a plan for the exercises I wanted to run;
    2. Prepared the activities in advance so I could focus on gathering data/generating insights and reflecting instead of thinking about the process;
    3. Had a set of questions prepared in case I got stuck;
    4. Put on some background music – a quick search on YouTube found this spiritual landscape music; and
    5. Had water and coffee ready so I didn’t need to leave the room.

    Here are the activities I used this year and that you might find useful for your own Personal Retrospective.

    A year in tweets

    Using very small stickies to simulate the 140 character limit (I’m guessing I had ~50) trying to generate a number of small tweets about how I felt about 2015.

    Personal Retrospective Activity: A year in review
    Personal Retrospective Activity: A year in review

    Generating a timeline of events

    I find the timeline a very powerful way to reflect on the year’s events, and to celebrate their significance. I first brainstormed memorable events before I attempted to nest them into the timeline. I the checked my personal and work calendars, realising that the human memory (or maybe it’s just mine!) is quite bad at remembering the order of events.

    I found this blog, my twitter stream and my slideshare page useful sources to remember other significant events.

    Personal Retrospective Activity: Timeline
    Personal Retrospective Activity: Timeline

    Constructing the timeline took the most time of all exercises. Partly because there were lots of significant events for me, and I wanted to appreciate how much had occurred in this year.

    4 L’s (Liked, Loved, Lacked, Longed For

    I don’t normally use the 4 L’s exercise but figured I would give it a go. It seemed to work well in terms of framing insights but I found I needed to reflect deeper in some of the initial ideas I wrote up. Having an independent coach/facilitator would have been useful but I had to play this role myself.

    Personal Retrospective Activity: 4Ls
    Personal Retrospective Activity: 4Ls

    Goals for 2016

    After looking back at the timeline, and reflecting on how the events made me feel and what impact they had, I brainstormed some goals for this year. My focus for this first round was to generate all possible goals I might have, even though these long term goals would not meet the SMART criteria.

    Personal Retrospective Activity: Goals (Before Actions)
    Personal Retrospective Activity: Goals (Before Actions)

    In the second round, I went through each of the different goals, generating some concrete next steps to move me towards each of those goals. My intention is to revisit the goals throughout the year and to take other actions to progress them further. The orange-coloured stickies in the picture below represet these next steps linked to the relevant goals (in green).

    Personal Retrospective Activity: Goals (Next Step Actions)
    Personal Retrospective Activity: Goals (Next Step Actions)

    I also spent the time digitising the outputs into a A3 Personal Retrospective report and have made the template available here if you want to print it instead.

    Have you set aside time to reflect on 2015? How did you run your Personal Retrospective? Leave a comment and let me know.

    If you liked this post, you might be interested in The Retrospective Handbook: A guide for agile teams, also available in print.

    Holding a Tech Lead course in Sydney

    With a one-time only opportunity this year, I am running a course for Architects and Tech Leads on 22-23 October at the ThoughtWorks Sydney offices. After interviewing over 35 Tech Leads for the Talking with Tech Leads book, I recognised there is a gap about teaching developers the special leadership skills a successful Architect and Tech Lead demands. The class size is really limited, so reserve yourself a place while you can.

    Tech Lead

    In this very hands-on and discussion-based course, participants will cover a wide breadth of topics including understanding what a Tech Lead is responsible for, the technical aspects a developers rarely experiences and is not accountable for, and the difficult people-oriented side to the role including influencing, relationship building and tools for better understanding your team.

    This is a two-day course that will quickly pay back dividends in accelerating you on your path or further developing your Tech Lead skills as developers. Register here on eventbrite for the course 22-23 October.

    5 Tips for Accelerated Learning

    I spent all of last year in Berlin, where I focused on learning the German language. After years learning different programming languages like Java, C#, Javascript and Ruby (not to mention all the tools, frameworks and libraries) and several years training and teaching I figured I could “eat my own dog food” and apply what I learnt about learning to a real language.

    Enter to Learn stone sign
    Stone sign: Enter to Learn. Image take from flikr under the Creative Commons licence.

    Since that year, I talked to numerous people impressed that I can speak fluent German after living in Berlin. They often ask me, how did I found my experience. This post is a good summary of what I found myself repeating. Firstly, if you really, really want to learn German, Berlin is probably not the best place since there are so many foreigners living there and the level of spoken English is ridiculously high. You can easily fall into hanging out with the English-speaking crowd, enjoy the city, and fail to pick up more than rudimentary German.

    Although I have very specific tips for learning the German language, this is more focused on what helped me learn the most that I think applies to any subject.

    1. Find different teachers

    At the start of the year, I spent the first three months doing an immersive language course at the Goethe Institute. Over the two classes, I experienced four different teachers, each with their own style and emphasis on what is important to learn. Although I wished that I had spent less time with one of the teachers, I found their point of view was sometimes useful. Each teacher focused on different aspects and it made my learning all that richer.

    Over the rest of the year, I found other avenues to teach me, guide me and give the feedback I needed to grow. If I had stuck with a single teacher, I would have missed out on a number of other valuable perspectives.

    2. Have a goal, and keep focused on it

    Unlike many European people, I was never bilingual as a child. Moving to England from Australia, I came to appreciate how useful a second language was by meeting many other bilingual people. Although I learned Japanese in school, I believe it is more important to have the ability to use it.As they say:

    Use it, or lose it.

    A whole year to learn a language was a once in a lifetime opportunity and my goal was to be fluent by the end of the year. I had a whole bunch of other personal reasons to learn German, but figured many things came into alignment and I would make the most of this opportunity.

    I reminded myself throughout the year about my goal, and why it was important to me, and it helped me keep focus on the learning. It helped me in particular when the going got tough, and it will get tough!

    3. Celebrate progress

    After a year passed by, I met with some of my colleagues again who were impressed that I could now speak with them fluently in their native tongue. Although it’s easy to celebrate that final result, there were many times along the way that I wanted to give up because it was hard, and I felt frustrated that I felt like I wasn’t learning as fast I wanted to.

    I was sharing a flat with a German, who knew that I was wanting to speak fluent German. Although he could speak English very well, he spoke only to me in German even if it would have been easier for him to communicate in English. I remember coming home one day, exasperatedly asking, “Can we just speak in English?!” His answer, “Nein!” (No, in German).

    Although there were bad days, there were also good days and I made sure to sit back and acknowledge these small milestones, such as watching my first film in German with subtitles (and understanding most of it), completing my first German novel, and going to the Town Hall to register myself without speaking a word of English!

    Each small step moves you towards your final goal, and celebrating progress will help you overcome the learning hurdles you experience along the way.

    4. Vary your learning activities

    One problem with a long-term learning goal, is that you will get bored and distracted. At the start of my year, I was naturally doing a lot of grammatical textbook exercises which was useful for the classroom. However I couldn’t see myself continuing to do just these exercises for the rest of the year. I wanted other ways to learn but would help me keep engaged. Therefore I combined learning German with other activities that I enjoyed, such as meeting with people (the German Stammtisch the language school organised was a good one), watching movies and reading books I liked in German (thanks library!), meeting with a tandem partner, and listening to the radio.

    A friend gave me the book, “111 Orte in Berlin, die man gesehen haben muss” which roughly translates to, “111 must see places in Berlin.” The book has two pages for each place, one with a short description and the other with a picture and was perfect for dipping in and out. I could read about a place I wanted to visit, and because I lived in Berlin, could go and see what it was talking about. At the same time, it helped me deepen my vocabulary and help me experience the unique experiences Berlin had of offer.

    Later in the year, I spent some time traveling around in Germany, where I did a number of tours in German. Each of these experiences kept the learning alive for me and I never grew bored about “learning German” because I was doing it at the same time as I was doing other activities I was enjoying.

    5. Accept you’ll never be perfect

    Early on in my career, I discovered the idea of the Beginner’s Mind (Shoshin). For me, part of this accepts that I do not, and cannot know everything and that means there are new things to learn. In learning German, I found that my vocabulary will never be as rich as it is in English because there are situations I have never found myself in.

    A good example of this was talking to a friend of mine when we first worked in a German-speaking office. She told me this story:

    Although I studied German at school and was very fluent, I was shocked the first time that I was running a project kickoff for a German-speaking client. Not only was I learning new German words for the domain (transportation) but I was also learning new German words for technology terms I had taken for granted.

    Our experiences shape who we are, and we cannot possibly be experts at everything, and that’s perfectly fine. I found it was more productive to focus on getting better than worrying about how close to mastery I was.

    Conclusion

    After years of coaching, teaching and training technology, I have many techniques that I consider useful as learning strategies. I found last year was a great opportunity to try applying some of them to a completely different skill and see how far I could go. Happily, it seemed to have worked.

    I hope you found this article useful and that you will find these tips above useful. In summary, try to:

    1. Find different teachers
    2. Have a goal, and keep focused on it
    3. Celebrate progress
    4. Vary your learning activities
    5. Accept you’ll never be perfect

    What other learning strategies do you find work for you?