Subscribe via RSS Feed

Tag: "alignment"

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.

December 6, 2010 | 0 comments | View Post

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

November 29, 2010 | 0 comments | View Post

Iteration Zero: Reduce Risk Before You Begin the Project

Reduce Software Project Risk Before Construction Starts

Sunglasses-and-RoadmapLast week we talked about the level of planning required to ensure that a journey (whether a travel adventure or a software project) be enjoyable, problem free and capable of delivering better results.

In the first stage of planning for our journey, we identified where we wanted to go and how we thought we’d get there. In software development, this can be thought of as business definition and understanding the business objectives. The second stage of preparation for our fictional journey — studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero.  This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Iteration Zero sets up the groundwork for construction by implementing the reusable patterns and components in the application architecture and preparing the environment for a development team to be effective. This phase helps to remove the traditional Just-In-Time environment setup that often occurs in the construction phase. By adding an Iteration Zero, you are essentially allowing for time to be utilized more effectively and predictably during the construction phase.

One perception about the phrase “Iteration Zero” is that it implies an agile style of development. This is not necessarily so. The practices in “Iteration Zero” have been used successfully with several different development methodologies.

One of the major dependencies for an effective Iteration Zero is awareness of the success criteria of the project defined and agreed to by the business. They also need to be understood by the technical team(s) before the Iteration.

Creating a Forum to Ask Questions and Learn

One of the most important elements for executing Iteration Zero is the Workshop. The Workshop allows the team to see how the software is going to be developed from a process perspective. Additionally, it helps the team become familiar with the technologies, components and patterns implemented and added to the code solution. This begins the process of the team becoming immersed in the construction process.

In order for the development and quality teams to be effective in Iteration 1, the Business Analyst should begin creating the Business Rules Documentation. Iteration Zero provides them with a jump start from both the development team and the quality team.

Iteration Zero can also be used to identify risky technical aspects of the system. These risky elements should be studied to form a mitigation plan (during Iteration Zero) to learn as much as possible, as early as possible.

Hit the Ground Running

Although there are ways to prevent a project catastrophe, most of us have still seen at least one project land in the dumpster for a myriad of possible reasons. While there are risky elements outside of delivery that can hurt a project, adding and enforcing Iteration Zero is a great way to make sure your next journey goes faster, behaves more predictably, and adds more value to the business.

How is your team using Iteration Zero?

Photo Credit: Thomas Beck Photo

November 22, 2010 | 0 comments | View Post

Software Requirements: Are The Business People With You?

The Role of the Business in Driving Software Requirements Definition

Many of us believe that the single hardest part of building a software system is deciding precisely what the business needs. No other part of a project has as much impact on the final outcome as requirements definition. Yet, the requirements process often ends up as the area most lacking in best practices.

I recently participated in a survey of IT executives at a Chicago trade conference. Some of the results of the survey were what I expected and some were surprising. But either way, the results are very relevant for teams looking for perspective on their own development practices. This week, I’ll report some of the basic findings of the survey.

Respondent-Roles-1

Most of the executives in the survey recognized the importance of accurate requirements and admitted to routinely struggling in two areas: Connecting with the business and managing requirements throughout the development cycle.

Key Survey Findings

  • 94% of respondents acknowledged that the quality of requirements is a leading factor in the success of their software projects.
  • Over 70% acknowledged that there is room for improvement in their requirements practices.
  • 75% agreed that better articulation of business and IT roles/responsibilities in requirements gathering would go a long way toward improving project outcomes.
  • While most admitted that the business has at least some input with requirements definition, requirements are often unclear.
  • Over 80% of respondents indicated that they do not learn about missed requirements until too late in the project development cycle.
  • Only about half of the respondents felt that business and IT teams have a consistent view on project status.
  • Over one third of respondents stated that progress is not consistently tracked in business milestones, resulting in rework and missed deadlines.

 

It’s Unanimous: Business Involvement Has a Big lmpact

It is not uncommon for business stakeholders to “throw their requirements over the fence” and expect to come back later to a successful working system. In practice, however, this approach leads to rework, project delays, cost overruns, and other disappointments.

Although the degree of business involvement varied within the survey, respondents overwhelming agreed that when the business is directly held accountable for clearly defining their needs, project outcomes improve. Respondents also mentioned the need for better articulation of business and IT roles and responsibilities in the requirements process.

ssp_temp_capture

Business Milestones: Now You See them. Now You Don’t.

Another big area of concern for survey respondents was managing requirements throughout the project.  Most agreed that project metrics must define progress and value in terms the business understands and appreciates. Approximately 50% reported that business and IT teams in their organizations share a consistent view of project status.

