Category: agile

Intended Audience

So you’ve bought into the SAFe brand, adopted it pretty much wholesale. You might even have had some successes after the initial adoption. But at some point, you’ve hit a plateau (or a major problem that you simply can’t get past with just SAFe’s guidance). Perhaps you need a shorter time to market than a quarterly planning cycle gives you. What do you do?

The rest of this post is structured very loosely as a set of steps. They generally make sense as a progression, but the reality is that for even remotely complex contexts, if you attempted to follow this line through just once, you’re likely to end up with more pain. There are feedback loops all over the place, and artificially trimming them into a single line is a waterfall-esque strategy for complexity management, which is suboptimal.

Step 0 – Don’t Panic!

You’re already on a transformation journey (Before SAFe -> Adopting SAFe -> Using SAFe -> ?). This is just the next step.

Step 1 – Start where you are

There’s no sense ramping up the psychological harm by saying you were wrong. Elements such as the Prime Directive of Retrospectives also echo the underlying fact that at the time, you made the best decision possible given the data you had access to. Now that you have more (or perhaps just different) data, it’s time to make the best decision possible today.

Step 2 – Take Stock

Look at what you have (in this case, SAFe) and focus on the mindset, and principles, as those generally remain valid. What will change is the practices, techniques and strategies that you use in order to sustain that mindset and deliver value continuously. For example, “Alignment” is great. SAFe’s implementation strategy for achieving alignment is generally by starting from the Portfolio level and “working down”. Other strategies include starting from the team and “working outwards”. Changing the scale of programmes of work (e.g. by picking an architectural style that facilitates this) can change the relative importance of alignment from being a pre-requisite into more of a side-effect. Disciplined Agile Delivery (DAD) has an Enterprise Aware principle that can be used to facilitate a discussion about Alignment.

Step 3 – Visualise The Implicit

Visualise your Ways of Working. (WoW). If you’ve adopted SAFe, then the SAFe “Big Picture” is probably it, or very close to it. DAD has a Program Lifecycle, which bar some label changes is very similar. Once your WoW is visual, overlay it with DAD terminology. This is a form of gap analysis and it should help you turn implicit process knowledge into explicit knowledge. The biggest insights would come from the associated “Process Goals” for the practices you are using. That’s a big step towards understanding why a practice is used. SAFe’s guidance is very good at telling you what to do and has some coverage of why it’s worthwhile. What is lacking though, are alternative approaches for achieving the same objective. That’s where DAD can offer significant advantages.

Step 4 – Target Process Improvements

With a map of process goals, now it becomes possible to target improvements to struggling areas. The areas to target will be highly context specific, and it’s worth using some root-cause-analysis techniques (e.g. 5 Whys or Ishikawa diagrams) to find them. Using a process goal as an anchor, you are more easily able to explore alternative strategies to solve the problem you’ve got. For example, if your current processes struggle with effective delivery of complex non-functional-requirements, then something like http://disciplinedagiledelivery.com/strategies-for-verifying-non-functional-requirements/ could help.

Step 4A – Have Meaningful Conversations

An interesting side effect of making your process goals visible, is you can engage your teams and stakeholders in a more meaningful discussion about the approach to the work. This can create space for highly innovative and inventive strategies for problem solving and value delivery to emerge.

Or in other words, instead of only relying on your team to think-outside-the-box, you get to redefine-what-you-mean-by-box.

Step 5 – Rinse and Repeat – Ad Nauseum

Don’t forget one of the pillars of the (SAFe) House of Lean – Relentless Improvement. Your drive to improve shouldn’t end. One of the challenges with adopting SAFe (or in fact any other branded framework that has a relatively prescriptive nature) is the illusion that there’s an End State to reach, and once you get there, you win the game.

