patkua@work

The intersection of technology and leadership

Category: Teams (Page 4 of 8)

Boosting Hyper Productive Teams

March 29, 2011 / / 0 Comments

I’ve been in the fortunate position of building up a small team since the start of the year. It’s the first “official” tech lead role I’ve had for a couple of years and I’m proud to say that we have a pretty rockin’ team. Blending and appreciating lean ideas into how we work mean that we’re in a pretty good position all around.

Building what matters
The project work for this client meant tight deadlines. For once, it’s not just because the detached marketing arm committed to some random date without asking about how likely it would be. This one was based on pure legal compliance by a certain date. Although arguably arbitrary, it certainly has some merit (e.g. if we don’t do this, we simply cannot operate business in this country). All my UX buddies will be proud, championing the end user and what is it that need to be able to meet compliance. This neatly fits in with the systems thinking point of view – rather than building what we think we need, talking to people who actually did similar jobs and finding out what their problems and way of thinking was. We drilled out some personas, worked out some user stories, attempting as best to map them out.

Building strong teams
Teams are forged around a common purpose. Not because they simply sit in the same room. Calling a group of people a team does nothing to change they are, in fact, just a group of people. Although it took a while for the entire team to settle into shape (we had one join in here or there), we tried building a Team Charter to help understand what it is we valued in each other, and what our expectations were of each other. We took time to make clear roles, responsibilities, and who most people expected to fulfill those responsibilities, remembering that roles do not map 1:1 to people.

I think it’s helped that everyone comes from such diverse backgrounds. We have two British people, one German, one Polish, one Indian, one Pakistani and myself, the Australian. It’s useful to find common interests and cultural interchange as another team building exercise.

Preventing impediments and swarming around those that appear
Risk mitigation and issue management isn’t about simply identifying them in some spreadsheet and leaving them away. Instead, it’s about the rigourous act of trying to prevent them from happening as early as possible and dealing with them. We knew pretty early that the development time to meet this criteria would be tight, so we focused on ensuring as smooth a flow of work through the cycle. I won’t admit that we used kanban without explicit work-in-progress limits, however this doesn’t mean that we didn’t apply the Theory of Constraints. We choose development (coding) as our bottleneck, creating tools to optimise testing, and ensuring minimal rework by being thorough in putting work ready to be picked up. Me (as tech lead), our QA, and BA would sit down to tackle features from different angles and building consensus with our Product Manager. As a result, I can’t think of many stories where we discovered information too late, or ended up with large amount of rework. I hope that everyone else has appreciated the flow.

Two weeks away and things still ran fine
It’s a strong test that I always ask people in leadership positions. How would you feel if you couldn’t talk to your team/organisation for a day? For a week? For two weeks? With a properly built team/organisation people should be capable of working out problems without you. I would worry about not just the signal, but what it says about your leadership style, if teams could not last without you. Fortunately one week of skiing and another week for a conference and I came back to a team happily churning along (although there was one event early on that seemed to knock the team’s confidence).

Retrospecting on the Retrospectives
Strangely enough, we’ve only run about two or three proper retrospectives. The first time, our QA remarked on how this had been their first session where the Went Well’s far out numbered the Less Well’s. For the other one, the only things that came up in the Less Well’s were organisational things we knew about, and had either actions pending for or were things we realistically weren’t going to be able to change.

Experimenting
I strongly believe most organisations waste human talent, passion and energy when you can’t create a good environment for them. I feel like we’ve done a pretty good job. We finished development complete of our critical legal requirements two weeks early with one developer less than originally planned and nearly through the next “nice-to-have” tranche of work.

I believe most teams would benefit the most by removing impediments, and creating flow. Unfortunately I don’t think most teams get there. However, once you are there, I believe the next best thing you can do is to experiment and trial new things. I’m trying to encourage our PM to let go of estimation and working out how to encourage just the right level of experimentation.

Swarming on Stories

February 7, 2011 / / 3 Comments

