Our TBMO is an agile team, but we do not do development work. I like this type of team, but others are unsure how they feel.
Our company is currently in the process of implementing Agile Dev Ops across multiple divisions and our TBMO is certainly a team that has embraced this action. For our TBM journey we have been running Sprints for a number of years and the Sprints include both Development and Non Development Epic Streams. As a team we have found that this has enabled us to work collaboratively across all areas. Our Dev team can see how we are utilising the data feeds they are providing us with and are very pro-active in offering solutions if they see a need for additional data which would improve our analysis. I think the nature of TBM means that any TBMO has to be Agile - its a perfect synergy from what we have experienced.
There are several examples of non-development teams adopting agile principles. The Harvard Business Review (HBR) has had several articles on agile this year including "Agile at Scale" and "HR Goes Agile". It's really about adopting the agile principles and the lean-agile mindset. Whether you organize your work to adopt scrum with sprints or Kanban to create continuous flow, it's about delivering that continuous value stream to the business and your stakeholders.
I think if your goals/deliverables are S.M.A.R.T and "segment-able" then it is fine. I worked in both Dev and Non-Dev Ops using Agile. The problem comes when you try to deliver a Sprint 1 or 2 proto-version of a solution or optimization but then find yourself having to explain why the solution at that point is not perfect. We know it is not suppose to be. It is suppose to solve for a core defect and then be improved iteration by iteration. The "suits" love Agile Non Dev in theory, but get squeamish in practice, especial if there is no clear ROI (time reduction or "person" hour savings and resource re-allocation does not entirely cut it)!
Angela Saldana Jeremie McGaw Laura Jenkins Jamie Baek
I like the idea of running a TBMO as an agile team. Keep in mind that Agile is not just Scrum and so other agile methodologies may be applicable depending on how you work. But for agile in general, as an example, you can create your use cases/outcomes as Epics and then build out your stories describing your work units to achieve that Epic. Achieving small incremental successes as you build toward fulfillment of the outcome is a very doable approach in TBM. If you feel like you cannot use a Scrum approach (very strict timeboxed work) take a look at a Kanban approach. Still agile and supported by almost all agile tools. The work is broken up in a similar manner, but gives a more 'flow' type of approach to getting the work done. You can even research a hybrid 'Scrumban' type of approach as well that uses ideas from both to get you somewhere toward the middle of the two. There are lesser known methodologies, such as Feature Driven Development, or homebrew approaches that may fit your resource availability, structure, and timelines as well.
Good luck and let us know how this is going.
I prefer Agile for TBM... and honestly, even for personal projects outside of the office. It's just a better way of getting things done! Belinda Wallace
Retrieving data ...