Develop Sharp Pictures

Have you ever taken a great picture with your phone and actually had it printed because you liked it so much? I’ve done that with photos of my kids since the grandma’s don’t do email. But I’m almost always disappointed by the prints. For various reasons, the printed photo looks grainy compared to the image on my phone.

Since I know the limitations of my phone camera, if I want great prints, I simply use my 35mm SLR camera. Prints from my SLR look just like the image on the camera – no surprises. It’s a random thought, but I see parallels in how this same approach can be used to achieve clear communication with our business stakeholders.

In waterfall, you take a picture of the project with your phone and email it to your sponsors. Everyone agrees that it looks great and the project kicks off. Somewhere during the development phase, the project manager is forced to print out the image. Sponsors are shocked to see the gritty truth that the project will cost twice as much and that the deadline is in jeopardy.

In contrast, agile is like using a nice, digital SLR camera. Emailed or printed, every iteration we share sharp images of scope increases, date shifts, roadblocks, etc. Openness and honesty are also an essential part of this communication. And because the business is seeing the relevant details from the start, that becomes their expectation.

So while Project Kickoff Documents and Weekly TPS Reports, like phone cameras, are great for giving people a rough idea of an image, they do little to communicate about the end product. Using better tools, like burn-ups and story walls, we can prevent surprises, which should lead to happier customers.

Mindless or Meaningful?

Where I work, there are a number of people who want to work alone in a cubicle all day, with only brief interactions with others. They believe that if they can just concentrate and stop any interruptions, they can get more done.

It’s a valid argument. Repetitive, mindless tasks are usually faster and more efficient without distractions. I started my professional “career” stamping mail and I could fly through it when I was focused. The problem I see is that these people are software developers – one of the least mindless jobs out there!

When people have been sequestered for too long, I think they forget the benefits of working closely with a group of peers. And while you can have success on your own, the personal benefits of collaborating cannot be ignored.

There is endless research on the dynamics of teams, so I’ll just share a few things that I have experienced firsthand. Just one disclaimer…to gain these benefits; you must actively participate on the team. ;)

• Self-esteem boost – other people on the team need your knowledge, your skills, and your unique perspective on a problem. It feels good to be needed.
• Occupational validation – working with others toward a common goal can affirm that you’re on the right career path and that you can make a difference in your corner of the world.
• Better ideas – team members stretch each other’s assumptions, which stokes your creativity, leading to better solutions.
• Accountability – when we get lazy, we need our peers to call us on it.
• Growth – I’m not talking about food days. ;) The best way to master a skill is to both pair with someone who can teach you and to teach someone who can learn.
• Comic relief – We laugh louder and fuller when in the company of others.

Deep down, we all know that we don’t know all. That’s why we are designed to interact and connect with others. Some of us need more, others need less, but without frequent, meaningful interactions, our work is less than what it could be.

So if you prefer a solitary, mindless job, don’t develop software. There are plenty of jobs in the mailroom for you. 

Open the Door for Someone

Even though I played sports in school, I struggled with running longer distances my entire life. Many friends encouraged me to run, telling me how much they enjoyed it. Despite their kind words, I still couldn’t run a mile. As an adult I gave up and resolved that I was not meant to be a runner.

And then one day I was talking to a friend. He happened to be a runner. I told him that I could not run and he mentioned casually that he was surprised. He thought that certain aspects of running such as tracking progress, goal setting, etc., suited my personality and that he thought I would enjoy it.

I laughed it off. But the idea wouldn’t go away. I started to see myself from his perspective. Maybe I did have it in me. Maybe I had approached it wrong all these years.

So I bought a treadmill and started a CouchTo5k program. Turns out I really like running! I’m not doing marathons, or even 5k’s yet, but I can’t describe the satisfaction of running a mile after 20 years of thinking that I never would.

What I learned from this:

•     When people tell me that I should do something because they like it, I nod while I think of reasons why it won’t work for me.
•     I like being successful. And I like even the possibility of being successful.
•   Sometimes I need other people to open my eyes to my own potential. 

That last point is the game-changer. In the chaos of life, sometimes we take our own skills, quirks, talents, for granted. By noticing a certain specific quality and suggesting that someone would be good at something because of it, you open the door for them to re-discover that about themselves. Sometimes just knowing that someone else thinks you can do something is enough to take the first step through the door.

No More Waiting In Line

For years, the roles on a typical software development team fell on some continuum close to or away from the actual users of the software. Developers sat at one end cranking out code and the business sat at the other making requests. In the middle were project managers and QA folks and, most recently, business analysts trying to make sure the ‘right’ software was delivered.

There is a major flaw with this model.

It’s based on the assumption that we can ask the business what they want and then we can go off and build stuff. The customer puts us into motion with their request or problem and then waits at the end of the line to tell us if we got it right.

It has been tolerated because we usually can deliver some software and we usually don’t screw it up too bad. We downplay the fact that the customer is confused by what was delivered, unsatisfied with the results and wondering how this could have cost so much.

Agile proposes a new model; one that satisfies customers and teams.

The agile model is a circle with the business at the center and the team built around them. The business still puts us into motion, but stays connected with the team throughout development, elaborating on requirements, prioritizing work and directing the course of the project. The roles of the team members also change as everyone focuses on completing the work instead of staying within the confines of their job description.

This collaboration focuses on understanding and satisfying the business needs and constantly communicating about what will be delivered and when. It also increases the team’s satisfaction because they are delivering the ‘right’ software. And that was the point in the first place.