Looking at the Twitterverse, I’ve seen a few people talk about SAFe being potentially a good way to start getting some agility into your large scale programme delivery – mainly because can be perceived by senior-management-buyers as a Tangible Thing, which is easier to accept than a grass-roots-hearts-and-minds-campaign-led-by-developers. However, at some point, a continuously evolving organisation will evolve beyond it. That said, the subset of SAFe that’s Don Reinertson’s work on Economics and Flow will remain relevant long after the SAFe practices are abandoned for more lightweight alternatives.

(or how I learned to stop worrying and love the Thinking)

Why I’m writing this

I have a new client. They’re a large Financial Organisation, therefore operating in a highly regulated market, with heavy compliance etc. requirements. The sorts of things that end up creating a paranoid organisational mindset, with a significant audit theme running through everything that they do.

The nature of this client is such that new ideas take a while (if at all) to establish. That pace isn’t helped by the fact that organisations like these generally are flush with cash – they can afford to overspend as well as maintain “death-march projects”. This is a functional characteristic and is neither good nor bad. It does, however, mean that delivery techniques that are radically different culturally to the prevailing winds are unlikely to be welcomed with open arms (i.e. there is no urgency to change). One such idea, is “User Centric Design”. This is a premise that the right thing to do is design services specifically for your Users. This cultural anchor (the Customer is central to everything) is more prevalent in front office teams (e.g. for a Bank, those might be branch staff), but isn’t necessarily the case in back office teams (e.g. the “IT Department”). User Centred Thinking may lead to better bank accounts, savings accounts, or interest rates, but is less likely to be adopted to improve the systems that an actuary might use.

Enter the labels “Design Thinking” and “System Thinking”.

What is “Design Thinking”?

The term has been gaining popularity over the last few years. I currently believe the term “Design Thinking” that represents a design thinking process (with terms like empathise, define, ideate, prototype and test) was popularised by the likes of Tim Brown and others at IDEO. The term Design Thinking might have been coined in the seventies, but ancestor terms such as “wicked problems” are far older. Even older are a lot of the concepts – divergent thinking to gather options, followed by convergent thinking to make a choice, test, learn, rinse and repeat – must have been around for about as long as humans have been experimenting. The Double Diamond process was created by The British Design Council for example. This a sketch:

How about “Systems Thinking”?

Disclosure: My introduction to “systems thinking” (lowercase, not branded, definitely not a Proper Noun) came from my undergraduate degree. Except I learnt about this under the banner “Systems Engineering”. Well, more specifically, when in a Mechanical Engineering lecture, my professor got us all to play a heavily modified version of Mousetrap (I’m sure other games are available). That was my first introduction to stock and flow diagrams. That also made me realise that I’d been using a system thinking mindset for a while leading up to that lecture. It turns out that my dad and I playing with Meccano and Dominos at the same time – building mechanised arms to tip dominos over is surprisingly good fun for most of the time, although the clean-up at the end is a royal PITF (pain in the foot) – is a good way for me to begin to work out how to build models in my head to predict the future, especially complicated when there are multiple events occurring simultaneously. That Engineering thing carried on into my Electronics and Control Theory (academic) life.

In business, the term seems to have more than the abstract analytical mindset that I learned about at University. The work that Deming did with Japanese manufacturers during the ‘50s and onwards started with a very basic model:

In this diagram, the customer (consumer) is another component, interacting with everything else. “Frameworks” such as Vanguard and books such as The Fifth Discipline etc. have moved the customer to be far closer to the centre of the system model. More precisely, in order to better define the purpose of the system. In itself, that’s not a problem, but it did take me a surprisingly long time to reconcile my perspective (systems-thinking-is-an-analytic-discipline) with the customer-centricity that I was seeing. Mostly because, I was seeing that human-centricity aspect as “Design Thinking” (rightly or wrongly, probably wrongly).

My View of the Differences between Design Thinking and Systems Thinking…

One of the things I find helpful for my focus when learning (or even just thinking) about a topic, is the ability to detect when I go off track and get distracted. To help me reason about either Design Thinking or System Thinking, it helps if I can create some space between the two concepts, just so that if necessary, I can also think about what a concept is not. It’s a form of abstraction and an aid to my thinking.

