Subscribe via RSS Feed

Author Archive for Alan.Smith

Everything I Know About Software Development I Learned from Elephants

The Swiss Army Knife of the Animal Kingdom

Elephant-2Last week, I talked about the importance of introducing the elephants in the room.  So now that we have the elephant in the room, let’s examine it and see what we can learn from elephant behavior and how we can apply it to software development. The irony of the “elephant in the room” metaphor is that it suggests that elephants are these large, bulky creatures that are imposing and not dynamic. In fact, elephants are one of the most versatile mammals on this planet. The elephant’s trunk is used to tear up food, so the elephant can digest it. It is a hand that can grasp objects, a means of drinking without having to bend over, and a way of  spraying mud on themselves to protect their skin from the sun. It is even used as a tool for  social interactions, to enhance their highly developed sense of smell, and to defend themselves from predators.

To deliver software predictably, we need to become dynamic, adaptable creatures as well. As the speed of technology gets faster and faster, we’re going to have to give up the idea of just doing one or two things really, really well. We’ll have to be like the elephants’ trunk. We have to know the foundation of coding, but not be married to any single language. We’ll need to understand the best practices of project management, but be flexible in our methodology and apply the best methodology to the best practice. We will need to master requirements facilitation, but have many different tools to gather requirements and to custom fit the requirements process to the appropriate projects.


Even We Can Become Extinct

If we are rigid and only do things one way, technology will pass us by and we’ll become extinct. However, if we are adaptable with our tools, practices, and methodologies, we’ll continue to evolve to meet the demands of business using the best that current technology has to offer.

In the past, the slower speed of technology may have meant that a method and tool would be useful for many years. In the fast pace of technology today, it is never the case that we can say that any idea, method, or tool works every time. We need to be constantly transforming ourselves, our ideas, methods and  tools to confront new challenges.

We may come to find more and more that projects are changed or canceled once we have gained momentum. Perhaps what made business sense when we started the project no longer makes sense due to new technology which has changed the marketplace. Rather than letting this disturb our equilibrium, we should begin to develop habits that allow us to shift rapidly and be adaptable to such change. Those in technology who can rapidly adapt will excel in tomorrow’s marketplace.

Being flexible and adaptable isn’t easy. It requires us to constantly let go of things that we know as true. Something may have worked for us before, but it may not work now. Or perhaps we have a perfect tool in mind for the job, but our client has a tool they like more. We have to let go of what has worked in the past for what it will take to accomplish the challenge before us.


And Maybe Dumbo Wasn’t That Far Off Base

One last thing we can learn from elephants is to use our big ears. Disney’s portrayal of Dumbo, the elephant with ears big as wings, wasn’t that far off base: Elephants have huge ears and an exceptional power of hearing.

As a predictable partner, we also need to always be using our ears. Not just to listen to what our clients are saying, but to really understand the meaning of what they are saying.

We can do this by maintaining a curiosity with our clients and what unique strengths and issues they have. Listening is a good first step, but when we are curious about our clients’ strengths and issues, then we have motivation to not just hear, but to understand.

Also, using our ears helps ensure that we are speaking the same language. It ensures that we are talking apples to apples and oranges to oranges. Our active listening helps our clients to know that they are being heard.

So next time you pop in the Disney classic about the elephant with the big ears, take note. Just like the underdog elephant who learned to fly, we can also use our ears to help us find success  with our teams and clients.

What Elephants Teach Us About Software Development

The Blind Man and The Elephant

SONY DSCSo there’s a treasure trove of stories and metaphors that revolve around elephants, and lately in my work with Geneca, I keep on running into elephants.

One of my favorite elephant stories that I’ve been coming back to lately comes from several sources in Eastern Philosophy: The Blind Men and the Elephant. In this story, several blind men encounter an elephant. One touches the ear and says the elephant is like a hand fan. Another touches the trunk and says the elephant is the branch of a tree. The one who touches the leg believes the elephant is a pillar and the one touching the tail believes the elephant is a rope.

This metaphor tells us that different people with different roles and perspectives will have different ideas of what the “whole” is. This reminds us that on projects, since each person can’t see the whole, we have to have good communication with each other to understand what the whole really is. And this leads me to the next metaphor that I keep running into:

Getting in the Elephant Habit

When I listened to “Last Lecture” by Randy Pausch, a Professor who had cancer and was delivering the last and most important lecture of his life, I was struck by the technique he used to address the most anxiety-producing topic in the room. What he said was: “My dad always told me, when there is an elephant in the room, introduce them.” Then, he goes on to talk about the fact that he has cancer, which everyone knows, but nobody wants to talk about.

To deliver software predictably means to always be introducing the elephants in the room. When there are things that everyone in the room knows about, but no one wants to discuss – politics, friction between team members, risks, difficult decisions no one wants to make — it is our duty as the predictable partner to introduce these elephants.

One of the best practices of predictable software delivery means that we are speaking the same language as our client, apples to apples, oranges to oranges. Because we are the predictable partner, and because we believe in the best practices of predictable software delivery, we need to step up and introduce the elephants in the room, even if it is difficult and perhaps risky to do so.

I’ve noticed that the first time you introduce an elephant in the room, it is not well received. It is as though you have disturbed a social norm. It makes people uncomfortable. Often the first elephant I’ve introduced is the friction between two members of a team. Everybody has noticed it, but everyone has consciously or subconsciously decided to accept this friction that negatively affects the team, rather than face the uncomfortable moment of calling it out.

