patkua@work

The intersection of technology and leadership

Page 16 of 53

The Retrospective Handbook

August 1, 2012 / / 5 Comments

I’m very proud to announce the release of “The Retrospective Handbook: A guide for agile teams“ now available on leanpub.com.

I wrote this book as another resource to help agile teams make the most of their retrospective practice. It contains the distilled experience of facilitating and participating in retrospectives for the past eight years as well as the advice gleamed by talking to, and observing skilled facilitators from numerous conferences and agile gatherings over the years.

Author of Agile Retrospectives, Diana Larsen kindly wrote the Foreword for this book.

Book Review: Strengths Based Leadership

July 16, 2012 / / 2 Comments

Several years ago, I read the interesting Strengthsfinder book. Rather than focusing on personality, it spoke of understanding your signature strengths and the benefits of a strengths-based focus in your life. Since they, they released the Strengthsfinder 2.0 book and, more recently, the Strengths-Based Leadership book.

The latest book describes using your signature strengths in the context of a leadership position. They classify the 34 signature strengths into four categories including Executing, Influencing, Relationship Building and Strategic Thinking. The book is very quick to read with a few stories talking about different leadership styles with different strengths at play, as well as almost half the book talking about the different strengths and tips on how to lead teams with it.

One aspect I found particularly interesting was the section where they talked about their study on why people follow. Their studies came up with four key areas that a good leader provides to any of its followers:

  • Trust – Out of the four, this one seemed the most obvious to me. People have to have trust in you to lead and it is important to maintain your integrity and keep your word. It’s hard to follow someone if you can’t trust them.
  • Compassion – Also an unsurprising basic need they describe where leaders need to have empathy and show that they care for their followers. Great leadership develop their people and demonstrate care for their followers.
  • Stability – Probably less obvious that the first two basic needs, the book describes stability along with words like security, strength, and support. My take on this basic need is that followers don’t see great leaders as ones that nurture chaotic environments.
  • Hope – This basic need is not one I would have named first, but it makes a lot of sense. I’ve seen a lot of software teams stifled because their leadership emotes so many negative emotions about their situation. It’s a bit hard to follow a vision if even the leader doesn’t believe in it. Their study also discovered that although this is a key need for followers, leaders did not spend enough time deliberately creating more hope and optimism in the future (something I am definitely taking away as part of this book).

I can definitely recommend this book as a non-nonsense book that gets into relevant matter very quickly. I think the book is relatively pricey for the amount of material it contains, but I’m guessing some of the fee goes towards maintaining the website and the code you use for uncovering your signature strengths.

Talking Feature Leads

July 15, 2012 / / 11 Comments

On my current project, I’ve tried something a little bit different inspired by the work of Feature Driven Development (FDD). Although sometimes cited as an agile methodology, my perception is that it is one of the lesser talked-about methodologies. On my current project we have been trying the idea of Feature Leads for the last four to five months, and I’m pretty happy with how it has turned out.

Feature teams versus Feature Leads
FDD often talks about Feature Teams – or a team that works on the design and implementation of a feature area. Since FDD heavily emphasises more modelling up-front, these tasks also often talk about Feature Teams leading the UML modelling and design documentation that goes along with it. In our circumstance, I didn’t think it made sense to have any real Feature Teams, namely because it was a greenfield project and there wasn’t any clear way features stayed independent of each other. I favoured the XP practice of Collective Code Ownership over what specialisation a Feature Team may bring together. I wanted the best of both worlds, so I introduced the team to the idea of a Feature Lead.

What does a Feature Lead do?
Our team had a good mix of experience, and introducing the “idea” of Feature Lead without communicating some of the responsibilities would definitely lead to some trouble. When I first introduced the Feature Lead term, I outlined a list of responsibilities that would come with it. I even printed a list to give to each Feature Lead to act as the starting point for a Standard Work checklist.

