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.

10 comments

  1. Rupesh

    1. I specially liked the Feature walkthroughs. It gave a clear idea about how each story will be linked together to build the functionality.
    2. Also the devs and Qas knew whom to approach if they need to discuss the technical implementation for a given story.

  2. Pingback: Dew Drop – July 16, 2012 (#1,364) | Alvin Ashcraft's Morning Dew
  3. Pingback: Becoming a Tech Lead « Anne J Simmons
  4. Pingback: Top Picks: Miscellaneous | Peter-John R. Lightfoot
  5. Pingback: Reflecting on Feature Leads | thekua.com@work
  6. Peter Zsoldos

    Sounds like a nice idea – could you give some more context? E.g.: how big were the teams, how many features have you had going in parallel? Did the feature lead become an (IT) feature owner, who would be consulted in case of enhancements and/or maintenance/production issues?

  7. Patrick

    Hi Peter,

    Thanks for the comment, and happy to provide more context. The team was not so big (maybe 14 developers at its peak). The business wanted a lot of features designed in parallel to support their planning. I think, at one point, we had about 10 large feature areas that required effectively architecting and designing a software solution. Most frequently we would have about three or four feature areas in flight.

    And yes, the feature leads (we had two!) did become a feature owner but only in the technical sense.

    I think one reason it worked so well was the business didn’t have a very strong Product Ownership model – there were so many different stakeholders so having one person cater to all those and still have some context of what was going on was pretty much impossible.

    Hope this answers some of your questions.

  8. Peter Zsoldos

    Patrick,

    thanks for the response! Your questions did answer a the questions.

    I think this approach could work on smaller teams too that caters to many different stakeholders/customers (typical setup in small-medium sized companies to have a singe”back-office” team that does everything). What often happens there is the team lead, who is still a developer at heart, who becomes so entangled in managing the clarifications, requests, etc. that (s)he has no time left for actual development (and often is not happy with that).

    Did you find this change came natural to the developers turned feature leads? I.e.: was it the case that the ones with a natural tendency towards playing a BA role volunteered for this (or were assigned) or it was a rotational role involving everyone, with you coaching them initially?

  9. Patrick

    Hi Peter,

    Thanks for continuing the conversation and your thought-provoking questions. I agree that the approach could work well with teams of any-size, and what you mention makes a lot of sense.

    I don’t think all developers suit Feature Leads and the support each person needed depended on their background. For instance, those with less exposure to a variety of situations would need more help coming up with a robust design that would enable evolving over time. I found that some developers also preferred to implement a solution, when for me, the best solution is actually avoiding the creation of software if possible. Some developers would also consider cross functional requirements (such as supportability, monitoring and consistency of platform) more than others, but that was part of the whole deal. My role as Tech Lead involved helping people through that thinking and also ensuring an overall consistency of approach.

  10. Pingback: Peter-John R. Lightfoot | Top Picks: Miscellaneous

Leave a Reply