Scrum in a Non-Development Environment
Scrum/Agile newbie here. Forgive me if this is long winded.
I am trying to determine the best way to incorporate an agile methodology into a non-development environment and after months of research have finally decided to post to this forum. A little background info -
I am partners in a small marketing agency. We are essentially consultants, however we are also tasked with executing on many of the reco's that we make. The team is comprised of 4 people -
1. Managing Partner - primarily in Sales
2. Account Manager - manages all of the client/agency interaction, primary point of contact.
3. Operations Manager - that'e me. Tasked with making sure all of the deliverables are met.
4. Client Service - works under Ops Mgr, does a bulk of the grunt work, coding html, data analysis etc. Most of the work toward deliverables is split about 50/50 between the Ops Mgr and Client Svc.
Typically we have 8-10 open projects/clients at a time, and each have weekly deliverables. I currently use SmartSheet to manage the tasks and deliverables and have a sheet that functions as essentially a digital Scrum Board.
My issue- My two other partners read Sutherland's book and insist that we incorporate Scrum into our processes. I would be the SM, and the Account Mgr the PO. I don't know that Scrum is the best method given our environment and am looking for advice from the experts here. My questions -
1. Can you balance 8-10 projects within a single Sprint structure where there are deliverables due on specific days within that Sprint?
2. We have weekly update meetings with our clients, which inevitably introduces additional tasks that were not originally set out in the Sprint yet they are due within that time frame. How do you manage that type of scope creep? Should there be a chunk of time allocated every Sprint for creep?
3. Obviously we have very limited resource bandwidth. Our daily scrums can take up an hour a day of resource time (3 ppl x 20 mins). That's 20 non-billable hours/month.
3a. We all sit in the same room and within feet of eachother. Is there a need to really stand up every day to meet? We already communicate across the room and what we are working on is visible.
5. The managing partner also wants to be able to project resource allocation out 3-4 months in order to determine when we can take on new projects/clients, which from what I understand is not a scrum tenet and is more traditional PM. We do not have the resources to have me operate as the SM and also the PM. Is there a tool out there that incorporates both?
I realize that this is a lot, but honestly it is the tip of the iceberg for me. Any help would be greatly appreciated.
Hi Tom,
sounds like a very challenging transition.
Scrum is a framework for developing products, so my first step would be to define what the product is in your case.
If this doesn't seem meaningful, maybe you don't develop a product here, but maintain an operational process.
In this case you might want to think about alternatives like Kanban, where you have a continuous flow of value instead of an incremental development.
Thanks Ludwig -
True - we do not develop 'products' per se. Each project has different goals and deliverables. Often times they are similar in nature, but due to the differentiation between our clients industries/business models/etc, the end result ends up looking different. I would liken it to building custom cars - they all have four wheels and an engine, but they can look and perform very differently.
I was leaning more toward something like Kanban or some type of Scrum-Ban hybrid, but wanted to make sure that I wasn't just missing something. From my perspective, I don't see a clear delineation between the two frameworks. To be honest, they look very similar to me, and there are a lot more resources and forums to research re: Scrum than there are for other agile methods like Kanban. So that is why we kept coming back to Scrum. I think Scrum is the easier of the two for people to grasp (and pronounce :- ) ) so that is why the other stakeholders here are pushing it.
Thank you for responding.
tt
Hi Tom,
How to know if Scrum is applicable.
The first thing you must clarify is the role of each one in the scrum team. Scrum says that you need:
- A Product Owner,
- A Scrum Master and
- A development team.
The product owner and the scrum master don't count as part of the development team, unless they work as part of the development team. Which is dangerous in early adopting companies.
Once you have each role clear, check that with the size of the development team you will be able to afford all the increments of work you will face each iteration. I suggest you to read the section 'Development Team size' of Scrum Guide (page 6).
After this I'm going to comment some of your points:
1.- An scrum team works on a single backlog prioritized and managed by the Product Owner. If you can create a single backlog with tasks of the 8-10 projects at the same time (avoiding project starvation), then the amount of projects are not a problem. For the scrum team they'll be like a single one.
2.- From the point of view of scrum, stakeholders and scrum team are not allowed to change Sprint backlog (the tasks arranged for the current sprint). An sprint can be cancelled only if the user stories in the sprint backlog lose their value. But you're talking about modifying it that, of course, is not a good idea because the sprint goal is always being moved. This has a high impact in one characteristic of the empirical process (scrum is based on): adaptation. You can't improve your way of working if you have problem for measuring how the sprint was.
Stakeholders can introduce tasks in the Project Backlog through the product owner. That's absolutely allowed and recommended. The product backlog must be always growing with new User Stories. The product owner must order them (most valuable on the top, less valuable in the bottom).
Sprints of one week are ill-advised. The amount of events (daily scrums, review, retro...) will take a lot of time and the team will be in problems to solve user stories. Try to perform at least Sprints of 2 weeks.
3.- Daily scrums are time-boxed events of no more than 15 minutes. Each member of the team must summarize basically answering three questions:
- What I did yesterday?
- What I'm doing today?
- Is something blocking me?
After daily scrum meeting, members that need to discuss or comment things in other meetings. But only the part of the scrum team involved. This way you avoid people wasting time hearing problems that are not part of their business.
4.- (3a) Yes, this is needed. Problems and questions outcrop when people answers the basic three questions. Maybe some non important comment of someone can be important for another person in the scrum team.
5.- After some sprints you can start with estimations about the future. The more time the scrum team work together, the more mature it becomes and more accurate are that estimations. There are several free tools for project managing (like redmine) and also for scrum board (Trello). Feel free to find the ones that fit you better.
Regards,
Fulgencio.
Hi Fugencio,
This is regarding answers given by you. I would like to disagee with you on the following point.
" From the point of view of scrum, stakeholders and scrum team are not allowed to change Sprint backlog (the tasks arranged for the current sprint)."
I agree that stakeholders(external) are not allowed to change Sprint Backlog. But development team of scrum team owns sprint backlog and can change it any time as long as it will not affect the sprint goal. Why do they change it.
As per sprint guide, Sprint backlog is nothing but user stories selected for the sprint and plan for delivering them. Before start of the sprint this plan may consists of tasks at very high level. As Development works thru sprint, they may add / delete tasks which the seem appropriate to achieve sprint goal.
Stakeholders cannot add userstories in the middle of sprint. If they want , they can inform product owner , who will put it into product backlog and prioritize it.
" An sprint can be cancelled only if the user stories in the sprint backlog lose their value. But you're talking about modifying it that, of course, is not a good idea because the sprint goal is always being moved."
I dont agree with your statement that sprint goal is always being moved. Sprint goal for a given sprint is crafted by Sprint Team after sprint backlog is forecasted by them, It provides guidance to development team on why they are building the increment. Sprint Goal will not change for a given sprint. Yes if the Development team achieves sprint goal before expiry of sprint timebox(could be 1 month) then Development is encouraged to take more userstories to work on (in the current sprint itself) as per the order done by Product owner.
This has a high impact in one characteristic of the empirical process (scrum is based on): adaptation. You can't improve your way of working if you have problem for measuring how the sprint was.
Stakeholders can introduce tasks in the Project Backlog through the product owner. That's absolutely allowed and recommended.
There is a difference between requirements, userstories and tasks. Requirements are at higher level provided by Stakeholders, Product owner converts them into backlog items(or user stories) and Development team breaks them into tasks. So stakeholders can only provide requirements but Product owner adds Detail, Order(prioritize), Value and with collaboration from Development team adds estimate.
Hi Rajasekhar,
Thank you very much for your reply. I agree with the comments you posted. I've mixed tasks with US and requirements. It's a good idea to clarify it.
Thanks ;)
Fulgencio.