…and Why it doesn’t really Matter

Assuming that the previous section resonates with you, dear reader, the main reason why I don’t believe it really matters where the precise boundary is between the two concepts, is because you need to incorporate both thinking models into your overall problem solving to genuinely make a difference to your customer. For example, whether you think about User Needs because you’re using Design Thinking or System Thinking isn’t relevant. What is important, is the fact that you’re actually considering User Needs.

Why is my client trying these?

This is an interesting question, and I’ve no real way of getting a completely accurate answer from anyone I’m in contact with, so this is where I get my theorising kicks from.

From what I’ve been able to observe, this client has had multiple attempts at one form of “agile transformation” or another over the past several years. While all of these attempts moved the organisation forward (for some definition of forward), none of the attempts did much more than improve the practices in effect at that organisation. Manager types still managed (although the role names did change a few times over the years). Requirements specialists still produced documents (although the name of the documents and the templates followed changed). Business engagement was still limited – in this case, limited to Product Managers. Product Owners (there is a difference at this client) were more likely to be a subject matter expert or a requirements specialist. In other words, a proxy to someone who more may be more appropriate to “own” what’s being delivered, but has insufficient time away from the day job. A centralised architecture function would determine standards to adhere to, and would be where approvals would be sought when teams wished to implement a design pattern (sometimes quite a low level decision).

The underlying culture appears to be quite resilient to change, and is what I would expect to see in a typical hierarchical, command & control, low trust, low empowerment organisation.  Again, no value judgements from me, but it is a prevailing culture that’s a polar opposite to the empowered, distributed authority, high trust, high collaboration culture that an agile way of working would require to truly shine. I think this underlying cultural resistance is one of the drivers for using these “differently termed techniques”. In particular, there’s a keenness by (very) senior leadership to adopt Systems Thinking, as the term doesn’t match any of the existing organisational silos or fiefdoms. In that respect, “Design Thinking” is a little harder, as one could argue (for example) that “As the Enterprise Architects are responsible for Service Design, that’s clearly where Design Thinking fits in”. Granted, your sanity could be questioned if you argued that point of view, but still, it’s possible. That is one of the strategies that a resilient bureaucracy can use to negate the risks associated with an invading culture – convert the new concepts into existing ones, and thereby eliminate the need to change. In order to stand a chance of converting the status quo, one needs to be careful about the battles that are picked.

I started writing this post as a gut reaction to the style of the language I found in SAFe – https://www.scaledagileframework.com/ as I have been trying to learn what I can, and I find connecting/comparing new things to stuff I already know to be an effective memory aid.

Background

I’ve spent the last few weeks dipping in and out of SAFe – my current employer has adopted it “in a big way” and as it’s one of the few agile scaling frameworks that I know relatively little about, I figured I might as well see what the fuss is about.

Disclaimer: I’ve known about SAFe for a while now, and the early versions were shall we say, “limited” in my opinion. But SAFe’s had a lot of content updates over the years, and having listened to a few SAFe people talk/defend SAFe, some of their language reminded me of some of the things the RUP lot were trying to say as they tried to explain RUP to a hostile audience.

I’ve mostly structured the comparison along different abstraction levels

The Strategic Lens

SAFe: Business Canvas, Portfolios and Budgets

SAFe borrows heavily from Lean thinking and uses a Business Canvas (extended to become a Portfolio Canvas, but the underlying concept is the same) as well as thoughts on Lean budgets for Value Streams. These are wrapped up in some structured guidance, using McKinsey’s Horizon Model and support mechanisms & tools for SAFe Consultants. I’d expect senior management to be comfortable with this degree of “formality” and structure.

DAD: Disciplined Agile Enterprise

DAD is far lighter in it’s approach to guidance. There’s an underlying assumption that organisations are more sophisticated than simplistic models could describe, and so it’s more appropriate to provide thoughts and principles for the major Departments (e.g. HR, Sales, Finance etc) to be used as the client organisation sees fit. The lack of significant cross-organisation structure will require greater experience from an Organisation’s Agile Consultants to be able to evolve these Departments to being more compatible with an Agile Mindset.

