Organizational health for Agile Adoption: Key traits of QA leads

This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first eight parts of this series here:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players
Part V: Sprint Execution
Part VI: Key traits of Customer Champions
Part VII: Key traits of Development Leads
Part VIII: Key traits of Schedule Facilitators

In Part IV (Key Players) we discussed that a role someone on projects at your organization must play is that of the champion of quality of the software for the customer or Quality Assurance (QA) Lead. People staffed in this role often have job titles such as Lead Test Engineer, or QA Manager or will be the same person running all of the tests at a startup or small company. These resources are tasked with ensuring that the software features developed in each Sprint are free of bugs to the point where they can be delivered to their respective customer.

There are four key concerns that help a QA lead shine in agile organizations.

Extract Scenarios

In most agile projects, there is just enough documentation created to implement features. In this situation, a QA lead cannot use the excuse “the docs didn’t say the software was supposed to do that!” since it should be pretty apparent that the software will do quite a bit that isn’t in the documentation. A primary challenge will be to discover through conversations, reading, and freestyle testing exactly what the software does. The result of understanding these scenarios should be to create a list of scenarios categorized by features, and be able to keep track of which of these has been tested, and what the status of those tests is (pass or fail). This extraction process includes answering questions like:

• What should the default values of controls (or parameters, in a service) be when starting the scenario?
• How does the user get to the scenario (or what methods must be called first, in a service)?
• What fields are required and what is their validation, including validation that is field-specific?
• What should the result(s) be when the scenario is completed?
• What are the other factors that could effect the outcome of this scenario (another user has locked a resource, certain fields or settings are time, user, or environment specific etc.)?

Create Reproducible Tests

Once scenarios begin to be extracted, the steps needed to test them should be recorded in a document, tool, or script that ensures it can be reproduced exactly each time. The excuse that “it’s too time intensive to write down the steps” is a common one that results in inconsistent results from one test cycle to another. The only way to have a strong feeling of conviction as to what’s passing tests is to know you are testing the same way each time. If you can’t take the time to write down the steps needed to test a scenario, you pay back that time in full through extra conversations with developers clarifying steps, bugs found in edge cases not tested in a prior run (with no guarantee you’ll find them in the future as they aren’t written down!), and completely fictional reports of stability.

Coverage at all Costs

Some tools are great at unit testing. Some do a great job at testing use cases. Others setup sophisticated scenarios that are difficult to test by developers. Regardless of the tool or approach used, the goal should be 100% coverage of user (or system) exercised features. If a tool only allows automation of 70% of scenarios, then create (and document!) manual test cases for the remaining 30%. The last words of a failed QA lead are “the tool won’t let us test that so we’re skipping it since it’s not very complicated”.

Estimate Quality with Experience

With the arrival of tools that watch the number of lines of code executed during tests, there is an unfortunate cultural shift in QA towards watching your overall code coverage statistic. Folks declare “90% coverage and all passing tests means ship it!”. When this number is quite misleading. Many of these tools do a good job, but due to the dynamic nature of code (and especially the sophisticated nature of most modern software architectures and their pluggable configuration) it is not possible to determine true code coverage with just one automated tool. A QA lead should spend time with developers understanding enough about the variances and flexibility in their implementation that requires additional testing on a case driven basis. QA leads should report their own estimate of code coverage, which should be based on both the results of automated tests, known scenarios that have not yet been tested, and personal feeling/conviction. As the final arbiter of quality, a QA lead should never report higher or lower stability of a project or feature due to political pressure. Let a manager or developer fight the truth, but never let lies be spoken from the mouth of QA.

Organizational health for Agile Adoption: Key traits of Schedule Facilitators

This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first seven parts of this series here:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players
Part V: Sprint Execution
Part VI: Key traits of Customer Champions
Part VII: Key traits of Development Leads

In Part IV (Key Players) we discussed that an optional role that someone on projects at your organization may play is that of a facilitator of smooth execution of sprints or Schedule Facilitator. People staffed in this role often have job titles such as Project Manager or Software Development Manager, and are typically only necessary on projects with more than a handful of people. These resources are tasked with aiding the development team in delivering the highest value, highest quality features out of each Sprint.

There are five key skills that help a schedule facilitator shine in agile organizations.

Track Dependencies

