Customer Experience, Outsourced Engineering Team, Successful Outsourcing
The show must go on: Developing a venue booking app with UPick
As the year winds down, it’s time to look back and celebrate all of our achievements of 2021, the challenges and the goals we conquered, and the clients whose projects we helped to become reality.
This time, let’s take a look at the story behind the development of the UPick app, which had the goal of creating a useful and reliable booking tool for both venues and artists, and how we helped them bring that dream from concept to a product you can use today. Enjoy!
What goes into making a good idea into reality? For the creators of UPick, it meant finding a reliable team that could build upon their idea, understand the concept completely, and offers the best technical know-how to bring it from paper into every smart device you can imagine. The beginning was simple enough; back in 2020, a couple of friends were looking into an area of opportunity no one else seemed to be exploring yet: what if you could simplify the process to book a show for a venue through an app?
The pandemic gave them a wide-open window to implement a solution for an industry that felt the consequences of this crisis deeply. Live shows account for nearly 50% of the music industry’s revenue, so six months into the pandemic, according to the World Economic Forum, shutdowns had already cost venues around the world 10 billion dollars in sponsorships and ticket sales, with no end in sight.
But with vaccination rates increasing, it was probably a good time to try and bring shows back, and UPick’s creators thought that an app that offered a quick way to reconnect performers with venues had some fertile ground to grow.
So, in February 2021 they started considering Scio as a partner, looking for developers who could create this app from scratch, decide the full scope of the final product, and make important decisions about the direction of the platform.
This was the first time our clients worked with Nearshore developers, and the advantages of having a fully experienced team equipped and ready to roll inside your own time zone became invaluable, keeping the costs of development down without sacrificing quality.
Since our clients had never been involved in a project of this size, constant communication to decide the specifics of UPick was critical, going from things like how to monetize the service, to the best hosting platforms to use.
Typically, development at Scio consists of a 5-step plan designed to arrive at a solution in the most productive way possible. Understanding users and their needs, as well as the objectives and constraints of the app itself, was Step 1. Step 2 involved analyzing the requirements of the app in order to trace a plan for the UX/UI and architecture of the platform. Then, Step 3 is pure Agile Development, up to the official launch, which was Step 4. And after the kick-off, is a matter of support to ensure the quality of the app, giving ongoing maintenance and adding features as a Step 5.
The Scioneers chosen were a Programming Lead who developed the architecture of the app, a UI designer tasked with creating a comfortable and stylish interface, another one assigned to create a search bar and review functions within the app, and a QA lead who would make sure everything worked perfectly.
Communication was key. Thanks to daily scrums, a core pillar of our process, we walked our client through the progress of the project, needing nothing more than 15 minutes every day to discuss the changes and challenges that surfaced, as well as what we accomplished, every week.
Here, we solved tons of questions born during development, like “how will a band schedule a show?”, “how will refunds work?”, and “how will the venues and bands make deals?” to more technical matters, like choosing a cost-effective hosting solution (AWS in our case), implementing login credentials from Apple, Spotify, and social media (including some necessary workarounds), to selecting the best payment processor.
Also, as we briefly mentioned, the business plan of the app had to be revised entirely once the booking process was decided, as Upick could easily be cut out from the deal between venue and performer, and our team took care of that.
The biggest breakthrough was deciding to make UPick a “progressive application”, where a web portal could function as an app with consistency across devices, like desktops and smartphones, making it as convenient as possible.
Then features were added, like the ability to share photos, videos, setlists, and even playlists from Spotify, and we had to rethink the way bands could contact venues as our understanding of these deals grew.
Progress went smoothly until finally reaching our Minimum Viable Product, where one of UPick’s users, whom the client showed a preview, managed to run all of their bands through the platform before it was 100% finished, which not only showcases the talent of our team but also made the customer base excited about the final product.
All in all, by September the app was ready to be launched, a whole project contained within the chaotic year of 2021, where Scio was able to offer the exact solutions UPick was looking for. A learning experience for both our team and our clients, we celebrate the effectiveness of Nearshore development, which can deliver no matter the circumstances.
The Key Takeaways:
- Since communication is crucial to make a product succeed, choose a development option that can communicate with you at the best time possible.
- It doesn’t matter if the details of your idea haven’t been ironed out yet, a good team will help you with those decisions.
- Development time of an app, depending on scope, doesn’t have to be too long. It took us around nine months to bring UPick from concept to reality.
- Some APIs are not very friendly, but there are always workarounds to any obstacle.
- If better ideas surge during development, it’s good to always voice them. The schedule might need to be reworked, but the final product is always going to be better.
Agile Methodology, Customer Experience, Project Management, Successful Outsourcing
If you search on the Internet for «agile project initiation» you are going to find a LOT of templates. People want structure and easy answers, so of course, these simple answers rise to the top of every search. Many (if not most) of the templates offered are pared-down formats from the Project Management Book of Knowledge (PMBOK) Project Initiation Documents (PID). There is nothing basically wrong with the idea of using templates or most of the templates offered, except – they tend to become prescriptive when they should be taken as guidance.
From the Agile Manifesto: «…we have come to value:
Working software over comprehensive documentation,»
With that in mind, we should ask – why do we document agile projects? Often, the answer is – because it is required (by someone) when in reality the answer should be – to communicate. But again, that simple answer fails to guide us to the necessary outcome:
- Documentation should be a natural part of agile project initiation, but not the goal. It should proceed from on-going discussions between stakeholders, the product owner and the development team that is developed in Sprint 0, but it must not end there. The conversations and the documentation of outcomes must continue through the lifecycle of the project and the product.
-
Initial documentation is just a strawman
Documents gathered from product owners and key stakeholders are starting points, not final documents. Documents developed by a designated team member to fill out a template are strawmen to be examined, discussed, questioned, and used as a base for the ongoing development of understanding within the entire project team.
- Living documentation formats should be preferred over static. In smaller projects, it may not be necessary to manage documentation formally, but in most cases using the same concepts as those used for source code management is a valid guideline. Properly maintained, living documentation answers the questions, «when was this decision made? by whom?» and gives a revision history that tells the story when necessary, but only makes it apparent when needed. It needs to include simple artifacts of these discussions – photographs of whiteboards, screenshots of modified mockups, etc. – in preference to notes developed after the fact and out of the sight of the team.
- During Sprint 0, the aim must be to develop enough trust among the project team members to allow questions and dialog to form the base for a common understanding of those items that are included in most PID templates. If initial documentation is «handed down from on high» to team members without open, trusting discussion – it cannot be internalized by the team and it will not respond to the inevitable changes that will come as discovery and learning continue throughout the project. Agile software development embraces change by allowing the project team to recognize the inconsistencies and discoveries that will come out during development, surface them and deal with their impact through discussion and collaborative negotiation.
And before we get too far away from it – there are some really strong ideas in the Agile Modeling page on Agile/Lean Documentation. Honestly, though, there is a lot of information in that reference that should really be digested as a part of understanding agile, not as a guideline for a new project. For that purpose, this short piece is a better resource. But, if the outcome of project initiation is not a bunch of filled out PID templates that we can all take back to our cubicles and file away – What is it?
Agile Project Initiation is All About Communication
With the ideas we have mentioned in mind, we have to acknowledge that open, trusting, collaborative communication does not happen automatically in an agile project team. There are natural stages that every group will go through before they can have the kind open discussion needed without fearing it will harm relationships and respect. Discussions need to be wider than the project infrastructure, technology, and user stories, without the feeling an individual is stepping over the boundaries by asking about non-functional issues. We might need to know:
- Does the culture and background of key user profiles matter to the software development team?
- Does the role of key subject matter experts (SMEs) in product development for an organization make a difference to who needs to be included in discussions?
- Are we using a Lean Product Development model with the inclusion of stakeholder users as part of Minimum Viable Product (MVP) development?
- If we are working in a DevOps implementation, how does that change our standard production procedures?
There are all sorts of questions that are not (and cannot be) included in standard PID templates but could be critical to a specific project. If we don’t discuss our viewpoints and ask questions, we run the risk of assuming we have a common understanding and making decisions based on those assumptions. Every project, every team, every organization is different. In the best case, we can open ourselves up to collaborative discussion by getting the team together, face-to-face during project initiation, for dialog and team building using team games and facilitation with a bias to being productive, explorative, and fun. Using these techniques, we can strengthen the bonds and shared risks necessary to maintain a successful project throughout its lifecycle.
In cases where face-to-face project initiation is not possible (hopefully more rare than the rule), much can be accomplished with video/voice meetings if they are relatively short and like agile documentation, structured just enough to ensure the meetings reach necessary outcomes and allow for continued direct discussions among stakeholders in the team when needed. There is nothing much worse than sitting in a meeting where a long, passionate discussion between two team members seems to be sucking all the air out of the room – and the meeting outcomes are lost.
This piece is relatively short and again, more of a guideline than a prescription for agile project initiation, as it should be if we are to «eat our own dog food.» Bottom line:
- Don’t be afraid to pull out a template when you start your next project, or when you look at it – crumple it up and throw it away so you can start your own list based on what you know and don’t know.
- What you think you know or don’t know are assumptions and should be treated as such both during project initiation and throughout the project. Only a discussion with open questions between team members can validate ideas and give us a basis for moving forward. And the assumption that is understood as valid today may not be completely correct at another time.
- Documentation must be limited to what is necessary when it is necessary and maintained throughout the project as living knowledge. Agile documentation should not be the domain of one person or one role. It must be available and dynamic – allowing everyone on the team to contribute when necessary – in a wiki-style rather than as a bunch of locked Word documents.
- Agile project initiation should focus on both the productive side – bringing together the information needed to organize the project, initialize environments, and the functional user stories needed, as well as the people/team side – developing the understanding, trust, and communication necessary to work collaboratively throughout the project. Ignoring either side is perilous. Assuming the job is done at the end of Sprint 0 is fatal.
Scio is a vendor of agile, nearshore services for software development projects with our customer base in North America. We can provide project-based or dedicated teams as required for each situation. We would be glad to discuss how our broad base of experience and skills could help you be successful with your next project. Contact us for more information.
Agile Methodology, Customer Experience, Outsourced Engineering Team, Product Development, Project Management, Successful Outsourcing
Of course, the first question for anyone looking at this is – what is the difference? Let’s start by saying that we’re not speaking specifically about “product engineering” – although it plays a part in this discussion. We’re actually looking at software development teams broadly, how they work and what they can (and can’t) do for your development efforts.
Today’s IT environments can be complicated beasts – with unique mixes of internal and remote API’s, web services, service-based components, virtualized infrastructure, and various open source, proprietary and custom applications. Orchestrating this architecture to provide the internal and external business services for an organization is an increasingly critical operational concern. Depending on the size and complexity of the environment, it is likely to be managed by one or more skilled engineers who are focused on the security, standardization, automation, scalability, availability and reliability of IT systems.
Traditionally, software development teams have been separated from this complexity to some degree by internal standards for application architecture and operation developed by IT. But, as the maturity of IT environments has progressed and agile has become the standard of the tech industry, software development teams are gradually being integrated into combined engineering and engineering teams under DevOps implementations. At this point, there are many different levels of integration between IT engineering and software development teams and if you are considering outsourcing a project – knowing what you are asking for is an important part of your research and decision process.
So, let’s set up a scenario: You are about to embark on a custom software development project. For the sake of this discussion, let’s assume the application to be developed is strategic and tied to your business model. With so many applications and systems available on the market, if it wasn’t – you would probably just adapt an off-the-shelf application for your purpose. You have a charter and description of the business problems your custom application needs to address, a general budget and executive support. The decision has been made to outsource this project rather than do it in-house.
With that in mind, let’s insert some different conditions that could make a significant difference in your needs for an outsourced team:
- New, but fully-backed venture with basic organizational structure but with no IT engineering beyond office systems automation and help desk.
- Existing IT team with legacy experience but little experience with modern infrastructure or IT operation patterns. No dedicated development team or significant custom applications.
- Traditional operations, IT and software development but siloed – not integrated other than by operational standards.
- An enterprise-level organization with a fully-integrated IT operations and development team in a DevOps style implementation with a significant portfolio of custom applications that are under continuous development and/or maintenance.
- A new venture of an existing entity that is expected to operate as a free-standing organization based to a large extent on the services provided by the new application(s) developed during the project.
There are other complexities we could imagine, but for the most part, they can be addressed as variations of these five scenarios and the basic conditions we set up for this discussion.
1. The New, Mostly Naked, Venture
As a new and growing company, there is always (or there should be) pressure to be efficient and do things right from the beginning. If you have a technical leader in your team and/or a significant part of your operation is based on leveraging software applications to provide your services, there is a natural tension – should you focus on your customers, your value proposition and lead your software development at the product level (leaving the actual development to an outsourcing partner), or should you build and control everything in-house? We’ve covered this question before and it is a significant decision – but now, we’re considering a little deeper level of thought. If you are considering an application that will actually support all or a significant part of the services you offer and your revenue – the proper operation and maintenance of that application is a strategic decision.
Your application must be:
- Planned with a set of operational standards in mind.
- Scalable, so it can grow along with your business without significant rewrites and basic changes in architecture.
- Logically broken into maintainable and extensible modules so it can be enhanced and the value of individual services can increase as they find their place in your portfolio.
- Reliable across upgrades, changing loads, and new features through the full product lifecycle.
- Economical to operate and maintain based on a solid architecture and the ability to leverage automation across all levels of development, deployment, and maintenance.
Photoshoot at Cluster 8/1/16
If you are a new venture and you want to spend your time focusing on your customer, the value of your services, and managing feature-fit, you shouldn’t expect an outsourced development team to simply take on these issues from day one. They may deliver a wonderful application that provides everything you need, except the five points above. Although your customers will be happy, you have just purchased a load of technical debt. Like any loan, it will come due at some point and the longer you wait to deal with these shortcomings – the more expensive they will be to retire.
So as an entrepreneur with enough problems on your plate, you have a choice (remember – our scenario is that you’re going to outsource this project):
- Dig in and hire a really competent engineering team that has real world experience in larger operations and understands where you are going. It is going to be expensive, time-consuming and at times – frustrating. You will have more expertise sitting around than you need in the early days, but it is an investment you need to make in lieu of the cost of redoing much of your early work when all your predictions come true. You don’t want to have to operate your business while changing the undercarriage as it speeds down the road. Once you have your engineering team and they understand your business model and where you are headed, they can manage your outsourced development team – but with both sides being new to you it is likely to be a fairly inefficient match in the beginning. Expect six to nine months to hire, train, and begin your project and another period of time integrating your outsourced team (which you also have to select) and your in-house engineering to the point where the combined team can be productive.
- Find an outsourcing partner that can provide the engineering skills as a part of the team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. The application should be designed with the five points above in mind from the start. If the vendor operates as a partner with your organization, doing that part of the development and operation successfully is part of their value proposition to you. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. Finding the right vendor will not be as quick as it might be if you were only looking for an outsourced development team (there are many pretenders in the field), but in the end, you should be able to get your project running faster, with better efficiency, lower cost, and risk.
The choice is yours and (of course) there are other factors you may have to consider in your situation – but at a high level, if cost, time-to-market, and lowering distractions from your emerging business are concerning, an outsourced engineering and development team would seem to be a strong option.
2. Existing IT Team, No Internal Software Development Team & Little or No Current Experience with Custom Apps and Modern Infrastructure
At first, this would seem to be a simple match for an outsourced development team – and in some cases it may be. But, the lack of current experience with custom application development and modern infrastructure in this situation should be concerning. Companies in this position tend to be service-based, SMB/E organizations with established client bases, regional strength in their market and a strong, competitive need to grow. As we pointed out at the beginning, we are assuming there is a budget for this project and the company is committed to outsourcing but – they have an existing market and they can’t afford to burn their existing customers while they transition to a new or expanded level of services. Because of that limitation, even without considering the eventual operation and maintenance of the new application once it is released, an organization in this position can’t afford to overburden their existing staff with development of a mission-critical, custom application and the operational planning needed while they continue to serve and maintain their existing services. The staff must be involved in the changes but only to the extent that they need to be to be able to take a role as things move forward.
Again, we come down to some choices:
Hire one or two technical leads/product and project managers who will take the position of planning the new application, its architecture, and operational requirements while managing the outsourced development team. They will need to be much more experienced than the existing IT team so there will be some initial friction and it will (again) take time, be costly and frustrating. It will take time to get them up to speed and integrated into the team before an outsourced development team can be selected and put to work. The reason to use only one or two resources, in this case, is to hold down costs, but doing so will only make each resource more critical and (probably) more expensive.
- Hire outside consultants to develop the operational architecture, requirements and train your internal team. Since the internal team is unlikely to be large or have the skills necessary, there will still be a need to hire additional internal resources, but it can be delayed to some extent. The downside of this strategy is that when experienced staff is added eventually, they may or may not agree with the direction put in place by the consultants and there may be a period of realignment and unexpected technical debt. Also, the use of external consultants to manage all or part of the work done by the outsourced development team can create an “arms length” relationship with the development team that can make it difficult to have the level of collaboration and trust you need to avoid communication problems, especially with agile development.
- Find an outsourcing partner that can provide the engineering talent as a part them team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. If you want to transition the outsourced team out at some point, you will still need to hire additional staff for operations and maintenance of your new applications, but you should be able to have them work in parallel with your outsourced team during the transition and lower the burden significantly.
Any of the three options could be successful but if you find the right outsourcing vendor, it would be a faster, less costly and less risky route to get your project going. But, of course, it depends on finding an outsourcing vendor with the option to include engineering skills in their team and to have a flexible approach to providing the team you need.
3. Siloed Operations, IT & Software Development Teams
This scenario lends itself to slightly larger and more technically-based operations than we discussed in the second scenario. This is the type of organization we expect to find in an established ISV with a strong client list in a specific vertical. Their operations are usually as they have been for a decade or more. Their IT staff is established and has a strong operational base. Their software development team is well-versed in their existing applications, the technologies they use and the customer base they work with. If they didn’t have to step out of that box to build this new application, we can easily assume they wouldn’t need to outsource and their engineering is just fine for what they are doing today.
But that is the rub. We’re examining a scenario where they need to extend themselves into new technologies and possibly change their operations significantly. And because we’re assuming their teams are informal, separate silos – we’re also assuming they know about the higher efficiencies they could achieve if they began to shift to a DevOps methodology but – again, like our second scenario, they have existing customers and products/services in the field to maintain and support. Like most companies in this situation, their backlog of feature requests for their existing software is just what they can handle at the moment. Adding another layer of work would just mean something would have to give. An outsourced development team, in this case, makes sense and this organization is likely to have customer-facing product development well-in-hand. But, what they don’t have is a scalable organization to match the importance of the project and a broad understanding of new technologies and architectures they need to consider to streamline their organization.
So, in this case, an outsourcing vendor who can bring in engineering experience as a part of their team skill and experience, a flexible, scalable team makeup and willingness to work in a partner role to help their existing team rethink and realign their operations could be a real asset. It is risky to try to do both at once with the same team, but if both teams have regular work to do and can collaborate to adapt operations over time it can be an opportunity that would be nearly impossible any other way. Again, the critical step is to have the skilled resources available as an integrated part of the team who can lead the effort to plan architecture and operations before development gets underway and you find that serious adjustment is needed. There are risks in this scenario, certainly, but there is also an upside to making changes in parallel with everyone onboard the organizational development and change initiative.
4. Mature Enterprise with Integrated DevOps style IT and Software Development
Again, we’ve moved the situation up the scale a bit but we’re still committed to outsourcing and we’re still considering what type of a team we need. In this case, the internal team has an implementation of DevOps and even if it is not complete, it is moving forward with staff support and commitment. Like scenarios two and three, our existing team has a number of custom applications in production and knows what it is doing when it comes to operations and development. We can assume they are fully engaged and the time allotted to this project is short, or they would simply hire as needed and do the project internally.
Since this organization has a DevOps implementation, there is already an assumption that new development resources will have experience in both development and systems architecture for continuous development and maintenance. Bringing on a team that doesn’t have that type of cross-functional experience and mindset would be a serious problem. They simply wouldn’t be able to hold up their end. In this case, if the project is to be outsourced, the incoming team must be able to handle both engineering and agile software development if they are going to hold up their end and integrate with the larger team successfully.
5. Spin Out/Off Venture with Software-Based Service
You might think this scenario would be a lot like the first, but spin-out ventures tend to be better positioned and planned simply because they usually come from organizations with a strong market position and goals that are carefully evaluated before the venture is started. In most cases, staff members come from the “mother ship” with a background in product development and deep understanding of the market they are going into. But, because the loss of technical resources inside the home organization could seriously impact production there for a prolonged period, they rarely pull out more than a few senior IT resources. With that in mind, their team is usually fully aware of current technologies and methodologies, even when they may come from an organization that culturally has not be able to move to them as quickly as they might wish.
A spin-out gives this core team an opportunity to move in fresh directions with less organizational baggage and legacy overhead. So, in some ways, they may look like scenario two with little IT in the beginning – but the big difference is they have experience in the product development side of custom software and how supporting systems can be orchestrated. They are better positioned to evaluate partners and decide on the roles they want in-house versus outsourced. Since we said at the beginning that all scenarios would be based on a decision to outsource – the question is still, “Do we just need an outsourced software development team or do we also need an integrated engineering component?”
The decision comes down to how much of the burden the mother organization wants to continue to shoulder and how expensive the “charge-backs” would be if they did. Leaders of spin-outs usually have strong stock incentives to keep costs in line and move relatively quickly to prove their direction is worthy of the risk. If using existing services inside their home company would create complications, slow product development, and increase costs – they will think twice about that direction. Since we have specified that they have already decided to outsource this project, we can assume they are not looking to spend any time taking on problems that do not get their services and products into the market. But that said, we know the IT resources in the venture are limited and if they want to go to a modern continuous release methodology so they can incrementally improve and tune their applications, they will need to have flexible, integrated teams of engineers and developers from the beginning so that their applications are architecturally and operationally sound from the beginning.
Bottom Line
The bottom line here is that software development is shifting away from internally-focused product development, siloed enterprise teams and monolithic applications to incremental release patterns, agile organizations, and customer-focused lean product development. Not everyone is there now. There are many different ways to implement change. But, all of these organizations have chosen to take on custom application development for a strategic initiative, the opportunity now is to do it better with an eye toward the future of their organization. This is just one small part of the change they seek, but it is an important one to consider. So, yes – an outsourced team that brings a range of engineering skills and experience along with their development background can be a big advantage for any of these situations, with a vendor who will operate as a partner in the organization.
Scio provides nearshore, outsourced software development and flexible teams with a range of software development and engineering skills based on our experience in many verticals and situations. Our teams can have flexible roles and their bias is toward agile methodologies broadly. If you have a project in mind, please contact us to discuss how our unique blend of skills and experience can benefit your organization. We would be happy to take the time to listen and provide insight into how we could partner for success.
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management, Successful Outsourcing
Lean Product Development (or Design), LPD, is gradually becoming a standard methodology in software development in much the same way that agile, scrum and lean have become industry standards. But, as is the case with other «standards» – many people say they have strong implementations, but if your product development team practices LPD principles, you might have trouble trying to integrate their approach. That problem can be troubling if you’ve invested in a rigorous, repeatable process for developing and releasing new software products and then find it difficult to find outsourcing services who understand your goals, your process and can work alongside your team seamlessly.
If you have software applications as a part of your services portfolio or directly to clients and use LPD methodologies, it is important to fully integrate your development team. But, if you are using an outsourcing service, what should you expect? How important is it to integrate your outsourced team?
A Little Level-Setting
In strict thinking, although the term «LPD» is used interchangeably for design and development, there are some differences in focus between the two in implementation. Both are based on Lean, the principles that started with Toyota Manufacturing and have evolved to embrace a process of finding solutions to customer problems that emphasizes iteration, reducing waste, and lowering risk. Broadly, both are informed by the Lean Startup Methodology, but because LPD has been adopted by many large organizations for the development of service and product lines, lessons from Lean Startup are brought down to the product level, rather than at a business model level as they are for startups. And, because we are specifically interested in services, software and software development, rather than manufacturing and the development of physical products, we can include the fact that all LPD implementations favor the use of agile, scrum and kanban as development methodologies.
As you might guess from the use of the word design, Lean Product Design implementations are focused on the design of the product, the user interface (UI) in software development terms and how the user interacts with the application. A process flow for a design implementation includes a growing system of sketches of screens (or modules), wireframes and design standards that evolve and become more specific as software development progresses through iterations.
Lean Product Development implementations tend to focus on the features required to satisfy user needs and product goals. So, while both implementations will use agile user story techniques, design-based implementations will be placed more in the context of the UI and user experience. Development implementations will focus more on groups of features and user goals. In practice, the differences between the two are relatively small and depend more on the full project team and their process than anything. A development team with clients that tend to be more visual, literal and unsure of needs may find it easier to be design-focused. A team with clients working on a business process and users with strong, informed opinions may find it easier to be more development-focused. And certainly, there are many blends of the two ways of thinking.
So, What Does This Mean?
There are many software applications that embody process and principles from a software product management point of view. How will they work for you if you decide to use an outsourced software development partner to help bring your application to market? Is one or the other better for software applications or integrating with software development teams? Are there methodologies or points to emphasize with potential partners as you discuss how their product development approach and experience?
From a high level, if your potential vendor has good product development experience and understands the product development cycle fully, the software you use for product management and the implementation of agile they use within their software development process shouldn’t matter a great deal – because they should be able to be flexible and do what is necessary to integrate the teams. If they are using something out of a book or a seminar that they have actually practiced a few times with a client – and that client wasn’t themselves fully committed to formal product management – it will be a distracting challenge for both teams to work through a methodology implementation while developing your application.
5 Questions for Your Potential Partner
Let’s start with a few questions to discuss. And a word about interviews: Don’t ask yes or no questions when you are investigating how a vendor operates and works with clients. Instead, ask open-ended questions that should be answered with more than a few words (if they actually have experience and formal services around the area they are discussing). If you don’t get what you feel is a strong answer, again, ask some open-ended questions that go down a level in detail.
1. Tell me about how you use agile in projects with clients practicing Lean Product Development?
The question here is not «do you use agile?» You need to know how agile informs their work with companies practicing LPD and what value they believe their implementation brings their customers. They should also include their practices within agile, such as scrum, extreme programming (XP), or kanban. If they don’t go into this level, ask another open-ended question for more detail.
One of the many implementations that large organizations have used.
In most cases, scrum will be the task management and basic development guideline, but it may be extended by XP practices. Some teams will be familiar with kanban and some will mention that they might start with scrum and transition to kanban if the project uses a DevOps implementation aimed at continuous development. At a high-level, the choice between scrum and kanban comes down to a philosophy about work and how to manage tasks. Scrum is generally considered to be more structured, using time-boxed iterations (sprints) and depending on the team to properly estimate tasks for each sprint and with specific planning and retrospective sessions for managing task backlog and priorities. Kanban tends to limit the number of tasks a team can have in work at the same time and new tasks are pulled down into development as soon as a slot opens up in the queue. Kanban is generally more flexible for the insertion of new features and less structured, requiring more feature management to avoid creep before the base application is completed.
It is only a guideline, but most teams find scrum to be a good system in application development and might use kanban or a variation after full release when the application is in maintenance or continuous development. Again, team familiarity and experience in adjusting their «standard» implementation to your team is more important than the particular flavor of the methodology they are using. Process mockups and walkthroughs of feature and feedback flow between the teams is an excellent way to evaluate how things might work and adjust to situations.
2. How do you understand the MVP process in lean product development?
Iterative development of a minimum viable product (MVP) is critical in LPD and probably one of the least understood parts of the cycle by non-practitioners. It is also very hard to estimate effort and time for the development team because it involves an open-ended process with key stakeholders and users. The key issue is to understand what they expect and how they will help you towards viable iterations for validation.
If their understanding is more like the top example in this illustration than the second, it is going to require some real thought to ensure you arrive at validation releases that are fully-formed (loveable) but not feature-rich or too simplistic. This is an element of your work as a whole team where you can really assess the ability of your outsourced team to work fully as a partner in product development. Can they come up with creative ways to give a good representation of the core product to users with less effort and time? Can they see the evolution of ideas and pick out key elements in customer feedback? If you expect or have to micro-manage every iteration yourself, you’re not getting a fully-prepared software development team.
3. How will we capture and manage user feedback during validation and following initial release?
Now, of course – a developer could just say, «This is your problem, not mine.» To a degree, they would be right, but you are looking for partner-level answers that indicate a willingness to do whatever is needed to make the product development process work properly and to be in position for the long run if your product is likely to benefit from a continuous development/improvement, DevOps-type release. Possible answers can be all over the board from add-on services that support help desk and application feedback to in-app custom modules. At a minimum, developers should be «in the loop» during validation and early release to assure that application bugs are not being reported as feature requests or issues and a system should be available to allow users to see proposed changes and «vote up or down» features they would value.
Including the development team in the feedback loop has a cost, but it avoids a lot of thrash when a feature is not working as expected, allows the developers to be proactive with corrective actions and to understand needs directly from a user’s words, rather than summaries. Again, what you are looking for is not a specific answer but that your partner is willing and able to understand what you need from a product perspective and provide creative solutions.
4. What are our options for capturing user metrics?
This requirement is, of course, very similar to capturing user feedback, so solutions can range from custom reporting within the application to third-party services and application libraries. In this case, the richness of options is key so you can evaluate different aspects of customer acquisition, feature usage, time to complete a process, etc. These features don’t exist in «average» applications, but they can be added relatively easily during development, especially if you compare the effort required to add them at some later point. You will have to get into detail about the kinds of metrics you feel might be most useful for your application and situation, but a strong developer team should be able to give you a range of options for implementation and some sort of dashboard for generating reports.
5. What do you do to assure that quality issues don’t get in the way?
It may seem a bit off point to discuss quality in an LPD focused question set, but the quality is far and away one of the biggest issues when it comes to unexpected project delays. You can’t expect stakeholders and users to be fully engaged in the product development process if planned releases are delayed or major features don’t appear fully formed as promised. A really good application that is unstable or has a poorly designed user interface is a big distraction from the goals of LPD project.
The best answers to this question include test-driven development, test automation, continuous integration and the tools that could eventually come into play if you choose to go into continuous development. The best case is to make this decision upfront, but things don’t always work out that way. Your primary aim should be to ensure you are in a position to move to that level when you need to without backtracking or having less than full test coverage and to leverage quality assurance tools and processes proactively from the beginning. Your team should be able to focus on feature execution and user experience as they do their acceptance and not buggy code or user interface inconsistencies.
The answers to this question should cover many of the issues of how teams will work and communicate. If they don’t, push follow-up questions in that direction specifically. If you have read anything about outsourcing, you already know that successful agile teams require strong open dialog and collaboration. Don’t let easy answers push you off this point. Understand fully how your project will deal with quality, communication, and ownership of the project goals.
There are a lot more questions you could ask, but these should get you started. The point is to have a conversation with your prospective vendor and come to an understanding of the methodologies they have utilized, the capabilities they bring to the table, and the customer experience you can expect. A conversation can clear up a lot more issues than a written response to an RFI or a proposal for work and give you a better idea if this is a group you can see your team working with. If you are actually looking for a long term partner and not just a team for a short engagement, it would be wise to have that conversation in person – in your offices or theirs. If it requires some travel, it is just part of the expense of finding a good match. It is much better to have your first face-to-face meetings in a positive, forward-looking atmosphere than when a project is underway and you’ve realized that a lot needs to be done to iron out issues.
Scio is a vendor of outsourced, nearshore software development services to our clients in North America. We provide teams with a background in Lean Product Development as a part of our service portfolio. We use agile methodologies and adapt them to the situation and needs of our clients. If you are interested in how we could partner with your organization to build a great set of new products – Contact Us. We would be glad to take the time to discuss your needs.
Agile Methodology, Customer Experience, DevOps, Nearshore, Product Development, Project Management, Successful Outsourcing
Rotating team members on agile software development teams is a controversial subject. Some leaders in the agile community are strongly opposed to the idea and won’t consider it at any level. Others are open to the subject, but frankly too concerned about the possible downsides to actively plan rotations or even hint to their customers it might be a good idea. And of course, there are the wild-eyed optimists who claim it is the best idea possible for every situation.
Our focus for this article is dedicated teams – teams with members selected for their skills and reliability over the long run. Typically, dedicated teams have no set sunset. They are dedicated to a product or part of a product suite and they generally stay through the active development and maintenance of a product lifecycle – which for enterprise software maybe years. But, that said, the ideas that bring up the subject of rotating members of a dedicated team could apply to any long term project, especially with smaller (3-5 member) teams.
And let’s be honest about one other thing too: the longer the project or product lifecycle, the more likely it is there will be an «unplanned» member rotation. Births, deaths, illness, vacations, career advancements and changes – all sorts of life events have to be managed as a part of maintaining a dedicated team. Even if the time a member is away is relatively short, in less than two weeks, the impact on the productivity of a small team needs to be managed to continue to meet client schedules and expectations. In some cases, the remaining team members can sustain production for a period of time by adding additional hours daily and on weekends, but eventually, that will take a toll on their personal commitment to the team. And when there is an unplanned need to bring in a replacement, there are consequences to the team regardless of the additional manpower provided. In fact, it is well understood that if for some reason two members of a small team needed to be replaced over a short period of time, it would be catastrophic for the team. Bringing the new member «up-to-speed» with mentoring and knowledge transfer takes time and effort of other team members away from their work. And, there is the well-understood impact of a team «forming, storming, norming, and performing» cycles as described by Tuckman. Changing a member of a small team always creates issues. Without some planning and forethought – it can kill the effectiveness of a team for an extended period of time.
So – why would anyone want to consider the idea of rotating team members on dedicated agile teams?
- If unplanned changes in a dedicated team are going to happen anyway, why not be prepared? Why not have the process for selecting, integrating, training and mentoring a new team member planned, documented and tested before it actually happens? Why wouldn’t you want the expectation that «this can happen» and «this is how we deal with it» in place and in front of the team and the client from the beginning?
The longer a team works on a product, the more likely they are to develop «tunnel-vision.» They see the UI, but they become blind to the problems a new user might encounter trying to use it. They know there are newer technologies that might make something more efficient or resilient, but it takes time to test, advocate change, and demo the option to the client team. If what you have works, is it really worth the effort? The longer a team works together, the more «normal» the little quirks about a product become. In the long run, it can make them resistant to needed change and reluctant to suggest options.- Working with the same people, on the same product, eventually leads to a level of isolation that can begin to make it difficult to want to get started on the «same old stuff» each day. Developers are part of «geek culture» and love to see new technologies, get input from other sources and try «cool» things. When this happens, production slips and members of the team may become less committed to the success of the product they are working on. It doesn’t happen in a day; it is a slow drip that eventually eats away at the team and makes it less effective. It can also make individuals on the team consider career changes because they are afraid their resume will reflect stagnation rather than stability.
- Bringing in «fresh (but experienced) blood» can bring cross-pollination from other experiences, new points of view on coding practices and processes, a new look at alternatives as you move forward and other benefits from another set of eyes on the project. If long term members of the project are not ready to accept new ideas, they can create strong resistance, but if they are positively primed for the idea by considering they could also benefit individually and as a team, it can be a shot in the arm for the team.
- «Ownership» of a product, or an area of responsibility, can be a strong motivator for a team. Their understanding of its deeper value and continued success is part of their pride and keeps the team on track. But, there is also a downside. If the team is the single point of knowledge and «truth» for a product, they are also the single point of failure. If there is no base of knowledge about the product outside of the team, in the wider pool of developers around them, there is no way to replace a team member easily or help them if there is a problem that causes a loss of a member or if the team runs into a serious internal disagreement (it does happen).
- Operationally, these long-term teams become silos. Outside the team, they are the go-to subject matter experts that always have the answers. Inside the team, individuals tend to become specialists, filling a niche that no one else can come close to. This not only runs against the whole concept of «agile organizations» – it becomes a growing risk within the organization.
There are more reasons too – but those concerns represent some of the more common drivers of the idea. They are all real issues and the problems the teams dealing with them have an impact on the projects they are in. But – does planned rotation actually solve the problems? Does the upside outweigh the downsides? Can rotation be planned well enough to overcome internal team dynamics? Will the supposed benefits last long enough to make rotations something you want to do? Can you actually present a case that would make client support, rather than oppose, the practice?
The answer would have to be – it all depends on implementation.
- Like any change, member rotations have to be sold internally before they can be implemented.
- Frank conversations about the health of teams, experiences in long term engagements have to be surfaced and alternative solutions have to be discussed.
- The timing and requirements for new members have to be considered and accepted by the existing team members. Simply dumping the idea on them without preparation is sure to bring disaster.
- The level of the incoming team member will make a difference in acceptance. Replacing a senior member with another senior developer may be more difficult than bringing in a mid-level or junior developer in their place. With less seniority, the new member will have lower expectations and less to live up to. They will be more accepting during knowledge transfer and mentoring and give existing team members new opportunities to grow. But if the outgoing member is considered to be a team leader, the impact may be very deep no matter who is brought in.
- If the practice is fairly new within the organization, replacing a team member is likely to be more problematic regardless of planning and thought. The practice can be new institutionally or within the team, it really doesn’t matter. If team members are not experienced with the concept, issues will arise. Assuming the issue will iron themselves out eventually is not a good way to manage change.
- Frequency is important. Single-member rotation will always cause thrash and lost productivity no matter how well it is planned. A team can only sustain so much change without becoming distracted and losing their center. In complex environments, it may take a considerable time for a new member to build up the necessary knowledge base. Most industry experience seems to circle around a period between six and nine months for the change of one member. More than that and the team might never gain cohesion again. Less than that and silos will begin to form. But, there is no perfect point. You can’t change a member during a critical release for a product, no matter what the calendar says. You have to work with the client team to gain acceptance and cooperation. Timing is a hard nut to crack and will be different in every situation.
This is an important and evolving area of management for outsourced agile teams. It is not widely discussed in the software development industry. Clients come to outsourcing vendors to avoid issues like team cohesion, resilience, and long-term stability. It may be difficult to bring them into a conversation about an issue that is seen as a vendor responsibility.
But, there are some ideas that are coming forward and worth considering. Larger outsourcing vendors can propose a dedicated «pool» rather than a team. The actual team in production continues to be a small number, but the vendor commits to a larger group, perhaps 7-10 including the active team, of developers that are involved and can become a team member with less overhead from change. This allows the members of the pool to become involved in project and product discussions, review code, and be the sounding board for ideas. There has to be an adjustment of the cost to allow this kind of an arrangement and a clear commitment by the vendor to avoiding the issues that are considered part of dedicated team contracts, but in certain situations, it is worth considering.
In the final analysis, it is hard to value the practice of rotating team members on dedicated teams. It can seem like a great idea if you have experienced the downsides of long-term engagements where unplanned changes and team stagnation become barriers to success. If the motivation, implementation, and outcomes are not carefully considered and monitored, it can become a serious distraction from productive development. Neither outcome is good so this is an important consideration and the decisions are likely to be different in every situation.
If you have experience with team member rotation (and not just fears or wild optimism) – I would be interested to hear your thoughts. This is still an unsettled area in agile team dynamics.
Scio is a provider of outsourced, dedicated and project teams for agile software development to our nearshore clients in North America. We have experience with many team and project configurations and would love to discuss how we could help with your next project. Please contact us with your questions.
