Agile | Techlist.io

lineApr 24, 20264 min readCurated summary

ODW #4: From Copilot to Pilot, Automating from Implementation to PR with Agentic Coding

LY Corporation’s Orchestration Development Workshop promotes a shift from using AI as a code suggestion tool to using it as an autonomous development “pilot.” The team combined specification-driven development with Jira/Confluence access through MCP so AI agents could investigate requirements, plan implementations, write code, run checks, create pull requests, and respond to reviews. The approach improved development speed and planning, but still requires humans to review AI-generated code and retain responsibility for product quality. ## From Copilot to Agentic Coding - The team initially used GitHub Copilot for small code-generation tasks but saw limited productivity gains. - Two developments enabled a broader shift: - Existing requirements and design documents supported specification-driven development. - Jira and Confluence became accessible to AI coding tools through the Model Context Protocol (MCP). - Agentic coding gives an AI agent a high-level goal, which it decomposes into tasks and executes iteratively. - Unlike autocomplete tools, an agent can analyze the broader codebase, run commands and tests, fix lint errors, and continue until the requested feature is complete. ## Workshop Goals and Human–AI Responsibilities - The workshop focused on automating the process from implementation through pull-request creation. - Humans remained responsible for: - Defining requirements and writing specifications - Final testing, review, and release decisions - AI was assigned: - Implementation planning - Code implementation - Pull-request creation - Initial review and review-response work - This division preserved the existing development process while giving participants practical experience with agentic workflows. ## Stage 1: Research and Implementation Planning - Participants supplied a Jira ticket URL to a custom slash command. - The AI agent: - Retrieved Jira data through the Jira MCP tool - Followed Epic links and collected related tickets - Retrieved Confluence documentation through the Confluence MCP tool - Explored the codebase, using an Explore Agent where available - Wrote a detailed implementation plan to `specs/{ticket-or-topic}/plan.md` - The plan included requirements, affected components, technical analysis, implementation tasks, risks, testing considerations, and a checklist. - Saving the plan to a file made it available for human review, future sessions, and later PR generation. - The team emphasized planning early because vague instructions can lead to incorrect implementations and costly rework. ## Stage 2: Implementation and Pull-Request Creation - The reviewed plan was passed to an implementation command. - The AI was instructed to: - Understand the plan and implementation scope - Modify the code - Add or update tests - Run the test suite - Run linting and build commands - Fix any resulting problems - Explicitly listing these steps encouraged the coding agent to maintain a task checklist and complete the full development cycle. - A separate PR command generated the pull request using the team’s template. - Information gathered during the planning stage could be reused in the PR description, reducing administrative work. ## Stage 3: AI Review and Issue Resolution - An AI screening-review command analyzed the generated PR. - It also read existing comments, including: - The AI’s own prior review comments - Comments from other team members - The agent identified issues requiring changes and explained its assessment of existing comments. - After a human reviewed those conclusions, the AI could implement the necessary fixes, reducing the cost of responding to review feedback. ## Benefits and Risks - **Higher code-generation speed** - Agents can work with less frequent human intervention. - Developers can perform other tasks while agents work. - Multiple agents can potentially run in parallel. - **Earlier risk discovery** - Detailed implementation plans clarify the work before coding begins. - Planning can reveal overlooked tasks, dependencies, and risks. - **Greater review burden** - AI can generate large volumes of code that humans must still inspect. - The unfamiliar workflow may create stress for developers. - **Human accountability remains essential** - Developers are responsible for the quality of AI-generated code. - Poor-quality output increases reviewer workload and can add technical debt. ## Workshop Results - The workshop was delivered twice: - A hands-on practical session requiring prior preparation - An introductory session with more detailed support - Approximately 2,500 people participated. - More than 40% of respondents had already applied, or intended to apply, some aspect of the workshop. - The sessions provided concrete guidance on MCP server usage and effective ways to delegate coding tasks to AI agents. The recommended approach is to introduce agentic coding incrementally: keep human ownership of requirements and final quality decisions, while allowing AI to handle structured planning, implementation, testing, PR creation, and initial review.

Read original

Agile AI Model Context Protocol Github Copilot+4

