Digital Products Create Agility
The ability to change the world with a simple digital product is here. You can create a digital product in under four weeks that is enhancing the lives of the people that use it – globally. The opportunities are nearly endless with countless digital products coming to the market everyday be they as simple games or complex apps using cutting end smart connected technologies commonly referred to as the Internet-of-Things. Which even product you want to develop we can help and the best way of doing this is using business and team agility.
This opportunity creates a dynamic environment to operate in. Dynamic environments are defined as one which change frequently and not in a predictable way. In these environments organisations have to be able to detect and response to changes to exploit emergent opportuntities and put in protections to deal with threats. Organisations that can change detect and adapt to these changes for their advantage are by definition agile – they have agility.
Business agility and digital products work as “Product Intent”. Product Intent means organisations should look to coordinate their products (physical, digital and hybrid) into specific customer focussed outcomes on the current and future benefit of the total suite of products. Product Intent are normally formed from modelled current and future value streams which create value for a defined customer or customer group. Product Intent is constantly changing with the environment to ensure the product suite stays agile as the organisation moves forward.
You can learn more about Business Agility and Product Intent in ProdDev framework that we run workshops on to show ProdDev is used at the corporate and portfolio levels of an organisation.
Team agility is the same as business agility but the focus is on building products that customers might want and then iterating to what they can have dependant on the constraints of the build i.e. money, time, skills, etc as a single team or Product Team consisting up to eight persons. Team agility it anchored and checked against the principles and values that defined the Agile software development movement from 2001 which focussed on people: those that wanted the product (customers), those that would define the product (product teams) and those that would build it (developers). These three people should live in a world where they are satisified and motivated to define, build, and use products in a sustainable manner with the organisation (product & development) reflecting on their behaviours routinely to check they and the customer and satisifed with the work.
Teams that are running with an agile approach (behaviours and workings) use whatever methods and tools they like. At Sprightly we have teams that run a defined framework such as Scrum or Kanban and then add a selection of exotic styles that suit them but also comply to our governance approach which is super simple: is it helping the customer? is it helping you? That’s it as we trust own teams to create their own standards rather than restricting a team’s options on how to behave.
Part of our Learning service offers the opporunity to learn about Team agility so have a look or let us know for more details.
Multi-Team Agility (MTA)
Between business agility and team agility there’s a middle ground where multiple team come together to collectively solve a customer problem that can’t be done by a single product team in a time scale where it’s needed. As a preference at Sprightly we don’t like to use multiple teams on a product as it suggests the product it too complicated and therefore likely to be slower but on the occasions where multiple teams do have to be formed we use our multi-team agility (MTA) approach which we have found useful if frustrating to begin with.
MTA – Maximum of three product teams or 30 persons
The temptation to get complex things solved is to throw a lot of clever people (or just people) at the problem as traditional in manufacturing the more people of a project the more progress there would be. In physical manufacturing and operations this may be true but in digital product development it is normally the worse things to do. The reason why it can be bad is adding more people to a complex problem or complicated operation is that it slows things done and becomes very expensive. The reducing in speed is due to the increase in the amount of information that has to be coordindated between people, messaging interpretation, different working needs, and politics which becomes impossible to avoid when lots of people gather. These factors create a conservative feedback loop where the work slows to ensure that’s not being wasteful as a lot of money is being spent. Due to these reason as Sprightly we have a simple rule: 3 teams max. Anything more than this then the product needs to be designed to allow it to work with 3 teams.
Why three? Because 3 teams allows the highest cooperation without being too large to communicate – think about when you are with two other friends; it’s impossible to have two conversations with three people. There are many other reasons about the complexity of design and code that needs to be built, managing individual health in a big team, ease of conflict etc etc.
The reason why it can be frustrating to start with is the temptation to wheel in an army of people to run a technical program of work – looks busy and proactive; however that initial surge in adrenaline doesn’t last and when things go “wrong” then things get tough. So trust us and stick to max team of three.
Multi-Team Agility (MTA) – One Product, One Owner – Vision Product Owner (VPO)
At mutli-team agility there are more than one agile team with an associated product owner then how do we cope with a ownership? Simple – of the three product owners one players the lead or as we call it the Vision Product Owner (VPO). It’s important to stress the Vision Product Owner is not put in charge of the other product owners (no one is in charge as the teams and self-organising) but is responsible for the overall vision of the product as it develops for a customer. The Vision Product Owner can change but it’s good if it stays the same and offer coaching to other product owners and business users on how to keep agility at the heart of what is trying to be built.
Multi-Team Agility (MTA) – One Product Engineer, One Pipeline
With the Vision Product Owner supporting the product owners in multi-team agility the equivalent role on the development side is the Product Engineer. The Product Engineer is responsible for ensuring good coding practices and learning as the product develops through the product continuous integration (CI) and continuous development (CD) pipeline. For the non-technical a CI/CD pipeline is digital construct for the product to be easily integrated, tested, and deployed automatically. The Product Engineer working with the team engineers to build, maintain and improve develop as the product develops.
If it’s Team agility or Multi-Team agility both will work closely with support teams, third parties, and other external but needed for the product’s development through an agile practice called DevOps where developers and operations or support teams work closely together. How they do this will depend on the team but the heavy use of automation and self-healing platforms is fundamental. Learn more about DevOps in our DevOps section.
If you would like to learn more about how here at Sprightly we use Team Agility and Multi-Team Agility then have a look at the Learning section where we offer learning on Agile, Multi-Team Agile, and DevOps. We also talk about this a lot in our blog so have a look around for how we use agility to build world changing products.