![\"Venn](\"/media/every-team.png\")
On how truly digital organisations include every team in their software development process. Technology is no longer just an IT affair.
","plain":"On how truly digital organisations include every team in their software development process. Technology is no longer just an IT affair."},"slug":"every-team-helps-to-develop-software","tags":["Software development","Software development teams"],"publishedAt":{"pretty":"10th May 2020","iso":"2020-05-10T00:00:00.000+00:00"},"featuredImage":"/media/every-team-social.png","content":{"html":"On how truly digital organisations include every team in their software development process. Technology is no longer just an IT affair.
\n
As traditional sales and service channels are replaced by digital means, software has been brought to the organisational frontline and the back office too. Software now impacts every member of staff in their day-to-day.
\nTechnology startups embrace the symbiotic relationship between software and the services they provide their customers. By pivoting and iterating both their business model and their software together, they are able to sense and respond in competitive markets.
\nThink about Uber's ability to launch a new service, Uber Eats, in response to consumer demand for simple food delivery. Their software development teams were able to respond with technology at a rapid pace that enabled them to enter a competitive market with a compelling product.
\nThe opposite is true for disrupted organisations, such as banks, as they have to play catch-up feature by feature, rather than being able to innovate their services and software in parallel. They have not embraced a sense and respond approach, they have not empowered their software development teams, and they haven't got every team in the organisation feeding into the process.
\nFor organisations to be transformed, they must ensure that every team is represented in the software development team.
\nThe value that users derive from your software is in enabling their needs to be met. Users are employing your software to complete a task; they might be buying new clothes, renewing a driving license or preparing month-end accounts. For users to do that successfully the software must too be usable.
\nAll too often software is shaped to solve organisational needs, rather than user needs. Why did I have to confirm my email address with Atlassian as I logged into Trello, even though I've been signed up to Trello for years? Why did I have to jump through confusing hoops – in this example, a multistep form – completely unrelated to my own needs of using Trello?
\nI later found that my username all over Trello had changed to an outdated username from my days of using BitBucket. To resolve that I then had to sign into Atlassian once again and change my details there, just so my colleagues that I shared Trello boards with would stop teasing me about my old gamer username.
\nOf course, organisational and user needs must be balanced. After all, it is organisational resources being spent on software so that the organisation's own needs are met. An e-commerce business wants to sell its wares in order to generate revenue and profit. That's the organisational value derived from e-commerce software.
\n![\"A](\"/media/user-org-balance.png\")
The important thing for organisations to remember, is that in order for its needs to be met sustainably, its software must also meet the needs of its users:
\nIt is therefore critical to represent both sets of needs in your team. The whole team ought to be empathetic towards both users and the organisation. User researchers and designers in particular can help focus the team on user needs, but design and research should be a team sport that everyone is involved in.
\nA subject-matter expert (SME) can also be included in your team to represent organisational policy and users within your team. Having a finance controller as an SME in a software development team developing a refunds and reconciliation service means that they will be able to explain finance jargon and can be a proxy for other finance users.
\nSoftware is critical to staff that use it to interact with customers or colleagues while performing their role. There is a huge opportunity to close the feedback loop by ensuring your software development team works closely with staff users.
\nCollocating your team with the staff who will use the software they are building will enable fast feedback opportunities. Just walk your laptop over to a potential staff member and get that feedback. There's no need to wait for testing labs in a week or two.
\nBy working closely with staff, you can not only digitise their processes but transform the way they work altogether. Coming back to the symbiotic relationship that technology startups have between business model and software, you can create this same relationship between your software development team and staff users.
\nBy mapping the processes of service areas, you can help staff get a better understanding of the way they work and this provides them with tools to self-reflect on their process and how it might be improved regardless of technology. It also provides an opportunity to support and challenge them by showing the art of the possible with software.
\nOrganisational leadership must be represented within the team. Your team requires this leadership capability in order to make solid prioritisation decisions. This leadership ought to be able to defend the teams ability to pivot and adjust their plan based on their learnings.
\nYou aren't necessarily going to be able to have the CEO of your organisation as part of your team on a daily basis; not even your CIO or CTO will be able to afford that kind of involvement if your organisation is at any kind of scale.
\nWhat you should be able to have is a service or product owner, who is involved on a regular basis and is empowered to make decisions on the organisations behalf. Your design and technical leaders within the team should also be able to make decisions autonomously regarding usability and feasibility.
\nThis leadership must be able to challenge the wider organisation. If issues outside the remit of the team are blocking progress, or if policy and service areas need to be informed by learnings from the software development process, then the leadership within the team has a responsibility – and must be able to challenge the organisation.
\nSoftware, and digital transformation in general, presents a great opportunity for organisational change. By acting more like technology startups, slow-moving organisations can begin to embrace change more readily.
\nOnly when your software development team works hand-in-hand with the wider organisation and it's users, can they maximise the impact of the software they are developing.
","plain":"On how truly digital organisations include every team in their software development process. Technology is no longer just an IT affair.\n\n\nAs traditional sales and service channels are replaced by digital means, software has been brought to the organisational frontline and the back office too. Software now impacts every member of staff in their day-to-day.\nTechnology startups embrace the symbiotic relationship between software and the services they provide their customers. By pivoting and iterating both their business model and their software together, they are able to sense and respond in competitive markets.\nThink about Uber's ability to launch a new service, Uber Eats, in response to consumer demand for simple food delivery. Their software development teams were able to respond with technology at a rapid pace that enabled them to enter a competitive market with a compelling product.\nThe opposite is true for disrupted organisations, such as banks, as they have to play catch-up feature by feature, rather than being able to innovate their services and software in parallel. They have not embraced a sense and respond approach, they have not empowered their software development teams, and they haven't got every team in the organisation feeding into the process.\nFor organisations to be transformed, they must ensure that every team is represented in the software development team.\nBalancing user and organisational needs\nThe value that users derive from your software is in enabling their needs to be met. Users are employing your software to complete a task; they might be buying new clothes, renewing a driving license or preparing month-end accounts. For users to do that successfully the software must too be usable.\nAll too often software is shaped to solve organisational needs, rather than user needs. Why did I have to confirm my email address with Atlassian as I logged into Trello, even though I've been signed up to Trello for years? Why did I have to jump through confusing hoops – in this example, a multistep form – completely unrelated to my own needs of using Trello?\nI later found that my username all over Trello had changed to an outdated username from my days of using BitBucket. To resolve that I then had to sign into Atlassian once again and change my details there, just so my colleagues that I shared Trello boards with would stop teasing me about my old gamer username.\nOf course, organisational and user needs must be balanced. After all, it is organisational resources being spent on software so that the organisation's own needs are met. An e-commerce business wants to sell its wares in order to generate revenue and profit. That's the organisational value derived from e-commerce software.\n\n\nThe important thing for organisations to remember, is that in order for its needs to be met sustainably, its software must also meet the needs of its users:\n\nIf your e-commerce store sucks and you've got competition: your revenue will not be sustainable\nIf you don't have competition: you are a sitting duck awaiting disruption\n\nIt is therefore critical to represent both sets of needs in your team. The whole team ought to be empathetic towards both users and the organisation. User researchers and designers in particular can help focus the team on user needs, but design and research should be a team sport that everyone is involved in.\nA subject-matter expert (SME) can also be included in your team to represent organisational policy and users within your team. Having a finance controller as an SME in a software development team developing a refunds and reconciliation service means that they will be able to explain finance jargon and can be a proxy for other finance users.\nSupporting staff\nSoftware is critical to staff that use it to interact with customers or colleagues while performing their role. There is a huge opportunity to close the feedback loop by ensuring your software development team works closely with staff users.\nCollocating your team with the staff who will use the software they are building will enable fast feedback opportunities. Just walk your laptop over to a potential staff member and get that feedback. There's no need to wait for testing labs in a week or two.\nBy working closely with staff, you can not only digitise their processes but transform the way they work altogether. Coming back to the symbiotic relationship that technology startups have between business model and software, you can create this same relationship between your software development team and staff users.\nBy mapping the processes of service areas, you can help staff get a better understanding of the way they work and this provides them with tools to self-reflect on their process and how it might be improved regardless of technology. It also provides an opportunity to support and challenge them by showing the art of the possible with software.\nEmpowered to challenge\nOrganisational leadership must be represented within the team. Your team requires this leadership capability in order to make solid prioritisation decisions. This leadership ought to be able to defend the teams ability to pivot and adjust their plan based on their learnings.\nYou aren't necessarily going to be able to have the CEO of your organisation as part of your team on a daily basis; not even your CIO or CTO will be able to afford that kind of involvement if your organisation is at any kind of scale.\nWhat you should be able to have is a service or product owner, who is involved on a regular basis and is empowered to make decisions on the organisations behalf. Your design and technical leaders within the team should also be able to make decisions autonomously regarding usability and feasibility.\nThis leadership must be able to challenge the wider organisation. If issues outside the remit of the team are blocking progress, or if policy and service areas need to be informed by learnings from the software development process, then the leadership within the team has a responsibility – and must be able to challenge the organisation.\nSoftware is a good excuse for organisational change\nSoftware, and digital transformation in general, presents a great opportunity for organisational change. By acting more like technology startups, slow-moving organisations can begin to embrace change more readily.\nOnly when your software development team works hand-in-hand with the wider organisation and it's users, can they maximise the impact of the software they are developing."}},{"title":{"html":"On software development teams: how to form one, what good looks like and how to set them up for success.
","plain":"On software development teams: how to form one, what good looks like and how to set them up for success."},"slug":"what-is-a-software-development-team","tags":["Software development","Software development teams"],"publishedAt":{"pretty":"6th May 2020","iso":"2020-05-06T00:00:00.000+00:00"},"featuredImage":"/media/successful-team.png","content":{"html":"On software development teams: how to form one, what good looks like and how to set them up for success.
\nDigital technology is now pervasive through societies world wide. Industries have been disrupted – even governments, too – and we now find ourselves in the software age. Software development is mainstream and organisations have now realised that in order to stay relevant they must embrace software to the point where most are now funding their own software teams.
\nWhat exactly is a software development team? The answer may seem obvious and I suppose it is in some ways – clearly, it's a team that develops software. How useful is that definition for organisations forming software development teams for the first time? What does a good one look like? How do you know if your software development team is set up for success?
\nThree factors need to be considered when developing software: value, usability and feasibility. Your team should have the necessary skills to ensure these factors are carefully balanced. The software they develop needs to be valuable, usable and feasible.
\n![\"Venn](\"/media/working-software.png\")
A successful team will weigh up each of these factors and make tradeoffs where necessary when deciding what to build, when to build and how to build. Failing to balance these factors can have undesired consequences:
\nThe last point was a little tongue-in-cheek, as you might have detected. It's an important point, though. Often business users do not get a choice in the software they use to do their job. Often their managers or directors will have made a purchasing decision based on cost rather than usability.
\nA multidisciplinary approach is needed for each of these factors to be considered. We combine two sets of needs with the skills required to develop software. We combine organisational needs with the needs of it's users to identify value. We bring both design and development folk together to translate this value into usable and feasible software, or in other words, working software.
\nThere are five properties a team must have in order to be successful in developing working software: empathy, trust, capability, time and feedback.
\n![\"Five](\"/media/successful-team.png\")
A high degree of empathy is needed when developing software and in fact, is a property of all high-performing teams. Empathy for each other is needed in order for a team to work well together and understand each other. Diversity can be a strength for teams but only when the team also has empathy. Empathy is also needed for organisational and user needs. A team must understand the drivers behind the software they are developing.
\nThe team must have trust from the wider organisation so that they may be empowered to solve problems, test their hypotheses and release the software they develop. If the team is not empowered to decide what to build, how to build, or when they can release software, they are not a software development team, they are a feature factory.
\nYour team need the capability to derive value from the business and user needs, in order to build usable and feasible software. This does not necessarily mean you need a team of distinct specialisms; you could instead form a team of generalists, but whatever you do, you need a team who are capable of developing working software.
\nA team requires the time to turn the business and user needs into working software. Every member of the team needs to be explicit in terms of their time commitment to developing the software. The team as a whole needs enough time in order to develop working software. The team needs time together where context and understanding can be shared, but also time apart to allow thoughts to be digested.
\nA continuous cycle of feedback is the only way a team will be able to test whether what they're developing is valuable, usable and feasible. Feedback is the mechanism by which a team learns together. The more frequent your team can learn, the faster they will be able to adapt their plans and deliver value.
\nEach of the properties need to be understood when forming a team, and be protected throughout the lifetime of the team.
\nA team first and foremost must have empathy for each other and the people they are solving problems for: their users and even their most tricky organisational stakeholders. Empathy must be nurtured throughout the course of the team's life in order for it to be maintained. It is critical for everyone, but especially leaders, to demonstrate and champion empathy.
\nHaving a shared understanding and purpose is a good starting point for focusing the team and fostering empathy. There a number of ways you can express a team's purpose:
\nYour team may complete one or more of the above, or use a different activity altogether, the important thing here is that they have a shared understanding of why the team exists, the challenges they face and that the challenges can only be overcome through teamwork.
\nThe organisation must trust the team to solve problems and should therefore give the team a problem to solve rather than instructions to be completed. Your team may at this point wish to define a problem statement, or the sponsor establishing the team may seek to define a problem statement with the team.
\nA good problem statement will explain a desired state or vision that isn't currently achieved. It will explain the current reality or context. It will explain the impact of action or inaction. Lastly, it will set out a question or hypothesis along with measures to prove or disprove success.
\nWith empathy and trust established, next you need to ensure your team has the capabilities and time needed to solve the problem it has been set. This means the team needs a budget to cover both staff time and expenses. If your team can't dedicate time to their mission then it won't be achieved.
\nThis also means recruiting a team with necessary skills. The team will need the leadership necessary to make decisions on value, usability and feasibility. This will often involve product, design and development skillsets, but may also include subject matter experts, senior leadership and even users.
\nFinally, the team need to define and agree ways of working that enable rapid feedback cycles. Regardless of your approach to process you need to ensure your team are regularly:
\nShort feedback cycles will minimise wasted time building the wrong thing and will guide the team towards developing working software.
\nA team must be healthy in order to be sustainably successful. The health of a team has several measures including safety, balance, learning and happiness.
\n![\"A](\"/media/healthy-team.png\")
The team needs certain safety levels in order to be honest and productive while working together. You can measure safety levels by looking at the team's ability to express how they're feeling. Can they provide and receive honest feedback? Is blame projected when things go wrong? Do they feel they can push back if they disagree? Are they able to compromise in order to move forward?
\nTeam members need to balance their work with the rest of their lives. Balance is required in order to sustainably develop software. You can measure balance by looking at how frequently people are starting early or working late in order to meet goals. Are the team taking adequate holiday? How often are the team crunching? Are there high levels of sickness in the team?
\nTeams have to be empowered to make their own decisions and solve problems. How often are your team blocked by outside influences? Does the team have the necessary leadership within the team to make decisions? Is the team trusted by its organisation?
\nTeams should always be learning. Does the team feel like they are learning on a regular basis? Is the team's confidence growing with time? Are the goals of the team in line with each member's career goals?
\nA healthy team is a happy team. Happiness is perhaps the hardest measure of success as everyone has ups and downs, and so happiness will vary but the team as a whole may still be healthy. To measure happiness you need to look at the team as a whole as well as on an individual basis. Is the majority of the team unhappy? Is only one person really unhappy? You need to dig into the why behind happiness and unhappiness in order for it to be useful. Use regular check-ins with your team to understand their happiness levels.
\nThere is only one measure of success for a software team: are they developing software that is valuable, usable and feasible? Are they developing working software?
\nThe team should be trusted to solve a problem. Along with that comes the responsibility of proving their success. This is both rewarding and fair. Proving or disproving their success is also important for feedback and adapting the plan based on new learnings. A team should have the freedom to iterate towards success.
\nMeasuring value, usability and feasibility should be a continuous process of the team. At the outset the team should have defined the reason why they exist and have a clear problem statement they are working on solving. The team should be reflecting on a regular basis as to whether they are achieving their mission.
\nProblem statements and missions can sometimes be long-lived, and so the team will also want to set out smaller problems, missions or hypotheses to work on. Each should have experiments and measurable objectives that can be used to determine success.
\nAt no point should the team consider they are done after releasing software. Before they are done they must prove what they released is working. Only then are they truly accountable and empowered to develop software that is valuable, usable and feasible. Only then have they delivered working software.
","plain":"On software development teams: how to form one, what good looks like and how to set them up for success.\nDigital technology is now pervasive through societies world wide. Industries have been disrupted – even governments, too – and we now find ourselves in the software age. Software development is mainstream and organisations have now realised that in order to stay relevant they must embrace software to the point where most are now funding their own software teams.\nWhat exactly is a software development team? The answer may seem obvious and I suppose it is in some ways – clearly, it's a team that develops software. How useful is that definition for organisations forming software development teams for the first time? What does a good one look like? How do you know if your software development team is set up for success?\nThey develop working software\nThree factors need to be considered when developing software: value, usability and feasibility. Your team should have the necessary skills to ensure these factors are carefully balanced. The software they develop needs to be valuable, usable and feasible.\n\n\nA successful team will weigh up each of these factors and make tradeoffs where necessary when deciding what to build, when to build and how to build. Failing to balance these factors can have undesired consequences:\n\nIf what you develop is valuable and usable but not feasible you'll never actually release any software\nIf what you build is usable and feasible but not valuable to your organisation, then you won't be able to claim any return on your investment\nIf what you build is usable and feasible but not valuable to your users, then I'm sorry to say but no one will use your software\nIf what you build is valuable and feasible but not usable, congratulations – you built enterprise software\n\nThe last point was a little tongue-in-cheek, as you might have detected. It's an important point, though. Often business users do not get a choice in the software they use to do their job. Often their managers or directors will have made a purchasing decision based on cost rather than usability.\nA multidisciplinary approach is needed for each of these factors to be considered. We combine two sets of needs with the skills required to develop software. We combine organisational needs with the needs of it's users to identify value. We bring both design and development folk together to translate this value into usable and feasible software, or in other words, working software.\nProperties of a successful team\nThere are five properties a team must have in order to be successful in developing working software: empathy, trust, capability, time and feedback.\n\n\nA high degree of empathy is needed when developing software and in fact, is a property of all high-performing teams. Empathy for each other is needed in order for a team to work well together and understand each other. Diversity can be a strength for teams but only when the team also has empathy. Empathy is also needed for organisational and user needs. A team must understand the drivers behind the software they are developing.\nThe team must have trust from the wider organisation so that they may be empowered to solve problems, test their hypotheses and release the software they develop. If the team is not empowered to decide what to build, how to build, or when they can release software, they are not a software development team, they are a feature factory.\nYour team need the capability to derive value from the business and user needs, in order to build usable and feasible software. This does not necessarily mean you need a team of distinct specialisms; you could instead form a team of generalists, but whatever you do, you need a team who are capable of developing working software.\nA team requires the time to turn the business and user needs into working software. Every member of the team needs to be explicit in terms of their time commitment to developing the software. The team as a whole needs enough time in order to develop working software. The team needs time together where context and understanding can be shared, but also time apart to allow thoughts to be digested.\nA continuous cycle of feedback is the only way a team will be able to test whether what they're developing is valuable, usable and feasible. Feedback is the mechanism by which a team learns together. The more frequent your team can learn, the faster they will be able to adapt their plans and deliver value.\nForming a team\nEach of the properties need to be understood when forming a team, and be protected throughout the lifetime of the team.\nA team first and foremost must have empathy for each other and the people they are solving problems for: their users and even their most tricky organisational stakeholders. Empathy must be nurtured throughout the course of the team's life in order for it to be maintained. It is critical for everyone, but especially leaders, to demonstrate and champion empathy.\nHaving a shared understanding and purpose is a good starting point for focusing the team and fostering empathy. There a number of ways you can express a team's purpose:\n\nA purpose, vision, mission and values statement\nObjectives in the form of OKRs, MOKRs and/or KPIs\nA problem statement\n\nYour team may complete one or more of the above, or use a different activity altogether, the important thing here is that they have a shared understanding of why the team exists, the challenges they face and that the challenges can only be overcome through teamwork.\nThe organisation must trust the team to solve problems and should therefore give the team a problem to solve rather than instructions to be completed. Your team may at this point wish to define a problem statement, or the sponsor establishing the team may seek to define a problem statement with the team.\nA good problem statement will explain a desired state or vision that isn't currently achieved. It will explain the current reality or context. It will explain the impact of action or inaction. Lastly, it will set out a question or hypothesis along with measures to prove or disprove success.\nWith empathy and trust established, next you need to ensure your team has the capabilities and time needed to solve the problem it has been set. This means the team needs a budget to cover both staff time and expenses. If your team can't dedicate time to their mission then it won't be achieved.\nThis also means recruiting a team with necessary skills. The team will need the leadership necessary to make decisions on value, usability and feasibility. This will often involve product, design and development skillsets, but may also include subject matter experts, senior leadership and even users.\nFinally, the team need to define and agree ways of working that enable rapid feedback cycles. Regardless of your approach to process you need to ensure your team are regularly:\n\nProviding feedback to each other\nSeeking feedback from the organisation and users\nLearning from feedback and deliberate practice\nChanging their plan in accordance to feedback\n\nShort feedback cycles will minimise wasted time building the wrong thing and will guide the team towards developing working software.\nMeasures of a healthy team\nA team must be healthy in order to be sustainably successful. The health of a team has several measures including safety, balance, learning and happiness.\n\n\nThe team needs certain safety levels in order to be honest and productive while working together. You can measure safety levels by looking at the team's ability to express how they're feeling. Can they provide and receive honest feedback? Is blame projected when things go wrong? Do they feel they can push back if they disagree? Are they able to compromise in order to move forward?\nTeam members need to balance their work with the rest of their lives. Balance is required in order to sustainably develop software. You can measure balance by looking at how frequently people are starting early or working late in order to meet goals. Are the team taking adequate holiday? How often are the team crunching? Are there high levels of sickness in the team?\nTeams have to be empowered to make their own decisions and solve problems. How often are your team blocked by outside influences? Does the team have the necessary leadership within the team to make decisions? Is the team trusted by its organisation?\nTeams should always be learning. Does the team feel like they are learning on a regular basis? Is the team's confidence growing with time? Are the goals of the team in line with each member's career goals?\nA healthy team is a happy team. Happiness is perhaps the hardest measure of success as everyone has ups and downs, and so happiness will vary but the team as a whole may still be healthy. To measure happiness you need to look at the team as a whole as well as on an individual basis. Is the majority of the team unhappy? Is only one person really unhappy? You need to dig into the why behind happiness and unhappiness in order for it to be useful. Use regular check-ins with your team to understand their happiness levels.\nThe measure of a successful team\nThere is only one measure of success for a software team: are they developing software that is valuable, usable and feasible? Are they developing working software?\nThe team should be trusted to solve a problem. Along with that comes the responsibility of proving their success. This is both rewarding and fair. Proving or disproving their success is also important for feedback and adapting the plan based on new learnings. A team should have the freedom to iterate towards success.\nMeasuring value, usability and feasibility should be a continuous process of the team. At the outset the team should have defined the reason why they exist and have a clear problem statement they are working on solving. The team should be reflecting on a regular basis as to whether they are achieving their mission.\nProblem statements and missions can sometimes be long-lived, and so the team will also want to set out smaller problems, missions or hypotheses to work on. Each should have experiments and measurable objectives that can be used to determine success.\nAt no point should the team consider they are done after releasing software. Before they are done they must prove what they released is working. Only then are they truly accountable and empowered to develop software that is valuable, usable and feasible. Only then have they delivered working software."}}]},"__N_SSG":true}