The IT Delivery Organisation

SAFe: Managing Change

SAFe has a lot of content all focused on “managing the environment”. From role titles (“Product Management”, “Solution Management”, “Lean Portfolio Management”), standardisation instructions across teams within a bounded context (e.g. all user stories are sized relative to the same baseline story for all teams) as well as a structured model for requirements (Epics -> Capabilities -> Features -> Stories), the sense I’m getting from the SAFe guidance is that of Management / Senior Leadership setting boundaries to operate within. This is much more closely aligned (at least when looking at the narrative) with most organisations. The overall SAFe diagram also has a very structured feel to it:

That suggests to me that there’s a general feeling that changes are optional – that you can say “no”, or at least “not yet”. At least for some types / categories of change. What’s interesting to me is this is a managerial style of thinking – “I will make a decision”.

DAD: Goal Driven

DAD has a different feel when navigated. A lot of the content is structured around “Process Goals” and the various options that could be chosen in order to achieve a degree of progress towards these goals. While there is some “structure” from an organisational perspective, it’s very lightweight. The visual style suggests a more team-centric bias (“Solution Delivery” is in the centre-ish). Though be warned that is just my gut response when looking at the visuals:

The visual style also suggests to me that there’s a general feeling that changes are mandatory – that as a team you have to operate in a way that is flexible enough to deal with whatever comes your way. What’s interesting to me is this is more of a “DevOps cultural” style of thinking – “How do I cope with this?”

DevOps

No comparison would be complete without comparing the two stances on DevOps (at least at time of writing…).

SAFe: Continuous Deployments, Release on Demand

SAFe describes Continuous Delivery as a four stage pipeline – “Continuous Exploration, Continuous Integration, Continuous Deployment and Release on Demand”. Basic descriptions are provided, and a CALMR acronym features as an aide memoire for the approach [Culture, Automation, Lean Flow, Measurement, Recovery].

DAD: Disciplined DevOps

DAD is rather more thorough in it’s description of DevOps, showing how more operational and non functional concerns (e.g. Security and Data Management) fit into the larger picture, admittedly by pushing the boundaries of portmanteau-decency (DevSecOps or DevDataOps anyone?). The sensible combination of these facets is simply called “Disciplined DevOps”, fitting in with the high level naming strategy.

Teams

One of the few things that every single Agile Scaling Framework has in common, is the reliance on empowered, self sufficient teams producing high quality output (e.g. Scrum+XP) as the basic building block.

SAFe: Alignment using Planning Increments

SAFe uses both cadence and synchronisation to keep all teams working towards a common objective in the ART (Agile Release Train) aligned. Teams are free to pick either Scrum or Kanban as their team execution pattern, however, the Kanban variant used isn’t “vanilla Kanban” (or whatever textbook version would be called), as the teams using Kanban would still be expected to align and coordinate with the overall iteration heartbeat used by the ART. Kanban teams would also be “forced” to plan in batch, just to allow them to operate within the PI Planning event. The PI Planning event is essentially a big room planning exercise to plan about three month’s worth of work. I’ve seen commentary that suggests that the PI Planning Event is instrumental to the successful use of SAFe.

This is an example of a Program Board that also serves as a “Big Visible Information Radiator”

DAD: Lifecycle Models and Program Maturity

One of the DAD Lifecycle Models is the Program Lifecycle

The DAD Program Lifecycle also integrates key elements from the Risk/Value Lifecycle, making explicit the need to get a stable base in place before scaling the program up to several development teams.

Other Perspectives – Agile Transformations

Warning: Many large top down transformations fail. Many bottom up transformations never make it out of the teams.

SAFe: Playbook for the Agile Transformation Consultant

