Actions allow teams to create tasks from a discussed Retro item, so that they can confidently track and measure their continuous improvements.

We’ve tailored the experience to solve some of our customers’ biggest pain points, which were:

• “Ok, we have something to do as team, but my JIRA board is for our product backlog?” 🎬
• “Who is owning or championing this task to completion?” 🎬
• “We have a burning issue to work on as a team but it isn’t really a task we can ‘tick off’, per se, so how do we remind ourselves?” 🎬
• “It was a great Retro last Friday, but I’ve forgotten some of the important things we actually discussed” 🎬

Using Actions will allow your team to:

• create, track and complete tasks that are team focused rather than product specific
• assign tasks to an owner to keep them honest
• keep a pulse-check on much needed cultural improvements

Have a peak:

Give it a try with your team during Retro this week!

Ready, Action! 🎬 + ✅ = 🎉 was originally published in Better For Teams on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every team’s continued success is up to how much they keep improving their people, processes and product/s.

Continuous improvement can be difficult for even the most refined and experienced of teams and this can be due to many things; time constraints, execution, following through on actions and so on.

We’re building a platform that helps teams practice continuous improvement seamlessly within your iterations so you can deliver only the best value for our customers.

Starting with a free retro tool, the team at Better have lot’s of plans to help make your team keep on improving, such as automation and integrations, so stay tuned over the coming months.

In the meantime, we’re always happy to hear your feedback, so please let us know what you think so far and what you’d like to see next!

Introducing Better: a tool for teams who want to be better was originally published in Better For Teams on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is a title — sometimes self-endowed — used in most workplaces/digital product and services teams that when uttered begins to eviscerate a team of their momentum, productivity and innovation.

We have a demo at 2 for the stakeholders, make sure everything is ready!

We have to deliver this feature for our stakeholders by end of next week!

The stakeholders have a great idea on how this feature should work!

🥩

Yes, the person, or people/exponents, who have a vested interest in, and often an opinion for, everything you’re doing.

The primary problem with this is that it is an umbrella term for a group of very different personas, each with their own idea of importance and success measurements; from their role and responsibility to their area of expertise and level of experience, they each add a certain bloat to a product or service team.

They — and I will try to move away from referring to stakeholders as a collective term — are probably not required for most day-to-day decisions. If you consider yourself a stakeholder for a product or a service, deep down you know this is probably true.

I declare war on the word — not the people. The word has to go and in lieu of it, I am suggesting a new approach in which correcting semantics will foster much smarter ecosystems and produce better results for your team, your customers, your partners and your investors.

New approach

Smarter ecosystems produce better results. Instead of calling the people around the outskirts of your immediate team stakeholders, a better way to approach this is to collect them into particular groups and execute your decisions based on the following order of importance:

1. Team
2. Customers
3. Partners
4. Investors

If a former stakeholder does not fit into one of these groupings, chances are they might not be relevant to your success. Although collaboration in wider circles is important, it can also be a waste of your team’s time in the way it’s currently being done.

If you consider yourself a stakeholder that might not fall into one of the above categories and are now feeling a bit lonely, don’t fret! There are plenty of useful, hands-on things teams need help with — you just have to ask them.

Team > Customers > Partners > Investors

The ordering falls as such; immediate team members are more important than your customers and so on. Understandably, sometimes this will shift in extreme cases, but primarily the order should be adhered to when making any decision for ultimate success.

By defining clear personas for, and groupings of, the people nearest to your product or service, it will:

• speed up your delivery
• enhance the value of your team
• minimise a lot of waste; and
• produce better results for your customers.

Let’s dive into what each of these groupings in your new world mean.

1. Team

Your immediate team should always come first. These are the people who work alongside you all day on the product or service, understand the customers, help steer the vision and who come up with ideas to deliver value. Without them you have no product and without a product, no customers. They are the most valuable asset for your success.

People will always come and go for their own reasons, but reducing these reasons is so important as to minimise the waste of rehiring, retraining and getting buy-in/passion from someone new. In the event you do turnover, bright new ideas should always be welcome!

Small things generally create small responsibilities. Keep your product and service teams small, outward facing and their roles sensical; designers, product owners, engineers.

It is better to have many autonomous teams than one large team. There are many ways to construct these independent teams; vertical streams, platform specific, horizontal layers.

Treat your immediate team members like family, deliver and achieve things together and foster a great culture — the rest will follow.

2. Customers

This would generally go without saying, yet time and time again our customers can often be put last. Customers are the most important people within the ecosystem outside of your team.

They often come in many shapes, sizes and personas; someone buying your product, someone consuming your API’s or someone advertising on your platform.

