Embed Size (px)
Citation preview
GettingsoftwareRight
Notes from the FieldVol. 1
1
Ensuring Successful OutcomesTo help our clients with the development of world-class software, we’ve created a series of papers called “Notes from the Field”. They cover a variety of topics and distill inputs from Tiempo team members that have spent their entire careers building software that “makes
lives better”. In this installment, we address the ever-present topics of:
Why software initiatives can fall short of clients’expectations.
Advice you should take to ensure outstanding outcomes.
We’ve aggregated over 40 pieces of candid guidance from scrum masters, project managers, developers, testers and others that have lived in the trenches with all kinds of development projects, large and small. You’ll see some tried and true advice, some common threads and maybe a few surprises and insights that can help guide your development efforts in the fu-
ture. We hope you enjoy.
“The more involved the clients are,the better the software.”
“Poor definition of the requirements, including “badly written user stories” are always problematic. These challenges normally come from not properly understanding the business needs and the market from the end user’s perspective. Poor understanding of requirements leads to continuous changes during development. And, while changes are always welcomed in an agile environment, changes should come from new discoveries that can provide an advantage to the business, not to patch poor research and lack of business knowledge.”
Francisco PonceDirector of Software Delivery
“The clients really need to be part of the team. They should be as involved as much as possible in the entire process. The moreinvolved the clients are, the better the software.”
Martin SánchezSoftware Engineer IV
”In my personal experience, I have seen initiatives that are oversold – only the benefits and positives were discussed with the client.
Good partners do not omit discussions regarding potential risks, issues, obstacles, and resistance to change that are associated with many new software initiatives.
Jessica VegaSenior Test Engineer
NOTES FROM THE FIELD VOL. 1 3
“My advice would be to give the development partnermaximum participation in the planning, architecture and product review before starting work. It’s important to have a broader vision of the scope to help manage resources and timelines.“
“The main reason I see for not meeting the client’s expec-tations is lack of clarity in the requirements. Many times, companies must comply with aggressive commitments in terms of time and work to be completed, and as serviceproviders we must align ourselves with those commit-ments. Inadequate planning and understanding can requiredevelopers to work in a reactive way, which is not ideal.”
Ricardo AnguloEngagement and Release Manager
““I recommend that teams should stop for adequate planning between each release - this has proven to be a very effective way to accom-plish outstanding outcomes. With one of our successful clients, we have quarterly releases, but in between releases, we take two whole weeks to plan, identify dependencies and quantify effort for the next features. This has allowed us to meet our goals while identifying risks to be managed.”
Gerardo González, Software Engineer Lead
“Miscommunication and poor teamwork can be common issues when outcomes don’t meet expectations”.
Paul Estrada, Software Engineer Lead
NOTES FROM THE FIELD VOL. 1 4
“My advice to clients is they always set the correct scope andexpectations around functional and non-functional requirements. If the client requires any type of work on an existing application, then a Technical Analysis should be executed. This enables the proposal of a new technical solution. On the other hand, ifdevelopment is from scratch, then the technical analysis becomes less complex and a technical proposal can be defined.
In general, I recommend clients follow the Scrum methodology around a clean and workable backlog and deploy high performing teams that can execute around the backlog. The high performing team should include a variety of roles including Scrum Master, Product Owner, Architects, Tech Leads, Engagement ReleaseManagers, Directors of Software Delivery, Developers, Quality Assurance and DevOps.”
Javier TreviñoDTS
“Expectations for functionality should be accurately set with ALL key stakeholders at the onset of a project.”
Erika ArellanoHR Manager
“Time management is always critical when developing software, but do not forfeit dev environments, testing and deploymentprocesses. Sometimes it may seem like this is not necessary or it takes too much time, but in the long run it ALWAYS pays off.”
Pedro GonzálezIT Engineer
NOTES FROM THE FIELD VOL. 1 5
“In my experience, we run into problems when there is 1) improper tracking to detect deviations from the plan, and 2) inadequate definitions or mechanism to get to well defined and market-vetted requirements.”
Francisco PerezScrum Master
“The clients team and external development team should act as one cohesive unit. Ideally these teams should be considered equal during the whole development process that includes planning, approaches, implementations and even celebrations. All opinions matter and all team members should be heard. Doing so instills ownership across the team that adds extra value.
Rodolfo Carmona, Scrum Master
“Creating positive outcomes requires a holistic approach on all phases of SDLC and it all starts with having a robust product vision, goal and roadmap.
There are many reasons initiatives don’t meet stakeholderexpectations, but most of them in my experience are created in the early stages. It’s important to identify the version of MVP that will have the most positive impact on ROI, and then determine the next best features to iterate.
The next challenge becomes communication at all levels. When strategy doesn’t perfectly align with execution (from stakeholders/product management to development) deviations occur either on scope, purpose or priorities. This is when we start having miss-matches on expectations.
Additionally, not having the correct methodology and best practices for each initiative will eventually cause unfulfilled expectations. Therefore, we need to focus on having the best talent available to put best practices in place and avoiding landing on Maslow’s Law of the Instrument.”
Angel Almada, Director Of Software Delivery
“Two pieces of advice I like to give to clients: Do not close your mind to change.
Yael Chavez, Software Engineer IV
“I have seen in my career times where capabilities were oversold – timeframes and resources required were underestimated. People involved in the project from both the client and developer side tried selling the perfect plan, but that kind ofperfection is only found in theoretical books.”
Jorge Millán, Software Engineer Lead
NOTES FROM THE FIELD VOL. 1 6
Trust more in technology. By doing these you will have better outcomes.”
“Software development requires teamwork.”
NOTES FROM THE FIELD VOL. 1 7
“In the ideal situation, the client is available to invest time in the development of their software and accept and actively support the implementation of best practices.”
José ArturoSenior Test Engineer
“Software development requires teamwork. And by that, I mean more than the “engineering team” – the team includes dataanalysts, product experts, stakeholders, and many others. The work starts much earlier than the first line of code. The better the Product Owner understands the clients’ needs, the market, the costsassociated with dates and compliance issues, the better and clearer the definition of the product before it arrives to the engineering team.”
Being able to quickly clarify the requirements and to properlyprioritize the features is the most important foundation of asoftware development project. Get this right, and the planningbecomes much easier, allowing the engineers to make the right technical decisions and implement the solution that will have the most value for end users.”
Francisco PonceDirector of Software Delivery
“At the end of the day, outcomes rely on having high-performing teams. No matter the methodology or the process, if you don’t have the right people, the final result will rarely meet the client’sexpectations.”
Martin SánchezSoftware Engineer IV
AT THE END OF THE DAY, OUTCOMES RELY
ON HAVING HIGH-PERFORMING TEAMS.
NOTES FROM THE FIELD VOL. 1 8
“Communication is key. Make sure all stakeholders are aware of and can access all the available communication channels like email, chat, support calls and proprietary platforms. Define responsibilities of key team members and remain strict to all team processes.
Always ask for feedback and discuss details with the team members before taking decisions that need action from the development team.”
Paul EstradaSoftware Engineer Lead
““Non-functional requirements are sometimes treated likesecond-class citizens when thinking of software. We care too much about what an application will do, but not enough about the application ecosystem. What is the typical user’s expertise level? Are they tech savvy? How fast do they expect the application to be? How many users are there? How many will there be in a year? How many in five years?
Jorge Gaona, Architect
“The quality of the team is one of the most important attributes of all. Make sure the team is well qualified and has all proper certifications and training.”
“Process is important. In my experience, I have seen cases where the team is not well prepared to follow the right process, follow the project targets, analyze the bugs report and keep track of time and budget. Projects should follow Agile methodologies and always be well organized.”
Jesús Rodríguez, Senior Test Engineer
COMMUNICATION IS KEY.
“Define and understand as well as possible the people that will be using the application. What are their motivations and needs? What do they consider mandatory and what features do they consider less important?”
“It often comes down to Customer Expectations. The teammembers with expertise should guide the project and expectations to provide a realistic view of what is possible and practical.”
Alejandro RuelasTest Lead / Senior Test Engineer
“I recommend that every client be as committed and involved in the project as possible. It is important that there is effective communi-cation with all members of the team - developers, managers, scrum masters and others. By actively communicating the client’s needs and expectations, the job gets easier for the team and has a more predictable outcome.
Sometimes high-level requirements are enough. The development team can make functional decisions. With one of our clients this is the case and the client is super happy. We develop software faster and they still get to see it in demo before we release it to production. The demo gives the client the opportunity to make revisions if they change their mind or something doesn’t work the way theyexpected.
In other cases, we’ll get very detailed and specific. We may ask the client a very trivial non-functional question like “”what header color do you prefer?” We do not only want to create software that will make clients’ lives better, but software that client’s love!
The bottom line is effectively and actively communicating client needs to the development team and then trusting them to make it happen.”
David AvalosTester IV
“We do not only want to create software that will make clients’ lives better, but software that client’s love!”
NOTES FROM THE FIELD VOL. 1 9
“Sometimes the client doesn’t have a technical team. This can make communication and understanding difficult. It’s important to have the right team members on both the client and developer side.”
Jonathan Andujo, Software Engineer IV
“Use agile methodologies, so you can add value to the end users in short increments of time. Agile results in a faster delivery of the product.
Ensure you choose the right partner, which has past-provenexperience delivering high-quality software with a well-defined agile strategy.”
Alejandro Rivera, Software Engineer
“Lack of vision can be a problem. Sometimes a client may not have a clear vision of what needs to be done or has a poor understanding of what to expect. When this is the case, the development team has not done its job.
Poor experience in new technologies and methodologies can create problems for both the developer and the client. Both parties must be open to hear and consider new and better ways.
Further, budgets that are not right-sized for the task at hand can often be problematic.”
Rodrigo Ruiz, Architect
“Simply put …. Establish clear requirements.”
Andres Fragoso, Dev III
“There are two big issues that I have seen throughout my career that can lead tounmet expectations. The first is not having requirements clearly defined. Thesecond is a poor decision to opt out of a thorough and formal testing process.”
César Galindo, Engagement and Release Manager
“Plan and think big. Break initiatives into small and easy to achieve but significant wins.”
Jorge Millán, Software Engineer Lead
NOTES FROM THE FIELD VOL. 1 10
“Both the client and the partner need to take ownership. The client needs to assume responsibility for collaborating with the developers on requirements and processes and working to eliminate potential bottlenecks. They should own the outcome.
Conversely, the development team should have enough engagement with the client and the high-level goals to add the most valuepossible. Poor development teams are unwilling to take the risk and accept ownership because it requires proactive communication and negotiation with the client. Like the client, the development team should own the outcome. In an ideal partnership, both parties should assume responsibility and take ownership.”
Rodolfo CarmonaScrum Master
NOTES FROM THE FIELD VOL. 1 11
“Sometimes customers are afraid of changes. It is incumbent on the service partner to help clients understand risks and all potential outcomes.”
Yael ChávezSoftware Engineer IV
“My advice is to develop a systemic vision of the product to bedeveloped. This vision should include understanding the trends of the markets and industries they serve, implementing agile at scale, and prioritizing features that maximize ROI while minimizing-time-to-market.
The proper technology needs to be selected to develop the product and best practices deployed such as coding standards, branching strategy, naming conventions, e2e testing process, go-live process, support, etc. All team members actively working on the product should have robust domain knowledge in order to generate aware-ness, take ownership and iterate over outcomes.”
Angel AlmadaDirector of Software Delivery
NOTES FROM THE FIELD VOL. 1 12
“The lack of adequate planning and release management of the product is what often causes problems. A good way to start is to visualize the final product and determine a good MVP path for it. It rarely can be accomplished in a single go; a phased approach is always the best way to get it done right, on time and on budget.”
Gerardo GonzálezSoftware Engineer Lead
““The teams should hold regular milestone meetings in order toreview the progress and accuracy of the work done and ask a few critical questions. Are we on the right path? What adjustments should we consider making?”
Octavio Islas, Senior Test Engineer
“Some clients lack commitment and have not allocated the required resources to the initiative. This makes it hard on the development team to understand what functionality will add the most value to the business.
Conversely, some development teams can lose focus on the main objective, which is always the same: “deliver software that adds value to the client’s business”. This goes beyond developers and includes managers, scrum master, leaders, testers and product owners.A single team member that lacks focus can affect the entire team.”
A common reason to not meet deadlines and budget is poor commu-nication between the client and the development team. If the client does not communicate well, incorrect functionality might be built. This can cause re-work and time delays. If the development team does not communicate to the client well regarding problems, issues and/or stoppers, this too can result in re-work and time delays.”
David Avalos, Tester IV
“In my career I have noticed a variety of issues that can negativelyimpact an outcome: 1) Goals are not clearly set at the start. 2) There is inadequate planning 3) Poor or no methodology exists.
Of course, all these problems can be easily solved with properattention and the right partner.”
Pedro GonzalezIT Engineer
“First, there has to be a good fit between the partner and the client. Clients must have adequate budgets and a willingness to adhere to Scrum or other development methodologies. Clients and partners need to be able to adjust to each situation.
Second, correct expectations must be set with all parties from the start. This includes having a workable backlog and scope around deliverables.
A Technical Analysis should be conducted early on of existing code repositories, software architectures, documentation and third-party tools. The development team should never jump into a project with-out knowing the current state of all existing software solutions.
Having the right insights and knowledge regarding technicalrequirements allows the developer to propose the right solution and right team, tailored to the client’s needs. Not doing so cancreate bigger problems down the road.
The partner and the client should follow a mature and provenprocess that identifies potential problems and alignment between the parties.”
Javier TreviñoDTS
“Correct expectations must be set with all parties from the start.”
NOTES FROM THE FIELD VOL. 1 13
“The team should define what you currently know about theapplication ecosystem in clear goals. If you are unsure, don’t guess or assume what you currently think is true. Define multiplehypotheses and then test if they are true. Allow for the architecture and design process to be evolutive, based on continuous feedback from all places including your development team, automation,monitoring tools and users. Use this feedback to adjust yourstrategy based on facts, so you can more efficiently focus yourefforts and provide better value to your users and stakeholders.”
Jorge Gaona, Architect
“There are three things you have to nail for a successful software deployment: 1) product planning, 2) solid technical planning and requirements, and 3) deployment planning which includes automated testing. If any one of these three have a major deficiency, it is likely you will run into issues. Understand going in that developing asoftware product that your clients will purchase is difficult. At some point, things may not go as planned. It is important to identify and address issues early.”
Mike Hahn, COO
“Failure can occur when you don’t get key stakeholders’ buy-in or when there is a lack of understanding regarding the customers’ business processes.
Understand the existing landscape of systems. Get the new system to “fit” into and enhance other systems. Clearly define the interfaces with other existing systems. Establish a thorough understanding of business process/stakeholders’ expectations. Ensure deepengagement from the beginning through thorough end user testing/security.”
Rong Wang, Chief Financial Officer
“Based on my experience, you should put an emphasis on team culture,requirements and agile methodologies.
It is important to not make too many assumptions. Don’t make promises without context. Make sure your team members have the right knowledge. Have thoughtful discussions about deadlines. Be very specific about requirements. Instill goodcommunication lines between teams.”
Manuel Villasenor, Software Architect
NOTES FROM THE FIELD VOL. 1 14
“No project is like another...”
NOTES FROM THE FIELD VOL. 1 15
“Each project is unique, with its own constraints and opportunities for success. No project is like another, so you must be smart about setting expectations based on the past.
Many times, in my experience, a lack of well-defined goals orunrealistic estimates of tasks and deadlines are the main reasons a project does not meet expectations.”
Denisse Vega, Pre-sales Engineer
About Tiempo DevelopmentTiempo is widely recognized as one of the leading software engineering companies in the US. Puttingto work nearshore engineering resources and high- performance teams with a relentless focus onclient outcomes, Tiempo designs, builds, and deploys software that makes lives better.
Tiempo is headquartered in Tempe, Arizona, with four world-class software development facilitiesin Mexico. Tiempo has been recognized annually by Inc. Magazine as one of the Fastest-GrowingPrivate Companies in America.
TEMPE | GUADALAJARA | MONTERREY | HERMOSILLO
www.tiempodev.com
Contact us at:[email protected]
