Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.
Continuous Improvement as a Team
6 Agile Games to Enhance Team Building and Creativity
In this article, we uncover typical ways in which Scrum teams fail stakeholders, from overpromising results to poor risk communication to neglecting feedback. Moreover, we will also explore actionable strategies to overcome these anti-patterns by building trust, aligning priorities, and enhancing collaboration for successful product development. 9 Anti-Patterns of How Scrum Teams Fail Stakeholders The following list aims to provide Scrum teams with a clear understanding of common mistakes in stakeholder interactions and practical advice for improving these relationships to achieve better outcomes and stronger collaboration: Over-Promising and Under-Delivering Manifestation Teams commit to more work than can realistically be completed within a Sprint, leading to unmet stakeholder expectations. Stakeholder Perspective Stakeholders depend on the Scrum team’s commitments to plan their activities and set expectations for their clients and superiors. When teams overpromise and underdeliver, it disrupts these plans. It erodes the trust and reliability placed in the team, as stakeholders will likely face negative feedback, possibly affecting their career perspectives if they continue to fail to deliver despite being dependent on other teams for the delivery. The responsibility for the failure will be theirs. First Step Initiate a thorough review of the team’s capacity and delivery capabilities to improve their future planning. While no one expects “precise forecasts,” a reasonable confidence in forecasts is expected. Engage in transparent discussions with stakeholders about what is realistically achievable, considering current bandwidth, skills, and potential obstacles. This approach fosters trust through honesty and realistic planning. Insufficient Stakeholder Engagement Manifestation Scrum teams fail to involve stakeholders adequately in the development process, especially during Sprint Reviews. Stakeholder Perspective Effective engagement ensures that stakeholders are informed and have a voice in the development process. Insufficient engagement leaves them feeling sidelined, questioning the relevance and alignment of the teams’ efforts’ outcomes with their actual needs, potentially leading to decreased support or questioning the usefulness of Scrum itself. (Please note: We are not paid to practice Scrum but to solve our customers’ problems within the given constraints while contributing to the organization’s sustainability.) First Step Establish a structured engagement plan beyond the invitation to standard Sprint Review sessions, outlining regular touchpoints and feedback sessions with stakeholders. It should prioritize inclusivity and active solicitation of input to ensure that stakeholder needs and expectations are continuously integrated into the team’s workflow. An excellent practice in this regard is, for example, collaborative User Story Mapping sessions. Learn more about Stakeholder communication here. Poor Communication of Risks and Issues Manifestation Teams avoid discussing potential risks and issues with stakeholders, hoping to resolve them internally. Stakeholder Perspective Scrum’s promise of transparency means stakeholders expect to be informed about potential risks and issues, making it a superior way of risk mitigation. However, concealing these realities can lead to unexpected turns of events, making stakeholders feel misled and questioning the team’s integrity and ability to manage challenges proactively. Also, communication failures may directly affect stakeholder’s career prospects, particularly regarding essential projects or products. First Step Develop a risk communication strategy that includes regular updates on potential issues and their mitigation plans. This strategy should aim for openness and collaborative problem-solving, inviting stakeholders to contribute their insights and support, thereby reinforcing a partnership built on mutual trust and respect. Engaging Sprint Review sessions and regular joint stakeholder/Scrum team Retrospectives are good starts. Learn more about Stakeholder Retrospectives here. Ignoring Stakeholder Feedback Manifestation Scrum teams fail to incorporate or adequately address feedback provided by stakeholders during or after Sprint Reviews. Stakeholder Perspective Stakeholders provide feedback based on their expertise, experience, and understanding of customer needs. Ignoring this valuable input can lead to outcomes that are misaligned with market demands or business goals, diminishing the perceived value of the Scrum team’s work. First Step Create a feedback loop mechanism to capture, evaluate, and address all stakeholder feedback appropriately. This mechanism should include transparent communication about how feedback is being incorporated or why specific suggestions cannot be implemented, maintaining an environment of mutual respect and understanding. An excellent tool for this purpose is a transparent system that funnels feedback, suggestions, or requirements into a Scrum team’s Product Backlog, as outlined in the following graphic. Lack of Visibility Into Progress Manifestation Scrum teams fail to provide clear and understandable updates on progress toward the current Product Goal, leaving stakeholders in the dark and adding to the general uncertainty of a complex environment. Stakeholder Perspective Regular updates on progress are crucial for stakeholders to feel confident in the team’s direction and achievements. Lack of visibility can create uncertainty and anxiety, undermining confidence in the team’s ability to deliver and reducing stakeholders’ ability to support and advocate for the project. First Step Use tools and dashboards to provide real-time, transparent insights into the team’s progress and challenges. Ensure these tools are accessible and understandable to non-technical stakeholders, enabling them to track developments closely and feel reassured about a team’s progress toward its Product Goal. Besides dedicated information radiators tailored to the information needs of stakeholders, a team can employ additional tactics, such as access to its Product Backlog, possibly (unanimous) invitations to Daily Scrum sessions, creating good old reports and internal newsletters, or a team diary in the form of a blog, a Confluence page, or even a GitHub repository. Misaligned Priorities Manifestation Scrum teams prioritize work based on their perceptions rather than stakeholder or business value, leading to misaligned outcomes. Stakeholder Perspective Stakeholders expect the team to focus on delivering the highest business and customer value. When priorities are misaligned, it signals a disconnect between the team’s activities and the broader organizational goals, leading to frustration and questioning of the team’s strategic alignment. Moreover, the misalignment may result in diminished support for a Scrum team, potentially leading to defunding. First Step Facilitate a priority alignment workshop with key stakeholders to understand their vision, objectives, and expectations. Use this understanding to guide the creation of a Scrum team’s Product Goal, Product Backlog, and, consequently, future Sprint Planning sessions, ensuring that the team’s efforts directly contribute to achieving strategic goals. Excellent supportive tools for this purpose are visualization tools like the Product Strategy Canvas, the Business Model Canvas, or the Product Goal Canvas. Learn more about the effectiveness of these tools here. Failure To Set Expectations Manifestation Scrum teams do not clearly define or communicate what is achievable within a Sprint, setting unrealistic expectations. Stakeholder Perspective Clear expectations around Sprint Goals are fundamental for stakeholder satisfaction. Failure to set these expectations can lead to disappointment and the perception that the team is not delivering value, impacting the team’s reputation and stakeholder trust and potentially leading to more supervision and micromanagement from stakeholders, for example, in the form of imposed deadlines. First Step Invest in alignment of stakeholders and the Scrum team on the business objectives. Help the Scrum team understand what is most desirable from the organization’s and the customer’s perspective. At the same time, as a team, help the stakeholders understand, non-technical ones included, what is technically feasible in what time frame. Help them also understand what changes the team would need to make regarding, for example, skills, team composition, tools, or architecture to narrow the gap between stakeholder ambitions and a realistic delivery. Neglecting Non-Technical Stakeholders Manifestation Scrum Teams focus solely on technical aspects and fail to engage with stakeholders on business or user experience concerns. Stakeholder Perspective All stakeholders, regardless of their technical expertise, have a vested interest in the project’s success. Neglecting non-technical stakeholders can lead to a lack of buy-in and support, as they may feel their contributions or concerns are not being considered or valued. This perception of rejection may lead to reduced support for the team in the long run, possibly lobbying against the team itself. First Step Organize educational sessions for non-technical stakeholders to demystify the development process and facilitate their meaningful participation. Additionally, tailor communication and updates to be inclusive and accessible, ensuring all stakeholders can engage effectively with the team and its work. Moreover, as a preparatory means on the side of the Scrum team, engage in understanding your team’s stakeholder landscape: who do you need to keep close to what extent to secure the team’s future? Inadequate Stakeholder Education Manifestation Teams assume stakeholders understand agile product development in general and the Scrum processes and their roles in particular, leading to confusion and misalignment. Stakeholder Perspective A fundamental understanding of Scrum enables stakeholders to participate in and support the agile process effectively. Without this understanding, there’s a risk of misalignment and frustration, as stakeholders may not grasp the importance of their role in supporting the Scrum team, product success, or the rationale behind team decisions. First Step Develop and deliver a tailored educational program for stakeholders, covering key Scrum principles and practices and their expected roles and contributions. You can create an effective program even for stakeholders who are completely uneducated in the art of developing new products. Learn more about a Successful stakeholder educational program here: App Prototyping with Absolute Beginners – Creating a Shared Understanding of How Empiricism Works. Food for Thought Questions Is there more that we should know about how Scrum teams fail stakeholders? Consider the following thoughts: How can Scrum teams balance stakeholder expectations and realistic delivery capabilities? In what ways can continuous stakeholder education transform the effectiveness of Scrum processes? Moreover, how do stakeholders have to educate Scrum teams to improve alignment? How do transparent risk communication and stakeholder feedback incorporation — or the lack thereof — impact the long-term relationship between Scrum teams and stakeholders? Conclusion Successful Scrum implementation hinges not just on following processes but on fostering deep, trust-based relationships with stakeholders. Addressing common pitfalls such as overpromising, insufficient engagement, and lack of visibility is crucial. By prioritizing clear communication, stakeholder education, and alignment on priorities, Scrum teams can ensure their efforts resonate well with stakeholder needs and organizational goals, ultimately leading to a more supportive, collaborative, and effective product development environment. How does your team improve collaboration with stakeholders? Please share your experience with us in the comments.
DevOps encompasses a set of practices and principles that blend development and operations to deliver high-quality software products efficiently and effectively by fostering a culture of open communication between software developers and IT professionals. Code reviews play a critical role in achieving success in a DevOps approach mainly because they enhance the quality of code, promote collaboration among team members, and encourage the sharing of knowledge within the team. However, integrating code reviews into your DevOps practices requires careful planning and consideration. This article presents a discussion on the strategies you should adopt for implementing code reviews successfully into your DevOps practice. What Is a Code Review? Code review is defined as a process used to evaluate the source code in an application with the purpose of identifying any bugs or flaws, within it. Typically, code reviews are conducted by developers in the team other than the person who wrote the code. To ensure the success of your code review process, you should define clear goals and standards, foster communication and collaboration, use a code review checklist, review small chunks of code at a time, embrace a positive code review culture, and embrace automation and include automated tools in your code review workflow. The next section talks about each of these in detail. Implementing Code Review Into a DevOps Practice The key principles of DevOps include collaboration, automation, CI/CD, Infrastructure as Code (IaC), adherence to Agile and Lean principles, and continuous monitoring. There are several strategies you can adopt to implement code review into your DevOps practice successfully: Define Clear Goals and Code Review Guidelines Before implementing code reviews, it's crucial to establish objectives and establish guidelines to ensure that the code review process is both efficient and effective. This helps maintain quality as far as coding standards are concerned and sets a benchmark for the reviewer's expectations. Identifying bugs, enforcing practices, maintaining and enforcing coding standards, and facilitating knowledge sharing among team members should be among these goals. Develop code review guidelines that encompass criteria for reviewing code including aspects like code style, performance optimization, security measures, readability enhancements, and maintainability considerations. Leverage Automated Code Review Tools Leverage automated code review tools that help in automated checks for code quality. To ensure proper code reviews, it's essential to choose the tools that align with your DevOps principles. There are options including basic pull request functionalities, in version control systems such as GitLab, GitHub, and Bitbucket. You can also make use of platforms like Crucible, Gerrit, and Phabricator which are specifically designed to help with conducting code reviews. When making your selection, consider factors like user-friendliness, integration capabilities with development tools support, code comments, discussion boards, and the ability to track the progress of the code review process. Related: Gitlab vs Jenkins, CI/CD tools compared. Define a Code Review Workflow Establish a clear workflow for your code reviews to streamline the process and avoid confusion. It would help if you defined when code reviews should occur, such as before merging changes, during feature development, or before deploying the software to the production environment. Specify the duration allowed for code review, outlining deadlines for reviewers to provide feedback. Ensure that the feedback loop is closed, that developers who wrote the code address the review comments, and that reviewers validate the changes made. Review Small and Digestible Units of Code A typical code review cycle should involve only a little code. Instead, it should split the code into smaller, manageable chunks for review. This would assist reviewers in directing their attention towards features or elements allowing them to offer constructive suggestions. It is also less likely to overlook critical issues when reviewing smaller chunks of code, resulting in a more thorough and detailed review. Establish Clear Roles and Responsibilities Typically, a code review team comprises the developers, reviewers, the lead reviewer or moderator, and the project manager or the team lead. A developer initiates the code review process by submitting a piece of code for review. A team of code reviewers reviews a piece of code. Upon successful review, the code reviewers may request improvements or clarifications in the code. The lead reviewer or moderator is responsible for ensuring that the code review process is thorough and efficient. The project manager or the team lead ensures that the code reviews are complete within the decided time frame and ensuring that the code is aligned with the broader aspects of the project goals. Embrace Positive Feedback Constructive criticism is an element, for the success of a code review process. Improving the code's quality would be easier if you encouraged constructive feedback. Developers responsible, for writing the code should actively seek feedback while reviewers should offer suggestions and ideas. It would be really appreciated if you could acknowledge the hard work, information exchange, and improvements that result from fruitful code reviews. Conduct Regular Training An effective code review process should incorporate a training program to facilitate learning opportunities for the team members. Conducting regular training sessions and setting a clear goal for code review are essential elements of the success of a code review process. Regular trainings play a role, in enhancing the knowledge and capabilities of the team members enabling them to boost their skills. By investing in training the team members can unlock their potential leading to overall success, for the entire team. Capture Metrics To assess the efficiency of your code review procedure and pinpoint areas that require enhancement it is crucial to monitor metrics. You should set a few tangible goals before starting your code review process and then capture metrics (CPU consumption, memory consumption, I/O bottlenecks, code coverage, etc.) accordingly. Your code review process will be more successful if you use the right tools to capture the desired metrics and measure their success. Conclusion Although the key intent of a code review process is identifying bugs or areas of improvement in the code, there is a lot more you can add to your kitty from a successful code review. An effective code review process ensures consistency in design and implementation, optimizes code for better performance and scalability, helps teams collaborate to share knowledge, and improves the overall code quality. That said, for the success of a code review process, it is imperative that the code reviews are accepted on a positive note and the code review comments help the team learn to enhance their knowledge and skills.
A sprint retrospective is one of the four ceremonies of the Scrum. At the end of every sprint, a product owner, a scrum master, and a development team sit together and talk about what worked, what didn’t, and what to improve. The basics of a sprint retrospective meeting are clear to everyone, but its implementation is subjective. Some think the purpose of a sprint retrospective meeting is to evaluate work outcomes. However, as per the Agile Manifesto, it is more about evaluating processes and interactions. It says, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Many scrum teams are not making most of the sprint retrospective meetings due to a lack of understanding. In this post, we will look at what to avoid in a sprint retrospective meeting and what to do to run an effective sprint retrospective meeting. What To Avoid in a Sprint Retrospective Meeting? A sprint retrospective meeting is an opportunity for the scrum team to come together and discuss the previous sprint with the purpose of making improvements in processes and interactions. But scrum teams often end up making a sprint retrospective meeting a negative talk of beating one another and less interesting due to the lack of implementation of outcomes of sprint retrospective meetings. Here are a few things that you need to avoid in a sprint retrospective meeting: 1. Focusing on the Outcomes The end goal of a sprint retrospective is undoubtedly increasing the sprint velocity of the team, but the process to do so is not talking about the outcome of the sprint. The focus is on finding areas that can be improved in processes and people to make it easy and efficient for the scrum team to work together. 2. Not Involving All Team Members’ Voice The output of a scrum team is evaluated as a team, not as each individual. Therefore, it is important that each member of the Scrum team is heard. Thus, the equal participation of the team members is required in retros. If someone has issues and they are not addressing them, it is going to impact the sprint output as the members of the sprint team are highly dependent on each other to achieve sprint goals. 3. Talking Only About What Went Wrong The purpose of a sprint retrospective is to make improvements, but it does not mean you do not talk about good things. We all are human beings and need appreciation. If you talk only about what did not work, a sprint retrospective will become more of a tool of blaming and beating each other rather than an instrument of improvement. Above all, it is important to talk about what went well so that you can replicate good things in the next sprint. 4. Not Taking Action on Retro Outcomes The worst thing that can happen for a sprint retrospective is not taking action items derived from it. This will lead to a loss of interest and trust in sprint retrospectives as it sends a message to the team that their feedback is not valuable. What To Do To Run an Effective Sprint Retrospective Meeting There are some basics you can follow to run an effective sprint retrospective meeting. Have a look at them. 1. Create a Psychologically Safe Space for Everyone To Speak It is the responsibility of a product owner and a scrum master to create a psychologically safe environment for everyone to speak up in the meeting to make a sprint retrospective successful. If you are asking questions like what went well during the last sprint, what didn’t go well, and what should we do differently next time, everyone should feel safe to share their views without any repercussions. 2. Use a Framework The best way to conduct an effective sprint retrospective meeting is to follow a template. Experts have created various frameworks for conducting effective sprint retrospective meetings. The top frameworks include: Mad, Sad, Glad Speed car retrospective 4 L's Retrospective Continue, stop, and start-improve What went well? What didn't go well? What is to improve? These frameworks help ensure that you are talking about processes, not people. For example, the Mad, Sad, Glad framework talks about asking what makes the team mad, sad, and glad during the sprint and how we can move from mad, sad columns to glad columns. Use a framework that works for your scrum team. 3. Have a Facilitator-In-Chief Like any other meeting, a sprint retrospective meeting needs to have a goal, a summary, and a facilitator. Have a facilitator-in-chief to make sprint retrospectives valuable. Usually, the role is dedicated to the scrum master whose responsibility in sprint retrospective is to: Set the agenda and goals of the sprint retrospectives. Collect feedback from all the team members on the action items to talk about in the retro. Defining the length of the meeting. Follow up with action items implemented in the last sprints. Summarizing the key action items for the next sprint. 4. Implement the Action Items The responsibility of the scrum master does not end with a sprint retrospective. A scrum master needs to make sure that action items found in the sprint retrospective are implemented in the upcoming sprint. Daily stand-up meetings are a great tool for the scrum master to ensure that the team is implementing what is agreed upon & discussed and making improvements. Also, you can see the results of sprint retrospectives in tangible terms with metrics like sprint velocity. 5. Positivity, Respect, and Gratitude for Everyone Lack of engagement is the biggest challenge of sprint retrospectives in the long run. It occurs when action items are not worked on, people are not heard, and the focus is on negatives. Cultivate positivity and have respect and gratitude for everyone. Talks about what can be improved rather than blaming individuals. Listen to others to mark respect and express gratitude to address everyone’s contributions. Paired with the implementation of action items, you can ensure that your scrum team sees sprint retrospectives as an opportunity to improve. Conclusion Sprint retrospective is a great opportunity to look past what worked well, what went wrong, and what we can do ahead to improve. It is a great instrument for a business to improve efficiency, keep its workforce happy, and build products that both clients and end-customers love. The only challenge is you need to utilize it appropriately. With insights shared in this post, there are high chances you will be able to run effective sprint retrospective meetings and bring actual value to the table.
In this article, we are going to look at the challenges faced when rapidly scaling engineering teams in startup companies as well as other kinds of companies with a focus on product development. These challenges change between different types of companies, sizes, and stages of maturity. For instance, the growth of a consultancy software company focused on outsourcing is so different from a startup focused on product development. I've faced much team growth and also seen the growth of teams in several companies, and most of them have faced the same challenges and problems. Challenges The following are some of the challenges or problems that we will have to address in high-growth scenarios: Growth is aligned with productivity: many companies grow, but the output is unfortunately far from the goals. Avoid team frustration due to failure to achieve growth goals. Avoid too much time being consumed with the hiring process for the engineering teams. Avoid the demotivation of newcomers due to chaotic onboarding processes: the onboarding process is the first experience in the company. Maintain and promote the cultural values defined by the organization. The impact on delivery is aligned with the defined goals and risks. New hires meet expectations and goals in terms of value contribution. Navigating the Challenges Goals Goals are the main drivers of the growth strategy. They need to be challenging, but also realistic, and linked to mid-term and long-term vision. Challenging: Push the team to go beyond their comfort zone and strive for excellence. It requires effort, innovations, planning, and agility. Realistic: Ensure the goals can be achieved to avoid lead with frustration and burnout. The growth of the company and its success have to enhance the motivation and inspiration of the team. Long-term: Goals have to be aligned with the company's long-term vision and in a wide range. Large growth cannot be organized with the next three months in mind, because that may be the time it takes to find suitable candidates. Goals have to be measurable, clear, and specific to: Promote accountability Evaluate and measure the goal's success Take data-driven decisions All growth requires dedication and effort from the team; time that they will not dedicate to product evolution or development. Example: Unrealistic Goal Let's suppose we have a team of 10 engineers divided into 2 squads: backend and platform. The company set the following goals: Triplicate the team in 1 year, from 10 to 30 engineers. Keep the delivery performance. Create three news squads: DevOps, Data Platform, and Front End. Promote the culture. Only hire top-tier engineers. Most likely, the number of candidates we will have to evaluate in interviews and technical exercises will be at best four candidates for each position in addition to the time dedicated to the onboarding process. Usually, there is more than one engineer collaborating in the hiring process so we are likely to have a significant impact on delivery. Finding a team of experienced and highly qualified people is not an easy task. It is necessary to define what we consider "talent" and the different levels at which we can hire. Maintaining and promoting the culture in a high-growth environment where in one year there are more new people than the team we have is very complex and requires a good strategy, definition of objectives, and agility in decision-making. With this, we want to reflect that one of these objectives would already be ambitious - but all of them together make it practically impossible to achieve success. Talent Acquisition and Hiring Process The talent acquisition team plays a crucial role in a company's growth strategy, but they need the support of all of the company. C-Levels and hiring managers have to provide all the support and be involved as the same team. Clear Communication Foster open and clear communication between teams to ensure that everyone understands the goals and the role each team plays in the process. Review Pipeline Quality Sometimes many candidates go through the early stages of the pipeline and are ultimately discarded, and this generates a lot of frustration in the engineering team because the analysis of each candidate requires significant effort. It is important to adjust the requirements and search criteria for candidates in the early stages of the pipeline and this requires constant communication between the teams. Market Knowledge Talent acquisition teams should provide insights into market trends and competitor strategies. This knowledge provides important information to the company to define the expectations and strategy and stay ahead in the market. Cultural Values It is important to keep in mind that each engineer who joins our team brings his or her own culture based on factors such as work experience, personality, or the country where they live. Although these people fit the cultural pattern we are looking for, most of the time they do not have the culture of the company, and the hiring process is not reliable. If maintaining the culture is important to the company, we need to mentor new employees starting with the recruitment process itself. Promote values in the hiring process. Promote values in the company and team onboarding process. Promote values during the first years through the mentoring process. Promoting the cultural values and the company's goal are tasks that must be done continuously, but we must reinforce and review them with new hires more frequently. On-Boarding In my opinion, the onboarding process has a huge role in almost all companies and is not given enough attention. It is especially important in high-growth companies. The two main problems are: No onboarding process: Onboarding is focused on a meeting with human resources, another with the manager, and finally the team: a three-hour process. This can only be considered as a welcome meeting. Highly technical processes: Processes very oriented to perform your first deployment and that mainly promote knowledge silos and little engagement with the company. The onboarding process must be led by the organization. It must be structured and must encourage a smooth integration of new hires into the organization, minimizing disruptions and maximizing productivity over time. In addition, the entire onboarding process should be a step-by-step process with as much documented support as possible. This would be a base structure for a complete onboarding process: Pre-boarding: It includes all the activities that occur between the acceptance of the offer and the new hire's first day. Continuous communication is important because it promotes motivation and cultural values and helps to create a feeling within the company. Welcome Day: Welcome meeting, company overview, review of company policies and cultural values Paperwork, documentation, and enrollment processes Initial equipment setup Introduction to Team and Manager Security training Company 360 (scheduled by month): 360-degree meetings with leaders from all departments provide valuable insights, foster collaboration, and help new employees understand the broader organizational context. Starting the first week: Cultural values and goals: The manager and the team share the same cultural values and team goals. The goals have to be clear and most of them measurable. Mentorship: Assign a mentor to support the integration process at least during the first year. Engineering Tech best practices and tools: Share the vision of architecture principles, DevOps, data principles, tools, and best practices of the organization. Roles-specific training Team integration: Start participating in team meetings. Feedback and evaluation: Feedback must always be continuous, honest, and constructive. We must put more emphasis on new hires to adjust goals, mentoring, or training. It would be better to start with one-to-one and include this evaluation and feedback in these sessions. Starting in the third month: Performance evaluation Continuous learning is part of the cultural values but at this time learning paths could be considered Initiate conversations about long-term career paths. It is important to avoid onboarding processes based solely on pairing or shadowing strategies because they require too much effort and also only generate silos and misalignment. These sessions are important but must be supported by documentation from both the organization and the team itself. Impact on Delivery The growth phase often requires a high investment of time, effort, and people in the hiring and onboarding process. Hiring process: Participating in technical sessions, reviewing candidate profiles, and reviewing technical exercises. Onboarding: The process of onboarding a new engineer to a team is always time-consuming and usually involves a learning curve until these people can offer more value than the effort invested in their integration. In the case of large growth, there may be situations in which teams are formed entirely by new engineers. This also has an impact on delivery, because these teams need: Mentors and support to adapt to the new environment Transversal coordination with other squads Talent Density In my opinion, growth should be based on the amount of talent and not on the number of engineers. At this point, there are a number of aspects to consider: What does talent mean to our organization? Finding talent is very complicated. There is a lot of competition in the market, people specialized in hiring processes, and the pressure to grow. Many people mistake talent for knowledge or years of experience. In my case, I have always given more value to the person's potential for the new role and for the organization rather than the experience in the role or the companies in which he/she has worked. The fit of a new hire is not only restricted to the hiring process but also to the evaluation period. Moreover, it is during the evaluation period that we can really evaluate the person. It is in this period when the decision is less painful for both parties, a person who does not fit in the organization will generate a negative impact both for him and for the organization. Team Topology These growth scenarios require changes in the organization and the creation of new teams or departments. Two fundamental factors must be taken into account: Team creation strategy Conway's Law Team Creation Strategy There are several strategies for developing the organization of teams: Integrate new hires into existing squads. Integrate new hires into existing squads and after some time, divide the team in two. Create entirely new teams with new hires. Create a new team from current leadership and new hires. The decision to apply a single approach or a combination of several approaches depends on several factors, including the organization's specific needs, resource availability, and long-term objectives. Conway's Law Conway's Law is a principle in software engineering and organizational theory: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Conway's Law suggests that the communication patterns, relationships, and team structures within an organization are reflected in the architecture, design, and interfaces of the software or systems they build. Summary The growth of engineering teams is one of the most complex challenges facing a growing organization, especially if this growth must be aligned with productivity and cultural goals. Hiring the number of people we have set as a target can be easy. Hiring the right people can be almost impossible and hiring a ratio of enough talented people is very difficult. This can only be done well if you work as a team.
GenAI is everywhere you look, and organizations across industries are putting pressure on their teams to join the race – 77% of business leaders fear they’re already missing out on the benefits of GenAI. Data teams are scrambling to answer the call. However, building a generative AI model that actually drives business value is hard. And in the long run, a quick integration with the OpenAI API won’t cut it. It’s GenAI, but where’s the moat? Why should users pick you over ChatGPT? That quick check of the box feels like a step forward. Still, if you aren’t already thinking about how to connect LLMs with your proprietary data and business context actually to drive differentiated value, you’re behind. That’s not hyperbole. This week, I’ve talked with half a dozen data leaders on this topic alone. It wasn’t lost on any of them that this is a race. At the finish line, there are going to be winners and losers: the Blockbusters and the Netflixes. If you feel like the starter’s gun has gone off, but your team is still at the starting line stretching and chatting about “bubbles” and “hype,” I’ve rounded up five hard truths to help shake off the complacency. 1. Your Generative AI Features Are Not Well Adopted, and You’re Slow to Monetize “Barr, if generative AI is so important, why are the current features we’ve implemented so poorly adopted?” Well, there are a few reasons. One, your AI initiative wasn’t built to respond to an influx of well-defined user problems. For most data teams, that’s because you’re racing, and it’s early, and you want to gain some experience. However, it won’t be long before your users have a problem that GenAI best solves, and when that happens – you will have much better adoption compared to your tiger team brainstorming ways to tie GenAI to a use case. And because it’s early, the generative AI features that have been integrated are just “ChatGPT but over here.” Let me give you an example. Think about a productivity application you might use every day to share organizational knowledge. An app like this might offer a feature to execute commands like “Summarize this,” “Make longer,” or “Change tone” on blocks of unstructured text. One command equals one AI credit. Yes, that’s helpful, but it’s not differentiated. Maybe the team decides to buy some AI credits, or perhaps they just simply click over on the other tab and ask ChatGPT. I don’t want to completely overlook or discount the benefit of not exposing proprietary data to ChatGPT. Still, it’s also a smaller solution and vision than what’s being painted on earnings calls across the country. That pesky middle step from concept to value. So consider: What’s your GenAI differentiator and value add? Let me give you a hint: high-quality proprietary data. That’s why a RAG model (or sometimes, a fine-tuned model) is so important for Gen AI initiatives. It gives the LLM access to that enterprise's proprietary data. (I’ll explain why below.) 2. You’re Scared To Do More With Gen AI It’s true: generative AI is intimidating. Sure, you could integrate your AI model more deeply into your organization’s processes, but that feels risky. Let’s face it: ChatGPT hallucinates and can’t be predicted. There’s a knowledge cutoff that leaves users susceptible to out-of-date output. There are legal repercussions to data mishandling and providing consumers with misinformation, even if accidental. Sounds real enough, right? Llama 2 sure thinks so. Your data mishaps have consequences. And that’s why it’s essential to know exactly what you are feeding GenAI and that the data is accurate. In an anonymous survey, we sent to data leaders asking how far away their team is from enabling a Gen AI use case, one response was, “I don’t think our infrastructure is the thing holding us back. We’re treading quite cautiously here – with the landscape moving so fast and the risk of reputational damage from a ‘rogue’ chatbot, we’re holding fire and waiting for the hype to die down a bit!” This is a widely shared sentiment across many data leaders I speak to. If the data team has suddenly surfaced customer-facing, secure data, then they’re on the hook. Data governance is a massive consideration and a high bar to clear. These are real risks that need solutions, but you won’t solve them by sitting on the sideline. There is also a real risk of watching your business being fundamentally disrupted by the team that figured it out first. Grounding LLMs in your proprietary data with fine tuning and RAG is a big piece to this puzzle, but it’s not easy… 3. RAG Is Hard I believe that RAG (retrieval augmented generation) and fine-tuning are the centerpieces of the future of enterprise generative AI. However, RAG is a simpler approach in most cases; developing RAG apps can still be complex. Can’t we all just start RAGing? What’s the big deal? RAG might seem like the obvious solution for customizing your LLM. But RAG development comes with a learning curve, even for your most talented data engineers. They need to know prompt engineering, vector databases and embedding vectors, data modeling, data orchestration, data pipelines, and all for RAG. And, because it’s new (introduced by Meta AI in 2020), many companies just don’t yet have enough experience with it to establish best practices. RAG implementation architecture Here’s an oversimplification of RAG application architecture: RAG architecture combines information retrieval with a text generator model, so it has access to your database while trying to answer a question from the user. The database has to be a trusted source that includes proprietary data, and it allows the model to incorporate up-to-date and reliable information into its responses and reasoning. In the background, a data pipeline ingests various structured and unstructured sources into the database to keep it accurate and up-to-date. The RAG chain takes the user query (text) and retrieves relevant data from the database, then passes that data and the query to the LLM in order to generate a highly accurate and personalized response. There are a lot of complexities in this architecture, but it does have important benefits: It grounds your LLM in accurate proprietary data, thus making it so much more valuable. It brings your models to your data rather than bringing your data to your models, which is a relatively simple, cost-effective approach. We can see this becoming a reality in the Modern Data Stack. The biggest players are working at a breakneck speed to make RAG easier by serving LLMs within their environments, where enterprise data is stored. Snowflake Cortex now enables organizations to analyze data and build AI apps directly in Snowflake quickly. Databricks’ new Foundation Model APIs provide instant access to LLMs directly within Databricks. Microsoft released Microsoft Azure OpenAI Service, and Amazon recently launched the Amazon Redshift Query Editor. Snowflake data cloud I believe all of these features have a good chance of driving high adoption. But, they also heighten the focus on data quality in these data stores. If the data feeding your RAG pipeline is anomalous, outdated, or otherwise untrustworthy data, what’s the future of your generative AI initiative? 4. Your Data Isn’t Ready Yet Anyway Take a good, hard look at your data infrastructure. Chances are, if you had a perfect RAG pipeline, fine-tuned model, and clear use case ready to go tomorrow (and wouldn’t that be nice?), you still wouldn’t have clean, well-modeled datasets to plug it all into. Let’s say you want your chatbot to interface with a customer. To do anything useful, it needs to know about that organization’s relationship with the customer. If you’re an enterprise organization today, that relationship is likely defined across 150 data sources and five siloed databases…3 of which are still on-prem. If that describes your organization, it’s possible you are a year (or two!) away from your data infrastructure being GenAI-ready. This means if you want the option to do something with GenAI someday soon, you need to be creating useful, highly reliable, consolidated, well-documented datasets in a modern data platform… yesterday. Or the coach will call you into the game, and your pants will be down. Your data engineering team is the backbone for ensuring data health. A modern data stack enables the data engineering team to monitor data quality continuously in the future. It’s 2024 now. Launching a website, application, or any data product without data observability is a risk. Your data is a product, requiring data observability and governance to pinpoint data discrepancies before they move through an RAG pipeline. 5. You’ve Sidelined Critical Gen AI Players Without Knowing It Generative AI is a team sport, especially when it comes to development. Many data teams make the mistake of excluding key players from their Gen AI tiger teams, and that’s costing them in the long run. Who should be on an AI tiger team? Leadership, or a primary business stakeholder, to spearhead the initiative and remind the group of the business value. Software engineers will develop the code, the user-facing application, and the API calls. Data scientists consider new use cases, fine-tune their models, and push the team in new directions. Who’s missing here? Data engineers. Data engineers are critical to Gen AI initiatives. They will be able to understand the proprietary business data that provides the competitive advantage over a ChatGPT, and they will build the pipelines that make that data available to the LLM via RAG. If your data engineers aren’t in the room, your tiger team is not at full strength. The most pioneering companies in GenAI are telling me they are already embedding data engineers in all development squads. Winning the GenAI Race If any of these hard truths apply to you, don’t worry. Generative AI is in such nascent stages that there’s still time to start back over and, this time, embrace the challenge. Take a step back to understand the customer needs an AI model can solve, bring data engineers into earlier development stages to secure a competitive edge from the start, and take the time to build a RAG pipeline that can supply a steady stream of high-quality, reliable data. And invest in a modern data stack. Tools like data observability will be a core component of data quality best practices – and generative AI without high-quality data is just a whole lot of fluff.
Junior, Middle, and Senior are how a Software Engineer (SWE) career looks, right? But what does this mean? Different companies have different definitions, so borders are blurred. In this article, I’m going to share with you my considerations regarding levels in software engineering and try to rethink what the path might look like. A kind of disclaimer: this is only my vision and not the ultimate truth, so I’m happy to hear your feedback. What Is Wrong With Current Levels They are polysemantic. From what I can see on the market, from my experience, and those I tracked, different companies have different definitions of Junior/Middle/Senior engineers. Some of them have even more: Staff, Principal, and Distinguished engineers to have a better expression of seniority of highly experienced individual contributors. One of the key problems with “Senior SWE” is that people with absolutely different experiences might get this title. Technically, a Senior Mobile Engineer is not the same as a Senior Frontend Engineer or a Senior Backend Engineer. There are different specializations, and in general, that would not be correct to move from SME to SBE without any downgrade, but why? Logic dictates soft skills are the same, and life experience is the same as well (because it is still the same person). Only one thing changed - the ability to solve problems. You might be an extremely experienced Mobile Developer, but you have never solved issues within a web browser, problems with distributed systems, etc. So, let me take this particular criterion as a separator between levels. The first milestone is simple problem-solving. 1. Pathfinder: Random-Way Simple Problem Solver Originally, a pathfinder was someone who found or created a path through an unexplored or wild area. This term was often used to describe explorers or scouts who ventured into unknown territories, paving the way for others to follow. They were crucial in mapping new lands and navigating through difficult terrains. Sometimes, I hear, “You have to look after Junior dev, but the Middle one is working fully on one’s own." Is that true? Not. People on the Middle level usually do not care about the wider picture of the world, so they cannot make the best decision just by design. In any way, you need to look after every developer to help to stay within the project’s range of norms and not to allow to leak of over-engineered solutions. So, Random-way Simple Problem Solver (author: RwSPS short scares me as well), a.k.a Pathfinder, is able to solve atomic problems (not decomposable in a relevant way). Think about one task that someone else prepared for Pathfinder. Would you name it Junior? Middle? It doesn’t matter because you measure the results of these guys by their ability to solve business problems. Ok, Pathfinder will solve your problems. SOMEHOW, is it just enough? It depends. If you are creating a short-living project and all tasks are straightforward, a group of pathfinders will probably be enough. But for a long-living project, you need to solve problems, especially in a simple way. Otherwise, maintenance becomes a nightmare. 2. Specialist: Simple-Way Simple Problem Solver Specialist has deep, extensive knowledge and expertise in a specific field. Specialists are highly skilled in their area, often focusing on a narrow aspect of a discipline. Simple-way Simple Problem Solver (SwSPS), a.k.a Specialist, is the next level after Pathfinder. The key difference is that Specialists have enough experience to solve simple problems predictably in a simple way. That might be a proper framework/library usage, assembling solutions from existing components. For example: If Pathfinder tries to handle nulls by IFs, the Specialist will use nullable types to strict nullability by design. If Pathfinder might add logging at the start and the end of every method explicitly, Specialists will just use Aspect Oriented Programming (those who believe that AOP is unacceptable should throw tomatoes in the comments) If Pathfinder might refactor ten lines of code one by one. Specialists will use IDE’s multi-cursor to introduce changes in many places simultaneously. With experience and seeing more and more code that works, mastering tooling Specialists will provide more reliable solutions faster. This level is limited to atomic tasks only. Sounds like the next growth point! 3. Generalist: Random-Way Complex Problem Solver Generalist solves problems by synthesizing and applying knowledge from various domains. They are often effective in dealing with new or unforeseen challenges due to their adaptable and flexible approach. What is outside of a simple problem? Other simple problems! The source of all these simple ones is one or more complex issues that software engineers have to decompose before they start working. Let’s define a complex problem. In the context of this article, a complex problem is a problem that might be decomposed for the sake of improved predictability of implementation time. Also, a complex problem might consist of other complex problems that should be decomposed eventually. The key difference between a Random-way Complex Problem Solver (Generalist) and a Simple-way Simple Problem Solver (Specialist) is scale. A generalist is still able to solve simple problems in a simple way, but experience relevant to complex problems is not enough to follow the same approach for complex tasks. Here are a few examples: Generalists might design a new complex system starting with microservices and ignoring the fact that the customer-facing systems have <10 unique users in total yet. Generalists might start from on-premise db instead of just relying on managed services even if requirements do not specify that need and the key motivation is past experience. Generalists might bring redundant complex technologies from the previous company, ignoring the fact that the previous and the current ones are at different stages of business maturity. Getting experience in solving complex problems, Generalist starts finding ways to quickly get simpler solutions, and it means that the next level is coming. 4. Navigator: Simple-Way Complex Problem Solver Historically, navigators were crucial on ships and aircraft. In modern contexts, the term is used in roles requiring strategic planning and direction-setting, like in project management or leadership positions in companies. Counterintuitive that solving problems in a simple way is more complex, but the nature behind this fact is ignorance. At the beginning of your path, you have a high level of unawareness about already available solutions and ready-to-go components. Sometimes, they appear while you develop your own. Simple-way Complex Problem Solvers (Navigator) can deeply and seamlessly dive into an unknown environment, map their experience, find a simple solution, and basically have this expectation of something available instead of reinventing the wheel. A few examples: Navigator would never start by creating a marketplace if the business is about selling things but not SaaS. Navigator would research available opportunities before planning and designing. Navigator is fine with Google Sheets + Forms to launch the business. Navigator provides relevant solutions to the current business stage. Profits of the Alternative Level Classification Relative to the classical level set, this gradation: Is more transparent in terms of specific business requirements. Is measurable in practical tasks. Does correlate with experience. Does align expectations of a particular company. Conclusion The past “Senior” job title doesn’t say anything about your real ability to solve complex problems in the new company. People should align their skills with reality and not pretend to be seniors only because they already have this title. Movement through Pathfinder -> Specialist -> Generalist -> Navigator requires constant self-educating, so don’t waste your time. And please, don’t tell me that I showed myself as Pathfinder when describing such a simple topic in such a complex classification :)
Meetings are a crucial aspect of software engineering, serving as a collaboration, communication, and decision-making platform. However, they often come with challenges that can significantly impact the efficiency and productivity of software development teams. In this article, we will delve deeper into the issues associated with meetings in software engineering and explore the available data. The Inefficiency Quandary Meetings are pivotal in providing context, disseminating information, and facilitating vital decisions within software engineering. However, they can be inefficient, consuming a substantial amount of a software engineer’s workweek. According to Clockwise, the average individual contributor (IC) software engineer spends approximately 10.9 hours per week in meetings. This staggering figure amounts to nearly one-third of their workweek dedicated to meetings. As engineers progress in their careers or transition into managerial roles, the time spent in meetings increases. One notable observation is that engineers at larger companies often find themselves in even more meetings. It is commonly referred to as the “coordination tax,” where the need for alignment and coordination within larger organizations leads to a higher volume of meetings. While these meetings are essential for keeping teams synchronized, they can also pose a significant challenge to productivity. The Cost of Unproductive Meetings The impact of meetings on software engineering extends beyond time allocation and has financial implications. Research by Zippia reveals that organizations spend approximately 15% of their time on meetings, with a staggering 71% of those meetings considered unproductive. It means that considerable time and resources invested in discussions may not yield the desired outcomes. Moreover, unproductive meetings come with a substantial financial burden. It is estimated that businesses lose around $37 billion annually due to unproductive meetings. On an individual level, workers spend an average of 31 hours per month in unproductive meetings. It not only affects their ability to focus on critical tasks but also impacts their overall job satisfaction. The Impact on Software Engineering In the realm of software engineering, the inefficiencies and challenges associated with meetings can have several adverse effects: Delayed Development: Excessive or unproductive meetings can delay project timelines and hinder software development progress. Reduced Productivity: Engineers forced to spend a significant portion of their workweek in meetings may struggle to find uninterrupted “focus time,” which is crucial for deep work and problem-solving. Resource Drain: The coordination tax imposed by meetings can strain resources, leading to increased overhead costs without necessarily improving outcomes. Employee Morale: Prolonged or unproductive meetings can decrease job satisfaction and motivation among software engineers. Ineffective Decision-Making: When meetings are not well-structured or attended by the right participants, critical decisions may be postponed or made without adequate information. Meetings are both a necessity and a challenge in software engineering. While they are essential for collaboration and decision-making, the excessive time spent in meetings and their often unproductive nature can hinder efficiency and impact the bottom line. In the following sections, we will explore strategies to address these challenges and make meetings in software engineering more effective and productive. The Benefits of Efficient Technical Meetings in Software Engineering In the fast-paced world of software engineering efficient technical meetings can be a game-changer. They are the lifeblood of collaboration, problem-solving, and decision-making within development teams. In this article, we’ll explore the advantages of conducting efficient technical meetings and how they can significantly impact the productivity and effectiveness of software engineering efforts. Meetings in software engineering are not mere formalities; they are essential forums where ideas are exchanged, decisions are made, and project directions are set. However, they can quickly become a double-edged sword if not managed effectively. Inefficient meetings can drain valuable time and resources, leading to missed deadlines and frustrated teams. Efficiency in technical meetings is not just a buzzword; it’s a critical factor in the success of software engineering projects. Here are some key benefits that efficient meetings bring to the table: Time Savings: Efficient meetings are succinct and stay on topic. It means less time spent in meetings and more time available for actual development work. Improved Decision-Making: When meetings are focused and well-structured, decisions are made more swiftly, preventing bottlenecks and delays in the development process. Enhanced Collaboration: Efficient meetings encourage active participation and open communication among team members. This collaboration fosters a sense of unity and collective problem-solving. Reduced Meeting Fatigue: Prolonged, unproductive meetings can lead to fatigue, hindering team morale and productivity. Efficient meetings help combat this issue. Knowledge Sharing: With a focus on documentation and preparation, efficient meetings facilitate the sharing of insights and knowledge across the team, promoting continuous learning. We will delve into a five-step methodology to achieve these benefits to make technical discussions more efficient. While not a silver bullet, this approach has proven successful in many scenarios, particularly within teams of senior engineers. This methodology places a strong emphasis on documentation and clear communication. It encourages team members to attend meetings well-prepared, with context and insights, ready to make informed decisions. By implementing this methodology, software engineering teams can balance the need for collaboration and the imperative of focused work. In the following sections, we will explore each step of this methodology in more detail, understanding how it can revolutionize the way software engineers conduct technical meetings and, ultimately, how it can drive efficiency and productivity within the team. Step 1: Context Setting The initial step involves providing context for the upcoming technical discussion. Clearly articulate the purpose, business requirements, and objectives of the meeting. Explain the reasons behind holding the meeting, what motivated it, and the criteria for considering it a success. Ensuring that all participants understand the importance of the discussion is critical. Step 2: Send Invitations With Context After establishing the context, send meeting invitations to the relevant team members. It is advisable to provide at least one week’s notice to allow participants sufficient time to prepare. Consider using tools like Architecture Decision Records (ADRs) or other documentation formats to provide comprehensive context before the meeting. Step 3: Foster Interaction To maximize efficiency, encourage collaborative discussions before the scheduled meeting. Share the ADR or relevant documentation with the team and allow them to engage in discussions, provide feedback, and ask questions. This approach ensures that everyone enters the meeting with a clear understanding of the topic and can prepare with relevant references and insights. Step 4: Conduct a Focused Meeting When it’s time for the meeting, maintain a concise and focused approach. Limit the duration of the meeting to no longer than 45 minutes. This time constraint encourages participants to stay on track and make efficient use of the meeting. Avoid the trap of allowing meetings to expand unnecessarily, as per Parkinson’s law. Step 5: Conclusion and Next Steps After the meeting, clearly define the decision that has been made and summarize the key takeaways. If the discussion led to a decision, conclude the Architecture Decision Record or relevant documentation. If further action is needed, create a list of TODO activities and determine what steps are required to move forward. If additional meetings are necessary, return to Step 2 and schedule them accordingly based on the progress made. By following these key steps, software engineering teams can streamline their technical discussions, making them more efficient and productive while preserving valuable product development and innovation time. This approach encourages a culture of documentation and collaboration, enabling teams to make informed decisions and maintain institutional knowledge effectively. Conclusion In the fast-paced world of software engineering, efficient technical meetings play a crucial role, offering benefits such as time savings, improved decision-making, enhanced collaboration, reduced meeting fatigue, and knowledge sharing. To harness these advantages, a five-step methodology has been introduced emphasizing documentation, clear communication, and preparation. By adopting this approach, software engineering teams can balance collaboration and focused work, ultimately driving efficiency, innovation, and productivity.
The Agile Manifesto, a revolutionary document in the world of software development, emerged as a response to the inadequacies of traditional, rigid development methodologies. This article explores its origins, applications, and misuses, offering insights for engineering managers on how to effectively interpret and implement its principles. Origins of the Agile Manifesto In February 2001, seventeen software developers met at Snowbird, Utah, to discuss lightweight development methods. They were united by a common dissatisfaction with the prevailing heavyweight, document-driven software development processes. This meeting led to the creation of the Agile Manifesto, a concise declaration of four fundamental values and twelve guiding principles aimed at improving software development. Key Values Individuals and Interactions: The focus is more on the individuals involved and their interactions, rather than simply relying on processes and tools. This highlights the importance of team dynamics and interpersonal communication in achieving success. Working Software: The emphasis is on delivering a working software as the principal measure of progress, as opposed to creating comprehensive documentation. This does not undermine the importance of documentation, but rather stresses the need for a functioning product. Customer Collaboration: Instead of focusing solely on contract negotiation, there is a greater emphasis on collaboration with the customer. This fosters better understanding of the customer's needs, leading to a product that better fulfills those needs. Responding to Change: The ability to respond to change is prioritized over sticking rigidly to a plan. This emphasizes the need for adaptability and flexibility in the face of changing requirements or circumstances. These values represented a radical shift from the traditional waterfall approach, emphasizing flexibility, customer satisfaction, continuous delivery, and team collaboration. Application in Software Development The Agile Manifesto quickly gained traction in the tech world, leading to the development of various Agile methodologies like Scrum, Kanban, and Extreme Programming (XP). These methodologies share the core values of the manifesto but differ in practices and emphasis. Scrum, for instance, focuses on short, iterative cycles called sprints, with regular reassessments of tasks and goals. Kanban emphasizes continuous delivery and efficiency, while XP prioritizes technical practices to enhance software quality. Misuse in Software Development In spite of its widespread popularity and adoption in many industries, particularly in the realm of software development, the Agile Manifesto is frequently subject to misinterpretation or misuse. This is often due to a lack of understanding of its core principles or an attempt to apply it in contexts for which it was not originally designed. The common instances where the Agile Manifesto is not used as intended include: Overemphasis on Speed: A common misconception about Agile is that it is solely about accelerating the delivery process. This interpretation often leads to compromised quality and sustainability, resulting in burnout among team members and building up technical debt that may hinder future development. Agile is indeed about swift delivery, but not at the expense of quality or the well-being of the team. Ignoring the Importance of Documentation: Agile methodologies do favor working software over comprehensive documentation. However, this does not mean that documentation should be entirely neglected. Misunderstanding this principle can lead to a lack of essential documentation, which is critical for maintaining the software in the long run and ensuring scalability. It's important to strike a balance between creating working software and maintaining adequate documentation. Dogmatic Adherence to Specific Methodologies: Agile is often synonymous with methodologies like Scrum. However, treating Scrum or any other methodology as a one-size-fits-all solution can be counterproductive. Agile is fundamentally about flexibility and adaptation to the unique needs and circumstances of each project. Strict adherence to a particular method without considering the specific context can defeat the very purpose of Agile, which is to promote adaptability and responsiveness to change. Engineering Managers and the Agile Manifesto For those in leadership roles within the field of engineering, having a comprehensive understanding and ability to effectively implement the Agile Manifesto is of utmost importance. Here’s how engineering managers can approach, internalize and execute Agile principles within their teams: Embrace a Mindset of Flexibility and Adaptation: Agile is much more than a mere set of practices; it's an entire mindset. Managers should strive to foster a conducive environment that values and appreciates the ability to adapt with an openness to change. This involves cultivating a culture that encourages innovation and flexible thinking, positioning the team to quickly respond to any shifts or changes that may occur. Focus on People and Interactions: Building a culture within the team that is centered around collaboration is absolutely vital. It's essential to encourage open communication, regular feedback, and collective problem-solving. This not only involves dealing with issues as they arise but also proactively working to prevent potential problems through effective communication and teamwork. Balance Agility With Discipline: While embracing the fluidity and flexibility that comes with change, it's equally important to maintain a disciplined approach to development. This includes maintaining critical documentation, steadfastly adhering to quality standards, and not compromising on sustainable development practices. Balancing agility with discipline ensures that while the team is adaptable, the quality of work does not suffer. Customer-Centric Approach: Regular interaction and engagement with customers and stakeholders are key. Agile methodology is fundamentally about delivering value to the customer, and this necessitates continuous feedback and collaboration. Regular check-ins, updates, and discussions with customers ensure that the development process is aligned with customer needs and expectations. Tailor Agile to Your Context: There is no one-size-fits-all model in Agile. Agile principles are meant to be adapted, not adopted verbatim. Therefore, engineering managers should tailor Agile principles to their specific project, team, and organizational context. This involves understanding the unique needs and constraints of each project and making necessary adjustments to ensure that the Agile principles are applied in a way that is most effective for the given context. Conclusion The Agile Manifesto marked a paradigm shift in software development, advocating for more flexible, iterative, and collaborative processes. While its principles have significantly influenced modern software development practices, it’s important for engineering managers to understand and apply these principles judiciously. Misinterpretations and rigid methodological adherence can lead to the very pitfalls Agile seeks to avoid. Ultimately, Agile is about creating better software, fostering better teamwork, and satisfying customers, and should be seen as a flexible guide rather than a rigid doctrine.
Embarking on the exciting journey of bringing a product from idea to market requires careful planning and storytelling. Product managers play a crucial role in defining and guiding the success of a product. From the inception of an idea to its market launch, product managers have to navigate through various challenges and make strategic decisions. As a product manager, crafting compelling narratives and strategies is key to success. As the LLM is disrupting the market PMs can use LLMs to build effective strategies at each stage of the product lifecycle to improve their productivity. This article is all about identifying the life cycle from ideation to market and how we can use prompt engineering to query an LLM model and increase productivity as a product manager. Product management is the art of turning ideas into experiences, challenges into opportunities, and dreams into tangible realities. A great product manager crafts not just solutions but stories that resonate with the hearts and needs of users. A Large Language Model (LLM) are advanced artificial intelligence system, primarily based on transformer architectures. and are powerful language models known for their broad language understanding and generation capabilities. Trained on vast datasets, they excel in understanding and generating human-like language. They offer powerful capabilities in natural language processing, enabling tasks such as crafting compelling narratives, generating creative content, and interpreting user queries with high accuracy. Leveraging LLMs empowers product managers to streamline communication, enhance user experiences, and extract valuable insights from textual data throughout the product development lifecycle. Integrating these models requires understanding their architecture, training processes, and the art of effective prompt engineering. Prompt engineering is the practice of crafting text in a way that a generative AI model can interpret and comprehend. A prompt, which is natural language text outlining the task for the AI, can take various forms, such as a query, command, feedback, or a detailed statement with context and instructions. The process involves formulating queries, specifying styles, offering context, or assigning roles to the AI. Additionally, prompts may include examples for the model to learn from, employing a few-shot learning approach. Effective prompt engineering is like giving clear instructions to a clever robot friend. It's about crafting questions or tasks in a way that helps the robot understand exactly what you want. It's like speaking their language to get the best results! Let's discuss a few prompt examples for PMs in different phases of product development to get help in documenting and crafting quality stories with meaningful tasks. The prompts are just hints, a little more effort and you can be creative and add more to add it for sure get the most productive results. We will consider a "To-Do" list as a product for all examples. Idea Exploration: At the inception of the product journey, we can dive into the story of how the idea was born. We have to discover the issue it wants to address, identify possible challenges for users, and imagine how it fulfills the demands of the market. At the beginning, unravel the story behind your product's idea. Imagine a time when someone realized how hard it was to remember all the tasks for the day. This realization led to the idea of a smart to-do list app that not only stores tasks but also sends friendly reminders. Prompt: "Generate a detailed narrative outlining the initial spark of the product idea. Describe the problem it solves, potential user pain points, and how it addresses market needs." User Persona Development: Create a story around the primary user of your product. Define their characteristics, goals, and challenges. Illustrate how your product becomes an essential part of their daily life, addressing their specific needs and concerns. Create a story about the primary user of your product. Picture a friendly neighbor named Tapan, a busy professional who struggles to stay organized. Describe how your smart to-do list app becomes Tapan's assistant, making his life easier and more enjoyable. Prompt: "Create a story around the primary user persona for the product. Define their characteristics, goals, and challenges. Illustrate how the product will enhance their daily life or address specific pain points." Competitive Landscape Analysis: Navigate through the competitive landscape, telling a strategic tale of key competitors, their strengths, and weaknesses. Share how your product will stand out and carve its path in the market. Navigate through the competitive landscape by telling a story. Consider a marketplace where various to-do list apps exist. Define how your app stands out by offering a delightful experience, combining simplicity with powerful features. Prompt: "Compose a strategic analysis of the competitive landscape. Identify key competitors, their strengths and weaknesses, and how our product will differentiate itself in the market." Value Proposition Crafting: Craft a compelling story that highlights the core value your product offers. Showcase unique features and benefits that distinguish it from other solutions, aligning seamlessly with the needs of your target audience. Craft a compelling story around the core value your product offers. Imagine a conversation with a user named Shree. She loves how your app not only keeps her organized but also adapts to her preferences, creating a personalized and stress-free experience. Prompt: "Articulate the core value proposition of the product. Describe the unique features and benefits that set it apart from existing solutions. Consider how it aligns with the target audience's needs." MVP Definition: Focus on the story of your Minimum Viable Product (MVP), detailing key features prioritized for the launch. Consider scalability and user adoption as you show the way for a successful introduction to the market. Visualize a small group of users who eagerly try out your app's basic features. Their feedback becomes a crucial part of the story, helping you shape the app into something that truly meets their needs. Prompt: "Outline the Minimum Viable Product (MVP) for the initial launch. Define the key features and functionalities that will be prioritized to deliver value quickly. Consider scalability and user adoption." User Journey Story: Map out a user's journey from discovery to becoming a loyal customer. Focus on the touch points, anticipate challenges, and reveal how your product provides solutions at every step of the way. Map out a user's journey with a story. Follow Tapan as he discovers the app, starts using it daily, and eventually becomes a loyal user. Narrate how the app seamlessly fits into different aspects of his life, from work meetings to weekend plans. Prompt: "Map out the user journey from discovering the product to becoming a loyal customer. Describe touchpoints, potential challenges, and how the product addresses user needs at each stage of the journey." Go-to-Market Strategy: Craft a strategic narrative for your go-to-market plan. Define your target audience, outline promotional channels, and share key messaging. Explore pre-launch activities, launch day execution, and post-launch engagement. Imagine Shree sharing her experience with friends and colleagues, creating a buzz around the app. Describe how your marketing campaign spreads the word, making the app a must-have for busy professionals like Tapan and Shree. Prompt: "Develop a comprehensive go-to-market strategy. Define the target audience, channels for product promotion, and key messaging. Consider pre-launch activities, launch day execution, and post-launch engagement." Iterative Development Plan: Tell the story of how your product evolves with an iterative development plan. Discuss how user feedback is collected and integrated into future releases, embracing an Agile approach for continuous improvement. Picture a scenario where user feedback leads to new features, making the app even more user-friendly. Describe an iterative journey where each update brings joy to users like Tapan and Shree. Prompt: "Create a phased plan for iterative development. Outline how user feedback will be collected and incorporated into future releases. Consider the Agile methodology and continuous improvement." Marketing Campaign Concept: Paint a vibrant picture of your marketing campaign. Set the theme, outline key messaging, and choose the most effective channels for promotion, both online and offline. Imagine creating a fun and relatable video featuring Tapan and Shree. Picture them sharing how the app has become an essential part of their lives, adding a personal touch to your marketing strategy. Prompt: "Craft a concept for a captivating marketing campaign. Define the theme, key messaging, and channels for promotion. Consider both online and offline strategies for maximum reach." Metrics for Success: Conclude your journey by defining metrics for success. Share how these indicators align with overarching business goals, reflecting user satisfaction, adoption, and retention. Picture a dashboard filled with positive numbers – increasing user engagement, high satisfaction rates, and a growing community of users who appreciate the simplicity and effectiveness of your smart to-do list app. Prompt: "Specify key performance indicators (KPIs) to measure the success of the product. Outline how these metrics align with overarching business goals and reflect user satisfaction, adoption, and retention." For product managers, these prompts become the tools to shape a compelling narrative that guides their products to success. As we conclude, remember: "Embarking on the product journey is like telling a captivating story. With these simple yet powerful prompts, you have the tools to shape your narrative and guide your product to success. Let your story unfold, embracing each stage of the journey with enthusiasm, adaptability, and a keen eye for the needs of your audience." Example of a Story Written by Chat-GPT With a Good Prompt. Prompt: I want you to act as a Product Manager. Define clear and concise Gherkin-style stories for the "Where is My Order" feature on an online retail platform, ensuring a seamless and user-friendly order tracking experience. Make sure that you write the story and various sub-tasks associated with it and write the functional requirements as an objective for completing the story. Gherkin is a format for writing executable specifications, commonly used with behavior-driven development (BDD) tools. Remember that we've only scratched the surface. We've explored how these language models can be productive in crafting compelling product narratives, and we've taken baby steps at effective prompt engineering. There's so much more to discover! The landscape of language and AI is vast, and as we continue this adventure, there's always more to learn, experiment with, and explore. Keep that curiosity alive! LLM is causing quite a disruption in the market scene. AI is the co-pilot in the journey of product management, navigating through complexities, predicting user needs, and ensuring a smooth ride to success. Further Learning: ChatGPT Prompts for Agile Practitioners Ethical Prompt Engineering: A Pathway to Responsible AI Usage Prompt Engineering: Unlocking the Power of Generative AI Models Let's keep the conversation going! I'd love to hear your thoughts on Large Language Models and prompt engineering. Feel free to share your experiences, ask questions, or even share your tips. Your feedback is like a compass guiding me through this language adventure! Drop your thoughts below, and let's explore the world of words together.
The Dynamic Squad model, a software development model, is the modern way of organizing software development teams focusing on a specific set of goal(s). A squad is a small group of people focusing on a particular goal or purpose. The size and lifespan of each squad will be different and will be based on the goal; hence, it's referred to as dynamic. Structure Each Dynamic Squad consists of at least four roles : Squad Structure Role Description Squad Lead Development leader who leads the squad Product Lead Provides Product Guidance Team Member(s) Developers, QA Tester Project Manager Manages the delivery plan for the squad Developer(s) are dedicated to one squad at a given time, whereas Squad Lead, Product Lead, and Project Managers can be involved in multiple Dynamic Squads depending on the needs in a particular organization. Life Cycle of Squad The life cycle of Squad consists of the following three phases. Create Senior Leadership appoints Squad Lead, Product Leads for Squad Squad Lead & Product Lead deep dives into the goal(s) and identify resources needed and appropriate team members from the available resource pool Squad is formed Function The squad starts detailed analyses of requirements associated with goal(s) and defines high-level solutions. The project manager outlines the overall delivery strategy and plan Squad now started putting the plan into motion using Agile methodology. Kanban is more suitable with this model, but depending on the nature of the work, Squad can decide and use Kanban or Scrum agile methodology. For proper execution highly recommend the following ceremonies: # Ceremony Frequency Purpose Participants 1 Squad huddle Daily To keep everyone in the squad aware of the progress Squad, PjM, PL 2 Requirements Refinement Weekly once or twice To refine the requirements on an ongoing basis Squad, PL 3 Retrospective Bi-weekly To come up with lessons learned and improvements Squad 4 Squad Leadership sync Weekly To monitor the squad's progress, Dependencies and risks and appropriate adjustments are made as needed. SL, PL, PjM Dissolve The squad enters into this phase once goals are achieved, and deliverables are pushed to production. The squad does a retrospective to identify what went well and what didn't go as per the plan and identifies potential improvements for upcoming squads. The squad gets dissolved, and members are released back to the resource pool so that they can be part of upcoming squads. Pros of the Model Focus on goals results in focus on delivering value Developer(s) are focused on one or more related goal(s), which reduces context switching and improves productivity, and also time to market is less The agility of the model allows quick adaptation to changes in scope, priorities, or business demands. The dynamic nature of this model allows leaders to do dynamic resource allocation as compared to strong team boundaries. Developer(s) get the opportunity to work on different things in a systematic order instead of multiple projects simultaneously, which boosts their morale. Squad members take ownership of their tasks, leading to higher accountability and commitment. Cons of the Model It's a cultural shift; hence, implementation from the traditional hierarchical model to this model could be challenging. Scaling this model with for large organization with a matrix structure needs an open mindset, continuous learning, and adaptation for successful implementation. Case Study I used this model for a group of 35+ developers. The group was responsible for Client Customization and integration development. For a while, operating in a scrum team-based model resulted in different challenges, as listed below. Developers need to switch context more often while simultaneously working on multiple client-specific projects, which is painful, less productive and takes a longer time to market. Difficult to maintain the team's backlog Due to strong team boundaries, it is hard to move resources between scrum teams based on need. To improve team efficiency and for a shorter time to market, there is a need for the group to operate in an innovative model that allows dynamic resource allocation. Developers have to focus on one thing at a given time. Started adapting the dynamic squad model. At a given point, there were 5-6 Squads, as shown below, with specific goals: After adoption, observed the following advantages Time to market improved by 50%, i.e., before, it used to take six weeks to deliver, whereas in the Dynamic Squad model team was able to deliver a similar type of work in about three weeks. The team happiness survey indicated that individual member’s happiness has increased by 25% since day-to-day operations became more structured and organized. Overall, leadership observed the success of the group after adopting the Dynamic Squad Model. Other examples where this model can be used are in Startups and big companies focusing on next-generation product development in a fast-paced start-up-like environment. Also, the latest emerging technologies complement this model.
Arun Pandey
|Accredited Investor| Enterprise Coach| Sr. TechLead| Topcoder Ambassador|
Otavio Santana
Award-winning Software Engineer and Architect,
OS Expert