Anything you build has no value until it is in front of a customer and without customers, your product essentially has no value.

In return for providing a valuable product or service, your customers will help keep the lights on at your workplace, so to speak.

Your product or service should be undergoing constant evolution and in order to evolve correctly, your customers need to be a huge part of your experimental ecosystem.

Customers have many problems and desires and we can’t know anything about them until we treat them with respect and priority.

‘Customer’ can be just an ambiguous term as stakeholder and with approaches such as Design Thinking and Human-centered Design, we can define and consistently learn more about them, in order to provide value to the various personas we are helping.

3. Partners

If you’re lucky enough to have grown to include ancillary roles in the family — growth, marketing, content, legal, compliance, human resources etc. — keep them busy and help them work efficiently with your common goal at heart.

You can assume that many of your stakeholders may fall into this basket.

These people often are, or will organise as, consultant-like or decentralised teams of one or more people — which is okay and often works out better. They are experts in their respective fields and assumedly are being brought in to propel your product or service forward in an area where your immediate team does not have capacity or skills, hopefully some cross-pollination occurs.

The difficult thing to balance is the fact that their remit can often be ephemeral yet in order to achieve the best outcome, you want them to own the success of the product or service as much as your immediate team.

If we start to shift our thinking about these people from being stakeholders of your product or service to more of an ancillary, purposeful function within a wider team that helps you achieve success, we start to reduce friction and tight-coupling that some partnerships can result in.

Partners will have opinions and solutions; exactly what they’re there to produce. The goal is to get results as efficiently as possible and to do so, make sure that the partnership is setup for success; no ambiguity about your vision or the task at hand.

Ultimately you have to steer the ship, so you need to help them so that they can help you.

4. Investors

Investors are the people who have invested some form of financial capital in you, your team and your product or service.

Assumedly they love you, your team and your vision and want to help guide you in order to secure tangible things, like return on capital, and hopefully even intangible things, like advancing the human race just that little bit more…or something.

Without your team, your product or service, customers and partners, the investors have no confident way of securing a return on capital, so the wisest thing that investors can do is help foster this smart ecosystem from arms length.

Hopefully your team uses investors for not only capital but also advice, mentorship, expertise and network access, as it would be wise, but at the end of the day, they trust you and your approach to produce a win-win-win-win outcome — your team, customers, partners and finally, them.

Corporate enterprise is still playing catch up to venture capital models on the outside but they should start to emulate such models if they want to eliminate bureaucracy, move quicker than their competitors and achieve ultimate success.

Quite often investors want proof of forward momentum and measures of success. There are smart ways to demonstrate cadence, growth, recent developments and so on. Such information should be readily available to pull whenever they want, but it also doesn’t hurt to project success and tell your story in the form of fortnightly presentations or displays of how data is driving your decisions, for example. Don’t dismiss the buy-in from your investors but aim to limit opinion projection.

Note, I’ve left out shareholders as a grouping on purpose. If you’re at that stage to have them, you can assume/hope that they’ve done their own homework on the way you run your business and have confidence in your team to deliver.

Let’s kill the word stakeholder and and apply some taxonomy to the important people around you in order to enhance your delivery speed, quality and accuracy to achieve ultimate success.

🙃

I wanted to explore how autonomous democracies could potentially improve modern society. Hopefully you find this post at least useful for understanding the possible intersection between cryptographic and governing systems and hold some optimism toward an autonomous future.

Democracy

Before I get into what an autonomous democracy is, let’s have a refresher of democracies in 30 seconds.

A democracy is a way to promote the best interests of, progression for and equality among a connected collection of individuals, a collection which we could also refer to as a tribe, a nation or even an organisation.

Originating in Athens around 500 B.C., the idea was introduced as demokratia, which roughly translates to “the people hold power” (demos “people” and kratos “power”). Initially, citizens within the early democratic entity partook in forums and voted for things such as policy and law directly, thus categorising early forms as direct democracies.

In modern democracy, citizens generally elect other qualified citizens, either individual or as part of a party, to partake in a governing body in order to propose, support, enact and enforce various policies on behalf of the democratic entity’s best interests. This is also sometimes referred to as a meritocracy or a representative democracy.

Modern representative democracies generally have the same goals as original direct democracies but implementation can vary for reasons such as societal complexities, scalability efficiencies, historical events influencing shifts or cultural traditions, such as religion.

In a democracy, you have to be a player — Hunter S. Thompson

In a list of the 20 most democratic nations, Scandinavian countries seem to be deploying a more accurate definition of what the good things original democracy promotes. These same countries also often fall into lists of nations with the happiest citizens; perhaps some correlation can be found.

