Tagged: ALM

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):

  1. Don’t resolve them
  2. Push the defect to the original developer, or the developer most familiar with the functionality for resolution.
  3. Allocate time for the first available developer to pull a defect in and resolve.
  4. Have a defect duty rotation where a person (or team) resolves only defects for a time period
  5. Have a dedicated team for defect resolution.
  6. … 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?”.

Advertisement

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]

Horizontal Management – Mobilizing team and networks: Ready for action

A team that does not work well not only is not a team; but is a blocker towards any success. It is a team (not) that does no work. – yes the not is from Borat.

We must be able to organize teams and networks to be ready for action as this helps the team get off the ground and moving. In order to help get things going as smooth as possible we can focus on a few key elements that can build teamwork and networks, these are leadership, teamwork attitude, common understanding and trust.

Leadership: In my experience, I have always enjoyed working on projects when I was able to be the leader, I think this is inherent to our nature that most of us want to be leaders instead of followers as it makes us feel important and think that we have make a significant contribution to the project. When working as a team, one of the great benefits (that most do not realize) is that the leadership can be shared equally among the team members, it can and should shift from person to person depending on what is required and the person’s strengths, this gives everyone a feeling of accomplishment and an equal and important say in the processes (even if it may not be). When working horizontally team members should be allowed to have debates, open discussions as they are key methods of identify opportunities and resolve conflicts that may arise….. so long as you can focus and move forward.

 Teamwork: Rewarding team members to play nicely as a team always gets peoples motivations up. Teamwork makes a horizontal partnership cohesive so management should encourage early team building activities and open engagement that help develop a sense of collective ownership. This can be encouraged by giving incentives to work successfully as a team, such as recognizing members for their team efforts by giving awards and rewards.

Common Language: Recently I worked on a project where I was using the phrase “data entry” to describe an action where “any user enters data using a graphical user interface”. One of the team members was having a very hard time following the discussion because to him “data entry” was specific to “data entry personnel” (people hired to do data entry), who used a specific data entry user interface that was different than the user interfaces used by others, this was because they didn’t need the pretty features as all they did was repetitive data entry. This is why it becomes very important that the team members have a common mental model and have developed a vocabulary that is understood by all as this helps develop a working culture where misunderstandings or unclear terms will be kept to a minimum.

Trust: Trust is very important in maintaining relationships, it is the glue that holds a team together, if someone does not trust other members in a team, or does not fully place their trust in the team they will not be completely open and might not want to take part in discussions or coordinated efforts. The need for trust makes it important to invest in relationships and build credibility, this can be done by undertaking small tasks, being open and honest with others and delivering what was promised. When team members trust each other they will be willing to risk more together.

[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]

Software Development Life Cycle VS Application Lifecycle Management

The Systems development life cycle (SDLC), or Software development process in systems engineering, information systems and software engineering, is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems.
In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process. http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management. http://en.wikipedia.org/wiki/Application_lifecycle_management

 

SLDC is focused on “Software” in development; its what you follow going from one phase of software development to the other; i.e. from scope & requirements to design to code to etc…

ALM is more than “Software”; its the interactions between various functions/teams that follows the life of the application; i.e. from support to development, development to QA or how things come in from clients as defects and end up becoming enhancements for future releases and so on….

There is a ton of stuff out there on SDLC; my next post will be on ALM and how one can setup workflows and events (there are tools out there that can help you) to automate and mange the ALM processes.