Technical Debt: In an Agile World

The phrase "agile development" has become common fare within the development community. As companies sought out new ways to innovate and optimize from within, Agile provided a new approach towards achieving productive results. Most developers have exposure to Agile in one form or another. Some companies have chosen to jump in while others have adopted select concepts. In either case, the Agile and Lean methodologies have produced frameworks such as Scrum and Kanban which have been well received. Although this might run the risk of over-simplification, Agile focuses on short cycles, fast results, and continued course corrections. After adopting this new mindset, an inevitable question arises. What do we do about technical debt? How does it fit within Agile? Does Agile eliminate or encourage technical debt?

Concerns about Agile's effect on long-term objectives have been raised, but it neither eliminates nor encourages technical debt. Although technical debt can be reduced with good practices, it is unavoidable. It cannot be completely eliminated. Armed with this knowledge, structure and visualization are necessary for proper administration.

There are many benefits to Agile, but arguably the most important one is the Silver Mirror. Agile forces companies to look within their own processes and it exposes troublesome areas. Before starting down the road of tackling technical debt, it must be properly tracked. Each situation should be entered in as a user story and placed into a separate "technical debt" backlog. There have been some arguments within the Agile community about entering technical debt as a user story. Simply put, if the change adds business value, direct or indirect, it should be a story. If it doesn't add value, then it is not truly needed. Let's leave the argument of "value" for another day. Think of technical debt as a feature set and treat it as such. Break the items down into immediate consumable stories with proper point allocations.

The two forms of technical debt, strategic and non-strategic, can include but are not limited to: code clean-up, restructuring concepts, unit test coverage, database problems, etc. Tackle debt for what it is, not who/what created it. All team members should be encouraged to contribute to the backlog. Advocate open conversation about code with team members to help drive out additional stories. It's important to remember that the backlog is never complete. It is always changing as new challenges arise while other debt is paid off. Like a garden, continuous grooming is key to a weed free backlog.

With a proper backlog in hand, it's time to engage the product owner. Technical debt is a fuzzy concept to most non-technical individuals; therefore, some education may be required. Additionally, a visual representation of the backlog must be maintained. One option is to chart the total number of points in the backlog from sprint to sprint. However this information is visualized, it should be reviewed on a continuous cycle. In a Scrum environment, the Sprint Review Meeting is a perfect venue. Another option is to place a printed version of the report on a Scrum or Kanban board. Keeping the backlog in the forefront is crucial.

The final step is implementing a strategy for tackling the backlog. As a member of the development community, it's a developer's responsibility to build a clear and tactful case (click here for more info). Depending on the company, this may require more or less conviction. Regardless of the situation, request a model that provides continued focus on reduction. If possible, place it on the product's road-map. The approach can manifest itself as a certain number/percentage of stories to be completed per sprint or release cycle. Concerns may arise about impacts to productivity as velocity and feature addicts foresee less direct results. This is where proper preparation pays off. When a product owner understands the concept and can sift through stories, he/she can assess a proper business risk/impact. This can be a helpful ally because as stories pile up, the impact will begin to outweigh the product's output.

Leadership in Software Development

Leadership within the software development industry can be a tricky area. All teams require some level of leadership. Promoting members within a team or organization is a practical choice, but skills so highly sought after in development don't always translate into good leadership. Developers are very logical and analytical. In the world of DiSC, which is a behavior assessment tool, most programmers fall into the D (Dominance) or C (Conscientiousness) categories. These individuals are direct, accurate, and task oriented. Although these traits might seem appropriate there are many other facets to leadership. Unfortunately, most individuals are thrust into leadership roles with little experience or guidance. Regardless of the situation, members in leadership roles must take the responsibility seriously. Leadership is a continuous journey of learning, teaching, and growing. Knowing this, how does one gain those abilities?

There are a few standard answers to this question. First, everyone receives the opportunity to learn on the job. Although this method works, the road can be difficult to navigate without a map. Second, ask for book recommendations about leadership. Everyone has at least one favorite they can recommend. Third, find a good mentor. Having a proper mentor is an invaluable resource. Don't be afraid to ask individuals if they have time to sit and talk about leadership. Most don't realize the accommodating nature of mentors. Sometimes they forget that those individuals were once in their shoes.

The last option is the most difficult to achieve because good mentors are hard to find, but there are other avenues. Recently, Chick-fil-A® held their annual Leadercast conference. This one-day event tackles leadership through the knowledge and experience of industry experts and seasoned veterans. One can travel to the actual event or view it at a simulcasted location. The 2013 event featured Jack Welch, Andy Stanley, Coach Mike Krzyzewski, John C. Maxwell, Dr. Henry Cloud, LCDR Rorke Denver, Gold Metal Olympian Sanya Richards-Ross, David Allen, and Condoleezza Rice. The sessions were a rich combination of presentation and interviews. Events like this create a sponging effect where years of knowledge and insight are soaked up. Documentation of each session becomes vital to encourage the flow of information, but still allows time for reflection and maturation. Below are a few highlights from the 2013 event:

"The key in complexity is to see simplicity."
Some also refer to the quote: "Complexity is simplicity done well." These simple references highlight the importance of finding simplicity in each task required.

"You don't need to be the smartest person in the room."
This is an important reminder for leaders. One doesn't need to answer all the questions or always have the best idea. Empower others to make decisions and utilize the outstanding skills of each team member.

"Yesterday is gone... let go of yesterday."
This is a reminder to not let the sins of the past control the future. Mistakes are only bad if they are not used as a tool for learning. Keep a consistent eye on the future.

"Get it out of your head."
Develop a system to keep track of things. This system must be outside of the brain in a notepad or task list. If left in the brain, one will spend either too much time or not enough on each task. The brain excels at tackling one item at a time.

"If everything is important, then nothing is important."
Leaders usually have an overflowing plate of tasks and responsibilities. It's important to have a narrowed focus, while inhibiting everything else. This applies to the team's progress as well.

"Rules don't lead."
Don't attempt to build and enforce rules. Work with teams to devise standards that everyone will hold themselves too. Rules are meant to be broken; standards are meant be exceeded.

Web Design: The Forgotten Advantage

Within the development community there seems to be a subtle disrespect towards the web design profession. Programmers view designers as disconnected Photoshop artists; furthermore, they consider designing to be a much easier job than programming. This viewpoint is unfortunate. Writing software is a team effort and everyone helps to make it possible. Developers must convert ideas into code, QA analysts must maintain high standards of quality, and web designers must ensure the software is easy to use and visually appealing. Without each of these working in concert even the best ideas will fail. Building an elegant website exposes a universal cognitive bias. People are drawn to beautiful, aesthetically superior things. This concept is referred to as the attractiveness bias. This concept permeates all parts of life. On the internet, this extends to the browser and websites being visited. People are not always aware of this behavior, but it is alive and well. A beautiful bride, a sleek new device, and amazing architecture all trigger this natural bias.

Some might say "Wait! There are many successful companies out there that don't focus on aesthetics." This is true, because the attractiveness bias is only a bias. It is not a golden unbroken rule. The concept of brand recognition allows well established products and companies to evade initial scrutiny. Consumers are more willing to provide a free pass, but even that has an expiration date. If a better product comes along, consumers will slowly be drawn towards it. The better product might be cheaper, easier to use, feature rich, or simply more aesthetically pleasing. Google is an excellent historical example. It started as a simple website that was more accurate, faster, and elegant than anything on the market. It beat out many established search engines (including Microsoft) and the rest is history.

Web design can and should be a product differentiator. At times a product is forced to build a "me, too" feature to match a competitor. In these situations a great design and experience can set software apart. Proper UI/UX can also help a new product get a foot into the market. Think of it as free marketing. The attractiveness bias will naturally encourage more people to investigate a product when a first glance is agreeable. On the web, visitors spend on average 2 minutes per web page. In this short time, visitors assert various judgments about a website. Arguably the most important decision they make is, "Was this web page helpful?" This drives many other feelings about a website, such as possible return visits and socialization amongst peers.

The late Steve Jobs recognized the importance of the attractiveness bias and used it as a guiding principle at Apple for decades. Even though Apple's products cost substantially more, the public still embraces the company. When people are asked why they like an iPhone or an iPad many retort with the same response: "It just feels nice." They are speaking about the physical design of the product, how it feels in the hand, and how the user interacts with the software. Even as competitors begin to offer better functionality in some areas, the broad audience of consumers are still reluctant to leave. This is the attractiveness bias at work.

One Point of Clarification
Although design is important, it is not a replacement for content or features. Even the most beautiful websites will fail if they cannot satisfy a user's inquiry. The attractiveness bias is only meant to draw one's attention, not keep it. On the other hand, sometimes companies achieve success on merit or market timing alone. This should only be viewed as a short term gain. Markets are always shifting and competitors are always lurking in the midst. Web design through proper UI and UX is important because, when all things are equal, beauty wins out.

Don't forget to take some time to thank each designer for their important contribution.

Let's Start By Goofing Off