Democratic-like environments do not necessarily have to be at geopolitical levels but can also be successful within organisations as seen within Ternary Software Inc’s ‘holacracy’.

Issues with current democratic systems

A key component of a democracy is transparency, which promotes trust and openness within a community and underpins all sorts of other good things, not least minimising economic waste.

Throughout the many implementations of democratic systems around the world, things have worked quite well in terms of finding a balance between social freedoms and economic growth.

However, these systems are often not deployed without flaws. Issues with modern democracies can include:

• corruption — self-serving, bribery, nepotism etc., approvals of policies moving through governing bodies which are not holistically beneficial
• low transparency — many decisions are made for various reasons that do not come to light, for better or worse, thus making modern democracies a somewhat of a black-box
• slow progression — bureaucracy, lengthy legal processes and tactics like filibustering which slow down opposing views
• vote tampering — whether physically, digitally or through false influence and misinformation
• bad actors — sometimes people with the loudest voice or most amount of money can rise to incredibly powerful positions, creating pseudo-dictatorships
• equality — up until recently, some countries including those that are supposedly democratic, banned or made it extremely difficult for women and/or minorities to partake in or vote. Although things have now modernised in all but one country (Vatican City at time of writing), the fact that it took an absurd amount of time highlights the lack of progressiveness in some democracies.

Autonomous direct democracy

We now have the technical capabilities to create autonomous direct democracies, that which can fix major problems within modern implementations and give actual power back to the people, just as the original direct democracies initially intended.

Such a thing is now possible through distributed, decentralised & trustless software systems which provide the scaffolding for an incredibly confident, secure and inclusive ecosystem. It could theoretically far outperform current implementations of democracies in various forms of measurement; economical, social and so on.

Distributed, decentralised & trustless systems

There are plenty of articles floating around that go into such technical systems in much more detail.

Let’s briefly break it down to understand what it means in terms of a implementation:

• Distributed: data is stored and computations are done from many places rather than one for various reasons such as high redundancy and accessibility.
• Decentralised: no single central authority which makes decisions but rather everyone partakes through their own local version of a system.
• Trustless: systems underpinned by appropriate design and cryptographic principles can move the trust in a transaction from the parties or middleperson to the actual system itself. Within the system nobody has to trust each other for it to be successful. Whilst it’s not exactly trust-less and insinuating as such adds flavour, the trust is absolutely minimised for each person involved compared to traditional systems.

The best example of such a system that most people would be familiar with by now is one that is underpinned by a blockchain.

There is a lot of hype, skepticism and even criticism about blockchains, cryptocurrencies in particular, which I won’t get into. For the sake of this article, consider the original intention of blockchains as immutable ledgers rather than as a database replacement to get investors into a room to pitch a mattress startup at.

If you are interested, you can read more in more detail about cryptoeconomics over at Blockgeeks.

To try and better understand how such a system could underpin an autonomous democracy, let’s use Uber as an example and look at it as if the app itself was built by many contributors in an open-source manner rather than by a corporation.

The application’s data would be stored on the local device of everyone who has the app, not a server somewhere in the cloud. The application itself would perform the automated transaction escrow duties between the rider and driver once the trip starts in the form of a smart contract. Once the trip has been completed and both parties agree satisfactorily, the smart contract is complete, the blockchain is updated and the transaction is therefore complete, seeing the funds transfer from the rider to the driver. The rest of the users with the app then confirm the transaction happened satisfactorily.

Things like identity verification, background checks and dispute resolution obviously require more thought and could very well be automated, but from a pure financial perspective we’ve basically just removed the need for a middle man, or the company itself, during a ride transaction. This was achieved through community driven effort, smart contract automation and highly enabled modern architecture resulting in a trustless transaction between two parties.

Example implementation

If you could try and imagine a similarly architected system as above, where we can vote on things like policies, regulations etc. on our mobile phones in the comfort of our own home, with the results and calculations occurring instantly, privately, and securely.

There is no governing body processing paper ballots and no necessary intervention by anyone to produce and announce the results.

Implementing a decentralised, distributed & trustless voting system based off blockchain technology, where votes on policy are as frequent as the citizen wishes to partake in, private and secure through cryptography and as a whole, gradually increasing in confidence through robust weighting algorithms.

Citizens are incentivised to vote and, as an automated process that occurs in the background, verify all other votes by allowing their devices to perform computations whilst idling in the background, earning a currency, perhaps one which you can spend the same as you would a fiat currency within the democratic entity or defer as tax breaks.