On leading a new team, I’m definitely trying to be as open to trying new practices particularly as I feel it is an important part of The Beginner’s Mind (topic to be talked about at InfoQ). One of the new practices we tried last week was swarming work on a user story.

Normally, our natural work in progress limit for development is limited by the number of pairs we have on the team (although not all tasks need pair programming). This time, I’m the odd one out, acting as tech lead and needing to do a handful of other activities including working to maintain constant flow between our BA and QA functions and guiding the development in the right direction. In a different world, I would have started a story and with other duties, probably be quite interrupted in flow to completion.

This time, we broke down a story into as many tiny tasks as possible, discussing those that needed some design elements, or identifying those tasks that could be taken in solo (such as knowledge gathering with report back) and the three of us worked on the same story. The result was a very minimal work in progress limit and actually, we made a lot of progress in a rich environment where we are learning about not only the constraints of the current build and development systems, but working out the best ways to implement what we need and deliver value.

I’m quite happy to report that I’m really liking the swarming on stories. It helps me feel involved in the way that things are going, rather than keeping on top of too many ongoing threads. I do wonder how many people it would be to scale to, but for now, it’s working for us. Inspect and amplify, or inspect and adapt!

Picture kindly borrowed from Max xx’s Flickr stream under the Creative Commons licence.

Performance is Emergent Behaviour

November 24, 2010 / / 1 Comment

Mark’s tweets got me thinking when I tweeted a short number of responses back at him recetly. Unfortunately twitter isn’t a great place to have a long and well thought conversation and figured I would blog about it like Mark did.

The gist of the conversation seem to float around two positions that seem to be in conflict.

One position states: someone’s behaviour is determined by their environment (or system). This is certainly the view that John Seddon writes about a lot in his book, Freedom from Command and Control.

Most people read this position and (incorrectly) deduce, someone’s behaviour is solely determined by their environment (or system) therefore, it is best to focus on one of them.

Mark makes a great observation that people perform “differently” given they have the same environment. In an environment, sometimes those “differences” may be “better”.

To which I responded in the brevity required by 140 characters, “different strengths and interests at play. Emergent behaviour based on individual and environment.”

Emergent behaviour in this case can be seen as much more than just strengths and interests at play. People are complex systems and highly unpredictable. Each individual goes through many different experiences. Just as an example, everyone’s commute around London is different. Train failure? Tube strike? Traffic on the street? Walking to work? Everyone has different social structures – sleep deprivation from young kids, happiness from a child’s graduation, hard night out celebrating a friend’s send off. Even the weather has a huge impact on people (though everyone responds differently).

It’s rare that I think we are all in the “same” environment all the time.

Add in the topics you’re currently interested in, the events unfolding around you and regardless of the system, and the skills, strengths at play and ambitions, I hope you start to understand why everyone behaves differently. Of course some of those elements in the system have minor impact on the end result yet might explain why some perform “better” (i.e. differently) to others.

Upcoming Speaking Engagements

November 3, 2010 / / 0 Comments

I’ve been terribly busy the last couple of months and it reflects by the lack of any blog posts. So sorry for that. Here’s a short post talking about upcoming speaking engagements.

My first one is for the Collaboration Track at Orevdev in Malmo next week. Titled, “Tightening the Feedback Loop”, I’ll be exploring how interpersonal feedback can be so much more effective. The programme for Oredev looks amazing so I look forward to contributing and participating in the conference.

The second speaking engagement is for the Skills Matter Agile, Lean & Kanban Exchange talking on their “Leadership, Value and Visibility Track”. I’ll be covering, “Making ‘Management’ Work with Agile.

XP2010 Review

June 7, 2010 / / 4 Comments

This year’s XP2010 conference was held in the great Northern parts of Norway, up in Trondheim, only about 200km south from my first XP conference (XP2006) I attended several years ago. I always find this series of conferences interesting, partly because there is always the blend between the academic (research papers and experience reports) and the industrial side as well as the infusion of the hosting country’s culture.

