The 6th Man Principle

In the midst of watching the NCAA March Madness tournament, I was reminded of the 6th man concept that RSI has used since its early days. As in basketball the 6th man concept is all about having a ”non-starter” prepped, practiced, ready to enter the game and immediately start contributing to the team. This concept is core to RSI’s 6th Man principle. For many of our strategic accounts we deploy an extra colleague to participate in the upfront strategy and design sessions, kickoff meetings and daily stand ups so that when their time comes they will be prepared to hit the court at full speed. Their time may come due to an injury, an illness, paternity or maternity leave, or maybe just a packed sprint that needs the extra help. Whatever the cause we know that this 6th Man will be able to step in, run the offense and execute the game plan because they’ve been to all the practices. But wait, why would an enterprising, software development firm place a non-billable colleague onto a team? The rational is that it’s good for the client, good for the colleague, and in the long run it’s good for RSI. For the client it’s the assurance that they know there’s a backup waiting to get in the game in case something happens. For the colleague it’s a better use of “bench time” than creating a “make work” internal project or watching another PluralSight video. For RSI it’s a way to keep both clients and colleagues engaged and happy. As March Madness enters the Sweet Sixteen and Final Four rounds take notice of how those 6th man players ultimately impact the game and success of the eventual winners.

Why Throwing More Bodies at Your IT Project is Not the Answer

A lot of companies find that competitive advantage comes with cutting costs and increasing speed to market. And that often works except if they’re launching a new IT project. This brings a new set of challenges, especially since the first reaction is to see who’s on staff who could do it. Throwing additional internal resources toward an IT project might not give you the competitive advantage you’re looking for. In fact, it could very well slow you down. The first potential impact is overextending staff by pulling them onto yet another project and moving their focus away from important, business critical tasks they were hired to do in the first place. Next, lack of expertise can become a roadblock. This can be costly when a project slows down due to errors or delays needed by staff to ramp up and learn something new. Another solution to consider is outsourcing because it can provide the flexibility and scalability that you need to innovate and get to market faster. Companies such as Basecamp, Squawker and Github, were created with outsourced development. Why? It’s smarter. The benefits of outsourcing are numerous. Let’s take application development as an example: 1. Experience – you’ll get the expertise you need, when you need it. Outsourcing means your development will be done by professionals who live and breathe development and are constantly learning and applying the latest IT trends to projects 2. Scalability – outsourcing allows you to rapidly scale up or down your development needs without the expense and long-term commitment of hiring additional full-time staff or overextending existing IT staff. 3. Efficiency – a team that is 100% focused on your IT project will increase your speed to market, getting the job done without spending unnecessary time and money on the development phase. 4. Reduced costs – increased efficiencies alone will reduce development costs but you’ll also reduce overhead costs and pay for the services you use, allowing you to save money during periods of low activity. The next time you’re faced with a new IT project with limited resources, you could save time and money by rethinking the reaction to simply throw more bodies at it and consider outsourcing instead.

Why Requirements Should be Tested – A Lesson in Quality Assurance

Software development teams may be accustomed to working with quality assurance (QA) teams at the end of the development cycle but there are many reasons to involve QA at the beginning of a project. One great reason is to let the QA team “test” the software requirements. Whether your software development team is following agile or waterfall processes, having a QA analyst test your requirements can mitigate the risks of misunderstood requirements and delivering software that does not meet the expectations of stakeholders. QA team members are very good at questioning requirements because they must understand how to test all features. When testers question the requirements at the beginning of a project, they can reduce defects in the code. Why test the requirements? Requirements can provide a starting point to discuss and solidify feature development. By “testing” or questioning the details of the functionality, the team can ensure that they are creating software that meets the correct requirements. Here are some things to look for when testing requirements: Ambiguous Requirements: A tester can ask questions to flesh out details of the requirements. For example, a requirement might state, “as a new user I can create a secure password.” To test this requirement, you need to know specifically what the system will consider secure and what will not be secure. Are the users required to enter passwords of a certain length? Are certain characters required? Is the user restricted from using certain characters or words? Does your organization have a security / password policy that you need to follow? If questions are asked to confirm requirement details, developers will know what to code and testers will know what they need to test. Unnecessary Requirements: Requirements may detail functionality that is not necessary. As the project progresses, a requirement that once was valid may no longer be valid. Unwritten Requirements: Many requirements are unwritten or assumed. If the project team does not share the same assumptions, the team risks delivering a system that does not meet the requirements of the end users. Unwritten requirements often include non-functional requirements such as system performance, security issues, usability, accessibility, configuration, etc. Questioning these assumptions will get everyone on the same track. What if there are no written requirements? Have you ever heard, “I can’t test this because there are no requirements?” Even if there are no written requirements, there are still requirements! Testing or questioning the details around these unwritten requirements can resolve a lot of ambiguity. Agile teams do not always have the time to write all the details of the requirements. One of the principles of agile software development is “working software over comprehensive documentation.” Often agile teams will refine requirements via team meetings. It is crucial for QA teams to attend these meetings. Testing can serve as documentation of the required functionality when requirements are missing. Conflicting Requirements: Does a requirement conflict with another requirement. Maybe the requirements conflict with other information you have from the customer or another source. Testable requirements: How will you test this functionality? Are there data dependencies that could affect how you create your tests? How can you make sure that you have fulfilled this requirement? Another consideration for testable requirements is the timing of testing. Is there a test that depends on an overnight process or batch to run in the system? Consider security roles for users. Can any user access or use the functionality? Or is functionality restricted only to certain users. If so, which users can or cannot perform this functionality? If the team is planning on automating tests for a web-based application, do all the pages have a <title> tag and all objects and images have an ID or name that the automation tool will recognize? Do you have the right tools to test this requirement? For example, if the requirement is that the system must support 10,000 concurrent users, how will you verify this? If there is a requirement that the system must run on different browsers or mobile devices, do you have access to those browsers and devices? What versions of each browser will you need to test? QA team members know how to test to make sure the customer’s requirements are met by using critical thinking skills, attention to detail, and curiosity. Testers can utilize these skills and techniques to help teams achieve consensus on project requirements. By involving QA early in the software development process and “testing” the requirements QA can help the team do the right thing, the right way, the first time. Editor's Note: This blog was updated from its original post.

