What can a developer do to instill a practical team Agile mentality? [duplicate]

Question

I have been at my new job as a contractor for about four months. Since I am very sensitive about workflow protocols and procedures, I made it a priority during the interviewing process to ask things like the SDLC culture, Agile, build processes, versioning, configuration environments, requirements gathering etc because, from personal experience, I find it easier to work in stiffer environments with a rigid structure rather than a loose, hectic one. I was told that the team was sort of Agile but not totally so I took the job hoping there is room for positive influence.

Part of the reason for my Agile inclination are my cognitive styles which partially revolve about my self-diagnosed attention deficit: I find it hard to grasp voluminous documents and requirements and instead focus on a single, atomic unit of work at a time, usually in a way that minimizes scope on the big picture. When I do something, I do one absolutely minimal thing at a time to get a sense of completion and I will usually split a task that others do all at once into many sub units. From my understanding of Agile, the methodology revolves around that concept exactly.

When I joined, it started becoming clear that most of the team members are in a complete waterfall mentality. The requirement documents are like book long whereas it is obvious they can be broken down into many atomic and almost independent sub tasks that build on top of one another. The whole requirement document is written before coding begins. I simply have a hard time reading a 50 page requirement document before I start coding because, by the time I am done reading, I will likely forget how it started. With smaller scope sub tasks, I do much better. Another example is that a functional module I have been working on contains many features that are not part of the core functionality (like "export data to Excel" and that kind of stuff) so I pushed those features in the next self-imposed sprint but requested that the QA test what has been done so far. The QA complained that I was not completely done yet so I had to explain Agile 101 to them and how things in the 21st century are done peacemeal in many different iterations to accommodate the finite nature of human cognitive and attentive powers, among other things, and make project management cleaner and more digestible, for the lack of a better term.

So, my question is, what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects? I am sure many companies that have existed more than 10-15 years have gone through this same transition and I would like to reuse their proven transition techniques, if any.

Answer 1

Clarity

First thing I'd like to clarify Agile is not necessarily better than Waterfall, and waterfall is not necessarily better than agile. Depending on your projects sometimes one methodology just makes more sense than the other.

The Problem

The problem they are dealing with is actually more they don't understand what agile is. Likely they consider themselves "kinda agile" because don't know what agile is, but do one or two things that agile companies do like hold daily scrum meetings.

First Step, Respect

You can't force change on anyone, people will only change if they see it as benefitting them. This is almost always the hardest sell in any change to a company culture. (And what you're proposing is a HUGE culture change, one we both agree is worth making, but I warn you now this will be a VERY slow process.)

Before you can really influence any sort of change in your company you need to earn a certain level of respect by those this would effect. This doesn't mean they have to like you or be your friend, only that they respect if you're taking the time to do this it's with good reason. Until you have this your chances of success are negligible. (you might already have earned this, but it's pretty rare for someone new to a company to have this sort of pull)

Second Sell It!

In this case you're a salesman, you're selling an idea / concept. The key to making sales is making the customer want your product. If they don't really want it, they won't buy it.

So how do you "Sell" Agile. This depends on the individuals and the company culture at large. Each person has their own drives, needs, and desires in regards to how they work. Some people want to receive their working order and just disappear for a week or two before turning it in and repeating this. Others like to vet out every little detail and nuance of a task in advance as a group. Both of these extremes can be very happy under agile, but how you sell them agile will have very different approaches.

The quiet worker

Agile has some social expectations that may not be present in the company as it stands. Daily Scrum meetings for example. Trying to sell the quiet working with this will only make them run kicking and screaming. That's literally the opposite of what they want.

On the other hand they HATE their boss constantly asking is their work done, what's the status on this, scheduling meetings to address that task that's ten steps later because it needs to be adapted due to an issue found at the current step, etc.

The Scrum board handles the lion's share of this! Once the boss is comfortable with the board they'll only bother the quiet developer when needed, and just skip to the board for the other stuff.

Agile also doesn't get into detail on step ten until we're closer to step ten. So instead of planning, replanning, and then further replanning you hopefully only need to plan each thing once.

That will make the quiet worker happy. They can get their work and do it without constant interruptions!

The Collective Worker

