It’s Better to Have Great People Than a Great Process

Imagine you had a team of ace software developers. This team is fabulous. They know how to get stuff done. They work well together and they work well with other teams. They always find a way to deliver good software.

Now imagine that they are given a terrible software development process to follow. The process is big, complex, redundant and bureaucratic. Every decision has to be validated, reviewed and approved. They are also given inadequate tools, poorly defined requirements, and a poor project manager. How could any team possibly succeed in such circumstances!

Yet, great teams overcome enormous obstacles. They find ways to succeed no matter what it takes. That’s what great teams do. They rally. They swarm. They fight. They win. The underlying process is simply a formality. The poor support structures are mere impediments.

The Opposite Won’t Work

Now imagine the opposite. Your team is given the world’s best software development process. This process is lean, efficient and simple. Many teams have followed it and its track record is nearly perfect. The team is also given excellent tools, clear requirements and a terrific project manager.

Unfortunately, the team members are rejects from other software development teams. They struggle with every decision. They argue amongst themselves constantly and they argue with everyone around them. They can’t agree on anything. Will this team find success by following the perfect process and having a great development environment?

No, they won’t. No development process, management support or technical training will save this team. They’re doomed!

Your Team Needs More Great People

Of course, real world software development teams are a mix of great people and not-so-great people. That’s why we need good processes, good tools, and good management support structures. These added elements help with team discipline and offer a path to consistency.

Want to improve your software development track record? Hire better quality people and pull all the stops to retain them. As for the poor performers, reassign them or fire them. Just get them off the team. They will only drag everyone else down.

It takes great people to build great software.

photo credit: michaelcardus via photopin cc

To Change, You need to Learn AND Unlearn

The challenge isn’t learning new things. It’s unlearning old ones.

Change is all but doing something differently, which requires learning something new. No problem, right? Life is learning.

But there’s a flip side to change. You have to unlearn something old. You need to stop doing something you’ve learned to do. If you’re not particularly happy with the old way of doing things, unlearning should be a pleasant task. However, if you’re comfortable and skilled in the old way, unlearning it will be a challenge.

Consider this common example.

Let’s say we have a software development team that’s accustomed to receiving lengthy business requirements documents. They study them carefully, prioritize the contents, and lay out game plans for building the systems. Let’s assume that they know many things will change along the way but they like seeing the big picture at the outset. That is, all the major and minor requirements are defined in a single document. When things change (as they always do), the team will re-group and adjust the plan.

When this team begins receiving business requirements in the form of user epics and stories, there will be a bit of culture shock. The big picture will still be there but it will be in the form of epics that progressively drill down into detailed requirements via stories. The epics and stories form a hierarchy that presents the same business requirements in a very different format.

To make things more unnerving, not all of the epics will be decomposed into stories before the team begins to write code — some details will be missing. Having been through this transition several times, I can tell you that some developers and testers will be extremely uncomfortable.

You can train people in a new way of doing something and you have to untrain them in doing something else.

It’s not easy. Be patient. It may not be practical to completely abandon the way things are done today and jump into the new way of doing the same things tomorrow. Going from the current situation to the new one may require intermediate steps. Some people will have trouble letting go, needing time to gradually transition to the new way.

There may be a clash between those ready to leave the past behind and those clinging to it. Keep expectations under control. Move fast but not so fast that some people get left behind and unable to contribute.

photo credit: giulia.forsythe via photopin cc

You Don’t Need to Be Better. You Need to Execute Better.

Companies don’t need to be better than their competition, they need to execute better. You don’t need to be better than your coworker, you need perform better. Your team doesn’t need to be better than another team, it needs to do better.

Make sense? Simple, right? Not at all.

When we use the term “better”, we’re implying that someone or some entity is superior in some way to others like themselves. The other person or entity may be smarter, stronger, tougher, faster or cooler. I’m arguing that you don’t need to be any of those things to be better. (They all help, but none are mandatory for success.)

The one thing all of us must do to be better is execute reliably and consistently. Forget the excuses. Focus on execution. There will always be someone who is smarter, stronger or better looking. It doesn’t matter. You need to execute better than that person.

We see it all the time in sports. The best team (statistically) doesn’t always win. The fastest race car doesn’t always cross the finish line first.

In business, the company with the best product doesn’t always capture the biggest market share. The product using the best technology doesn’t always sell the most units.

The principles of agile software development and Scrum in particular support the concept of executing better. Amazing results are achieved with teamwork and collaboration among technical and business people. Here’s what you need to do:

• Tell others what you’ll do, and do it (even if you don’t want to).
• Deliver on your commitments (even if it hurts).
• Treat others with respect and dignity (even if you don’t mean it).

That’s it. Make sense? Simple, right?

photo credit: jot.punkt via photopin cc

How to Do Less and Deliver More