Citizens votes are weighted (absolutely privately and autonomously) on the unique persons experience, education and/or expertise, contributions to previous policies and and past voting successes and is completely unique to the particular topic that the vote is being made on.

Voting success should be measured by a democracy’s cultural standards. For example, let’s consider two scenarios:

1. A democratic country, which is more socially aligned, has a new policy vote which has social advantage but financial disadvantage i.e., $100 spent, 10 people helped.
2. A corporation, which is more financially aligned, has a new policy vote which has financial advantage but social disadvantage i.e., $50 spent, 4 people helped.

Citizens of each who voted in such a way that upheld the primary cultural values of the entity would be considered stronger voters in future votes.

To be able to change policy, this again should be a crowd-sourced effort where people offer suggestions for changes, others can join in and these are voted on.

This approach has worked quite well for communities such as Wikipedia, StackOverflow and Quora.

Existing concepts

The concept of a autonomous direct democracy managed through a system built on top of a blockchain has been proposed through systems such as the Ethereum platform team in DAO’s (Democratic Autonomous Organisations) and also by the Horizon State team, who are gaining a lot of traction in Australia and Indonesia and who appeared on ABC’s Download This Show podcast recently.

Modern use cases

The recent example where a system such as this could have drastically improved process and policy is the Australian plebiscite vote for same-sex marriage by the Liberal Party of Australia. Whilst the outcome was socially desirable (majority vote in favour of, laws were updated), it cost tens of millions of dollars, compared Australia to other western countries with similar values who had all progressed well before Australia had, required a physical mail ballot, sparked protests involving thousands and allowed an uncountable amount of continued discrimination to occur due to bureaucracy.

Had there existed a blockchain based voting system within Australia, the voting could have been easy, instant and without deliberation. It could have all happened on a persons own device, from the comfort of their own home with as much toggle of voting preference and a scan of their fingerprint.

Social Support Case 1: Wisdom of the Crowd

There is an interesting concept known as wisdom of the crowd, where the “collective opinion of a group of individuals” can be found to be more successful than “than that of a single expert” when there is a precise answer to something.

An example of wisdom of the crowd is trial-by-jury, where a group of people decide on the verdict of an accused fellow member of society, based on facts presented by a defending and opposing teams. The alternative to a trial verdict is trial-by-judge, where the residing judge makes an individual, expert decision based on the same delivery of facts.

Even through the use of quantitative data there are far too many factors for each case to determine which approach has been more successful. In the case for wisdom of the crowd being applied to social and economical outcomes, precision is perhaps very difficult to achieve — unless of course principles and foundations of the body are extremely clear.

This theory could support the success of autonomous democracies.

Social Support Case 2: Wa (和)

There is a Japanese cultural concept known as ‘wa’ (和), which is sometimes loosely translated to English as ‘harmony’, but more specifically implies a ‘peaceful unity and conformity within a social group’.

It is very much integral to Japanese culture and reflects that, as an individual, you are a part of a much more connected ecosystem. Your decisions as an individual subsequently effect the holistic ecosystem as to better society as a whole.

This is a really powerful aspect to communities and way of life of which autonomous democracies should really be underpinned by.

Possible considerations

There are of course plenty of considerations with an autonomous democracy being run in a decentralised, distributed and trustless system that is a blockchain, such as:

• Short term failures may occur in lieu of much stronger long term societal gains.
• I suspect this model will initially be more successful in small organisations, small teams within an organisation or microcosms within society due to generational, technical, experience, complexity and scalability issues
• People’s time is valuable, how can citizens vote on everything? Perhaps this should be non-mandatory but incentivised voting through tax benefits. Or perhaps in the future we have moved back into a ‘village mentality’ structure where automation has freed our time up and there are fewer things to vote on but we can vote on everything (much like town halls back).
• What if the majority votes on the ‘wrong’ outcome somehow? As above, the ‘wisdom of the crowd’ theory does not eliminate incorrect outcomes completely. How quickly is this determined to be ‘wrong’? How is this decision reversed?
• Everyday people may find difficulty in understanding geopolitics, cryptography & economics, yet need to participate in a system where these form the technical foundations. Should a socially minded everyday person feel responsible for voting on whether or not a new mine which could provide electricity and create thousands of jobs at the cost of the detriment of the environment.
• Globalisation — people have the ability to travel and live wherever they want, whenever they want (of course, with some limitations) — how do such systems cater for ephemeral participation or nomadic movement between such environments.
• It is debatable whether an understanding of economics and geopolitics is important for everyone who votes.

What next?

As overhyped or misunderstood as it may be, I believe that blockchain technology can definitely be utilised to underpin an autonomous democratic system successfully for the betterment of society as a whole.

