Category: Learning

Reflecting on Feature Leads

Last year, I wrote about trialling the idea of Feature Leads. I think the idea worked out and I would encourage more teams to adopt this approach. It helped devolve some of the responsibility and made the work more engaging for developers. Looking back at the list of things to consider, I would now add more items.

What is missing list?

  • New environment needs? – Do we require new environments to support business stakeholders in their own testing, or do we overload an existing environment? If we rely on external dependencies, can they support the number of environments that we need.
  • Identify external dependencies – If we are working with external vendors, we need to probably be a bit more upfront in working out when key dates are so that we can co-ordinate
  • Has the business made any external/internal commitments – As much as teams get frustrated by arbitrary dates set by the business, it’s useful to know if a) any have already been set, or b) business stakeholders want to communicate dates because that means you need to manage expectations and ensure that those commitments are balanced with other priorities going on.
  • Is the solution simple, but evolvable – Does the approach make any anticipated work harder than it needs to be? Does it balance out time to market? Can we go for an even more lightweight solution and substitue a more complex one later if needed?
  • Do we need to build anything for the feature? – Is software even needed, or can some lightweight business process take care of the need? If we build this, how long will be used, and therefore how much effort in maintaining it/adding automated tests around it?

Looking back at the list of responsibilities, I think these elements help add to a standard list of what things to consider when designing any sort of software solution, and not just the building of it, but thinking about the long term effects of it (who uses it, who’s going to run it, who’s going to maintain it).

Looking back at a year with a client

Over the last twelve months, I’ve worked with a client to rebuild a digital platform and a team to deliver it. It’s now time for us to leave, and a perfect time to reflect on how things went. The digital platform rebuild was part of a greater transformation programme that also involved the entire business changing alongside at almost all levels of people in the organisation. The programme also outlined, before we arrived, outlined a complete change in all technology platforms as well (CRM, CMS, website) to be rebuilt for a more integrated and holistic service offering.

Our part in this program turned into building the new web digital platform, working against a very high level roadmap, and a hard marketing deadline. We ended up building the site using Ruby on Rails serving content driven by a 3rd party decisioning platform (much like Amazon recommendations) guided by the business vision of better tailored content for end users. We didn’t have much input into the final choice of several products. I’m very proud of the end result, particularly given the tense and short-timed framed environment in which we worked. Here are some examples of constraints we worked with:

  • 4 Product Owners over the span of 11 months – From January this year, through to the end of October, the business was onto its fourth Product Owner for the digital platform. Building a consistent product is pretty much nigh impossible with changing product hands, and trying to bridge work from one Product Owner to the next was definitely a challenge.
  • Constant churn in the business – The 4 product owners is one instance, but we would often be working with people in the business to work out what should be done, only to find that the following week they were no longer with the business.
  • 3 Design Agencies engaged resulting in “reskinning” approved by the board before the 6 month public launch – We saw several “design changes” done by firms well stocked with people capable of generating beautifully-rendered PDFs that were signed off. However often these would imply new functional work, or be impractical to the web medium.
  • Marketing deadlines announced well before the development team had been engaged - A common pattern in the business was marketing launching a press release announcing a date, well before the people involved in delivering it were made aware, or even consulted on it.
  • PM Explosion – At one point, it felt like we had more Project Managers on the group planning out work with budgets and timelines that would be approved well before the development team had been approached.

Even with these constraints we’ve been able to deploy to production 37 times in the last three months and more since the original MVP go-live in July. Part of what I’m particularly proud of is the team where we were able to achieve the following:

  • Building an Evolvable Architecture – We questioned the original choice and need for a CMS but with a constraint that a decision had been made on buying these tools, we architected a solution that would hide the implementation details of the CMS via a content service. With our TW experience and pain dealing with CMSes that are shadowed by business need, we wanted something that would not constrain what the business could achieve (hence the decoupling). We even had a chance to prove this out when the business requirements quickly hit the limit of the CMS’s built in categorisation module.
  • Responding to Change – The business roadmaps seems to change on a daily basis, and our team was able to quickly tack to accommodate these business changes. We changed the team structure as the team size increased, changed the team structure as we went live, and again as people in the business changed. Whilst our process felt similar, it would look nothing like a textbook XP, Scrum or Kanban process.
  • Improving the Process – Our team has been constantly trying to change the process not only internally to the development team, but also helping people in the business find ways of improving their own way of working. Progress has been slow as the change that starts falters as people leave. Retrospectives have been a key tool but also has the ability for the team to feel empowered with recommending and pursuing improvements they see fit.
  • Setting an example of transparency – Showcases are key to the business, and we would offer fortnightly showcases to the features built to the entire organisation. Huge numbers of people came along and I found it fascinating that it was one place where people had an opportunity to talk across silos. This sometimes slowed down our ability to show what we had actually done, but I felt exposed missing communication structures that people still needed.

