Culture and Methodologies

Sometimes in our careers, we feel like we're not progressing from our current level. Well, who doesn't? The least said about it, it is an annoying place to be: working hard, putting in long hours, and feeling like our career is going nowhere. I was there too. So, after having navigated my way through it, here's advice I wish I could give my past self. The Reality Check: Why Hard Work Alone Isn’t Enough I’ve noticed a common myth at workplaces that working long hours will get you a promotion. The reality is that putting in extra hours is not a differentiator. While dedication and a strong work ethic are important, it may not take you to the next level. Any leadership looks for people who can tackle higher-level challenges and lead through influence rather than effort. You have more chances to move forward if you are a strategic thinker rather than a hard worker. A lot of successful experts who have climbed the ladder have a few things in common: they prioritize strategic impact, lead by example, and take the initiative to tackle further complex challenges. Camille Fournier, former CTO of Rent the Runway, emphasizes in her book "The Manager's Path" that transitioning from an individual contributor to a leadership role requires a focus on guiding others and taking on projects that impact the entire organization. Think about the following engineers. The first engineer regularly completes work by working after hours, produces a lot of code, and meets deadlines. In contrast, the second one assumes responsibility for cross-functional projects, focuses on identifying trends, solving issues that affect numerous teams, and shares knowledge to elevate team productivity. Although both engineers are valuable, the second engineer has a much higher chance of being given a promotion. Why? He is not only making a positive contribution to the team but also driving its success and exhibiting crucial leadership traits at the senior level. The Path to Promotion: Focus on Next-Level Problems and Leadership To get past mid-senior you need to stop focusing on the work you do and focus on the impact of that work. Will Larson, in his book, "An Elegant Puzzle," discusses how senior engineers should focus on high-leverage activities, such as system design and mentorship, rather than getting caught up in day-to-day coding tasks. Below are three-step strategies that can help you grow. 1. Work on Next-Level Scoped Problems At the mid-senior level, technical skills are expected. What distinguishes you is your ability to work on problems of a larger scope and greater strategic importance. These are problems that require not only technical expertise but also business acumen and the ability to connect your solutions to the company's long-term goals. Here is an example of owning a cross-team initiative. Suppose there are problems integrating a certain new technology stack across different products. Instead of contributing to this initiative by writing code for only your application, one could take ownership of the entire project. This would be carried out by coordinating with the involved teams, understanding the variations in need and constraint, and thereafter delivering a solution keeping in view the overall strategy of the product platform. This means you're solving more than a problem: you can show that you can manage complexity, influence others, and drive outcomes that have a material impact on the business. 2. Deliver Through Others As you go up the career ladder, success for you will be delivered through influencing and guiding people around you. This perhaps will be one of the most important transitions from an individual contributor to a leader. Whether you mentor, delegate, and collaborate across teams is going to be most crucial for your promotion. Suppose you are tasked with the implementation of some new feature. Instead of making the whole implementation yourself, you realize that there's a junior who can take on some portions of the implementation. You then invest in teaching them through proper specification and best practices needed. By effectively delegating, you empower others, freeing your time for more strategic activities at higher levels. This way, you show that you can lead a team, which is one of the competencies needed to access senior positions. 3. Think Strategically and Be Proactive The level at which you work requires good execution; you must think strategically. That means knowing the context of the business, knowing what problems are going to happen in the future, and therefore proactively suggesting solutions. Suppose you find your company's development process hemorrhaging inefficiencies, slowing down the release cycle. Maybe instead of waiting for another person to fix that problem, you could propose a new initiative that smooths out the process. You would research best practices, build stakeholder support, and lead the implementation of the new process. This proves that apart from you being a problem solver, you are also a strategic thinker who can seize opportunities and ensure change. Final Words: Shift Your Mindset, Elevate Your Career If you feel stuck at your current level, it’s time to rethink your approach. Growing is not just about working harder — they’re about demonstrating your ability to handle next-level challenges and lead others to success. Jeff Shannon, author of "Hard Work is Not Enough: The Surprising Truth about Being Believable at Work," wrote that people will tell you that hard work will take you far, but it won't. He believes that "hard work is a good start" to get yourself established early in your job, but it is not enough to help you rise to the top. Start by focusing on problems that have a broader impact, mentor and guide your peers, and think strategically about how you can contribute to the company’s long-term goals. By making these shifts, you’ll not only position yourself for progression but also develop the skills and mindset needed to thrive in senior-level roles. It isn’t just about the hours you put in—it’s about the difference you make.

By Gaurav Gaur CORE

TL; DR: Why Solving Customer Problems Instead Matters Scrum is just a tool; your job is to solve real customer problems and deliver value. Stop focusing on perfecting frameworks and start prioritizing outcomes that matter. It’s time to reassess what truly drives your success, particularly given the challenging business environment. Why Solving Customer Problems Matters More Than Perfecting Scrum Agile practices, particularly within Scrum, often captivate practitioners with their events, roles, principles, rules, and stickies. However, practitioners tend to overlook two crucial truths — both veterans and newcomers alike: First, we are not paid to practice Scrum — or any other specific agile framework — but to solve our customers’ problems within the given constraints while contributing to the organization’s sustainability. Remembering that our primary responsibility — helping create valuable outcomes — goes beyond simply adhering to a framework is essential. Our value lies in navigating complex challenges, delivering meaningful solutions, and supporting the organization’s long-term health and profitability. Second, as long as we deliver business value ethically, legally, sustainably, and in a financially viable manner, no one cares about the specific tools or frameworks we use. And rightfully so. The reality is that customers, stakeholders, and executives are not interested in the mechanics of how you deliver value — they care about the outcomes. Whether through Scrum, Kanban, or any other method, the tangible business value you create matters. These basic principles are often overshadowed by a focus on perfecting using agile frameworks, which can lead to a dangerous complacency. Regardless of experience, Agile practitioners may fall into the trap of believing that mastering Scrum — or any other Agile framework — guarantees success. However, the practical, real-life measure of success lies in the business value delivered, not in the flawless execution of a framework. Suggested Calls to Action I encourage you to reflect on your current practices. Are you indeed focused on delivering value, or have you been caught up in the pursuit of perfecting your use of a framework? Are you solving real customer problems or simply following processes without questioning their impact? You can quickly start analyzing your current situation: Reassess your priorities: Take time to critically evaluate whether your current focus is on solving customer problems or simply following Scrum’s motions. Adjust your approach accordingly. Engage with stakeholders: Start conversations with your stakeholders and customers to ensure you align on what they perceive as value. Use this feedback to inform your team’s efforts. Challenge the status quo: Regularly question whether your practices and tools are the best fit for delivering value in your current context. Be willing to adapt and change when necessary. Emphasize outcomes over outputs: Shift your team’s focus from completing tasks to achieving outcomes that make a meaningful difference to your organization and its customers. Reflect and adapt: Build a habit of personal reflection. Regularly reflect on your role and contributions and make adjustments to ensure that you are not just practicing Scrum but genuinely delivering value. Conclusion Let’s cut to the chase: If you’re still equating your success with how well you adhere to Scrum events or how strictly you follow the rules of any framework, you’re missing the point. Agile, at its core, isn’t about religiously practicing Scrum or any other practice. It’s about solving real customer problems, delivering tangible value, and doing so in a way that sustains the organization. Scrum and other frameworks are merely tools in your toolbox. They’re helpful, but they’re not the endgame. The real question is: Are you using these tools to create something that matters? If you’re more concerned with the process than the outcomes, it’s time to reassess your priorities. Take a moment to reflect: Are your practices driving value, or are they just going through the motions? Are you challenging the status quo, or are you complacent, mistaking adherence to a framework for progress? Your role as a Scrum Master or Agile Coach isn’t about being a gatekeeper of Scrum but a catalyst for change and delivering value. In the end, nobody cares about the tools you use if you’re not delivering results. It matters whether you’re helping your team and organization solve the right problems and achieve meaningful outcomes. So, take a hard look at your approach and ask yourself: Are you delivering the value your customers and stakeholders need, or are you just ticking boxes? To stay relevant and valuable, focus on what truly counts. Remember, it’s not about Scrum — it’s about delivering results that matter.

By Stefan Wolpers CORE

