“Talent wins games, but teamwork and intelligence wins championships.” ― Michael Jordan
I recently had the opportunity to conduct several agile trainings and workshops where I was requested to address “How do I optimize my agile practices to get my product in production every two to four weeks”
Almost every client I work with, is challenged to rapidly releasing features to production. One common and substantial problem many of the teams encounter is that the setup and structure of their Agile teams directly affect their ability to deliver product to market in an accelerated manner.
An Agile team is cross functional comprising of developers, architects, designers and testers.
Teams (developers, architects and testers :) ) frequently tend to focus solely on their specific tasks (architecture, automation, tools, testing, development and technology) losing sight of the primary component – organization.
One key aspect of the Agile manifesto that needs to be considered is how to organize the team in terms of value that drives domain, product and technology so that every opportunity to increase speed to market is taken. Speed and value are key. Quality is a given.
There are many ways to set up Agile teams. Below are a few key organizational principals to think through while setting up cross functional Agile teams
- Embark on the agile journey by building Value Stream/ Customer journey teams. Start with identifying streams that define a value to the customer in terms of return of revenue or a customer journey. For example if you are building a digital offering, identify components which bring tangible value in terms of added revenue, incremental revenue or retained revenue. Tangible value is the crux.
- Decompose value streams or customer journeys into Product teams. A customer journey or value will typically span across multiple products. Product teamscarry the responsibility to build the entire product. For example, to deliver a digital platform with x return of investment which is my customer journey, I would need to build a payments product, a B2B product, a cash management system, an interface to my legacy applications and so on and so forth.
- If a product is large (which will typically be the case), decompose Product teams into Feature teams. Feature teams focus on specifics. For example in a cash management system, it could be a credit life cycle management feature, a portfolio management feature, so on and so forth. This is the lowest level of team decomposition which means all of the skills necessary to architect, develop and test the feature are in that team.
- Build cross functional Component teams and /or Architectural teams. If a feature is a house, then the Component teams or Architecture teams, are the ones building the walls, electrical and plumbing for the house. Examples include; technical components, such as communication protocols, security frameworks or database encapsulation services, which can be used by all the Feature teams.
- It is necessary to first build the Product teams/Feature teams and then identify Component teams/Architectural teams which will build components / architecture that the Feature teams will consume.
- In terms of execution, the Component/Architecture teams should ideally start their sprints/iterations earlier so that the basic components are available for the Feature teams to use.Reusability and standardization is key.
In summary, intelligently thinking what I should build that maximizes value, in bite sized chunks and how I should organize my team is the key to success.
Agile teams must understand that value may increase or diminish over time and hence they need to continually inspect, adapt and reorganize.