Hiring new team with limited resources using Scrum

Question

My team consists of 4 people

1. Myself (Division Director, Senior Developer and Project Manager (adhoc PM))
2. Emp1 (Data Administrator/Data Entry for entire agency)
3. Emp2 (Junior Developer - Have not hired yet)
4. Emp3 (Assistant Salesforce Administrator / Assistant Developer - Have not hired yet)

Overview:

The agency I work for consists of 7 divisions. My division (Data Services) is responsible for Data Collection, Data Entry, new Development, and maintaining existing web applications (total of 5 sites including Salesforce for 70 users). I'm currently the only one developing, maintaining, and administrating all sites including Salesforce. I'm also the one responsible for all of my staff and can put together any kind of team that I need, but with only the resources for hiring 3 employees.

Why I want to use Scrum:

I want to put together a Scrum team because our projects change often, and randomly due to politics. So, with traditional management I found that I was starting over and wasting a lot of time re-writing requirements only to have them change in the middle of development.

My Issue:

With the resources listed above, can I successfully pull off a Scrum team? The reason I'm concerned is because I'm the one juggling the Scrum Master role, as well as Salesforce development, .NET development, and managing my staff. Granted I will have a Junior Developer and Assistant Salesforce Admin, that will take some time to get them up to speed.

So to sum it up, is this possible without jeopardizing conceptual control? What I mean by this is; with the types of resources and non-dedicated Scrum Master (since I also have a few others roles) am I high risk for failure approaching using Scrum?

Answer 1

In your situation, I would highly recommend hiring developers who have already worked in a scrum environment before so they don't need as much coaching from you. They don't have to be CSMs or anything, but they should understand the framework and have worked with a team that has used it before. The less hand-holding you have to do with them on the process, the better. For interviewing, I'd just ask them to tell you about some of the pros and cons of scrum or agile development that they've witnessed. You should be able to tell within a minute or two if they have the experience and also get an idea of how well they'll work with the system.

Also, be careful not to let scrum restrict you either. With a small team, you may find that some of scrum is overkill for your team. As an example, you may see specific durations listed for timeboxing your meetings. While a 12 man team might very well take 4 hours of planning for a 2 week sprint, you may find that your 4 man team can plan out 2 weeks in an hour. Always remember to do what makes sense for your team/project and use your retrospectives to facilitate this.

Your team size/make-up is fine. I've personally used scrum on projects before where I was the only team member. I've also worked on projects where I was a team member, scrum master and product owner. It's not ideal by any means, but sometimes real world constraints give you no other choice. It can work though. One important thing is to always make sure the team knows what role you're speaking as at any given time. You have to assure them that when you're working as a team member, your status as their boss doesn't come into play. You'll have a hard time achieving a self-managing team if you don't because they'll always be looking to you as their boss to give them marching orders and that'll just take up more of your already limited time.

Answer 2

A Scrum Team success depends greatly on the Product Owner and her work. If she is unable to put together a good and usable product backlog, it doesn't matter how good the Scrum Team is, it is going to fail. If you don't have a Product Owner yet, get one. Keep in mind that the Product Owner is not a Scrum Team member, and cannot be one, because she needs to keep the backlog updated and valid, which doesn't really allow time to spend with development.

The next key figure is the Scrum Master. Your team is quite small, and there is a good chance that you can make progress with a dedicated Scrum Master, but it is important to save some time to learn about Scrum and have frequent discussions inside this team on how to do Scrum properly. It must be a research + presentation + conversation like discussion.

I read that the project changes often. How often? Because if it is changing on a weekly basis, you may problems with Scrum. A traditional two week long iteration may be too long in this case. Anyway, Scrum is a good start - if you have the dedicated Product Owner and backlog - , but I would keep my on the resent events on the continuous deployment movement.