patkua@work

The intersection of technology and leadership

Category: Learning (Page 5 of 15)

What’s in your coaching backpack?

May 13, 2011 / / 0 Comments

This morning I facilitated a coaching workshop at XP2011 called, “What’s in your coaching backpack?” It was a four hour workshop, so lots of time to go into detail. I designed this workshop to focus more on depth than breadth for the four hours. After some introductions to the purpose and format of the workshop, I got everyone to move into groups and spend some time introducing themselves to each other. In these groups, we spent some time focusing on brainstorming various coaching tools, models and techniques and we came up with a huge variety. I’ll get around to writing each one of these up (there’s quite a lot of detail) so look out for them in future blog posts. Our coaching backpacks are now much fuller than what they were before.

After a break, we then reconvened and I asked people to focus on some case studies of some coaching situations where, in their groups, using the coaching tools to articulate how they’d approach each situation. There were some really great conversations and discussions, where I hope people got a better feeling trying to see how others might apply different techniques to the situation. Having been grounded in real world experience, people also wanted to know what did happen (even though there aren’t any correct answers to case studies).

I also had a quite mini retrospective, asking the questions, “What you enjoyed about the session?” and “Suggestions for improvement?” I had some great feedback and wanted to put it on line:

  • Like – Practices and real examples, discussion and division to groups, Scrum board or presentation agenda
  • Great format, loved the taskboard, posting on wall “backpacks”, case studies
  • Good group size, great group
  • Really well facilitated
  • Interesting content generated by the open conversations
  • Sitting in the sun was AWESOME!
  • Great opportunity to discuss different approaches to coaching and agile
  • Like the idea of showing progress of the workshop at the scrum board using tasks
  • Case studies/real life examples always interesting
  • Good, clear setup with backlog
  • This was the session I got more out for my work/myself than any other session 🙂
  • The workshop format
  • Working in small teams, all adding different perspectives
  • Sun
  • Nice with practices and your communications
  • Your excellent preparation and light-weight facilitation
  • Small groups
  • Interesting case studies
  • Exchange of ideas
  • Case study
  • Very well organised and structured
  • Good atmosphere, positive energy
  • The case study discussions
  • Living whiteboard agenda
  • Maybe switching up the teams between case studies might reduce effect of powerful personalities
  • Rotate members in tables to get more ideas?
  • Suggest you split groups with the knowledge spread more evenly – you asked experience and could have used that info
  • Same team all he time. Maybe we could have shuffled people in the middle of the session
  • Changing teams after a while (e.g. at lunchtime if in for whole day)
  • I could even have a whole day of doing this without being bored
  • More practises and making the descriptions of “methods” out from this
  • Produce example tool(s)
  • Put all coaches tool/methods together and have a global short discussion
  • Common discussion about the good practices
  • Would have liked to hear/learn more about coaching techniques
  • Would have been nice with an introduction to the methods/worksheet part to get the flowing associations
  • A conclusions panel to write the achieved results

Learning a new language

April 29, 2011 / / 2 Comments

I took a week off my current project to take part in intensive German lessons. I figured having some full time theory would help round out what I’ve learned from audio guides since working in Berlin, and it’s a good opportunity to do it whilst still in Germany. In talking about “The Beginner’s Mind“, I thought I’d share how I’ve been applying these to what I’ve been doing.

Recognising I’m still a Novice
In his book, Outliers, Malcolm Gladwell talks about experts requiring this magic “10,000” hour number. I’m well far from that. Models that describe how we learn, such as the Dreyfus Model of Skills Acquisition, point out different levels requiring a different environment to further your skills.

For example, if I could speak German fluently, I would want to further hone my skills my taking part in public speaking classes such as Toastmasters or reading a book on philosophy, in German. I’m well far from that.

As a novice, I need to build a base vocabulary. I need strict rules on how sentences are (generally) formed and lots and lots of practice.

