The intersection of technology and leadership

Category: Management (Page 6 of 8)

Long Feedback Cycle on a 4 Year Old Project

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

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.

Argyris’ article: Good Communication that blocks learning

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.

Systems Thinking: The Leaders Summit

I was fortunate enough to attend The Leaders Summit organised by John Seddon’s company, Vanguard. The day unfolded with plenty of people talking about applying systems thinking/lean thinking to various environments.

Given Seddon’s experience with the public sector, I wasn’t surprised by the large number of people from other public sector organisations. In fact, given the perceived ineffectiveness of many public services, I’m all for this enthusiasm and interest.

Some of my key takeaways follow, however it’s definitely worth while checking out the, very much more detailed and thorough, blogging from Benjamin Mitchell here.

Change is hard – agile transformations, same for systems thinking transformations
A lot of the presenters talked about the difficult positions they were in before looking toward systems thinking. They all had their critics, all the usual people not wanting to do things differently, and support or lack of support from management. For example, one speaker, Denise Lyons from East Devon District Council encountered the “That’s how we’ve always done it around here” mentality.

Another speaker had to sneak their change program through existing mechanisms for change and business efficiencies. Even the questions asked by the audience reflected this.

I found this interesting as these are often the same problems we see, trying to introduce agile values into the software delivery capabilities of organisations. Even many of methods for helping people with change were the same.

Pragmatic Improvement
One of the questions we often struggle with, applying lean and agile to the software delivery part of an organisation, is should we really be working on the entire organisation structure. Listening to some of the speakers is that it’s worth starting somewhere and build on that success.

Rob Brown talks about the long changes still to go rolling systems thinking out to the rest of the organisation, but there was plenty of value already generated by implementing it in that area. For example, they still have to deal with the HR challenges of annual appraisals and all the budgeting games of the larger organisation.

All the speakers emphasised the way of starting small, and building on that success. Of course, this still ensures that you take as large of a systemic view as much as possible. Some of the constraints will be out of your control.

Labels don’t really matter
As much as everyone used the labels of the Vanguard consultants, I found it refreshing to hear about people really understanding the ideas behind lean thinking from a systems perspective without getting too hung up on the labels. One of the people talked about instead of “interventions”, they did “reviews”. It was also refreshing to get Dr Steven Allder, someone who came to systems and lean thinking through Peter Senge who didn’t use the same labels but you could see the same thinking behind it.

Performance is Emergent Behaviour

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

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.

John Seddon Keynote

As part of our closing keynote, English based systems thinker and well known author, John Seddon presented his keynote. Interestingly, like many speakers these days, Seddon presented with zero slides and talked about the application of systems thinking and the work that he did.

Having been a speaker with plenty of experience, he definitely came across with plenty of confidence, timing his witty remarks perfectly. Backing them up with personal stories about their success and simple things that others could relate to, I think he definitely hit the mark as a keynote speaker getting more people to think and applying systems thinking to the work that we do.

For a number of us already interested in this field of study and almost active application, I think we were simply glad to hear about how someone has been so successful in its application. This is particularly important around its pragmatic application.

His talk reinforced the importance of helping people see the system for themselves, rather than trying to fix the problems for them and how that will lead to longer lasting results. His talk also highlighted that the work that we do in an agile world isn’t always the best place to focus our efforts because we don’t really want to be delivering the wrong thing faster. Whilst I think many practitioners realise this in the agile community, those with less experience or those simply looking to make money out of a value set do not – and something more people need to understand as it’s adoption grows larger.

Finally as much of a friendly and well opinionated man as Seddon is, he is clear where he stands with the term lean, frequently used in his vocabulary in a derogatory sense. I found this point particularly interesting because my experience, and the ideas espoused by other lean followers in the software community harks back to the value and mindset of lean, rather than the tool junkies and commercial lean people Seddon seems to associate the term with. For me it was an important reminder to validate other people’s association and anchors with words before moving towards more fruitful conversations.

I’d definitely recommend Seddon as a speaker and at least the book I read, Freedom from Command and Control.

Away Day Weekend

Two weekends ago we had our UK office annual away day. These events let us, as a group, get together and share ideas, reconnect with old faces and establish new ties with new ones. This year, we held our event at Centreparcs Elveden Forest that turned out to be a really nice venue for all of the sessions.

I attended plenty of interesting sessions including Liz Douglass’ session on building Android applications, the new Operating Model of the company presented by Stephen Forshew and a great back to basics but see them fly Refactoring session put on by Pete Gillard Moss.

I also presented alongside my colleagues, Luca and Frankie on the application we built for the iPad competition (something I’ll post about when we get our application live). In the meantime watch this space since we managed to win the competition based on the crucial judgement and critical feedback from our UK based peers.

Like most of these events I came away recharged and drained at the same time.

Presented at Universite du Si

It’s almost three weeks ago I presented at USI2010 (Universite du SI). Organised wonderfully by the Octo consulting company, the conference’s tag line, “The Annual meeting of Geeks and Bosses” captures a really good essence. Mix over conferences and events are important to ensure that communities don’t silo themselves in ways that prohibit their growth. The complexity and chaos community clearly demonstrated the value of idea cross-pollination between between professions with their think tank, the Santa Fe Institute. This event is definitely the seeds of something good like this.

To add to the mix, I had the opportunity to present my session on Building the Next Generation of Technical Leaders here. This is the first conference I’ve been to where the majority of the session were not in English. This made me think a lot about how memes spread, and how quickly this affects how adaptable a community is.

I think it is wonderful for this conference to invite speakers from non-French speaking backgrounds, as I hope that it helped seed some more ideas into a community where translating text into a local language hinders the uptake of new ideas. I know that it is much more difficult for people to understand a language other than their native tongue and I can only admire those French people willing to strike up a conversation with me during the conference where my study of the French language is what tourist books teach.

The conference was very well run and although I would like to comment much more on the presentations since most of them were in French. If you understand French, and you find yourself near Paris, then I think it’s an excellent one to attend.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