The Night That Changed Everything Remember the days when your phone buzzed more often than a beehive in spring? That was us, drowning in a sea of alerts. Our Slack channels looked like Times Square on New Year's Eve, and our PagerDuty . . . well, let's just say it was living up to its name a little too enthusiastically. We were facing a classic case of alert fatigue, and it wasn't just costing us sleep — it was impacting our ability to respond to real incidents. Something had to give, and it wasn't going to be our sanity. The Reality We Were Facing Looking back, it's almost funny how bad things had gotten. Almost. We had alerts for everything. And I mean everything. Server hiccup? Alert. Tiny traffic spike? Alert. Someone breathe on the database? You guessed it, alert. Finding a real problem was like searching for a needle in a haystack. A very loud, annoying haystack. Our alerts were everywhere. Slack, email, PagerDuty — you name it, we had alerts there. It was chaos. How We Turned Things Around The next morning, running on more coffee than sleep, I called a team meeting. We knew we had to change things, but where to start? Here's what we came up with: 1. Operation: Slack Cleanup First things first, we had to get our Slack under control. We created one channel — just one — for all our important alerts. It was like finally organizing that junk drawer in your kitchen. Suddenly, we could see what we were dealing with. 2. The Dashboard Dream One of our newer team members had been tinkering with Datadog. We gave him the green light to go all out. A week later, he came back with a dashboard that blew us away. For the first time, we could see our entire system at a glance. It was like going from a flip phone to a smartphone. 3. Weekly Alert Therapy We started meeting every Friday to go over the week's alerts. It was part post-mortem, part planning session, and, let's be honest, part group therapy. But it worked. We started seeing patterns we'd never noticed before. 4. Taming the Noisiest Alerts Instead of trying to fix everything at once, we focused on the worst offenders. Each week, we'd pick the 2-3 alerts that were driving us the craziest and work on those. Slow progress, but progress nonetheless. 5. Rewriting the Rulebook We took a hard look at our alert rules. Some of them were older than our newest team members. We updated, rewrote, and sometimes just flat-out deleted rules that weren't serving us anymore. 6. Monthly Alert Audit Once a month, we'd take a step back and look at the big picture. Were our changes working? What new problems were cropping up? It was like a monthly health check for our alert system. The Results (Or, How We Got Our Lives Back) I won't lie, it took time. But after a few months, the difference was night and day: Our alert volume dropped by almost half. Suddenly, when an alert came in, we knew it mattered. People started looking. . . rested? The bags under our eyes were disappearing, and our caffeine budget went down. Most importantly, we were catching real issues faster than ever. Turns out that when you're not drowning in noise, it's easier to hear the important stuff. What We Learned This whole experience taught us a lot. Maybe the biggest lesson was that alerts are supposed to help us, not run our lives. We learned to be picky about what deserves our immediate attention and what can wait. Going forward, we're sticking to a few key principles: We review our alerts regularly. What made sense six months ago might not make sense now. We're always looking for ways to make our system smarter. Better tools, better processes — whatever helps us work smarter, not harder. We talk. A lot. About what's working, what's not, and how we can do better. The Bottom Line Look, our system isn't perfect. We still get woken up sometimes, and we still have the occasional false alarm. But it's so much better than it was. We're not just reacting anymore; we're in control. To any team out there drowning in alerts: there's hope. It takes work, and yeah, probably a few late nights. But trust me, when you get to silence your phone at night and actually sleep? It's worth it. Here's to fewer alerts, more sleep, and happier engineers. We got there, and you can too. Additional Contributor This article was co-authored by Seema Phalke.

In the world of software engineering, a conflict between a product manager's vision and the engineering team's technical strategy is a recurring obstacle for many teams. While product managers strive to create disruptive and innovative products, engineers need to ensure that these visions can be implemented into successful realities either within the constraints of current technology or discover a breakthrough themselves. The gap between the product vision and the technical realities can be a daunting challenge, but balancing these two aspects is crucial for the success of any project. This article explores the dynamics between product vision and technical reality and how taking an iterative approach can help navigate the gap between the aspect and the feasibility. Understanding the Product Vision Imagine you are a builder (software developer) and are hired by a family (product manager) to build a house. The family will have an image of a dream house in their mind — a beautiful, large, comfortable home that will fulfill all their functional and lifestyle dreams (vision). Now, for the builder to do their job well, they need to understand the family's vision and then build upon it. But at the same time, the family's vision also needs to be well crafted and decipherable for the builder to comprehend it. Along similar lines, a well-defined and well-constructed product vision is essential for guiding a successful technical strategy. At the same time, it is equally essential to ensure that this vision maps to a feasible reality. The engineering team should actively participate in shaping the product vision, adding insights about technical constraints or potential limitations. Even if the product vision is deemed ambitious or poses technical challenges, there is always a product strategy guiding that vision. Product managers and the engineering team should meet regularly to whiteboard and plan solutions, ensuring a technically viable plan is driving this strategy. This way, the engineering team can build and apply the technical strategy at a micro level and make better decisions for execution. What Happens When the Product Strategy Doesn’t Align With the Technical Strategy? While collaborative meetings or whiteboarding sessions are a necessity, there are two other key areas where forgoing can quickly create grounds for failure: Roadmap and Ownership. If the product and engineering organizations are not in alignment about what features they want to build and when or if they do not have clear ownership metrics about who will drive the planning and execution decisions, it can quickly lead to an array of problems. Launch delays, resourcing constraints, organizational friction, and increased costs are some of the most common ones. Contrary to the above, when engineers start getting pulled into more strategic discussions to brainstorm questions like what should we build along with the "how to" and "can we" build it, sometimes overreliance on execution strategy (the how?) can also hamper "the what" and "the why." If the product managers keep getting a "No" or "Maybe" for most of their ideas from engineering partners, it can quickly break the trust relationship between the two teams. It is essential to understand that technical strategy is often not about using the latest technology for product development. Nor is it about finding the best or most innovative plan for development. As a matter of fact, these emerging innovative tech stacks come with their own burden of scalability and integration restrictions. Additionally, such integrations can create an over-dependency on the development team for any bug fixes or new features due to the educational gap. Trying to focus on developing the most innovative tech strategy can result in a future of the "wrong" kind of technical debt and can hamper the future of product and customer growth. Speed is also a critical factor, considering the rapid pace of market evolution. With such hasty changes in customer behavior, the once visionary product can quickly become obsolete if not manifested fast enough. In my experience, the best technical strategies are the ones that focus on faster execution without adding additional friction of tech debt. The goal here is for engineers to focus on what we can build, edging the umbrella of current constraints instead of focusing on what we cannot. That is how we will foster a trustable partnership between the product and engineering teams and deliver groundbreaking products. Working Through the Feasibility Gap Working through the gap between the product vision and technical strategy is not about compromising the product vision, but rather about creatively adapting it to align with technical limitations, potentially creating a better product-market fit. In the process of working on these groundbreaking products, there will be several scenarios where an agile trifecta of flexibility, adaptability, and continuous feedback can help achieve the product vision or save engineering efforts from going adrift. In a rapidly evolving tech market, If the product needs change faster than your product can actualize any value, an agile approach will allow you to gather feedback quicker and refine your product to meet the evolving market needs. Innovative products often come with a factor of "unknown," such as technological constraints, economic shifts, or regulatory changes. An agile approach can help you respond faster to such unexpected disruptions. Even if the interruption is internal, such as a change in leadership priorities, or if the launched product does not meet leadership expectations, the results can be disappointing, but this is where an agile approach to roadmapping can save a lot of potential churn and overhead. We must not forget the importance of open-ended communication and collaborative working environments. When engineering teams understand why they are building something and how it helps the business, they will always propose better solutions to bridge that gap. Overall, an Agile approach will enable the creation of a more responsive and adaptable MVP timeline, allowing the project to progress responsively and iteratively. The product roadmap can be planned into measurable milestones that can be tracked via shared metrics. Such a structure will help teams create more realistic and responsive timelines, progressively closing the gaps to match the evolving product vision. Conclusion: Examples of Successful Deconstruction of Product Vision Into Actionable Goals That Align With Technical Feasibility 1. Spotify's Personalized Playlists Spotify transformed its vision of providing highly personalized music experiences into actionable goals by leveraging data engineering and machine learning technologies. They broke down the vision into smaller, feasible projects like the Discover Weekly feature, focusing on algorithms that analyze user behavior to suggest new music tailored to personal tastes. 2. Airbnb's Global Expansion Initially, Airbnb aimed to provide an alternative accommodation option for guests attending a conference in San Francisco. This initial concept evolved into a platform connecting travelers with hosts offering short-term accommodations. Recognizing the technical and operational challenges of global scaling, they deconstructed this vision into small and quickly actionable goals, such as establishing local market strategies and adapting the platform to support different languages and handle payment complexities. This approach allowed Airbnb to address the logistical hurdles of international expansion systematically. 3. Tesla's Electric Vehicle Production Tesla's success can be widely attributed to its intelligent and phased alignment of product vision with technical feasibility. Tesla had a very clear product vision of moving the world towards sustainable energy solutions while emphasizing electric vehicles. They used their in-house expertise in lithium-ion battery technology to gain a competitive edge and challenged the norms of the traditional automotive industry by showcasing "software-driven" vehicles. Planning a vertical integration strategy and constantly providing a superior user experience allowed Tesla to plan and incrementally overcome technical barriers, including battery cost reduction and introducing enhanced capabilities via software updates over time. These examples clearly show how aligning product vision with technical strategy is paramount to driving innovation and how deconstructing these visions into technically feasible goals allows companies to systematically approach complex challenges and achieve success in their product development journeys.

