All About Agile | Agile Development Made Easy!
Where to Start
Hi all, I face daunting the first steps, ones I’m sure you are all familiar, I want to implement an Agile, principally SCRUM approach for my company.
I’m the Development Manager for a medium sized software provider (50 or so employees), together with two other department heads, our Implementation Manger who encompassing test and Support Manager who picks up the pieces, we have long suffered and tried several method to manage our products, always falling back to almost daily releases, poor test, poor specifications and commercially driven goals.
Obviously its not uncommon and a tough run, but after discovering Agile and Scrum I saw the light! I have read up, ran day to day scenarios past the other dept. heads and explained the benefits to the directors, we are all sold. Now I want to take up the challenge of making it happen and it’s all on me to educate and implement SCRUM for our business. I can come up with a plan based upon articles and techniques i have read, but its seems there are no set rules, I would really prefer to hear it from someone who has been successful in this same starting step.
I don’t need a full working solution and don’t expect it to work straight off, but would love some sage advice in getting the ball rolling. e.g. Did you start with just one iteration planned out? How did you structure your teams? What worked in terms of starting and stopping a sprint? Re-education of customers and sales teams? etc.
Thank you,
Ryan
Views: 18
Replies to This Discussion
-
Permalink Reply by Simon Kiteley on -
As you seem to having the go ahead. Could you pick a team of enthusiastic developers et al. Choose a low priority project, leave Friday, have a nice weekend and come back Monday morning and just go for it. Be hard and mistakes will happen but work it out. Once implemented add a team at a time to the new way.
However stepping back into a world where most would find that too scary. Try finding the think that annoys people them most and can be fixed but an agile practice do that first. If people don't see that something is going to make there life easier you need to use the stick which is unlikely to work.
-
Permalink Reply by Ryan Hobson on -
Great advice Simon, Im actually working on a plan now, this could really help, I have selected a willing product owner developers and test, need to work out the next two sprints and will ensure i get some annoyances in there to keep them on side. Then i can add a product and team at a time.
Main issue im facing right now is our developers are cross product...i belive i need to add a step for myself to communicate the commercial priorities to the product owners who take it from there, but how do they know what other owners are planning on using the developers.....need a view of what each developer is signed up to i guess.
-
Permalink Reply by Les Oliver on -
I disagree with the suggestion "choose a low priority project".
If you succeed with a low priority (Agile) project nobody will care, 'cos it's low priority - and you won't get buy-in.
Your first few Agile projects should be real, high priority, high value projects - and then when you deliver the value thru the succesful project then people will care and will want to know more about "how Agile works" and you'll get buy-in.
-
Permalink Reply by Ryan Hobson on
-
Thanks guys, both sides have advantages, however my starting product choice is limited at the moment, its medium priority, but the stability at the end of a sprint is much more important than other applications so I should gain the kudos and have a less public start off. The other products have recently had a major release, due to the scale and complexity I want to wait longer for issues to calm down before attempting to run in Sprints, its possible, but would be a royal headache to start, with no kudos.
-
Permalink Reply by Simon Kiteley on
-
The same situation occurs where I work. Developers are not cross product but cross projects in the same programme. Different Project Managers are assigning different engineers to do actual work. This really puts a barrier in the way for progressing Agile.
I think the answer is the Product Owner (or anyone out side the team) is not allocated a developer or can assign work to a developer for any given project.
Instead a team exists with the appropriate skills (because the developer is in that team) to work on that Product Owners project and the Product Owner is assigned a part of that team time. The Product Owner can then have an idea for how much development support they have but the team will decide who will do the work. It may end up being the developer who would have been assigned anyway but may be some one better suited or be better handled if some one is off sick or some other problem.
Everyone should be a winner!
-
Permalink Reply by Ryan Hobson on
-
hmmm, I’m starting to think my product owners should have reduced responsibility. This role currently doesnt exist, I try and gain all requirements and sequence accordingly, at the moment I plan the following;
1) Scrum masters pull the Commercial priorities (features) from the Exec's (this already happens bi weekly)
2) Scrum master pass these priority features to the product managers who can sequence with their own product backlogs accordingly for the next sprint.
3) Sprints will start every two weeks and run Monday to Monday.
4) Monday morning will be open for anyone wishing to learn what was in a sprint.
5) Monday afternoon will be used for the teams to review the next two sprints and alert the scrum masters to potential difficulties.
6) Product managers, Developers and test will run the sprint daily between themselves (let them evolve their own ways to work together)
7) Scrum masters will hold 10 minute stand-up reviews (unsure of frequency here, very senior teams? every Wednesday, Friday.)
8) Scrum masters will alert the product owner to any new requirements that may interrupt (should be minor).
9) Scrum masters will monitor burn down charts and react accordingly with the teams.
What are your educated thoughts?
-
Permalink Reply by Simon Kiteley on
-
Educated thoughts... erm, just opinions really...
Yes Product owners could well have much reduced responsibilities as in telling the team how to do things and who will be doing things but obviously this should help them because they can more concentrate on what the system has to do, the longer term goals and smoothing the use of the new/modified software within the business as a whole or your customers business.
1) Maybe the Product Owners should be pulling the features and drive what the customer wants. This would allow the Scrum master to more concentrate on if Scrum is being followed in the team and how to meet the business requirements in the best way.
2) Are Product Owners and Project Managers the same? What is the difference?
3) Two weeks is cool. Is this long enough for you to have something to "show and tell".
4) Cool
5) Cool
6) Cool. Just make sure it is short and doesn't have anyone leaving the stand up who cannot progress.
7) Cool
8) Cool. Scrum Master and Product Owner working together is good (He states the obvious)
9) Cool.
-
Permalink Reply by Ryan Hobson on
-
Hi Simon, I took on board your last comments and have discussed internally, having your input is great btw, the sense check give me added confidence. However after discussion, im faced with changes to my plan, mostly due to resource limitation, so here goes again!
1) We have a reasonably small, but experienced team, we have approximately 10 applications working across a product suite. Product owners are by far the best guys to drive what a customer wants, but its not practice for them to pull the commercial priorities (it would mean having each owner in the bi weekly meeting that i arrange with the execs. Logistically not possible with everyone’s commitments, not ideal i know, but as most small businesses we limited resource its not practice at this stage). I will liaise with the execs (they know the apps also very well) and we will drop commercial priorities into future sprints (estimated durations will be known). I will always leave 50% free to start in each sprint for the normal product backlog.
2) I will continually liaise with the product manager and developers to fill the rest of the next two sprints.
______same 'Cool' steps as before :-) _______
3) Sprints will start every two weeks and run Monday to Monday.
4) Monday morning will be open for anyone wishing to learn what was in a sprint.
5) Monday afternoon will be used for the teams to review the next two sprints and alert the scrum masters to potential difficulties.
6) Product managers, Developers and test will run the sprint daily between themselves (let them evolve their own ways to work together)
7) Scrum masters will hold 10 minute stand-up reviews (unsure of frequency here, very senior teams? every Wednesday, Friday.)
8) Scrum masters will alert the product owner to any new requirements that may interrupt (should be minor).
9) Scrum masters will monitor burn down charts and react accordingly with the teams.
Any concerns?
Thank you again,
Ryan.
-
Permalink Reply by Simon Kiteley on
-
Much appreciated you're finding my input helpful and its giving you confident.
1) Sounds sensible and pragmatic which is important for getting acceptance. Far from being 'not ideal' I think you have come up with a very practical solution. And being Agile if its not ideal... you can change it later ;)
I have no concerns over what you have written but as I say I'm more voicing my opinions. Think its just the case to be open and communicate what you are doing, and listen to any concerns and fears from all levels (time for some good leadership skills as developers can be rather introvert, and get scared of all the working as a team stuff) and also if things don't go so smoothly try to look for the best way to sort the problem rather than allow people to slip back into old ways (seen it too many times).
Good luck.
-
Permalink Reply by Ryan Hobson on
-
As soon as I have the pre-req's in place I will begin and keep you posted, thankyou for all your advice, very much appreciated.
Ryan
-
Permalink Reply by Donna Reed on -
Hi Ryan - Scrumban or Kanban might be your answer.......There is a FREE webinar next week 6/30 that will talk about how to start your agile transformation by understanding where you are…
RESERVE YOUR SEAT at: http://www.agilistapm.com/impl-agile-with-kanban/
SPEAKER: Alan Shalloway is the founder and CEO of Net Objectives. With almost 40 years of experience, Alan is an industry thought leader. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in Lean, Kanban, Scrum, Design Patterns, and Object-Orientation.
-
Permalink Reply by Ryan Hobson on
-
Thank you Donna, I'll take a look...
Ryan
© 2012 Created by Kelly Waters.
