This course covers the techniques required to break down and map requirements into plans that will ultimately drive software production. Upon successful completion of this course, you will be able to: - Create effective plans for software development - Map user requirements to developer tasks - Assess and plan for project risks - Apply velocity-driven planning techniques - Generate work estimates for software products
4.4.1D: Anti-Patterns - Individual Developers
Loading...
Del curso dictado por University of Alberta
Agile Planning for Software Products
919 calificaciones
De la lección
Module 4: Risk Planning
You’ve made it to the last module, congratulations! Here, we’re going to talk about what can cause projects to fail. We’ll start off by discussing common causes of failures, including anti-patterns. Then, you’ll learn how to assess risks, looking at their likelihood and potential impact on the project. We’ll end on an optimistic note by leaving you with strategies for intervening when risks present themselves and avoiding those risks to begin with.
Conoce a los instructores
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[MUSIC]
We covered anti-patterns related to how individual managers can negatively
impact development teams through their own behavior.
Now let's talk about a few anti-patterns that stem from individual developers.
And how to address them.
The first is the loose cannon.
A loose cannon is a person who makes significant project decisions
without consulting the rest of the team.
They might also cause problems in their workplace
by asserting their opinions on nearly any topic.
Instead of helping to make progress, the loose cannon often impedes it.
By raising small concerns and questioning every little thing.
If the person makes their point often enough,
others in the group will often concede just to avoid making a fuss.
Slowly, productive and openly conversing teams can turn into a bitter mess.
To make things worse, the loose canon can make everyone so
apathetic to issues that groupthink sets in as well.
When a loose canon makes decisions without consulting the group, they can create more
work for other team members, and cause major headaches for everyone involved.
This isn't heroics, like I discussed earlier in this lesson.
It's recklessness.
There isn't really a quick fix to the loose cannon.
And the solution often depends on why the individual is acting the way they are.
Sometimes the loose cannon just wants to cause trouble.
And sometimes they want to prove their own worth.
An ideal solution to the loose cannon is to try and get an individual
to see their own behavior as destructive and make steps to change it.
The personality of these individuals can often make change harder than
it needs to be.
In these cases sometimes organizational steps need to be taken
in order to address the problem.
A loose cannon can tear through a development team and
quickly derail productivity.
As difficult as it can be,
it's important to deal with the behavior of a loose cannon as quickly as possible.
Another destructive behavior exhibited by individuals,
often on the development team, is Intellectual Violence.
This is the final anti-pattern I'll talk about in this lesson.
Intellectual violence is as much about the developer's inner world as any of
the other anti-patterns I've described.
Intellectual Violence can be used by loose cannons, making meetings unbearable.
Intellectual Violence is a situation where a person uses their advanced knowledge in
an area to intimidate others.
This might manifest itself as a developer talking down to team members
when they ask questions about a technology they aren't familiar with.
As you might imagine, behaviors like this can cause team members to
feel unappreciated and unimportant.
Because of this, your team's morale can drop, and
you can be missing out on some key ideas, or at least clarifications.
To address an intellectual violence problem,
try talking to the individual in private.
Ask them to reflect on how their behavior affects others on the team.
Like the loose cannon it's important to deal with this issue early so
that it doesn't have a lasting impact on your team and your project.
Another solution that works is encouraging a there is no stupid question policy
at meetings.
On top of that, try encouraging open communication in the work place.
And discourage prejudging opinions or inexperience.
Stewart has been sitting in his office all week
without talking to the other developers on the team.
As the team's manager,
Poliana approaches Stewart to see what he has been up to.
When she talks to Stewart he tells her that he has changed the team's
user interface to better fit with proper practices.
Poliana asked the rest of the team if they knew about this, and
they tell her that they didn't.
What sort of anti-pattern is Stewart exhibiting?
A. Unproductive behavior,
B. Intellectual violence,
C. Loose cannon, or D. Expert behavior.
The correct answer here is C.
By making changes to the product without anyone else knowing,
Stewart is being a loose cannon.
To address this, Poliana should begin by
encouraging Stewart to communicate more regularly with his team.
And avoid making changes without talking to the rest of the team first.
Let's see how anti-patterns are dealt with by industry professionals.
[MUSIC]
>> Email as a primary communication tool sounds like a pretty easy thing to do
these days, everybody's using email and in fact I actually think it's used too much.
I would never recommend email as a primary communication medium.
And I would recommend two things.
When considering a communication medium, I would think about,
what are your stakeholders' preferred communication medium?
How do they like to communicate?
In the end, it's really not about your preferences and your communication mediums
and preferences, it's really about the people receiving the project deliverables.
So how do they want to be communicated with; whether it's by phone, by email,
you know face to face.
Whatever that looks like for them.
So find out what their preferred communication medium is.
In terms of email being a primary communication medium.
I'd also recommend going to the old phone or
the old face to face communication, I think too often we rely on email.
And email as a tactic can often be misconstrued, or
actually as a communication medium, can do the opposite.
It can actually have miscommunication in terms of the tone or
the voice that you're trying to create through an email may not be
heard in the way that you want it to be heard.
And so email can sometimes create new challenges for you.
In that people may not take that communication the way that you meant it,
and you've now created yourself some more work.
So now, you have to go and manage different personalities,
manage different situations, all because of the way an email was taken.
So I would recommend primary communication is the preference of your stakeholders,
as well as making sure you remember that there is a phone, and
you can actually have a face-to-face conversation with people too.
[MUSIC]
Intellectual violence is something real within our projects.
So intellectual violence can be defined as people using information or
knowledge as power to intimidate others within their project.
And so what you need to do as a product or
a program manager is really understand different people's personalities.
And understand how you can break through some of those silos and
the trust of your team members so that they can understand that knowledge and
information when shared is really when it's going to be most valued.
So to lead to success and the results that you're trying to get out of your project,
you need to find ways to do team building, to do confidence building.
To allow your team and your resources to really trust each other and
create that safe environment so they will share.
And so what you want out of your team is to ensure and
enhance sort of that understanding of each other's personalities so
that they feel comfortable in a safe environment.
Sharing whatever information that they have, realizing that
really the true success of your project is dependent
on this information sharing that they will do.
>> Well, that's it.
Those are all the anti-patterns I'm going to cover in this course.
There are plenty more.
As I said at the top of the lesson these are just a few from the project management
side of things.
However there are also anti-patterns related specifically to coding and
software processes as well.
If you are interested, there are links in the course resources
to help you dive a little deeper.
To quote Steve McConnell another writer in this field
some mistakes have been made often enough to be considered classics.
Others are unique to specific projects.
So now that we've covered the classics let's talk for
a little bit about what you can do to address these project specific mistakes.
Join me in the next lesson to find out.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