SAFe includes John Kotter’s work on Leading Change [link is to slightly older material than the current view on kotterinc.com], albeit modified slightly, but maintaining the original premise – leaders should lead the change, enabling their teams to act on the Vision.

One thing to bear in mind is how integrated the SAFe training courses are in this Transformation Roadmap. When using the shu-ha-ri metphor, I’d say this is good for Ha levels of Transformation Consultant (if you’re Shu level, then being an Agile Transformation consultant is dangerous IMHO). The availability of coherent reference material will also make the Executive Engagement activities a little easier, so it should be easier to start larger scaled transformation endeavours. This feels more like a top-down transformation initiative.

DAD: Structured as a Reference

DAD on the other hand, doesn’t really have anything like this – it’s structured as Reference Material. You’d need to be a Ri level of Transformation Consultant to get maximum advantages of the DAD framework. If you’re at Ha level, then you’ll still get value, but it may be a more nerve wracking experience as you’ve not got a specific playbook to use. The DAD books (e.g. Choose Your WoW! ) are aimed at filling that gap, giving teams support to help them evolve their ways of working. This feels more like a grass-roots / bottom-up transformation initiative.

Data Warehouses are slightly different from my typical project past (I’m far more au fait with custom software or package configuration / implementation gigs).

However, there’s an interesting aspect of Data Warehouses that can make them very suitable for more experimental/research oriented delivery techniques. To set that sentence in some context, I see two main categories of advantage to having a Data Warehouse:

1. Regular Reporting that’s more insulated from changes to operational systems that feed the reporting (this is an Efficiency type of advantage)
2. By aggregating multiple data items, it is possible to increase the probability of discovering previously unexplored patterns and relationships (this is an Insight type of advantage)