TL; DR: Transformed and Scrum Despite criticism from the product community regarding Scrum as a framework for effective product creation, namely Marty Cagan himself, I believe that it is worthwhile to compare the principles that help form successful product teams with those of Scrum. Let’s delve into an analysis of “Transformed” and how its principles align with Scrum’s. Matching Transformed’s Product Success Principles with Scrum Principles Last week, Paweł Huryn summarized the product success principles from Marty Cagan’s book Transformed. (Please find his post on LinkedIn and consider following him.) I took those principles and compared them step-by-step with the principles derived from the Scrum Guide. As an agile practitioner, you are familiar with the ongoing debate about the best frameworks and principles that drive success. Marty Cagan's Transformed offers a set of product principles that are widely respected in the product community, but can these principles coexist with Scrum, a framework often critiqued by the same community? Despite the criticism, a closer look reveals that Scrum aligns with and enhances these principles when implemented effectively. Scrum’s values and practices effectively support each principle, from empowering teams and focusing on outcomes to fostering innovation and continuous learning. Scrum's emphasis on self-managing teams, iterative progress, and servant leadership creates a culture that prioritizes value, innovation, and adaptability—key ingredients for building successful products. When applied correctly, Scrum is a robust framework for driving product success. So, let’s delve into how Scrum matches the five key product principles identified by Paweł Huryn in Transformed, demonstrating that Scrum remains a powerful approach for building successful products: I. Product Team Principles 1. Principle: Empowered With Problems to Solve Scrum principle match: Self-managing teams Explanation: In Scrum, teams are self-managing, meaning they have the autonomy to decide how to tackle the problems. This aligns with the principle of being empowered with problems to solve, as the Scrum Team, particularly the Developers, are empowered to decide how to approach their work within the Sprint to achieve the Sprint Goal. 2. Principle: Outcomes Over Output Scrum principle match: Focus on delivering value Explanation: Scrum emphasizes delivering value over simply completing tasks. The Sprint Goal and the focus on delivering potentially releasable Increments during each Sprint align with the principle of prioritizing outcomes over output. Scrum teams are encouraged to focus on what brings the most value, not just on doing more work. 3. Principle: Sense of Ownership Scrum principle match: Commitment Explanation: Scrum instills a strong sense of ownership through the commitment to Sprint and Product Goals and the collective responsibility of the Scrum Team. For example, each team member is committed to achieving the Sprint Goal, which fosters a sense of ownership over their work. 4. Principle: Collaboration Scrum principle match: Collaboration and cross-functionality Explanation: Scrum’s framework is built on collaboration, particularly within the Scrum Team, which is cross-functional and works together closely to deliver the Sprint Goals. Daily Scrums, Sprint Planning, and Retrospectives all emphasize and facilitate collaboration. Unsurprisingly, no one on a Scrum team has any authority to tell anyone else what to do or how to do things. Selected Insight "The most fundamental of all product concepts is the notion of an empowered, cross-functional product team." Scrum alignment: Scrum’s very foundation is built upon cross-functional teams empowered to manage their work. This directly aligns with Scrum’s principle of forming cross-functional teams with all the skills necessary to deliver Product Increments every Sprint. II. Transformed: Product Strategy Principles 1. Principle: Focus Scrum principle match: Sprint Goal Explanation: In Scrum, the Sprint Goal focuses on the entire team during a Sprint. It is a singular objective that the Scrum Team commits to achieving, which aligns perfectly with the principle of focus in product strategy. This focus ensures the team works towards a common, clearly defined goal. 2. Principle: Powered by insights Scrum principle match: Empiricism Explanation: Scrum is built on the pillars of empiricism: transparency, inspection, and adaptation. The process of inspecting the Increments, gathering feedback, and adapting the Product Backlog accordingly is driven by insights gained through these activities. This ensures that decisions are based on actionable data and information rather than assumptions. 3. Principle: Transparency Scrum principle match: Transparency Explanation: Transparency is one of Scrum’s core pillars. All aspects of the Scrum process are visible to those responsible for the outcome. This ensures that all team members and stakeholders clearly understand the project's current state, which directly aligns with the principle of transparency in product strategy. 4. Principle: Placing Bets Scrum principle match: Product Backlog refinement Explanation: In Scrum, the Product Backlog represents at any moment what the team considers necessary to accomplish the next step. Based on new insights, it is continuously refined and prioritized based on what is most valuable to the customer and the organization. This process involves placing bets on which backlog items (problems or features) should be addressed next based on their potential impact and alignment with the Product Goal. Selected Insight "Product strategy is all about which problems are the most important to solve." Scrum alignment: Scrum aligns with this principle by defining Product Goals and, consequently, the ongoing prioritization and refinement of the Product Backlog to reflect the “best” path to accomplish this goal. The Product Owner continuously assesses which items are most critical to achieving the Product Goal, ensuring the Scrum Team is always focused on solving the most important problems. III. Product Discovery Principles 1. Principle: Minimize Waste Scrum principle match: Iterative development and incremental delivery Explanation: Scrum’s iterative and incremental approach inherently minimizes waste by focusing on delivering small, valuable Increments that are regularly reviewed and adjusted. This prevents large amounts of work that may not be needed or valued, aligning with the principle of minimizing waste. 2. Principle: Assess Product Risks Scrum principle match: Inspection and adaptation Explanation: In Scrum, the regular inspection of Increments and subsequent adaptation of the Product Backlog help to identify and manage risks early. By continuously assessing what has been built and adjusting the plan accordingly, Scrum teams can mitigate product risks effectively. 3. Principle: Embrace rapid experimentation Scrum principle match: Sprint Explanation: Each Sprint in Scrum can be seen as an experiment in which the team tests ideas and solutions by building and delivering Increments while investing in product discovery activities, such as creating prototypes to test assumptions. This rapid cycle of planning, execution, review, and adaptation aligns with the principle of rapid experimentation in product discovery. 4. Principle: Test Ideas Responsibly Scrum principle match: Sprint Planning and incremental approach Explanation: In Scrum, Sprint Planning can be adapted to include the creation of prototypes or experiments specifically for testing assumptions. These experiments do not need to meet the full Definition of Done but should be designed to gather valuable feedback quickly and responsibly. By breaking down larger ideas into smaller, testable components (often referred to as "spikes" or "experiments"), teams can test assumptions without the full cost of production-level quality. This incremental approach allows teams to validate hypotheses quickly, adjust based on feedback, and ensure they responsibly manage risk and resources during the discovery phase. Selected Insight "The heart of product discovery is rapidly testing product ideas for what the solution could be […] an experimentation culture not only helps you address risks, but it is absolutely central to innovation." Scrum alignment: Scrum’s framework is built around iterative experimentation. Each Sprint is an opportunity to test and validate ideas quickly, making Scrum a natural fit for an experimentation-driven approach to product discovery. IV. Transformed: Product Delivery Principles 1. Principle: Small, Frequent, Uncoupled Releases Scrum principle match: Incremental delivery Explanation: Scrum promotes delivering small, valuable Increments frequently. Each Sprint should produce potentially shippable product Increments that can be released to stakeholders or users. This aligns with the principle of small, frequent, and uncoupled releases, ensuring continuous value delivery. 2. Principle: Instrumentation Scrum principle match: Definition of Done and transparency Explanation: The Definition of Done in Scrum includes all the criteria necessary to ensure that an Increment is fully functional and of high quality. Instrumentation — such as testing, documentation, and monitoring — is crucial to meet the Definition of Done, ensuring that every Increment is releasable. Transparency in Scrum also ensures that the state of each Increment is always visible and understood by all stakeholders. 3. Principle: Monitoring Scrum principle match: Empiricism (Inspection and Adaptation) Explanation: In Scrum, regularly inspecting and adapting the product is akin to monitoring. By constantly checking the product’s progress and quality through reviews and inspections, Scrum teams can identify issues early and make necessary adjustments, aligning with the principle of ongoing monitoring. 4. Principle: Deployment Infrastructure Scrum principle match: Continuous Integration and Deployment Explanation: While Scrum doesn’t explicitly prescribe technical practices, it is often complemented by practices like Continuous Integration and Continuous Deployment (CI/CD). These practices ensure that the deployment infrastructure is set up to allow for frequent, reliable releases, which aligns with the principle of having a robust deployment infrastructure. Selected Insight "This means, at a minimum, each product team releases their new work no less than every other week (…) For strong product companies, this means releasing several times per day (...)." Scrum alignment: Scrum’s iterative cycles of work (Sprints) encourage regular, frequent releases. While traditional Scrum suggests a Sprint duration of up to one month, many teams operate in environments where releases happen more frequently, demonstrating Scrum’s flexibility to accommodate rapid delivery cycles. V. Product Culture Principles 1. Principle: Principles Over Process Scrum principle match: Scrum values (Commitment, Courage, Focus, Openness, Respect) Explanation: Scrum places a strong emphasis on values that guide the behavior of the team rather than rigidly adhering to a process. These values create a culture where principles like commitment and openness take precedence, enabling teams to make decisions that align with their goals and values rather than just following a set process. 2. Principle: Trust Over Control Scrum principle match: Self-managing teams Explanation: Scrum teams are self-managing, meaning they have the authority and trust to decide how best to achieve their goals. This principle of trusting the team to make decisions rather than imposing strict control aligns perfectly with Scrum’s emphasis on self-management and empowerment. 3. Principle: Innovation Over Predictability Scrum principle match: Empiricism (Inspection, Adaptation) Explanation: Scrum’s iterative approach, where each Sprint allows for experimentation, learning, and adaptation, fosters a culture of innovation. Instead of prioritizing predictability, Scrum teams are encouraged to inspect and adapt based on their learning, promoting innovation over rigid adherence to plans. 4. Principle: Learning Over Failure Scrum principle match: Sprint Retrospective Explanation: The Sprint Retrospective is a key Scrum event focusing on continuous improvement by learning from past Sprints. It provides a space for the team to reflect, fostering a culture of learning from experience rather than dwelling on failure, and aligns well with the principle of prioritizing learning over avoiding failure. Selected Insight "(...) this means moving from hands-on micromanagement to servant-based leadership with active coaching. It means leading with context rather than control." Scrum alignment: Scrum advocates for servant leadership, particularly in the role of the Scrum Master, who supports the team by removing impediments and fostering an environment of self-organization. This approach aligns with the shift from micromanagement to leadership that provides context and support, allowing the team to operate with autonomy and trust. Food for Thought on Transformed and Scrum Let us finish with some thought-provoking questions and points for further reflection to encourage deeper consideration of the topic: 1. Is Scrum Truly Flexible Enough? While Scrum aligns well with the principles in Transformed, some argue that Scrum can become too rigid if not adapted to specific team needs. How can teams maintain the flexibility to innovate while adhering to Scrum’s principles? 2. Balancing Empowerment and Accountability Empowerment is a key principle in both Scrum and Cagan’s approach, but how can teams balance this with the need for accountability? What practices ensure empowerment doesn’t lead to a lack of direction or responsibility? 3. The Role of Leadership in Scrum Scrum emphasizes servant leadership, but how can leaders balance being hands-off and providing the necessary guidance and support? How can leadership adapt as teams mature in their Scrum practices? 4. Is There a Point Where Scrum Becomes Counterproductive? In complex, fast-moving environments, could there be situations where adhering to Scrum might hinder rather than help? How can teams recognize these situations and adjust their approach accordingly? After all, we are not paid to practice Scrum but to solve our customers’ problems within the given constraints while contributing to the organization's sustainability. Evolving Product Culture Scrum’s and Cagan’s principles emphasize the importance of culture. What steps can organizations take to continuously evolve and improve their product culture, ensuring it supports innovation and sustainable delivery? Transformed: Conclusion Marty Cagan’s Transformed provides a compelling vision for product success, with principles that champion empowerment, focus, rapid experimentation, and a product-first culture. However, there’s a growing narrative that Scrum might fall short of supporting these ambitious goals — a perspective often voiced within the product community. But let’s set the record straight: Scrum, when applied thoughtfully, is not just a process or a set of rituals. It’s a framework designed to empower teams, deliver real outcomes, and foster a culture of continuous improvement. The principles outlined by Cagan are not at odds with Scrum; in fact, they can be seen as an evolution of the very principles Scrum has always stood for. Consider this: Scrum’s focus on self-organizing, cross-functional teams directly aligns with empowering teams with problems to solve. The emphasis on delivering potentially shippable Increments matches the drive for outcomes over output. Also, the culture of continuous inspection and adaptation through retrospectives perfectly mirrors the need for learning over failure. Scrum is far from being the bureaucratic beast some critics make it out to be. It’s a dynamic, adaptable framework that, when used with a clear understanding of its purpose, can be the very vehicle that drives the success Cagan’s principles aim for. Yes, Scrum requires a commitment to transparency, collaboration, and relentless pursuit of value. Still, when these elements are in place, Scrum becomes a powerful enabler of the product excellence Cagan envisions. In the end, it's not about Scrum vs. Cagan’s principles from Transformed. It’s about leveraging Scrum as the foundational practice that makes these principles actionable and achievable in the real world. When we stop viewing Scrum as a set of rules and start seeing it as a tool for fostering a culture of self-management, innovation, focus, and continuous delivery, we realize that Scrum is not just helpful—it’s essential for driving the kind of product success Cagan talks about. What is your take on “Transformed” meeting Scrum? Please share with us in the comments.