I think the ball is beginning to roll in this space.

With my true MVP hat on, what I’d like to see as first steps in the near future is small teams or companies begin to implement such a system in order to see how successful they can be as fully autonomous democracies.

Once it matures, I’d love to see a system enabling citizens to vote on important social topics, much like the equality vote here in Australia, in a much cheaper, efficient, secure and modern way.

Beyond that, I’d love to see a more transparent and empowered future for citizens of any sort or size of democracy.

I’ve always been a big adversary of deadlines in business. I believe that they create stress, rush unfinished products and normally aren’t even met, causing performance anxiety potentially leading to hostile environments and a high staff turnover rate for organisations. They are driven by over promise, often leading to under delivery. They are often set by someone who is not carrying out the workload or does not have an acute understanding of the ‘how’.

The etymology of the word deadline is interesting, coming from a very literal war-bred origin, alluding to a perimeter around a prisoner enclosure where they could not pass without facing consequences one could only assume by the namesake didn’t bode well.

The phrase then naturally found it’s way into the business world, initially at newspaper presses where reporting on breaking news is paramount to success. This is one example where there can literally be time, environmental or physiological constraints. Another example would be agriculture and seasons. I’m not implying deadlines are dead for these types of constrained environments.

So let’s look at possibilities as to why such an originally grim term eventually made it’s way into delivering business solutions. Deadlines do a few things, such as:

• ensure that goals, business or otherwise, are met in timely manners
• drivers for solving problems or driving progress quicker in competitive environments
• drumming up motivation as a ‘call-to-action’ in order to align a team together to achieve a desired outcome

These are good things, so why do I think deadlines are dead for everything else?

Deadlines just don’t make sense anymore.

Do products, not projects

Deadlines don’t make sense because we have so many learnings under our belt from ‘failed’ projects. We have stronger tools at our disposal that can do things such as automatically predict delivery dates based on data mined from teams and operations. We have new methodologies of delivering value quicker, more consistently and more precisely.

A project with a deadline insinuates something which has an end of life. When has a project ever finished on time, under budget and never had anything needed do be done after that project deadline?

The next question is, why did we start this project in the first place? To solve an existing problem and deliver customer value, of course. There are a few problems with delivering using the ‘project’ approach, which are as follows:

• you should not only assume you have to pivot daily, you should be ready to
• whilst your big goals may be less vague, your clients needs won’t stop evolving or shifting
• the initial problem you’re solving won’t stop splintering into others

When building something in this day and age, it should be treated like a product with, hopefully, no assumed end of life and something that will move, shift, pivot or bounce it’s way into evergreen success. If a product is unsuccessful, it probably points to a failure to truly understand the needs of your customers or rather, your customer research or product delivery techniques need improving, but that is a whole other kettle of fish.

Deliver continuously, not once off

We are living in pretty darn good times. We are enabled, we are quick and we can create a huge amount of impact easily. Why would we limit ourselves to a deadline when we are so empowered?

It’s all about delivery; from software and manufacturing to hospitality and training, things like practicing continuous delivery and continuous improvement reinforce the value we put in customers and their ever evolving requirements. Employees should be constantly delivering, always ready to pivot and live, dare I say it, agile work lives.

By focusing on continuously delivering and evolving a product, you get all of the benefits of deadlines (as above) — and more — but diminish any of the negatives that come with them.

Be declarative, not imperative

A culture of setting deadlines is imperative, imperialistic and archaic. A culture of continuously delivering value is declarative, holacratic and highly responsive.

Focus on setting up the correct product delivery cultural foundations and only good things will follow; less stress, add more value for your customers, less waste, more money saved and all the while still maintaining that speed to market and most importantly, the competitive edge.

Let deadlines go the way of the dodo.

A follow on from Our lean path to market: rituals and disciplines

One of the keys to creating and evolving a great product is to enforce great software practices from day dot. If done right, this will foster an ecosystem of thriving, happy, highly skilled and multifaceted developers.

In a good product team developers are not silo’d but are apart of the core team and are equally as responsible for the success of the product as the product owner is, as the designer is etc.

Following lean product practices and having highly disciplined developers in your team, you will very quickly see the massive benefits for the product in the form of:

• continuously delivered code — new features to production as quick as possible
• less bugs — high confidence
• extremely nimble product development — pivot to perfection

In order to do this, the developers must be disciplined in the tools, practices and mindsets in which they work in order to create a well-oiled delivery pipeline. Sometimes this calls for evolution in a rapidly changing landscape, but setting the baselines from day one are essential.

Full-stack > XP > DevOps

