Tag: context

My two biggest insights from last year

Posted on January 2, 2021January 2, 2021 by Doug Belshaw

Last year, the pandemic was more ‘annoying’ to me and my family than damaging to our health or finances. So, if there’s one thing that 2020 showed me, it was my privilege.

I turned 40 in December, which means I’m now inescapably middle-aged. I’m also a straight, white, male. Thankfully, somewhat unrelated to the pandemic, I also spent 2020 learning a bunch of things about myself and how I relate to others. This happened primarily through CBT, research and learning around the Black Lives Matter movement, and doing some work around Nonviolent Communication.

My two biggest takeaways from the above were:

I don’t need to have an opinion about everything. As Marcus Aurelius said, “We have the power to hold no opinion about a thing and to not let it upset our state of mind—for things have no natural power to shape our judgments.”
I should stick to only discussing my own experiences and context. I have no idea of the internal world of others, and how things which seem major/minor to me might be minor/major to them.

I guess this is a lo-fi version of Hume’s fork. In other words, there are statements that can be made about ideas (which are either true or false by definition) and statements that can be made about the world (which are true or false based on experience).

Over the last six months, I feel that there’s been a shift in my writing here since starting the #100DaysToOffload challenge. This has been incredibly useful in weaning me off assertions meant to provoke a response from others towards more introspection and self-documentation.

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

Managing projects is about understanding context

Posted on June 18, 2020June 18, 2020 by Doug Belshaw

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:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
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

Collaboration, perception, and context.

Posted on March 20, 2011 by Doug Belshaw

a Zed and two Noughts

One thing you can never really know is how people perceive you. This is especially true at a distance with people you’ve never met face-to-face. Whether face-to-face or at a distance, however, each situation depends heavily upon the ‘history’ you share with others. There are only a few people, for example, that I’ve known online since 2004 (when I started teaching) that I haven’t met face-to-face. Context changes things.

As I explained in On the glorious weirdness of connecting with people online (2009) I’m careful about the impression I give to people when meeting them for the first time. This first impression is often the one that lasts, or at least colours all future interactions. It’s been interesting, for example, to see how people I’ve known for years have reacted to my co-kickstarting the Purpos/ed debate (overwhelmingly positive) compared to the reactions of a small minority who have assumed that it’s some sort of Ponzi scheme.

The differing reactions, of course, demonstrate that at least some people think I’ve got form in collaborative and co-operative ventures:

2004 – Set up a Grouper-powered network to help members of the Schoolhistory.co.uk forum share educational resources.

2006 – Demise of Grouper led to establishment of HistoryShareForum.com.

2007 – Inspired by EdTechTalk, started EdTechRoundUp to enable UK-focused weekly discussion and debate of issues relating to educational technology.

2008 – Created elearnr.org to host guides relating to social media and educational technology.

2009 – Started a Twitter hashtag called #movemeon to provide advice for newly-qualified teachers (now collated into a book!). Shared strategy and plans relating to Director of E-Learning position, spurring others to do likewise.

2011 – Co-kickstarted Purpos/ed with Andy Stewart to provide a non-partisan, location-independent platform for discussion and debate about the purpose(s) of education.

I’m not being disingenuous when I say that over-and-above an income that provides for my family I’m not particularly interested in money. It’s a means to an end. What I am interested in is connecting and collaborating with people, attempting to inspire them, and working to make the world a little better than I found it.

There’s a lot of cynicism, jockeying and false promising in western societies. My aim for Purpos/ed (and any future projects I help establish) is to provide something of an antidote to this world-weariness I see around me. It’s taken me a while, but I’ve finally realised: you don’t have to ask permission to be the change you want to see in the world.

If you feel likewise, and have an interest in education, why not come along to the Purpos/ed Summit for Instigators on 30th April in Sheffield? We’re trying to make the world a better place by debate and discussion leading to action. Why not join us?

Image CC BY-NC-SA Naccarato