Building software with humanity, part 3

In my last two posts I laid out a case for empowering software teams to succeed by leveraging their humanity. The point is, by connecting and relating to one another in a personal way, teams can accomplish much more than disconnected, uncaring teams.

So how do we get from here to there? Here are a few practices I’ve observed that have a dramatic impact on a team’s success:

• Daily, in-person accessibility between the development team and the business. Agile practitioners call this “co-location”, and the business person or persons, “product owners”. Some of the major impediments I have seen project teams struggle with could have been mitigated by having a business user on hand to answer simple questions. This challenge can manifest itself in many ways. If a team has an unclear understanding of a requirement, a co-located product owner could clarify the question in a hurry. If a developer comes up with a unique way of solving a problem that would be valuable to the client but would change the requirements, a product owner could weigh the risks and benefits and make a decision. If developers go down the wrong track in building a feature, a product owner can set them straight before too much time has elapsed.
• Co-located testers and infrastructure teams as well. Everyone involved with a project can benefit by being present with the other members of a team. Testers get the benefit of a better understanding of the product by interacting with the business people, and they can communicate their bugs and questions in a clear, personal manner.
• A regular session where the team reflects on its performance and discusses opportunities to improve. On one agile team I was a part of recently, we called these “retrospectives” and these informal meetings helped to identify best practices and pitfalls to be aware of. We learned about sections of the application that others were working on, and we developed a personal connection with one another and with the product we were building.

Developing a complex software application is difficult enough without all the communication hassles clients seem to be so intent at throwing at development teams. Having clear communication and a team with a shared vision and culture provides the team with many of the tolls it needs to realize its full potential and build amazing products for its clients. For more insight into how to build software with a human touch, read the Agile Manifesto.

Building software with humanity, part 2

In my previous post I outlined my ideas on the concept of humanity as a key factor in the success of a software team. In this post I’d like to point out a couple of examples of what can happen to a product when humanity is absent from a project – one from a user’s perspective and one from a development team’s perspective.

Exhibit A: The user interface from Hell

The first example comes from an HR portal belonging to a nationwide company with thousands of employees. In this portal there is a place where users can search for and download pay stubs:

Now keep in mind that the user is already logged in to the system at this time. Yet they are still prompted to enter their Social Security number and date of birth. This is idiotic. The user is authenticated, and the system knows who it is, yet it still asks the user to authenticate – this time in a different way from the username/password he used to initially log in.

OK, I’m willing to accept that there may be some valid security reasoning behind this extra layer of security, and that Really Smart People dream up things like this. Even so I think it’s a horrible and unnecessary user experience. But besides that, there is another spectacular failure on this page. Next to the Date of Birth text box, there is a little Date-Picker-thingy. When you click on it to pick a date, you get this….

Click on the drop-down for the year – because the user was not born today, after all – and you get this….

….A long list of years, none of which is anywhere near the year an actual employee would have been born. Click the “before 1998” list item, and you get…..

Oh dear. Suppose the user was born in 1971. OK, click it again.

Now, finally, the user is able to select his birth year, and continue on with his task – if he can even remember what that task was to begin with.

Clearly this is a broken interface! But wait, what does this have to do with humanity?

Well, here’s the kicker….

This user interface completely satisfied the Business Requirement for this functionality. It passed User Acceptance Testing with flying colors! It was rolled out to production, and no one had any clue(or if someone did, he didn’t care enough to speak up) how truly godawful this screen really was.

Things like this only happen when the team engaged in the work has no real human connection to the business being served, and doesn’t have any notion that the system they are building will be used by actual human people who will curse and bemoan its failures for years to come. To them, it’s just a series of technical specifications on an office document, no more, no less. But it doesn’t have to be this way.

Exhibit B: The project team only an accountant could love.

The second example has no screen shots or user experience anecdotes. It could be an actual project team but the reality is I’ve seen this example played out a number of times in my career. It goes something like this.

The development team is housed in one part of the country. The business is several hundred miles away. The testers are on another continent on the other side of the world. The infrastructure team is on another continent still. At no time are all of the team members observing regular business hours at the same time.

How is this a problem? After all, with technology we are always connected, right? Well, consider this: when testers are blocked by broken functionality or misunderstood implementation they often must wait until the next day to get a resolution. When developers have misunderstandings about requirements, they must hash it out over the phone, which is a sub-optimal format for conveying complex issues and subtle concepts. When the business users see functionality that has been implemented according to the written spec but the written spec was deficient or vague, time is lost, money is wasted, or the business must resign to accept less.

Software is a complex technical undertaking, but if you approach it as a merely technical endeavor you are missing half the point. Software is also very much a social product, as well, and it is a one-off product. You cannot create software like you manufacture a car, using interchangeable parts, interchangeable laborers and process. You cannot mass-produce innovation.

There is a better way, and I have seen it. I’ll talk about my ideas on creating a better software team in part 3 of this post.

Building software with humanity

I’ve had the pleasure and privilege  of having worked on a number of very different projects, for a diverse array of clients, using different processes and methodologies every time.  I’ve seen projects that delight the client and exceed every expectation, and projects that failed to live up to every promise.  And I think I’ve discovered a common thread – a thread runs throughout all the successful projects, and is largely lacking in the projects that fail to deliver on every expectation.

 Humanity. 

Software projects are among most complex things mankind has ever built, and most of us rely on software to perform critical functions in our lives.  Businesses and governments rely on software to such an extent that they would be crippled if it suddenly stopped working.  Software is also very, very expensive to build. And yet, as an industry we often act as if we have no idea of how to structure a software project that stands a good chance of succeeding.

 In my opinion, the single best predictor of success or failure in a software project is the presence or absence of humanity.  Humanity, then is:  the extent to which the project team engages, connects with, and supports one another for the shared purpose of creating the best possible solution to the project at hand. 

 All too often we structure our software projects in such a way to make it nearly impossible for the people on the project to communicate effectively with one another.  We do this through a number of insidious techniques:

• Separating members of the team, often placing them on separate continents.  When people are physically separated, communication and understanding suffer.   Throw in time-zone differences and language and cultural barriers, and you compound the problem.
• An over-reliance on  documentation.  This, I believe, hearkens back to the old days of computer science when people thought of programming in the same way they thought of engineering – in primarily technical terms. “Analysts” would produce reams and reams of documentation  in a “specification”, which the programmers would then convert into code.  This approach probably worked well back then, and is still the way to go if you’re designing a space shuttle or a microwave oven, but modern software has a human element that documentation just can’t handle. The old way doesn’t work anymore.
• Resistance to change.  Many software projects are religiously schedule-driven, and change represents threat, so it must be beaten back. On projects like this, innovation and new ideas are subordinate to the Almighty Schedule,  even if they lead to more value to the customer. So the innovation is disregarded, or renegotiated into a “change request”(meaning more paperwork), lest the status KPIs turn yellow.

 

But it doesn’t have to be like this.  Most software teams have the capability to produce innovative, high-quality products.  But what’s often lacking is a culture conducive to such innovation.  What’s needed is a culture that values interaction and cooperation as its highest virtue.  What we need is humanity.

 And by the way, I say “culture” rather than “process”, because a process is merely a set of guidelines to follow, whereas a culture lives in the hearts and minds of its members.  In other words, it is an internal, rather than an external, focus.

 In Part 2 of this post, I’ll discuss two examples of how a lack of humanity can produce disastrous results on a software project, the first from a user’s point of view and the second from a developer’s point of view.