Drinking from a firehose, one mouthful at a time
When you know you don’t know everything, it’s tempting to want to take in everything. I see someone in my class writing down everything, asking about complex sentences and all the variant manners of how to say something (German is full of these!) For me, I recognise it’s just too much at a time. Learning occurs through repetition, growing a wide base, and at the same time, building on top of what you already know.

Knowing when to say enough is enough is the key to not simply being overwhelmed.

Building stronger knowledge networks
The prerequisite for building knowledge is first having a wide enough vocabulary set. This means simply getting more words and experience under your belt. As I’m growing this set, I’m searching for links between words, trying to find patterns or relationships between words. I think it’s working out relatively well with the limited set that I have, though I know that if I can find ways to remember these, it’ll be easier to remember them later.

Scandev 2011 Summary

April 28, 2011 / / 0 Comments

A couple of weeks ago 700 geeky Swedes (and a handful of other Scandinavian people) descended on Gotheburg to attend Scandanvian Deveopers Conference. It was the first year that I went along and enjoyed the experience of this conference.

The two days had plenty of options – with eleven (yes eleven!) parallel tracks including language specific ones (java, .net), mobile, upcoming things, agile methods, web, SOA, etc. Something for everyone for the most part. This invariably brought a whole collection of interesting speakers from plenty of different walks of life. I met plenty of new people and reconnected with many others.

My key takeaways
Just like many of my colleagues, I’m interested in the “what could” be for functional programming. I have my own thoughts on its applicability, relevance and maintainability to my day to day work, however I made myself attend several sessions to see what it was. Neal Ford (great presenter as usual) did a great introductory session to the mindset behind functional programming. I’m glad to see that my studies in this at university meant a lot of it I already understood (first class functions, recursion, etc). I understood, though can’t extrapolate the strength of closures (at least the way that Neal was describing them), and the real world application of currying.

I enjoyed listening to Douglas Crockford talk about the new changes in the upcoming update to the Javascript language. I found him honestly refreshing – talking about which features to avoid (and why) and which things have been added to make users’ lives much easier and still maintain backward compatability. I can’t say that I learned a lot that I could immediately apply but had to laugh at pictures like this:

I also really enjoyed Matthew McCullough’s talk on git that was both insightful and entertaining on the internals, practicals and plenty of live demonstrations using the tool. As a fairly new user to the tool, I learned quite a bit and know more about what I don’t know and can work to fill that gap.

I have to admit the keynotes didn’t really get me thinking any differently, but I think that’s more of a function of having followed Alistair Cockburn’s thoughts for some time and having worked with and understanding change (the topic that Henrik Kniberg talked about).

Optimising for info on the go

April 8, 2011 / / 2 Comments

Up in the Air represents a great example of what it’s like to be a consultant. It’s a little stark and depressing at times, yet extremely accurate in many places. Optimising workflow matters to quality of life when travelling. There’s nothing worse that being stuck in an airport when there are many other things that you can do. I can highly relate to its main character, describing what it’s like:

“That’s exactly what it is, it’s luggage. You know how much time you lose by checking in? … 35 minutes a flight. I travel 270 days a year. That’s 157 hours. That makes seven days. You willing to throw away an entire week on that?”

There are many other aspects to optimise when you’re looking at travelling like this. One of the things made difficult is digesting large amounts of content, things I would normally need to be connected online for. Here’s how I’ve optimised my workflow.

The iPad Difference
Winning the iPad in a competition we had last year made a huge difference to enabling this. It’s been the biggest enabler to reading content while being disconnected from the Internet. It’s instant on. Instant off. This means I have the opportunity to digest content on the plane while waiting for the plane to taxi, the attendants to complete their safety briefing and turn it off when instructed to do so at the flick of a switch.

ReadItLater (Speedy Digesting)
Last year I tried a couple of applications that downloaded online content for offline digesting. I signed up for the ReadItLater service and been extremely happy with it. As an application it has two modes – one for seeing the original HTML content, and the other that attempts to “smart parse” the core text of a web page, making it easier to digest. Not perfect, but I’m completely satisfied with it.