woowahanDec 5, 2025Original article

아한형제들 기술블로그 (opens in new tab)

The 7th Woowacourse crew has successfully launched three distinct services, demonstrating that modern software engineering requires a synergy of technical mastery and "soft skills" like product planning and team communication. By owning the entire lifecycle from ideation to deployment, these developers moved beyond mere coding to solve real-world problems through agile iterations, user feedback, and robust infrastructure management. The program’s focus on the full stack of development—including monitoring, 2-week sprints, and collaborative design—highlights a shift toward producing well-rounded engineers capable of navigating professional environments. ### The Woowacourse Full-Cycle Philosophy * The 10-month curriculum emphasizes soft skills, including speaking and writing, alongside traditional technical tracks like Web Backend, Frontend, and Mobile Android. * During Level 3 and 4, crews transition from fundamental programming to managing team projects where they must handle everything from initial architecture to UI/UX design. * The process mimics real-world industry standards by implementing 2-week development sprints, establishing monitoring environments, and managing automated deployment pipelines. * The core goal is to shift the developer's mindset from simply writing code to understanding why certain features are planned and how architecture choices impact the final user value. ### Pickeat: Collaborative Dining Decisions * This service addresses "decision fatigue" during group meals by providing a collaborative platform to filter restaurants based on dietary constraints and preferences. * Technical challenges included frequent domain restructuring and UI overhauls as the team pivoted based on real-world user feedback during demo days. * The platform utilizes location data for automatic restaurant lookups and supports real-time voting mechanisms to ensure democratic and efficient group decisions. * Development focused on aligning team judgment standards and iterating quickly to validate product-market fit rather than adhering strictly to initial specifications. ### Bottari: Real-Time Synchronized Checklists * Bottari is a checklist service designed for situations like traveling or moving, focusing on "becoming a companion for the user’s memory." * The service features template-based list generation and a "Team Bottari" function that allows multiple users to collaborate on a single list with real-time synchronization. * A major technical focus was placed on the user experience flow, specifically optimizing notification timing and sync states to provide "peace of mind" for users. * The project demonstrates the principle that technology serves as a tool for solving psychological pain points, such as the anxiety of forgetting essential items. ### Coffee Shout: Real-Time Betting and Mini-Games * Designed to gamify office culture, this service replaces simple "rock-paper-scissors" with interactive mini-games and weighted roulette for coffee bets. * The technical stack involved challenging implementations of WebSockets and distributed environments to handle the concurrency required for real-time gaming. * The team focused on algorithm balancing for the weighted roulette system to ensure fairness and excitement during the betting process. * Refinement of the service was driven by direct feedback from other Woowacourse crews, emphasizing the importance of community testing in the development lifecycle. These projects underscore that the transition from a student to a professional developer is defined by the ability to manage shifting requirements and technical complexity while maintaining a focus on the end-user's experience.

Agile Android Distributed Systems Monitoring+4

kakaoDec 3, 2025Original article

What the AI TOP 1 (opens in new tab)

