Reviewing the week’s blinks

I’ve signed up for a new service, called Blinkist, a service that provides summaries of books in 15 minutes both in text and audio format. I was looking for a way to review a number of books that I’ve both read and not yet read, to either determine whether or not I should read them, or just something new to learn.

Here’s a review of some of the book summaries that I’ve been listening/reading to:

  • Games People Play by Eric Berne – Humans play games all the time, acting in the role of Parent, Adult or Child depending on the “game” being played. We play games with different goals (safety, interaction, ) in mind although we cannot articulate them. Understanding the different roles people have when in a game gives insight into patterns of behaviour and this insight is useful in all relationships. We need to be particularly careful playing too many games in a personal relationship, as it is only when we stop playing games do you get to truly create deeper relationships.
  • Turn the Ship Around by David Marquet – A leadership tale that describes a leadership style that made one of the worst performing naval ships into one of the best. A good summary of turning a command-and-control leadership style, into a leaders building leaders style as well as other tricks to create quality control and feedback without using punishment. I’ll add this to my list of books to read further.
  • The Coaching Habit by Michael Bungay Stanier – A nice summary that distinguishes between the difference of mentoring (where you are providing more advice/answers) to coaching (where you lead through asking questions). A good summary of the benefits to this leadership skill, and some good examples of open questions to stimulate good conversations.
  • Getting There: A Book of Mentors by Gillian Zoe Segal – With a subtitle about mentors, I thought this book would focus more on how mentors helped people succeed and instead you end up hearing the stories of some successful people. Although still inspirational, I found the summaries didn’t focus very much on the role the mentor played.

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.

Book Review: The John Carlos Story

At our internal away day in Brighton, ThoughtWorks EU had a Pillar 3 Bookstore, a book store selling books that encouraged people to learn more about Social and Economic Justice Issues. I ended up picking up The John Carlos Story: The Sports Moment That Changed the World, a bibliography of one of the two famous runners in the 1968 Mexico City Olympics Games who raised their black-gloved fists on the winning podium.

John Carlos Story

As an Australian I remember reading last year a couple of articles of Peter Norman, a person who joined their protest by wearing a symbol but also lived with the same consequences. He died of a heart attack in 2006.

Despite being icons for protesting the movement, what struck me is the courage and the passion that John Carlos had at the time, fighting for equal rights and representation despite the environment in which he found himself. I can only imagine what it was like, having used the opportunity of a world-wide stage, to live with the aggressive response from both the Olympic committees and the sporting community back in the day.

