Excited to make a first post on my new dev blog! This is something that's been on my mind recently; I'm going to share some thoughts on the difficulties of applying a standard agile technique such as Scrum, to a group of developers working in a DAO.

In the second section, I'm going to explain a hypothetical structural model for development within a DAO and offer suggestions on how to avoid some of the current problems of working within a DAO.

What on earth is a DAO?!

In its most basic terms...

A DAO is like a club, but instead of one leader or CEO telling everyone what to do, the club is run by a set of rules on a computer. The rules make sure that everyone follows the same plan and that any money is used the way everyone agreed on.

Like a club, the members of the DAO can vote on important decisions and have control over the club's assets. And like a club, everybody can see what's happening in the club and nobody can cheat or change the rules without everyone knowing.

I stole this 👆 from the-protocol-erc.gitbook.io which goes into way more detail!

So what's the problem?

How do traditional development frameworks/methodologies...work? Well let's look at some of the guiding principles behind Agile:

• Early and continuous delivery

• Welcome changing requirements

• Deliver frequently, with a preference to the shorter timescale

• Business people and developers must work together daily throughout the project

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

There are a lot of Agile Principles that can be positively applied the differences of work within a DAO. There are some principles that cause problems in a traditional company structure, and these still exist within a DAO structure - for example if the team doesn't place significance importance on the process of self-reflection and improvement, then you're going to make the same mistakes week after week. This issue exists regardless of whether Agile is being run in a traditional company structure or a DAO structure.

However there are a few Agile Principles which are inherently more difficult when working in a DAO, which I'd like to discuss.

Face-to-face Conversation

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This emphasizes the importance of ongoing collaboration and idea-sharing, with daily meetings, sprint planning, demos, and more.

See how this might be a problem within a DAO? In some cases, you might find yourself working alongside a team of developers that you don't know, who possibly work an entirely different schedule to you or even live in a different timezone. How does face-to-face conversation work in that situation? As a result of the massive amount of change caused by the pandemic, we've learnt that a lot of interactions actually work pretty well over video. The physical limitations of remote working don't necessarily impact a face to face conversation any more.

But what if a discussion can't go ahead because the other party is offline until the evening in your time-zone? What if your current item of work depends on a decision or discussion that you can't arrange? You find yourself blocked.

So what are our options? Well, you could decide to work late - work on a different task in the meantime and jump on a call outside your own working hours to have the discussion on a call with the other developer. Sure, that works as an occasional thing - but if you're doing this on a regular basis then you're starting to blur the line between work life and home life when one schedule starts bleeding into another. For some that might not be a huge deal, but for me... that's not a good enough solution.

Okay, a different option - what if we discuss things like this as part of the daily stand up with your remote team (assuming that the team can agree on a time that gains consensus from everyone). I like this option, it is a simple solution that is designed to thoroughly wind up your scrum master; likely triggering interjections such as "Guys... can we talk about this offline?" whilst wasting the time of everyone else who has joined the stand up. Not particularly 'Agile' though. If we're supposed to be 'welcoming changing requirements', cramming all discussions into a 15 minute call after your Daily Scrum isn't the most 'flexible' thing to be working with.