By Stefan Wolpers CORE

Here is how I became a software engineer without a computer science degree. Let me be real with you: coding was hard. I wasted so much time fixing missing semicolons, mismatched brackets, and misspelled variables. Even when the code was compiled, it would not work as expected, and I would spend hours staring at the screen and questioning my life choices. But over time, I picked up some strategies that made coding click for me, and I'm going to share these strategies with you today. Don’t Try To Know Everything The first thing I learned was that as a programmer, you don't need to know everything. When I began my first programming job, I was unfamiliar with Linux commands. When I joined Amazon, I did not fully understand G. At Amazon, my first project was in Python, and I had never written a single line of code in Python. Later, when I joined Google, I could not program in C++, but most of my work was in C++. The point I'm trying to make is that you don't need to know everything; you just need to know where to find it when you need it. But when I was a beginner, I would try to do these 30-40 hour boot camps to learn a programming language, thinking that I was going to learn everything. In reality, you cannot learn everything there is to learn. So, do not wait until you have the right skills to start your project; your project will teach you the skills. Do not wait until you have the confidence to do what you want; the confidence will come when you start doing it. Focus and Avoid Overwhelm Well, a successful warrior is an average man with laser-like focus. The same is true for a programmer, but it's really hard for a beginner to stay focused. That's because a programmer has more choices than a buffet at an Indian wedding. First, they have to choose a programming language. After that, they need to pick a course to learn that language. If they want to learn front-end development, they have all these choices, and for back-end developers, there is a whole other set of options. The more options available to a person, the longer it takes to decide which option is best. This is also called Hick's Law. As a beginner, it can be tempting to learn a little bit about many different technologies. After all, there are so many exciting areas to explore. While broad exposure is good, it's important for beginners to pick one technology stack to focus on initially. Mastery takes time and repetition, so go deep and not wide. Programming concepts take time to fully click. By focusing on one technology, you can iterate on the fundamentals again and again until they become second nature. Usually, you need to know one technology stack really well to get hired. Breadth is great, but you'll be evaluated on how well you know a specific technology that the job requires. Develop Problem-Solving Skills Next, the lesson was not to just focus on coding ability, but also on developing a problem-solving mindset. You see, coding is ultimately about solving problems, big and small. But the issues we solve as developers don't come prepackaged as coding problems like you see on LeetCode or in coding interviews. They come disguised as open-ended product requirements, refactoring challenges, or performance bottlenecks. Learning to deconstruct these messy real-world issues into solvable chunks is a key skill that you need to build. Example of Problem Solving Let's say there are thousands of users on the internet browsing for a dilution ratio calculator for car detailing products. They are wondering how much water should they add to the car detailing products based on the known ratio of detailing products and water. For this purpose, you can make a dilution ratio calculator in HTML, CSS, JS, or whatever language you prefer. But we recommend Python over HTML, CSS, and JS because you will need to write fewer lines of code. It was just one example: there are hundreds and thousands of problems that need to be solved. Techniques for Better Problem Solving Let me tell you two techniques that helped me become better at problem-solving. The first is the Five Whys analysis. This technique was created at Toyota as a way to identify underlying reasons behind manufacturing defects. Here is how it works: when you encounter a problem, you ask "why" five times, one after the other. Each answer forms the basis of the next "why." For example, let's say your code is running slower than expected. Why is that happening? Because it's taking a long time to process a large data set. But why? Because I'm using two nested loops to search for a specific value. And why is that? Because I thought that nested loops were the easiest way to solve the problem. Why is that? Because I do not know more efficient search algorithms. But why? Because I've not taken the time to study data structures and algorithms. By the time you get to the fifth "why," you have reached the core issue. The second technique I use is the separation of concerns. The main idea behind this is to break a complex problem down into smaller, manageable parts. For example, let's say you are building a web app with user authentication. You can break this problem down into multiple tasks, like building a user interface for login and registration, database management for storing user credentials, and authentication logic for verifying user identity. This makes the problem easier to process without getting overwhelmed. Building strong problem-solving skills will also help you in coding interviews. In coding interviews, they will ask you questions based on data structures and algorithms. These questions are designed to test your logical thinking and problem-solving. Stop Obsessing Over Syntax The next thing you need to do is to stop obsessing over the syntax. As I mentioned at the beginning of this article, I would constantly get frustrated by silly syntax errors. I would spend hours just trying to get my code to run without any errors. But then I realized that obsessing over the syntax is pointless. Syntax is just the grammar of the language; it's important, but not the core of coding. As we discussed, the core is problem-solving — breaking down a complex problem into simple steps that even a computer can understand. That's why I started practicing coding with pseudocode first. Pseudocode lets you mock out your solution in plain English before trying to write proper code syntax. It forces you to truly understand the logic of your solution upfront. Once I had that down, the actual coding became much easier because I just had to translate my logic into whatever language I was using. Here is an example of pseudocode for the fizz fizz game: Pascal style: procedure fizzbuzz; for i := 1 to 100 do print_number := true; if i is divisible by 3 then begin print "Fizz"; print_number := false; end; if i is divisible by 5 then begin print "Buzz"; print_number := false; end; if print_number, print i; print a newline; end C style: fizzbuzz() { for (i = 1; i <= 100; i++) { print_number = true; if (i is divisible by 3) { print "Fizz"; print_number = false; } if (i is divisible by 5) { print "Buzz"; print_number = false; } if (print_number) print i; print a newline; } } Python style: def fizzbuzz(): for i in range(1,101): print_number = true if i is divisible by 3: print "Fizz" print_number = false if i is divisible by 5: print "Buzz" print_number = false if print_number: print i print a newline Write Code for Humans, Not Computers Another thing I wish I had learned early was to write code for humans, not computers. A study done by Chajang University found that developers spend 58% of their time just trying to understand the code they are working with. As beginners, we tend to write code that works in a way that only makes sense to us. But effective code needs to be understandable by any developer who looks at it, including your future self. I cannot tell you how many times I came back to my code from a week ago and could not understand it myself. So, writing clean, readable code with proper variable naming, code formatting, and comments can massively boost your productivity as a developer. It's a skill I worked very hard to build by studying coding best practices and getting code reviews. Trust me when I say this: your future self will thank you for writing readable code. Master Debugging Techniques In talking about understanding code, the next thing that made my life easier was learning debugging. I can't tell you how many hours I wasted just randomly tweaking code, compiling, running, and tweaking again in the hopes that it would magically work. I thought that was the only way to do it. But then I read this article by Devon H. O'Dell that talked about how developers spent somewhere between 35% to 50% of their time debugging. That's over a third of their time. So, I decided to get serious about learning debugging. I learned how to use a debugger, adding log statements systematically, and recreating issues in smaller isolated cases. Learning and applying a proper debugging process saved me a lot of time and headaches. Most code editors have built-in debugging functionality. In certain cases, you can also use a third-party extension like ReSharper. To learn more about debugging, check out Google's troubleshooting and debugging techniques course on Coursera. Enroll for free! Focus on the Little Things And this brings me to the most important lesson. Back in the 1980s, American Airlines was looking for ways to cut costs and improve its profit margin. Bob Crandall, who was the head of American Airlines at the time, decided to take a closer look at the airline's food service. He noticed that the salads being served on the flight included a garnish of three olives per salad. Bob did some quick math and figured out that if they removed just one olive from each salad, they could save a substantial amount of money. Keep in mind that American Airlines was serving thousands of meals every day, so even though one olive might not seem like much, the numbers added up fast. American Airlines saved around $40,000 per year in today's dollars by doing this (Ref). The lesson here is that sometimes the biggest improvements come from paying attention to the little things. Incremental Improvements In his book Atomic Habits, James Clear talks about the power of making small, incremental changes in life (ref). The idea is that tiny habits, when compounded over time, can lead to remarkable results. He shows that just a 1% improvement every day over one year can make you 38 times better. The key to making these improvements is starting small. So, if you want to get in shape, start by doing one push-up per day. If you want to read more, start by reading just one page every night. And if you want to learn programming, start by doing just two exercises per day. Over time, these small improvements will compound. Two exercises will become 20, and 20 exercises will become one project, and so on. Whatever you do, you cannot have anything worth having without struggle. And if you're struggling to learn programming, you are on the right track.

