I think I can explain agile in three words; “uncovering better ways”.
These three words feature in the first sentence of the manifesto for agile software development. They are that important. They tell us the essence of agile.
Uncovering – Finding out as we go, not thinking we can know it all upfront.
Better – Always looking for improvements.
Ways – Tells us it’s a practice, it needs to be done, repeatedly, to make it work.
Good digital teams:
Based on Laura Bunt‘s post on leading charities in a digital society.
I’m going to try out some different retro formats, and this month it’s the starfish.
Tackling the four big risks (valuable, usable, viable, feasible) to create a quality product environment. Last month I started to work on improving how we test throughout the product development process, and on infrastructure reliability. Lots more to do here but stable tech and usable products feel like the most urgent.
I’ll keep working on my side projects:
My reflective practice of daynotes, weeknotes and monthly retros and delivery planning continues. It’s the most consistent thing I do. I also reorganised my roadmap a bit to make it clearer which items are achieving which goals.
Starting new things. Both at work and for side-projects (the list is growing again). High WIP is a constant theme for both. I think I managed to highlight one of the ways that unplanned work arises and gets in the way of planned work.
Systems thinking and mapping for understanding what makes things work the way they do (mostly human behaviour, assumptions, cultural practices, all the kinds of things I find hard to understand).
Using mini roadmaps/kanbans for each project to break the work down into more achievable chunks. I have these in my head but it would be better to have them documented.
Holding on tightly to things that matter to me but don’t matter to anyone else, e.g., what I see as the corruption of good practice. It’s just not worth the stress of trying to communicate why it should matter to others. I know it’s part of a bigger problem (systems mapping above) but I can’t change it by being dogmatic.
Thinking through side-projects rather than jumping into creating something just because it interests me. Basically, be my own product manager. But still giving myself the freedom to follow my interests. I think I can create some kind of template for this.
I’d also like to see if I can connect my side-projects and thinking more coherently. It makes sense to me that the stuff about responsible product management is one of the practical aspects of system-shifting product management’s vision stuff. And the technology charity is an example of system-shifting product management and using technology to achieve social impact at scale. So, I think they do connect, but maybe not in a very obvious way.
Finding opportunities to connect with people (in and outside the team). I don’t know how yet, but it feels like a valuable thing to do. My usual thinking is that this needs a ‘vehicle’, a reason to spend time together and talk about things but maybe that’s not always the case.
Whatever transformation initiative or framework adoption it is, if it fails, it gets the blame. Agile, lean, OKRs, etc.
But a concept can’t fail, just as it can’t succeed. It’s just a concept. It doesn’t come with inherent success criteria that define success or failure.
An idea, mindset, framework, etc., can’t succeed or fail. Only our implementation of them can, but that’s hard to admit so we blame the thing instead.
There doesn’t seem to anything in the project management principles that a product manager would say wasn’t also appropriate to product management. Maybe they aren’t so different.
“uncovering better ways”
These three words are what agile is truly about.
Uncovering – Not assuming the answers are known upfront, but that they have to be found along the way.
Better – Continually seeking to improve.
Ways – Performing a practice, doing, and learning by doing.
The lesson for this month; too much work in progress.
Tried to be more available for the team but still big gaps here. I didn’t manage to figure out the right balance between spending time with the team that is valuable and not leaving them with less time to achieve things.
Worked on some aspects of creating an ‘enabling environment’ to help with reducing work in progress, which is definitely one of our barriers.
We tried a few things to get better at delivering projects faster, including validating ideas, giving ourselves deadlines and reducing the scope. There’s still so much more we can do here.
Had a couple of interesting chats on Twitter, and joined a group video call about using AI in the charity sector and perhaps using it to accelerate innovation in the sector. One reflection I had was how dependent being part of a network is on making any kind of contribution like this.
I think the contribution I want to focus on is writing the technology charity book.
Started writing a book about the technology charity, and how charities can use technology to achieve change at scale.
Still haven’t done anything on my BSL course.
Nothing on this course either.
Nada.
Very slowly reading Delivery Management.
Added a few more things. Need to answer the question of whether it should have individual articles, podcast episodes, etc., which is probably more useful for users but a lot more work for me, or just have the blog, podcast, etc.
Wrote one edition of Irregular Ideas, just because I had an idea and some time.
I’ve got one email to write and add to this, and it’s been on my to do list for ages, but I still didn’t get around to it. I’m not sure it’ll make much difference but I want to get the thinking about the four ways charity product managers achieve value wrapped up.
Didn’t work on magix teams, but I have collected some more thoughts about what a ‘matrix’ means and how it’s rooted in working collaboratively.
I wrote weeknotes on schedule every week. That’s about the only thing I’ve managed to maintain any consistency for. I haven’t really written much each day, but I think I want to use the notes section of my website to record more ongoing thoughts.
Was indoors most of the month.
Hardly walked at all.
Did more on buying a house.
Organisations succeed when they have a fast flow of value.
Fast, because our users get value early and often and we get feedback sooner. Flow, because smooth efficient processes reduce waste. And value, because quality outcomes make it worth it.
Removing the barriers to a fast flow of value is the transformational work all organisations need.
Agile, lean, dev ops, digital, remote working; all of these are the tools of transformation, they aren’t the transformation. Being agile or digital isn’t the point, the point of transformation is achieving a fast flow of value.
