Would Scrum & Kanban work for a small organisation with several "projects"

Question

Background

My question deals with introducing Scrum and/or Kanban in a small organisation (currently 9 employees), but with several more or less distinguished areas of focus, some including only one person. Mainly my concern is with how to keep everyone in the organisation involved in where we are heading as an organisation, but finding a better method than less-than-productive weekly meetings, like we have now.

We are a community TV channel, with our main sources of income being either paid video/TV productions or projects with grants for a limited time (usually 1-3 years), plus some "general income" such as membership fees and sponsoring. The projects are in that sense partly separate (as they have their own aim, purpose & budget, stated in the project application), but still an integral part of the organisation.

Current organisation

Our current organisation looks like this (some staff are involved in several projects/teams):

• 1. Executive Director (100%)
• 2. Director of Operations (100%)
  • 9. Marketing (25%, not technically a paid staff role, but at the moment rather an extra responsibility of one of the project leaders below)
  • 3. Financial administrator (20%, accounting, human resources)
  • 4. Programming manager, incl. IT & administration (100%)
  • Production Team (also includes others when there is demand)
    • 5. Producer (50-60%)
    • 6. Technical manager (50%)
  • Projects
    • Project 1
      • 7. Project leader (100%, but up to 25% also with general productions)
      • 8. Developer (50%, server management, programming, web - including about 10-15% with development of the organisation's website)
      • 5. Producer (40-50%)
      • 3. Financial administrator (15%)
    • Project 2
      • 9. Project leader (75%)
      • 5. Producer (about 10%)
      • 3. Financial administrator (15%)

To complicate further, The Director of Operations, Technical Manager & the Project Leader for Project 1 are all available for productions when demand arises. Even the Executive Director at times. And the developer, employed at 50%, is using 25% of his time for the general website.

100% means 40 hours per week. Thus, the Project Leader for Project 1 is working 30-40 hours per week with Project 1, since he's also available for productions that require more people, etc.

Going forward

My idea is that the Director of Operations (me) will also be the Scrum Master both for the Production Team & Project 1. Project 2 is on its last year and consists mainly of the project leader. For Project 1 Scrum would fit well, particularly for the developer parts, but Kanban would be more fitting for the Production Team, as well as the production parts of Project 1.

But how then to keep the financial administrator & the programming manager in the loop? The financial administrator will not really benefit from participating in daily scrums & the programming manager is kind of independent, although partly connected to the Production Team. And the producer is divided between the Production Team & the two projects.

One reason I've been looking into agile project management is to assist the project leader in Project 1, as his experience in planning & leading projects is very limited.

Conclusion

Sorry for a long post. But do you think some combination of Scrum and Kanban would work for an organisation like this? Some of us have started to use Trello for this.

And how to keep everyone in the organisation in the loop with what's happening in the other teams and for the organisation as a whole? We have started using Slack for team communication, but since we're all physically in the same facility, some sort of physical meetings with the entire staff would also be good.

Answer 1

In such small teams and intersecting boundaries scrum won't do any good. It would be an overhead instead of help.

I would recommend using only loose process with direct overwatch. For instance - take kanban for project task management. Take scrumban "planning on demand" for project planning.

As the member of financial side is always the same one he can be separated and involved only in weekly or monthly meetings, if no, then you need to provide more details about his daily duties. Project 1 and Project 2 teams should do their own cycles with daily standups and planning on demand meetings. Also it would be good for top level management to have kaizen or restrospective events once a month with teams, to hear about the problems and talk about solutions.

As you are physically located in one office you do not need any communication tool except task board, maybe start with a physical one, a thing that can be put on a wall and seen by everybody. A wall of transparency in your company. A wall to remind everybody what is going on and what are the responsibilities.

Finally, you should start with task board, meeting routines and later iterate to estimating and measuring performance. As basically there is only one way to evaluate if methodologies are helping - try to measure performance and see how it is improving or failing.

P.S. Work on some company culture which could teach everyone that process based work is less stressful and beneficial than chaotic environment. And of course this is the quality assurance included.

Answer 2

TL; DR

[D]o you think some combination of Scrum and Kanban would work for an organisation like this?

Possibly, but not the way you're thinking of implementing it.

[H]ow to keep everyone in the organisation in the loop with what's happening in the other teams and for the organisation as a whole?

Have a communications plan, or leverage your framework ceremonies such as Sprint Reviews. Don't bog people down in details they don't need or want.

Rethink Your Problem

One of the key principles of agile development is that most team ceremonies only include those with "skin in the game." Stakeholders are not allowed to actively participate in daily stand-ups, and teams are kept to the smallest cross-functional unit that can do the job.

So, whatever you're trying to do isn't Scrum or Kanban. What you seem to be missing is:

1. An effective communications plan for radiating project information to stakeholders.
2. A designated person (perhaps the "project leader") to manage information artifacts and execute the communications plan.
3. An acceptance that as a company grows, there may be people who you think should care about related or unrelated projects, but who very possibly have zero interest. Such people shouldn't be force-fed extraneous information unless you're prepared to have the feeding process slow down your entire organization.

To sum it all up: trim the fat. Your project participation should be lean, but with very tight feedback loops from actual customers or from a Product Owner that represents them. Everything else probably belongs in a "management silver bullet" book, of which you have an infinite number to choose from.

Answer 3

When I can't use Scrum, I use Kanban.

If you think you can deliver the functional product every two or four weeks, go for Scrum!

Otherwise, Kanban provides a great tool for visualization of tasks. Visual board should let everyone in your small organization see who is doing what and should help to detect the bottlenecks to improve the processes.

Keep in mind that your board will have high value if it will be relevant all the time. Maybe letting people to move tasks by themselves and letting everyone know (Trello service does that in the Activity panel).

Estimation of tasks may be sometimes skipped as well.

You should agree on the frequency of your stand-ups. If the communication is very good, every day meetings may become not necessary. Discussions of every project in separate Skype groups or/and email can serve better than standups. Weekly meetings can be very useful as they can be taken more seriously, can be better organized, and can produce a better tool for the incremental improvement in your organization.