It’s this second advantage (see something like https://www.youtube.com/watch?v=X30tpFcKlp8 ), if a little hard to quantify, that I’m interested in.

Running an Experiment

Assuming the data already exists somewhere in the Warehouse, the high level end to end flow is fairly straightforward

Delivering “The Tech”

The analysis and transformation work seeks to create information by transforming the underlying data into useful structures. It is sometimes impossible to predetermine exactly what structures would be useful, leading to the need for experimentation / trial-and-error or other uncertainty-reduction-strategies. The transformation efforts can be split into two parts (if necessary). Converting a source system data model into a logical (or canonical) model is a useful step, as it allows the Data Warehouse users to decouple themselves from the inner workings of a source system. This canonical form is typically in 3NF. Converting the canonical form into a Facts and Dimensions model is a useful step to improve the reportability characteristics of the data. However, this step can often only be performed once there is enough insight into the sorts of questions that the datasets need to answer.

The aggregation work seeks to combine potentially related sets of information to be able to reveal additional patterns and trends and create insight. This insight is where the value is when using a Data Warehouse (or more precisely, these insights can be acted upon to generate additional value for the business).

A continuous delivery model can work well in this context, particularly if there is a strong desire to create differentiation in a mature market. Work can usually be delivered quickly as in these scenarios there are usually no new architecturally significant requirements that need to be met (mainly because the Data Warehouse already exists, is operational, and has been sized to also cope with a reasonable degree of ad hoc reporting).

Mind the Gap

There are scenarios that don’t easily fall into that model. One significant one is when the raw data to be used does not yet exist in the Data Warehouse.

The solution to this problem is to introduce additional steps in the value stream, moving it left to also include ingesting the new data source as well as integrating (e.g. cleansing) the data and storing it in a coherent manner.

Filling the Gap

The Ingest & Store activities can be performed with a couple of different strategies.

• The first strategy is to only Ingest & Store what is required by the downstream work (i.e. the Analyse and Transform work identifies the specific data gaps. Those are filled)
• The second strategy is to Ingest and Store everything that is available from the data source, regardless of whether or not it is needed

The main benefit of the first strategy, is that only valuable work will be carried out (more just-in-time and less just-in-case). The main disadvantage is the time/effort it takes to build or change an Ingest process (this is typically an architecturally significant piece of work). An interesting side effect of only ingesting what is needed, is that it’s much slower to “just explore data and discover new insights”. In other words, serendipity is far less likely to work for you.

The main disadvantage of the second strategy, is that it can take more time (and money) than the first strategy to get to the version-one-dataset (i.e. the dataset known to be needed). The main advantage is that it is more likely that unforeseen relationships can be discovered, and those insights could be a source of a competitive advantage. However, there are no guarantees

The Client Specific Problem

There is a lot of advice and guidance that’s applicable to evolving “established” Data Warehouses. There is comparatively little advice and guidance on how to bootstrap your Data Warehouse and start generating value from it even when there’s extremely little data contained. A lot of the latter guidance uses tangible outputs (e.g. a report or a dashboard) as a way to bound the early work.

The initial ask of the project team (more accurately a platform team, but that’s a topic for another day) was to produce two reports for two business units. These two reports represented a significant piece of value. These were both fairly mature reports, having been developed and enhanced over a number of years. This was the strategy for being able to unlock value from the Data Warehouse at an early stage.

However, as the work progressed, it became apparent that there were significantly more data sources involved in the production of the complete reports (only discovered when new outputs were compared to the existing reports). In this environment, the work required to Ingest a new data source has significant architectural requirements to be satisfied before the data contained is accessible for use. The initial planning assumptions that led to the selection of these reports to be the first business use of the Data Warehouse were proven to be false. Seeing as all of the reports / dashboards that were deemed to be valuable were of similar ages (i.e. have been evolved and refined over a number of years) it was reasonable to assume that similar deal breakers would emerge unless far more thorough data analysis was performed.

A different strategy was needed. Instead of “trying to deliver a pre-defined thing”, what would happen if the focus shifted towards “get datasets into the Warehouse ASAP”? The ability to deliver a specific thing would suffer. However, the ability for the business to explore their data and attempt to derive meaning and insight from it would be improved. It involves a reframing of the ask. Moving from “Recreate X” towards “Try to make use of Y”. It gives the business users a chance to stretch their creativity muscles.

This proved to be a bridge too far. The rest of the “Change Organisation” had been optimised for projects. Or perhaps that should be “had evolved to make Projects the easiest vessel for money to effect changes”. Asking that organisation to switch to what is essentially a far more open ended “Research” mode of working wasn’t feasible in the short-medium (and I’m not holding out much hope for “long” right now) term.

So we found a halfway house. A Frankenstein-esque mesh of “push oriented work” and “value/pull driven work”. Development efficiency was the main driving force behind the sequencing of the Ingest/Store/Analyse elements. Datasets would be pushed onto the Data Warehouse in as efficient a manner as possible. Experimentation and “Product Development” was the main driving force behind the Analyse/Aggregate/Trial/Adopt elements. The most valuable reports and KPIs were targeted first, and experiments would be run to work out viable ways of delivering the insights using whatever datasets were available at that time. Interim solutions would be accepted, knowing that when additional datasets were delivered onto the Warehouse, it offered the chance for refactoring and redevelopment to occur.

It’s not pretty, but it’s a huge step forward from where the team was when I joined. Hopefully this one remains benevolent…

Note: Credit for most of this goes to @susannehusebo

• They start their daily stand ups on time
• They tend to laugh a lot and have fun
• Everybody in the team gets to express themselves
• They correct and edit each other when they go off track
• They try out new things with appetite. But they are quite willing to admit those things that don’t succeed
• They often don’t care very much if it looks like they’re working hard
• They encourage each other to leave on time
• They talk about “we built” or “we failed”, rather than “I built” or “I failed”
• They have lunch together, or some other time within work hours where they talk about other things than work
• They welcome more junior members of the team and enjoy mentoring them
• They have inside jokes
• They share responsibility for communicating with outside stakeholders
• They don’t agree on everything
• They debate between short term benefits and long term strategy. They reach compromise
• They question each other on topics like accessibility and inclusivity in design and development
• When they finish a task they check if they can help someone else finish theirs
• There’s room in good teams for extroverts and introverts. And those in between.
• Team members are aware of their needs and communicate those to others
• I’ve seen some great teams have seriously stubborn people in them. They can be great when the team needs reminding of why they came up with a certain rule: specifically so the team wouldn’t compromise when they’re in a hurry
• Good teams often fight for independence to make their own decisions
• They ask “why” a lot
• They discuss the users of their products every day, and user experience is viewed as everyone’s responsibility
• If they are remote, they try new ways to make everyone equal, even if it means compromising the experience of those people that are in a shared space
• They are not dogmatic
• Testers and designers are included in discussions of estimations and backlog refining
• They respect agreed decision making structures, but argue their points
• The people are not too similar to one another. They think about problems from different angles
• If someone on the team is ill, the others figure out how to get by without that person
• They have quiet time. In whatever amount is valuable to them
• They don’t interrupt each other. They take equal turns in speaking
• They get each other tea/coffee/water
• They have one-to-one chats with each other to discuss points of agreement or disagreement
• They know each other’s personal and professional goals and aspirations, and try to support them where possible
• They are not all equally skilled at everything. But they try to work on things where they can learn
• When people pair on a task, the less experienced person is usually the “driver”
• Senior team members ask for advice and feedback from more junior team members
• They don’t have to give positive feedback every time they give negative feedback
• They thank each other for favours, for tea, for good ideas, for bad ideas, for observations…
• They use the products they’re building
• When someone has an idea, the other team members build on it and add to it
• They accept that people have “off” days
• They are generally resilient when it comes to change, including change of direction, goals and vision
• They can work quickly, but it’s not always crunch time. There’s a sustainable cadence to work
• They regularly talk about how they work together, and try to improve on that
• Team members generally know what every other team member is working on, and what kind of issues they’re having
• They encourage each other to share work early, rather than wait for it to be “perfect”
• They have some shared values or principles that guide their interactions
• They try new tools and methods quite easily
• They might defend each other to people outside the team
• Before they ask for feedback or reviews from other team members, they read through their own code/work
• They have time to/they prioritise automating tasks that are not valuable
• They talk about technical debt, and teach stakeholders about it
• The work they do feels important
• They argue
• They talk about how well they’re doing compared to expectations. If the estimates turn out to be off, that’s not a disaster
• They take turns dealing with boring or time consuming tasks
• They are interested in each other personally
• They talk about problems without talking about people’s characters, rather they focus on the work
• In meetings they put their phones down or close their laptop lids when they’re listening
• They have a say in who joins the team
• They have shortcuts for common communication (like signals for when the conversation is derailing, or when they’re losing focus)
• They don’t mistake fun for a lack of discipline
• They consider different communication styles. Meetings are not just held so the loudest speakers are heard the most
• They care that other team members and stakeholders understand the work they’re doing
• Documentation is updated whenever errors are spotted, by the person that spots the error
• Team members feel a shared sense of pride and ownership of their work
• It’s not ok to notice a problem, and not do something about it, even if it’s not in an individual’s immediate area of responsibility
• Developers participate in sketching sessions, designers understand how git works
• Team members reach out to their personal networks to ask for help for other team members
• Everybody tests
• Team members let each other try things out even if they think it will fail (sometimes, if constructive)
• They notice when other team members seem worried or down. They ask about it
• Everyone knows that it’s ok to be wrong, as the rest of the team have your back
• Everybody participates in user research
• Everybody’s involved in pairing or non-solo work
• They have a shared history and sense of purpose
• They argue like siblings. Intensely, but when it’s over they’re still teammates
• There’s an awful lot of trust sloshing around the team. All of that trust has been earned by people doing what they say and looking out for each other
• Work is criticised. People aren’t
• No-one is “keeping score”
• “I don’t know” is not a dirty phrase. “Let’s find out” is an even better one

I was recently invited along to have a discussion with a few interesting people about a topic it turns out I’m fairly enthusiastic about.