In an agile environment, often Microsoft Project is foregone in favor of using just-in-time Sprint planning (I’ll discuss this in a future post) where an “end date” is available for each Sprint (current and future) that has been loaded up with features from the backlog. As you look out further into the future from the current sprint, the reliability of estimates for future Sprints becomes more volatile. In this environment teams have to find another piece of software or means to track dependencies between each others’ features that they are assigned to in a Sprint. Developers are often good at identifying and reporting status on dependencies, but need help watching them. As a schedule facilitator, enable developers to communicate dependencies to you as they are identified during both design and implementation of phases of the project (you’ll have dependencies identified mid-Sprint, guaranteed). Then keep track of these by periodically asking the developers responsible for features that others are dependent on in the current sprint for the status of those dependent features. The challenge is to find a frequency in asking for status that is non-intrusive to their workday and also frequent enough that it results in change. Ask too often, and you get the same answer and irritated developers. Ask too rarely, and you find out there is a problem too late. See the “Report Status” skill for a way to alleviate this.

Facilitate Availability

Another one of the biggest challenges development teams have in an agile environment is getting access to business resources. The Customer Champions closest to the needs of the customer are often responsible for many activities as part of their normal job, and their need to be available to developers for design of new software features is seen as an additional burden. One of the biggest things a Schedule Facilitator can do to in this scenario is to help soothe this friction. A good Schedule Facilitator should help the development team with any logistics around getting access to Customer Champions. This includes meeting room planning, getting tools for collaboration on the project, and continuing to communicate to business resources the importance of their involvement in the design process. Business resources often need continual reinforcement of the value of their involvement to achieve success.

Report Status

As a schedule facilitator one of the most common tasks is still reporting status. In a good agile project, the development team members themselves (including the Development Lead) should be enabled to choose and use the processes and tools they determine as best for their project to communicate status to each other. However at specific intervals, it will be necessary to communicate status to stakeholders such as customers, CTOs, or other high level management expecting an estimated release date or progress to date.

For starters, developers should have a meeting with the Development Lead, all development members, and the Schedule Facilitator to report status semi-regularly. The common format here is SCRUM and it typically happens once a day or twice a week. The goal here is to quickly go around the room and have each person report three things:

1. What did you do before last time we met?
2. What are you going to do next?
3. Are there any roadblocks you need help with removing?

This meeting should not be used to gather completion status on features or to talk about their design. The goal is for each developer to talk for 1-3 minutes. This is a great way to raise visibility to all the development team members of what their colleagues are working on (though a tightly knit group won’t need this), and also to give additional opportunities to identify roadblocks that a Schedule Facilitator can help to remove. However it’s not sufficient for gathering all the information needed to communicate status to other stakeholders. This should be done through a tool or document that allows developers to update their status on features they are working on in a Sprint at any time with the following information:

1. Time remaining on feature (hours or days)
2. Percent completion of feature (up to 100%)

Throughout the week, give developers a tool to allow them to update these values at any time. Let them know when the Schedule Facilitator will be communicating status to stakeholders so that they have an opportunity to update their status. However once this interval is established, unless you identify a problem with a resource not updating their status, assume that the status each day is current. The goal is to let status reporting from the dev team be autonomous and not some once-a-week endeavor that wastes time by getting everyone in a room to read to the group numbers that are already available in a document or web-based tool.

Prioritize within the Sprint

As developers complete features assigned to them in a Sprint, they will pick up new ones off the backlog as described in Sprint Execution. This can get tricky when the business stakeholders are in the middle of re-prioritizing the backlog. A good Schedule Facilitator communicates with the business regularly to let them know when developers are going to need a new feature to work on, and asks them to expedite determination of the highest priority features on the backlog mid-Sprint.

As developers come up with new tasks to complete identified during design of features and fix bugs from previous ones, a Schedule Facilitator helps greatly in determining the order in which tasks are completed, bugs are fixed, and completed features are tested. Communication between the business, development, and QA when making these prioritizations is key to making sure resources know what effect changes in prioritization will have on them and whether there are other concerns that should be kept in mind before committing to the reprioritization.

Inform and Educate

Inevitably on agile projects (due to their being so adaptable to change), some changes will cause friction in the organization. Because business stakeholders can adjust the highest priority features to work on from one Sprint to another (as described in Backlog Management), at times there will be features that are not finished at the end of a Sprint, or new features requested that are difficult to implement due to dependencies or technical constraints. As a schedule facilitator, one of the most powerful things you can do is inform and educate the stakeholders to which status of the project is being communicated on these issues. Instead of asking a developer to spend 30 minutes explaining to the CTO the issues around implementing a feature, talk with your developers and then communicate this yourself. Schedule facilitators should be aware of the importance in giving developers time to complete their tasks, but never should they shy from talking with a developer when more information is needed to communicate effectively to stakeholders. One of the worst things a Schedule Facilitator can do is to communicate an issue to stakeholders with reasons or additional information that has not been confirmed by the development team as valid.