I really enjoyed reading the book to better understand the story you never hear about, and the struggles and bravery people have to fight for the causes they believe in. Do yourself a favour and get a copy of the book here.

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.

    SATURN 2016, San Diego

    I first heard of SATURN via social media through Michael Keeling, an IBM employee who spoke at XP2009 many years ago. Sam Newman spoke last year about Microservices. Although the conference has a Call For Papers (CFP) each year, they also had a small number of invited speakers and Michael organised for me to go along to talk about Evolutionary Architecture.

    SATURN is a conference organised by the SEI (Software Engineering Institute). SEI are probably most well known for CMM, although there is now another institute responsible for it. The conference has been running since 2005 and has a long history of focusing on architectural concerns.

    Architecting the Unknown
    Architecting the Unknown keynote by Grady Booch (@Grady_Booch)

    What I really liked about the conference

    I believe that one of SATURN’s greatest strengths is a focus on architectural thinking, through the application of the latest tools. Unlike some other conferences, I felt like the programme tried to assemble a good collection of experience reports and presentations that emphasised the architectural principles, rather than focusing on the current tools.

    Although this may be less popular for people wanting to learn how to use a specific tool, I feel this emphasis is much more valuable and the lessons longer lasting.

    What I also really enjoyed about the conference was the relatively small size which was just over 200 participants from various parts of the world. Having a good location, and small size allowed for some better quality conversations both with other speakers and attendees. One good example of the conference facilitating this, was an office hours session for attendees to easily ask questions of speakers. I shared by office hours with Eoin Woods (author of Software Systems Architecture) and Grady Booch (IBM Fellow, One of the Three Amigos who were best known for developing the Unified Modeling Language).

    SATURN 2016 Conference Dinner
    Conference dinner at a baseball game for SATURN 2016

    Another example to reinforce that was connecting with Len Bass (one of the authors of Software Architecture in Practice) at the conference dinner (at a baseball game).

    Other observations

    During the conference I spoke with many people carrying various Architect titles. Interestingly many came from many larger organisations and government agencies, which shouldn’t have been any surprise given the history of the conference. I remember meeting and speaking with one particular Enterprise Architect (EA), who seemed to be one of the most pragmatic EAs I’d met, who was trying at all costs to stop his board randomly signing large contracts with product vendors like Oracle and IBM without the proper diligence about understanding what they were actually building.

    At the same time, I met a number of architects struggling to help their organisations see the value of architecture and the role of the architect.

    My talk

    I spoke after Booch’s initial keynote, “Architecting for the Unknown” which lead really well onto the topic I was speaking on, “Evolutionary Architecture“. I had a packed room as was a topic that resonated with people. At one point the conference organised brought more chairs into the room and there was still only standing room for the 90 minute talk! I had some great questions and conversations throughout and found out later that I won the award for the best conference talk in the “Architecture in Practice” category!

    Evolutionary Architecture Talk
    SATURN Evolutionary Architecture talk audience

    I’d definitely recommend attending SATURN if you’re interested in focused on building architectural thinking and an opportunity to connect with architects across the industry. The size is great for conversations, sharing experiences and with next year’s scheduled for Colorado will be really interesting too.

    Final thanks

    I’d like to thank the organising group calling out Michele Falce (Technical Event Coordinator), Bill Pollak (General Chair), Jørn Ølmheim and Amine Chigani (Technial Co-Chairs) who did a great job putting together a fantastic conference, John Klein for hosting Office Hours, and Michael Keeling for organising an invite for me.

    Book Review: The Phoenix Project

    It has been a while since I read The Phoenix Project and I am glad to have reviewed it again recently. Described as a business novel, or The Goal for the 21st century, the book focuses on a story that large organisations need to realise when they feel they need to transform IT.

    Title cover of the Phoenix Project book

    The book focuses on a company in crisis – a company that is trying to complete lots of software projects, has a terrible number in flight and grapples with the problems many companies have – lack of visibility of the work, dependency on key individuals, marketing lead promises and IT treated as a cost-centre attitude. Bill, an IT Manager is one day promoted into a higher role where he is responsible for turning around and dealing with all the critical issues. He is given access to a mentor who introduces him to the “mysterious Three Ways” that are slowly uncovered throughout the book.

    What I liked about the book

    Business novels are refreshing to read as they feel less like reading a business book and sometimes makes picking up the book less of a chore. The authors manage to talk about generating insights and explaining some of the tools from a number of angles (Bill’s thoughts as well as from other characters’ perspectives) as well as relating it to existing material such as Theory of Constraints.

    Like all good books, you follow the exciting story plot that descends into what seems like an insurmountable situation, only for the protagonist to find ways of overcoming it. For those who have never been exposed to visual ways of working (like Kanban), or understanding Work in Progress, Queueing theory and how IT capability matters to business, there are many useful lessons to learn.

    What would have made the book better

    Although the book has several characters who behave in a negative way, and pay for some of thoese consequences you don’t hear about the attempts by the protaganist which end up failing (with their consequences) unlike the real world. I also felt that the pace at which things changed seemed to occur at an unrealistic rate – but that’s proabably the downsides of a business novel versus what might actually happen in real life.

    Conclusion
    I would still highly recommend this reading if you’re interested in understanding about how modern IT, interested in how DevOps culture operates and some tools and techniques for moving IT management into a more responsive, flexible but still highly controlled manner.

    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.

    Two topics best avoided in retrospectives

    When I introduce people to retrospectives I often am asked what topics should be covered and not covered as part of this. When I have asked this question of other people, I hear answers like “Everything should be open for discussion” or “No topic is ever taboo.”

    Although I agree with the sentiment, I strongly disagree with the statements.

    Photo from coltera's Flickr stream under the Creative Commons licence
    Photo from coltera’s flickr stream under the Creative Commons licence

    Yes, being able to discuss most topics openly as a team, particularly where there are different views is a sign of a healthy, collaborative team. Even then, I still believe there are two topics that teams should watch out for because I feel they do more harm than good.

    1. Interpersonal conflict

    Imagine yourself working with a team where two people suddenly start shouting at each other. You hear voices continue to escalate, maybe even watching someone storm off. An uncomfortable silence descends in the open team space as no one is quite sure how to react. Is this something you discuss as a team in the next retrospective?

    Perhaps if the issue involves the entire team. When it involves two people where tension escalated too quickly over a single topic, it is more likely you need mediation and a facilitated conversation. A person wearing a leadership role (e.g. Project Manager, Line Manager, or Tech Lead) may be an ideal person with context to do that, but it may also be better to find a mediator who can get to each person’s interests and to find a way to both move forward and to start healing the relationship.

    Although it will be impossible to ignore the topic in a retrospective, the focus should be on team expectations about behaviour, or identify ways the team can support each other better. It is unlikely you will solve, as a group, the conflict between the two people without making each of them very uncomfortable and unsafe.

    behavioural issues for a single person

    Just as you wouldn’t isolate two people and make the entire retrospective about them, teams must not “gang up” on a single person unless they feel safe to discuss the topic. If the entire team complains about what a single person is doing, the person is likely to feel targeted, isolated and potentially humiliated in front of their peers.

    It may still be important to highlight issues impacting the entire team, but be careful that a retrospective does not become a witchhunt.

    Where repeated, consistent behaviour needs to be addressed, a better solution is targeted one-to-one feedback.

    Conclusion

    Retrospectives are important practices for agile teams, but it is not a tool that will solve all problems. Retrospectives work well with other tools that offer better, more focused conversations for smaller groups such as mediation and one-to-one feedback.

    What topics do you think should be avoided in retrospectives? Please leave a comment with your thoughts.

    3 Tips for building a Technical Vision

    One of the key responsibilities of a tech lead or architect is to ensure there is a shared understanding of where the team is heading. A clear Technical Vision is really important so that everyone on the team pulls together in the same direction instead of moving in potentially different ways, or worse, pulling against each other. What follows are three tips I think about when focused on building a Technical Vision.

    1. Use a visual

    Although developers will often joke about the “whitebord architect”, I find diagrams are a powerful way of articulating ideas that cannot be succinctly expressed in code or words alone. I highly recommend Simon Brown’s The Art of Visualising Software Architecture which provides concrete advice to make your diagrams better.

    Your first step in building a Technical Vision is to make sure you use some sort of visual model. Using words alone leads to unintentional misinterpretations or misunderstandings. Diagrams offer different perspectives and a shared model between two people. Use a number of visuals to model different perspectives but identify first what perspective you find adds the most to shared understanding.

    TOGAF list a number of potential perspectives you might visualise. Remember however that more models does not lead to a better understanding. Diagrams are only a tool to aid communication, not to replace it. This leads nicely onto our second tip.

    2. Discuss as a team

    Successful architects and tech leads build a shared understanding of the Technical Vision by involving the entire team in its creation. Whiteboards are your best tool here to allow for real-time collaborative creation. A model is best built block by block with the same shared context and story.

    Building a visual together is a much more effective way than printing off a PDF or asking people to view a static copy on a wiki. Beware your human sunk cost fallacy cognitive bias which my colleague Neal Ford calls the Irrational Artefact Attachment. Try not to invest too much time in any models or diagrams, or you’ll find yourself (irrationally) defending or preventing change to the model which leads us to the third and final tip.

    3. Iterate – reflect and review

    A real Technical Vision must incorporate feedback. Unlike the once-off architecture models written by true ivory tower architects, the Technical Vision should be revisited as the system evolves and as the team learn more about the domain and constraints of their environment.

    Look to review the shared Technical Vision as a team on a frequent basis (once every three months is a good guideline for a long-lived system) to ensure the shared understanding is the same.

    The practice of reflection in action

    In a previous article, I explained how the most essential agile practice is reflection. In this article, I outline examples how organisations, teams and people use reflection in action.

    Reflection through retrospectives

    Retrospectives are powerful tools that whole teams use to reflect on their current working practices to understand what they might do to continuously improve. As an author of a “The Retrospective Handbook“, I am clearly passionate about the practice because they explictly give teams permission to seek ways to improve and when executed well, create a safe space to talk about issues.

    Reflection through coaching

    Effective leaders draw upon coaching as a powerful skill that helps individuals reflect on their goals and actions to help them grow. Reflective questions asked by a coach to a coachee uncover barriers or new opportunities for a coachee to reach their own goals.

    Coaching is a skill in itself and requires time for both the person doing the coaching, and for the people being coached. When done well, coaching can massively improve the performance and satisfication of team members by helping coachees reach their own goals or find ways to further develop themselves.

    Reflection through daily/weekly prioritisation

    I have run a course for Tech Leads for the past several years and in this course, I teach future Tech Leads to make time during their week to reflect and prioritise. I see many people in leadership positions fall into a reactive trap, where they are too busy “doing” without considering if it is the most important task they should be doing.

    Effective leaders build time into their schedules to regularly review all their activities and to prioritise them. In this process, leaders also determine what is the best way of accomplishing these activities which is often involving and enabling others rather than doing it themselves.

    Reflection through 1 to 1 feedback

    When I work with teams, I teach team members the principles of giving and receiving effective feedback. I truly believe in the Prime Directive – that everyone is trying to do the best that they can, given their current skills and the situation at hand. A lot of conflict in working enviornments is often due to different goals, or different perspectives and it is easy for people to be frustrated with each other.

    When team members do not know how to give an receive feedback, being on either side can be a really scary prospect. 1 to 1 feedback gives people opportunites to reflect on themselves and make space for personally being more effective and for strengthening the trust and relationships of the people involved.

    Reflection through refactoring

    Refactoring is an essential skill for the agile software developer and a non-negotiable part of development.

    Three strikes and you refactor – Refactoring: Improving the Design of Existing Code (Martin Fowler)

    Developers should be making tiny refactorings as they write and modify software as it forces developer to reflect on their code and think explicitly about better designs or ways of solving problems, one bit at a time.

    Reflection through user feedback

    In more recent years I have seen the User Experience field better integrated with agile delivery teams through practices such as user research, user testing, monitoring actual usage and collecting user feedback to constantly improve the product.

    While good engineering practices help teams build systems right, only through user feedback can teams reflect on if they are building the right system.

    Conclusion

    Reflection is the most powerful way that teams can become agile. Through reflection, teams can better choose the practices they want and gain value immediately because they understand why they are adopting different ways of working.