WIth this application, I send ReadItLater links (I’ll expand on this further) and then sync the application before I leave the house, for it to download all the content for later reading. It has tagging (though I don’t tend to use it as much as I did originally), its fast at rendering content and has some great features for looking at photos for those image-heavy webpages.

The clunkier and definitely less efficient alternative would be to “Save Web Page As” or “Print/Save to PDF”, transferring them to the many available PDF or content readers.

Note: I tried the other popular offline content reader, Instapaper, but ReadItLater has served me well.

Speedy Indexing via Bookmarking & Application Integration
One of the great aspects to ReadItLater is its popular integration with many applications. Initially, I used the browser bookmarking feature in firefox, chrome and safari. This means, when I find interesting links on my laptop that I don’t’ want to read immediately I simply bookmark it for reading it later. I know I’ll digest it pretty quickly on my next trip.

Book marking works okay for the odd article or two, but is a bit clunky when dealing with links from twitter. Clicking through on twitter, opening the browser and then bookmarking is a bit clunky. Particularly on things like mobile devices. Fortunately ReadItLater also have great integration at this level. Holding down on a link in both Echofon (for iPhone) and the native Twitter application on the iPad gives options to send links to ReadItLater. Works great with photo links, web links, etc.

Extreme Speedy Indexing via Application Integration with Shortcut Keys
For about two months, I used this method to read most of my content. Something that was still clunky was sending long, or particularly interesting content from my RSS Reader (Google) for offline reading. Chrome had a couple of plugins as did firefox as well as a couple of Google Reader Lab options to send an article to ReadItLater. Unfortunately most of these options weren’t as simply as a checkbox instead needing to do things like “Click Send To”, “Hover over options”, “Select ReadItLater”. Not particularly smooth.

I recently stumbled across a great RSS Reader for the Mac called Gruml. Best of all, it feels like it’s been designed for keyboard-shortcut obsessed people like myself. It syncs with Google Reader, and then, using the keyboard, I can quickly send articles to ReadItLater, as simple as hitting SHIFT-L. This makes a huge difference when I’m quickly scanning through my reader, using the arrow keys to move up and down different feed groups, articles and then choosing which ones to send. Each keystroke doesn’t block either, letting me move on to the next article to quickly send articles.

Long Feedback Cycle on a 4 Year Old Project

April 5, 2011 / / 0 Comments

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night to reskin our interface using JGoodies because he wanted make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step towards a bigger change. The real problem was that the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

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.

Speaking at QCon London 2011

January 17, 2011 / / 0 Comments

This year marks the 5th QCon London conference to be held on March 7-11, 2011. The program is full of strong and interesting topics. This year, I’ll be speaking on the Software Craftsmanship track.

I’ll avoid getting drawn into the arguments around all the blog posts going back and forth about whether Software Craftsmanship is a craft, and whether or not it’s good or bad in its current incarnation. I’ll assume that people attending this track care about getting better at what they do, focusing on how you go about doing this with a talk, “The Beginner’s Mind“.

Better yet, save ÂŁ100 by using the following code to register: KUA100. Hope to see you there.

It’s never been about what you do

January 16, 2011 / / 3 Comments

I find it fascinating talking to people about their agile implementation. Some people immediately claim they’re agile by describing the practices they use. I often ask a few more questions such as, “How is that working for you?” and they start to describe a number of problems they have. Another answer people often give is, “We’ve been doing agile for ages!”

“Doing agile” has never been the point. The agile mindset is about working with customers or stakeholders to deliver solutions whilst always continually improving. The practices are simply ways of getting there. It’s never been about what you do. What matters is how you do it.

Improving how you do something is easy yet requires constant discipline. First, you need to be continually asking yourself, “How does this practice help us?” and searching for answers to another, “How can we get better at this?” Talking to people outside your organisations often help, as does following what other people do around the world (made easy through social channels like twitter and blogs).

