Tag: leadership

  • Addressing Technical Debt With Minimal Cost

    Addressing Technical Debt With Minimal Cost

    Organizations small and large move forward at an increasing pace. That makes it easy for things to be lost in the activity required to maintain our focus. These lesser tasks often include important deliverables that we say we will “get done later.” That is also known as technical debt. Put simply; these are the items left to do if we were to complete a project. When they are left undone, we are not able to claim a project or task is complete. This situation may seem easy to solve (just do the work), but it is not that simple. We have projects that are “good enough” that are super-ceded by higher priority projects. Here are some ways to address that technical debt without having to sacrifice those high priority projects.

    Research And Improvement Hours

    Many years ago, Google had a benefit for its staff that was shrewd in its approach. They set aside Fridays for personal projects for all the staff. These could be running with ideas for a side hustle or improving parts of the company or product. The organization sacrificed some time, but it ended up increasing the overall productivity of their workers. People will put in extra effort for things they enjoy. This benefit also made employees feel more ownership over the projects they worked on.

    There are many ways to adopt this approach to your situation. The easiest is to set aside a few hours each week for employees to work on whatever they desire. It could be training, chasing down a side project, or improving something they currently are working on. Those options may seem too open-ended. However, many employees will be willing to use that time to eliminate technical debt to feel better about the work they have done. There is also a morale boost that projects like this give to staff. The change in work focus allows them to do something different, which appeals to them more. They sometimes even find that there are parts of their job that they enjoy.

    Fill In The Gaps

    Many productivity suggestions include finding ways to tackle little things among the larger tasks. In our modern world of waiting for people to show up for a meeting, reply to an email, or waiting on vendor responses, there are many times we have “downtime.” These events could have us sitting and waiting without being productive while our path forward is blocked. When we have a list of little tasks available, those can be used to make use of that time. Fortunately, many technical debt items are a perfect fit for this.

    For example, documentation is often some portion of technical debt. In many cases, we can pick up and put down documentation projects fairly quickly. They have little intellectual requirements, and a rough draft of notes can quickly be captured. When these small tasks are made available to staff (or pointed out to them), there are opportunities to chip away at the debt list. Just a few minutes a day on these tasks can add up quickly over time.

    Technical Debt Side Projects

    It was mentioned earlier that a change in focus could be refreshing. Many of the technical debt items require a small project to address the need. This need can be in the form of data migration, simple automation, or data entry. All of these can be side projects assigned out to staff or for staff to choose. These side projects are typically one-offs where there is a lot of freedom to choose how they are done and the technologies involved. That can be a win-win for an organization. The staff member can use a side project to learn a new skill while the organization gets a needed item completed. In some cases, these side projects can lead to ideas for commercial products and other game-changing solutions.

  • Agile Patterns For Success – Team Work

    Agile Patterns For Success – Team Work

    I recently spent some time digging deep into the world of the Agile Manifesto and related methods for software development. This research included a look at agile patterns and anti-patterns. That is my focus in this article. There was an underlying theme that I kept coming across and do not see emphasized often enough. Spoiler alert, that theme is teamwork. There are many aspects of Agile that make it an effective way to approach software. However, the true power and ability to succeed comes from how it empowers the team.

    The Team Defined

    First, we need to be clear about how the team is defined in Agile. This is often the development team but can also include the scrum master and product owner. For our purposes in the article, we will focus on the development team. Many of these patterns make the entire team better. Nevertheless, I want to focus on the development team as they are the workhorses for our software project. These are the people that most impact success or failure when we build a solution.

    Unleash The Team

    It should be common sense that the biggest factor in any calculation is the one that becomes the largest focus. In sports, you hear about a player that “has to be stopped.” In politics and advertising, you hear about ket demographics. Businesses have flagship products and cornerstone customers. The odd thing is that we miss this concept when we consider teams. There may be an individual that is the most productive or effective on a team. However, the team is key, not just the individual. We have seen this played out in numerous contexts and multiple times over the years. Yes, a leader can make a sizable difference. On the other hand, most leaders are measured by how they motivate their team and increase productivity.

    The best leaders remove obstacles for their team. They reduce “red tape,” streamline processes, and empower team members. There is another way to view this. The best leaders unleash their team members to be the best team they can be. That takes us back to a focus on the team, not the leader. In case this example seems a bit abstract, managers are leaders.

    Professionals Are Professional

    The essential cog in the whole Agile Manifesto is that a development team is built of professionals. The members were hired because someone saw them as bringing value to the organization. Why would we throw that out once we place them on a team? It would seem to be common sense to trust these professionals to know how to do their job best. They know what their experience and skills are as well as where they work best.

    That leaves managers to listen to their staff and find ways to clear obstacles. It may seem trivial or lack glamour. On the other hand, it makes a statement that team members are valued as individuals. They are trusted to make the team the best it can be. Sure, there can be conflicts and a need for team members to learn how to work together. However, how often are we able to make other people like or trust each other? Managers are not miracle workers. Do not force employees into a hole. Let them define their role.

    Agile Patterns Are Not Suited For Everyone

    The second most important idea that needs to be understood in this pattern is that some teams are not suited to Agile. We need to have a team that has some experience, has self-awareness, and is driven to succeed. The team can develop these criteria as they go, but they need a starting point. A team full of similar or junior members will struggle. If there is not enough time for the members to branch out and differentiate themselves, Agile will not work. This concept goes back to that trust factor.

    When the team is trusted to “get the job done,” let them do the work. When you question whether the team can succeed, then do not burden them with Agile. They have to be able to make decisions and have confidence in those. Members that have no experience will rarely be able to do this. Instead, they will suffer from stress and lack of direction. Agile will be the worst direction to take.

    Agile patterns start and begin with the team. When you have a team that has the ability to over-achieve then turn them loose. Your trust and vote of confidence will be rewarded.