There are times when work is, well ... a lot of work! The stress of important deadlines or goals can be overwhelming at times. Sometimes the "daily grind" can also have a sapping effect on overall productivity. How can we reverse this trend? By goofing off at work, of course! For some, this might sound counterintuitive because the institution of "hard work = success" has been a mainstay for decades. Although hard work does get the job done, the satisfaction of employees cannot be lost in the conversation. Software development can be a very mentally exhaustive profession. Developer burnout is a real topic that should not be ignored or avoided. Holistically programming is a fun and exciting profession, but some lose that spark when software development and business collide. Having fun at work can re-ignite that spark and change a person's focus and perspective.

Having fun in the workplace can take on many forms. For instance, a cheap Nerf gun such as the Jolt (only $5.99) can create hours of fun for employees. Nerf wars can become legendary while they build camaraderie. Why is that? They allow for impromptu battles where everyone can participate with no prior skill required. These events create a much needed pause within the work day to let one's brain reset. Scooters, Frisbees, and dodgeballs also encourage an environment of spontaneity. Providing a chess board, ping-pong table, Nintendo WII, online games (such as Call of Duty), or a basketball net are great team activities. These can be encouraged over lunch or after work. Additionally, setting up tournaments allows for cross department interactions and creates a healthy form of competition.

Let's not get lost in only physical activities. Social activities such as an ice cream social or a pizza party always lift spirits. Although these activities might celebrate an achieved goal, they shouldn't always be connected. The reason can be as simple as "It's Tuesday!" or "Because it's a nice day outside!" Monthly celebrations of employees' birthdays is another great reason to pause productivity. Showing support for fun activities is vital. Individuals in management positions should participate as much as possible. This can allay fears that the company does not condone these actions. Setting up a "fun committee" can further show the support for a proper work-life-fun balance. If support is difficult to find, focus on non-company sponsored activities and outings with co-workers.

Fun can even manifest itself in very small ways. Building a "wall of fame" where thank you notes, fun announcements, and personal/company accomplishments can be displayed helps people feel connected. Even the encouragement to decorate and individualize an employee's workspace can create an uplifting of spirits.

Viewing distractions as slowing productivity is unfortunate. Stopping to have fun is like a sling shot. Things slow down temporarily but accelerate must faster when people return to work. Having fun not only relieves stress but it reminds people they are valuable and important to the company and each other. Embracing fun opens new forums for creativity, discovery, and learning; furthermore, enjoying one's job is the best retention policy!

Multitasking is Bad?!?

Denouncing multitasking might sound crazy, but let's put some context around the statement. Multitasking made the modern computer a viable solution. The desire for people to multitask in business is a natural progression. Within the technology industry it's in very high-demand. Tackling more tasks leads to faster results, right? Also, it's a great way to impress a manager, isn't it? Multitasking might sound like a no-brainer, but modern research has provided interesting insight into this topic.

Let's step back and define multitasking. It is "performing more than one task simultaneously." Although that might seem obvious, multitasking also includes switching back and forth between tasks. Some people might say "Hey, wait! I'm great at multitasking!" For those individuals, I encourage deeper analysis on the quality of output and time required for those tasks. In the past, many believed multitasking was a good way to increase productivity and it was a skill that could be taught. This resulted in many confused, disoriented, frustrated, and burned out individuals. Some researchers suggest that multitasking reduces productivity by up to 40%! That might seem high, but even 10% less efficiency is still moving in the wrong direction. Why is this? Multitasking impairs cognitive abilities by overworking the brain. It creates extra stress that, although not always visible, takes a toll on the human body.

Rapidly completing different tasks and/or moving between multiple tasks creates a drain called "context switching." This is the wear and tear of continuous readjustment. As one moves between tasks the brain attempts to maintain multiple cognitive states at once. Unfortunately, the brain isn't built for this because it struggles to inhibit distractions. Some simple tasks such as listening to a conversation and writing down a note might seem feasible, but that is based on complexity. The attention required for a task is directly correlated to its complexity. In programming there are few tasks that do not require a high level of concentration. Insufficient attention during the designing, programming, or debugging phases all have negative repercussions. Context switching is further compounded as a programmer moves from project to project, feature to feature, and language to language. Each one requires different information which adds further mental load and increases the time invested.

So how do we fix multitasking? We do more with less. We need to identify multitasking situations and break the habit. We need to focus on one task at a time. The following is a brief list of suggestions.

• Reserve a time during the day to be "wired in." This can be accomplished with business hours or designated quiet time. This creates low and high periods of distraction. Be sure to take on lighter, easier tasks during potentially high distraction periods.
• During high cognitive load find ways to reduce distractions. This can include setting a smartphone out of reach, shutting down email for a while, etc.
• If distractions are unavoidable, stop working on the current task and give the distraction one's full attention. Once it has been resolved, go back to the previous task. Do not try to balance both activities.
• With the exception of debugging, try to limit the exposure to multiple technologies at once.
• Try to avoid back-to-back meetings. Downtime is important for concept hardening.
• If the temptation to multitask is due to a lack of time and an abundance of tasks, define what is important by prioritizing tasks. Also, review if any obstacles can be eliminated or tasks offloaded.
• Maintain an ongoing list of tasks. The impact of a distraction can be mitigated if it can be offloaded to a future task.

