I’ve recently been playing with ways of explaining the extended Agile team for large and largeish organisations. I get frustration when I see Agile teams that are essentially siloed off from the wider business (for many reasons). This causes dependency and communication issues and means they just aren’t able to deliver anything very quickly. I don’t think the answer is to just throw everyone in together as it’s not always that practical and can cause communication issues as the team gets really big. I’ve been using the Agile team onion to describe a model of how it might work.
I have been thinking about barriers to diversity at conferences a lot recently. This is sparked by a few things, including my own recent conference submissions, an experiment that I carried out recently that let people encourage their friends to speak and conversations on the topic. Here is the round up of some of that thinking and things for conferences to consider to reduce those barriers.
As you may know from previous posts, I’ve been busy writing a book called “Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations”.
The book is now ready and you can now buy it both on kindle and as a paperback (print on demand) book.
I am currently involved in running meetups in London (Agile on the Bench) and Leeds (Agile in Leeds) and c0-ran a conference last year. A couple of the challenges that I have are around finding new and interesting speakers as well as maintaining diversity in the speakers and the audience. A challenge that many organisers face.
I have found myself explaining the role of delivery manager a lot over the last few weeks, so I thought I would share that description here.
The term delivery manager is an agile role used in government and other organisations, mainly within (but not limited to) digital or IT departments. It describes the person on the agile team whose main concern is enabling a team of skilled people to deliver value. They create the right environment for the team. They facilitate the team and remove obstacles and blockers that might get in their way. They work closely with the product manager (sometimes known as product owner), but while the product manager is concerned with the vision the delivery manager is concerned with making it happen. The perfect visionary and doer pairing.
As I mentioned in my last post, I have been writing a book called ‘Building successful communities of practice: Discover how learning together makes better organisations’, which is due to be published in early 2016. I wanted to share more about how I have gone about writing it using agile tools and techniques.
I have been very busy recently writing a book (currently) called Building successful communities of practice: Discover how learning together makes better organisations. It’s been in progress since September and I’m planning on publishing it early next year.
I’ve run a fair few workshops over the years and they tend to include many sticky notes and have learnt a few tricks along the way, here are my top tips for pro sticky note handling.
Recently I blogged about the Agile on the Bench conference, a minimum viable conference in a campsite that I ran with David Lowe. It happened last Saturday, 25th July and it was an awesome day. The speakers and audience were fantastic and, much like our lunchtime events, the sun came out, despite the heavy rain the day before. In my last post I talked about what we were trying to achieve and here I’ll talk about the successes, what we learnt, where we could improve and share the conference budget.
Those of you who read my blog, or follow my twitter account will have seen that I co-run a meet-up called Agile on the Bench. This summer we are taking the idea forward to a one day conference in a campsite.
Getting busy people in a room together to workshop is hard and a challenge I came across last week. I’m currently working at the wonderful ustwo as an Agile coach (who are currently hiring for Agile coach/PMs in case you were wondering). One thing that I was asked to help out with is a refresh of the guidelines around how to kick off a new project. As we had so much knowledge in the team, I wanted to make sure that everyone had a chance to help build any proposed solution, but the biggest challenge that we had was that the team is so busy with their respective projects, getting them all in a room together at the same time for a workshop session was going to be near impossible.
There was a great turn out for the third, chilly but sunny Agile on the Bench last Wednesday lunch time, thanks for everyone that made it along and contributing to the discussions.
2015 is going to be all about learning and learning to learn. There has been a shift in the way that organisations are run, as the speed of technology and innovation increase, being able to learn and adapt is more and more important in order to keep up. This is why so many organisations are moving to more agile ways of working, which embraces learning and allows for change.
After a successful first Agile on the Bench, we decided to do it all again, who’d have thought standing in the cold listening to people talk about agile related topics, without the use of tech would be what people wanted to do with a lunch time in December, but it is!