patkua@work

The intersection of technology and leadership

Author: Patrick (Page 7 of 53)

3 Tips for building a Technical Vision

3 Tips for building a Technical Vision

March 21, 2016 / / 0 Comments

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

The practice of reflection in action

February 8, 2016 / / 2 Comments

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.

What is the most essential agile practice?

The most essential agile practice

January 22, 2016 / / 3 Comments

Since the declaration of the Agile Manifesto our industry has seen and continues to see many agile methodologies, some better than others. The large number of methods and practices can be confusing and overwhelming for newcomers although each offer their own advantages in different circumstances.

Methdology is made up of many practices

Methodologies offer a starting point for a set of practices, not an end point like many people think. I draw upon practices from a variety of methodologies almost all the time because I find value using them. Some examples include: Continuous Integration, Co-Located and Cross-Functional Teams, Test Driven Development, Refactoring, Daily Stand-Ups, Small Iterations and Retrospectives. Although I feel agile values and principles are important, I also believe that practices are just as important. Practices offer people something concrete to start with and a way to breath life into a principle or value.

After working for more than a decade in agile teams and enviornments, I truly believe there is one key agile practice that has the biggest impact. Organisations, teams and people who fail to use the most essential agile practice end up cargo-culting, or using a practice because others are using it and are unlikely to gain real value from the practice. Organisations, teams and people who use the most essential agile practice become the best at what they do because they understand why they are doing what they do.

Insanity: doing the same thing over and over again and expecting different results – Albert Einstein

The most essential agile practice is Reflection. In the upcoming follow on article, I will explain how I have seen organisations, teams and people use the practice of reflection.

Making Change Stick

January 15, 2016 / / 0 Comments

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?

2015 in review using numbers

January 3, 2016 / / 1 Comment

Although I recently ran a personal retrospective, I also like looking back at the past year using different models to recognise progress and celebrate events.

Picture of numbers

Image sourced from eye/eye under the Creative Commons licence.

Here’s how 2015 went for me in numbers:

Running a Personal Retrospective for 2015

December 30, 2015 / / 5 Comments

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.

Types of Development Teams

December 17, 2015 / / 2 Comments

In some of the Tech Lead courses I have held, we sometimes talk about leadership styles and whether or not the Tech Lead role is essential. During these discussions, one of the biggest influences on both style and necessity is the style of teams.

This article represents my current classification of teams I have seen over my years in industry.

One man army

A lonely developer working on a project by themselves. Most likely they are working on multiple projects and consequently multi-tasking, because that’s the way the organisation works. Often seen in organisations that are siloed. Technically not a team but treated as a part of a team.

Distributed

Distributed teams come in many shapes and sizes. Although distributed teams are similar to Off-Shore teams (see below), distributed teams tend to be a team spanning several locations. GitHub are an example of a distributed team (and organisation). Often seen with start-ups who are seeking talent not easily found in the same location.

A distributed team typically spans several timezone, making an “all-hands” meeting more difficult. Relies on asynchronous tooling such as chat software (e.g. IRC, Slack) and virtual task boards.

Off-Shore

An Off-Shore team is a distributed team in mainly two locations. Often used by many IT organisations as a “cost-cutting” tactic trading communication effectiveness. Sometimes an off-shore team is a historical artifact (company acquisition or expansion) and necessary to keep essential knowledge alive.

Off-shore teams often have better overlap with time zones that fully distributed teams, but often results in an us-and-them mentality.

The “Pod” shaped team

The “Pod” shaped team is a co-located team who that has most of the skills they need to deliver a project. The team often includes a PM, developers, analysts, testers and sometimes operation and support people. They are all working towards the same project at the same time. This reduces co-ordination and communication lag and makes software delivery more effective.

They are called a “pod” because they are kept to a certain size (typically less than 12 people) to keep communication overhead minimised.

Functional Silos

Functional silos are not representative of effective teams because people are grouped managerially and physically by skillset instead of by goal. Each group is managed by a separate person and in larger company, decision making and authority reaches several layers much higher into the organisational hierarchy. Collaborating and changing the way that a team working on the same project across functional silos becomes very difficult to change.

Typical functional silos often seen: PM (and their PMO), Analysis, Developers, QA, DBA, System Administrators, Network and Support.

Retrospectives – not just for agile teams

December 11, 2015 / / 1 Comment

I was reminded yesterday of the power of retrospectives, even in the context of non-agile software delivery teams. I have recently worked with a programme team who are building a five-year business case (quite a world away from software delivery and one would argue, very waterfall-like). Fortunately, several people have been very open to seeing how agile works in their environment so I facilitated a retrospective looking back over several months.

During the retrospective, we uncovered a number of typical issues that groups encounter: visibility of work, differences in how work should be approached, and general puzzles about the organisation. Better yet, the group came out with concrete steps towards making incremental improvements and an excitement and appreciation for the retrospective practice, something I was particularly pleased by.

Although there are other ways of achieving the same goals, it reminded me of how effective retrospectives create a safe space to discuss and address issues and create a better working environment. Better yet, retrospectives work for everyone, not just for agile teams.

The dark side of gaming metrics

December 7, 2015 / / 0 Comments

I published an article a while ago on how to design for metrics, but I read this well-written, but article of horror, “Why drivers in China intentionally kill the pedestrians they hit.”

This article hits home about the reality of a population gaming a metric and what is leading to a shift in cultural values through their actions. The short story, if you don’t read the article is that it is apparently seen as more economical to pay for someone’s death, than for their healthcare overall combined with a low chance of apparently being caught for murder. Due to the economic cost, it has apparently become acceptable, or at least, very common for someone to finish someone off, rather than pay for what medical aid they made need.

Keynote at the GDS Away Day

October 6, 2015 / / 0 Comments

A couple of weeks ago I had a last minute invite via James Lewis to speak at at Away Day for some people from GDS. I only had a couple of days notice and was going to give a talk around being a Tech Lead but thought I would adapt some of my talks to the broader audience that would include developers, web operations, delivery managers, tech leads and architects.

I ended up with a talk titled, “Technical Leadership Matters.”

I have been thoroughly impressed by the work and innovation that the GDS team have made along the way and my goal was for everyone to come away, feeling like they could demonstrate Technical Leadership without requiring a title of a “Tech Lead” or “Architect.”

Fish Island Labs
The GDS Away Day was held at Fish Island Labs, a new digital hub set up by the Barbican group and located on the river Lea with a nice spacious set of rooms for conferences and co-working and a very functional bar down stairs.

I held my talk as the closing keynote before I joined everyone in the pub downstairs and had some great feedback about how relevant the message was, and that many people came away inspired, which I was particularly happy with given it was the first time I held this talk and the little time I had to prepare for it.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