What I’ve found is that after introducing the first elephant, the second becomes easier. After the second, the third is expected. After the third, people have adapted to this behavior, and even begin to call out elephants they see. It becomes a habit, a part of the team culture. And having a team culture of calling out the issues rather than sweeping them under the rug is what being a Predictable Partner is all about.

Next week, I’ll talk about what we can learn from elephant behavior and how that can be applied to software development.

So, can you learn to adapt, or will you go extinct?

Photo Credit: Martien Uiterweerd

Requirements Processes: Welcoming Base Level Users to Participate

Doors-ImageNow that we’ve established the advantages of software requirements sessions leverage base level users: we have to address  two very important issues: Are these individuals ready to participate in the requirements process from day one? What can we do to prepare them to do their best? Here are some ideas that I’ve  found to be easily implemented and highly effective:

Start With an Expanded Kickoff Session
Many business analysts find it valuable to have a requirements kick-off session for individuals with no previous requirements session experience. This gives them the opportunity  to describe what is expected during the process and get everyone familiar with the terms, concepts and technologies used on the project. For example, if the project is taking an Agile approach, include a description of what Agile. This helps base level resources feel more involved with the project and prevents them from checking out during the requirements sessions when unfamiliar items come up.

Empower for Best Results
Base level resources often have a wealth of knowledge that BAs are eager to capture. However, some base level users find that participating in a new process and working side-by-side with executive  stakeholders is a little unnerving. One way to encourage the base level resource to speak up is to explain that the reason they’re involved in the requirements session is to correct inaccuracies and provide their viewpoint of how things work.

Clarify Obligations
Participation in requirements sessions often requires “homework”. Be straightforward about action items that may be required during and outside of sessions. Make sure that time commitments are confirmed prior to the kickoff meeting. If the BA thinks of questions that need to be answered prior to the next session, he/she should have a process for tracking and obtaining such information.  Some techniques that have proved successful include giving due dates for assigned items and keeping a list of all requested items and their status.

Emphasize the Value of Participation
While participation in requirements sessions involves time commitments, there are tangible benefits. Participation results in more education on the technology used in the solution and enhances the use of the finished product. For example, call center representatives involved in the design of a CRM solution are better equipped to use the technology from day one and train other representatives.

Building the Ideal Requirements Team
An ideal requirements session should include diverse resources who collectively provide the  authority to make business decisions, insight into business strategy, and knowledge of end user needs and business operations.

Using a base level user is a cost efficient  way to broaden the perspective of the business stakeholder group to include operational knowledge and end-user feedback. Plus, base level users involved in the requirements solicitation process get up and running more quickly and experience business value faster.

If you  use base level resources in your requirements process, what advice would you give to others to get the most from their sessions?

Photo Credit: Eduardo Zarate

Uncovering Hidden Software Requirements


823004299_42b6abf953_z-232x300Base Level Users in Requirements Gathering Sessions Can Yield Gold

The need is clear for business people to be part of requirements definition – that is, understanding the intent of the system and creating a common definition of success. Once that course is set and specification begins, how can we ensure we’re getting the right details to accomplish those goals?

Today, the idea that a software team can gather requirements without direct participation from the stakeholders who can speak for the user is outdated. Receiving sufficient quality customer input — along with the business stakeholders — makes a direct impact on a software teams’ ability to predictably deliver business value.

I have found that business stakeholders are not necessarily equal, interchangeable resources. For example, consider a requirements session where the stakeholders do not have the authority to make business decisions. Or, a session where the stakeholders lack sufficient knowledge of business processes. And then there’s the case where  the stakeholders have the authority and knowledge of business processes yet the solicited requirements are still incomplete. So what’s wrong with this picture?

Probably what’s missing is the perspective of a resource who has knowledge of business operations and is also an end user of the existing process or the new process being designed. A base level user who knows not only how the system actually works from the ground floor, but also knows about the undocumented bugs — and the work around to get from A to B — that the current system may have.

Adding base level users brings an important perspective to the requirements session and improves the quality of business information and project implementation. This resource is not only cost effective but typically has more availability than the stakeholders who wield the power to make business decisions.

The Benefits of Using Base Level Resources

There is a wide body of knowledge regarding User Centered Design, which emphasizes the value of using end users in the requirements process. After all, these are the people who are using the current solution that is being replaced or will be physically using the new solution on a daily basis.

Users involved in the design of a solution from the beginning understand how that solution works and are better equipped to use the solution after it has been developed. The User Acceptance Testing process is also enhanced when the base level / primary end user is involved in testing, satisfying one of the key goals of User Centered Design.

Hands On Knowledge of Operations

Base level resources are often essential to the requirements process because they have knowledge of ground level businesses operations that other resources are often unaware of.   Jason Prine, owner and  Principal Business Analyst at JPx2 Consulting Inc., describes these resources as the “folks who work in the weeds everyday … and are essential to any successful project.”

It makes a lot of sense: Having the appropriate operational requirements goes a long way in making sure the end product satisfies the needs of the user. This also prevents requirements from addressing only things as they should be rather than how they are.


Next week I’ll share some ideas on how to welcome and prepare base level resources into your requirements process.

Does your requirements gathering process routinely get input from base level users? What effect has it had on your team’s ability to quickly deliver business value?

Photo Credit: Angelo Juan Ramos