This year, the conference saw 425 attendees (50% of them Norwegian) across 8 different tracks and covering four days of a wide variety of conference mixtures including Lightning Talks, Panels, Workshops, Tutorials, and Open Space events.

ScottPage

The first of the two keynotes, run by Scott Page was my favourite – a lecturer and researched on complexity in different environments. He talked about the importance of diversity and its impact on building better solutions as well as a provable formula calculating what the wisdom of the crowds was. Hopefully they’ll be putting up his slides somewhere as a result.

The second of the keynotes, ran by David Anderson did a great job of condensing down a long talk into a thought-provoking discussion on the work that he’s been doing on building a Kanban movement in the places he’s been working as well as a discussion of his recently released book about Kanban. He had some nice visualisations on the slides and even finished slightly earlier with plenty of times for questions.

Overall the conference seemed to have a nice blend of both process and technical topics, although there were a few complaints about specific discussions around “XP” itself although I think plenty of discussions about specific practices quite useful within any agile context.

I ended up much busier than I thought I would be, playing host for two of the session talks, helping out with a Pecha Kucha (more on that later) session and running a workshop on my own.

Entertainment

Venue, organisation and efficiency wise, the organisers need to be congratulated on a job that will be hard to surpass. Everything seemed to run smoothly including an amazing and difficult-to-forget Conference Banquet involving interesting local foods (smoked reindeer heart, moose and local seafood), a pair of comedic jazz academics, Keep of Kalessin playing some Extreme Metal, all inside Trondheim’s amazing Student Society venue.

ExtremeMetal

The strangest part of the conference for me was participating in a “What’s in my agile suitcase?” Pecha Kucha run by Martin Heider and Bernd Schiffer. You can read more about the format here and it was great to be one of the five other prepared Pecha Kucha’s including Rachel Davies, Mary Poppendieck, Joshua Kierevsky and Jeff Patton. I found the diversity of styles and approaches fascinating as well as the specific things that people “packed” in their suitcases. Being the first time format all the speakers found it a fascinating format made thrilling by the short-time and the fact you don’t have control over the timing of the slides. If I were to do this differently, I’d definitely try to focus on a smaller range of topics (or just one).

My week ended (as did the conference) with my final workshop called “Building the Testing Pipeline.” I’d specifically targeted people who’d been working with automated tests for some time and I ended up with a surprisingly full room. I’d run this previously at ACCU with a slightly different audience. We had some great brainstorming sessions (I’ll be putting that up soon) and hopefully more people came away thinking more consciously about the balance of tests they have and whether or not they have the correct balance that maximises their confidence, and minimises their feedback cycle.

I’m also very proud that the experience report that I shepherded won best paper (experience report), and I finally got to meet the author, Jørn Ola Birkeland of Bekk Consulting, in person to congratulate him on the day.

Thanks to all the organisers, participants, and passionate people that made the conference so much fun and success. Wonderful to reconnect with old friends and make many new ones.

Agreeing to Agree at London Geek Night

February 7, 2010 / / 0 Comments

Conflict is a natural part of your every day life, whether it is at work or home. A certain amount of conflict is healthy as long as you work out how to resolve it.

Liv Wild and I will look at a number of conversation models we’ve found healthy teams use, in agreeing to agree. We’re holding it at the Thoughtworks UK office from 7pm this Tuesday (9 Feb). More details can be found here.

XP2009 Day 2

June 3, 2009 / / 0 Comments

Thoughts about the second day
Ivar Jacobson gave an equally uninspiring keynote, talking about “What they don’t teach you about software at school: Be Smart!” In it, he focuses on the fact that it’s not only enough to try to “Be Agile”, but you need to “Be Smart”. Unfortunately many of the items that he talked about didn’t really seem to be any different from “Being Agile” and that he had obviously targeted the wrong audience.

I’m glad the conference ran with an open space session, this year introduced by Willem Van Den Ende and Lasse Koskela. I suggested a topic titled, “The Kanban, Lean, Agile Divide” and I felt we had the best quality discussions during this open space. I wanted to answer a number of questions including:

  • Did people know about the Kanban Community?
  • How active were people in that community?
  • Did people perceive a divide?
  • And if so, why?