The Top 5 Reasons Your Company Should Go Agile

Agile development is not new. In fact, it’s been 15 years since the was created as an alternative to software development processes, such as waterfall. At this point, agile is not a passing fad and if you haven’t adopted it yet, 2016 may be the year. Here’s five reasons why: 1. It enables a faster time to market. Every business wants to get a new product to market as fast as possible especially when that product will help drive revenue. In contrast to the waterfall development approach, in which each phase of a project must be completed before the next phase can begin, agile development breaks projects down into smaller increments with short timeframes called sprints. Within each sprint product development occurs across the various phases simultaneously. This allows development teams to bring products to market much faster. The resulting product does not need to reach its full functionality or include a complete set of features before being released. Development teams put effort on specific functionality during each sprint, setting short time periods during which work is to be completed and made ready for review. This allows for the release of software more frequently and with greater focus on the features and functionality that will deliver the highest return on investment and/or are most critical for the business. 2. It allows for continuous improvement. Organizations are always looking for the best software development method, but implementing a new process or tweaking an existing process can have a big impact on the business when sequential development approaches, such as waterfall, are employed. Agile development makes it possible to continuously improve processes, which in turn drive efficiency. You will be able to identify inefficiencies and improve processes within each sprint because Agile’s short development cycle allows development teams to try new approaches and ideas while they are developing, leading to innovation and improved efficiency. 3. It is user focused. You want to bring products to market that users want and need, right? At the end of the day, these products drive your business in more ways than one. Bringing products to market more frequently and in shorter intervals means that you can iterate and improve quickly based on customer feedback. In this regard, development becomes more user focused and considers direction from the end user. And when those changes need to be made, the shorter agile development cycle means you’re able to get valuable feedback early in the project and make additions or changes in the next sprint. 4. It’s flexible. Unlike traditional software development methods, Agile allows you to better adapt and meet changing needs. This eliminates getting to the end of a long development cycle only to realize the product you have created does not meet your current business needs. 5. It drives transparency. Frequent communication between the development team and the business helps discover issues and other challenges early, providing opportunities for quick resolution. In contrast, a lack of transparency makes it difficult to adjust to changes, keep track of the work being completed, and identify and eliminate potential roadblocks. Transparency helps the team make sound, informed decisions and keeps projects on track. More and more businesses are realizing that with Agile development comes tremendous benefits. In today's fast paced, competitive business environment, Agile can help drive your software development efforts to realized business success.

Your Team’s Not Agile Unless You Are Doing Agile Testing