Reflecting on how I use twitter

January 12, 2011 / / 5 Comments

Thanks to Mike Jones, my twitter life sprung out of nowhere just over a year ago. Reflecting on 2010 got me thinking about what impact it had on my life. Twitter is a mixed bag – just like facebook is. There’s a blurring about who you are, what your interests are and what you focus on.

Most of my connections on twitter tend to be focused on my profession – those people in the development, lean, agile and systems thinking space. Less of who I follow tend to be about things going on around London. There’s this slight blurring between professional and personal lives. I don’t think this is necesarily a bad thing. Where facebook, at least how I previously used it, was more focused on the social connections, Twitter provides connections to people across the Internet I wouldn’t normally make so many connections to.

The beauty of how it works is the simplicity and openness. While facebook is infamously open with your personal data, to the degree that they’ve now changed some of that, twitter is simply open with ideas. You don’t necesarily need to “accept invites” to send messages, don’t need to join groups to participate in conversations. Where the Interent and Google provide long term storage for ideas and the enabling infrastructure, twitter is definitely more the “hive mind” of humanity as it evolves. Memes, or ideas, cascade across through retweets. More relevant, though sometimes at a cost of polish and filtering, news arrives faster than through typical avenues. Observing this phenomenon intrigues me. For that, I’m indebted to Mike Jones to setting me up.

I’ll admit I’m not the earliest adopter of technology amongst my peers. Part of twitter’s problem, for me, is simply dealing with its large volumes of data. It’s not like we’re in need of it. Emails, web pages, and RSS feeds. Twitter is yet another source to add to the list. My information coping strategy for email doesn’t translate well into how I use twitter. I operate strict, near-to-zero inbox policies, responding quickly where possible to emails, or choosing to digest and never respond.

The sheer volume of tweets sometimes forces me to discard inforamtion much more readily than I’d like and that makes me slightly uncomfortable. I’m surprised how people can follow well over 200 people, even up to 1000s and cope with effective filtering of information. I’m all about the quality, not the quantity and I’m not employed to crawl through that information for my day job.

Still, I’ve found it much more interesting participating in the experiment and seeing where it takes me. I’d be interested to hear from you on how you use twitter, or what surprises it’s led you to.

Argyris’ article: Good Communication that blocks learning

December 27, 2010 / / 2 Comments

Benjamin Mitchell asked for my thoughts on this article at the start of the month. I’ve finally had some time to read it so I thought I’d share my thoughts. It’s much easier to blog about it than to tweet it. Mitchell is a big proponent of Arygris’ work and a lot of what Mitchell talks about resonates a lot about with my own observations in the world.

This very old article, published in 1994, still holds relevance to today’s organisations and managements. I think, if anything, it’s even more relevant as organisations look to adopt agile methods and thinking to help improve responsiveness. Argyris links back stories and observations back to some of the ideas he is well known for including the difference between single loop and double loop learning and theory in use versus theory in action (what you say versus what you really do).

What stood out for me was Argyris’ interpretation of “good communication”. He uses plenty of examples where managers focus on the “positive” to the detriment of covering over their own opinions and what they really think. These examples naturally fuel his arguments between unsustainable change and how these very actions prevent people from accomplishing any learning. For me I find it fascinating his association with “good communication” meaning communication that solely focuses on “positive” emotions.

When I think of “good communication”, I more think of effective communication. For me, this is more of the idea behind the interests-based negotiation talked about in the book Getting to Yes, or the ability to really talk about the matters that really matter like in the books, Crucial Conversations and Crucial Confrontations. Lying, or hiding what you think is not what I’d call effective, or good, communication.

I still think that Argyris’ article has value and relevance for today. I see many of the examples of behaviours he writes about in managers trying to flex authority in order to empower people. I liked his description of a CEO “lending power” to people instead of trying to question why the system prevents people from taking action on their own. My only issue with the article is that he’s examples do not resonate strongly for me for demonstrating good communication.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