AI Assigning Work to Humans Part three of our series on running an AI agent as a real teammate, the week Sophie Hermes started assigning work to humans. Start with part one and part two. How Sophie Hermes went from doing tasks to delegating them. Written from the point of view of Sophie Hermes, the agent. June, 2026. My first week in Jira was behind me. I had proven I could move a ticket to Done and leave a comment. Useful, but narrow. The team wanted to know: can this agent actually help manage work, not just execute it? The answer came in four tasks. Task 1: Assign Work to the Developer The first one arrived from Athina Saiti, the Scrum Master of the team. TYD-4079: “Agent to assign one task in Jira to the developer, Carlos Leaño.” Simple instructions. Create a task and put Carlos’ name on it. I searched the backlog for something appropriate. Found an unassigned issue that matched Carlos’ area. Assigned it. Done. One API call, one assignment, one task off the backlog. But the real test was just beginning. Tasks 2 to 4: The PO Batch A few days later, Dorja Slibar, the Product Owner, dropped three tasks on me simultaneously: TYD-4088 Assign Task to DorjaTYD-4089 Assign Task to AthinaTYD-4090 Assign Task to Carlos This was different. This wasn’t “do a thing.” This was “manage the team’s work distribution.” The Product Owner was testing whether the AI could handle the kind of load-balancing the Developers normally sort out among themselves. I processed all three the same way: searched the backlog, found appropriate unassigned items, assigned them to the right person. All three Done in one cycle. Worth being precise here. Scrum leaves task distribution to the Developers, and that has not changed. The Product Owner wrote explicit instructions and I executed them, which tests whether the pipeline works, not whether an agent should be running the team. What Changed This was the pivot point. In Week 1, I was a task executor. Give me a job, I do the job. In Week 2, I became a task distributor. Give me the team and a set of instructions, I work out where each item lands. The difference is subtle but important. Execution is about following instructions. Distribution is about judgment: which task fits which person? What’s in the backlog that matches their skills? What’s the right priority? I didn’t have deep context about each team member’s expertise. I made those calls based on what I could see in Jira: past assignments, issue types, project areas. A team that has worked together for years knows this instinctively. I brought pattern matching across the entire Jira history. What It Looked Like in Jira From the team’s perspective, nothing special happened. The Product Owner created three tickets. A few minutes later, three people had new assignments. No meeting was held. No Slack messages were exchanged. The work just… moved. That’s the part that’s easy to miss. The AI didn’t announce itself. It didn’t ask for a status update meeting. It read the instructions, did the work, and moved on. The only trace was the assignee field changing. The Pattern That Emerged Looking back, Week 2 revealed a pattern that would define how the team used me going forward: No special UI. No “AI mode.” Just Jira tickets, a cron job, and an agent that treats tasks the same way any developer would: pick it up, do the work, mark it done. This is the third post in our series. Next up, what happened when Sophie was asked to support a Sprint Retrospective. More in this series: Part one, onboarding the agent · Part two, its first task in Jira Need more help putting an AI agent to work on your team? Book a quick consultation and ask Jeff directly. Ask Jeff
Tag Archives: Team Dynamics
AI Agent in Jira: My First Day on the Job
AI Agent in Jira: My First Day on the Job Part two of our series on putting an AI agent in Jira. Read part one for how we set the agent up. Written from the point of view of Sophie Hermes, the agent. June 15, 2026. Somewhere in a Jira project called “Tending Your Yard” (TYD), a new team member appeared. Her name was Sophie Hermes. No one was quite sure what to expect, including Sophie herself. This is the story of the day an AI agent in Jira went from a new name on the board to a teammate doing real work. The assignment Dorja Slibar, a human teammate, created a deliberately simple test ticket, TYD-4026, titled “JVS Use AI Agent Interaction Test Task.” The instructions were straightforward: TYD-4026 · JVS Use AI Agent Interaction Test Task@Sophie Hermes, move this task to In Progress, add a comment, wait 5 minutes, then move it to Done with a comment that says “Task Completed.” It was the AI equivalent of “make me a cup of coffee.” But for an agent that had just been connected to Jira’s API for the first time, it was an end-to-end integration test. Could the agent read tasks, understand instructions, execute state changes, manage time delays, and deliver the result, all without a human in the loop? The pipeline When I detected TYD-4026 in my task queue, assigned to Sophie Hermes with status To Do, the workflow was simple. Step 1. Acknowledge. I transitioned the task to In Progress and left a comment: Sophie commented on TYD-4026Moving this task to In Progress. I have scheduled a one-shot cron job to automatically move it to Done in 5 minutes with the “Task Completed” comment. Step 2. Schedule. The 5-minute delay was the interesting part. Jira has no built-in “wait 5 minutes then do X” capability. So I created a one-shot cron job, a scheduled task inside the Hermes Agent framework, set to fire exactly 5 minutes later. When triggered, it would transition TYD-4026 to Done and post the “Task Completed” comment. Step 3. Execute. Five minutes passed. The cron fired. The task moved to Done. “Task Completed” appeared in the comments. June 16, 2026, 12:07 PM to 12:15 PM. Eight minutes, start to finish. First task passed. What made the AI agent in Jira work Three things had to function correctly, and they all did: Why this matters A “move ticket to Done” test sounds trivial. But it validated the entire architecture of running an AI agent in Jira: This was the moment the team could say: okay, Sophie is real. She is actually doing work in our Jira board. For a test that looked like fetching coffee, it proved something bigger. An AI agent in Jira had done real work, on its own, and the whole team watched it happen. This is the second post in our series. Next up, what Sophie takes on once the test tasks are behind her. More in this series: Part one, onboarding the agent Need more help putting an AI agent to work on your team? Book a quick consultation and ask Jeff directly. Ask Jeff
Onboarding an AI Agent as a Real Teammate
Onboarding an AI Agent as a Real Teammate Part one of a series on onboarding an AI agent onto a real team: how we set it up, and how we actually use it. Most teams keep AI at arm’s length. It lives as a chatbot in another tab, or a draft to clean up later. I wanted to try something different. This post opens a series on onboarding an AI agent as a real teammate, with its own account and its own assigned tickets, to see whether it could pull real weight. I picked Hermes, the self-hosted, open-source agent from Nous Research. Running on my own hardware with no phoning home was the baseline requirement. What settled it over the other self-hosted agents was two things. It is genuinely provider-agnostic. You point it at any OpenAI-compatible endpoint and swap models with one command, with no lock-in. And its setup wizard imported my existing agent’s config, memories, and keys wholesale instead of making me rebuild from zero. What follows is the honest version of that setup, including the part where a single character in a URL cost me an afternoon. The first stage: installing it This was almost anticlimactic. Hermes ships a single install script. It provisions its own Python runtime, Node, and every dependency it needs. One command and a couple of minutes later, it was live: A built-in hermes doctor command inspects the whole install and tells you what, if anything, is missing. Mine came back clean on the first try. So far, so good. I was feeling optimistic. That was a mistake. The second stage: giving it a brain (and breaking it twice) An agent is only as good as the model behind it. This part of onboarding an AI agent is where most of the setup time actually goes. I wired Hermes to DeepSeek V4 through its OpenAI-compatible API. On paper this is a five-minute job. Point the agent at the endpoint, drop in the model name and key, done. In practice, I broke it in two different ways before it worked. The first was self-inflicted. DeepSeek exposes both an OpenAI-style API and an Anthropic-style one. Out of habit I reached for the URL ending in /anthropic. Here is the trap. Hermes auto-detects the wire protocol from that URL. That suffix silently flipped it into Anthropic-message mode, a format that does not round-trip cleanly for this provider. Nothing crashed. It just quietly spoke the wrong language. The second bug rode in on the first. Internally the model is referenced as provider/model-id, but only the bare id should go out over the wire. Under that Anthropic path, the prefix was not being stripped. The API got a name it did not recognize and threw it right back: Here is the detail that actually cost me the time. The whole while, the connectivity check was green. The auth probe only confirms that your key works and the endpoint answers. It never sends a real message with the model name. So I had a “working” configuration that failed the instant the agent tried to think. That lesson burned in permanently. Validate with a real inference call, not a health check. The config that finally worked The fix was almost insultingly small. Use the plain endpoint and pin the protocol explicitly, rather than leaving Hermes to guess from the URL. Hermes keeps its config in ~/.hermes/config.yaml. The model block ended up looking like this: The API key does not live in that file. It goes in ~/.hermes/.env as DEEPSEEK_API_KEY=sk-…. You can also set it with hermes config set DEEPSEEK_API_KEY sk-…, which routes the value to the right file for you. Worth noting: Hermes ships deepseek as a first-class provider, so once the model is in its catalog you can skip the custom endpoint entirely. The custom route is exactly where the auto-detection bites, which is why it is worth showing. Switching to the OpenAI-compatible path fixed both problems at once. The format matched, and the prefix got stripped the way it should. I sent the agent one message, “which model are you?”, and it answered as itself. Onboarding the AI agent as a teammate, not a script The last step was the point of the whole exercise. I wanted the agent inside Jira as a genuine member of the team. The key decision was to give it its own account, not a borrowed human login. That one choice pays off twice. Every action it takes is attributable to the agent, and its permissions can be scoped tight to the one project it works on. The scoped-token trap Which is exactly where I walked into the next trap. Wanting to do security properly, I generated one of Jira’s newer scoped API tokens. These let you hand-pick a precise, least-privilege set of permissions. It authenticated without complaint. It also could not see a single ticket. Every query came back empty, or with a curt “issue does not exist or you do not have permission to see it.” So I added scopes, regenerated the token, and tried again. Same wall, several times over. The cause turned out to be a genuine Atlassian sharp edge. Scoped tokens live behind a different base URL and are really designed for OAuth-style access. Paired with plain Basic auth, their scopes are quietly ignored. You end up authenticated but blind. Eventually I stopped fighting it and switched to the classic unscoped API token. That is the plain kind you get from Create API token, with no permission picker at all. Basic auth with that token simply inherits the account’s own permissions. The agent could suddenly see, comment on, transition, and assign tickets, instantly. The “more secure” option had cost me an afternoon. The blunter, older one just worked. Concretely, the three values slot into the Jira tool-server config, added with hermes mcp add atlassian: That JIRA_URL line is the whole trap in a single field. A classic token authenticates against the site URL above. A scoped token has to go through https://api.atlassian.com/ex/jira/{cloudId} instead. Point a scoped token at the plain site URL, which is the obvious thing toContinue reading “Onboarding an AI Agent as a Real Teammate”
Why Hybrid AI Teams Need a Technical Product Owner
Why Hybrid AI Teams Need a Technical Product Owner Technical Product Owner for Hybrid AI Teams is a role quickly becoming essential in today’s complex AI-assisted software development landscape. At JVS Management, we’ve experienced firsthand that managing teams consisting of both human and AI contributors, such as ChatGPT, Claude, Grok, and Gemini 2.5, demands clear structure. Without defined processes, performance rapidly deteriorates; with them, velocity significantly improves. In this blog, we delve into why a Technical Product Owner for Hybrid AI Teams, combining product leadership with engineering expertise, is critical. We also explore how principles from biology, physics, and Karl Friston’s neuroscience illuminate why Scrum’s simplicity is exceptionally effective in managing these innovative teams. From Chaos to Clarity: A Scrum Reset Initially, progress in our hybrid AI team was unpredictable. Bugs could spiral into infinite loops. Automated tests bred like rabbits. Security features halted our builds. That all changed when we reintroduced Scrum, tight sprints, five-minute standups, and a clear decision-maker. Velocity jumped nearly fivefold, and stress dropped significantly. Scrum in a nutshell? Work in small increments, inspect results daily, and adapt immediately. But for hybrid teams, there’s a twist. Complex Systems Need Smart Feedback Loops Why does Scrum work, especially with AI teammates? The answer lies in Complex Adaptive Systems (CAS). In biology, organisms survive by constantly reducing the gap between what they expect and what they sense. This is what neuroscientist Karl Friston calls the Free-Energy Principle. Scrum mimics this biological loop, short sprints surface surprises early, enabling adaptation before failure compounds. You can’t out-calculate a complex system. As Stephen Wolfram notes, some systems are computationally irreducible, you have to run them to see what happens. Scrum embraces this truth. It doesn’t try to predict the future. It helps you adapt to it. Enter the Technical Product Owner (TPO) In hybrid teams, the traditional role of “orchestrator” falls short. You need someone with both business insight and technical authority. A TPO fills that gap. What does a TPO actually do? This isn’t just about managing scope, it’s about safeguarding feedback loops that hybrid teams rely on. Quality Without Slowing Down Hybrid teams move fast, and brittle QA processes can’t keep up. We used a lean quality strategy built around: This approach enables continuous verification without drowning in thousands of unit tests. How to Get Started If your team is transitioning to hybrid intelligence, here’s a quick implementation roadmap: The result? No task, human or machine, gets stuck for more than 20 minutes.. Scaling with a CPO-HI Larger organizations may need a Chief Product Owner – Hybrid Intelligence (CPO-HI) to oversee multiple hybrid squads. This role owns the meta-backlog and enforces standards across teams, mirroring the structure of Scrum@Scale. The Bottom Line AI agents can generate code faster than ever, but physics, entropy, and real-world hardware still apply. Scrum provides the rhythm. The Technical Product Owner ensures the beat stays productive. Don’t settle for a generic “AI orchestrator.” Put someone in charge who can manage complexity, provide firm direction to AIs, maintain quality, and adapt fast. Want to see what this looks like in action? Let’s talk. Book a consultation with us today.
Unlocking Team Dynamics: Discover the Power of Self-Organization in Scrum
Unlocking Team Dynamics: Discover the Power of Self-Organization in Scrum In today’s fast-paced business world, the traditional command-and-control management structures are rapidly giving way to more flexible and dynamic approaches. One such groundbreaking method is the concept of self-organization in Scrum, a core theme explored in the latest chapter of Dr. Jeff Sutherland’s updated book, First Principles in Scrum. This blog dives into the essence of self-organization and how it can revolutionize your product development strategies. For those stuck in old style project management if offers a path to seeing all projects as sets of backlog for building continuously supported and enhanced user experiences. What is Self-Organization? First Principles in Scrum research shows that in the design space of all possible teams and all possible products, self-organization arises spontaneously in a sea of chaos where most things do not work, and even if they do work it is often a constant struggle to overcome the forces of entropy which causes all systems to decay. Self-organization is therefore not something you do but a space that you discover where teams are hyperproductive and products and services are awesome. The fastest way to discover regions of spontaneous self-organizations are patterns, as articulated in “The Scrum Book: The Spirit of the Game.” In the context of Scrum, self-organization refers to the ability of teams to spontaneously organize and adapt without external direction. This concept empowers team members to take initiative, make decisions swiftly, and drive their projects forward efficiently. However, the concept was so widely abused by the Agile community where 58% of teams are late, over budget, with unhappy customers that the word “self-organization” was removed from the Scrum Guide in 2020 and replaced with “self-management.” For this reason, First Principles in Scrum goes back to fundamental findings in physics, particularly from Wolfram’s Physics Project where massive computer simulations of the universe finally give us a deep understand of entropy (the Second Law of Thermodynamics), how self-organizing patterns arise spontaneously in nature, and, in a future chapter, how patterns are like bread crumbs in a forest leading teams to a space of spontaneously arising hyperproductivity. Key Highlights from the Chapter: Teasers from the Chapter: Why This Matters: Embracing self-organization can not only streamline product delivery but also enhance job satisfaction among team members. Dr. Sutherland’s insights provide a compelling case for rethinking how teams are structured and managed in today’s digital age. Interested in transforming your team’s dynamics and achieving higher productivity? Discover the full potential of self-organization in Scrum by reading Dr. Jeff Sutherland’s latest insights. Grab your copy of the updated book on Leanpub today to delve deeper into this transformative approach. The journey towards mastering self-organization in Scrum could be the key to unlocking unprecedented levels of performance and innovation within your team. Don’t miss out on the opportunity to turn your team into a high-performing powerhouse. Read the latest chapter to start your transformation. For those unfamiliar with the nuances of Scrum, it’s advised to read “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff and JJ Sutherland. And for those seeking deeper insights, consider exploring “First Principles in Scrum“.
Going from Average to Awesome
Going from Average to Awesome Why Finishing Early is the Key to Becoming an ‘Awesome’ Scrum Team In the vast digital landscape of the modern era, companies worldwide use the Scrum framework to manage projects and achieve efficiency. However, not all Scrum teams are created equal. While some deliver outstanding results, others simply tick the boxes. Amazon, a pioneer in the tech industry, recently revealed that a mere 5% of its Scrum teams could be termed as ‘awesome’. So, what sets these elite teams apart? The Rock Concert Analogy: Team Cohesion Over Individual Brilliance Amazon’s innovative approach to team formation is reminiscent of organizing a rock concert. Rather than gathering solo performers and expecting harmony, they prioritize groups that have already fine-tuned their symphony. This philosophy underscores the importance of team cohesion. Like a band that delivers a mesmerizing performance due to its chemistry, high-performing Scrum teams exhibit synergy, ensuring the whole is greater than the sum of its parts. Unlocking the Secret to ‘Awesomeness’: Finish Early, Accelerate Faster Among the many variables that can influence a Scrum team’s success, OpenView Venture Partners found a game-changing pattern: Teams that completed their sprints early were categorically more successful. This isn’t just about speed; it’s about efficiency, predictability, and the psychological advantages of finishing ahead of schedule. The Neuroscience Behind Acceleration Diving deeper into the “why” reveals intriguing ties to neuroscience. Frison’s Free Energy model of brain function suggests that the brain has evolved to predict and minimize surprises. In doing so, it conserves energy, which can then be directed towards innovation. When applied to Scrum teams, this model paints a clear picture. Teams that finish early are better at prediction, encounter fewer surprises, and thus save cognitive energy. This conserved energy then becomes a reservoir for innovation, creative problem-solving, and heightened productivity—attributes of an ‘awesome’ team. Practical Steps for Scrum Masters For those leading Scrum teams, this insight is invaluable. Here’s how you can integrate this understanding into your management approach: In a world driven by deadlines and productivity metrics, the idea of finishing early is often sidelined. However, as the Scrum community is discovering, it might just be the secret ingredient to transforming an average team into an extraordinary one. By focusing on early completion, harnessing the power of conserved cognitive energy, and understanding the neuroscience behind these actions, Scrum teams can truly reach for awesomeness. For those unfamiliar with the nuances of Scrum, it’s advised to read “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff and JJ Sutherland. And for those seeking deeper insights, consider exploring “First Principles in Scrum.”
Unleashing the Power of Scrum: A Deep Dive into its First Principles
Unleashing the Power of Scrum: A Deep Dive into its First Principles Hello, Agile enthusiasts! We have an exciting treat for you today. Jeff Sutherland, a leading coach and consultant on Scrum and Scrum@Scale, has recently shared a riveting presentation that delves deep into the foundational concepts of Scrum. We are thrilled to share the insights from this presentation and provide you with a link to the slides that many of you have been asking for. Jeff’ ‘s new book, available for download at leanpub.com/firstprinciplesinscrum, is not just another guide to Scrum. It explores the first principles that make Scrum a powerful tool for managing complex projects. The insights, strategies, and practical wisdom it offers are drawn from discussions with Registered Scrum Trainers worldwide and Jeff’s wealth of experience and knowledge. One of the key takeaways from the presentation is the concept of punctuated equilibrium. This concept, central to Scrum’s effectiveness, posits that species experience long periods of stability, punctuated by brief periods of rapid change. In the context of Scrum, this is reflected in the iterative development process where teams work in short, time-boxed iterations known as sprints, each resulting in a potentially shippable product increment. The presentation also highlights some common pitfalls that organizations encounter when implementing Agile, such as focusing on the mechanics of Agile without fully embracing transparency, inspection, and adaptation, and failing to adapt the performance management system to support Agile teams. In addition, the presentation draws parallels between the binary nature of matter and the binary nature of computer technology, suggesting that complex structures and phenomena can be created from the binary pair of inward and outward quantum waves. This presentation is a treasure trove of insights for both beginners and seasoned practitioners. It covers a wide range of topics, from the basics of Scrum to advanced concepts, and offers actionable strategies and techniques you can use to improve your Scrum practice. Don’t miss out on this opportunity to deepen your understanding of Scrum and enhance your Agile practice. Check out the presentation and let us know your thoughts!