Over time - small gripes add up (that one's coming from personal experience).

"Fine - we just build teams within the DAO whose members' schedules are complementary." Maybe that helps, but isn't part of the appeal of DAO membership the ability to work as a bit of a vigilante? Banding together with other global tech nomads, all contributing to build something brilliant? Does anyone else think that vision is slightly lessened if you're told that you have to work with the team on your table (drawing tenuous comparisons between a school classroom, and a global group of DAO-enlisted hungry developers here).

Skewed Velocity and Continuous Improvement

I've just unpacked one Agile Principle there, but it isn't the only one that I feel has some potential headaches when applied to the DAO way of working. For brevity, I won't dig too deeply into another one, but if you're interested then I encourage you to think about the concept of 'Velocity' - which is an important Agile metric used when calculating how much work the team can get through over the course of the next Sprint. A huge change to traditional working 'norms', that is introduced by DAOs is encouraging the flexibility of choosing your own hours, and working as much or as little as you decide. See how that could introduce a lot of inconsistency in the team's velocity over the course of many Sprints?

*A visual representation of the Continuous Improvement Practices from PMI - Disciplined Agile *

Velocity is one of the most valuable metrics to a scrum team, and it can be used a fantastic way to measure your Continuous Improvement. Whilst it is not impossible in a DAO to use Velocity to measure the team's Continous Improvement, I'd argue that it's certainly more difficult.

So what's the solution?

I'd be doing myself a disservice if I solely focused this blog post on the problems, without at least offering my thoughts on what should be done to address the issues I've brought up.

I tend to work on ideas from the complete basics and then build upon them (wow look at that fine display of Agile working). So this idea isn't in any way complete or fault-proof. Maybe it is even more fault ridden than the Agile methodology that I've just spent time picking apart. But it's my blog so I get to share incomplete ideas that I've been thinking about (affectionately referred to as "Shearer's Sentient Dumps" - who knows how long that name will last).

I think you need to look at it from a different perspective - from the ground up, design a methodology that makes things incredibly easy to pick up, work on in isolation or with very little support, and check in. I call this approach "the food chain" - a name that was completely and unapologetically ripped off from working in a previous company.

Food Chain fundamentals

Each developer within a DAO who could be situated anywhere on the planet, has the same little 'Virtual Pneumatic Pipe' shooting out of their desk. Out of that pipe can come a few different things. Firstly, the pipe can bring lovely bite-sized well defined tasks. These tasks have been refined by more than one person, and have an approximate indication of the size of the item. Nothing too new here - the pipe delivers items from the backlog that are well defined, and contain enough information for anybody to pick up.

What does a developer do with that item? Well, I'd like to unapologetically steal this next bit from a leaked email sent by Elon Musk to Tesla employees:

To: Everybody
From: Elon Musk
Date: Monday October 4 [time redacted]
Subj. Please Note

If an email is sent from me with explicit directions, there are only three actions allowed by managers.

1. Email me back to explain why what I said was incorrect. Sometimes, I’m just plain wrong!

2. Request further clarification if what I said was ambiguous.

3. Execute the directions.

If none of the above are done, that manager will be asked to resign immediately.

Thank you,

Elon

Blunt as ever, who would expect anything else from a man trying to launch humankind to Mars. I've stolen the options that he gave and applied them to this work item that we've received from the food chain. So, with our work item - the options are:

• Send the item back because something about it is either wrong, or not required.

• Request additional information about some part of the item. This doesn't mean 'context' gaining context on the issue is something you should be able to do yourself, and not be given from someone else in person. The item is sent back to the creator of the item in order to get additional information added.

• Just... do it! Work on the task, and check it in for code review, following whatever processes your DAO has in place.

Pretty straightforward so far - you either work on the item, or you send it back. Easy. But what if you're the person that created an item, and someone else sends it back to you? Well that nicely leads us on to the next thing that can pop out of the food chain...

Revising work items

You created a work item for a feature, and popped it into the food chain. Someone else picked that up, realised some important detail was missing, and popped it back in the food chain where it was delivered back to you. It is now on you to amend the work item so that someone else can get on with the development.

This should be a minor amendment only - members of the team will be evaluating the work item backlog and refining the items as an ongoing process, so the item will have been discussed at some point between two people. Add whatever detail is missing and pop it back into the food chain, or mark it as a larger amendment which will move the work item back onto the backlog for more in-depth future discussion.

Breaking things down

Remember above where I ripped off Elon Musk to set out 3 options for dealing with a work item? There's actually a secret 4th option... break the thing down.

Part of the way that a DAO is organised, means that an item isn't necessarily going to be worked on by someone who is competent enough to complete that work task. Rather than setting the barrier of entry high (eg. 1 years experience in Solidity required to join this Dev team), we can allow someone to break the task down into 2 smaller items.

There are rules here, such as when breaking a work item into 2 'child items', 1 of the child items must have a smaller size than the parent item. This gives flexibility to the whole model - the process can be followed to break down an entire feature from the largest item (sometimes called an 'Epic' in project planning terminology) into discrete items of work (sometimes called 'Story' or 'Task' items).

One other rule - items that have an estimated sizing as 'Small' (or whatever your smallest metric is) cannot be split into 2 child items. A well defined work item should take around half a day's effort - entirely my opinion but I feel that decomposing items into parts that are too small will eventually reach a point where process harms productivity.

This is a way to remove that barrier of entry - if the developer doesn't have the competency to complete the entire work item, then they can break off the bit that they can do and encapsulate the rest of the work in another work item that goes back into the food chain. Obviously common sense needs to be applied to avoid this process getting messy or lazy, but that's something that can be handled by individual DAO process.

Conclusion

I have to end this dump somewhere, otherwise it will end up even more of a rambling mess than it already is. I understand that my suggestions of a solution focus more on the process of developing work items within a DAO rather than addressing some of the more usability-focused issues I pointed out in traditional Scrum.

However I do see the suggested model as an idea that could improve or reduce the impact of some problematic Agile Principles when applied to a DAO organisational structure.

Maybe I'll flesh it out a bit more in a future post. Thanks for reading, please give me any feedback as I've never written a blog post before and could likely use a lot of kicking in the right direction.