ssp_temp_capture2

Another important benefit of using common metrics is more awareness of when requirements are due. All too frequently, IT learns about missed requirements too late in the development cycle.

In the case of the survey, all agreed that it is critical to find out as early as possible whether key requirements are missing. However, most respondents indicated that they become aware of missed requirements during User Acceptance Testing (UAT) or after deployment.

What level of commitment do the business stakeholders have in requirements definition in your organization and how does this impact project outcomes?

Next week, I’ll write about some of the steps you can take to pinpoint the areas of your organization most likely to interfere with your ability to satisfy business expectations.

October 26, 2010 | 1 comment | View Post

How Internal Pressures Can Implode an IT Organization

Roadmap with cities and distances

Know where you are today. Be clear on where you’re going.

Last week, I talked about some of the many organizational pressures that can implode an IT team.  In fact, some of these may apply to other parts of the organization as well.  This week, I’ll take a look at an approach that can shed light onto solving these issues.

It’s All About Perspective

The ability to look inward in a truthful, non-self-serving manner is a phenomenal attribute to possess.  The same holds true when looking at an organization that you’ve helped create.  Allowing myself to pull out from working within the team to working on the team has afforded me valuable insights.  This ability to change perspectives is the best way to look around and objectively survey the landscape.

Once I change my perspective, the focus becomes applying a very simple approach that has been invaluable to me over the years.  Three steps: Where do we want to be, where are we now, and how do we get there?  In that order.

Where Do We Want To Be?

What may have worked well a few years ago may not be the optimal solution for today.  This is simply because our surroundings continually change.  So, resetting the baseline and re-establishing alignment can be a continual process.  Understanding how the organization will be measured and knowing what problems you’re trying to solve today will be the starting point to crafting your solution.  Not knowing where you want to be is like driving a car with a blindfold.  You’re bound to hit something and you won’t get anywhere.

Getting the right group involved is a great way to start the alignment process.  During that process, it may become clear that others have different agendas, goals and ideas on how something should be implemented.  Facilitating this group alignment on where the organization needs to be and establishing a common vision will allow everyone to head in the same direction.

This is also the time to make sure your goals will solve the problems as they are perceived today.  If silos exist or technology is scattered as I described last week, then perhaps one of the goals is to look at how to create horizontal technologies that can be shared amongst the silos.  The goal could be as simple as creating a shared platform which has an added benefit of getting the teams communicating more.

Where Are We Now?

This is where taking a step back is the most helpful.  Being immersed in something for an extended period of time gives us a single perspective of what we know to be true.  Because many teams have a lot of knowledge about what already exists (after all, they live it every day) it can be tempting to breeze through this phase.  Do not breeze.  Do.  Optimally, document the enterprise architecture of the technologies, processes and roles that exist.  You will most certainly uncover some interesting aspects of your surroundings that were previously based on assumptions.  If you have found this to be true in your experiences, please share in this blog discussion!

How Do We Get There?

This is the part where a roadmap is created.  This is typically the most difficult phase.  It has been equated to creating a solution to changing the tires on a moving race car.  It can be difficult, but do-able.

Not only is this the most challenging phase, but it’s also my favorite.  This is also the same phase where you should consider inviting the solutioning team from the first phase. They are invested in the destination, so it only makes sense that they should have some passion and energy around getting everyone else there.  Don’t go it alone.  Following this approach, you will begin seeing a team start to craft a common vision and a plan that is designed to accomplish what may have previously been thought as impossible.

The Bottom Line

Continually measuring and re-aligning has helped me immensely in preventing my teams from imploding.  This is not a tool that gets used once and discarded.  It’s designed to be used continually.  The frequency will be determined by the velocity of change in your organization.

Discussion

  • How have you had to cope with organizational pressures and how did you get started toward resolution?
  • How did you engage the right people for the solutioning phases?
  • What obstacles did you overcome?
  • What other pressures have you seen implode or hurt an organization?

Photo Credit: Goldemberg Fonseca

October 5, 2010 | 0 comments | View Post

How Internal Pressures Can Implode an IT Organization

Implosion1Last week, I talked about some of the organizational mindsets that lead to misalignment within an IT team. This week, I’ll look more closely at some of the specific pressures that can cause problems for the team and impact IT team performance. These are based on some of my own experiences in my role as an Architect.

Team Silos and Lack of Communication