I included the following activities:

  • Explore all the use cases – Arrange workshops with the business owner to understand all business objectives the are trying to accomplish. Design a solution with that stakeholder, balancing business process supported by technology. Challenge assumptions about technology constraints and solutions, and avoid building software if there isn’t a clear need (i.e. we don’t want to build the wrong thing faster). Work with me (as the overall Technical Leader) to validate the solution. Consider the end-to-end flow including business people who need to be involved in set-up, on-going maintenance or business support as well as expected outcome.
  • Explore the impact on deployment and architecture – Does the business needs/technical solution warrant a change in architecture?
  • Identify spikes as early as possible – Are there any investigations we need to explore to create more options, or to validate assumptions before committing to a solution? Separate work that is not estimable into a spike and a story (and highlight the dependency on the spike).
  • Consider external configuration – Will this work require new configuration work? How often will it change? Where will we store it?
  • Who/where is the authoritative source? – If there is new data, or a new data store, be clear about which system is the authoritative source
  • Does it make sense to re-write the backlog items? – We had already been given backlog items broken down, but often we found them with an assumed solution in place. After exploring what the business really wanted to do, the nature of the stories would most likely change.
  • Verify assumptions against new stories – With the set of stories identified, work to validate all assumptions with the business stakeholder.

How I worked with Feature Leads

After the pair iterated over possibilities and designs, I would review their solution and stories with them, ensuring that cross-functional requirements such as security, performance, etc were all taken into account and represented. I would also work with the Feature Leads to ensure the overall design worked with the other Feature Leads and that we never diverged.

Once validated, I worked with the different Feature Leads to organise a Feature Walkthrough, talking about the business problems, the outcomes and how the stories fit together to make a comprehensive solution. This Feature Walkthrough distributed knowledge to the entire team so that they had enough context to pick up a story in any feature area and understood how it worked.

Feature Lead + 1
To ensure that we never had a bus factor of one, we always identified two Feature Leads (a primary and a secondary). Both needed to involved in the design and discussions as well as the story identification process so that if one went away on holiday, or was ill, that feature area would not come to a halt. As a fallback, I would also pick up the solution if both were away.

How has it turned out?
I am personally really proud of the team, and the way that the Feature Leads lead the design. We had some great solutions and ideas, and their outputs allowed the entire team to continue to own the codebase as a whole. There are so many other dimensions to talk about, but will get around to writing about them separately.

Book Review: Getting Past No

July 14, 2012 / / 0 Comments

A long time ago, I read the very excellent Getting to Yes (1981), a book that described the difference between position-based negotiation and interests-based negotiation. The follow up book written by one of the authors, is aptly named Getting Past No in applying the same principles from Getting to Yes but provides a different technique when negotiating with another party who is unwilling to relent.

In the book, Ury describes the conditions that prevent people from getting to agreement, including your own reactions, their emotions, their position, their dissatisfaction and their power. I like the five step series that he outlines in the book:

  1. Don’t react, go to the balcony – A powerful metaphor that describes a thinking style of keeping your reactions from affecting the negotiation. Instead of giving to natural instincts of striking back, giving in or breaking off, going to the balcony offers a different alternative to approaching the situation. Take time to evaluate the situation as it will lead to the best outcomes for both sides
  2. Don’t argue, step to their side – What I like about this book is the way that Ury describes a collaborative approach to negotiation. Stepping to their side often involves acknowledging (you don’t have to necessarily agree) with the other party’s point of view. Until the other party’s viewpoint is heard, they are unlikely to hear your own.
  3. Don’t reject, reframe – Reframing involves using questioning and other techniques to change the game from a “fixed-pie” mentality to a “win-win” opportunity. Rejecting doesn’t progress negotiations. Exploring interests can. The point of this chapter talks about avoid dismissing the other party’s position, but instead trying to understand what their motivation they have behind it and finding a solution that might solve both sets of interests.
  4. Don’t push, build them a golden bridge – Ury describes this stage as one that takes time. If you try to close a deal too quickly, negotiations will break down. During this phase, you need to address unmet interests, help people save face and involve the other side in the solution.
  5. Don’t escalate, use power to educate – This section outlines a number of strategies if the other party sticks to their position and is unwilling to relent. The key to this stage is knowing both your own Best Alternative to a Negotiated Agreement (BATNA) as well as theirs. Ury recommends executing on your BATNA as this will reduce the possibilities of future transactions, but by knowing both positions, you can explore the consequences if both parties fail to agree. He talks about strategies such as using third parties and aiming for mutual satisfaction rather than adopting a victory mindset.

