15

I am working as project manager on a large project with a five person development team. They have been without project management support for several months and there is no project management methodology in place (though build processes - CI etc. - are quite mature). Agile is attractive to them but they have little or no experience with it.

What tools and techniques would you introduce to get a team started on agile without overwhelming them (and me!). In your experience is it more effective to introduce everything at once or is a phased approach more effective?

I have limited experience of Scrum and Kanban from previous roles but not at introducing them for the first time.

Improve this question
2
  • 1
    Could you indicate whether you think Kanban or Scrum would fit better for your team? This will greatly effect where to start.
    – Andrew Clear
    Aug 31, 2012 at 14:00
  • I think Scrum is probably more suitable since there is a big backlog of work that I'd like to see split out into more manageable blocks. I also think it's more likely to keep senior management happy because they could see regular demos.
    – Willl
    Aug 31, 2012 at 14:06

3 Answers 3

Reset to default
10

Scrum is probably the more difficult of the two to implement from scratch. Here's what I would suggest:

First Phase: Preparation

1) Spend some time grooming and prioritizing your backlog. The key here is to break the backlog items into small enough pieces. Most new Scrum teams fail early because they are unable to deliver software at the end of a sprint, and that is usually because their backlog items (user stories) are too large.

2) Have your team read up on the Scrum process, and go over with them the plan of implementation. Get their feedback, and feel for where you are getting pushback. Talk to them about TDD/BDD.

Second Phase: Sprint 1

3) Set up your first sprint. I usually suggest 3 weeks. If after 2 sprints, your team is having difficulty delivering working software, shorten your sprint length to 2 weeks. This will force you to break your backlog items into smaller pieces. Increasing sprint length is usually a black hole that you'll never get out of.

4) Implement all the required meetings, including the daily standup.

Third Phase: Automation

5) If you don't already have them, now is the time to set up your CI builds, and work on your developer's daily workflow. Encourage them to use the get latest > build > code > build > get latest > build > check in flow.

6) If your project doesn't already have extensive automated tests, now is the time to really start encouraging their creation. Your sprints will be more productive, and your working code will be more "working" if you can achieve good code coverage for your CI builds. Consider a check in policy that requires an increase in code coverage for a successful check in. This can be abandoned later on, once everyone is used to writing unit tests for their new code.

If you get this far and you haven't had a revolution on your hands, you can now start talking about setting up automated deployments, pushing TDD/BDD, implementing a code review policy, and formalizing an input/feedback process with your product owner that is more continuous. The last part can be quite difficult. Most teams end up with what we call Water-Scrum-Fall where the product owners act in more of a waterfall manner and only want to be involved at the beginning and ending points. The further into the organization you can push the agility, the more benefits you will see.

As for technologies I recommend TFS 2012. I've written a fairly decent overview of it's power on stackoverflow here. To recap, it combines pretty much everything you will need from both the PM side and the developer side under one umbrella.

On a final note: it is possible to do this in almost the exact reverse order, except for grooming your backlog (that should almost always come first). You could choose to concentrate on developing your team member's daily habits before implementing the structure of Scrum. Get them increasing your code coverage with automated tests, introduce a CI build, and (hopefully) set up automated deployments first, then create the sprint structure around that. Talk to your team, and see which they would prefer. Scrum is all about continuous value delivery achieved through automation and continuous communication. Get your team's input throughout, but if you get some pushback you may need to enforce some structure. Hopefully after a few sprints, they will see the benefits.

Edit

After some discussion with my colleagues, I believe I left out something important. I mentioned TDD/BDD, but I failed to emphasize the importance of integrating testing into your sprints. You need to include enough testing (unit, integration, acceptance) inside your sprints to ensure that your "working" software is actually working and fulfilling the product owner's needs. I've found that one of the most effective ways to achieve this is through multi-dimensional teams. Put a tester or two on your teams. Paired programming with a tester and a dev can be incredibly successful if they can work in a collaborative arrangement.

