nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Introducing Agile to a team with no prior experience of it

GMcGann

Hi everyone,

I am a computer science graduate student at the University of Oxford, currently researching Agile methodologies. I'm also a staffer at the UN Dept. of Economics working in a scrum team.

In my research, I’m exploring the best approach to introduce teams to Agile when they have no previous exposure to it. I would appreciate your insights on two specific strategies:

Option 1: Introduce Agile theory comprehensively from the outset, ensuring a solid foundation in Agile principles and practices.

Option 2: Introduce Agile theory gradually, aligning with the immediate needs and tasks of the team.

Which approach do you find more effective in your experience? Your advice will be invaluable for my research, and I'm interested in hearing about your experiences and rationale for choosing one approach over the other.

If you're interested in my research or just want to connect, feel free to reach out to me at gregory.mcgann@kellogg.ox.ac.uk

Comments

Nic Brough -Adaptavist-

Both, and a lot in between - it's not a binary "big bang" or "gradual creep", there's a scale.

I have been involved in a lot of Agile transformation projects, and the approach taken has always been fitted to the teams who are going to be adopting it. Some teams work best if they transform overnight, others need to be guided into it over a period of time.

Overall, yes, explain it to all the teams as an introduction, but take each team individually and see how ready and willing they are to move. Some will resist, others will be keen.

Rodrigo Borgia

Hi Gregory,

Greetings from Argentina! I came across your post and found your research on Agile methodologies quite intriguing.

In my experience, I've found that Option 2 - introducing Agile theory gradually and aligning it with the immediate needs and tasks of the team - tends to be more effective. Not all teams are ready for a full-scale implementation from the outset. The concept of taking incremental steps and incorporating ceremonies that can be sustained over time seems to make a more profound impact, allowing teams to adapt and internalize Agile principles organically.

I appreciate your exploration of this topic, and if you're interested, I specialize in Agile training. I'd be more than happy to share my approach and experiences in a conversation. Let me know if you'd like to connect and discuss further.

Best regards,

Rodrigo

TC Wang_f5xqx2

Hi @GMcGann welcome to the community!

Not directly related to your question. But perhaps this post would help out with your research. Good luck!

Ron Skyberg_fsi42k

Option 2:Introduce Agile theory gradually, aligning with the immediate needs and tasks of the team.

I feel that a gradual introduction into an Agile/SCRUM approach has been - for me- a better way to go. Introduction of the core manifesto concepts (Individuals and interactions over processes and tools, Responding to change over following a plan, Working software over comprehensive documentation, Customer collaboration over contract negotiation), setting the foundation for an Agile methodology within an existing and established team. If you are transitioning a team to Agile/SCRUM (remembering that SCRUM is just a framework for Agile methodology); the team may get initially bogged down in all the scrum ceremonies (backlog grooming, retrospectives, point planning, etc.) and not get off the ground.

I personally have found that transitioning an existing Software Dev team into an agile/scrum approach is best done after a major milestone has been achieved, such as successful testing of an MVP candidate - "Hey team, GREAT work on getting the MVP out the door! Now, moving forward, lets try this approach to expanding the MVP to a really great customer experience. PM wants THESE features, which ones do you think we can deliver in X weeks?..." type of spiel. This gives them a sense of involvement and ownership in the success of the project ('Deliver This by date X' , vs 'I agree to deliver this in X weeks') and that their input matters. No formal point sizing and no full backlog grooming yet, just a This is what PM (as 'the voice of the customer') wants, what do you think can we deliver in a set time frame? I "Define Done" (Code checked in/passed unit testing vs. code passed formalized QA and is deployable) at this point when getting lightweight commitments. It's easier to get that commitment (major milestone achieved, no external immediate pressures to the team because hey, we just achieved a major milestone!), and the team can show advancement of project at the end of the sprint. Then in this initial phase in, I include daily team standups to cover progress/reveal blockers, and have a retro at the sprint close. Then, I introduce backlog grooming/point sizing. I let them grow into a full Agile/SCRUM approach seeing the benefit of each step in the process, explaining the 'why' at each new SCRUM method inclusion. I have the beginnings of sizing/velocity metrics for future planning sessions, and we are building up on that foundation (core concept acceptance, working and delivering Y in timeframe X, adapting and overcoming, feedback is valued, et c) as a TEAM.

Additionally:
1) Be prepared for the inevitable push back of "But, We've always done it this way" when switching from a 'waterfall-y' approach to a more agile methodology - have answers in mind as to how an agile and/or scrum methodology can benefit the given project AND team.
2) YOU need to be truly AGILE in your approach to changing the team. If something in your Agile approach is not working, adapt it/change it for wider acceptance by the team.
3) Above all else, remember that the Agile and Scrum approaches/methodologies are GUIDELINES; especially the 'Individuals and interactions over processes and tools' part; not a "Do It This Specific Way or The Agile Gods Will Smite You!" decree from on high --- because, how Agile would that be?

Lou_i8ocvv

Couldn't agree more with this.. Forget OR, it should be AND.. Common mistake many people make, as it's all relevant until proven otherwise.

Just because you've tried something with one team, and didn't meet your success criteria. Doesn't mean you shouldn't try it with another, because every environment is different and thus produce a unique (good or bad) outcome.

Welcome!

It looks like you're new here. Sign in or register to get started.