Full-stack developers

Writing infrastructure as code i.e., AWS CloudFormation templates, setting up an alert from logs/monitoring tool when your app is under duress, building a RESTful API, implementing a new search tool for a website, building authorisation into an Android app.

What do these things have in common? In a well-practiced full-stack team, it’s all just code.

Each developer should be able to do any of these things. Does this mean everyone has to be a rock-star developer and be able to do them from day one? Actually, quite the opposite. This begs for empathetic approach to your product, to your customers needs, to allowing for things to inevitably change and rapidly adapt.

People will always have their own interests in particular portions of software development and this is a good thing which should be harnessed for those clinch decisions. For example, Jane loves building API’s and making them as quick and lightweight as possible whereas John loves UI, winning each pixel perfect battle and delivering the perfect experience. Domain experts are good to have, they drive knowledge sharing through passion.

Extreme Programming (XP)

Having full-stack developers makes the XP methodology a lot easier to implement and fulfill.

I will not do the entire methodology justice here, so please read up on XP if you are interested yet not familiar. In short, XP is consistently practicing a set of particular developer disciplines methodically, including but not limited to:

• pair-programming
• behaviour-driven development
• high-test coverage
• continuous delivery

Pair-programming

Pair-programming is where being a full-stack developer really starts to make sense. Shared knowledge is not shared understanding. We prefer collaboration over documentation.

Through daily rotation, you could be working on a different part of the codebase, at any given layer of the stack. It allows the spread of knowledge of the entire codebase, removing bottlenecks and dependencies.

Being in a state of constant code review is much more efficient than opening a pull-request to potentially tired eyes with no background knowledge of the feature, fix or update being implemented.

Generally, tackling a problem with two minds is better than one. Technical discussions are paramount to good solutions. We’re all human, even the most senior developers can be prone to making mistakes or bad decisions.

One of the key attributes of the best programmers is empathy, and actually the most important factor we take into account when recruiting new members of a team.

But we’re paying for two developers to do the same job?

This old chestnut. Pair-programming speaks to big picture thinking. The simplest way to approach this question is by providing one of the cost-benefit analysis studies done, but honestly there is so much more than this. Software is the product, and good quality software means good quality products.

Behaviour-driven development

Behaviour-driven development in particular, is a natural language testing framework that emerged from traditional test-driven development. Essentially, the tests you write are in natural language which describe how a feature of the product should function, hopefully to match the Product Owners feature story scenarios.

Red > Green > Refactor

Writing unit and integration tests for your code first allows you to really think about the problem at hand, discuss it in depth and implement testable code. It is quite a paradigm shift coming from conventional programming and takes some getting used to, but eventually makes you into a better, if not more careful and thoughtful developer.

Another benefit of BDD is understanding the codebase better retrospectively. Tests act as documentation!

High-test coverage

An XP principle for testing is that it is done with high code coverage. Our codebase is just shy of 100% coverage.

How do you know something works?

High-test coverage gives you great confidence that your code has a high probability of working in different environments and under different circumstances. This means that after making a change and running the test suite, somewhere else in the codebase might have broken and will be picked up.

This leads to far less bugs and greater chance of getting code live in production sooner.

Continuous Delivery

Getting code into production as quickly as possible is key for the product; we want to test new features with our customers. This mitigates financial risk by allowing us to know sooner whether or not our customer requirement assumptions are on the right track. If they aren’t, we won’t waste more development time on that particular feature.

A Continuous Integration + Continuous Delivery pipeline is a necessity in modern product engineering. They are cheap, fairly easy to setup and allow you to get your code live shortly after you push changes.

DevOps

Every developer is responsible for each line of code in production. Through the way the software is built, all of the developers can confidently rotate through support and be confident enough to identify where any problem might be.

Our developers are well versed in each layer; front-end, services, infrastructure and any operations systems involved in ensuring the apps reliance. This makes product issue discovery and fixing far easier than if they had just worked on one layer.

Another key component of DevOps is allowing for the automation of anything we can. This allows us to focus on continuous improvements to our product rather than repeating manual tasks.

Some aspects that we love about the DevOps approach:

• continuous integration — code that tests, builds and deploys itself
• agile infrastructure as code — declarative approach to building servers, also making them redundant through load balancing, auto-healing and auto-scaling etc.

Bootcamp

Our bootcamp goes for 3 months and can be quite intensive for someone who has never paired or practiced BDD. A new developer will be working on production code from day one with one of the existing developers. There are no manuals, no documentation; only immersion.

The bootcamp readies developers to outgrow their junior, reliant status into integral members of the team to look to as product and codebase experts fairly quickly.