During my 10+ years of experience in Agile product development, I have seen the difficulties of meeting the rapid requirements of the digital market. Manual procedures can slow down highly flexible software engineering and delivery teams, resulting in missed chances and postponed launches. With AI and Large Language Models (LLMs) becoming more prevalent, we are on the verge of a major change. Gartner points out a 25% increase in project success rates for those using predictive analytics (Gartner, 2021). These technologies are changing the way agile product development is optimized - by automating tasks, improving decision-making, and forecasting future trends. As stated in a report from McKinsey, companies using AI experience a 20% decrease in project costs (McKinsey & Company, 2023). In this article, I discuss how agile product development including any experiences and user journeys can be improved based on AI and LLM integrations across the development lifecycle. Also Read: "The Foundation of AI and Analytics Success: Why Architecture Matters" AI and LLM Integration Phases for Agile Product Development Automating User Story Generation Creating user stories is crucial for Agile development, although it can be time-consuming. LLMs, for example, such as GPT-4 from OpenAI are able to streamline the process by creating comprehensive user stories using available documentation and feedback. This speeds up the process while also enhancing precision and significance. Application Scenario For example, I focus on utilizing AI or LLM-based methods for streamlining, optimizing, and automating the creation of user stories. Integrating such methods with a comprehensive backlog has allowed me to improve product development lifecycles and any engineering prioritization. This significantly reduces user story creation time, which is also helpful for solutions architects and increases user satisfaction where there is more relevant and accurate feature development. Significance and Advantages The automation of generating user stories is essential as it reduces the monotonous job of creating stories by hand, enabling product managers and software engineers to concentrate on more strategic tasks. This process guarantees that user stories are created uniformly and in line with user requirements, resulting in improved prioritization and quicker development cycles. Assisting agile teams in sustaining their progress and releasing features that better align with user needs. Additionally, organizations that adopt AI for generating user stories usually see a 50% reduction in story creation time (Menzies & Zimmermann, 2022). Also Read: "User Story Reflections" Optimizing Backlog Prioritization Key to swift value delivery is effective prioritization of the backlog. AI algorithms analyze user feedback, market trends, and technical dependencies to forecast the most valuable features. This approach driven by data assists product managers in making well-informed choices. Application Scenario For example, during the development of a digital healthcare consumer platform, I utilized AI tools to review user feedback and determine which backlog items to focus on first. This was mapped across different prioritization techniques as well as how engineering would execute them based on complexity. As a result, there was a 40% rise in feature utilization and a 20% decrease in feature development duration, which also helped the software engineering team improve their metrics. Significance and Advantages It is crucial to prioritize backlog optimization in order to make informed decisions that improve the value of the product and customer satisfaction. Utilizing AI for prioritization aids agile teams in determining which features will yield the greatest benefit, enabling them to utilize resources effectively and concentrate on tasks with significant impact. Companies that have implemented AI for prioritizing their backlog have seen a 40% growth in feature adoption (Buch & Pokiya, 2020). Leveraging Predictive Analytics Predictive analytics offers insight to help shape development tactics. AI models can predict risks and estimate delivery times by examining historical data, helping teams address issues and align development efforts with market changes. Further, this can help agile product development teams assess how to staff across sprints and ensure workforce optimization to improve feature velocity. Application Scenario For example, I use predictive analytics in collaboration with engineering development and delivery teams to predict how new features would affect Sprint planning, Sprint allocation, and user engagement. The information assisted in determining which updates were most important as well as need execution in upcoming sprints and has allowed me to optimize MVPs, resulting in a ~25% rise in user retention and a ~15% increase in new user acquisition across two different products. Significance and Advantages Predictive analytics offer practical insights that steer strategic choices in flexible product development. Teams can prioritize new features that will have the greatest impact on user engagement and retention by predicting their effects. Businesses that use predictive analytics have observed a 25% rise in customer retention (Forrester, 2019). Improving Product Experiences and User Journeys AI and LLMs improve user journeys and product experiences through a more user-focused approach to development. Automated creation of user stories guarantees that features are developed according to genuine user requirements, resulting in products that are more instinctive and captivating. This alignment improves user satisfaction and involvement by customizing features to meet specific needs and desires. Use Case For example, I used LLMs to analyze user feedback and create features that directly addressed user pain points. This resulted in streamlining and optimizing how different product features are lined up along with tech debt for engineering execution. I have seen a ~35% increase in user engagement significant reduction in user churn rates. Significance and Advantages Improving product experiences and user journeys with AI and LLMs ensures a user-focused approach in product development, resulting in more user-friendly and personalized experiences. Aligning with user needs not only boosts satisfaction but also enhances engagement and retention. After incorporating AI-driven improvements, companies have experienced a 35% rise in user engagement (Ransbotham, Kiron, Gerbert, & Reeves, 2018). Supporting Agile Product Development and Product Management Incorporating AI and LLMs into agile product development changes how teams tackle and carry out projects, providing numerous advantages. To begin with, these technologies simplify the process of developing user stories, cutting down on manual work and allowing more time for strategic duties. This results in enhanced precision and significance in feature advancement. Also, by using AI to prioritize the backlog, teams can concentrate on important tasks, leading to better use of resources and increased overall productivity. Predictive analytics enhances value by predicting feature performance, allowing teams to make educated decisions that increase user retention and engagement. From my own experience, I've noticed that these advancements not only speed up the process of development but also make products better suited to user requirements, resulting in a more agile and adaptable development setting. The integration of AI in agile product development leads to improved product management, faster iterations, and enhanced user experience. For example, the global AI-assisted custom application development market is expected to grow up to $61Bn and from 21% to 28% by 2024 (Deloitte Insights, 2020). As a product manager working across multiple software engineering teams, AI and LLMs have helped me simplify decision-making by automating routine tasks and providing actionable insights. Automated user story generation and backlog prioritization free up time to focus on strategic aspects, while predictive analytics offers data-driven forecasts and trend analysis. This results in a more agile and responsive product management process, where decisions are guided by comprehensive data and real-time insights, ultimately leading to more successful product outcomes and better market alignment. Benefits of AI and LLMs for Agile Product Development Conclusion and Next Steps The incorporation of AI and LLMs in agile product development seems like a dynamic revolution. In my opinion, these tools have revolutionized the way tasks are done by automating them, streamlining processes, and forecasting trends accurately. They have made workflows more efficient and enhanced product experiences, resulting in more agile and responsive development cycles. As we further accept and improve these technologies, I look forward to witnessing how their developing abilities will continue to change our strategy for creating and providing outstanding products. The process of incorporating AI and LLMs into agile product development methods is indeed exciting and filled with potential. Key Takeaways Start using AI and LLM tools to automate and improve the generation of user stories and prioritize backlogs in your development processes. Utilize predictive analytics: Employ predictive analytics to gain insight into potential project risks and market trends, enabling proactive modifications. Prioritize user-centric development: Utilize AI-generated insights to enhance product experiences for better user satisfaction and retention.

