RAPID Agile: Customer Focus – Defect Management
Before we dive back into defining an approach that mixes Product and Custom focus, we should probably ask “How does one focus on the customer?”
In an ideal world there are no defects; but since there are, and customers expect them to be resolved, an ideal approach balances itself between being proactive and reactive; proactively resolve reported/discovered defects and appropriately manage escalations. On the surface, one focuses on the customer by making sure that the defects are fixed before a customer reports them and if a customer reports them, they are addressed promptly (top priority of course) and the customer is satisfied – below the surface, defect management and prioritization play an important role towards our customer focus as this tells us how soon we can (and will) actually resolve defects.
The list below doesn’t capture all possible approaches in resolving defects; it captures approaches that I have had some experience with (I recommend that you certainly do not try the first one):
Don’t resolve them
- Push the defect to the original developer, or the developer most familiar with the functionality for resolution.
- Allocate time for the first available developer to pull a defect in and resolve.
- Have a defect duty rotation where a person (or team) resolves only defects for a time period
- Have a dedicated team for defect resolution.
- … Some other create ways to resolve reported defects..
Always push to most familiar
Pushing the defect to the most familiar sounds like a great idea and in many cases it is because the one most familiar would be able to resolve quickest and positively impacts customer experience. The issue with this approach is that the most familiar person might be involved with something that has a higher priority than this defect, or is out on PTO and would not be able to resolve for another 2 weeks. Let’s say it takes someone familiar with the code to resolve in 1 hour but takes someone not familiar with the code 6 hours. If the defect goes to the person currently tied up and is most familiar, the customer will have to wait a minimum of 2 weeks + 1 hour; however, if it goes to the person not currently tied up and is least familiar, the customer will have to wait a minimum of 6 hours. Being collaborative and available for the team may improve the turnaround time on average, but a hard coded “always send to the one who created it” may not be the best approach.
Allocate time to pull
Allocating time towards the end of an iteration, development or whatever, towards “defect resolution” allows the team to first get the scheduled work out of the way, and “if” there is time, someone may pick something up from the backlog of defects. The issue with this approach is that if the development cycles are fully booked (maybe there is a hard date) and there is any risk or complexity that might lead to developers putting in all they have to meet the delivery; defect resolution gets thrown on the back burner. In most cases where the approach is “allocate time to pull defects”, the unspoken rule is that new products come first, defects second – unless; where the “unless” is for escalations and chaos/fire-fighting instances. For agile teams, if the time allocated towards defect resolution does not change from sprint to sprint, then there is no impact to velocity; however, if the time allocation is not fixed the velocity can get impacted depending on how much time is spent on defect resolutions (usually hours) vs. features (SP’s)…. You could estimate defects in story-points but this can lead to additional issues that will need to be worked out… i.e. do you really want to hold a sprint back? etc..
Defect resolution duty rotation
For a given time (usually the span of a sprint) a developer within a team, or a whole team themselves will be on defect resolution duty; once the time span is over, someone else (or a different team) takes on defect resolution duty and so on. This helps cross-train and helps make everyone familiar with the code base. It can also help improving code quality since everyone is learning from everyone’s mistakes and provides a great collaboration platform; while it does have some great benefits it does introduce some challenges. A significant issue is that developers and teams lose traction as they switch focus from “new product” to “old product”; the interruption can cause a delay since the developer(s) will need to get back to where they were after the rotation is over. For organizations that have many teams or larger teams this may be less of a concern since the rotation might happen every few months; but even then, when it does happen it does have a negative impact.
Dedicated team for defect resolution
The thought on this one is that if there is one team solely focused on supporting “released software” (defect/engineering sustaining team) and other team(s) focused on creating “new software” (Feature teams) that you end up with a two-tiered development approach where both the product and the customer can be focused on. The feature (new software) team is rarely impacted by defects from the “live” world and they can always focus on delivering new product; the defect/engineering sustaining team is dedicated to resolving defects and is not tied up with new features. The issue with this approach is that no one aspires to be a “defect fixer”, developers want to “develop” new and innovative “features” (or at least I did); It is possible to make this work if more attention is given to down-time cross-training, root cause analysis, collaboration, role rotations, etc… (I have seen teams evolve this approach into a “defect resolution duty rotation” approach)
In addition to the above, there can also be hybrid approaches that mix various approaches, i.e. defect resolution duty rotation with an added “pager duty” where someone (not on defect duty) is on-call but in general there is no “incorrect approach”; however:
Any approach can become incorrect when developers are forced to accept an approach that they do not agree with (or understand).
Any approach that is going to be implemented should be discussed with the teams that will be implementing it, focus on and explain the “why”. When an approach does not work, try to adjust it or try something else!
“if the code repository is an “elephant” and new code is peanuts being fed to this elephant by the other guys, then I am always cleaning up after the elephant; who wants to be a shit cleaner forever?”.
Maturing from a StartUp to a StartedUp culture – Series Part 5
People growth – Old blood vs New blood
I wrote my first post here on Jan 23 2011 and that post was titled “Startups – importance of your team“; Its been a little over 2 years since I wrote that post.
Most of us work 5 days a week, putting in about 8 or so hours a day (we will stick to the average/norm here). We come back home in the evening to spend anywhere from 1 to 4 hours with our family/friends.
When friends and/or acquaintances form a startup, the long hours and the close working relationship build on existing relationships and everyone at the startup works as a “family”; but what happens when there are no existing relationships? or what happens when you already have a family and someone new tries to come in? Wouldn’t it be awkward if you were out with your family/friends and a stranger joined your group and just hung out? would you be your self? most wouldn’t.
So how do you take an existing family (a started up culture) and add newer members to it? How do you mix the two so that you do not end up with friend circles?
I have 4 simple attitudes/behaviors that I build my base on:
“We are not that different”.
The new member see’s a whole new planet, different people, cultures, processes, jargon, etc. The first step should be to look for similarities between what they know and what they should know. For my teams I use a buddy system and its usually the previous newest member who buddies up with the new member. They go over materials, documenting anything new that might come up, go for lunch, talk about process, go through the who’s-who, engage the new person in conversations with the other team(s); they try to get to know this person as if they were dating each other.
“We got this, lets work on it together”.
How do you start work? where do you start? who do you ask? Scary questions for someone looking under the hood of something they do not understand. Here is where the buddy comes in again; during stand ups and sprint planning the buddy might offer “we can work on this together”, or someone else on the team might say “hey this is a good problem for me to show you how xyz works, and we can solve it”… they get the knowledge, they figure out how to start, they experience the process and they know how to close it. Build trust and accountability.
“Your team mentioned that you are catching on so quick, what can we improve?”
Over communicate reinforcement of team acceptance, ask for ideas on what can be improved, engage the new member; engaged employees have ideas and feedback that they want to share, things they have questions about.
“You are doing great, let me share my vision on how you play an important role to the team”
Setup a growth plan that’s challenging and communicate that it may be challenging and track to it. I like to plan for the 1, 3, 9, 12 and beyond and use data obtained directly or through peer feedback to gauge fit; if there is going to be tissue rejection, you need to act fast and figure out what you need to do to make it work successfully.
These 4 steps get you on track but you will still need to build additional on-boarding processes (around material and core knowledge ) that will grow the employees product knowledge. Its also important to keep your existing members in mind when you optimize culture as you want to grow the existing employees as well and not just the new ones.
At the end of the day it helps if we recognize that the teams we work with are more than just “Random people”; they are people we spend several hours with, they are friends, people we trust, can openly collaborate with and people we want to continue to work with.
When one finds a team they can work with for the rest of their life and can call family, its no longer “work”…it’s just a large friends & family gathering where they just happen to be working on something together and having fun.
We should all build and be part of such teams.
Maturing from a StartUp to a StartedUp culture – Series Part 2
The Startup and the 3 P’s: Product, Process and People
I will not pretend to know everything about startups and startup culture, but I will list the reasons why startup culture is exciting, at least for me:
You meet great people, people who have ideas and want to try things, people who have passion and want to make an impact, people who will challenge you to do better. There is passion for working together as a team, passion for building trust within the team and passion for collectively making an impact in other people’s lives; or sometimes, passion for just making something happen – to create. There is passion for possibly creating something that could go big – disrupt everything, all built from the ground up with the teams sweat, blood and tears where everyone is high on adrenaline. Suits? Offices? As long as you are connected with your team and are working well together, those things don’t matter. There is no red-tape, or big top-down structures, everyone and anyone has access to all. Anyone can start working on anything, there are many hats to choose from; wear all. You don’t get bored as things are evolving and stay fresh, there are new ideas, old ideas, odd ideas; anything can change anytime.
At the end of the day, a startup is defined by its growth; when a startup doesn’t grow, it dies; it stops.
There can be several growth stages for a startup, and startups evolve; once they start growing they are now “startedup” and will hopefully grow exponentially. In a perfect world, the cultural values that made the startup fun would remain and in some cases they do (depending on where the growth has lead the startup) but there are times where the culture itself that helped the startup grow and evolve starts conflicting with what is needed to grow to the next level.
Let’s say you follow agile and you end up with iterations, planned work, release schedules and a clear pipeline of what needs to be built. This all worked great when you had 2 products and a team of 10; since you have grown, the expectations of what you can or will deliver have also grown. Some brilliant folks in your team have discovered 2 more products that should be added to your portfolio; how do you grow your current 2 products (since they have a feature and defect backlog) and also work on these 2 new products without increasing your team size, changing delivery for current products or burning out resources? Before you grew, you may have had your own expectations of when and how you would bring on these two new products; now that you’ve grown, others may have different expectations from you and your team(s). Maybe you say “we need more people”, which brings me to the next point
With the growth of the startup, either through sales, funding or more investment and the need to create more product it is decided that you bring on more people, and you do. You end up facing the same issue, how do you grow people with the same 10 resources you had who are busy working the two existing products; some of the people you bring on may be self-starters and will figure everything out by themselves but what about the ones who don’t? So now you say “we need some process and automation to free up some of the manual work so that we can do more with the same resources”, which brings us to…
How do you focus on process and automation to free up time when the people you have are busy with supporting the existing two products, or are supporting the existing two products and are also trying to bring the new hires on-board?
A part of me says that the above three growth challenges are not really challenges and that they are part of what it means to be a startup culture and are expected. However; there are a few by-products that the 3 P’s create that can become toxic, stop growth and hurt the culture if they are not accounted for when trying to grow.
The Frat party & the first team
The first team consists of the people that built the startup; it was their teamwork and effort that made the startup grow; anyone who comes later is an outsider and “we need to be careful about who we let into our frat party” (once upon a time I lived on frat row). This one is not intentional, but when you work closely in teams and blur the line between friendship and co-workers, you end up creating an inner circle and make it challenging for an outsider to easily integrate and feel welcomed. This by-product is a blocker for People growth.
The golden simple process
At some point there was predictability and little chaos in what all needed to be done (smaller team, less products) so everyone starts expecting things to always be perfect. Even though you have grown, you have kept your process simple and did not optimize for KPI’s and other metrics that can help with predictability, complexity, risk and estimation. There will be times where things change, dates get reset and/or product scope creeps. If you had built a roadmap of what releases when, had committed the teams to that and put all these releases with their iterations back-to-back (because of all the product that had to get pushed out to show growth and maturity) and dates or requirements change on you (usually not for the better) the team and its happy culture will get disrupted as it will take effort to get things back on track; when/if this happens all the time, it gets hard to get away from the domino effect and people burn out, get disengaged and/or leave. This by-product is a blocker for Process growth.
When you were small, everyone knew what everyone else was doing, everyone shared and individuals had their skillsets. Now you have grown, 2 months ago you were 10 people, today you are 75, the 65 newer ones don’t understand the code base or the original design, there is some good documentation but they need more information and there are 3 key people who know different things about the original products; original products that you want the new 65 people to work on so that the first team can work on the two new ones; how do you distribute the knowledge known by the 3 key people, make them available to the 65 and allow the 3 key people to focus on their new projects? If they are constantly being pinged by others and cannot get their work done; their sense of accomplishment doesn’t scale much; especially if you did not plan for them to set time aside and help others. This by-product is a blocker for Product growth.
Each blocker is situation (just like leadership) and can be solved; we will examine and solve for each, before we move onto other “StartedUp” culture challenges. The next post goes into process KPI’s and metrics – addressing the golden simple process blocker.
Horizontal Management – Maintaining momentum: Keep progress moving
While machines might give the same level of output everyday, the same doesn’t apply to people.
In a real environment, each member’s momentum and motivations will change without notice. This requires management to step in and make sure they are constantly evolving the processes so that members will remain motivated. Leadership is important to motivate key players, channel information to keep everyone engaged and make working horizontally routine. To accomplish this, management might bring in an outside champion, who will help wring in new ideas and “fresh” stream of motivation. Instead of looking at a project as a whole, it should be broken down into smaller goals that are realistic and achievable. Management should encourage and build on small success, to demonstrate that it was an important milestone and motivate members. Progress and results should be demonstrated so that members can all acknowledge the ongoing progress and success. Management can keep the members interests by ensuring that they are always focused on achieving the goals that were set, and if deviation is detected, corrective action is taken to bring things back on track.
A horizontal team is dynamic as it is always changing, management needs to account for its dynamic nature and make necessary adjustments to accommodate/adapt to the change. Money is probably the best motivator, but too much money too early in the process can hinder individual initiative and prevent people from innovating. Since horizontal structures focus on team collaboration, a downfall is that meetings can go on forever and schedules can be missed; this can unmotivated some members who feel that decisions are not being made in a timely manner, which is why management can implement deadlines which will help practitioners develop a common schedule and manage workloads effectively so that the projects momentum is kept at a steady pace.
[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]
Horizontal Management – Building support structures: To keep Horizontal team in check with Vertical roles
Even though a “horizontal structure” is flat in nature, it does still need a (vertical) support structure.
The main purpose of a support structure is to help managers build lasting relationships and achievements with teams. There are two basic type of support structures that managers can mix and match when building or working with teams, depending on the requirements as each has its own attributes.
- Informal structures don’t define rigid roles and responsibilities, they are open to interpretation and people can define their own roles and swap roles as needed, hence they are less resource intensive, more flexible and less binding on members; Informal structures help promote open discussion and communication among its team members; and
- Formal structures are more rigid and roles/titles might be defined where members have specific responsibilities; this makes them more resource intensive but less ambiguous; they require some logistical skill and expertise to implement. These structures are great when consistency and quality are important factors.
It’s important for management to recognize what type of structure needs to be in place and when its put in place; as “when” a structure is erected, it can play an important role in the success of the teamwork initiative. If too much formality is introduced early, people might feel there is no difference in the “horizontal structure” and the “vertical structure” where vertical structures are rigid, formal and bureaucratic and would be less motivated to work with the initiative. In contrast, waiting too long to build a support structure or the lack of a support structure can hinder the ability of the team to successfully work together as a team, especially when they need to be able to adapt when in tight spots.
Since the resources and effort required are greater when setting up formal structures, informal structures are great for short projects, however when the projects will go on for a long period of time or are of large scale, formal structures would be more suited as they are less ambiguous and will stay well formed longer (as they are more solid than informal structures).
Authority and roles in informal structures are more ambiguous and can be swapped around; In formal structures, the roles and responsibilities are more definitive, hence less ambiguous and in that regard, formal structures would work best in situations where important decisions need to be made.
[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]
Startups – importance of your team
As far as I can recall, I have always been trying to build something.
In high school it was a community magazine. In college it was a BBS (bulletin board system).. Then towards the mid/end of the 90’s it was a subscription based web publication system and an online food court.
Let’s just say it was the wrong county and maybe the wrong time.
But moving forward came the idea of an online community that connected people, services and things based on geolocation…. This is before twitter, facebook, myspace, groupon, etc, etc.
Re-evaluating all my projects; I had realized that it was the “lone-star”ness that should be blamed for the failures.
I decided all my projects eventually failed because I was doing everything and eventually burning out and loosing interest on my own project.
August/September 2009 I decided I was going to have a team for my next venture. Started looking at startup job postings, contacting startups, etc… Wasn’t going anywhere until on twitter I found a post from Fan, looking for a techie to help with blanklabel.com and I reached out as in the early 2000’s another idea I had toyed with was online tailoring…. A year+ blanklabel.com grows, at a rate that far exceeds the expectations of our followers and probably our competition.
At home, many times I use to find an abandoned coffee cup; forgotten, unfinished and left in place. Credit goes to the now wife… I would ask her “what the hell is this?” and her response would be “a chemistry experiment”.., hence my motivation for making the following analogy…
A team is like the tube in a particle reactor and the particles are the team members.., you could state it’s an experiment where the tube contains the particles and helps them move towards the desired direction. Why is it an experiment? Well, you hope that the constant colliding will produce the energy/effect desired and not blow up the entire reactor. So it’s also important that these particles mix well.
Without this tube and other particles, I’d still be a free radical… A lone star that would eventually burn out and have no potential of creating and being part of a “big bang”.