Larger IT organizations often contain splintered groups that focus on either specific functional or technological areas. These groups can easily become silos. This can result in redundant efforts and solutions, dissimilar technologies, or disjointed entry points for business requests. More importantly, these silos may not easily communicate, inhibiting collaboration. Probable result: If a technology group makes changes and deploys, they run the risk of clobbering another team’s systems. Usually, they won’t know about it until production issues arise. The teams are neither in alignment on technology, people or process. This has the potential to bring progress within the IT organization to a standstill.

Pressure to be Bleeding Edge

Have you ever witnessed a technology team adopting new technologies for the sake of being bleeding edge? This desire to be bleeding edge is another factor that can cause pressure on the IT team. There are certainly many cases where new technology solves problems and creates additional efficiency. But what about the team that wants to utilize a new technology only for the sake of playing with new technology? It may perform the same function as the current technology, but just does it in a different way. Is there any value in that?  Does it help attract talent? Can it be adopted and integrated without any additional effort? Does it position the team to becoming more nimble? Does it align with long-term objectives of not only IT but the organization as a whole?

If some members of the team answer “yes” to these questions and some answer “no”, then the use of some new technologies can cause misalignment on the IT Team.  They may either have conflicting agendas or may just be out of alignment with how they need to accomplish the task-at-hand.

Teams That are Always Stretched

Stretching from time-to-time can be very healthy. It keeps a team aware of their limits and capabilities. It also helps a team to gel and rally around an effort that has a sense of urgency. Then, during the non-stretch times, it allows the team to think strategically, place more focus on refactoring which will allow it to scale for the next stretch. On the flip side of that, a team that is never stretched can have morale issues and may not deliver value at the velocity that is expected. But while the resulting atrophy isn’t healthy, teams that are always stretched are in worse condition. Stretching can result from task overload, following an antiquated process, working with unfamiliar technologies and working toward an unrealistic goal.

In any of the situations above, design and development decisions are usually made with the highest priority being: “Get this pain away from me as quickly as possible”. Decisions consistently made in this mode, usually create technical debt. If an IT organization consistently resorts to short term fixes, it compromises its potential and future progress and we begin to see implosion at the organizational level — not a sustainable plan.

What are some of the pressures has your IT team faced recently?

Next…

Next week, I will delve into some of the approaches that can be used to rectify these situations or prevent them from happening in the first place.

September 28, 2010 | 0 comments | View Post

How Internal Pressures Can Implode an IT Organization

When an IT Group Unravels

Many of us have gained valuable insight from articles about lack of business-IT alignment. But what about an IT organization that is misaligned with itself? How prevalent is this and what causes it to happen? There are many kinds of organizational pressures that can cause this to occur. Over the next two weeks, I will reveal how IT can implode from within.

This week, I’ll talk about what leads up to an IT organization becoming internally misaligned. But first, let’s define what “misaligned” means. It means that groups or individuals think that they are all focused on the same agendas, have the same motivations and are marching to the same objectives and goals, but in reality, they are not.

Think of a deep sea submersible designed to withstand immense pressures.  During a deep dive, all it takes to implode that submersible is a single breach that isn’t discovered until it’s too late. Similarly, an IT organization may be designed to be resilient to pressures and stretching, but may have weaknesses that eventually reveal themselves and result in implosion.

So What Causes an IT Team to Become Misaligned … With Itself?

I’ve been hearing a lot lately about how IT should actually be a part of the business team and not exist as a separate entity. In reality this is not actually practiced in many organizations. For the most part, IT exists as a separate, autonomous organization. Given that this is the norm today, this post will assume that situation.

There are cases when business provides exactly what an IT organization needs to deliver value. Yet, despite that clear direction from the business, the technology group still fails to deliver. What resides at the core of this issue? Why do we still see technology groups with silo mindsets, separate agendas, different motivations, and  little, if any, insight into what makes the other groups tick?  I believe it all starts with a lack of understanding of how to unite these technology groups and individuals into a single, cohesive and effective functioning organization.

Separate, non-transparent, or seemingly conflicting agendas and motivations can kill any alignment within a team.  Like functional groups looking to gain a competitive advantage or reduce operational costs, the technology groups are trying to manage technology costs in real-time, reduce risks, deliver value and leverage centralized technologies to support and keep pace with functional changes. Notice any real similarities in what drives groups described here? Neither do I.

I’ve never met a technology group that didn’t have the desire or best intentions of providing superior value to the business and the company.  Unfortunately, passion alone will not cut it in today’s market. In fact, this passion can actually be the catalyst that exposes the IT team’s potential to implode. And that’s a good thing. It allows us to see the signs before the damage actually happens.