Have you ever had a manager ask you to “do more”? Or maybe he skipped the politeness and just told you to “do more”? It usually happens after you’ve indicated that you have too much to do — too many projects, too many tasks, and not enough time. Rather than offer help, all the manager gives you is “do more”.

It’s happened to me. I was once in a management job where an ordinary week was 55-60 hours long. If something out of the ordinary happened, it quickly became a 70-80 hour work week. Whenever I requested assistance, all I got was “do more”. Not surprisingly, the company eventually filed for bankruptcy. Luckily, I got out of there before that happened.

If you find yourself in a similar position, here are a few suggestions.

• Start by reviewing all the stuff you need to get done. Ask yourself what can be delegated to someone else or skipped entirely. Discuss your ideas with your team and your manager. Be as specific as you can be. You’ll get some push-back so be ready.
• When you’re feeling overwhelmed, describe the problem to your manager in detail. Be specific about what’s causing the issue and what assistance you need to get the job done.
• If additional staffing, either permanent or temporary, will help, say so. Offer specifics about the required skills and the length of time they’ll be needed.
• If more or better equipment and tools are needed, speak up. Do some research into what’s available and what value it will add.
• If you’re overwhelmed by administrative tasks, offer ideas for reducing or eliminating them. Even temporarily skipping some routine drudgery might free enough time to give you some breathing room.
• If you’re not getting the support you need from other team members, be specific about what you need and who should provide it.
• Be clear about any management interventions that cause delays. For example, preparing fancy status reports, attending routine status meetings, incessant requests for status updates, preparing documentation simply because the “process police” require it; these can be huge time sinks. Offer specific ideas for how these artifacts can be reduced or eliminated.
• Ask about priorities. What REALLY matters? The answer is likely to be something like ‘everything matters’. If so, point out that the team needs to focus in order to be most productive. Offer the manager an opportunity to guide the team or risk losing control of them.
• Make it clear that if you don’t get what you need, projects will be delivered late and/or quality will suffer. You’ll do your best, of course, but being stressed-out and over-worked will have a negative impact.

The major theme in these ideas is specifics — be as clear and precise as you can. If none of the above work, your manager is likely more interested in protecting herself than helping you. My best advice in that situation is find another job — you’ll be less stressed and more energized.

photo credit: net_efekt via photopin cc

Getting Stuff Done Leads to Happier and More Productive People

I have good days and not-so-good days. I’ll bet you do too. My good days are the ones that leave me feeling a sense of accomplishment. That happens when I get something done — finished, not just “worked on”. My bad days are the ones that leave me wondering what I did all day.

You see, it’s not simply a matter of being busy. I have a lengthy backlog of work — more than I will likely ever finish because it seems to arrive faster than I can finish it. I’m always busy but I crave more. I need to be done. I need to finish stuff.

If you’re like me in this regard, and I suspect you are, your job satisfaction and productivity have a direct relationship to how much work you get done — that’s finished, acabado, fini, finito, fertig, consumandam. How often do you hear people bragging about what they spent time on? Rarely, right? They brag about what they accomplished. What they completed. What they got done!

We all need more good days. People are energized by finishing. We derive job satisfaction from finishing a major task — accomplishing something of value. All of us should be finishing something significant every day — every single day.

Another Reason Why Waterfall Doesn’t Work

That’s a huge problem for software developers in traditional development organizations. They are forced to spend days, sometimes weeks, working on documents and diagrams. After all that work, they’re forced to wait for some bureaucratic approval process to complete — it’s hurry up and wait all over again. Or, they may be forced to summarize the documentation in a PowerPoint presentation and deliver it to a committee. As each day passes, ‘just shoot me now’ becomes more and more appealing.

Productivity declines. Output volume shrinks. Quality suffers. Managers are oblivious because people appear to be busy as progress is being recorded in weekly status reports.

Management 101

The secret to better morale, improved productivity, and superior results is unbelievably simple. Let your teams finish something. Note the word ‘finish’. I didn’t say “do something”. I said “finish something”! Stop creating busy work. Dump the approval cycles. Remove the impediments.

In addition, when your team needs something from you such as an approval or an upgraded development tool, make it happen. You’re putting a lot of pressure on the team and some of that pressure will push back on you. It’s only fair that you respond quickly.

Improving morale isn’t brain surgery. It’s common sense. To create more good days define simpler accomplishments, remove impediments and get out of the way.

photo credit: jayneandd via photopin cc

Don’t Just Change the Rules, Change the Game

Several studies have shown superior software development success rates when using an agile approach like Scrum or Kanban versus a waterfall approach. Does using a waterfall approach to develop software cause many projects to fail? Conversely, does using an agile approach cause projects to succeed?