10% time

Once a fortnight, we take a day to focus in on something that is somewhat tertiary to our primary product, but is important for so many reasons:

• growing our team capabilities
• nurturing personal development
• bi-directional learnings with our own product
• burnout is real; stepping away from something we pour so many hours into is good for the mind.

Whether it be a small TypeScript /Node / MongoDB Ping Pong scoring app, sitting with a resident security expert for a day to go over current known vulnerabilities with a well-known service or pairing with the designer to explore loading spinners, it’s all important and it all feeds back into the product and holistic approach eventually.

Everything matters

Sometimes it’s hard to see the benefits from simply reading a few blog posts. Our approach is all-encompassing; every one of our developer practices has a purpose toward the product and it would not be the same if we approached it in a piecemeal manner.

Most importantly, it all leads to an extremely stress free and fun environment. We’re always busy, there’s always something to do but at 5:30pm we clock off, go home and unwind.

Happier teams are more productive teams, which ultimately leads to a better quality product and that’s what it’s all about for our customers.

MotoMe.com.au just rolled out a redesign focused on maturing the customer experience, go and check it out.

Has it changed much since it’s inception? Not quite enough and I’m here to teach an old cat some new tricks.

Pair names

Give each pair names. This helps when you want to reference a certain pair of machines during discussions — Pair 1 & Pair 2 are boring. A good example may include 80’s and 90’s childhood hero duos:

Mix it up

Pairing offers mixed results determined by the mix in the levels of experience of each individual: expert-expert, expert-novice, novice-novice.

Let’s not just stop there:

• 1 x expert controlling both keyboard + mouse sets: one’s enough
• novice-drinky bird: similar results to novice-novice
• novice-intern: see above
• au pair programming

Pair with other roles

Whilst less important than developers, these other roles are sometimes useful to collaborate with in closer proximity.

• designer: we like to pair with our designer from time to time to ensure that we refuse every single slightly-difficult change they ask for to their face, rather than cowardly going through our product owner, which we also often do.
• product owner: we have built everything under the sun and know that this very thing simply cannot be done, even from the very first time our product owner begins speaking their request, or thinks about it. It’s good to pair and shut these silly ideas down early on.

Work hard, play hard

If coding wasn’t competitive enough for you, then your ping-pong breaks certainly should be. Pairs should code and play together against other pairs. Boasting and banter are strongly encouraged. Double-dragons are worth two points.

double-dragon; receiver volleys, partner smashes

Reward everything

As a pair, you are both responsible for every line of code and decision made that day, so it’s positive to reward good things!

However, sometimes we do things that are not always good. Ergo, also reward stupidity.

• push untested code? you get to wear the fat pink dress together!
• lack of information in commit message? Bind one hand of each pair together with a sock (bathroom breaks are interesting).

Learn through immersion, not documentation: discuss, ask questions, solve problems together and ultimately have fun :)

This is a satirical post. Mostly.

The Peacock suite bundles Jekyll & reveal.js together, allowing developers to collaboratively build & deploy presentations through Github with nothing more than a bit of Markdown knowledge and a pull request.

A central blog-like static site that can be run anywhere locally or served as static assets. Peacock allows developers to contribute their presentation to the bundle of presentations, creating a beautifully flowing experience that can be viewed in a web browser on any device.

Check out Peacock today.

A follow on from Our lean path to market: the foundations

Before you have any misconceptions about us, no we don’t hold weekly sacrificial intern offerings to Xibalba so that our builds stay green.

Rituals and disciplines provide structure and instil focus to the way our team works toward our vision. Consistency is the key to everything we do and maintaining our momentum each working day is incredibly important.

Here at MotoMe.com.au we have a particular set of these to maintain our rhythm and keep our points of contact close, some being based on the Pivotal Labs model.

Disciplines

Regular breaks

Stepping away from the keyboard every hour or two is great for getting the blood flowing and having a mental break. We like to go for a walk along Darling Harbour or play some ping pong for our breakouts. They’re great for socialising, ice breaking or simply just switching off from work briefly.

Meetings

We consider most meetings outside of our rituals to be disruptive and actually somewhat wasteful, more so for particular roles. We keep these to an absolute minimum. A good week for us is zero meetings.

A classic post by Paul Graham ‘Maker’s Schedule, Manager’s Schedule’ details this sentiment well.

Timebox

We timebox everything; we keep our rituals and meetings short by getting straight into it, reducing the small talk and cutting them off at the time we said they will end.

Rituals

Standup — daily

After breaky, we kickstart every day at 9.06am on the dot with a prompt standup around our team whiteboard, all set with a short term calendar and kanban action board. Nothing revolutionary!