The Kakao AI Native Strategy team successfully developed a complex competition system for the "AI TOP 100" event in just two weeks by replacing traditional waterfall methodologies with an AI-centric approach. By utilizing tools like Cursor and Claude Code, the team shifted the developer’s role from manual coding to high-level orchestration and validation. This experiment demonstrates that AI does not replace developers but rather redefines the "standard" of productivity, moving the focus from execution speed to strategic decision-making. ### Rapid Prototyping as the New Specification * The team eliminated traditional, lengthy planning documents and functional specifications. * Every team member was tasked with creating a working prototype using AI based on their own interpretation of the project goals. * One developer produced six different versions of the system independently, allowing the team to "see" ideas rather than read about them. * Final requirements were established by reviewing and merging the best features of these functional prototypes, significantly reducing communication overhead. ### AI-Native Development and 99% Delegation * The majority of the codebase (over 99%) was generated by AI tools like Claude Code and Cursor, with developers focusing on intent and review. * One developer recorded an extreme usage of 200 million tokens in a single day to accelerate system completion. * The high productivity of AI allowed a single frontend developer to manage the entire UI for both the preliminary and main rounds, a task that typically requires a much larger team. * The development flow moved away from linear "think-code-test" patterns to a "dialogue-based" implementation where ideas were instantly turned into code. ### PoC-Driven Development (PDD) * The team adopted a "Proof of Concept (PoC) Driven Development" model to handle high uncertainty and tight deadlines. * Abstract concepts were immediately fed into AI to generate functional PoC code and architectural drafts. * The human role shifted from "writing from scratch" to "judging and selecting" the most viable outputs generated by the AI. * This approach allowed the team to bypass resource limitations by prioritizing speed and functional verification over perfectionist documentation. ### Human Governance and the Role of Experience * Internal conflicts occasionally arose when different AI models suggested equally "logical" but conflicting architectural solutions. * Senior developers played a critical role in breaking these deadlocks by applying real-world experience regarding long-term maintainability and system constraints. * While AI provided the "engine" for speed, human intuition remained the "steering wheel" to ensure the system met specific organizational standards. * The project highlighted that as AI handles more of the implementation, a developer’s ability to judge code quality and architectural fit becomes their most valuable asset. This project serves as a blueprint for the future of software engineering, where AI is treated as a peer programmer rather than a simple tool. To stay competitive, development teams should move away from rigid waterfall processes and embrace a PoC-centric workflow that leverages AI to collapse the distance between ideation and deployment.

Agile AI Gemini Claude+5

kakaoNov 19, 2025Original article

How the POPM Course Became a (opens in new tab)

Kakao developed its internal POPM (Product Owner/Product Manager) training program by treating the curriculum itself as an evolving product rather than a static lecture series. By applying agile methodologies such as data-driven prioritization and iterative versioning, the program successfully moved from a generic pilot to a structured framework that aligns teams through a shared language of problem-solving. This approach demonstrates that internal capability building is most effective when managed with the same rigor and experimentation used in software development. ## Strategic Motivation for POPM Training * Addressed the inherent ambiguity of the PO/PM role, where non-visible tasks often make it difficult for practitioners to define their own growth or impact. * Sought to resolve the disconnect between strategic problem definition (PO) and tactical execution (PM) within Kakao’s teams. * Prioritized the creation of a "common language" to allow cross-functional team members to define problems, analyze metrics, and design experiments under a unified structure. ## Iterative Design and Versioning * The program transitioned through multiple "versions," starting with an 8-session pilot that covered the entire lifecycle from bottleneck exploration to execution review. * Based on participant feedback regarding high fatigue and low efficiency in long presentations, the curriculum was condensed into 5 core modules: Strategy, Metrics, Experiment, Design, and Execution. * The instructional design shifted from "delivering information" to "designing a rhythm," utilizing a "one slide, one question, one example" rule to maintain engagement. ## Data-Driven Program Refinement * Applied a "Product Metaphor" to education by calculating "Opportunity Scores" using a matrix of Importance vs. Satisfaction for each session. * Identified "Data/Metrics" as the highest priority for redesign because it scored high in importance but low in satisfaction, indicating a structural gap in the teaching method. * Refined the "features" of the training by redesigning worksheets to focus on execution routines and converting mandatory practice tasks into selective, flexible modules. ## Structural Insights for Organizational Growth * Focused on accumulating "structure" rather than just training individuals, ensuring that even as participants change, the framework for defining problems remains consistent within the organization. * Designed practice sessions to function as "thinking structures" rather than "answer-seeking" exercises, encouraging teams to bring their training insights directly into actual team meetings. * Prioritized scalability and simplicity in the curriculum to ensure the structure can be adopted across different departments with varying product needs. To build effective internal capabilities, organizations should treat training as a product that requires constant maintenance and versioning. Instead of focusing on one-off lectures, leaders should design structural "rhythms" and feedback loops that allow the curriculum to evolve based on the actual pain points of the practitioners.

Agile Product Design Product Management Data Analysis+3

figmaAug 12, 20243 min readCurated summary

The Atlassian Method: The Power of Developer Joy | Figma Blog