Is This IT Team Ready to Implode?

Have you ever been in a situation where the business summoned IT to deliver some seemingly ambiguous value on some seemingly arbitrary date? Or perhaps the business drivers weren’t communicated to everyone. You might have even wondered why an initiative was chosen and given to IT in the first place.

An IT organization may hear something like this: “The business has a strategic initiative to enable our partners to integrate into certain aspects of our operations. This will allow us to reduce costs by 3%. We need to provide them with access and limited control over certain portions of our systems and we need it no later than March 15th.  IT, please deliver this objective and start development next week.”

In this scenario, commitments were made without the technology buy-in. Technology teams often ultimately say, “We will start next week and figure it out as we go. It sounds aggressive but it should be ‘do-able’”.  The functional group interprets this as a commitment from the technology group. However, without more clarity around a vision of success for this project, the business will probably not get the value they need to satisfy their agenda. And, IT will most likely be held accountable when they don’t deliver. Everyone loses.

Although the IT team had a desire and passion to help, they also set themselves up for implosion on the project. They accepted the cards they were dealt without saying “In addition to what you have provided, we need X to be successful”.  In other words, they set themselves up for failure rather than move forward informed and empowered to deliver on expectations.

Next week, I will dig deeper into some of the specific pressures that can cause a team to implode and how to meet the challenges.

Has your team ever come close to implosion? What cause did you identify?

September 21, 2010 | 0 comments | View Post

Business/IT Alignment: 4 Ways to Win Admiration and Respect

handshake-300x158Business/IT Alignment: How does an IT shop with talented individuals, the latest technology, millions of dollars in payroll, and a history of developing business centric applications become so disconnected from the business that they disappoint the very teams who depend on them? What can be done to close this gap and turn this relationship into a trusted partnership? While there are many ideas on how to address this difficult situation, in my experience there are three key approaches IT can use to rebuild burnt bridges and stop unconsciously undermining their business partner relationships.

Learn to speak a common language

In order for Business/IT alignment to occur, IT must adopt the same terminology and language of its business users. (A claim is a claim – not a bill or a statement). IT also needs to be aware that a complex project plan does not communicate meaningful information to the business. Deliverables need to demonstrate real business functionality, QA-passed and ready for review. The more often progress is shown the more involved your business partner gets. If communication is the basis of a good partnership, then a common view of success is the necessary foundation for delivering on business expectations.

Create a common view of success

One of the most disruptive events we can have when working with a partner is discovering you’re not working towards the same goals. Both IT and the business problem owner must work together to establish common success criteria for a project and eliminate assumptions.

Creating a common vision is a process that includes the problem statement down to a detailed description of the individual items to be produced for the solution. In many cases lengthy documents and general conversations are not enough. Pictures are worth a thousand words when developing product descriptions … even for the “simple” reports.

Spending time to develop the detailed components of a solution requires a time commitment from your business partner to get involved. This is the only way to reduce surprises that lead to project disappointment and rework in the development phases. The common view of success needs to capture the results of this cooperative effort in a manner comprehensive enough to help determine project scope, sizing and estimating. Once this process is perfected, it can be accomplished in as little as three weeks for projects up to a year in length.

Allow your business partner to manage change

In order for the project plan to not interfere with business decisions, individual items in the plan must include all costs and efforts. This gives the business the ability to effectively react to change and unexpected events. For example, if three months into a project a business is acquired or sold, the business partner should be able to easily substitute new objectives with the same cost and effort for the original ones.

Negotiate the plan with your business partner. Once the time and effort required to deliver each scenario is understood, the option to manipulate plan elements like building blocks allows the business to determine priorities and set the scope for the project.

Be open and demonstrate your integrity

No Business/IT partnership can survive ongoing disruptive surprises. Rather than trying to make up for problems or delays, communicate them and share options to schedule, resource or scope issues when they happen.

If accurate sizing and estimating best practices are not in place and original estimations are incorrect, IT needs to inform the business as soon as possible and reforecast the release plan. IT cannot afford to jeopardize its ability to deliver business value by hiding information or trying to take drastic measures to make up for project execution problems.

Utilizing these practices can help IT predictably deliver measurable business value and help make Business/IT alignment a reality. While this is not something done overnight, your commitment to building a true partnership with your business partners will go a long way in bringing predictability to a process plagued with missed expectations and cost overruns.

What practices have worked best for you to to enhance your relationship with the business?

feature photo credit: dotbenjamin
post photo credit: Aidan Jones

August 10, 2010 | 0 comments | View Post
« Previous Page