When teams get their variance right, everything else falls into place. Variance is a measure of whether teams are doing what they say they are going to do. A team with high variance is over-committing or under-delivering. A team with low variance is delivering on its plans. In this case, stakeholders can feel confident in the team, the team can celebrate at the end of each sprint, and longer-term planning is likely to be accurate. In this article, we will look at what variance is, how it is calculated, and, most importantly, what Scrum Masters, coaches, and team members can do to get it right. What Is Variance? Variance is the difference between story points Committed and story points Done. A rule of thumb is to aim at a variance of no more than 20%. Points committed are calculated on starting the sprint. The points on all work items in the sprint are summed. Points done are calculated when the sprint ends. All points, attached to items that have been done, are summed. The two counts can then be displayed on a velocity chart (see below): Typically, Scrum Masters will do an at-a-glance analysis of variance. If the two bars are close together, all is good. If Committed is, say, double the Done, then some action is required. So in the example above, we can see that variance looks too high in the first three sprints, but much better in the following three. See the Appendix for how to calculate variance. Why Is Variance So Important? Variance is so important for Agile teams. Here is why: 1. Barometer of Team Health If a team has low variance — i.e., it is doing what it is committing to do — it is an indicator that many other things are going well. For example: Backlog refinement and estimation: A low variance suggests the team is effectively managing the backlog and doing accurate estimation. Sprint planning: If the team has low variance, they are doing what they are committing to do. So during sprint planning, they must be taking in a manageable amount of work into the upcoming sprint. They must be managing their capacity. Definition of Ready (DoR): Low variance suggests that the team has a solid definition of DoR and is applying it to all items put into a sprint (more on DoR below). Conversely, high variance suggests there are issues with some of the above. 2. Impact on Other Metrics Burndowns If a sprint has low variance, it means the team has done what it planned to do. Of course, it won’t determine the shape of the burndown line, but it does mean the line should end up close to zero. Cycle Times I am thinking here about the average time a work item takes to get done; i.e., from the time it gets put into a sprint to the time it is put into a done state. If variance is low, it means that all or most of the work items in a sprint are getting done by the end of it. So, cycle times will be around the same as the duration of the sprint. This is normally the target for cycle times. 3. Longer Term Planning Increasingly across the industry, organizations are making efforts to align the work of the scrum teams to longer-term plans. This can be done in a variety of ways: Product goals: To align the goals to long-term plans, they can be set to be time-bound and specific. PI planning: Organizations doing some form of scaled agile are often using the idea of PI (Product Increment) Planning. This is where the team and stakeholders (who are working on the same product) meet periodically (typically quarterly) to align to a shared vision, plan deliverables, identify risks and dependencies, etc. Roadmaps: Some organizations are aligning scrum teams to roadmaps. While this may feel a bit non-agile, I would argue that as long as these roadmaps are based on empirical data, coming from the squads, it is most likely beneficial for the organization. No matter what form of long-term planning is being used, teams with low variance will be able to accurately plan for the future. Four Ways to Improve Variance 1. Definition of Ready (DoR) When a team has high variance, they are typically taking items into the sprint that are not ready. In this short video by Jeff Sutherland, he walks us through some of the key aspects of DoR. They include: Immediately actionable: The team should be able to start work on this item on Day 1 of the sprint. If they are waiting on some input from a stakeholder or a deliverable from another team, it is not ready and does not belong in a sprint. Doable in one sprint: If it is too big to get Done in one sprint, it is not ready and should be broken down into smaller items. Understood: Discussions with the PO and the stakeholder should have already happened. The team should know exactly what needs to get done to deliver the item. Otherwise, it is not ready. When teams take in items that are not ready they are likely to get blocked, delayed, and put on hold. Variance will be impacted. The best practice is to rigorously check all work items against DoR during sprint planning. 2. Push Back on Pressure From Stakeholders As deadlines loom and pressure builds, Agile teams are sometimes pressured into taking on too much work in a sprint. They will often justify their actions with heroic phrases: “We will pull out all the stops," “We will go the extra mile," etc. Sadly, it doesn’t often happen. The team cannot deliver on an unrealistic workload and has to admit to stakeholders that they are not going to get what was promised – an uncomfortable situation for all concerned. There are many concerns about over-committing: Stability In Agile, we are aiming for stability. One of the principles of the Agile Manifesto states: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." The False Promise of Longer Working Hours There have been numerous studies that have suggested an increase in working hours actually reduces productivity. Encouraging people to spend long hours working actually decreases the work they get done. The Downward Spiral Typically, working long hours sets up a downward spiral: work/life balance is impacted, physical and mental health are impacted, people get demotivated and frustrated with their work, productivity goes down, quality goes down and people start looking for other jobs. High staff turnover always has a major negative impact on productivity. One solution lies in the fundamentals of Agile. One of the pillars of scrum is transparency. Teams must make their work visible. They must be open and honest about what they can do, and also what they can’t do. One of the scrum values is courage. It takes some courage to say to managers: “I am sorry, but we don’t have the capacity to complete these items this sprint." But it is far better than committing to doing something and then failing to deliver on it. 3. Avoid Overly Optimistic Estimation There is a tendency for team members to be overly optimistic when estimating and deciding how much they can get done in a sprint. There are several root causes: Happy Day Scenario: They are only considering the Happy Day Scenario. They assume that everything will go according to plan and they will not face any issues with the work. Entirety of work item: They are not considering the entirety of the work item. Most work items consist of doing – reviewing/testing – re-working – re-reviewing/acceptance. There is a tendency to only consider the doing bit. Historical data: They are not considering historical data and looking at how long it took to do similar items in previous sprints. Scrum Masters have a role to play here. They can coach the team on estimation, helping them to take a holistic approach and consider the overall sizing of the item, not just the doing bit. They can bring in historical data to inspect how long similar items have taken to do in the past. 4. Do Capacity Planning It is dangerous to assume that all team members will be working on all the days of the sprint. In distributed teams, there may be public holidays in various locations, and team members may be taking personal time off. It is important to track this data as it will impact the capacity of the team in the upcoming sprint. This was a mistake I made when I first became a Scrum Master. We would meticulously do our sprint planning basing the committed story points on the velocity of previous sprints. Then midway through the sprint, I would realize that several team members had gone on vacation and forgotten to tell me or there were public holidays in other countries that I didn’t know about. I very quickly implemented a team calendar (I used the one in Confluence, but there are many tools that will do the job). I regularly reminded the team members to put in personal leave and any public holidays in their country or region. During sprint planning, one of the first activities was to review the calendar and determine the capacity of the upcoming sprint. Conclusions We have seen that a team with low variance is most likely a high-performing team who delivers on their plans. And we have looked at several techniques teams can use to reduce their variance. As variance decreases, stakeholders gain confidence in the team; they know they are likely to get what has been planned. Best of all, at the end of each sprint, the team can celebrate delivering what they set out to deliver. Appendix: Variance Calculation Variance can be calculated using the following formula: Variance = (Committed – Done) x 100/Committed In the above example in Sprint 1: Committed = 56 Done = 20 Variance = (56 – 20) x 100/56 = 64% As mentioned above, a good rule of thumb is to aim to keep variance below 20%.