Out of around the 12 people participating, probably only two or three hadn’t heard about the community, and only one or two people were active in participating (in the mailing list portions). We had lots of discussion as to what people considered as Kanban as well.

kanban

First page of notes from the open space session

We noted down the mailing list, available on Yahoo Groups: Kanban-Dev and several “published” resources including the paper, Kanban Vs Scrum, and the book, Scrumban.

When asked about what Kanban was the participants, here’s what we recorded:

  • Elements of one piece flow (particularly limits to WIP or Work In Progress). Translated into practical terms, it meant focusing on one story at a time (as a team or as a pair)
  • Kanban was an alternative scheduling technique
  • Unprescriptive, or less prescriptive (relying on other practices to help out)
  • Constantly evolving
  • “Good for maintenance”
  • Most people considered Kanban a “Practice more than a methodology”, though there was general agreement that some people are trying to turn it into more than that
  • Focused on delivering “Minimal Marketable Features”
  • Quote from Tom Poppendieck, “Scheduling and Workflow are orthogonal”. We expanded upon this for a bit and a more concrete example is you can use different scheduling techniques such as Kanban or Timeboxes with the same workflow such as a simple, “To Do, In Progress, Done” workflow.

I recorded that some people were still doing sprint/iteration planning whilst using Kanban though I don’t remember if we got into the details.

I also recorded two concerns, such as knowing, “When do we get stuff done?” and a very “Loose Terminology” leading to lots of confusion, particularly the overloaded associate with Kanban (as a practice) and Kanban (as a methodology).

When asking the question, “Is there a kanban divide?” some answers included, there is maybe a divide in a community sense, and when probing further, when interpreting Kanban as a practice, not a methodology there wasn’t however there was definitely a sense when treating Kanban as a methodology and not as the practice with a feeling that some people in the community wanted to make money.

kanban2

Last page of notes from the open space session

We asked why the community divide and understandably, there was no real community around to openly discuss Kanban (as a practice) and felt similar to those that had been around during the XP early days. There didn’t seem to be any general list for “agile practices” with extremeprogramming and scrum-dev mailing lists. It’s also not the first time practices have had their own list, like the pairprogramming or the test-driven-development lists. We did note down that there were several potential ones the community could have joined including lean-agile, lean-dev instead of creating their own kanban-dev.

In the afternoon, I went along to the panel on Lean Software Development although I seemed to come away with the same questions and less answers. One of my questions about budgeting was answered by the next morning’s keynote, while another focusing around the lack of discussion around practices seemed to be dismissed by Mary Poppendieck as, “I don’t believe in practices”, maybe best surmised as, “I don’t know” (which I would have also been happy to take).

The evening was an impromptu beach BBQ held by the awesome folks at Agical. Whilst a small company, I’m glad to see them still as passionate and having grown year upon year with more enthusiasm about a huge variety of topics. The BBQ was amazing and I know that everyone had a great time.

More to come…

XP2009 Day 1

June 1, 2009 / / 0 Comments

General impressions about the conference
I really enjoyed this year’s conference with the combination of a remote island in Italy and the small numbers (100+) giving many great opportunities for chatting with our experienced practitioners, and a handful of academics about lots of different topics. I found it refreshing that there seemed to be significantly more experienced practitioners and thus, I found it extremely nice to be able to chat about similar experiences rather than simply unidirectional advice I find when present with a higher proportion of beginners.

conferencepool

Who wouldn’t want to gather around this place for some great conversations?

The quality of sesions was better than the last two conferences, once again focused less on the introductory nature and more focused on specific aspects. Of course, I had recommendations about how to improve, particularly the organisational aspects, of the conference and I’ve at least had an opportunity to give that feedback having shared a return train with one of the organisers for next year’s conference.

