people factor as failure reason of agile adoption

Post on 06-May-2015

1.380 Views

Category:

Self Improvement

2 Downloads

Preview:

Click to see full reader

DESCRIPTION

Slides from Mikalai Alimenkou talking at Agileee conference 2009, Ukraine

TRANSCRIPT

People factor as failure reason of Agile adoption

Alimenkou Mikalai

19.09.2009

Background

Java Technical Lead/Scrum Master at Zoral Labs

5+ years in software development 3+ years of working by Agile methodologies Expert in Agile engineering practices Agile coach (TDD, Testing, Planning)

Agenda

Introduction Why people are so important in Agile Agile team member responsibilities How people factor causes failures in Agile

adoption Ways of preventing failures

Some thoughts about Agile…

There is no ideal formula of success in software development

Agile is not for everybody If you fail with Agile it is not just

your failure

Why it doesn’t work?

How to fail fast with Agile?

Don’t pay attention to people factor Build Agile team from nothing Choose inappropriate time and conditions Have internal or external resistance Don’t understand Agile values Don’t have Agile leader or coach

Agile is built around the people

Individuals and interactions over processes and tools

Build projects around motivated individuals The best architectures, requirements and

designs emerge from self-organizing teams Business people and developers must

work together daily throughout the project

Why people are so important?

What is the main goal?

How to build right product?

How to buildproduct right?

ScrumXP

Scrum doesn’t tell us how to ...

Write high quality code Deploy the system Test the system Architect the system Support the system Maintain the code base Work with legacy code

May be try XP?

It is so complex …

Ideal Agile developer’s life

Communicate!Do pair programming!

Do continuous integration!

Do unit testing!Do TDD!

Do acceptancetesting! Make architectural

decisions!

Dialog with Agile manager

- Who is an architect in your team?

- Whole team!

- Who is a QA in your team?

- Whole team!

- Who is a manager of your team?

- Whole team!

“Agile” team behavior

“Architect!”

We don’t needupfront design!

Nobody likeyour architectural

documents!

Agile team member should …

Be ready for self-organizing Have high communication skills Make architectural decisions Build high quality product Have enough technical experience to do

engineering practices Have deep understanding of Agile values

You are lucky if your team is ...

Self-organizing High motivated Very efficient Experienced enough Technically skilled Responsive to changes Able to communicate easily and effectively Working together for a long time

If not so lucky?

Developers write bad code QA can’t control quality, but just find bugs Nobody is manageable, chaos in the team Technical dept is coming Communication is very difficult Expectations of the customers are failed Releases and deadlines are missed

But …

If you have a high motivated,

self-organizing team of skilled

and efficient professionals

you don’t need process at all.

They will build it themselves!

Why most of us are not lucky?

Not all team members may become Agile team member

Time and hard work are needed to become an Agile team member

Team is just a set of people Lack of self-education Lack of Agile leaders or coaches Misunderstanding of Agile values and

approaches

You can’t clone people

Self-education survey

How many of you have read at least 3 technical books this year?

How many of you have tried at least 3 new frameworks this year?

How many of you have visited at least 2 trainings or conferences this year?

What to do?

Have enough (at least 50%) technically experienced team members

Use full set of engineering practices Be patient and give team enough time Prepare comfortable working conditions Improve communication skills Use team building Make sure that everyone understands and

commits to Agile values

Way of the developer

Produce less but high quality code Continuous self-education (books, trainings,

blogs and forums, conferences and technical meetings)

Improve architectural skills Improve communication skills Share knowledge and experience (pairing,

games, brown bags)

Way of the QA

Think about QA but not QC Prepare to be a full functional team member Learn new frameworks and approaches Participate in all stages of development Continuous self-education (books, trainings,

blogs and forums, conferences and technical meetings)

Leave old habits in the past

Way of the manager

Try to build self-organizing team Forget about “command and control”

methods Read and analyze full flow of new ideas and

approaches Inspect and adapt Motivate people Listen to people and help them to be efficient Help people to improve their skills

And of course…

Hire right people!

Conclusion

People are the heart of any organization and

Agile process, so invest in them and don’t

forget about people factor making important

decisions …

Any questions?

Email me: lumii.subscriber@gmail.comRead my blog: http://javadevelopmenttips.blogspot.comVisit my website: http://agilecoaching.com.ua

top related