Tech teams have a hard job. They deal with tight deadlines and tough problems. This can cause stress and self-criticism. But being kind to yourself can help. Self-compassion makes you feel better. It also helps the team work better together. This guide will explain what self-compassion is. It will also show why it’s good for tech teams and how to use it at work. Self-Compassion for Tech Teams Self-compassion is like being your own supportive friend. When things go wrong or you make mistakes, instead of being hard on yourself, treat yourself kindly. For tech teams, this means understanding hard tasks and handling mistakes gently. It helps you stay calm and focused. Dr. Kristin Neff talks about three parts of self-compassion: 1. Self-Kindness When you or someone else makes a mistake, be kind. Instead of getting mad, take a deep breath. Remember, everyone makes mistakes. It's how we learn and grow. Tell your team to do the same. 2. Common Humanity Know that everyone in tech has problems and feels bad sometimes. You are not alone. When you make a mistake, remember others have too. Talk about these feelings with your team. It helps to know others understand. 3. Mindfulness Notice bad thoughts and feelings without judging them. This helps you grow. If you feel upset, take a moment to notice it. Don’t ignore these feelings. Think about why you feel this way and what you can learn from it. This helps you move forward. Why Is Self-Compassion Good for Tech Teams? Being kind to yourself in tech teams can help in many ways. It helps team members feel better about themselves and their work. It makes the workplace more positive and supportive. People are kinder to themselves and each other. This leads to less stress and more creativity. Everyone works better together and feels happier. Let's take a look at the below points which we should adopt to cultivate the team culture: Better emotional strength: Team members who are kind to themselves bounce back faster from setbacks. They adapt better and stay motivated. They don't get stuck in negative thoughts. Improved problem-solving: A kind culture makes people feel safe. They can take risks and try new ideas without fear. This leads to more innovation and creativity. Stronger teamwork: Being kind to yourself helps you understand others better. This leads to better working relationships and teamwork. People are more willing to help each other. Less burnout: Self-compassion reduces stress and self-criticism. This leads to a healthier work-life balance and more job satisfaction. People are happier and more productive. Better leaders: Leaders who are kind to themselves manage their teams better. They create a supportive environment. They help their team grow. They inspire their team to be kind too. More confidence: When you are kind to yourself, you feel more confident. You believe in yourself. You take on challenges with a positive attitude. Lower anxiety: Being kind to yourself helps reduce anxiety. You feel calmer and more relaxed. You worry less about mistakes. Better decision-making: Kindness to yourself helps you make better decisions. You think clearly. You choose the best options without fear of making mistakes. Increased motivation: Self-compassion keeps you motivated. You stay focused on your goals. You work steadily towards them. Healthier relationships: Being kind to yourself helps you build better relationships. You communicate well. You resolve conflicts peacefully. How To Help Your Tech Team Be Kinder: A Multi-Level Approach Creating kindness in tech teams takes effort from everyone. Here are some easy ways to do it at different levels: For Yourself Mindfulness: Do simple exercises like meditation or deep breathing every day. This helps you notice your thoughts and feelings. Change negative self-talk: When you think bad things about yourself, try to change them to kind words. Be gentle with yourself. Seek support: If you have problems, talk to mentors, friends, or therapists. They can listen and help you. Sharing your troubles makes you feel better. You are not alone. They might have good advice or just a kind word. Don't be afraid to ask for help. Take breaks: Make sure to take short breaks during work. This helps you relax and recharge. Celebrate small wins: Notice and celebrate your little successes. It makes you feel good and confident. Even small achievements matter. Give yourself a pat on the back. For Your Team Lead by example: Managers should show kindness. Admit mistakes and support team members. Encourage reflection: Give your team time to think about their challenges and what they can learn from them. Focus on learning, not blaming. Open communication: Create a safe space for team members to share their struggles and concerns. This helps everyone feel understood and supported. Team activities: Organize fun activities to strengthen the bond among team members. It improves teamwork. Give positive feedback: Regularly give positive feedback to your team. It motivates and encourages them. For Your Company Culture of care: Make your workplace a place where people care about each other. This makes everyone feel like they belong. Provide training: Offer workshops or online resources about self-kindness. This helps everyone learn how to be kinder. Promote work-life balance: Set up rules that help balance work and personal life. Think about flexible hours, remote work, and mental health support. Recognize efforts: Say thank you and appreciate the hard work of employees. A simple thank you can mean a lot. Mental health resources: Give access to counseling or stress workshops. This helps people feel better emotionally. Real-Life Examples of Self-Compassion in Tech Teams Here are some real-life examples of how tech companies use self-compassion: Mindfulness Programs Big companies like Google and Apple offer meditation and mindfulness sessions. These help workers be kind to themselves and stay strong emotionally. They feel better and work better. Now, many smaller companies are starting these programs too. "Fail Fast" Mentality Many tech companies tell their teams it's okay to fail quickly and learn from it. This helps everyone see mistakes as chances to grow. It makes people less afraid of messing up. Other companies are adopting this idea as well. Mental Health Support Lots of tech companies offer mental health support. They provide counseling services and allow mental health days. This helps employees take care of their emotional well-being. More small and medium companies are now offering similar support. Peer Recognition Some companies have programs where employees can praise each other. They celebrate each other's successes. This helps everyone feel appreciated and boosts confidence. Smaller companies are also using these programs. Flexible Work Hours Some tech companies let employees choose their work hours. This helps them balance work and personal life better. Many smaller companies are starting to do this too. Remote Work Options Big tech companies often allow remote work. This gives employees flexibility and reduces stress. Smaller companies are also offering remote work options now. Team-Building Activities Many tech companies organize fun activities for their teams. This builds stronger bonds and improves teamwork. Smaller companies are doing this as well. Learning Opportunities Tech giants offer workshops and courses on self-compassion and mindfulness. These help employees learn how to be kinder to themselves. Smaller companies are starting to provide these learning opportunities too. How To Handle Problems With Being Kind to Yourself in Tech Teams Before we finish, let's look at some common problems tech teams face when trying to be more self-compassionate. By knowing these issues, teams can better add self-compassion to their work culture. Perfectionism: People think they must be perfect. This stops growth. See mistakes as chances to learn. Focus on getting better, not being perfect. Fear of laziness: Some think being kind to themselves will make them lazy. But self-compassion helps you stay motivated and productive. It helps you do better. No time: Tech teams are busy. It's hard to find time for self-compassion. Do short exercises like deep breathing. Add self-compassion talks in meetings. Hard to share feelings: Talking about struggles is tough. Leaders should show it's okay to share. These builds trust and support. Don't know about it: Some people don't know what self-compassion is. Explain it simply. Show how it helps. Cultural norms: In some places, showing feelings is seen as weak. Encourage sharing. Leaders can set the example. Fear of judgment: People might fear being judged. Create a safe space where everyone feels accepted. Pressure to perform: High expectations make it hard to be kind to oneself. Remind the team to take breaks and ask for help. No support from leaders: Without leaders' support, it's tough to practice self-compassion. Leaders should promote and support these practices. Misunderstanding: Some think self-compassion means feeling sorry for yourself. Explain that it means being kind and understanding, not self-pity. Conclusion In tech teams, being kind to yourself helps everyone do better. Kindness and patience reduce stress, spark new ideas, and improve teamwork. Using self-compassion for yourself, your team, and your company makes the tech world healthier and more supportive. This means more success for everyone. When people feel good, they work better. They help each other more. They come up with great ideas. So, let’s all be kinder to ourselves and each other. It makes a big difference. Happy learning!!