Lastly, when communicating decisions made in changes to project scope, vision, or direction by stakeholders back to the development team, it’s usually better to not discuss these until they are finalized as some developers will make changes to the way they implement a feature knowing a change is coming. This is great if you’re sure you are going to do it, but if the change isn’t for certain, you’ve now created a concern for a developer that may not blossom into even being one.

Organizational health for Agile adoption: Key traits of Development Leads

This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first six parts of this series here:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players
Part V: Sprint Execution
Part VI: Key traits of Customer Champions

In Part IV (Key Players) we discussed that an important role that someone on projects at your organization must play is that of a leader of the development resources, or Development Lead. People staffed in this role, whether the sole proprietor of a startup or a technical leader assigned to a project such as an architect or senior consultant, are tasked with more thought collaboration and less reliance on technical savvy in an organization.

There are five key skills that help a development lead shine in agile organizations.

Refactoring

Predictably, it’s important that people tasked with leading the development activities of projects at agile organizations be competent at refactoring. The ability to bring experience from real projects (sometimes failures bring more experience than wildly successful ones) and to apply this to a rapidly changing codebase is increasingly important, because on an agile project the design of key modules and patterns is going to change somewhat regularly. Experience with modern source control solutions; modern architectural patterns and their tradeoffs, refactoring features in IDE’s like Visual Studio, Eclipse, and Resharper; and some competency with the technologies involved are all good ingredients for refactoring success.

Mentoring

It’s also important to have a Development Lead who is aware of their shortcomings. A lead who solicits input from other team members on their own, and who offers more of their time to do reviews of design and code is the type of person we’re looking for. A person with great technical skills will produce functional code. A person with great technical collaboration skills will produce a team of producers of functional code. A goal for Development Leads should be to create a culture of “sustainable autonomy”. Developers on their team should be able to prioritize their own bugs, gather their own requirement clarifications, and assign themselves to new work as other items are finished without constant oversight by them. Though junior developers on an agile team may require more oversight, this should be the exception, and not the rule. Development Leads may take the drivers’ seat in making some of the initial process and technical decisions at the beginning of a project or sprint, but the changes that occur when the theoretical gets concrete (as most agile projects are light on up-front technical decisions, preferring decisions made at the latest responsible moment) should be team driven. Doing this diversifies some of the leadership skills across the team instead of centralizing it on one star player. It’s still important to have one technical final arbiter of decisions at which the buck stops however.

Written, presented, and oral communication

This one’s pretty self explanatory but it’s so important it really has to be worked on to be harnessed. A development lead should work to be better at conveying information, in a variety of formats, to a variety of audiences, and then gathering and interpreting feedback from that conveyance. This means good grammar, spelling, email voice/attitude consideration of audience, and even selection of media. This is a foundation upon which the other skills needed by a solid Development Lead rest.

Compromise

It also bears repeating from the Key Players post that communication with business resources is of the utmost importance to Development Leads. A good lead has an ability to provide the right analogies and information to convey ideas without being overly technical, and makes business people feel excited when discussing ideas with them instead of intimidated. Business resources should feel like “this is the person who’s going to turn my ideas into reality” instead of “this is the person who’s going to change all my ideas to fit technology limitations”. People on both the business and development side of the fence live day to day with the reality that at times software vision must bend to the unfortunate compromises of technical limitations, but a good development lead puts energy on what can be done instead. You want a person who sees the process of cultivating a project out of agile processes to be one who sees the cup “half full”. This doesn’t mean being a well-to-please, but rather someone who works tirelessly to find an acceptable level of functionality to solve the business problem within technical constraints.

Pragmatism

This ability to compromise also extends its benefit when a Development Lead must consider budget and schedule constraints when weighing tradeoffs of technical decisions. Every time dependency injection, testing approach, partner integration patterns, or any other aspect of the design of the software is on the table; a good lead considers the true weight of each factor (and not just their own position) for all involved and strives to make the right decision for users of the software and the business. This more often than not means accepting a difficult technical limitation in favor of meeting a requirement or a deadline. It is still important in these situations to document the limitations imposed by weighted decisions both to keep track of addressing them later and to prevent accusations of ignorance should the limitations become politically stressful for the customer or organization.