Here we’ll cover the following in under 5–10 minutes with a closing synchronised clap:

• welcome any newcomers or visitors
• share any interesting tidbits i.e., footy score over the weekend, advances in science & tech
• ask for help with anything i.e., how to get setup on Slack
• upcoming events or meetings
• what we did yesterday in a sentence, shout out any blockers
• discuss or move any items on our kanban action board i.e., order snacks

This gives us a clarity and it’s brevity sets a nice, quick pace for the day.

Dev Standup — daily

The developers will follow up with their own brief, more technical standup which is more focused on planning what the pairs will be working on that day.

IPM — 1hr weekly

Although we technically practice lean, continuous delivery and don’t do iterations in the general agile/scrum sense of the word, we do have what we refer to as weekly Iteration Planning Meetings.

IPM is where we plan the next building blocks for which our product continues to evolve and grow.

Our product owner sits with the dev team and the UX designer and goes over the next lot of backlog stories ready for estimation.

The stories are written with a high degree specificity in terms of scenarios and expected outcomes for each user persona.

Since we practice user-centered design, any story that is ready for IPM which introduces a new feature on the website for example, the final design mockup has been rigorously tested and validated with users by our UX designer.

These are key to minimising waste in the build stage.

After carefully reading the story and meticulously picking it apart in order to understand it in it’s entirety, the developers then vote on the story based on the anticipated complexity.

Complexity increases exponentially so they weigh the vote using fibonacci numbers (1, 2, 3, 5, 8, 13…). Any large story (5-8+) indicates a high complexity and as a team we try to break down into smaller stories, keeping in mind that our focus is on Minimum Viable Product and everything should be lean as to not incur waste.

Once it’s ready, it is considered prioritised and ready to start whenever the developers hit it next in the backlog.

Design review — 1hr weekly

Although we are in constant collaboration with each other throughout each working day, the design review is a good chance for one hour to go over any designs in the pipeline.

This could be something being explored as a concept by the designer and currently in user testing or an imminent feature on track to be built by the devs.

It is a good time to understand why certain features were designed to be built the way they were before implementation.

Practicing user-centered design ensures that our UX designers prioritise user interaction research as paramount to the evolution of their wireframes and mockups as to validate our assumptions about the feature design.

It is also a good time for the developers to shout out any things like consideration for reusable components or difficult things to do, always keeping MVP in mind.

Retrospectives — 1–2hrs weekly

We are big on continuous improvement; closing the feedback loop as quick as we can.

We want to have complete transparency with each other in the team so we practice retrospectives (a team retrospective and a more technical dev one).

Retrospectives are a great way to shout out anything that went well, anything that needs to be considered or watched and anything that didn’t go so well.

We draw up three columns on a whiteboard; good column, so-so/watch column and the sad column. Everyone gets 5 minutes to write up whatever they want. We then go over them quickly in case someone needs more understanding and then we have 3 votes each. We discuss from highest to lowest until the clock hits 5.30pm.

We generally have the team retro on a Friday afternoon before we go home, accompanied by a few beverages, cheese and crackers. It is a practical form of release after each week where we can let off some steam and have a laugh or a sook about certain things in order to have a clear mind before heading into the weekend.

Lunch and learns

Sharing knowledge and seeking new learnings is at the heart of a human’s curiosity.

Lunch and learns are a great way to share our learnings to a wider audience. This can be anything from unique, new, tried and tested and generally focuses on a different topic each time.

Providing lunch for the audience serves the purpose to get butts on seats with the hope that when the butts leave, their owners have learnt something new.

We generally have a category or theme for each and it varies, e.g., UX research techniques, continuous delivery of our product, guest speaker from another company who is doing things differently.

Funcooker

We are a social bunch normally but Funcooker is where the magic happens.

Each month we get together outside of work and one of us organises an event that we haven’t done before. We rotate responsibility, make sure it’s inclusive, fun and interesting. It’s a great way to get to know each other better.

Some of the past activities we’ve done in the past include pub trivia, laser tag, barefoot bowls and trampolining just to name a few.

Days over

Burnout is real. Working longer hours does not mean more work is done, in fact the work that is done when tired is often of a lower quality and we can incur more technical debt. We’re always constantly busy, but we still leave at 5.30pm.

Making our team as happy and productive as possible is paramount to the success of the product, so we also timebox our days.

That’s our lean principle shining through right there. We go home, relax with our friends and family and forget about work. It’s a new day tomorrow with all new challenges!

These are the rituals and disciplines that we’ve used to great success so hopefully they help your team too.