Improve this answer
2
  • This is really helpful thanks. The team are pretty good at the CI side of things (I'll add to the question), it's really the prioritisation, regular releases/demos and communication side of things that I'm keen to improve.
    – Willl
    Aug 31, 2012 at 15:25
  • If you go the TFS route, Feedback Manager is a great tool for involving your product owners more proactively.
    – Andrew Clear
    Aug 31, 2012 at 16:06
3

Before you look at Scrum/Kanban keep one thing in mind: It's a partnership with the business. if you don't have a member of the business who can prioritise (this can be a person, a group, a committee, etc) then it's not going to work.

When I first introduced Scrum I had to work really hard to convince the business to participate. They were deeply suspicious of Scrum and didn't initially see the benefit of the time they'd have to put into the process.

So, forget about unit test automation and the technical elements of this. Here are some questions you and the dev team need to ask yourselves:

  1. By going down the Scrum route you are handing prioritisation over to your Product Owner. Usually, for Scrum to be successful this needs to be someone in the business. Are you happy to do this?
  2. You will have to prepare and manage the backlog. This means getting the team to provide extimations for work that you will be held to by your Product Owner. Are the team willing to spend a reasonable time estimating and are they willing to be held to their estimations?
  3. The team will have much more contact with the business through Prioritisation, and demos with the business. Some people like this and some don't. With they?
  4. Scrum is incredibly transparent. We used to send our Product Owner our burndown chart every day, so if we were behind it was obvious by day 4. Forget about hiding things under the carpet - if you've got issues you'll need to be honest with the business sooner rather than later to retain credibility. Are you willing to share your daily status reports?
  5. Once you do actually deliver the business will have a quick honey-moon (they'll sing your praises) but they'll soon get used to constant delivery. Are you happy to do this?

Never mind the technical stuff. Is the business and the team ready for Scrum? Don't just "declare" you're doing it, talk what you want to do through with the business. Talk it through with your team and make sure they understand what they're getting into.

And then send someone on a ScrumMaster course.

Improve this answer
2

I don't recommend to introduce Agile or Lean, because one of them is attractive to your developers.

They love to try out new things by nature, and it is completely fine, but you as a project manager are responsible for the project and if you don't have any process, you should analyse the demand instead of checking out processes.

Find out what your customers want, what are the key moments in the life of the projects and know the vision. Usually, when there is no process, means there is no vision.

Let's say you introduce Scrum, but your customers don't want to participate in demos, and don't want periodic deliveries. You spent a lot of time and their money on a process which doesn't fit. Demand comes first, and then the supply.

Here is a possible list for you:

  1. customer demand
  2. vision
  3. process idea which fits into the vision and demand
  4. internal process pilot
  5. idea validation with the customer (if doesn't fit, go to step 1)
  6. process education
  7. work
Improve this answer
5
  • Customers don't have to participate in product demo's, only the product owners. You can use Scrum even if your customers want waterfall (which they don't, they just don't know they don't and you should be helping them to see the benefits, both monetarily and quality of product wise of going away from waterfall). You just need a product owner who understands fully what the product the customer wants is. You demo to that person, not the customer.
    – Andrew Clear
    Sep 2, 2012 at 17:11
  • I disagree. If you want to make sure that the right features are delivered, you have to demo to the customer.
    – Zsolt
    Sep 2, 2012 at 22:25
  • I agree totally. But sometimes customers don't understand that. You should be trying to convince them, but you also need to be working. This is why you can do scrum without the customer's support.
    – Andrew Clear
    Sep 3, 2012 at 18:41
  • It is a very interesting situation. For me Scrum is around the customer, and if he or she doesn't cooperates Scrum loses one of its key motivators and the transparency. I've seen several stealth Scrum projects, and I'm kind of fine with them. My point is to find the right framework that works well with the customer. I'm more than happy if you managed to do Scrum even if the customer wasn't interested. All of our approaches failed so far :-(
    – Zsolt
    Sep 5, 2012 at 8:41
  • I agree that finding a framework that works well with your customer is important, to a point. If the customer is insistent on a waterfall approach where they don't want any interaction until the project is completed (and you need to continue to work with this customer), "stealth Scrum" (I like that term) is a decent option.
    – Andrew Clear
    Sep 5, 2012 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.