Resetting grant privileges on mysql root

June 12, 2012 / / 1 Comment

We had a root mysql user account given to us for a MySQL database but somehow that account did not have the ability to GRANT others any privileges. Running:

select user, grant_priv from mysql.user

showed us that no users had that. A bit of searching around and I stumbled across this blog that demonstrated how. Running the following seemed to work:

update mysql.user set grant_priv = 'Y' where user = 'root'; commit; flush privileges;

Rerunning:

select user, grant_priv from mysql.user

now showed us that the root user had the GRANT ability. The following command also confirmed it:

show grants

XP2012 Continued

May 24, 2012 / / 0 Comments

The morning started off with a keynote from Sally Spinks of IDEO talking about design thinking and their wholistic design approach to organisations and service design. From what I understood, her role involves “Organisational Design” which is an interesting concept that I initially balked a little at. How can you “design” an organisation and just expect people to play it out. Fortunately she answered that later in the talk about preparing for people to surprise you and to make sure you plan for that change. She talked a little bit about the history of IDEO moving from product design to service design to organisation design and describing how business models are the new units of design.

Being effectively a “change agent”, her most compelling message hit home for a lot of us. Set purpose. Do small stuff, tell big stories. Iterate on the purpose, do more stuff and tell more stories and keep going.

Another highlight for me was a short speech by a well known Swedish chef (in Sweden at least) called Jan Boris-Möller. He’s famous for a TV show going into people’s homes and cooking a three course meal in a a short time based on everything they have in their kitchen. He talked about leadership (setting direction for the kitchen), adaptability and understanding your constraints (e.g. catering for weddings on a farm where you limited access to power sources) and balancing personal creativity with customer success. He talked about understanding your customer and the contraints they work in. He gave the example that it is extremely rare for Swedish people to drink at lunchtime, but often drinks wine at dinner. This means that if you serve the same soup at dinner, it needs to probably be more intense in order to compete with the acidity in the wine.

He even prepared the wonderful evening meal for the conference dinner including wonderful creations including ceviches, foams and an intensely flavoured shot of soup. He

I also hosted an open space session called, “Succeeding as a technical leader” and had some really great conversations covering topics such as what makes a technical leader different from other leaders, their key responsibilities, their challenges and growth paths or how organisations help (or don’t) help them grow. We discussed items such as dealing with conflict, whether or not the role was needed and heard some great stories from the other open space participants.

I also later participated in the workshop, “Combining Usability and agile” involving both a little exercise and a healthy discussion on the different ways that teams integrate usability with agile. It was a small group but lead to some great examples and discussions.

XP2012 So Far

May 22, 2012 / / 0 Comments

Just a quick summary of the different sessions so far:

My Half-Day TDDing Javascript Workshop

I had a nice small group of people attend this workshop where I ran through this off-line tutorial available on github. The size meant that we could deviate from some of the material and talk about some topics the participants wanted to go more depth into. The attendants had a mix of skills – some with a java background without knowing javascript so well, and those with a front end background but not having done any testing before.

In the three hours, we managed to get through quite a number of the stories. I few hiccups though due to the terrible nature of missing commas, or semi-colons resulting in very difficult to diagnose code. I received some great feedback, and realised that it’s a very dense tutorial that introduces quite a lot of concepts. At the beginning, I assumed most people had read Crockford’s JavaScript: The Good Parts. I also realised that having an IDE auto-save made a big difference to running the TDD red-green-refactor cycle.