Digging Into "Fail Fast, Fail Often"

In the article, "Psychology and the Agile Methodology," the concept of embracing failure was put under the microscope. In summary, although agile encourages failing fast and often, this can be a difficult concept for people to accept. This predisposition is due to modern expectations and the barriers pre-built into human nature. Most educational systems indoctrinate their students with the mental equation "hard work + time = success" and the "failure is not an option" mentality. There are many positives to this approach, but it can create unintentional mental roadblocks towards failure. In this article, let's look at failing fast from a slightly different angle. This refreshing direction might help some understand and embrace one of Agile's core concepts a little easier.

Telling someone that failure is a great way to succeed might sound like a fools proposition. This is due to the negative memories and emotions that failure rekindles. Some of the most unassuming products were a result of failure. The following list highlights a few:

• It took Thomas Edison thousands of failed attempts until he found the correct filament for the light bulb.
• Kleenex tissues were originally created to help women remove make-up.
• WD40 gets its name from the number of attempts to get the water displacement formula correct.
• Post-It notes were invented to replace bookmarks. Their idea was a failure.

How did the previous list of products succeed? They learned from their failures. The phrase "Fail Fast, Fail Often" is unfortunate because it sets the wrong tone. It should be "Learn Fast, Learn Often." It's not about failing. It's about learning. The purpose of failing fast is to learn and adjust course more quickly. This saves time and money. The Lean methodology take this concept one step further with the statement "Think big, act small, fail fast; learn rapidly."

Fully embracing this concept is not easy, but the rewards are palpable. Try it, have fun with it, and don't forget to learn/grow. Although books might help a programmer expand his or her knowledge, failure creates seasoned programmers. This makes them more valuable to their company and the industry. Experienced developers are hired not for their skill alone, but for their vast knowledge from prior experience. Being able to avoid pitfalls and provide expertise to others is where developers can flex their muscles.

As failure is embraced it has a tendency to find its way into programming architecture. Companies such as Google took this concept and used it to become very successful. In the early days, they purchased thousands of old computer parts and built make-shift servers out of them. This idea was unheard of at the time. They built these servers with the assumption that many would fail. But armed with this knowledge, the software team created a "fault tolerant" system that recognized failure and gracefully continued without impact to its customer base. They solved an expensive problem with a cheap solution. They used failure to their advantage.

The Sharp Truth About Contour Bias

Sometimes the design of a web page just seems off. No one can put a finger on it. The layout of the screen makes sense. The separation of data is well proportioned. There isn't a lack or overuse of color. Yet, the web page doesn't feel inviting. This might be the fault of human nature and a psychological force called Contour Bias. The principle states that humans have a tendency to favor objects with curved contours over objects with sharp angles or points. Knowing this preference, take a second look at the web page. HTML elements such as divs and spans are "squarish" by default. Does the design have contours or simply lots of boxy edges? Does the site feel manufactured?

Some might ask, "Why does this matter?" or state that the concept is overrated. Contour bias is not something that people consciously think about or control. It is pre-programmed into our DNA. Humans like objects similar to themselves. This is why people are drawn towards nature. Take another look at nature and play a game of "Where's Waldo" with sharp angles and points. The contours will far exceed the sharp objects. Why do we like contours? It all starts in the amygdala. This is a region of the brain where fear is processed. It considers sharp or pointy objects potential threats. The amygdala does not rationalize the purpose of an object. In contrast, soft edges do not pose any threat and therefore are preferred. This influences how people appreciate the aesthetic nature of objects. Implementing contours softens a design and makes it easier on the viewer's eyes.

So everything needs soft edges or rounded corners, right? Actually, no. The contour bias only works on objects which are emotionally neutral. Objects which already have an emotional association are not easily swayed. Additionally, contour bias can be used in conjunction with angular objects to attract a user's attention. Since rounded objects are emotionally positive and aesthetically pleasing, an angular object within them will have a natural pull. Thanks, amygdala!

One easy way to introduce contours on a web page is rounded corners. IE9+ and modern browsers support the CSS3 property "border-radius." This feature allows custom radii to be applied to common objects such as divs and spans. CSS3.info has an excellent article on the use of the property. Although rounded corners are useful, it's important not to overwhelm a design. Too many rounded corners or corners with large radii can result in a trivial appearance. It's always important to vet designs with feedback from customers and other respected resources.

Click here to view an excellent study on contour bias.