Open Thinkering

Menu

Tag: projects

Enjoy things while they last (or hope for the best, prepare for the worst)

Note: it’s hot, this post might be be more ramble-y than usual…


Next to my bed I have one of these:

Glass paperweight with image of waves within it

It’s a glass paperweight that serves as a memento mori, a reminder that one day I will die. That might seem a bit morbid, but it reminds me to carpe diem (“seize the day”, to use another Latin phrase) and that things won’t be this way forever.

My kids will grow up and leave home.

My current state of calm will dissipate.

My possessions will stop working, get lost, or be stolen.

The list is long, for good and bad.


But my reason for writing this post is not a personal one, but a professional one. Right now, I’m more interested in talking about projects and initiatives ‘dying’ than me kicking the bucket. There have been multiple reasons over the past week where I’ve noticed that people expect things that start off great to continue to be so.

An OER repository was sold off to a company whose website is blacklisted by many educational institutions. A popular Android launcher was sold to an analytics company that’s often blacklisted by network blocking software. A project I’ve been involved with looks like it could be in danger of betraying its radical roots.

This is all very predictable, and is the reason for the popular phrase “hope for the best, prepare for the worst”. Especially in the kind of work I do at the intersection of learning, technology, and community, there are some amazing people collaborating on some fantastic things. It just takes a few bad actors (or people with ‘misaligned incentives’ shall we say) to spoil things.

That’s why setting up projects the right way from the beginning is so important. With MoodleNet, for example, we used the AGPL license, which meant that after I and the team resigned due to some internal drama, the Open Source code could form the basis of the project which has turned into Bonfire.

Even without specific licensing, just working openly can have the same effect. For example, there’s an archive of the work I did with a community that I helped grow at Mozilla around the Web Literacy Map. There’s no reference to it any more on the Mozilla site, but I can still reference it myself.

I’m not bitter about these things. (Well, not any more.) My point is rather than you should set up projects and initiatives in open ways, providing ways for awesome, talented people to get involved. But don’t be naive while doing so. Use defensive licenses, like the AGPL, and the wonderful Creative Commons Attribution-Sharealike (CC BY-SA) license which forces derivative works to be shared under the same license.

The same is true of legal structure and governance. WAO is set up as a co-operative with a flat structure and Sociocratic decision-making. It’s not possible for one person to sell out our company from underneath us because of the legal structure we created, after taking advice from more senior members of the co-operative community. And we’ve learned that consent-based decision making allows us to make decisions in line with our values.

Processes (especially around decision-making) work… until they don’t. You have to be intentional about these things. Remember that contracts are for when things go wrong, so cover your back. Imagine the worst thing that could happen, and put in place safeguards. Come up with ways to make decisions in productive ways with other people. Share your work far and wide, but protect it using an appropriate license.

Remember that our time on this planet is short, so let’s be awesome to each other.


In case you’re wondering, I bought my memento mori from The School of Life, and while you can’t get this particular one any more, there are others which are great — if not quite as awesome.

Managing projects is about understanding context

Agile is a verb, not a noun

Ah… projects. There are some people who believe that the One True Way is Agile™. And by that they mean agile development frameworks such as SAFe and RAD and ASD and other awkward acronyms. At least for the kind of work I do with my co-op colleagues, those people are wrong.

The main thrust of the Agile Manifesto is that ‘agile’ is a verb rather than a noun. You don’t “do” agile, you work in an agile way. The difference is important.

Just as a recap, or perhaps for those who haven’t seen this before, here are the twelve principles of agile software from almost 20 years ago:

  1. Our highest priority is to satisfy the customer
    through early and continuous delivery
    of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

For me, the five bits that tend to leap out at me are those I’ve highlighted above. I believe agile methodologies can be applied to almost everything, so stripping out the references to software, focusing on the parts I’ve highlighted, and doing a bit of rewriting gives:

  • Simplify
  • Establish a sustainable pace
  • Build projects around motivated individuals
  • Create self-organising teams
  • Welcome changes based on feedback the audience you’re targeting

