Defining your ways of working

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.

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.

Ways 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.

In 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.

Deciding as a team

As a self-organising team you need to have a shared understanding of your ways of working. You must come to that understanding together.

You 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.

What 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.

Start by defining your flow, or as you may know it, product development lifecycle. You can do this by asking your team four questions:

• How will you turn ideas into value?
• How will you work together?
• How will you seek feedback?
• How will you evolve your process?

Let’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.

How will you turn ideas into value?

The 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.

It 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.

The 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.

Therefore 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.

To create a shared understanding as a team you can map out your flow, artefacts and ceremonies on a whiteboard.

Flow

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.

Your 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.

Artefacts

Artefacts 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.

The 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.

Artefacts 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.

Ceremonies

Teams 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.

Common ceremonies include: backlog planning, backlog refinement, stand ups, stand downs, show and tells, showcases, and retrospectives.

You 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.

As 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.

Where do you start?

If 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.

What 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.

How will you work together?

So far we've focussed on processes and tools. If you've seen the agile manifesto you may now be feeling bad. After all:

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.

Individuals 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.

Together 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.

Shared values

Values 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.

The 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?

I’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.

Roles and responsibilities

It'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.

You 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.

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.

Next 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.

While 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.

Each 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.

Which 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.

By 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.

Core practices

Oh boy, I usually get really excited at this point.

Next, 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.

Product 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.

Design 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.

Technology 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.

You'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.

How will you seek feedback?

Fast 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.

Your 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.

By 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.

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.

With the team you should discuss both formal and informal ways of collecting feedback.

Formal Feedback

Your 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.

Using 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.

You 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.

Developers 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.

The 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.

Informal feedback

Your 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.

Your 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.

Your 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.

Another 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.

Your 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.

If 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.

How will you evolve your process?

I 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.

You 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.

You 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.

It'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.

By 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.