Thoughts about the first day
The first part of this day was a keynote delivered by lean evangelist, Mary Poppendieck. Titled, “The Cultural Assumptions behind Agile Software Development”, Mary proposed that there are several (American-style) cultural assumptions behind many of the agile practices that make it all the more difficult to implement. She referenced heavily the work discussed by Geert Hofsted in his book, Cultural Dimensions.

I didn’t find the keynote particularly inspiring, nor particularly challenging. Country-based cultural dimensions are just one of the factors that permeate the way that people behave. As an agile consultant, you end up fighting corporate culture, and the systems that encourage and maintain that corporate culture and I see country-based cultural dimensions yet another contributing systemic effect. This does not mean that just because a country has a high degree of individualism, working in pairs or working collaboratively in a team will be impossible (perhaps just all the more difficult). As much as I enjoy hearing Mary speak, I also found her presentation a little bit too heavy in the whole powerpoint presentation with far too much text and outdated clipart.

I also ran my workshop in the morning, titled “Climbing the Dreyfus Ladder of Agile Practices” and want to thank all the experienced people that attended as it resulted in some really rich discussions. We managed to discuss seven different agile practices in detail, brainstormed a large set of behaviours for each, classifying them and classifying them into the different levels described the the Dreyfus Model of Skills Acquisition. The results from the workshop can be found here (photos to be updated).

In the afternoon, I helped out Emily Bache’s coding dojo, focused on Test Driven Development. We saw four different pairs tackling four different coding problems using different tools and languages. I learned about the tool JDave (it’s still a little bit too verbose for my liking), and saw different styles in the way that people executed the code kata. For me, I was hoping to demonstrate more on the pair programming side of test driven development as a pair, and I had a lot of fun even though I felt a little bit out of my depth with the tools. Thanks to Danilo for complementing my lack of experience with tools like Cucumber. 🙂

More to come…

Improving Collaboration Between Developers and Testers

April 30, 2009 / / 5 Comments

One of the biggest divides you need to cross, even on agile teams, is the chasm between testers and developers. By the nature of their different roles there will always be tension with developers focusing on creation, change, and construction, and testers focusing on breaking, destructive, and exposing questionable system behaviours. It’s essential that both organisations and, in particular, individuals realise what they can do to ensure this tension doesn’t dissolve into an exclusively confrontational relationship.

catdogfight

Photo taken from Sephiroty’s Flickr stream under the Creative Commons licence

Recently, a new QA person highlighted this very issue for me. I’d finished some functionality with my pair and the QA had been testing it after we declared it ready to test. They came along to my desk and said, “I’ve found some defects with your code.” Internally I winced as I noticed myself wanting to say, “There’s nothing wrong with my code.” It got me thinking about why.

Evaluating people puts them on the defensive
Just as giving effective feedback should focus on behaviour, poor feedback makes a person feel criticised. When the QA said that there are some “defects”, it implied a broken state that you had to fix it. Made worse is the way that they said it made it feel like they were blaming you, and it’s very hard not to feel defensive in a situation like this. A very natural outcome is to pretty much deny the “evaluation” which I’m sure anyone in our industry would have witnessed at least once.

Avoid terms like “defect”, “broken”, “bugs”
One of the biggest differences working with agile testers versus testers who come from traditional backgrounds is the terms that they use. Traditional testers constantly use the words above. Agile testers focus on discussing the behaviour of the system and what expected behaviour they would see. They only use the words above once they have agreement on both of the both the current and expected behaviours. I definitely recommend you do not start a conversation with the words above as they all carry some connotation of “evaluation” and I’m yet to meet someone who truly feels comfortable being “evaluated”

Focus on Effective Feedback
Effective feedback follows a neat and simple pattern:

  1. What behaviour did you see?
  2. What impact did it have?
  3. What do we want to change?

Testers should use a similar series of questions (in order):

  1. What behaviour did you see?
  2. What behaviours did you expect to see?
  3. What are the consequences of the current system behaviour?
  4. Is that desired or undesired?
  5. Do we need to change it?

Apply the guideline above and watch the collaboration improve!

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