patkua@work

The intersection of technology and leadership

Category: Agile (Page 3 of 22)

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.

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.

Book Review: Software Architecture for Developers

April 28, 2015 / / 1 Comment

Simon Brown’s book, Software Architecture for Developers has been on my reading list for some time. I am aware of Brown’s talks that he gives at conferences, and his very good workshop on describing how to draw more effective diagrams as a communication mechanism for developers to other groups, but I wasn’t quite sure what his book was going to cover.

Software Architecture for Developers

This weekend, whilst travelling, I had a bit of airport time to do some reading to plough through his book.

What I enjoyed about the book
Architecture is a touchy subject, and Brown doesn’t have any problems raising this as a contentious topic, particularly in the agile community where it doesn’t have an explicit practice. Some XP books explain the role, but mantras like “Big Design Up Front” and “Last Responsible Moment” are often (wrongly) interpreted as “do no architecture.” What I liked about Brown’s approach is his recognition of the Goldilocks approach – not too little and not too much where he provides both points of view and some concrete practices.

Brown covers important topics like quality attributes (Cross Functional Requirements), what the role of an Architect is (and that it is just a role, not necessarily a person). I am biased in the opinion but I enjoyed Brown’s perspective about whether or not architects should code, and it aligns well with my own point of view that for a Tech Lead (or Architect) to make effective decisions, they need to have empathy and understand (live, breath and sometime burn for) the decisions they make.

I appreciated the way that Brown puts “Constraints” and “Principles” as key factors that aren’t necessarily represented in the codebase and are unlikely to be easily discoverable for new people. Both are things that I have done when leading software teams and are things I would repeat because I find it helps people navigate and contribute to the codebase.

What I found slightly strange about the book

I believe the book is really strong but there were a few sections that seemed slightly out of place, or not yet completely finished. One was around the “Sharepoint projects needs architecture too”, which I don’t necessarily disagree with but could easily be extended to “Any software product extended to build an application needs architecture too” (cue s/Sharepoint/CMS/g or other examples).

Conclusion

Software Architecture for Developers is a very accessible, relevant and useful book that I do not have any problems recommending for people looking at how to effectively implement Software Architecture in today’s environment.

Book Review: The Lean Enterprise

February 9, 2015 / / 1 Comment

This weekend I finished reading a copy of The Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly.

Top level summary: If you want to learn about the truly agile organisation, this is the book that shows you what it looks like.

The Lean Enterprise

I have read many books about agile, lean and organisations that build software, but this is the first that really brings it all together. Other books tend to be either too theoretical (founded from either Drucker or Taiichi Ohno) or with a very practical toolkit in a very narrow domain.

This book is aimed at executives and managers or organisations – the people with the authority to change to change the system. We know from W. Edwards Deming:

A bad system will beat a good person every time.

Like a book that was actually test driven by real-life questions, it provides answers to questions executives and managers ask time and time again.

The book is packed with information and provides solutions to problems that organisations, doing agile software development, struggle with in other parts of their organisation. Better yet they offer many examples of companies who are doing it right, proving that it is not just theory and that it can be done in many ways. There are many great stories from many industries demonstrating how different approaches can be yet still exhibit the lean attitude and culture that is so essential to success. I am also glad how much the authors focus on the importance of culture (and what people can do about it) and not just a single focus on either theory or tools.

The authors have done their research well, with excellent, tangible examples of lean concepts, practices and tools linked to much more detailed reading in a referenced article, paper or book. I would almost buy this book only to give people the reading list in the back – it is really that good. I have read many of the books referenced, and I remember how they challenged and changed my thinking in a positive way. After this book, my own personal reading list is also much richer.

What makes this book especially stand out for me is the pragmatic nature of the book. Even though, to many readers, the contents may appear idealistic or too unrealistic, the authors have given many examples of companies doing it, refer to many case studies or experiences where they have seen the practices and principles at work and shown their own insights into the challenges or dangers that lie ahead. This last part speaks volumes to the authors sharing their experiences about the questions some organisations have not even asked yet and advice on how to solve it. One good example is the paradoxical nature of balancing exploration through prototyping (discovery) against the disciplined nature of continuous delivery (e.g. additional work of well refactored code, tests and scripted deployments).

When I got to the end of the book, I knew that I would need to re-read the book for a deeper understanding because it is so rich with concepts and tools – some I have not had the chance to try out.

A perfect match for the target audience it was written for and a book that will continue to be relevant for many years to come.

Thoughts on OOP2015

February 4, 2015 / / 0 Comments

I spent the first half of last week in Munich, where I was speaking at OOP Conference 2015. I missed last year when Martin Fowler was a keynote but had presented both in 2013 and 2012.

The conference still seems to attract more seasoned people like architects and decision makers and I am still constantly surprised at the number of suits I see for a technical conference – I do not know if that is more of a German culture difference as well. I felt like there were significantly more German-speaking sessions than English ones, and I sat in a number of them when I expanded my vocabulary.

I was only there for three of the five days of the conference, and was lucky enough to be invited and attend a special dinner on Monday evening where Dr Reinhold Ewald (a former German astronaut) gave a presentation about what it was like being an astronaut, what they do in space and some of the interesting challenges.

I saw a number of the keynotes and talks which I’ll briefly summarise here:

  • Challenges and Opportunities for the Internet of Things (IoT) by Dr Annabel Nickels – A relatively introductory session on what the Internet of Things actually means. The talk explained the IoT well, why it’s not possible and what people are experimenting with. It was clear that security and privacy aspects had not advanced and that there was still a lot of work to go, as there were lots of questions from the audience, but no clear answers in this space – more “it’s something we’re looking into”-sort of answers
  • Coding Culture by Sven Peters – Sven is an entertaining, engaging and obviously well-practiced presenter who knows how to engage with the audience with pictures and stories. His talk focused on coding culture – but more particularly the coding culture of Atlassian, the company Sven works for. An entertaining talk about how they work inside the company, but was not particularly surprising for me since I know already a lot about that company.
  • Aktives Warten für Architekten by Stefan Toth (Actively Waiting for Architecture) – A nice introduction to the Last Responsible Moment or what is more popular in the Agile community these days, Real Options.
  • Ökonomie und Architektur als effektives Duo by Gernot Starke, Michael Mahlberg (Economics and Architecture as an effective pair) – From my understanding, the talk focused on bringing the idea of calculating ROI on an architectural front. The pair spent a lot of ideas introducing financial terms and then a number of spreadsheets with a lot of numbers. Although well-intentioned, I wasn’t sure about the “calculations” they made since a lot of it was based on estimates of “man-days” needed and “man-days” spent/saved – it all looks very good when calculated out, but they didn’t really spent much time eliciting how they get estimates. They spent a lot of time introducing Aim42 which I wasn’t familiar but will now look into.

I ran two talks that had both good attendance and great feedback (like the one below):

OOP2015 - Best Talk

The fist was “The Geek’s Guide to Leading Teams” where I focused on exploring the responsibilities and remits of what a Tech Lead does and how it’s quite different from being a developer.

The second was “Architecting for Continuous Delivery” which focused on the principles and considerations for when people build systems with Continuous Delivery in mind.

I had a great time visiting the conference and had an interesting time expanding my German vocabulary as I tried to explain what I and what my company do in German – something I didn’t really do a lot of when I was living in Berlin.

Booklist from the Retrospective Facilitators Gathering 2014

May 19, 2014 / / 0 Comments

The Retrospective Facilitators’ Gathering is the only conference I planend on attending in 2014. Like many conferences, I end up with many books to read, and thought it’d be worth sharing the list I accumulated here:

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