For many software testing professionals experienced in traditional development processes, working in an Agile project can be a foreign concept. Testing in older development models often only takes place near the end of a major development phase by a team of dedicated testers. As a result, test phases can be seen as a bottleneck since a multitude of bugs can be (and most often, are) found when QA analysts start looking at previously untested software. In order to meet deadlines, testing phases may be shortened or eliminated altogether, resulting in increased numbers of potentially severe issues at worst, or increased customer support workload at best. Utilizing Agile development practices can alleviate these problems by integrating testing throughout the development process, allowing for a higher quality application. Agile processes can seem chaotic or time-consuming at first, especially if the team is unfamiliar with or still adapting to the shift in thinking required. Whereas traditional development cycles will have a definite start and end, Agile projects are often treated as a continuous endeavor made up of iterations, or sprints, which often last around two weeks. Team members decide on what issues or functionality they will deal with in each iteration, and once that sprint is finished, the next one begins. Testing is not performed in only one phase of the process, but is integrated into each phase to varying degrees, starting as soon as code is created. Members of an Agile team are often expected to utilize different skills, so it is not unheard of for developers, stakeholders, and other roles to perform some types of testing duties along with the QA team. Testers should be well-versed in a variety of testing tools and techniques. Commonly, testing will be exploratory in nature, but understanding how to perform acceptance, UX, load/performance, and even unit testing can be beneficial in an Agile project. Since regression tests can become burdensome over time, many teams implement some form of automated testing. In order to decide whether to add automated tests to a project, team members should weigh the time spent on regression testing against the time that will be spent maintaining the automated test scripts, which can become a problem if the system changes too much, too frequently. Agile processes are not flawless. Acceptance criteria can change unexpectedly based on stakeholder feedback, and a lack of documentation can create knowledge gaps for the team. Luckily, these types of problems can be avoided if Agile methodologies are properly used. Continuous communication between team members, along with having everyone as involved as possible in each step of the process, can reduce communication issues and help the team to be more adaptable to any changes that can come up. Understanding the nuts and bolts of a system or application and how it should behave under certain conditions is essential to any testing efforts, and with the continuous testing integration that Agile methodologies provide, that type of understanding can be achieved with relative ease.

Quality Assurance: Why Should Requirements Be Tested?

Software development teams may be accustomed to working with quality assurance teams at the end of the development cycle. There are many reasons to involve QA at the beginning of a project, but one great reason is to let the QA team “test” the software requirements. Whether your software development team is following agile or waterfall processes, having a QA analyst test your requirements can mitigate the risks of misunderstood requirements and delivering software that does not meet the expectations of stakeholders. QA team members are very good at questioning requirements because they must understand how to test all features. When testers question the requirements at the beginning of a project, they can reduce defects in the code. Why test the requirements? Requirements can provide a starting point to discuss and solidify feature development. By “testing” or questioning the details of the functionality, the team can ensure that they are creating software that meets the correct requirements. Here are some things to look for when testing requirements: Ambiguous Requirements – A tester can ask questions to flesh out details of the requirements. For example, a requirement might state, “As a new user I can create a secure password.” To test this requirement, you need to know specifically what the system will consider secure and what will not be secure. Are the users required to enter passwords of a certain length? Are certain characters required? Is the user restricted from using certain characters or words? Does your organization have a security / password policy that you need to follow?If questions are asked to confirm requirement details, developers will know what to code and testers will know what they need to test. Unnecessary Requirements - Requirements may detail functionality that is not necessary. As the project progresses, a requirement that once was valid may no longer be valid. Unwritten Requirements - Many requirements are unwritten or assumed. If the project team does not share the same assumptions, the team risks delivering a system that does not meet the requirements of the end users. Unwritten requirements often include non-functional requirements such as system performance, security issues, usability, accessibility, configuration, etc. Questioning these assumptions will get everyone on the same track.What if there are no written requirements? Have you ever heard, “I can’t test this because there are no requirements?” Even if there are no written requirements, there are still requirements! Testing or questioning the details around these unwritten requirements can resolve a lot of ambiguity.Agile teams do not always have the time to write all the details of the requirements. One of the principles of agile software development is “Working software over comprehensive documentation.” Often agile teams will refine requirements via team meetings. It is crucial for QA teams to attend these meetings. Testing can serve as documentation of the required functionality when requirements are missing. Conflicting Requirements– Does a requirement conflict with another requirement. Maybe the requirements conflict with other information you have from the customer or another source. Testable requirements – How will you test this functionality? Are there data dependencies that could affect how you create your tests? How can you make sure that you have fulfilled this requirement? Another consideration for testable requirements is the timing of testing. Is there a test that depends on an overnight process or batch to run in the system? Consider security roles for users. Can any user access or use the functionality? Or is functionality restricted only to certain users. If so, which users can or cannot perform this functionality?If the team is planning on automating tests for a web-based application, do all the pages have atag and all objects and images have an ID or name that the automation tool will recognize? Do you have the right tools to test this requirement? For example, if the requirement is that the system must support 10,000 concurrent users, how will you verify this? If there is a requirement that the system must run on different browsers or mobile devices, do you have access to those browsers and devices? What versions of each browser will you need to test? QA team members know how to test to make sure the customer’s requirements are met by using critical thinking skills, attention to detail, and curiosity. Testers can utilize these skills and techniques to help teams achieve consensus on project requirements. By involving QA early in the software development process and “testing” the requirements QA can help the team do the right thing, the right way, the first time.

Sign up for our blog updates!