By Arun Pandey CORE

Architecture is often celebrated as a fine art, particularly when a building's aesthetic features stand out. Yet, a beautiful design alone does not guarantee functionality. Architectural design requires a blend of technical precision and artistic vision. The form of a building should directly serve its intended function, illustrating the principle that form should follow function. For example, the Royal Ontario Museum in Toronto, despite its striking appearance, has been criticized as one of the 'worst examples of architecture during the 2000s' due to its impractical interior spaces characterized by awkward corners and slanted walls that compromise usability. Similarly, in software development, while users may admire a well-designed interface, they often overlook the backend architecture that equally influences their experience. Software architects face myriad design decisions that affect an application's performance, scalability, and future adaptability. Their challenge isn't just to create something elegant but to design systems that are both effective and maintainable. This article highlights the often 'invisible' artistry of backend software engineers, acknowledging that creating performant, scalable, and maintainable software architectures is an art form in its own right. We Don’t Look at Software as a Creative Art Software development is often perceived more as a functional craft than a creative art, likely because of its roots in engineering. This background has historically aligned software development more with manufacturing principles — predictable, efficient, and repeatable processes — rather than the nuances of creative design. During the rapid expansion of computer usage in the 1960s and 1970s, businesses and governments needed reliable software quickly, leading to methodologies that mirrored factory assembly lines. This approach emphasized division of labor, where individual programmers focused on specific tasks, thereby limiting the scope for creativity in favor of functionality and bug-free code. However, this view neglects the inherent creativity and dynamism in software engineering. Consider the differences between manufacturing cars and developing software. In car manufacturing, processes are standardized with fixed objectives and requirements, focusing solely on output. You don’t see new requirements introduced mid-assembly line, new machinery being swapped in for the old during production, or users testing very early versions of the car directly on the factory floor. In contrast, software development is dynamic, with requirements, tools, and even end goals shifting significantly during the project lifecycle. What starts as a car might evolve into a pirate ship due to changing business needs, technological advancements, or user feedback. Creativity is essential in software development, influencing all aspects from user interface design to system architecture and complex problem-solving. Recent recognition of the creative aspects in fields like game development, web design, and user experience has begun to balance the narrative, showcasing that artistic design is as crucial as technical proficiency in developing software. We May Recognize a Beautiful UI Design, but What About a Great API Design? A design-oriented approach, which is prevalent in software development, centers around a user-centric problem-solving process. This methodology encourages developers to empathize with users, define problems, ideate solutions, prototype, and test, all of which require creativity. While the influence of this approach is readily apparent in user interfaces (UIs) due to their direct interaction with users and visible aesthetic elements, its application extends beyond the front end to other crucial elements like system architecture and API design. For example, APIs (Application Programming Interfaces) play a transformative role in enhancing internet user experiences by streamlining access to services and simplifying complex tasks. A well-crafted API enables seamless interactions between different systems, facilitating a more integrated and smooth user experience across various applications and services. Here are a couple of examples: Stripe API: Revolutionizing online payments, Stripe provides developers with a flexible, customizable, and straightforward API. It allows even small startups to implement sophisticated payment systems that are both robust and secure, significantly improving the e-commerce experience. OpenAI's GPT API: As one of the most popular APIs in recent years, it offers advanced natural language processing capabilities. Developers can integrate features such as chatbots, automated content generation, and more into their applications. This not only enhances user interactions but also creates more intuitive and human-like experiences in customer service and interactive applications. Post on Threads How Backend Design Decisions Shape the User Experience Backend design decisions critically shape the user experience, directly influencing the application loading time, how fast you can search the data, how seamless the user experience is in any given location, etc. In summary, these choices affect everything from the application's responsiveness to its stability across different environments. Key areas impacted by backend decisions include: Tech stack selection: The choice of technology—programming languages, databases, and server architecture—affects how quickly and efficiently data is processed and delivered to the user. Architectural style and patterns: Opting for specific architectural styles (e.g, microservices or serverless) impacts scalability and the ability to update features without disrupting user interactions. Third-party integrations: The integration of legacy systems and third-party services can enhance functionality but requires careful handling to maintain performance and ensure data consistency. Data structure design: How data is organized and managed (especially in distributed systems) directly impacts how quickly data can be accessed and manipulated, affecting everything from search functionality to transaction processing. These backend choices are often invisible to the end-user until an issue arises, and then they become glaringly apparent. Things like slow load times, downtime, or data inconsistency highlight how important robust system design is to ensure continuous user satisfaction. How Backend Design Decisions Shape the Org Backend design decisions extend beyond user interaction, fundamentally shaping an organization's ability to scale its product, grow its user base, and be innovative. The system design of software is not only a cornerstone for technical robustness but also crucial for economic sustainability over time. When designed poorly, systems accumulate architectural technical debt, which is often costlier and more complex to resolve than code-level technical debt, and can lead to severe operational disruptions. Indeed, the major outages experienced by industry giants like AT&T, Meta, and AWS over the past 18 months illustrate the dire consequences of unchecked system complexity. Furthermore, backend flexibility plays a vital role in an organization's agility—its capacity to swiftly adapt to market changes and seize new opportunities. A great example of this is the explosive user growth experienced by the Cara app, a platform built by volunteers to allow artists to share their portfolios. Cara's backend, designed with serverless architecture, scaled remarkably to support a jump from 40,000 to 650,000 users in just one week. While this rapid scalability enabled Cara to capitalize on a market opportunity, it also led to a substantial, unexpected cost— a $98,000 Vercel bill after a few days of peak usage. This underscores that each architectural decision carries its own set of trade-offs and necessitates a delicate balance between addressing immediate needs and anticipating future demands. It highlights the creative challenge of aligning current requirements with potential future scenarios in a dynamic market landscape. Conclusion: The Unseen Artistry of Backend Engineers In software development, the artistry behind backend architecture is often invisible yet immensely impactful. As we continue to demystify the backend, it becomes clear that these engineers are not just coders; they are the modern-day architects of the digital world, crafting foundational structures that empower businesses and enhance user experiences. Embracing this perspective can transform how organizations value and execute their software initiatives, ensuring that both the visible and hidden elements of our digital solutions are crafted with artistry and foresight.