I have little time for people who try and impose a particular approach without understanding the context they’re entering into. Instead, and although it may take longer, co-creating an agile approach to the problem you’re tackling is a much better solution.

So, in summary, investing in people who work within a particular context, while being informed by what has worked elsewhere is absolutely the best approach. At least in my experience. But the best of luck to those who think that Industry Best Practices® and blunt implementations of complicated frameworks are going to save them.

I’ll be watching with my co-op colleagues, eating popcorn, getting ready for the inevitable call or email to help. And, you know what? We’ll be happy to.


This post is day three of my #100DaysToOffload challenge. Want to get involved? Find out more at 100daystooffload.com


Header image by Christopher Paul High

Winnowing the MoodleNet project down to MVP size

Note: this post refers to the MoodleNet project that I’m leading. More on that can be found here: moodle.com/moodlenet

Context

As a knowledge worker, you can’t win. If you do your job well, then the outputs you produce are simple and easy to understand. It’s your job to deal with complexity and unhelpful ambiguity so that what’s left can comprehended and digested.

In a way, it’s very much like the process of writing for an audience. We’ve all read someone’s stream-of-consciousness email that said much but conveyed little. Good writing, on the other hand, takes time, effort, and editing.

The problem is that high-quality knowledge work looks easy. Long hours of thinking, discussing, and experimenting are boiled down to their essentials. You just see the outputs.

Perhaps the most obvious example would be brand redesign: almost no matter what’s produced, the response is usually that the process resulted in money wasted. That’s even more true when there’s public money involved.

Belfast 2008
The City of Belfast spent around £200k on this logo in 2008. It’s a heart-shaped B conveying love. I quite like it..

As a result, logo designers tend to share the process which got to that point. They share iterations towards the final idea, any rejected ideas, and the conversations with people who had some input into the process.

Likewise, all knowledge workers should show their work, as Austin Kleon puts it.  This not only proves the value of the work being done, but invites commentary and constructive criticism at a time when it can be useful — before the final version is settled upon.

Process

A Minimum Viable Product, or MVP, is “a product with just enough features to satisfy early customers, and to provide feedback for future product development.” However, in my experience, there’s a few stages before that:

  1. Research: whoever’s in charge of the project (in this case, me!) situates themselves in the landscape, talks to lots of people and does a bunch of reading.
  2. Hypothesise: the same individual, or by this point potentially a small team, comes up with some hypotheses for the product being designed. A direction of travel is set, but at this stage it’s only as granular as north, south, east, or west.
  3. Design: a small team, including a designer and developer, take a week to ‘sprint’ towards something that can be mocked-up put in front of users. The result is the smallest possible thing that can be built and tested.
  4. Prototype: developers and designers come up with a working prototype that can be put in front of test users within a controlled environment. Sometimes this uses software like Framer, sometimes it’s custom development, and sometimes it’s powered by nothing more than Google Sheets.
  5. Build: the team creates something that can be tested with a subset of the wider (potential) user base. The focus is on testing a range of hypotheses that have been refined through the previous four processes.

Following this, of course, is a lot of iteration. It may be that the hypotheses were shown to be invalid, in which case it’s (quite literally) back to the drawing board.

Where we’re at with MoodleNet

Right now, I’m working with colleagues at Moodle around a job ‘landscape’ for a Technical Architect to join us in the next few months. In the meantime, we’re looking to work with a design and development consultancy to take us through steps 3-5.

It gets to the stage where you just need to build something and put it in front of people. They either find it useful and ‘get’ what problem you’re helping them solve, or they don’t.

You can’t be too wedded to your hypotheses. As project lead, I was sure that a federated approach based on an instance of Mastodon was the place to start, until I spoke with some people and did some thinking and realised that perhaps it wasn’t.

And, of course, it’s worth reminding myself that there’s currently the equivalent of 0.8 FTE on this project (I work four days per week for Moodle). Rome, as they say, wasn’t built in a day.


Image: HEAVENLY CROP by American Center Mumbai used under a  CC BY-ND license

css.php