The term bankruptcy has a bad reputation in the business world. This is not surprising considering one definition of it: utter failure or impoverishment. Another definition centers around an inability to repay debt, and that’s the one we want to focus on here.
There are two kinds of debt in the average software project that an agile team will worry about. The first is technical debt and the second is logistical debt.
Technical debt refers to the concept of work required to make a change which is not directly related to the change being made. Another way to view it is by counting work not done now as technical debt for later. This is generally in the form of choosing an easier but more limited solution to make a change now which makes altering the functionality later take longer than if a more complex solution was implemented.
Logistical debt, as I’m using it, is the number of items requested over time, the documentation around the product, process enhancement ideas, and any metrics that have been collected over time. These might appear as a large backlog, large pdfs, or charts that go back more years than the team has been in its current form.
Just because we’re talking about debt doesn’t mean it’s all bad. As with many choices in a project, there are benefits and risks on both sides of the equation. Preventing debt generally requires longer lead times at the outset which can slow a product’s time to market. Taking on some debt may be necessary to get moving on a new product. However, letting this debt grow unchecked can result in a product which it doesn’t make sense to improve in the future, resulting in lost customer confidence when the product is replaced instead of enhanced.
Technical debt isn’t a new concept. It slows a team down over time. The more that accumulates, the more it slows the team down. In extreme cases, which are more common than we like to admit, it becomes so difficult to make changes dropping everything, and starting over is actually easier and faster. Except it’s never easy to drop everything and start over. Between sunk cost fallacies and the elusive solution just around the corner realizing a product has reached this point is extremely difficult.
Preventing technical debt is not a completely solved problem, but there are ways to limit it. From automated testing to rigorous standards for implementation it isn’t impossible to make things easier to change later. In software projects specifically creating functionality as components that can be independently tested and validated through automation means making a change will result in fewer hidden consequences. Any problems will immediately show up in failed tests and tracing them back to a root cause should be much easier than tracing a random bug.
Logistical debt is something I have not heard a lot of people spend much time on. This is interesting to me because the concept of backlog bankruptcy, one great tool for dealing with it, is not new. Logistical debt isn’t only about a huge backlog though. If updating a feature includes months of revising documentation there could be a problem. When senior leadership pulls out a velocity graph going back five years and has questions, there definitely is a problem.
Backlog bankruptcy is the concept of deleting a backlog, or a large portion of it, without exception. It is generally done when a team or organization realizes and accepts that the backlog is larger than they will finish in any reasonable amount of time or that there are many items on it that are no longer relevant. While one may argue it will likely just grow that large again, in practice things that really weren’t that important don’t make their way back onto the backlog and people in charge of the backlog tend to become more protective of what is allowed onto it after this experience. Even if it grows again, the cognitive relief and long lead time before it grows again are generally worth it.
Other types of logistical debt can be dealt with in similar ways. If documentation has gotten out of hand, try splitting it into smaller pieces or, even better, simplifying it greatly. (Perhaps it’s a sign your solution has also gotten too complex?) Limit metric tracking and reporting to relevant time frames, and make sure people understand what the metrics they’re tapping into mean.
Regardless of what kind of debt is weighing your project down, declaring bankruptcy on it and moving forward fresh is an option with considering.
If your team or organization is struggling I can help. Contact me now to set up a free initial consult. We’ll discuss what the symptoms are and come up with a plan of attack for me to help diagnose the true problem and devise a solution.
In the United States asking for help is often seen as a weakness. Telling your boss you want to bring in someone from the outside to help you can feel like career suicide.
Unfortunately there is often a large difference between “this is a little more than the team/I can handle” and “we can justify a full-time person for this.” When a team or person first gets to where things are getting to be a bit much there is often a desire to handle it. This might be fear of looking unqualified, false confidence, or any number of reasons. The problem is often compounded by how this state can sneak up on people. One day the workload is fine, and the next it’s six months later and despite 60 hour weeks everything is falling behind.
The good news is that this perception is changing, and in many places bringing up the idea of an outside consultant to help with short or long term needs or goals is no longer problematic. This can take many forms, the most common of which is a person to do front-line work on a part time basis. Another is to hand an entire small project over to another firm.
while there’s not much more than time and repetition which can help people see asking for help as a sign of strength instead of weakness, I can go over some ways asking for help can be beneficial to teams.
The most common way a team will discover the need for assistance is when the workload in general gets too big. This is a pretty easy problem to solve. Initially, an intern or part time contractor is a way to get more hours on a project. If the need is large enough, an other person could be hired to the team. This will reach a point of diminishing returns, a team can only get so big before it should either be split into two, or a second one started. This type of help is generally needed as an organization grows and can be seen as healthy in all regards.
Another way a team find a need for help is when something goes wrong. The number of way something can go wrong such that a team needs help are innumerable. Some are good, some are bad, but that part isn’t the focus of this post. What kind of help the team needs and how to get it is. The answer here is, it depends. It highly depends on what went wrong. Trying to boil this down I’ll leave us with three scenario’s. Thing that went wrong was driven by the organization. Thing that went wrong was from within the team. The thing that went wrong was outside of both the team and the organization’s control.
When something goes wrong and it is driven by the organization the team loses trust in the organization. Any attempt by the organization to fix the problem will be met with skepticism. At this point the organization can try to hand everything over and stay out of the way. This may allow the team to fix what went wrong, but it won’t restore any trust in the organization. The relationship between the team and the organization will remain tainted going into the future. Instead of just handing things over, a better approach would be to bring someone in from outside to not only help the team address what went wrong, but why it went wrong. If possible, the team should be part of choosing the outside person to bring in. The organization needs to take this seriously, and make moves to fix problems outside the team which led to what went wrong. This will help not only fix the problem, but also restore the team’s trust in the organization. It also set the organization and the team up to be stronger going forward.
When the problem starts from within the team the organization is in a better place. It is telling that the team was unwilling to seek help from outside of itself as things were falling apart and waited until things went wrong. This comes back to trust. the team may not trust that the organization is willing or able to help them. In any event, once things have gone wrong and the team acknowledges the problem comes from within, it’s time for the organization to help the team. If the team cannot identify the problem they need someone from outside the team to come in and work with them to find it. If they can identify it, but not fix it, they again need someone from outside the team – though in this case it may just be support to make something happen. If the team can identify and fix it, then the organization may just need to give them space. Teams grow through adversity just as well as they grow through other means.
Problems outside both the organizations and team’s control are rare, but 2020 showed us they can happen to any organization. Whether help from outside the company is needed in these cases or not really depends on the type of problem, and the reaction of the team and organization. If the problem is within the organizations expertise, they may be fine without help. If the problem is outside of the organizations expertise – power grid problems at a restaurant – they may need outside help. Even if the problem is within the organizations expertise, it may be at a scale that requires outside help. If the problem has the team or organization frozen whether in overwhelm or indecision, then just as above some outside help may be needed.
The best way for a team to recognize they need help is simply knowing they don’t know something or can’t do something. Having the ability to call in an expert, even on a short-term consulting basis, is the sign of a strong team in a healthy organization. This is always a better solution than waiting until something goes wrong. If your teams have never sought out help it may be time to examine why. Often it’s not that help, even in the form of money for training, isn’t wanted but rather that they don’t feel safe enough to ask for help.
The idea that Agile means no planning has more or less been eradicated by now. However, many people are left wondering what level of planning Agile processes, methods, or frameworks need.
It depends. – Every consultant. Ever.
Many “out of the box” Agile implementations you can get training and support implementing have specific guidance on what level of planning they require. The same can be said of many more generic approaches and frameworks. In a more general sense, practitioners such as myself enjoy the phrase “just enough to deliver value next sprint” or something similar. Of course, none of that really helps most people reading this right now.
The goals of planning in an Agile context are not all that different than planning in a classic context. We need to set expectations, guide efforts, control risk, and deliver value.
A product owner’s priority is the product. They want the best product possible, as fast as possible. The development team wants everything defined well enough for them to deliver a quality product, and the time to deliver that product. The customer wants value. The company wants profit. Everybody involved has some expectation, and those expectations need to me be managed. Proper planning allows all voices to be heard, a common vision to arise, and a sustainable pace to evolve.
For work to effectively result in real value there has to be a roadmap. Without knowing what is valuable, nobody knows what to work on. During planning the entire team works together to set that roadmap. Without this, people could work on functionality that is at odds with each other, resulting in bigger problems as opposed to solutions.
A big part of project management is risk management. In classical project management, this meant sticking as close to the plan as possible lest time or money slips out further than can be dealt with. In agile project management, this often means not planning things to such a detail that changing direction becomes problematic. The idea is to accept the risk of change rather than control it.
Even today everybody understands what the “death march” of a project is. Some date has to be met, no matter what. The pace is constantly quickened as issues come up to ensure the timeline doesn’t slip. This is anything but sustainable. In an agile environment, the scope is allowed to flex based on new information as it comes in. This doesn’t just mean a project can be on-time missing functionality or late with all functionality. It also means a project could release with functionality nobody envisioned until part-way through, and what was once thought important may be left out as all parties realize it was not needed.
How do we use that knowledge to fix our current planning sessions?
Listen to the entire team, not just the one who the product is for. Don’t look at the moon in your pocket and promise Jupiter. Be open to altering the plan as needed over time, and make sure everyone knows their input is actually used in planning.
Like many things in an agile environment planning is a team effort. If you’re struggling to see how the planning your team does matches with their reality, give me a call! We’ll talk about the disconnect you feel and how I can help you and your team close the gap.
In the USA it’s pretty normal. Five days a week we get up, go to work, and then come home. The other two we don’t – usually. (Hopefully?)
In doing this, many people speak about “leaving work behind” or “separating work and home life.”
This is important, in some sense. You need to leave the stress of work out of your home as much as you can, in some professions even more than others. At the same time, you do need a place to safely decompress work, and that’s often at home.
Leaving home and going to work at the office. Leaving the office and going back home. It’s very normal and common. Until it isn’t. And it turns out it’s not necessarily a bad change.
There is a danger in taking the separation of work and home too far. If people are putting on a mask at work and not bringing any part of their true self, then they will almost never truly become part of the team.
We’ve talked about this before. Turning a group into a team takes more than just giving them an activity together though. Each person in the group needs to be willing. More importantly, they need to feel safe enough to bring themselves to work.
I’ve been guilty of this in the past. My time in the Navy is a great example. Who I was on base during those four years was very different than who I was on leave. The team on the submarine never got to know me, even though we’d spend weeks stuck together underwater with little to no interaction outside of the boat. Sure, pieces would sneak through from time to time, but I never delivered my true self.
In another job, I not only allowed myself into the workplace, but I was also friends with some of my coworkers outside the office. Invariably, every time I’ve been on this type of team it has been a better experience, at work and home.
While not coming into the office has its own set of problems, it also does something amazing. It brings the office to everybody’s homes. When working from home, people generally feel safer, and more willing to let themselves, their true selves, into work. This naturally increases trust in the group, either bringing them closer to being a team or closer to becoming a high-performing team.
If your teams are struggling to work together I can help. Whether it’s a struggle due to working remotely, or a long-standing effort to move from group to high-performing team that has stalled get in touch and we’ll set up a 30-60 minute discussion on your needs and how I may, or may not, be able to meet them.
When people gather it’s called a group. You might see a group of people at the park, in the mall, or in an office building.
There’s nothing inherently wrong with a group. People naturally gather, even extreme introverts such as me get together with others at times.
A group can generally do more than an individual. Some things even require a group, such as sports.
Eventually, something happens though. For some things, a group isn’t enough. A group will reach limits. It will run into obstacles outside the abilities of a simple group. For highly complex situations something more is needed. The group needs to change, it needs to become a team.
Often the only thing that binds us to others at our job is having been hired at the same company. There are exceptions all over, some people work with family and some got jobs with friends. These are less common though, and even when someone gets a job with a friend or family member they generally find themselves surrounded by people they do not know.
Regardless of your hiring process, this means that at their heart people working together are nothing more than a group. None of us like to think of it that way though. We always think of our co-workers as part of our team. In fact, at Target everyone is considered a “Team Member” as opposed to an employee. Recruitment all over espouses the benefits of joining the team at company x.
How do you know if your group of employees is a team?
According to Merriam-Webster a team is “a number of people associated together in work or activity.” (https://www.merriam-webster.com/dictionary/team) By the book, a group turns into a team much more quickly than I suggest above.
However, consider a collection of people who gather every day. They each do a task that, when combined, outputs a single product. They do not talk to each other. Not one of them pays any heed to what another does. When they aren’t gathered in that space, they have nothing to do with each other and don’t even cross each other’s minds.
By the book, that’s a team. In my mind, they aren’t.
Agile practices promote the idea of creating high-performing teams. I’ve always felt the operative term here is “team” no “high-performing.” The next question is, how do you determine if you have a team or a group?
I contend a team not only has a common goal but that they also constantly strive to improve on achieving it – together. A team knows their whole lives affect their time together, and they strive to make their time working towards a goal better by connecting outside of that time.
If your team punches the clock and checks out, it may not be a team after all. You need to engage them, get them excited for what they’re doing together, and get them interested in working together. This can be as simple as hosting a quarterly game day. Let them spend half of a Friday every few months playing group games together instead of working. It can also be as elaborate as booking a group vacation for them, dropping them into a wilderness retreat for a week where they can get to know each other better. They come back with a shared experience that helps them relate to each other, and eases the tension on working together.
Wherever your team is on the spectrum of a group to a high-performing team a coach can help bring them to the next level. A coach from outside the organization can see things the organization has become blind to, garner trust the people may not have in the organization, and provide relevant experience from other environments. They can help a group discover what’s causing them to hold back from each other, even if they don’t yet realize they’re holding back. They can help a team realize a rut they’re in and provide ideas of alternates to break out of it. They can help a high-performing team communicate better with the rest of the organization.
How does middle or upper management sell doing Agile to a team that may not be too excited about being told to change how they work?
In most Agile transformations the biggest hurdle is the people who are not on board. When Agile is pushed down on existing teams, those teams can become that hurdle. What starts as a plan to improve customer value, delivery cycles, and employee satisfaction turns into a fight between management and employees. This is not a new problem. Martin Fowler, one of the original 17 creators of the Agile Manifesto, said in a blog post on October 2, 2006:
Drifting around the web I’ve heard a few comments about agile methods being imposed on a development team by upper management. Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception. http://martinfowler.com/
Basically, Agile pushed in a prescriptive manner misses the point. The problem is companies all over are seeing real value from Agile transitions. On top of that, team satisfaction in Agile environments is generally higher than satisfaction at your company. The real question now is how do you bring your teams on board?
The most important thing to do first – figure out why you are pushing this transition on the team. Is it being mandated to you? Are you seeking higher performance? Are you chasing the latest trend? Are you trying to deliver more value? This is important. This will form the basis of everything that comes next. That’s because Agile is not a specific set of processes, tools, and techniques that the teams must follow. It is a way of approaching work that values people, collaboration, flexibility, and results over strict plans and tools. Use the reason and Agile Manifesto values to create a vision that you can sell to the teams.
With the knowledge of why you are pushing this transition you must know how important the specifics you initially proposed are. If you’re lucky they aren’t important but instead are flexible. If you aren’t lucky you are being forced to push a specific set of tools and practices down. You can work with either of these.
The next step is to realize that Agile requires a different kind of leadership than you might be used to. Instead of directing everything the Agile leader sets a goal, or a vision at higher levels, and empowers their teams for success. Take attempting to release to production more often as an example. In a classic leadership model, leadership is going to decide that the latest release of the development environment enables shorter cycle times and then dictate that everyone now must move to it. Maybe they read about it in a white paper or heard from a colleague. In an Agile environment, leadership is going to tell the team that there is a goal for more frequent production releases. The teams will come up with solutions. They may or may not include the latest development environment. They may not even be the same across the teams. Leadership is going to work with the teams to make these solutions a reality, inspect the results, and adapt as necessary.
With our goal in mind, and knowledge that Agile requires a different approach we now have other issues to address. You might be pushing a specific methodology because your management has dictated it. This needs to be part of bringing it to the teams. Assuming this methodology is a true Agile one then also bring to the teams the idea of continuous improvement. This may lead to a realization that the teams just don’t understand Agile.
Most often this can be seen in corporations where the project managers all get sent out to learn scrum. They take a two-day class, a test, and then come back chomping at the bit to put their new knowledge to work. If they have a lot of energy and the personality to back it this can force change, for about a month. It will also cost them trust afterwords. Everyone involved needs at least some training in what is happening for it to work, scrum or not. You may not need to send the entire team to get certified, but at the very least they should be given resources to learn the basics of the Agile Manifesto and how the chosen methodology fits in.
If training alone leaves the teams still wary, then applying some of the same logic Mike Cohn suggests for selling Agile to bosses can help them see a bigger picture.
Let’s return to your attempt to convince your boss to let your team use Scrum. Imagine you had focused on the benefits of Scrum rather than its features. You told your boss how using Scrum would lead to more successful products, more productive teams, higher quality software, more satisfied stakeholders, happier teams, and so on.
i.e. – Instead of just telling them to have daily stand-ups, tell them how daily stand-ups will benefit them.
After all of this, the most important thing is trust. The teams have to trust that leadership will not get in the way of the Agile transition. Leadership has to trust that the teams will work the system instead of going through the motions. As the leader looking for change you must show that you trust the team before the team will trust you. Without trust, the Agile Transition will be long and difficult.
The term bankruptcy has a bad reputation in the business world. This is not surprising considering one definition of it: utter failure or impoverishment. Another definition centers around an inability to repay debt, and that’s the one we want to focus on here.
