Help my small organization become more... agile... without "Agile"?
May 25, 2020 6:56 PM
My (40 person) NGO organization produces reports and 'communications products' (formerly paper, but increasingly complex/digital), and doesn't have codified processes/protocols/norms/tools to ensure that everyone along a product production line are alerted to changes in status/delays etc. The speeding and halting of production is communicated with patchy person to person emails, and by the communications director physically walking to each desk of every project manager and technician once per week. Inevitably, communication gaps are rising and with our COVID19 shift to telework, exponentially. I'm their advisor on technology and innovation. What can I suggest?
I searched prior askmes on terms such as: production process management, agile, organizational learning and efficiency, many posts like this this this and this SWOT for SCRUM seem fitting/ informative (many seem to be asking about software or IT development, with responses mentioning Agile/Scrum/PhoenixProject, or ironing out terminology issues like 'differences in defining 'done').
Most caution that software is v often not the answer. I get that, so I’m hoping to do a quick dive of ideas/tools/approaches now, with the intention of cultivating slower, strategic, ‘right-sized’ organizational change - first to tackle the urgent issues, and then to cultivate deeper/process based change or tools over the next 9-12 months (minimizing backfire if possible).
The organization (40 people) has long produced traditional printed, and now digital communication products (reports, websites, GIS maps etc). Unanticipated delays, at every stage of the process, are commonplace, and can range from a few days to three months. Beyond a general lack of 'accountability culture' (that's for a different question), the organization doesn't have codified processes/protocols/norms/ or tools to ensure that all along the production chain are alerted to changes in status/delays etc. The speeding and halting of production is communicated (single person to single person) either by email, or one person (the chief communications officer) physically walking around to all project managers desks and all technicians once per week.
Inevitably, gaps arise. With the COVID19 induced telework policy, its become horrific and I anticipate much more fallout coming the rest of the year if we don't come up with some solutions.
Like many small businesses, COVID19 shoved us into a long delayed embrace of Teams. General sentiment is that its not perfect, but it could be worse... we could use it better of course. Maybe there's a readymade Teams plugin we have no idea about that could help track and alert in production process?
Yet even when we were all in the same office, people sincerely don't know who they should have notified about what/how it affects others and their planning, and how quickly.... and/or actions/timelines/assigning of responsibilities don't come with the notification. How do we change this?
Most folks are working on between 3-5 different projects, the technical (IT/Webdesign) folks possibly responding to requests from 10+ projects each. Delays can occur all of the in pre-project phase (delayed funding), the science side: mid-research/writing/review, and in physical/virtual production (technology/misinterpretation/network issues and outages etc). The Tech team (to date) deals with delays coming from the science team by simply switching tasks when able, and are understandably resentful when the Science person gets upset that they aren't then available 'on demand' as they'd indicated (sometimes long prior).
In my past, I've worked with dynamic modelling/conceptual modelling/mediated modelling.
Visually in my head I can see the feedback loops forming, and the delays exacerbating existing planning and budgeting difficulties.
So my instinct is to hone more specifically in on the production process, suggest we document visual maps of 'whole team soup-to-nuts processes/production, and also write up more protocols/norms/expectations, at least to daylight them/elicit group design/consensus. So that:
1) greater system/colleague awareness would (in theory) lead to fewer/shorter preventable communication delays
and
2) incoming employees can also see and participate faster, as opposed to (current) trial-and-error.
But I'm concerned that's not enough, or not concrete enough to help other managers document expectations/shift behavior. And, we'd still need more group awareness of where products are they're at, so people can receive notification and 'get ready' that its almost 'their turn' to contribute.
A last question pertains to How does one institute new communication 'norms'? And how clearly must we spell out what words must mean- ala 'done' in a prior askme? We have a very diverse, multicultural organization, so our former assumptions that this would be 'common sense' is not the case....
To pre-empt a question I saw on prior askmes: Yes, there is 'will' among management to change, and a Chief Comms Officer that can champion the change, and I (overseeing the tech/innovation team) report to the COO. The tech team thrive working on their own IT/GIS/Web projects, admittedly they could be working better as a team, and in our next meeting I'm going to be asking them for team approaches to this same question, hopefully seeded with some ideas from here.
I also note that many of the prior askmes warn that many of the digital tools from IT/software development (like Agile etc can be intertpreted as micromanaging etc, and for this situation are not likely the answer, but don't know what else to look for.
Hit me with your experiences/approaches/ideas/resources if you have 'em! Blog posts/tool kits/rules of thumb/ anecdotes.... all good!
Many thanks in advance!
I searched prior askmes on terms such as: production process management, agile, organizational learning and efficiency, many posts like this this this and this SWOT for SCRUM seem fitting/ informative (many seem to be asking about software or IT development, with responses mentioning Agile/Scrum/PhoenixProject, or ironing out terminology issues like 'differences in defining 'done').
Most caution that software is v often not the answer. I get that, so I’m hoping to do a quick dive of ideas/tools/approaches now, with the intention of cultivating slower, strategic, ‘right-sized’ organizational change - first to tackle the urgent issues, and then to cultivate deeper/process based change or tools over the next 9-12 months (minimizing backfire if possible).
The organization (40 people) has long produced traditional printed, and now digital communication products (reports, websites, GIS maps etc). Unanticipated delays, at every stage of the process, are commonplace, and can range from a few days to three months. Beyond a general lack of 'accountability culture' (that's for a different question), the organization doesn't have codified processes/protocols/norms/ or tools to ensure that all along the production chain are alerted to changes in status/delays etc. The speeding and halting of production is communicated (single person to single person) either by email, or one person (the chief communications officer) physically walking around to all project managers desks and all technicians once per week.
Inevitably, gaps arise. With the COVID19 induced telework policy, its become horrific and I anticipate much more fallout coming the rest of the year if we don't come up with some solutions.
Like many small businesses, COVID19 shoved us into a long delayed embrace of Teams. General sentiment is that its not perfect, but it could be worse... we could use it better of course. Maybe there's a readymade Teams plugin we have no idea about that could help track and alert in production process?
Yet even when we were all in the same office, people sincerely don't know who they should have notified about what/how it affects others and their planning, and how quickly.... and/or actions/timelines/assigning of responsibilities don't come with the notification. How do we change this?
Most folks are working on between 3-5 different projects, the technical (IT/Webdesign) folks possibly responding to requests from 10+ projects each. Delays can occur all of the in pre-project phase (delayed funding), the science side: mid-research/writing/review, and in physical/virtual production (technology/misinterpretation/network issues and outages etc). The Tech team (to date) deals with delays coming from the science team by simply switching tasks when able, and are understandably resentful when the Science person gets upset that they aren't then available 'on demand' as they'd indicated (sometimes long prior).
In my past, I've worked with dynamic modelling/conceptual modelling/mediated modelling.
Visually in my head I can see the feedback loops forming, and the delays exacerbating existing planning and budgeting difficulties.
So my instinct is to hone more specifically in on the production process, suggest we document visual maps of 'whole team soup-to-nuts processes/production, and also write up more protocols/norms/expectations, at least to daylight them/elicit group design/consensus. So that:
1) greater system/colleague awareness would (in theory) lead to fewer/shorter preventable communication delays
and
2) incoming employees can also see and participate faster, as opposed to (current) trial-and-error.
But I'm concerned that's not enough, or not concrete enough to help other managers document expectations/shift behavior. And, we'd still need more group awareness of where products are they're at, so people can receive notification and 'get ready' that its almost 'their turn' to contribute.
A last question pertains to How does one institute new communication 'norms'? And how clearly must we spell out what words must mean- ala 'done' in a prior askme? We have a very diverse, multicultural organization, so our former assumptions that this would be 'common sense' is not the case....
To pre-empt a question I saw on prior askmes: Yes, there is 'will' among management to change, and a Chief Comms Officer that can champion the change, and I (overseeing the tech/innovation team) report to the COO. The tech team thrive working on their own IT/GIS/Web projects, admittedly they could be working better as a team, and in our next meeting I'm going to be asking them for team approaches to this same question, hopefully seeded with some ideas from here.
I also note that many of the prior askmes warn that many of the digital tools from IT/software development (like Agile etc can be intertpreted as micromanaging etc, and for this situation are not likely the answer, but don't know what else to look for.
Hit me with your experiences/approaches/ideas/resources if you have 'em! Blog posts/tool kits/rules of thumb/ anecdotes.... all good!
Many thanks in advance!
If you're a book person, start reading the Phoneix Project tonight. It's kind of long but very engaging, and it's going to exactly describe the problems you're having...and then the you how to fix them.
If you aren't a book person read it anyway, or get the audio book.
It is all about a software company but the entire point is about delivering "product" just like a factory would. It sounds like this applies to you.
posted by Nonsteroidal Anti-Inflammatory Drug at 7:31 PM on May 25, 2020
If you aren't a book person read it anyway, or get the audio book.
It is all about a software company but the entire point is about delivering "product" just like a factory would. It sounds like this applies to you.
posted by Nonsteroidal Anti-Inflammatory Drug at 7:31 PM on May 25, 2020
Here are some ideas, from the least handholding to the most:
1. Ticketing system/bug tracker. Each project is a ticket and people update statuses/write notes about what’s going on and then assign the ticket to the next person when they’re done with their part. They work beautifully for non-software project tracking too, but obviously require everyone to change their workflow to some extent to include using the ticketing system.
2. Wiki or shared Google Document/Google Sheet listing every project and its current status. Prompt everyone to check and update the document daily/weekly/whatever you need till it’s habit.
3. Daily/weekly scrum-like all hands check-in call. Someone (you or the COO) leads it, calls on people in turn, and they give the briefest possible update on what’s going on with the projects they’re working on. Everyone listens and takes notes for what applies to them.
4. Someone (you, the COO, or a PM you hire) takes on the task of being the organization’s communicator for now and literally talks to each person as often as possible, gets status updates, and passes them along to the relevant people. It will be the easiest option for the 39 other people but the most time intensive for whoever gets stuck doing that and probably the least sustainable over time. But it could do in a pinch for a week or two while you set up a better option.
Probably in general a couple of visual flow charts and meetings to explain them to everyone would be smart but probably not sufficient and a time suck at what may already be a hectic time with trying to figure out everyone working from home, etc. If I were in your position, I’d do option three or four to solve the immediate problem while trying to research and set up option one or two for longer term.
posted by bananacabana at 7:48 PM on May 25, 2020
1. Ticketing system/bug tracker. Each project is a ticket and people update statuses/write notes about what’s going on and then assign the ticket to the next person when they’re done with their part. They work beautifully for non-software project tracking too, but obviously require everyone to change their workflow to some extent to include using the ticketing system.
2. Wiki or shared Google Document/Google Sheet listing every project and its current status. Prompt everyone to check and update the document daily/weekly/whatever you need till it’s habit.
3. Daily/weekly scrum-like all hands check-in call. Someone (you or the COO) leads it, calls on people in turn, and they give the briefest possible update on what’s going on with the projects they’re working on. Everyone listens and takes notes for what applies to them.
4. Someone (you, the COO, or a PM you hire) takes on the task of being the organization’s communicator for now and literally talks to each person as often as possible, gets status updates, and passes them along to the relevant people. It will be the easiest option for the 39 other people but the most time intensive for whoever gets stuck doing that and probably the least sustainable over time. But it could do in a pinch for a week or two while you set up a better option.
Probably in general a couple of visual flow charts and meetings to explain them to everyone would be smart but probably not sufficient and a time suck at what may already be a hectic time with trying to figure out everyone working from home, etc. If I were in your position, I’d do option three or four to solve the immediate problem while trying to research and set up option one or two for longer term.
posted by bananacabana at 7:48 PM on May 25, 2020
We have set up a weekly business planning group Teams meeting which consists of key process stakeholders and which holds in common shared resources and project money. We have hired a Programme manager who sits on top of the streams and whose responsibility is to create an overview of resources and help the organisation learn to structure things as projects. Note that we are in a different area and we're essentially scrumming business products for customers, but you might find something useful in it. There are generally 18-20 people per meeting.
1) Introduction: This may sound deeply goofy, but it works and in a multicultural organisation, it has been essential to get people listening. We spend anywhere between 20-45 minutes getting to know each other. I facilitate. Often we use a game called "Teamwork" questions. Last week I had people interview each other with some set questions. This week we're doing some storytelling. This builds a culture of communication and starts the meeting with everyone listening.
2) Status: Programme leader presents an overview of ongoing initiatives, grouped into relevant swim lanes. If there is delay or a shortage of resources this is noted. We keep a stable of other candidate initiatives so if one thing is delayed, we can green light another.
3) New projects-- before being admitted to the swim lanes, the new projects need to have a clear business case, budget, and resource assessment. They also need to have a designated owner and sign off from the other resource holders as part of the business case.
I would be very wary of process software until you have a decent process. You need a culture of working in this way before it can be helpful. I've been somewhere between tech and retail for the last 20+ years and I've never seen process software fix a culture issue. I have seen a lot of attempts at it, however.
posted by frumiousb at 7:56 PM on May 25, 2020
1) Introduction: This may sound deeply goofy, but it works and in a multicultural organisation, it has been essential to get people listening. We spend anywhere between 20-45 minutes getting to know each other. I facilitate. Often we use a game called "Teamwork" questions. Last week I had people interview each other with some set questions. This week we're doing some storytelling. This builds a culture of communication and starts the meeting with everyone listening.
2) Status: Programme leader presents an overview of ongoing initiatives, grouped into relevant swim lanes. If there is delay or a shortage of resources this is noted. We keep a stable of other candidate initiatives so if one thing is delayed, we can green light another.
3) New projects-- before being admitted to the swim lanes, the new projects need to have a clear business case, budget, and resource assessment. They also need to have a designated owner and sign off from the other resource holders as part of the business case.
I would be very wary of process software until you have a decent process. You need a culture of working in this way before it can be helpful. I've been somewhere between tech and retail for the last 20+ years and I've never seen process software fix a culture issue. I have seen a lot of attempts at it, however.
posted by frumiousb at 7:56 PM on May 25, 2020
if a ticketing system seems too complicated, i suggest trello (there are alternatives) style kanban boards. they are simple to use and understand..
posted by lescour at 8:01 PM on May 25, 2020
posted by lescour at 8:01 PM on May 25, 2020
Beyond a general lack of 'accountability culture' (that's for a different question), the organization doesn't have codified processes/protocols/norms/ or tools to ensure that all along the production chain are alerted to changes in status/delays etc.
That's not a different question; that's your root cause issue. You can't have an accountability culture without a way to keep track of who should be held to account for what.
Once an organization grows past "everybody is in the same room", you need an issue tracker, a change management process, documentation and ownership, and the understanding that this is necessary (and the cultural modelling required for it to take root) has to come from the top. I'm happy to talk about this at some length if you memail me, but this is a very common growing-team cultural issue.
posted by mhoye at 8:06 PM on May 25, 2020
That's not a different question; that's your root cause issue. You can't have an accountability culture without a way to keep track of who should be held to account for what.
Once an organization grows past "everybody is in the same room", you need an issue tracker, a change management process, documentation and ownership, and the understanding that this is necessary (and the cultural modelling required for it to take root) has to come from the top. I'm happy to talk about this at some length if you memail me, but this is a very common growing-team cultural issue.
posted by mhoye at 8:06 PM on May 25, 2020
The core principles of Agile are pretty solid. You can absolutely get a lot of benefit without adopting a whole overbearing, overprescriptive framework. To me 'Agile' boils down to 'agile' (lowercase a) -- "we iterate on an X weekly basis, with planning and retrospectives bookending each iteration, and some form of daily status communication". You want to do this not this. Kanban is a great, lightweight way to start.
Retrospectives seem kind of corny at first, but to me are the biggest benefit of adopting an 'agile' (still lowercase a) process. They give you a venue to make sure your process is serving you, and not vice versa.
It's about cadence and visibility/communication, and that's it. The rest is enterprise consultant bullshit IMO. I'm a bit hesitant to recommend any specific tools -- it's okay to use what works for you, or what you might already have. Just make sure you have some sort of tool to track issues (jira, trello, github issues, etc.), and that's a good start you can iterate on to find a process that works for your team.
posted by so fucking future at 7:14 AM on May 26, 2020
Retrospectives seem kind of corny at first, but to me are the biggest benefit of adopting an 'agile' (still lowercase a) process. They give you a venue to make sure your process is serving you, and not vice versa.
It's about cadence and visibility/communication, and that's it. The rest is enterprise consultant bullshit IMO. I'm a bit hesitant to recommend any specific tools -- it's okay to use what works for you, or what you might already have. Just make sure you have some sort of tool to track issues (jira, trello, github issues, etc.), and that's a good start you can iterate on to find a process that works for your team.
posted by so fucking future at 7:14 AM on May 26, 2020
I would distill down the core of agile1 to three main practices:
1. Direct involvement of customers/stakeholders in planning, down to very finest level of detail.
2. Frequent, small releases (e.g. daily/weekly, not monthly/quarterly/yearly) with immediate feedback.
3. Retrospectives and continuous process improvement.
These pieces fit together and amplify each other, and together help you build a delivery machine. You're constantly delivering small increments of value, so the practice makes you better at delivery. The direct feedback from customers means you're always focused on value. And regular retrospectives make sure you learn what works and formalize that into the next cycle. There's no specific set of practices that works everywhere2 (e.g. I've seen SCRUM work brilliantly, and also fail miserably); the best process is to... iterate on process and figure out what works.
My experience is that organizations that can commit to these practices -- really commit, not just pay them lip service -- will eventually figure out which specific practices work for them, and build that delivery machine.
---
1 I'm deliberately using small-"a"-agile here, to differentiate it the formalized big-"A"-Agile practices, which are significantly more rigid and, dare I say, kinda cult-y.
2 That said: I do think it would be a good idea for you to investigate Kanban as a starting point. Many of the things you say you struggle with -- planning, delays, interrupts, multiple projects in flight -- are things that Kanban is designed to help with. Specifically, the concept of Work-In-Progress (WIP) limits is a powerful one. I've seen it be transformative on teams that sound similar to yours.
posted by jacobian at 7:19 AM on May 26, 2020
1. Direct involvement of customers/stakeholders in planning, down to very finest level of detail.
2. Frequent, small releases (e.g. daily/weekly, not monthly/quarterly/yearly) with immediate feedback.
3. Retrospectives and continuous process improvement.
These pieces fit together and amplify each other, and together help you build a delivery machine. You're constantly delivering small increments of value, so the practice makes you better at delivery. The direct feedback from customers means you're always focused on value. And regular retrospectives make sure you learn what works and formalize that into the next cycle. There's no specific set of practices that works everywhere2 (e.g. I've seen SCRUM work brilliantly, and also fail miserably); the best process is to... iterate on process and figure out what works.
My experience is that organizations that can commit to these practices -- really commit, not just pay them lip service -- will eventually figure out which specific practices work for them, and build that delivery machine.
---
1 I'm deliberately using small-"a"-agile here, to differentiate it the formalized big-"A"-Agile practices, which are significantly more rigid and, dare I say, kinda cult-y.
2 That said: I do think it would be a good idea for you to investigate Kanban as a starting point. Many of the things you say you struggle with -- planning, delays, interrupts, multiple projects in flight -- are things that Kanban is designed to help with. Specifically, the concept of Work-In-Progress (WIP) limits is a powerful one. I've seen it be transformative on teams that sound similar to yours.
posted by jacobian at 7:19 AM on May 26, 2020
Vanilla agile (2 week cycles, daily stand ups, backlogs of work etc) can be a bit of a culture shock for people coming from structured waterfall style processes, never mind the unstructured organisation you describe.
You might want to look at Shapeup, the methodology that Basecamp uses. It’s ‘chill agile’ essentially - regular cycles but longer, emphasis on written communication and asynchronous reporting. It’s also designed to work with their own software, which sounds like it might be a good, low impact tool for your organisation to use. I’ve been a Basecamp user on and off for a decade and it is very, very easy to pick up and very adaptable to a range of working styles.
posted by Happy Dave at 1:17 PM on May 26, 2020
You might want to look at Shapeup, the methodology that Basecamp uses. It’s ‘chill agile’ essentially - regular cycles but longer, emphasis on written communication and asynchronous reporting. It’s also designed to work with their own software, which sounds like it might be a good, low impact tool for your organisation to use. I’ve been a Basecamp user on and off for a decade and it is very, very easy to pick up and very adaptable to a range of working styles.
posted by Happy Dave at 1:17 PM on May 26, 2020
Nth-ing the other responses for regular small-steps-forwards, early delivery, continual improvement, habitual cadence and transparent communication.
Continuous improvement and the psychological safety to own a f__kup and learn from it are hard. I think it's important to emphasise that it's even harder to build rapport and sustain good relationships now that they're not face-to-face. Western civilisation under-pays for emotional labour, but it's where we've got to go to glue together disparate people.
You may have to be the conduit for this information about the state of the system, until you need to stop saying the same status updates to 15 different people per day and can bring them into a daily status blast -- it's not a long call -- where each person shares yesterday-achieved/today-will-attempt/current-blockers, that takes a maximum of 15 minutes. (What other people do with that information is up to them, and you hope they'd get on with removing blockers.)
The 'unanticipated delays' need some record of what they were and some measures taken to eliminate or minimise delays -- though let's acknowledge there's always some stuff you can change, some stuff you can put up with and the rest is gravity that you have to endure. Getting people to under-promise and over-deliver also buys time for this information-overhead stuff such as tracking where the unanticipated delays come from, or what time to give up to prepare for and contribute to those things like the daily status blast and a regular review-and-improve session.
posted by k3ninho at 10:46 AM on May 27, 2020
Continuous improvement and the psychological safety to own a f__kup and learn from it are hard. I think it's important to emphasise that it's even harder to build rapport and sustain good relationships now that they're not face-to-face. Western civilisation under-pays for emotional labour, but it's where we've got to go to glue together disparate people.
You may have to be the conduit for this information about the state of the system, until you need to stop saying the same status updates to 15 different people per day and can bring them into a daily status blast -- it's not a long call -- where each person shares yesterday-achieved/today-will-attempt/current-blockers, that takes a maximum of 15 minutes. (What other people do with that information is up to them, and you hope they'd get on with removing blockers.)
The 'unanticipated delays' need some record of what they were and some measures taken to eliminate or minimise delays -- though let's acknowledge there's always some stuff you can change, some stuff you can put up with and the rest is gravity that you have to endure. Getting people to under-promise and over-deliver also buys time for this information-overhead stuff such as tracking where the unanticipated delays come from, or what time to give up to prepare for and contribute to those things like the daily status blast and a regular review-and-improve session.
posted by k3ninho at 10:46 AM on May 27, 2020
This thread is closed to new comments.
posted by bleep at 7:11 PM on May 25, 2020