At a technical level, I’m really proud of some of the principles I wanted to achieve at the start and that the team lived throughout (I’d love to hear what their experience is). Some of these include:

  • Fast developer setup – Getting started on each new machine should be fast without complicated installation processes
  • Developers rotating through operations – There’s nothing like supporting the code you wrote to help developers understand the importance of logging, test cases that are missed and just experiencing what production support is like
  • DevOps culture – Everyone on the team is capable of navigating puppet, knowing where to look for configuration changes and ensuring that applications are configurable enough to be deployed without special builds across environments.
  • Continuous Delivery – Our second product owner (the first transitioned out the day we went live) actually asked for us to release less often (i.e. it is a business decision to go-live) so that they could work with the rest of the business to ensure they had their non-IT dependencies in place.
  • Devolved Authority to Feature Leads – I blogged previously about Feature Leads who could help shape the technical solution and drive the knowledge for the project.
  • Metrics Driven Requirements – Though not completely successful, we were able to stop the business from implementing some feature by showing them production metrics. In this case, we were able to avoid building a complex search algorithm to show that we could achieve the same result by adding to a list of synonyms on search.
  • Everyone grows – If I look back at the project, I think everyone on the team has experienced and grown a significant amount in different ways. I think we struck a good balance between being able to work towards individuals goals and find ways they could help the project at the same time.

Other particular things I’m proud of the team:

  • Taming the Hippo - Worthy of its own post, Hippo CMS has been one of the least developer friendly tools I’ve had to deal with for some time. The team managed to work out how to run an effective functional test around its poor UI as well as deploy and upgrade the beast in different environments without the 12 step manual process outlined on their wiki.
  • Rapid team size – Management wanted the entire team to start at the same time. Even being able to push back, we ended up with a very aggressive ramp up and we still managed to deliver well.
  • Diverse but co-operative – We had something like 17 people and 14 different nationalities and it’s one of the strongest teams I’ve seen who were able to work through their differences and forge ahead.

Things that I would like to be different:

  • Find a way to code a lot more – Due to the circumstances, many elements drew me away from coding. At best, I can remember pairing with someone for at most two days a week (for a short time) and I would like to find a way to do that more.
  • Implement more validated learning – Although dependent on a product owner willing to do this, I would have liked to work more on trying to build and experiment a lot more.
  • Have a stronger relationship with decision makers with authority – I believe development teams work best when they are connected to people who can make decisions, not just organisational proxies who provide answers. Unfortunately I felt most of this cascaded very far up the organisation and due to the constant flux and organisational change, this wasn’t possible in the timeframe. I’m hopeful that as the business matures and more permanent people find their place, this will be more possible.

Spike Showcase

A key concern of mine, as a Technical Leader is ensuring that knowledge is distributed on a team. Working on a large team makes that a challenge because so many changes happen at the same time, but you’re also dealing with multiple learning and communication styles. This means that one technique doesn’t work as well as another. Due to my passion for learning, I try to keep this in mind and try to ensure we use multiple channels for getting information to everyone.

One practice we’ve been experimenting on our project is one we call, “The Spike Showcase”. Spikes come from the Extreme Programming methodology and represent an investigation into an area the team doesn’t have knowledge of. We create one of these when we need to generate options for the business, or when we are dealing with a new integration point and want to assess the quality, testability, or best designs. That knowledge is normally take on by a pair and remains dangerously siloed on a fairly large team.



Image sourced from drubuntu’s flickr stream

The pair normally writes up their outcome on the wiki (for long term purposes) and they have an area where they can check in their code for reference, yet documentation is not very engaging and I know that most people on the team won’t look at the code unless they are going to work in that area because they are busy doing other things. Pair programming solves this problem to a degree, but on a large team would take a long time to distribute the information.

Our solution has been to hold a “Spike Showcase” where the pair who completed the spike hold a session with the entire development team, talking about what the problem space is, what they tried, and running through the design and solution. Depending on the type of problem being solved, the pair will use a white board to diagram the logical interactions, or show some screenshots of what they were trying to achieve from a business sense and then they will demonstrate the spike solution in action before finally showing the code and how it all works. We then run some question and answers with the team (allowing people to pull knowledge) before finishing up.

We have run several “Spike Showcases” now and I feel they are invaluable to ensuring a large team keeps abreast of various solutions going on.

Book Review: Strengths Based Leadership

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

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

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.

Learning with lunchtime videos