I wish it was that simple. Ultimately people cause projects to succeed or fail. People are drawn to people like themselves. People are drawn to environments and cultures they prefer. What characteristics do you look for in the people you hire?

Waterfall approaches to software development are prescriptive. They use command-and-control, phases, gates, documents and approvals to get things done. What kind of people, do you suppose, are attracted to those techniques?

Agile approaches are collaborative. They use teamwork, self-organization, conversations, visuals and feedback to get things done. What kind of people, do you suppose, are attracted to those techniques?

Real Change Takes Time

I’m not a psychologist or sociologist so I’m not going to attempt a deep dive into these ideas. My point is that if you want to improve your software development results, you need to take a hard look at the messages you’re sending and the people you’re attracting.

Why is this so important? If you decide to change your development approach, you’ll need to change your people too. How are you going to do that? It won’t happen in a sprint or two. It will likely take a year or more to completely transition from one approach to another.

In a large organization, you’ll have multiple development teams. Are they all going to transition at once? If so, it will be a huge undertaking. If not, how will interteam dependencies be managed when one team is using Scrum and the other is using waterfall? Their deliverables will not be aligned.

Adopting agile software development is not simply a matter of changing the rules — you need to change the entire game. What would you do if you wanted a basketball team to play ice hockey? How about a soccer (football) team converting to basketball? It would be a colossal transition requiring plenty of training and conditioning. Some players would not be able to adapt. New players would need to be recruited.

That’s what you can expect when going from a traditional, prescriptive, software development approach to Scrum or Kanban. You can make it work if you’re willing to invest the time and effort. Do you have the time?

photo credit: fchmksfkcb via photopin cc

Hire the Best People By Focusing on What Matters

In my post “Don’t Just Prioritize User Needs, Prioritize the Process Too”, I discussed the need to prioritize the elements and artifacts of the software development process. In this post, I’m turning my attention to the hiring process.

When your team needs to bring another developer on board, what do you look for? If yours is like most teams, you compile a list of technical skills something like this:

• PHP
• Javascript
• Eclipse
• Spring framework
• etc.

You may add some non-technical skills to the list like this:

• Good communication skills
• Team player
• Works independently
• etc.

And just for good measure, you might add…

• Walks on water and doesn’t leave foot prints

(Okay, maybe that last one is slightly exaggerated!)

These lists of job requirements are often lengthy and at times contradictory (such as “works independently” and “team player”). You need to ask yourself a critical question — “What really matters?”.

I can’t give you a direct answer to that question because the answer depends upon your situation. I’ve hired many people over the years (and, sadly, fired a few). Here’s what I’ve learned.

• Focus on what really matters.
• Highly specific technical skills don’t matter. (For example, someone who knows several computer languages can readily learn a new one.)
• Getting along with people, even difficult ones, really matters.
• Knowing how many stuffed animals fit in a Volkswagen Beetle doesn’t matter.
• Ability to learn new things really matters.
• Writing elegant and eloquent specifications doesn’t matter (unless you’re a big consulting firm).
• Being able to convey an idea to a group really matters.
• Solving problems doesn’t matter (that’s a team activity).
• Identifying problems before they ruin your day really matters.

Who should you hire for your team? It depends on your company culture and your work environment. If your company favors top-down, command-and-control, you need to hire people who are good at following procedures. If your company favors distributed, self-organizing teams, you need people who work well in an open, team setting.

Bottom line: Focus on the soft skills. People who are smart, open-minded, team players will learn whatever technical skills you need. The opposite is not true — people with great technical skills and poor soft skills are unlikely to change. Firing them won’t be pleasant.

photo credit: NoJuan via photopin cc

Open Source, Agile Development and Social Media Have Something In Common

Open source software, agile development techniques and social media tools are three of my favorite things. They have one thing in common that binds them together — they help people collaborate.

All three provide mechanisms people can use to interact and cooperate. In fact, the more we do so, the better the results. That’s how crowdsourcing works — many hands, many minds, better results! Think about it.

Open Source Software

Open source projects existed before agile development and social media. The popular open source projects like the Apache HTTP Server, LibreOffice, Linux and Mozilla’s Firefox are great because lots of people contribute. Many ideas, opinions and contributions make the software better. It can get cantankerous at times but that’s okay. Reasonable people can disagree — sometimes strongly — and still work together to achieve a better result.

Agile Development Techniques

Agile software development came along to address the process issues around building software. It takes a lot of skills, tools and techniques to build great software. But more than anything else, it takes people who interact and collaborate. We can debate Scrum vs. Kanban vs. XP vs. Lean for weeks. None of those approaches will work without good people who are willing to work together and accept compromises. It’s not about the process. It’s about the people.

Social Media Tools

