![\"\"](\"/media/flow.png\")
On defining your ways of working: turning ideas into value, deciding how to work together, nurturing a feedback culture and adapting your process to meet changing needs.
","plain":"On defining your ways of working: turning ideas into value, deciding how to work together, nurturing a feedback culture and adapting your process to meet changing needs."},"slug":"defining-your-ways-of-working","tags":["Software development","Software development ways of working"],"publishedAt":{"pretty":"28th May 2020","iso":"2020-05-28T00:00:00.000+00:00"},"featuredImage":"/media/flow-with-artefacts-and-ceremonies-social.png","content":{"html":"On defining your ways of working: turning ideas into value, deciding how to work together, nurturing a feedback culture and adapting your process to meet changing needs.
\n
Software development teams are able to adapt their process to meet the problems they face. In a rapidly changing digital world, the ability to learn and adapt is a competitive advantage. Teams must be enabled to define their ways of working and continue to learn and adapt as they go.
\nWays of working go way beyond just picking a software development process such as Scrum, Kanban, or (hopefully not) SAFe. Frameworks are never complete, except may be in the case of SAFe, which in my opinion is completely bonkers.
\nIn a lot of ways, you need to forget about wholesale dropping in an entire process that was likely designed for very different needs than yours.
\nAs a self-organising team you need to have a shared understanding of your ways of working. You must come to that understanding together.
\nYou may be working in an organisation that has established processes. You may not be the first software development team to form. Your team may have even worked together before. All the same, your team will have a new purpose and mission, solving a new problem, and therefore it is healthy to explicitly define your process together.
\nWhat you decide now isn't set in stone. In fact, as you work towards your mission you will have to learn and adapt – your process should evolve as you do.
\nStart by defining your flow, or as you may know it, product development lifecycle. You can do this by asking your team four questions:
\nLet’s think about these questions and how you can work with your team to define your ways of working. You can do this when first forming your team or if your team has yet to define your ways of working together.
\nThe fundamentals of software development are simple: as a team you convert opportunities and ideas into value through delivering working software into the hands of users. Some teams call this flow a product development lifecycle. Some teams call it by the name of a particular agile framework like Scrum. What you call it isn't important, but having a shared understanding of how it works is critical.
\nIt may well be that your team chooses Scrum as their agile delivery framework of choice. Unfortunately Scrum was created by developers and they forgot altogether to include instructions on how to incorporate design in the Scrum development process. Whoops.
\nThe lack of design process in such frameworks then pushes design back into a waterfall "design up front territory" and is often disguised as a user-first discovery. Instead, you want designers and developers working hand-in-hand, working together to deliver valuable, usable and feasible software.
\nTherefore your team can start with this or that framework but you must ultimately define a flow that works for your team, probably composing a number of different methodologies. This is what some people refer to as the idea of “being agile” rather than “doing agile”. There is no magic process, the magic is in your team's ability to adapt to their environment.
\nTo create a shared understanding as a team you can map out your flow, artefacts and ceremonies on a whiteboard.
\n![\"\"](\"/media/flow-with-artefacts-and-ceremonies.png\")
As a team you need to understand how you are validating ideas and opportunities to ensure they deliver valuable, usable and feasible software. You need a way of turning those ideas into deliverable units of work. Once released, you must make sure to validate your software is having the desired impact. This is your flow.
\nYour team should be clear on the stages of your flow and what enables them to progress work from one stage to another. Your flow should be simple enough to be drawn on a whiteboard in a minute or two and I'd recommend doing this whenever you review your ways of working.
\nArtefacts are what get your product owners and delivery managers excited. Popular examples include: product roadmaps, product backlogs, user story maps, sprint backlogs, Kanban boards, etc. I warn you now, many hours have been lost in perfecting artefacts which for the most part are ephemeral and thrown away.
\nThe importance of artefacts is in their ability to be used as communication tools by your team and wider stakeholders. Artefacts don't work without shared understanding, you can't just show your boss your product backlog and expect them to understand it. Artefacts have to be used and changed communally.
\nArtefacts help you communicate the stages of your flow and the work currently in those stages. As a team, you need to agree what artefacts you wish to use and how they relate to each stage of your flow. Try adding them to your flow on the whiteboard.
\nTeams use ceremonies to communicate and to evolve their shared understanding. Ceremonies can be used to celebrate successes and learn from mistakes, and ceremonies are the places where artefacts can be changed communally.
\nCommon ceremonies include: backlog planning, backlog refinement, stand ups, stand downs, show and tells, showcases, and retrospectives.
\nYou can definitely overload your team with too many ceremonies. No one likes being stuck in a day's worth of ceremonies every week or two, no matter how much you like your colleagues. Start with a minimum and make sure you timebox them, it should be exceptional for a ceremony to run longer than an hour, and your stand-ups shouldn’t turn into sit-downs.
\nAs a team, you need to be clear on what ceremonies you wish to use, when they should occur, and how they relate to each stage of your flow. Finish the sketch of your flow by adding ceremonies to it.
\nIf you're not sure where to start, I recommend starting with a framework such as Scrum or Kanban. They provide a flow, a set of artefacts, and ceremonies though the latter Scrum calls events. I know I said you need to forget about wholesale dropping in frameworks, and you should, you can’t just expect them to work. They take time to adopt and adapt to your teams particular needs.
\nWhat you won't get from Scrum or Kanban is how your team should work together to validate ideas, develop software or prove that your software is meeting the needs of your organisation and users. Don't worry, we'll get onto that next.
\nSo far we've focussed on processes and tools. If you've seen the agile manifesto you may now be feeling bad. After all:
\n\n\n\n
Individuals and interactions over processes and tools
Manifesto for Agile Software Development
Well, I wouldn't feel too bad if I were you. It's not like the "Agile Manifesto" is saying you shouldn't have tools and processes. In fact, it's easier to talk about individuals and interactions with the backdrop of an easy to understand process.
\nIndividuals and interactions are however more important than processes and tools. The quality and impact of your work is dependent on a team that works well together. You are solving problems, and how you do that may have to change, you can't just blindly follow a process and hope for the best.
\nTogether you need to agree on your shared values that underpin your work. You will need to define roles and responsibilities that describe what tasks and activities need to be performed by the team. You should also define core practices you will use to complete your work.
\nValues are the shared attributes that you expect and encourage from each of your team members. Your values are the foundation of how you will work together as a team.
\nThe Agile Manifesto has four values that are best summarised as: human-centred, working software, communication and responsiveness. Extreme Programming (XP) has five: communication, simplicity, feedback, courage, respect. Why doesn't anyone ever add “fun” to the list?
\nI’d suggest an exercise where each team member spends some time individually coming up with values that they feel are important and align with your team's purpose and mission. You can then compare these together and arrive at 3-7 values you all agree on.
\nIt's important to remember that you're forming a multidisciplinary team and that each of your team members are contributing their various strengths to the team. Roles in your team aren't there to create silos, burden individuals, or create hierarchy in the team. Roles should create clarity on what your team needs to do, those roles may be shared by the whole team, or be mostly owned by a person with certain skills.
\nYou can draw a team canvas that includes the various stakeholders and skill sets needed in your team. On this canvas you can place post-its that represent the roles your team has decided on.
\n![\"\"](\"/media/team-canvas.png\")
If you are practicing Scrum, you might include product owner in the product circle, developer in the technology circle, and scrum master in the middle of the Venn diagram. You will also need to include roles that Scrum doesn't define, such as user researcher and interaction designer, those go in the design circle.
\nNext to roles you can put more post-its with team members' names on them. You can, and probably should, have multiple post-its for one person. For example, your whole team may each rotate the Scrum Master hat, rather than have someone in that dedicated role for the entire flow. You could also treat product ownership and user research as whole team activities too.
\nWhile not necessarily related to the roles of the team, you can also include roles and names for the outer areas of the business, if applicable to your teams work – for instance, subject matter experts, organisational leadership and key users.
\nEach role needs responsibilities that are clearly defined too. In some cases such as product owner and scrum master, you can defer to textbook definitions. Sadly though, a lot of the responsibilities of healthy and successful teams aren't defined in guides to agile frameworks.
\nWhich roles are responsible for reporting regularly to the wider organisation about the progress of the team? How will you keep an eye on team health and happiness? Code quality? Again, these might not be owned by one person but you should express these explicitly and put one or more names against them.
\nBy the end of building your team canvas, you should be clear on the roles and responsibilities based on what you know now. Bear in mind, this can always be revised later on.
\nOh boy, I usually get really excited at this point.
\nNext, your team should decide on what core practices they want to use when working together. You can roughly categorise core practices into the Venn diagram again.
\nProduct management practices might include: planning poker, three amigos or user story mapping. You could decide to maintain a physical wall for this in a shared office space, or you may decide to keep it digital, using tools like Trello, JIRA or whatever your flavour of the month is.
\nDesign practices such as usability testing can be conducted on a regular basis to ensure the software you are building is usable. You could decide to maintain a research wiki to make it easily accessible to your team as well as other teams too.
\nTechnology practices are the backbone to delivering high quality software. Your team should be adopting test-driven and trunk-based development, pair programming, small releases, refactoring, peer reviews using pull requests, continuous integration and automated deployments.
\nYou'll never complete a full list of practices, especially as you may occasionally experiment and try new things as a team. The idea here is to define a set of sensible defaults the team should always be using.
\nFast feedback cycles are a key tenet of agile software delivery. They enable your team to minimise waste, make failing safe for all and guide you towards success.
\nYour teams can minimise waste by testing hypotheses before building anything. Researchers, designers and developers can work together to define problem and solution hypotheses that enable them to test ideas. You might choose to spend a certain amount of an iteration testing hypotheses with user research, surveys, technical spikes and prototypes.
\nBy releasing software early and often your team can have earlier opportunities to learn. You can test your software with users, particularly early adopters, to ensure you are building the right thing. The more frequently you can release software, the more opportunity you have to correct a wrong or find out if an idea has failed. Failing becomes safe when failure is cheap, and you make failure cheap by seeking feedback on a daily or weekly basis which will ensure failure costs you days rather than months.
\n![\"\"](\"/media/feedback.png\")
Ensuring your team has enough feedback mechanisms built into their ways of working means that they will have regular opportunities to adjust their course. The more frequently the team can correct their bearing the sooner they will deliver software that generates value for both their organisation and its users.
\nWith the team you should discuss both formal and informal ways of collecting feedback.
\nYour team should decide what formal feedback they would like to include in their ways of working and when. This is usually done by agreeing practices that need to occur at certain points of your flow to encourage feedback. They generally should happen at those points in time unless there are exceptional circumstances.
\nUsing workshops like user story mapping and including organisational leadership, the team and other stakeholders, you can build consensus and receive feedback on your plan. Backlog planning is another way of ensuring your team can provide feedback to the product owner and vice-versa.
\nYou could consider using three amigos, a practice that historically included the product owner or business analyst, a tester and a developer. These days organisations that use automated testing may instead choose to include a user researcher or designer in place of a tester. You can use three amigos to ensure work is ready before it’s picked up for development, check that it meets the team definition of ‘done’ when complete, and then to prove it is having the impact you set out to achieve by reviewing KPIs and thorough testing with users.
\nDevelopers in your team may choose to use peer reviews before code is merged to provide the wider team, including designers, an opportunity to review work. Any visual changes should either be deployed in a dedicated environment for the review or at least be included as screenshots along with an explanation of the changes so that designers can give feedback before code is merged.
\nThe showcase and retrospective are common formal feedback mechanisms that most software development teams include in their process. The showcase enables the organisation and its users to provide feedback to the team. The retrospective enables the team to give feedback to itself.
\nYour team should also decide what informal feedback they wish to encourage. These are practices or team norms that can be used on an ad-hoc basis.
\nYour team should encourage a feedback culture where feedback is shared on a frequent basis when things go well and when they don't. Feedback cultures like this however require constant maintenance ensuring that team members feel safe receiving and giving feedback. It’s worth it though, after all, feedback is a gift to both your colleague and your future self.
\nYour team might occasionally include hypothesis testing as part of your iteration goals. By testing hypotheses in your iterations your team can work together to test ideas, whether that’s in user testing labs or building a prototype.
\nAnother practice you could adopt is research and design reviews, where the team gets together to review new research developments and designs in whatever form they take. This is an opportunity to review and critique designs with a cross section of the team.
\nYour team might choose to encourage pair programming some or all of the time. This enables pairs of developers to provide immediate feedback to each other as they work on a feature.
\nIf your team is collocated with organisational users, or can easily get to them, then encouraging ad-hoc by walking over to those users with laptop in hand to check something ensures very immediate feedback. You need to establish some etiquette with your users if you are planning on doing this, though. Try not to be “that” person.
\nI hope you didn't think you were going to define your ways of working up front and then be done with them? We’re talking about agile here rather than waterfall, buddy.
\nYou might find these ways of working difficult to uphold at all times. And that's okay! It's likely that they won't all necessarily meet your team's needs. You won't really know that until you get started. Rather than fascinating over it for too long, see if you can run a workshop for a couple of hours when forming your team to establish your initial ways of working and then establish a frequency at which you'll review them.
\nYou should use retrospectives as a weekly or fortnightly opportunity for your team to discuss the good, the bad and the ugly regarding your ways of working. Not every retrospective format will make it easy to do so but as long as you get an opportunity every few retrospectives that should be enough.
\nIt's worth putting in quarterly ways of working reviews with your team too. This can usually line up with your mission and quality goal reviews. Having a quarterly breakpoint to take a deep breath and reflect as a team for a day or two, or even a week, is both a great pressure valve and a revitaliser.
\nBy establishing and evolving your ways of working collaboratively, your team will work as an effective unit, be able to adapt to the challenges they face and iteratively release working software that delivers value for both your organisation and its users.
","plain":"On defining your ways of working: turning ideas into value, deciding how to work together, nurturing a feedback culture and adapting your process to meet changing needs.\n\n\nSoftware development teams are able to adapt their process to meet the problems they face. In a rapidly changing digital world, the ability to learn and adapt is a competitive advantage. Teams must be enabled to define their ways of working and continue to learn and adapt as they go.\nWays of working go way beyond just picking a software development process such as Scrum, Kanban, or (hopefully not) SAFe. Frameworks are never complete, except may be in the case of SAFe, which in my opinion is completely bonkers.\nIn a lot of ways, you need to forget about wholesale dropping in an entire process that was likely designed for very different needs than yours.\nDeciding as a team\nAs a self-organising team you need to have a shared understanding of your ways of working. You must come to that understanding together.\nYou may be working in an organisation that has established processes. You may not be the first software development team to form. Your team may have even worked together before. All the same, your team will have a new purpose and mission, solving a new problem, and therefore it is healthy to explicitly define your process together.\nWhat you decide now isn't set in stone. In fact, as you work towards your mission you will have to learn and adapt – your process should evolve as you do.\nStart by defining your flow, or as you may know it, product development lifecycle. You can do this by asking your team four questions:\n\n How will you turn ideas into value?\n How will you work together?\n How will you seek feedback?\n How will you evolve your process?\n\n\nLet’s think about these questions and how you can work with your team to define your ways of working. You can do this when first forming your team or if your team has yet to define your ways of working together.\nHow will you turn ideas into value?\nThe fundamentals of software development are simple: as a team you convert opportunities and ideas into value through delivering working software into the hands of users. Some teams call this flow a product development lifecycle. Some teams call it by the name of a particular agile framework like Scrum. What you call it isn't important, but having a shared understanding of how it works is critical.\nIt may well be that your team chooses Scrum as their agile delivery framework of choice. Unfortunately Scrum was created by developers and they forgot altogether to include instructions on how to incorporate design in the Scrum development process. Whoops.\nThe lack of design process in such frameworks then pushes design back into a waterfall "design up front territory" and is often disguised as a user-first discovery. Instead, you want designers and developers working hand-in-hand, working together to deliver valuable, usable and feasible software.\nTherefore your team can start with this or that framework but you must ultimately define a flow that works for your team, probably composing a number of different methodologies. This is what some people refer to as the idea of “being agile” rather than “doing agile”. There is no magic process, the magic is in your team's ability to adapt to their environment.\nTo create a shared understanding as a team you can map out your flow, artefacts and ceremonies on a whiteboard.\n\n\nFlow\nAs a team you need to understand how you are validating ideas and opportunities to ensure they deliver valuable, usable and feasible software. You need a way of turning those ideas into deliverable units of work. Once released, you must make sure to validate your software is having the desired impact. This is your flow.\nYour team should be clear on the stages of your flow and what enables them to progress work from one stage to another. Your flow should be simple enough to be drawn on a whiteboard in a minute or two and I'd recommend doing this whenever you review your ways of working.\nArtefacts\nArtefacts are what get your product owners and delivery managers excited. Popular examples include: product roadmaps, product backlogs, user story maps, sprint backlogs, Kanban boards, etc. I warn you now, many hours have been lost in perfecting artefacts which for the most part are ephemeral and thrown away.\nThe importance of artefacts is in their ability to be used as communication tools by your team and wider stakeholders. Artefacts don't work without shared understanding, you can't just show your boss your product backlog and expect them to understand it. Artefacts have to be used and changed communally.\nArtefacts help you communicate the stages of your flow and the work currently in those stages. As a team, you need to agree what artefacts you wish to use and how they relate to each stage of your flow. Try adding them to your flow on the whiteboard.\nCeremonies\nTeams use ceremonies to communicate and to evolve their shared understanding. Ceremonies can be used to celebrate successes and learn from mistakes, and ceremonies are the places where artefacts can be changed communally.\nCommon ceremonies include: backlog planning, backlog refinement, stand ups, stand downs, show and tells, showcases, and retrospectives.\nYou can definitely overload your team with too many ceremonies. No one likes being stuck in a day's worth of ceremonies every week or two, no matter how much you like your colleagues. Start with a minimum and make sure you timebox them, it should be exceptional for a ceremony to run longer than an hour, and your stand-ups shouldn’t turn into sit-downs.\nAs a team, you need to be clear on what ceremonies you wish to use, when they should occur, and how they relate to each stage of your flow. Finish the sketch of your flow by adding ceremonies to it.\nWhere do you start?\nIf you're not sure where to start, I recommend starting with a framework such as Scrum or Kanban. They provide a flow, a set of artefacts, and ceremonies though the latter Scrum calls events. I know I said you need to forget about wholesale dropping in frameworks, and you should, you can’t just expect them to work. They take time to adopt and adapt to your teams particular needs.\nWhat you won't get from Scrum or Kanban is how your team should work together to validate ideas, develop software or prove that your software is meeting the needs of your organisation and users. Don't worry, we'll get onto that next.\nHow will you work together?\nSo far we've focussed on processes and tools. If you've seen the agile manifesto you may now be feeling bad. After all:\n\nIndividuals and interactions over processes and toolsManifesto for Agile Software Development\n\nWell, I wouldn't feel too bad if I were you. It's not like the "Agile Manifesto" is saying you shouldn't have tools and processes. In fact, it's easier to talk about individuals and interactions with the backdrop of an easy to understand process.\nIndividuals and interactions are however more important than processes and tools. The quality and impact of your work is dependent on a team that works well together. You are solving problems, and how you do that may have to change, you can't just blindly follow a process and hope for the best.\nTogether you need to agree on your shared values that underpin your work. You will need to define roles and responsibilities that describe what tasks and activities need to be performed by the team. You should also define core practices you will use to complete your work.\nShared values\nValues are the shared attributes that you expect and encourage from each of your team members. Your values are the foundation of how you will work together as a team.\nThe Agile Manifesto has four values that are best summarised as: human-centred, working software, communication and responsiveness. Extreme Programming (XP) has five: communication, simplicity, feedback, courage, respect. Why doesn't anyone ever add “fun” to the list?\nI’d suggest an exercise where each team member spends some time individually coming up with values that they feel are important and align with your team's purpose and mission. You can then compare these together and arrive at 3-7 values you all agree on.\nRoles and responsibilities\nIt's important to remember that you're forming a multidisciplinary team and that each of your team members are contributing their various strengths to the team. Roles in your team aren't there to create silos, burden individuals, or create hierarchy in the team. Roles should create clarity on what your team needs to do, those roles may be shared by the whole team, or be mostly owned by a person with certain skills.\nYou can draw a team canvas that includes the various stakeholders and skill sets needed in your team. On this canvas you can place post-its that represent the roles your team has decided on.\n\n\nIf you are practicing Scrum, you might include product owner in the product circle, developer in the technology circle, and scrum master in the middle of the Venn diagram. You will also need to include roles that Scrum doesn't define, such as user researcher and interaction designer, those go in the design circle.\nNext to roles you can put more post-its with team members' names on them. You can, and probably should, have multiple post-its for one person. For example, your whole team may each rotate the Scrum Master hat, rather than have someone in that dedicated role for the entire flow. You could also treat product ownership and user research as whole team activities too.\nWhile not necessarily related to the roles of the team, you can also include roles and names for the outer areas of the business, if applicable to your teams work – for instance, subject matter experts, organisational leadership and key users.\nEach role needs responsibilities that are clearly defined too. In some cases such as product owner and scrum master, you can defer to textbook definitions. Sadly though, a lot of the responsibilities of healthy and successful teams aren't defined in guides to agile frameworks.\nWhich roles are responsible for reporting regularly to the wider organisation about the progress of the team? How will you keep an eye on team health and happiness? Code quality? Again, these might not be owned by one person but you should express these explicitly and put one or more names against them.\nBy the end of building your team canvas, you should be clear on the roles and responsibilities based on what you know now. Bear in mind, this can always be revised later on.\nCore practices\nOh boy, I usually get really excited at this point.\nNext, your team should decide on what core practices they want to use when working together. You can roughly categorise core practices into the Venn diagram again.\nProduct management practices might include: planning poker, three amigos or user story mapping. You could decide to maintain a physical wall for this in a shared office space, or you may decide to keep it digital, using tools like Trello, JIRA or whatever your flavour of the month is.\nDesign practices such as usability testing can be conducted on a regular basis to ensure the software you are building is usable. You could decide to maintain a research wiki to make it easily accessible to your team as well as other teams too.\nTechnology practices are the backbone to delivering high quality software. Your team should be adopting test-driven and trunk-based development, pair programming, small releases, refactoring, peer reviews using pull requests, continuous integration and automated deployments.\nYou'll never complete a full list of practices, especially as you may occasionally experiment and try new things as a team. The idea here is to define a set of sensible defaults the team should always be using.\nHow will you seek feedback?\nFast feedback cycles are a key tenet of agile software delivery. They enable your team to minimise waste, make failing safe for all and guide you towards success.\nYour teams can minimise waste by testing hypotheses before building anything. Researchers, designers and developers can work together to define problem and solution hypotheses that enable them to test ideas. You might choose to spend a certain amount of an iteration testing hypotheses with user research, surveys, technical spikes and prototypes.\nBy releasing software early and often your team can have earlier opportunities to learn. You can test your software with users, particularly early adopters, to ensure you are building the right thing. The more frequently you can release software, the more opportunity you have to correct a wrong or find out if an idea has failed. Failing becomes safe when failure is cheap, and you make failure cheap by seeking feedback on a daily or weekly basis which will ensure failure costs you days rather than months.\n\n\nEnsuring your team has enough feedback mechanisms built into their ways of working means that they will have regular opportunities to adjust their course. The more frequently the team can correct their bearing the sooner they will deliver software that generates value for both their organisation and its users.\nWith the team you should discuss both formal and informal ways of collecting feedback.\nFormal Feedback\nYour team should decide what formal feedback they would like to include in their ways of working and when. This is usually done by agreeing practices that need to occur at certain points of your flow to encourage feedback. They generally should happen at those points in time unless there are exceptional circumstances.\nUsing workshops like user story mapping and including organisational leadership, the team and other stakeholders, you can build consensus and receive feedback on your plan. Backlog planning is another way of ensuring your team can provide feedback to the product owner and vice-versa.\nYou could consider using three amigos, a practice that historically included the product owner or business analyst, a tester and a developer. These days organisations that use automated testing may instead choose to include a user researcher or designer in place of a tester. You can use three amigos to ensure work is ready before it’s picked up for development, check that it meets the team definition of ‘done’ when complete, and then to prove it is having the impact you set out to achieve by reviewing KPIs and thorough testing with users.\nDevelopers in your team may choose to use peer reviews before code is merged to provide the wider team, including designers, an opportunity to review work. Any visual changes should either be deployed in a dedicated environment for the review or at least be included as screenshots along with an explanation of the changes so that designers can give feedback before code is merged.\nThe showcase and retrospective are common formal feedback mechanisms that most software development teams include in their process. The showcase enables the organisation and its users to provide feedback to the team. The retrospective enables the team to give feedback to itself.\nInformal feedback\nYour team should also decide what informal feedback they wish to encourage. These are practices or team norms that can be used on an ad-hoc basis.\nYour team should encourage a feedback culture where feedback is shared on a frequent basis when things go well and when they don't. Feedback cultures like this however require constant maintenance ensuring that team members feel safe receiving and giving feedback. It’s worth it though, after all, feedback is a gift to both your colleague and your future self.\nYour team might occasionally include hypothesis testing as part of your iteration goals. By testing hypotheses in your iterations your team can work together to test ideas, whether that’s in user testing labs or building a prototype.\nAnother practice you could adopt is research and design reviews, where the team gets together to review new research developments and designs in whatever form they take. This is an opportunity to review and critique designs with a cross section of the team.\nYour team might choose to encourage pair programming some or all of the time. This enables pairs of developers to provide immediate feedback to each other as they work on a feature.\nIf your team is collocated with organisational users, or can easily get to them, then encouraging ad-hoc by walking over to those users with laptop in hand to check something ensures very immediate feedback. You need to establish some etiquette with your users if you are planning on doing this, though. Try not to be “that” person.\nHow will you evolve your process?\nI hope you didn't think you were going to define your ways of working up front and then be done with them? We’re talking about agile here rather than waterfall, buddy.\nYou might find these ways of working difficult to uphold at all times. And that's okay! It's likely that they won't all necessarily meet your team's needs. You won't really know that until you get started. Rather than fascinating over it for too long, see if you can run a workshop for a couple of hours when forming your team to establish your initial ways of working and then establish a frequency at which you'll review them.\nYou should use retrospectives as a weekly or fortnightly opportunity for your team to discuss the good, the bad and the ugly regarding your ways of working. Not every retrospective format will make it easy to do so but as long as you get an opportunity every few retrospectives that should be enough.\nIt's worth putting in quarterly ways of working reviews with your team too. This can usually line up with your mission and quality goal reviews. Having a quarterly breakpoint to take a deep breath and reflect as a team for a day or two, or even a week, is both a great pressure valve and a revitaliser.\nBy establishing and evolving your ways of working collaboratively, your team will work as an effective unit, be able to adapt to the challenges they face and iteratively release working software that delivers value for both your organisation and its users."}},{"title":{"html":"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![\"Venn](\"/media/every-team.png\")
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."}},{"title":{"html":"On the irony that social distancing has brought us all together more frequently. I think I'm going to need to create some digital social distancing for myself too.
","plain":"On the irony that social distancing has brought us all together more frequently. I think I'm going to need to create some digital social distancing for myself too."},"slug":"digital-social-distancing","tags":["COVID19"],"publishedAt":{"pretty":"2nd April 2020","iso":"2020-04-02T00:00:00.000+00:00"},"featuredImage":"/media/social-digital-distancing.jpg","content":{"html":"On the irony that social distancing has brought us all together more frequently. I think I'm going to need to create some digital social distancing for myself too.
\n![\"Sign](\"/media/social-digital-distancing.jpg\")
Is this how fully remote companies always feel?
\nI don't know about you but I've spent more time on video calls in the last two weeks than I ever have before. Whether it's close to 8-9 hours of back-to-back calls for work, or catching up with my family in the evenings – I'm finding myself exhausted with all this connectivity.
\nIn a moment where we are socially distancing from each other, physically we are being drawn together through digital mediums. It's lovely in a sense that we do indeed cling together – that's another tune that rings in my ear as I write this. I get warm fuzzies thinking about the love people are generally showing each other right now. My faith in humanity is rewarded by the kindness in my neighbours eyes – even if they have got their mouths covered as we exchange glances in the hallway. What a weird time.
\nI have questions, as you probably do too. I've been fascinating over why all this digital connectivity is so tiring. Why is it more tiring to spend time on calls than in the office? Why is my diary even busier than usual and why am I dialled into more meetings now, even though my workload hasn't exactly increased? If anything, it’s decreased. Weird.
\nAnother weird thing I've noticed is that we have less time for novel side chats and small talk. There’s no way to turn to a colleague and whisper something to them. I'm sure most of my colleagues are happier that I'm unable to disrupt meetings in that way – silver linings?
\nI've also found larger group meetings are more like one direction webinars. It's weird talking into a silent void. I love feedback, I thrive on it! I've also found that some interviewees really don't open up unless you give them audio cues that you're listening and engaging with them. "Everybody, go on mute" doesn't work for everybody.
\nAnyhow, I'm tired. And I can only move as slow as my diary lets me. It's time for some digital social distancing.
\nI was sitting at my desk frustrated at my calendar looking busier than ever. We had our quarterly leadership planning scheduled for Monday and Tuesday – and full-day workshops, at that. I decided to send a message on Slack to my colleagues.
\nIn the first instance I asked Rory, our CEO, if we could limit our sessions to 08:30-11:30 and then 13:30-15:30 to ensure we had big enough breaks and weren't spending more than 5 hours of the day on calls. He approved and I'm so grateful that he did; my brain felt all the better for it this week and we still achieved all our goals for the two days of planning.
\nMore generally I've put the following measures in place:
\nThe aim of these measures is to force myself and others to respect my time. It is also a way of prioritising. Much like agile delivery teams using timeboxes to constrain and force prioritisation, I'm using the same technique with all of my commitments.
\nAnyhow, trial and error, next week is my first full week with these all in place so I'll let you know how it goes. I hope I can continue moving slow.
\nI'd be interested in hearing from anyone else who is experiencing similar exhaustion from calls and what digital social distancing you might be doing to give yourself more space. Let me know what you think on Twitter @LukeMorton.
","plain":"On the irony that social distancing has brought us all together more frequently. I think I'm going to need to create some digital social distancing for myself too.\n\n\nIs this how fully remote companies always feel?\nI don't know about you but I've spent more time on video calls in the last two weeks than I ever have before. Whether it's close to 8-9 hours of back-to-back calls for work, or catching up with my family in the evenings – I'm finding myself exhausted with all this connectivity.\nIn a moment where we are socially distancing from each other, physically we are being drawn together through digital mediums. It's lovely in a sense that we do indeed cling together – that's another tune that rings in my ear as I write this. I get warm fuzzies thinking about the love people are generally showing each other right now. My faith in humanity is rewarded by the kindness in my neighbours eyes – even if they have got their mouths covered as we exchange glances in the hallway. What a weird time.\nI have questions, as you probably do too. I've been fascinating over why all this digital connectivity is so tiring. Why is it more tiring to spend time on calls than in the office? Why is my diary even busier than usual and why am I dialled into more meetings now, even though my workload hasn't exactly increased? If anything, it’s decreased. Weird.\nAnother weird thing I've noticed is that we have less time for novel side chats and small talk. There’s no way to turn to a colleague and whisper something to them. I'm sure most of my colleagues are happier that I'm unable to disrupt meetings in that way – silver linings?\nI've also found larger group meetings are more like one direction webinars. It's weird talking into a silent void. I love feedback, I thrive on it! I've also found that some interviewees really don't open up unless you give them audio cues that you're listening and engaging with them. "Everybody, go on mute" doesn't work for everybody.\nAnyhow, I'm tired. And I can only move as slow as my diary lets me. It's time for some digital social distancing.\nMy measures for digital social distancing\nI was sitting at my desk frustrated at my calendar looking busier than ever. We had our quarterly leadership planning scheduled for Monday and Tuesday – and full-day workshops, at that. I decided to send a message on Slack to my colleagues.\nIn the first instance I asked Rory, our CEO, if we could limit our sessions to 08:30-11:30 and then 13:30-15:30 to ensure we had big enough breaks and weren't spending more than 5 hours of the day on calls. He approved and I'm so grateful that he did; my brain felt all the better for it this week and we still achieved all our goals for the two days of planning.\nMore generally I've put the following measures in place:\n\nI've set my Google Calendar office hours to 08:30-15:30 – I'm not accepting any meetings outside of these hours\nI've set my Google Calendar events to only show if I've accepted them in my email inbox – this means I need to have explicitly said yes for me to attend a meeting, stopping last-minute invites that I'm not aware of\nI'm only accepting meetings of up to 2 hours per week for each service area of the business I'm involved in\nI'm continuing to provide 30 minutes every two weeks for all of my line management/career development 121s\nI'm only accepting 10 minute coffees for anyone else who needs my time\n\nThe aim of these measures is to force myself and others to respect my time. It is also a way of prioritising. Much like agile delivery teams using timeboxes to constrain and force prioritisation, I'm using the same technique with all of my commitments.\nAnyhow, trial and error, next week is my first full week with these all in place so I'll let you know how it goes. I hope I can continue moving slow.\nI'd be interested in hearing from anyone else who is experiencing similar exhaustion from calls and what digital social distancing you might be doing to give yourself more space. Let me know what you think on Twitter @LukeMorton."}}]},"__N_SSG":true}