One of the greatest things I appreciate about my work colleagues is their passion for learning and growing themselves as people. As an example, one of my work colleagues, Duana (@starkcoffee), brought in the practice of Friday lunchtime video sessions at a common client of ours last year.

To make it effective, and to make it relevant to all people, she worked with everyone to brainstorm a list of videos that we could watch over lunch. We would bring sandwiches, or grab food to bring back to the office where we sat in a meeting room watching these videos over lunch. The goal was to try to watch a video that worked not just one part of the brain that we used in day-to-day programming, but to watch videos that would inspire and exercise the other half.

I really enjoyed the practice and need to remind myself of this great ritual. It brought people together from different parts of the organisations, and was great watching a number of different topics from different areas. We watched a number of videos from technical sources loaded onto places like InfoQ, or Vimeo and sourced a number of other “alternative” videos from sites like TED or Youtube. The challenge was finding two short videos that you could watch over a lunch-hour, so we tended to go for 15-20 minute videos.

Here’s a list of great videos to get you started:

Applying learning theory to a real language

My current project work colleagues know I’m learning German while I’m here in Berlin. I doubt I’ll become fluent by the time I leave, but I feel I’ve learned plenty – even without being able to speak it full time at work, or with very few official German lessons.

I feel part of what has helped me successfully accelerate my learning is applying my understanding of learning styles to learning a “real” language (not a programming one for once!) Some of the lessons learned include:

Showing my ignorance – I talked a lot about this during my Beginner’s Mind talk. Being in Germany, I’m surrounded (mostly outside of project work) by people who are experts in the field of the German language. By attempting (and generally failing fast!), I can find out where the current limits of my vocabulary, sayings and articulation is. Trying again then lets me practice more and more.

Accepting that it is the way it is – The hardest things about learning other languages is the “nuances” that come along with the language. Real languages are “loose” with their meanings, and just because you say one thing in English doesn’t mean you can translate it word-for-word to another.

Find multiple “masters” – Just like there is no single “agile” way of working, and there is no “correct” philosophy, it’s good to have multiple teachers and sources of truths. I’d had a few official German lessons, I listen to Pimsleur audio guides, use Rosetta Stone for learning, (try to) read German magazines and try to use German where I can. Each source focuses on different things and all useful in different ones. Pretending that you can learn everything from a single source is destined for failure.

On the way to 10 000 hours – I believe learning real languages takes much longer than that, but trying to use it and practice it as much as possible has definitely improved my novice skills. Even native Germans have commented on how quickly they’ve noticed the language skills improve.

Vocabulary and grammar work as a system – Learning vocabulary without grammar makes you sound strange, and grammar without vocabulary really limits your conversations. Learning both at the same time forms an amplifying loop that allows you to learn more faster.

Align your passions – Anyone who knows me will know I enjoy my food and drink. I blog about it and love discovering neighbourhood gems in a new city. So much so my biggest asset in learning more German has been the Zitty Berlin Essen + Tricken (Food & Drink) magazine special that details restaurants, cafes, and bars around Berlin. I spend time translating each small review of each place and because I’m familiar with many of the places, I can better understand what they’re trying to say. Admittedly I’m not sure how much use all of the language is but it certainly is helping.

Three Days of Clojure Joy

A couple of weeks ago, I sat in a training class run by Stuart Halloway, CEO of Relevance and who ThoughtWorks happened to bring across from the US to give us the low down of Clojure.

We covered a lot of material in the three days – covering pretty much every aspect of Clojure. We learnt all the basics such as core data types, namespaces, how to get documentation and examples, and many of the key functions that come as part of the core clojure libriares.

I appreciated the time spent discussing the background of why clojure exists, and the alternatives that are present in many other languages. It was great to have someone as knowledge as Stuart as we could ask as many questions as we like about things.

The training wasn’t just all talking and we did do a few exercises. I have to admit because I hadn’t touched any real functional programming since university, many of the exercises towards the end of the three days went over my head a little bit – a combination of needing to know some key clojure functions, and probably needing to re-adjust to a “functional way of thinking” which I think proves the biggest challenge.

In terms of tooling, we used the simple REPL and whatever environment we chose (the exercises don’t really need that much) although I learned about ParEdit that seemed to be quite useful.

I also learned about a new datastructure – Bit Partitioned Hash Trees (more here and here that I need to do some more reading around.

The course accelerated quickly, covering basic functional programming on the first day, the different ideas between state and time in clojure and then syntatic programming. Also we covered topics such as Interoperability with Java libraries and the problems that protocols address and defrecords (prefer defrecords over deftypes as the latter is now considered deprecated).

Just like any good training course, it left me realising how much more I need to learn and get my head around. This only really comes with more time and practice.