Open Thinkering

Menu

Tag: projects

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

How to build an architecture of participation

Back in 2014, when I was still at Mozilla, I wrote a post entitled Towards an architecture of participation for episodic volunteering. I bemoaned the lack of thought that people and projects put into thinking through how they’re going to attract, retain, and encourage the volunteers they crave.

‘Architecture of participation’ is a term used to describe systems designed for user contribution. It’s a term I use relatively often, especially at events and thinkathons run by our co-op. Not only is it a delightful phrase to say and to hear, but (more importantly) it’s a metaphor which can be used to explore all kinds of things.

In my 2014 post, I made some suggestions for ways to improve your project’s architecture of participation. I’ve updated and improved these based on feedback and my own thinking. Based on my experience, to build an effective architecture of participation, you need:

  1. A clear mission – why does this project exist? what is it setting out to achieve?
  2. An invitation to participate – do you have an unambiguous call to action?
  3. Easy onboarding – are there small, simple tasks/activities that new volunteers can begin with?
  4. A modular approach – do volunteers have to commit to helping with everything, or is there a way which they can use their knowledge, skills, and interests to contribute to part of the project?
  5. Strong leadership – do the people in control of the project embody the mission? do they have the respect of volunteers? have they got the capacity to make the project a success?
  6. Ways of working openly and transparently – does the project have secret areas, or is everything out in the open? (this post may be useful)
  7. Backchannels and watercoolers – are there ‘social’ spaces for members of the project to interact over and above those focused on project aims?
  8. Celebration of milestones – does the project recognise the efforts and input of volunteers?

Most of the links I can find around architectures of participation seem to be tied to Web 2.0 developments pre-2011. I’d love to see a resurgence in focus on participation and contribution, perhaps through the vehicle of co-operativism.

If you’ve got another couple of features that lead to a positive and effective architecture of participation, I’d love to hear them. Then this can be a 10-point list! As ever, this post is CC0-licensed, meaning you can do with this whatever you like.


(Image drawn by audience members during a keynote I gave at Durham University in 2015)

css.php