For the other extreme their are people who prefer to work in teams and favor pair programming and working in tandem with others over isolation. Agile works for them too! If you describe what you just said to the quiet worker they might like it, or it might completely disinterest them. Not that they'd hate it, just it's not very exciting.

For these people the sprint planning and daily scrum can be big sells! No more running people down to check on things! no more bothering people when you need that second pair of eyes. Collective brainstorming of something particularly troublesome needed? No problem! bring it up in the daily scrum meeting and take it offline right afterwards!

Being able to readily access the necessary people to get your work done is a huge sell to the collective worker.

Many many people

There are literally limitless variations in personalities. Some will be easy to sell on agile, others will be very difficult. You need to figure out what a person likes and dislikes work wise to figure out how to get them on your team. Note, you DO NOT need everyone on board, you just need to have the overall momentum in support of implementing proper agile.

Lead by example

Okay, so you've got a good amount of support now. They people want agile... but where do you start? This is where things get tricky. Very few managers will just go off and change their processes, but here's a fun fact you do NOT need your manager to change most of your processes, only a select few.

In this case you should start leading by example. You want to get a proper scrum board? set one up for yourself that is publicly visible. Once some of the other pro agile teammates see it they'll want one. This will naturally lead you to consolidate this into a single board. Once most of the team is already on the board you can start to win get management in on it which can help get those you weren't able to win over into using it. (expect resistance as well, try to win them over, but if you can't management can bring them in line once they're sold on the idea, hopefully though you can win everyone over, or at the minimum get them to reluctantly tolerate it)

Once you've got that board in place you move on to the next process, overtime you slowly convert to being closer and closer to true agile. As you convince management they want what you're selling you can start selling them on breaking things down into more manageable pieces and walla! you're agile!

Cautionary Note

As stated before. Agile isn't necessarily right for everyone / everything. In some cases resistance to true agile will be unmovable. Perhaps the CEO likes planning everything from A to Z and has no interest in breaking it down. In such a case the switch to agile is likely doomed from the start. (At best grim)

If there is a clear resistance to agile practices you need to be careful to not get yourself branded as uncooperative, a trouble maker, etc. Sometimes being the person who swims against the flow to create change is the best thing that can happen to a company. Other times it's a fast track to a pink slip. Make sure people overall want this change and aren't having it forced on them. One is a good thing, the other is going to be messy at best.

Good luck. I've converted three departments I've working in to agile/scrum. It's a long road, and there is no guarantee of success, but it can be worth it.

Answer 2

what can I do to influence the rest of the team to move to the 21st century and part ways with the obsolete and inefficient waterfall way of thinking and managing projects?

As a peer? Not much in my experience.

You can inform them about this new stuff. You can say how awesome it was. But at this point, if they've not migrated it's not because they've somehow not heard that there's this agile thing that is awesome. There is likely apathy or organizational impediments to changing. There might even be real business reasons to do waterfall, but that's unlikely.

A better approach would be to convince the boss. They (or you, if you're the boss) can then work with their boss to work with project management and QA and... you need to get high enough that some person can say - we shall be agile and has enough clout to do the education/correction/punishment necessary to make it work.

How to do that? In my experience, (and perhaps because I'm an overly critical person) I focus on the pain. Why is your current process painful? Do big requirements lead to slow development time? A lot of wasted time in meetings?

Explain how your solution will make this pain better. In my experience, people put more credence in the pain they feel every day than the hopeful future of some fad.

Answer 3

Companies, departments and teams have inertia, just like physical moving objects. You need to change the direction of this inertia. The challenge lies in determining if they are a rolling ball or a tank. Seems like the latter to me.

Do you have management buy-in? If you do, I would suggest setting up some mini-training sessions to better expose them to what Agile really is, sounds like they know the name but not the process. When they have had a chance to digest that, try to run a single project with the Agile model and let them slowly experience the difference.

If you don't have buy-in, the best you can do is gently point out some of the benefits and try to work as Agile-ly as you can for your work so they can see how it can improve the process. Hopefully they will be convinced of the difference and begin adopting.

This is not going to be an easy transition even if they are fully on-board, there is plenty to "un-learn" and lots to learn. Give it time and be gentle, if you make it a battle, human nature is likely to make them fight you automatically. You also need to understand that this may never work out. Not every group is adaptable and willing to change.