Jutta Eckstein on Agile in Corporations
I decided to go along to Jutta’s talk focusing on agile in big corporations and some of the limits created based on existing organisational behaviours. I liked some of the different things she observed and recommended such as :

  • Put customer obligations into contracts – Don’t just specify what they want and how the vendor will work. Also create mechanisms in the contract for the vendor garnering feedback from the customer.
  • Remember different stakeholders – Include operations people, founders, etc instead of just the customer. This is more important in large organisations because of the different competing needs in their ecosystem. Just a reflection of reality, not the ideal.
  • A smell for a lack of trust is the introduction of formalisation – People introduce formalities and rigid process to compensate where trust does not exist. This creates a certain amount of overhead but creates a certain amount of safety for both parties by making interactions more explicit. Be careful of this and an increasing amount of this!
  • Transparency relies on trust – Avoid certain of transparencies too early as the organisation may not be ready for it.
  • Agile development is a trouble detector – Like the lowering of a waterline. It exposes existing problems in the system, generally does not create it.
  • A reminder of the Hawthorne effect – Another introduction to the hawthorne effect where the fact that something is being studied actually alters the behaviour of the subjects under study.

Diana Larsen on People Are Funny

Had a fun, interactive series talking about Human System Dynamics Institute, and the ideas of Containers, Differences and Exchanges.

Emily Bache on Geek Feminism

Emily talked a lot about the idea of geek feminism and some helpful tips including treating minorities as the same as everyone else (and try not to go out of your way to highlight their differences, even if in a good way!). She had some great research, and references and hoping she puts her slides up somewhere.

Panel on Successful Automated Testing in Agile Environments

I spoke on this panel, turned fishbowl discussion where we talked about our experiences with teams who we think succeeded with automated testing, some the common problems when teams take on automated testing, patterns and tips on how to achieve it and then some interesting topics brought up by the audience including how to “convince” people to do TDD (The answer: Do not) as well as specific things like measuring success (e.g. don’t do it by measuring coverage).

USB Programming with Ruby

May 20, 2012 / / 2 Comments

I have a current side project of looking for a simple to construct build radiator that is reasonably affordable from a hobbyist’s point of view. I came across this blog post, that used a sub £10 USB device for displaying the state of monitors. Although good, the drivers only appear to work on linux (not on my mac!) but I decided to not let that stop me.

I spent a couple of hours yesterday reading up on USB, the options around ruby (my current project’s development language of choice) and then the source code for the linux drivers written in C++. Here’s proof that I managed to learn a few things:

Outlining some of the things that I learned:

  • Two ruby libraries exist for wrapping the generic libusb library that vouches to be cross platform (win, linux, mac). The first “ruby usb” is one that I couldn’t get working on my machine partly because I couldn’t configure it properly to read my installing libusb. I went for the libusb (for ruby) library. This proved easier as they already had a gem for it.
  • The generic USB interface is pretty well documented. This website gives a good overall introduction. The concepts translated into the library quite easily.
  • At the heart there are some simple steps, but if you plan on controlling a device, you need to know the special “byte” messages to send as instructions. I don’t have an electrical engineering background, but I’m guessing this is similar when they write device drivers. Having documentation helps (this is where looking at the device driver code helps).
  • The libusb gives some pretty reasonable error codes, and because my device simply does not respond, I didn’t have to worry so much about any other processes controlling it at the same time.

Generic steps for interacting with a USB device:

  1. Create a new USB context to discover all the devices
  2. Find the device you care about. For this device, the property idVendor is set to 0x1d34 for Dream Cheeky and the idProduct set to 0x0004). They also had some string descriptions you could use. For example, the manufacturer property returned "Dream Link" and the product returned "DL100B Dream Cheeky Generic Controller"
  3. Once you have the device you first “open” the device to get a “handle”. Your system may already have a reference to it. If so, you need to “detach the kernel driver” before claiming it. As I said, I didn’t need to although the linux driver has that code in it.
  4. With the handle, you can now send/receive information to it. The USB property “bmRequest” prepares the device for communication. This page really helped me understand more, although I simply followed what the linux driver did to know what values to set.
  5. Make sure you close the handle when you’re done.

I learned way more than I needed to about USB devices such as devices hosting several configurations (though only one at a time) and they have a concept of endpoints, but wasn’t particularly relevant. Debugging the device with irb was great fun as I could dynamically query the device as long as it was connected. I’ll write about the ruby code in a different blog post.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