Atlassian treats “developer joy” as more than a smoother developer experience: it is a company-wide philosophy centered on reducing friction and protecting the craft of development. After poor productivity and satisfaction in 2022, Atlassian standardized tools, improved processes, and empowered engineering teams to address frustrations directly. The effort produced major gains, including higher satisfaction, faster pull-request cycles, more frequent deployments, and improved roadmap delivery. ## Developer Joy as a Company Priority - Developer experience typically covers workflows, tools, and processes; developer joy focuses more deeply on the values, standards, and craft of development. - Atlassian found that developers lose more than eight hours per week—about 20% of their time—to inefficiencies. - Common sources of friction include: - Searching for information and solutions - Poor tooling and redundant systems - Cross-functional coordination with design and other teams - Planning and process overhead - In 2022, Atlassian frequently missed public roadmap commitments, while developer satisfaction fell below 50%. ## Operationalizing Joy - Atlassian created a cross-functional “champions” program to identify and eliminate organizational frustrations. - The initiative focused on: - **Systems:** Auditing tools and processes, standardizing where possible, and removing redundant tools—the company’s “Noah’s Ark of tooling.” - **Culture:** Establishing coding standards, shared values, and metrics that emphasized quality and craft, not just efficiency. - Every engineering team allocated 10% of its time to developer productivity improvements. - This gave developers an “ownership stake” in solving the problems affecting their work. - Developer joy became a company-wide OKR reported by teams every month. ## Measuring the Business Value - Atlassian accepted short-term tradeoffs, prioritizing engagement and productivity improvements over immediate revenue optimization. - The company measured both quantitative and qualitative outcomes. - Within a few months, it achieved: - A 50% increase in developer satisfaction - A 50% reduction in median pull-request cycle time - A threefold increase in deployment frequency - Delivery of all customer roadmap commitments instead of repeated delays - An increase in internal CSAT from below 50% to 80% - The results reinforced the idea that investments in tools, processes, and clear measurement compound over time. ## Toward Team Joy - The success of developer joy helped Atlassian build broader support for applying the same principles beyond individual developers. - The initiative began moving toward the larger concept of “team joy,” extending the focus to collaboration and the shared experience of delivering work. Organizations seeking similar results should treat developer productivity as an ongoing company responsibility: give teams dedicated time to improve their systems, reduce unnecessary complexity, and measure satisfaction alongside delivery performance.

Read original

Agile Software Development DevOps Developer Experience+3

figmaJul 17, 20192 min readCurated summary

A step-by-step guide to using Figma for retrospectives | Figma Blog

Figma can make agile retrospectives more inclusive and collaborative than a traditional whiteboard. Its multiplayer editing, comments, components, and remote-friendly workflow let everyone contribute simultaneously and clearly. The article recommends using retrospectives as both a practical meeting format and a low-pressure way to introduce a team to Figma. ## Sharing and Permissions - Create a Figma file or duplicate the provided retrospective template. - Use the blue **Share** button to invite teammates by email or generate a link. - Ensure anyone with the link has editing permission if the whole team should participate. ## Organizing Feedback with Frames - Divide the canvas into three frames: - What should we continue doing - What should we stop doing - What should we start doing - Apply constraints to headers, backgrounds, and other child elements. - When a frame is resized to provide more writing space, constrained elements adjust automatically. ## Using Sticky Note Components - Provide sticky note components so participants can quickly add feedback. - Duplicate notes with **Command + D** or by holding **Option/Alt** while dragging. - Component instances support overrides, allowing users to change text, colors, and effects without altering the master component. - Multiplayer cursors and shared visibility make the process engaging for in-person and remote participants. - Remote teammates can follow the discussion directly in the file instead of relying on a camera pointed at a physical whiteboard. ## Customizing the Template - Add the company logo and customize Figma styles with brand colors. - Create components for common interactions, such as “+1” markers for agreement or items needing further discussion. - Design themed cover pages when creating a new file for each retrospective. - Export completed frames for documentation or sharing. Figma’s collaborative canvas provides a flexible alternative to physical whiteboards, especially for distributed teams. Starting with the template and adapting its frames, components, and visual styling can make retrospectives more accessible while encouraging broader adoption of Figma.

Read original

Agile Figma Design Systems Collaboration+1