Smartphones have given us the ability to communicate in new ways. The simple phone call is from the last century. Facebook, Google+, Instagram, Pinterest, Twitter and similar tools have changed our lives. They give us new ways to interact with others — even people we’ve never met. Suddenly, anyone can be heard and acknowledged anywhere in the world by simply posting a message or picture through one of these services. It’s amazing and addictive.

Collaboration Is Key

When we collaborate, we get more done in less time with higher quality. The collaboration must be genuine, however. If the opinions of managers carry more weight than those of others, collaboration is crushed — command and control take over.

If you dislike the concept of open source software and you hate social media tools, you aren’t going to like agile software development either! It’s time to change.

photo credit: Will Lion via photopin cc

Don’t Ask Me What I Want, Give Me What I Need

I don’t know about you, but scenarios like the following happen to me all too often. I meet with the business stakeholders and representatives of the user community to discuss changes to a software application. We discuss new features and/or changes to existing ones. They give me a general idea of what they want. I describe how this might operate within the software. They indicate agreement and I go forth to develop the features in our sandbox.

Depending on the type of changes and which software development groups need to be involved, I may create a formal specification, write up stories and/or throw together a mock-up. For small efforts, I may simply make the changes directly in the sandbox (Salesforce.com makes this really easy). I can always write some kind of documentation after we agree on the implementation approach.

So far so good, right? I show them the sandbox implementation. They offer a few minor suggestions and ask how soon the changes can be deployed in production.

We love it … But …

Here’s where it gets interesting, amusing or frustrating depending on your point of view. The changes are deployed and complaints arrive in my inbox — usually only a few but on occasion, it can be a blizzard! Why does that happen?

1. Sometimes the stakeholders and user representatives didn’t fully understand the problem expressed by the end users.

They should have dug deeper and I should have engaged at least some of the end users directly rather than having all the information filtered through their reps.

2. Sometimes the stakeholders and user representatives didn’t fully understand the solution I proposed.

They should have spent more time exercising the sandbox implementation and asking questions. I should have explained the solution better and more importantly, I should have clearly defined what the software would and would not do.

3. Sometimes the stakeholders and user representatives didn’t really know what they wanted. Their real intention was to try something, see the result, and make another set of changes to the software based on user feedback.

That’s fine too, though they should have stated up front that they wanted to conduct an experiment. This is a communication breakdown that stems from lack of trust.

4. Adding more people to the discussion by deploying the software always generates new ideas and opinions.

That’s a good thing — as long as everyone is reasonable. I always listen carefully to everyone’s concerns and opinions. Most people simply want to be heard and understood.

5. Some people simply enjoy complaining.

Sadly, there’s nothing we can do about this latter group. Let them complain and always ask them for their ideas.

These issues don’t crop up every time but often enough to be troubling. Everyone is busy trying to operate their area of the business. Everyone has too many demands on their time. These issues will never go away entirely.

Welcome to the world of software application development. I don’t know what I want but I’m sure you can figure it out.

photo credit: Sybren A. Stüvel via photopin cc

Whiners and Complainers Can Be Sources of Inspiration

Would you like your team to do a better job? Do you want to change your approach? Try talking to the team members who are discontented — the disgruntled ones. Why are they unhappy? What would they change?

This can be a difficult conversation to have. Some people are just plain grumpy. They are the ones that always complain no matter what the situation is. I often say that some people aren’t happy unless they have something to complain about.

You really need to focus on those who can offer constructive criticism. It’s easy to complain and criticize. Anyone can do it. It’s much tougher to follow complaints with constructive suggestions — new ideas that improve the situation.

People who whine and complain constructively can be a source of inspiration. Here’s how to tap into it.

Define the Problem

The first step is to clearly define the problem. For example, if someone says that a process is too cumbersome, it’s largely meaningless. What precisely is cumbersome about the process and in what way? You need specifics. Here are some questions you can ask to get started.

• What’s going on?
• Why does this bother you?
• Is there something brewing within the group?
• What prompted you to speak with me?
• Does this happen often or occasionally?
• What are your expectations?

Explore Solutions

It’s important that the team member offer ideas for solving the problem. It’s not the job of a team leader or manager to solve every problem. If no ideas are presented, challenge the team member to find a solution and suspend the conversation. If an idea is offered, explore it and add one of your own.

• Can you move beyond pointing out the problem and help solve it?
• How can we solve this together?
• What changes do you recommend?
• Who else needs to be involved?
• How will these changes affect other teams?
• How quickly can this get done?

Agree on Next Steps

• Would you be willing to do X?
• If you’ll do X, I’ll do Y. Agreed?
• Let’s meet again tomorrow.

If you encounter someone who wants to change the world or proposes a big, expensive solution, bring the person down to earth. Explain the realities of budgets and potential impacts on other teams. I like to tell people to start small and lead by example. If you implement a positive and constructive change, others will gravitate toward it and more changes will follow. We all want to succeed, right?