Process, Agile, and Projecting: Your Way Isn't the Only Way

DZone 's Guide to

Process, Agile, and Projecting: Your Way Isn't the Only Way

· Agile Zone ·
Free Resource
I remember a topic my childhood pastor would revisit from time to time: "gift projection". Without going deep into the subject, it's the tendency of people to assume that whatever giftings or callings they have are the same ones everyone else should have as well. If your thing is visiting the sick, you think everyone else should do that just as much as you. Evangelism? Ditto. Do you clean the church between services? Where's the rest of the congregation? Slackers!

My pastor's favorite way of dealing with was quite clever. Someone would tell him that a congregation member was sick, and that he, as the pastor, should visit them. My pastor would point out that God had laid this burden on their heart, not his. Perhaps, he'd say, God wants you to visit our sick friend.

This is, sadly, what far too many "experts" and developers do to each other every day. If we're writing unit tests, then dogone it, everyone should too! If we're having a blast pair programming, why isn't everyone? Scrum? Yes sir! It's the only way to run a project. Or, just as bad, you're not writing tests, so no one else should either.

This simple trap is one people fall into every day: projecting. If it works for me, it should work for everyone. Think about the unconscious arrogance in that point of view. Do you really feel that your experience is so broad, and your mind so brilliant, that you can map out the One Right Way for anyone else, much less the rest of the world? Personally, I think I'm having a great day if I can keep myself on track!

I say that, but I also make a living teaching people better ways to create software. My job is driving process within my company. I try to help others see better ways of working, but I don't pick a set template that worked for me and require others to follow it. Instead, I bring in principles and patterns. I show people what works for me, as well as what works for others. Then we look over the situation, the product, the people, and the timelines, and find what fits.

Think about how this works for someone you're trying to help. You could sweep in, lay down the proverbial law, and dictate the new way to getting things done. How likely are your team members to feel like they own the process? Were they involved in creating it? I've frequently this model build disrespect and resentment. It often discredits the ideas being introduced, and sours the team members to ever using them again.

On the other hand, what if you bring a few ideas to the table and discuss them. Ask people what feels like a good fit for them. Let them decide which direction to take. Who owns the change now? You were the catalyst, but the team members had an active hand in driving the change. They understand the motivations and thought processes behind the changes and are much more likely to make it succeed over time.

How do you see the world? Is it a black and white place where everyone is workign your way, or they're just incompetent? Is it your way, or wrong? I'd argue that there are many, many ways to build great software. There are many Agile practices that work very well. Some apply to teams, some apply to projects. Some affect individuals more, others are a great help to larger organizations. Which ones are the Right Ones? The ones that work for you!

Let me encourage you to try another approach the next time you run into a problem at work. Before you offer any advice or solutions, step back, think about the root problem (try The Five Whys), and bring back three ways to solve the problem. Hit the internet and find out how others have solved the problems. Post it on your blog or twitter account. Ask for help in any forum you frequent, and see what comes back to you.

Bring these three solutions to the discussion and let everyone criticize or complement each of the approaches. Sometimes additional ideas come out during the meeting. I try never to bring just one or two ideas, as it doesn't provide enough choice. On the other hand, bringing five to ten ideas, it's too much choice and the team tends to get too distracted and they never pick anything to use. (See The Paradox of Choice )

If you've only got one solution, you may have accidentally fallen into the trap of process projection. It's usually not intentional, but it can be very destructive. If you can't provide a few different solutions to a problem, I'd bet you haven't done enough research (or thinking) to be qualified to provide an answer.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}