jcfausto

Opinions, thoughts, and ideas on leadership, management, software development, and people development.

Category: Teams

What Is A Feature Lead?

There’s a lot of resources explaining more in details many roles in IT, but one in particular I think it’s not well defined or explained. The Feature Lead.

I have an overall idea of what this role should do and which behaviors or skills people on this role will have to develop or show in order to make the most out of it and really create an impact.

In order to share these thoughts I’m drafting an e-book that will bring a more detailed perspective on this subject. See below an excerpt of the first chapter.


What is a Feature Lead?

The Feature Lead is a role – a set of responsibilities – that can be deployed inside software development teams as a mean to empower people to take ownership and make decisions regarding the development of new features, creating a more fertile environment for growing self-managed teams as well as a culture of experimentation and learning.

The feature lead is the equivalent of a product owner on the technical side of things. That means that the Feature Lead will be responsible for taking care of all the technical issues that involves the development and especially the delivery of a new feature end-to-end.

Did you know?

The definition of what a “feature” is, as we know it nowadays in software development, was described by Peter Toad in 1997 in his process for software engineering called The Coad Method, that later evolved to become the Feature Driven Development process. The core of the Coad process was an artifact, created during the analysis phase, called “a feature”. It was similar to a requirement, except by the fact that it was written using a domain language which the project sponsors could understand. The main concept is that a “feature” should be written in a way that the sponsor could agree that the feature had meaning and was required in the system [1]. Doesn’t this sound like an old relative of User Stories?

Key points:

  • It’s a role and not a job title.
  • A feature lead is responsible for feature delivery.

Did you like it? See below the outline of the e-book:


3 Voices You Should Have Inside Your Team

This article is not about the Scrum Master, Product Owner, and Dev Team. Curious? I’ll explain what I mean.

If I ask you to propose a way to organize a team that allows the team to be as independent as possible and is also capable of enabling self-management. Which approach would you suggest?

I have the feeling that suggesting Scrum as an approach for this particular situation came to your mind. Although Scrum is a very good framework to introduce the agile way of doing work it doesn’t perform very well when it comes to helping your team to be agile. It tells you what, but it doesn’t tells you how.

I’ve seen recently many teams moving away from this standard way of setting up agile teams to a more tailored solution that takes into account the company’s culture, regulations, the type of industry. I believe that agile coaches or change agents with a certain experience have acquired sufficient knowledge to create or suggest a tailored solution that will fit better the organization’s needs.

Following a generic recipe, which is essentially what frameworks are, is not your only option when it comes to enabling an agile mindset and structure. Instead, you can think and use these generic tools as a reference, cherry picking or adapting what is there according to your environment’s needs.

For instance, you should take some time to analyze and understand where are the bottlenecks, communication ruptures, etc. Understand first the environment you’re in and after think of a solution that will survive on such conditions.

Different perspectives are what you need in order to create different experiments that will allow you to really leverage agile practices inside your teams in order to get better results. I’ve thought a lot lately about many agile related learned concepts that aren’t making much more sense anymore considering the different scenarios I saw. Contexts and people changed and I believe this is one of the reasons why I’m having such thoughts and feeling.

Having the abovementioned in mind, I’d like to share a different perspective to take into consideration when trying to build an agile team. Forget about which framework you’ll use, just make sure you have three voices inside your team.

The Three Voices

If you’re serious about autonomy and self-organisation and you really want a team that “is” and not just “do” agile than pay attention to these voices.

A team without one of these three voices will not be balanced and will most likely depend on external people that speak one of the missing voices. Still, even having all the voices, there’s no guarantee that the team will be able to self-organize because voices are just one part of the equation that results in autonomous and self-organizing teams. However, having the voices will increase your odds of success.

1 – Voice of Viability

Who takes care to check if what’s demanded is viable or not?

This voice is responsible to say to the team what are the market and business needs and what are the potential solutions to fulfill these needs.

A rough example: A company that produces software designed to manage cargo ship construction, will not likely decide to add smiles to the app’s chat because that’s not what the market is demanding. It’s not a viable solution for that particular business.

2 – Voice of Desirability

Who takes care of checking if a solution is desired?

This voice inside the team will be responsible for saying if something is being desired or not but customers. In order to do that, this voice has to understand the customer world.

It’s not very hard to imagine some viable solutions, but which ones will custorems be more willing to buy? Which ones have higher changes to succeed? These are questions that the voice of desirability is reponsible to answer.

3 – Voice of Feasibility

Who takes care of checking if what’s is viable and desired also feasible?

This is the most technical of the three voices. Usually the people that will transform the idea into something concrete – that can be consumed by users – are the ones that can express this voice and say if something is feasible or not from the technical perspective.

Make use you have these three voices inside your team, and your problem regarding autonomy and self-organization will be half-solved or at least will have higher changes of being solved.


Conclusion

If you ensure that your teams have these three voices inside and those voices can talk to each other frequently and in synergy, you’ll be able to build the framework you need for your team and organisation.

© 2019 jcfausto

Theme by Anders NorenUp ↑