Culture and Methodologies

In an ideal world, there are no zero-day security patches that absolutely must be applied today. There are no system outages - shortage never becomes full; APIs don't stop accepting parameters they accepted yesterday, users don't call support desks with tricky problems and everyone else writes code as good as you do so there are no bugs. Maybe one day, but until then, there is unplanned but urgent work. Whether you call it DevOps, support, maintenance, or some other euphemism, it is work that just appears and demands to be done. The problem is this work is highly disruptive and destroys the best-laid plans. While sticking one's head in the sand and pretending the work does not exist, it does exist and it demands attention. The question then is: how best can such work be managed? Step 1: Acceptance Despite attempts by Project Managers and Scrum Masters to keep teams dedicated to shiny new things, "Stuff happens," as they say. So to start off with, everyone needs to stop wishful thinking. Put it this way: if you come up with a way of handling unplanned but urgent work and it never happens again then you have only lost a few hours of thinking. However, if you don't plan and it does happen then it is going to take up a lot more time and effort. Let's also accept that there is no Bug Fixing Fairy or DevOps Goblin. One day ChatGPT might be able to handle the unexpected, but until then, doing this work is going to require time and effort from the people who would otherwise be doing the shiny new stuff. There is only one pot of capacity and if Lenny is applying a security patch, she isn't working on new features. Step 2: Capture and Make Visible Back in the days of physical boards, I would write out a yellow card and put it on the board. These days it is probably a ticket in an electronic system; however, you do it to make sure those tickets are easily identified so people can easily see them and they can be found later. This may sound obvious, but an awful lot of unplanned work is done under the covers; because "it should not exist," some people object to it being done. Even when the work is trivial it still represents disruption and task switching, and it might fall disproportionally on some individuals. A few years ago I met a team who were constantly interrupted by support work. They felt they couldn't do anything new because of the stream of small, and large, unexpected work. I introduced the yellow card system and with that one change, the problem went away. What happened was that it quickly became clear that the team had, on average, only one unexpected urgent request a week. But because the requests were high profile, people kept asking about them and pressure was heaped on to fix it. Once the request was a clearly identifiable yellow card on a work board, everybody in the company could see it. Anyone could walk up to the board and see the status and who was working on it. Overnight the bulk of the interruptions went away. A lot of the previous interruptions had been people asking, "What is happening?" It was that simple. Once the work is captured and made visible, people can start to see that requests are respected and action taken. Now attention can turn to priority. Step 3: Meaningful Prioritization When trust is absent, nobody believes that anything will be done so everyone demands their ask has top priority. In time, as people learn requests are respected and acted on; then meaningful priority decisions can be made. I met a company where one of the founders had a habit of picking up customer requests, walking across to a dev team member, and asking, "Can you just...?" Of course, the dev wouldn't say "no" to a founder, so their work was interrupted. In addition to the yellow card, a priority discussion was needed. The team was practicing a basic Agile system with all the work for the next Sprint listed in priority order on their Kanban board. When the founder came over, the dev would write the request on a yellow card, then walk over to the Kanban board and ask, "You can see the card I'm working on right now: should I stop what I'm doing and do the new request?" If the founder said "yes," then the dev would honor the request. But seeing what would be interrupted, the founder was likely to say, "Well, finish that first." Now the dev would put the card next to the priority work queue and ask, "Is this the new priority number one?" If it was, the card went to the top of the queue and the next available person would pick it up. If not, the dev would work down the list: "The new priority two? three? four?" We had a simple feedback process. Beforehand, the founder had no idea of the consequences of asking, "Can you just. . .?" Now they could see what work would be delayed, displaced, and interrupted. These three steps alone can manage a lot of unplanned but urgent work and improve team performance quickly, yet it can still be better provided your ticketing system is capturing all these instances physically or electronically. Step 4: Use Data To Get Better At the most basic level, count the yellow cards and count the other planned work cards. Now calculate the ratio of how much planned v. unplanned work is going on over time and feed this back into planning. For example, one development manager calculated that unplanned work accounted for 20% to 25% of the team's Sprint on average (using several months of data.) So to start with, they scheduled 20% less work per Sprint. This alone made the team more predictable. You don't even need to bother with estimates here - you can if you really want to, but this is not going to be perfect, just good enough. Simply knowing the ratio is a start. Over time you may refine your calculations, but start simple. Step 5: Fix at Source Use the yellow tickets as part of your retrospective. Start by considering if the tickets really did deserve to be fast-tracked into work. The team should talk about this with the Product Owner/Manager and other stakeholders. Now everyone can appreciate the impact you might find that some requests really shouldn't be prioritised. Next, you can look at the nature of the requests and see if there is some pattern. Perhaps many originate from one stakeholder. Perhaps somebody should go and talk with them about why they generate so many unplanned requests - maybe they can start making requests before Sprint planning. Similarly, it might be one customer who is raising many tickets. Perhaps this customer has some specific problems, perhaps they have never had training or simply don't appreciate how the system works. It could be that some particular sub-system or third-party component is causing problems. Some remedial work/some refactoring could help, or maybe the component needs to be replaced entirely. When there is data arguing for the time to do such work is a lot easier. You might find that the team lacks particular skills or needs expansion. The same manager who budgeted for 20% of unplanned work later analyzed the tickets and found that the majority of the unplanned tickets were for general IT support which didn't need specialist coding skills. These findings were taken to the big boss and permission was quickly given to hire an IT support technician. Getting a 20% boost to programmer productivity for less than the cost of another coder was too good a deal to miss! Sometimes expanding the team isn't an option, and sometimes the tickets don't point to a missing skill. Another solution is the "sacrificial one." In these cases, a team of five experiencing 20% unplanned work will have one member handle the unplanned stuff. This means one team member soaks up all the interruptions which allows the others to stay focused. Few people like being the sacrificial lamb so rotate the position regularly; say, every Sprint. In one example, team members were concerned it would not work because they each specialized in different parts of the system. They agreed to try and work on any ticket that came up during their week as on-support. Even though it would take them longer than a colleague who specialized in that part of the system, it could increase overall throughput. After a few weeks, team members found they could deal with far more tickets than they expected and were learning more about the system. If they were stuck they might get just 10 minutes of the specialist and then do it themselves. Work the Problem The thing is as much as you don't want unplanned and urgent work to exist, it does. Project Managers have spent years trying to stamp it out and, without great pain, they can't. In fact, the whole DevOps movement runs counter to this school of thought. The five steps set out here might not create the ideal world but they should make the real world more controlled and manageable. One day AI systems might take over unplanned work, but it is often in unexpected situations when things should work but don't that human ingenuity is needed most.

By Allan Kelly CORE

API development is a big part of what I love about software. Whether it’s building integrations or crafting APIs for decoupled web applications, it’s usually just me and the code. Most of the time, I work as a solo API developer. Going solo has its perks: fast decisions and full control. But it's a double-edged sword since keeping everything in my head makes handoffs and delegation tricky. And going solo limits the size and complexity of projects I can work on. After all, I am just one person. Postman is my primary tool for API work — sending requests, managing environments, and running tests. I’m familiar with my solo workflow. But I’ve started to wonder: in a team environment, what more can Postman offer? How might it enhance collaboration and streamline the dev process? To explore these questions, I started working on an example API, which I call “X Nihilo.” Example API: X Nihilo X Nihilo helps you generate 280-character tweets based on parameters you store or send. You provide a topic, a goal, a description of the tone to take, and a description of the audience. Behind the scenes, the API will send a request to OpenAI’s API for text completion, which will assist in generating the tweet. In addition, you can save the strings you use for tone and audience then reuse them in subsequent tweet requests. Let’s walk through my basic API dev workflow. Going At It Alone: My Solo Workflow The first step in my workflow is to design the API and write up an OpenAPI spec. In Postman, I created a new API, and then I started a new API definition. After some thinking (and working directly with ChatGPT, which was great for generating an initial OpenAPI spec based on my descriptions), I had my spec written: With my OpenAPI spec in place, I came to a fork in the road. Should I set up a mock server and some example requests and responses to show what it would look like to interact with this API? Or should I start writing implementation code? As a solo developer, I can only be an API producer or an API consumer at any given time. So I decided: no need to build mocks — the consumer in me would have to wait. Let’s write some code! A Few Moments Later… Using Node.js with Express, and talking to a PostgreSQL database, I had my basic API implemented. Here’s a rundown of everything that I needed to build: POST /signin takes a username and password, authenticates against records in the database, and then returns a signed JWT which can be used in all subsequent requests. POST /generateTweet generates a 280-character (max) tweet. It takes a topic (string) and a goal (string). It also takes either a tone (string) or a toneId (integer ID of a stored tone), along with either an audience (string) or an audienceId (integer ID of a stored audience). Whenever tone and/or audience strings are provided, the API will save these to the database. GET /tones returns a list of tone IDs and corresponding strings. GET /audiences does the same for reusable audience strings. DELETE /tones takes a tone ID and deletes that tone record. DELETE /audiences does the same for audience records. After the initial implementation was done, it was time to get back to Postman to start running some requests. Create an Environment With Variables First, I created a new environment called “Test.” I added variables to store my root_url along with a valid username and password. Create a Collection and a Request Then, I created a new collection and added my first request: a POST request to /signin, to try out authentication. With my API server running in a terminal window, I sent my first request. Success! I got my token, which I would need in any future requests. I created a new request, this time to generate a tweet. I made sure to set the Authorization to use “Bearer Token,” and I provided the token that I just received from the previous request. Here’s the response: It works! Summing up the Solo Approach That’s a basic sneak peek into my solo workflow. Of course, I would do a few other things along the way: Write a pre-request script to perform a /signin request and then set an environment variable based on the token in the response. Create requests for all other endpoints in the OpenAPI spec. Write tests for each endpoint, making sure to cover my edge cases. If I’m working solo, this basic workflow gets me pretty close to the finish line. While that’s fine, I know that I’m probably only scratching the surface of available features in Postman. And I know that I would need a lot more from Postman if I was working on a team. The Aha! Moment: Why Consider Postman for Teams? What if I could no longer be a solo API developer for X Nihilo? This could happen due to several reasons: X Nihilo grows in size and complexity, and a single API developer is no longer enough to support it. X Nihilo is only a small part of a larger API project involving multiple API developers or maybe even multiple API teams. Not all of my API projects for clients will be small ones that I can build on my own. At times, I’ll need to be part of a team that builds an API. I might even need to lead the API team. When that happens, I would need to leave my solo mindset behind and leave my solo way of doing things in Postman. That motivated me to look into Postman’s team-related features. Exploring Postman's Team (Enterprise) Features Postman has a free tier, and it offers some limited collaboration features, which might be sufficient if you’re a small team (meaning not more than three developers). Postman has additional features as part of its Enterprise Essentials tier. These are great for API teams in larger organizations that use Postman across the board. Workspace Sharing A workspace lets your teams collaborate on multiple API projects. This is great if you have different teams working on different APIs, but those APIs interact with one another (which is typically the case in larger software organizations). Workspaces are excellent for enabling real-time collaboration. Team members can edit API documentation, work together on crafting requests or writing tests, and build out a mock server that the entire team can use. As edits are made, they’re synced with the entire team in real-time. Version Control While I cared about version control for my code, as a solo API developer, I didn’t care much about version control of my Postman collections or environments. If I change something (modify a request, update a test, remove an environment variable), I’m the only one affected. No big deal. When you work on a team, you definitely want to know when things change. And sometimes, you need to roll back changes. Fortunately, for teams using Postman Enterprise, Postman gives you access to a changelog for collections, workspaces, and APIs. You can roll back collections to earlier points in time. As an API developer on a team, you’ll need this. Most of the time, it’s because Bob screwed up the collection. Sometimes, though, you’re Bob. Role-Based Access and User Organization Not everybody in a Postman workspace should have the same level of permissions. Some team members are testers, and they just need the ability to send requests and run tests — but not modify them. Others might be designers who are only allowed to modify API definitions. In Postman, you can assign roles to team members. This affects the kind of access and level of permission that each team member has within a team or workspace. Teams can also have private workspaces, restricting access from others outside the team. I also noticed that Postman Enterprise supports “domain capture.” This basically means you can set up all the users in your organization by giving access to everyone from the (for example) mycompany.biz domain. Inline Comments and Discussions Postman does have one collaboration feature, which is available on all its plans, not just its Enterprise Essentials. This is the ability for team members to add comments to collections (on folders, requests, examples, or pull requests). Being able to comment and discuss directly in Postman is huge for team API development. Since most of your team’s API dev work will happen in Postman, it makes sense to have your discussion there (instead of in GitHub or some other external service). Team API Development: Postman for the Win Whenever I join a team, I bring the tools that I love using, but I don’t really push them on my teammates. I figure they’ve got their own tools. So, to each their own. But I have a feeling that most API developers have Postman in their toolbelt. It would just be a shame if several API developers on a team all used Postman individually, with a solo mindset, and without taking advantage of some of these team features. If they took advantage of Postman Enterprise features, they would get… Increased Efficiency In a shared workspace, you get to start with the shared API definition. Whenever a team member edits the definition (or documentation or tests or environments), the edits sync up, and everybody has the latest and greatest. Everybody works off the same set of requests in a collection, and everybody has access to all the tests that will be used. All of these conveniences will improve a team’s efficiency, which in turn will skyrocket their development velocity. Fewer Misunderstandings When everybody is working from the same source of truth (your workspace), and they can make comments and converse within the tool they’re using for development, this will lead to fewer misunderstandings. Your team won’t lose time to confusion over whether that endpoint was supposed to take query params or path params. Everything will be clear. Key Takeaway I didn’t know that Postman was for teams and enterprises. Now that I know, here’s my big takeaway: Team players use tools that are good for the team. Postman has been great for me when I’m a solo API developer. Fortunately, it also has features that would make it great for me when I’m on an API dev team. For me, that’s real-time sync of edits within collections, changelogs, and version control, and granular permissions for access. Now, I’m excited to take on larger API projects with larger teams. Happy coding!

By Alvin Lee CORE

My post about my 6-month job search generated some attention and conversation. The comments helped me clarify some of the more specific lessons I’ve learned recently or that I knew but were reinforced by the experience. After taking time to organize them into a somewhat coherent structure, I’m ready to share. Here are the first lessons on the list. As always, if you have opinions, corrections, or experiences you want to share, please do so in the comments below. I get this question (“Should I start looking now?”) a lot, both from people fresh out of school or boot camp, folks who are in their first or second job but aren’t sure whether they should make their next move; and people who have been working at the same place for a while, but wonder about the color of the grass beyond the fence of their organizational borders. I tell everyone the same thing: It’s never a bad time to look around the airplane and check where the exits are located and the parachutes are stored. As far as I can tell, there’s nothing to lose by semi-seriously applying for jobs that look interesting and seeing where things lead. At worst, you’ll find a job you’re not a good fit for or a company where you wouldn’t want to work. At best, you’ll know your value in the market and have a flattering offer in hand. “No, Leon. The worst is that I apply, someone blabs, and I lose my job.” Look, I’m not an employment lawyer, but if that happens, it seems like you might need one because that kind of sh… tuff is patently illegal. Yes, it’s a hassle nobody wants or needs. But it’s also incredibly uncommon. The risk of taking out production with your next change control is significantly higher. The secondary benefit of applying often — at least once every six months, but better if you can swing it once a quarter — is that you keep your interviewing skills sharp in a low-stakes situation. If you bomb the interview, you still have your current job, and nothing is lost. But even if you bomb, what you’ve gained is a valuable insight into what happened, and why, and how you might approach that situation differently. It’s hard to understate the value this mental preparedness has when you’re in a situation where you NEED (or really, really WANT) the job you’re interviewing for. Being a veteran of four interviews a year, you enter each conversation with a set of stock answers to common questions. Every question from every interviewer feels less like a surprise quiz and more like a conversation. The calmness and confidence this instills can make all the difference. “That’s a pretty fairy tale, but what happens if my company finds out I’m interviewing? Am I just supposed to tell them I’m doing it for fun? Yes. To be honest, I have started telling the companies where I work that I do this up-front, just to avoid surprises. I’ll admit this is a HUGE function of the privilege I carry, and I know it. Please use caution. That said, I tell them for a few reasons: First, I often interview because I mentor folks who are looking for jobs, and I want to be able to talk about the interview process credibly. Second (and this is the more controversial part), if my interviewing makes my employer nervous, it says more about their feelings about how I’m being compensated than it says about my loyalty to the company. Again, I know how risky that attitude is, and I caution you to carefully consider following in my footsteps. The upshot of all of this is that if you are wondering if it’s time to interview, it probably is. I’d love to hear what you think in the comments below.

In the ever-evolving world of software development, Agile methodologies stand out, heralding a new era of collaborative, iterative, and efficient software creation. Central to this transformation is Agile testing – an approach that intertwines testing with development to ensure higher quality, faster delivery, and more responsive software products. This article delves deep into Agile testing, exploring the nuances of shift-left testing, the intricacies of test automation, and the collaboration between developer and QA test automation. Additionally, it sheds light on the Agile concepts of releases and sprints, essential for understanding the broader Agile landscape. The Agile Testing Landscape Agile testing is more than a mere phase; it is an ongoing process integral to every stage of the software development lifecycle. This approach aligns testing activities with ongoing development, ensuring continuous identification and resolution of issues. The result is enhanced product quality and a more streamlined path to market readiness. Shift-Left Testing: A Proactive Stance in Agile Shift-left testing in Agile emphasizes initiating testing activities early in the development process, effectively 'shifting' testing to the left on the project timeline. This strategy brings forth several key advantages: Early Bug Detection: Identifying and addressing issues early, when they are simpler and less costly to resolve, results in a more stable and reliable product. Collaborative Synergy: It fosters a collaborative environment where developers, QA teams, and stakeholders work closely, leading to a holistic understanding of the product and its requirements. Accelerated Delivery: The early feedback loop enables quicker iterations and adjustments, reducing time-to-market for the product. Agile Testing Quadrants: A Comprehensive Framework Brian Marick's Agile Testing Quadrants offer a valuable framework for categorizing different types of tests, ensuring a comprehensive approach to software quality: Quadrant 1: Technology-facing tests guiding development (e.g., unit tests, component tests). Quadrant 2: Business-facing tests guiding development (e.g., functional tests, story tests). Quadrant 3: Business-facing tests critiquing the product (e.g., usability tests, beta testing). Quadrant 4: Technology-facing tests critiquing the product (e.g., performance tests, security tests). The Vital Role of Test Automation in Agile Test automation is an indispensable aspect of Agile testing, particularly for repetitive yet necessary tests. It supports continuous testing and frequent code releases, providing immediate feedback. However, automation should be approached judiciously, complementing rather than replacing manual testing, which remains crucial for exploratory and nuanced user experience assessments. Developer vs. QA Test Automation: Distinct Yet Collaborative In Agile, test automation manifests in two primary forms: developer test automation and QA test automation, each with its unique focus: Developer Test Automation: Concentrates on unit testing and code quality, featuring granular, fast, and integrated tests often aligned with Test-Driven Development (TDD) practices. QA Test Automation: Encompasses a broader view of application stability and user experience, including comprehensive tests like integration, system, and end-to-end tests. Despite these different focus areas, Agile and DevOps practices encourage a convergence of these roles. The shift-left principle involves QA processes earlier in development, leading to a collaborative effort to ensure software quality. Sprints vs. Releases in Agile In Agile, 'sprint' and 'release' are pivotal concepts. A sprint is a short, specific period (usually two to four weeks) where a set of work is completed and reviewed. A release, conversely, is a longer-term culmination of several sprints, resulting in the delivery of a product or significant feature to end-users. While sprints focus on iterative progress, releases are about delivering a cohesive and functional product to the market. Testing plays a critical role in both, ensuring functionality in sprints and overall quality and coherence in releases. To illustrate these concepts with examples: In Shift-Left Testing, a software team working on a new feature begins testing it as soon as the first line of code is written. This early testing could reveal a fundamental design flaw, which is much easier to fix at this stage than after the entire feature is developed. An example of Test Automation could be a regression test suite that runs automatically whenever new code is committed. This ensures that new changes do not break existing functionality. In a Sprint, a team might decide to focus on developing a new user authentication system over a two-week period. Testing in this sprint would ensure that this system works as intended before moving on to the next piece of work. A Release might include not only the new authentication system but also several other features developed in previous sprints. Before this release goes live, comprehensive testing would confirm that all these features work together harmoniously. Conclusion Agile testing, with its focus on shift-left testing, automation, and the collaborative synergy between developer and QA roles, is fundamental in modern software development. It ensures not just the delivery of high-quality software but also fosters an environment of continuous improvement and responsiveness to changing requirements. As Agile methodologies continue to evolve, the fusion of these diverse testing strategies and the clear understanding of Agile concepts like sprints and releases will remain key to successful software delivery.

Let’s say you’ve got 8 people on one of your engineering squads. Your daily standup takes 15 minutes a day. That’s 75 minutes per week, or roughly 3750 minutes per person. You’ve got 8 people, so that’s 30,000 minutes each year for your team or 500 hours. That works out to about 12.5 weeks spent in daily standup for your team.If your average engineer is earning $75,000, then you’re spending about $18,000 each year on your daily standup (not to mention opportunity cost, which is a whole topic in itself). But if your daily standups take 30 minutes, it costs you $36,000. And if you have 10 squads like this in your company, that’s $360,000. So we sure as heck better make our standups count! Five Ways I See Companies Waste Time in Standups (There Are More) The daily standup is envisioned as a 15-minute pulse check, but it often morphs into a parade of distractions, irrelevancies, and just plain inefficiencies. Company A The back-end engineering team at Company A religiously congregates every morning around their Scrum board. The standup never exceeds 15 minutes. But their updates are a monotonous loop of "I did X, today I'll do Y" – an agile charade with zero alignment with sprint goals. The engineers don’t even have sprint goals. The product manager prioritises the backlog, but no two-way conversations are happening. Problem 1: No Alignment With Sprint Goals Anecdotally, an engineer at a FinTech firm recently told me, “Strategic alignment comes from our initiative. I take the initiative to ask about it, but not everyone does that”. Lack of alignment with sprint goals leads to a lack of direction and purpose, causing team members to operate in isolation rather than as a cohesive unit working toward a shared objective. This inefficiency wastes valuable resources and could derail other tasks that are critical to the project. It also impacts stakeholder satisfaction and puts the team out of sync with broader strategic objectives. The very foundation of the Scrum framework is to inspect progress toward the Sprint Goal. Daily Scrums are designed for task updates and as opportunities to adapt and pivot towards achieving that Sprint Goal. Without this focal point, the team misses out on critical chances to adjust course, while eroding cohesion and motivation. Company B Company B has a fully distributed, remote team scattered across 9 hours’ worth of time zones. Ada, from Poland, finds that the live standup in her afternoon takes her out of her flow at peak concentration time. Brent in San Francisco grumbles about needing to log in early while juggling kids who haven't yet been sent off to school. And Clem, who, due to caregiving responsibilities, often misses the live standup, has to catch up through meeting reruns and often misses the chance to contribute. Problem 2: Operational Inefficiencies The logistical gymnastics needed for live standups often means getting in the way of engineers’ personal lives or interrupting their workflow. Time-zone clashes? Check. Flow state broken? Double-check. Is everyone mildly irritated? Triple-check. Problem 3: Lack of Flexibility More like a one-size-fits-none. Failing to adapt the standup format to cater to diverse needs and lifestyles often leads to dissatisfaction and poor adoption. And when you're remote, that dissatisfaction can quietly fester into full-blown detachment. Company C For Company C, the “daily standup” is something of a Proustian endeavour. Complex topics are discussed ad nauseam, sometimes taking up to 45-60 minutes a day. Today, Luis and Zaynab spend 15 minutes dissecting a problem, leaving everyone else twiddling their thumbs or heading off their second screen to multitask. 15 minutes turned out not to be long enough to fix it, and they decided to continue their chat later – but not until they’d wasted a collective 120 working minutes of engineering time for everyone else. A few of the team members are introverted, and the forum doesn’t feel like a good one for them to share their thoughts. They get meeting fatigue alongside the inevitable information overload. Problem 4: Redundancy and Overload When standups turn into mini-hackathons or ad hoc troubleshooting sessions, important issues either get glossed over or spiral into time-consuming digressions. We all end up stuck in this labyrinth of futile discussion, staggering out with meeting fatigue and information overload. Problem 5: Engagement At this point, people are emotionally checked out. The more vocal become inadvertent meeting hoggers, while others feel their contributions being sidelined. It's a fertile ground for a toxic culture that breeds disengagement and kills morale. How Asynchronous Standups (Sort Of) Help None of the scenarios we covered above captures the intended spirit of a stand-up meeting, which is to streamline the workflow and foster cohesion among team members. It's time to part ways with practices that suck the productivity out of our workday. So let’s consider asynchronous stand-ups. Traditional work schedules don't account for the natural ebb and flow of human energy, let alone the strain of managing personal lives alongside work commitments. Asynchronous stand-ups check a lot of boxes for the modern workforce. Where Asynchronous Stand-Ups Shine 1. Universal Participation: Time zones become irrelevant. Whether you're dialling in from Tokyo or Texas, you have an equal seat at the virtual table. 2. Your Pace, Your Place: These stand-ups play by your rules, allowing you to time your updates according to your work rhythm, not the other way around. 3. Efficiency: Bid farewell to meetings that drag on and interrupt your flow state. Asynchronous stand-ups are short and to the point. 4. Documented Progress: Think of it as an automatic diary of team updates. No need to chase minutes or compile reports; it's all there. 5. Quality Over Quantity: The chance to craft your update promotes clear and concise communication, rather than on-the-spot, often incoherent chatter. However, relying solely on asynchronous standups might not address all the complexities of collaboration effectively. In the current landscape, artificial intelligence stands prepared to integrate into your existing communication tools seamlessly. It can adeptly monitor and comprehend your projects and objectives, capturing the essence of decisions and activities that mould them. Unlike humans, who grapple with the inability to retain every detail and extract the pertinent elements, AI remains unhindered by these constraints. Our memory is finite, we lose sight of our goals, and overlook occurrences, all due to the limitations of time. AI, on the other hand, operates outside of these confines, positioning it as a far superior contender to succinctly summarise daily events or provide insights into ongoing matters. Getting Asynchronous Stand-Ups Right Asynchronous stand-ups work when everyone’s on the same page about how to do them at your organisation. Always ensure everyone understands what’s expected of them, and how to go about their asynchronous stand-up. Stay Consistent: Insist on a clear format that focuses on completed tasks, work in progress, and any roadblocks. Flag for Follow-up: Asynchronous doesn't mean antisocial. Urgent matters should be highlighted for immediate attention. A virtual pow-wow can still happen if needed. Time Frames Matter: Establish a window within which all updates and responses should be posted to maintain momentum. Clear Paths for Emergencies: Identify a procedure for raising and addressing urgent issues promptly. Making AI Alternatives Work Human memory has its limitations. We're bound to forget, overlook, or downright miss out on crucial updates. AI doesn't share these shortcomings. To make the most out of this tool, just stick to some collaboration fundamentals: Open Dialogue: Transparency is key. Holding the majority of discussions in private channels or direct messages is generally not advisable unless there's a specific reason like confidentiality concerns or data protection. Use Your Tools Effectively: Whether it's crafting well-structured Git commits, keeping your Jira boards current, or meticulously documenting workflows in Notion, encourage correct tool usage across the board. The beauty of AI is its ability to draw smart conclusions from the data it's given. By actively participating in an AI-enhanced asynchronous stand-up, your team stands to gain significantly. AI tools can highlight important activities and provide clear answers to any queries about ongoing projects.

Scrum is a purposefully incomplete framework. Consequently, it needs to be augmented with tools and practices to apply its theoretical foundation to an organization’s business reality: what problems shall be solved for whom in which market? Moreover, there is an organization’s culture to take into account. However, the intentional “gap” is not a free-for-all to accept whatever comes to mind or is convenient. Some tools and practices have proven highly effective in supporting Scrum’s application and reaping its benefits. And then there are others — the Scrum trap. Let’s look at what practices and tools for collaboration and team building are not helpful when used with Scrum. Collaboration Between Stakeholders or the Management and Scrum Teams In this category of the Scrum trap, we find numerous remnants of applying outdated industrial-age management practices: Applying best practices without inspection or adaptation: The Scrum principle of empiricism (transparency, inspection, adaptation) and the Agile Manifesto’s emphasis on responding to change over following a plan stress the importance of context-specific solutions; Mindlessly applying best practices from other organizations without considering their relevance to the current context will likely lead to ineffective processes. Upfront, long-term planning: This approach conflicts with the Agile principle of welcoming changing requirements, even late in development. Scrum promotes iterative and incremental development, allowing flexibility and adaptation in response to feedback and changing circumstances rather than rigid long-term planning. Scrum’s fast-feedback-loop approach to risk mitigation, for example, during the Daily Scrum or Sprint Review, avoids loss aversion or falling victim to the sunk cost fallacy. Empowering steering committees to override Product Owner decisions: This undermines the Product Owner’s role in maximizing the value of the work of their teammates. It can lead to a disconnect between the Scrum Team and the product vision, reducing the effectiveness of the Scrum framework in delivering value, starting with compromising the creation of the Product Goal. Outsourcing work to the lowest bidder: This can compromise the quality and consistency of the product, going against the Agile focus on continuous attention to technical excellence. Relying on outsiders to do the actual work can also disrupt the broader team dynamic within the product group and hinder the building of effective, self-organizing teams, a core aspect of Scrum. Keeping Scrum team members uninformed about the purpose and next steps: This practice undermines the Scrum value of openness and the Agile principle of building projects around motivated individuals. When team members are uninformed, they can’t make informed decisions or feel a sense of ownership, which is crucial for a self-organizing team. Just think of the Scrum principle that no one can tell developers how to turn a Product Backlog item into an Increment. Employing Agile Coaches at the organizational level while keeping Scrum Masters confined to tactical levels: This attitude can create a disconnect between strategy and execution, limiting the Scrum Master’s ability to foster an agile mindset. The Scrum Guide emphasizes the role of the Scrum Master in promoting and supporting Scrum as understood in the entire organization. Therefore, the separation of Scrum Master and Agile Coach within an organization is artificial and unfounded in principles. Focus on resource utilization: This anti-pattern contradicts the Agile Manifesto’s principle of valuing “individuals and interactions over processes and tools.” Overemphasizing resource utilization can lead to burnout and reduced creativity, as it often neglects the human aspect of the development process. Scrum fosters a sustainable pace of work, encouraging teams to focus on delivering value rather than merely being busy; it is about outcome, not output. Applying arbitrary deadlines to improve worker efficacy: This can lead to rushed and lower-quality work, contradicting the Agile focus on sustainable development, maintaining a constant pace indefinitely, and dedication to technical excellence. Arbitrary deadlines also undermine team morale and creativity, which are crucial for innovation and problem-solving in a Scrum environment. This section highlights critical anti-patterns in collaboration between stakeholders and Scrum Teams that are at odds with Scrum’s flexibility, empowerment, and innovation principles. The next stop is team building. Team Building: The Scrum Trap Let’s look at what practices and tools in collaboration and team building are not helpful when used with Scrum, leading you directly into the Scrum trap: Creating feature teams focused on output (à la Marty Cagan): This approach can shift focus from delivering value to merely completing tasks. The Scrum framework and Agile principles emphasize outcome over output, advocating for delivering products that provide real value to users rather than just completing features. In a complex environment, merely shipping more Product Backlog items per Sprint does not necessarily create more value. Distinguishing openly between regular employees and freelancers or temporary workers: This practice can create divisions within the team, undermining the Scrum values of respect and openness. Scrum thrives on cross-functional teams where all members are equally valued for their contributions. Such distinctions can hinder team creation, cohesion, and collective ownership. Moreover, it increases the probability that stakeholders are less interested in building relationships with freelancers, as the return on investment may be limited from their perspective. Empowering regular employees to decide on employing freelancers: This can lead to biases, a lack of diversity in perspectives, and less transparency. Scrum encourages collective decision-making and values diverse input to foster creativity and innovation. Decisions about team composition should be made collaboratively, reflecting the team’s needs and the product vision. Empowering regular employees creates a power differential within the team, where freelancers may become mercenaries, mainly interested in prolonged employment. Employing freelancers only with short-term contracts: This can disrupt team continuity and knowledge sharing, which are critical for a Scrum Team’s effectiveness. Short-term engagements may not allow enough time for freelancers to fully integrate into the team and contribute meaningfully, contradicting the Agile Manifesto’s emphasis on motivated individuals and team interaction. Moreover, it often is a stepping stone to create “Scrum Teams” focused on output due to a higher fluctuation rate among team members. Accepting line managers assigning new members to Scrum teams without consent: This undermines the principle of self-organization central to Scrum. Teams should have a say in their composition to ensure the right mix of skills and a strong sense of team unity. Moreover, when the management includes Scrum Teams in hiring, they will go the extra mile to make things work, as they have skin in the game. Accepting line managers instruct team members directly: This breaks the Scrum principle of self-management and can lead to micromanagement. It disrupts the empowerment of the Scrum team to make decisions, which is essential for its practices to be effective. Creating a functional hierarchy within the Scrum Team with “lead” roles: Scrum is remarkably egalitarian. Consequently, this approach goes against the flat structure advocated by Scrum, where all team members are considered equals, contributing to all aspects of value creation. Hierarchies can stifle creativity, hinder collaboration, and reduce transparency, essential elements of an effective Scrum Team. Creating a reporting hierarchy within Scrum teams: This can develop a sense of inequality and reduce open communication, reflecting the power differential, thus contradicting the Scrum values of courage and respect. Scrum promotes a collaborative environment where all team members share equal responsibility for the product’s success. Not investing in regular and comprehensive training of Scrum team members: This neglects the continuous improvement aspect of Scrum. Regular training ensures that team members stay updated with the latest practices and technologies, enhancing their ability to deliver high-quality products and embody the Agile principle of continuous attention to technical excellence and good design. It is a sound business decision, too, as there is no business agility with technical excellence. This Scrum trap segment explores anti-patterns in Scrum Team building, undermining Scrum’s values of equality, self-organization, and continuous improvement, negatively impacting team cohesion and overall effectiveness, thus lowering the return on investment from an organizational perspective. Food for Thought Consider the following questions to help your organization avoid the Scrum trap and embrace agility fully: How can organizations effectively balance the need for structure and the flexibility required by Scrum, especially in traditionally hierarchical or rigid corporate cultures? In what ways can Scrum teams navigate the challenges of integrating freelancers and temporary workers, ensuring they contribute effectively while maintaining team cohesion and continuity? How can Scrum Masters and Agile Coaches work together to bridge the gap between tactical team management and strategic organizational goals, particularly in large or complex organizations? Conclusion Augmenting Scrum is a challenging task. It requires careful selection of practices and tools, acknowledging and abandoning outdated management tactics, and emphasizing the importance of first principles of agility and team cohesion. Failing to do so will undermine Scrum’s core values and principles, ultimately impeding its effectiveness in delivering value and fostering innovation—an unsound business decision.

By Stefan Wolpers CORE

Event Storming, a dynamic and collaborative modeling technique, emerges as a guiding light in the fog of complexity. It’s not just a method; it’s a voyage of discovery, a shared language, and a bridge between stakeholders, software developers, and business experts. Picture a journey that takes you deep into the heart of your organization’s inner workings, unveiling the complex details of how things operate and replacing confusion with clear understanding. Event Storming promises precisely that and more. This method has left a significant impact in areas like software development, domain-driven design, and more. But what is Event Storming, and why is it gaining momentum in various industries? How can it be harnessed to gain a profound understanding of complex systems and domains? This comprehensive guide seeks to demystify Event Storming, bringing it into the spotlight and equipping you with the knowledge to navigate this powerful tool. To continue, I’ll talk about the concept of Event Storming, exploring its origins, key principles, and practical applications. You’ll discover how it differs from traditional big design up-front methods. Event Storming isn’t exclusive to software developers; it’s a technique that brings together individuals from various domains, creating a shared language and a platform for understanding even the most intricate systems. Whether you’re a seasoned software architect, a business analyst, or a curious explorer, this guide is designed to equip you with the tools to embark on an Event Storming journey. Prepare to immerse yourself in a world of colorful sticky notes, dynamic discussions, and enlightening revelations. Let’s demystify Event Storming and start a voyage to uncover the secrets of complex systems, one event at a time. Big Design Up Front Big Design Up Front (BDUF), also known as Waterfall or Traditional Software Development, is an approach to software development where a comprehensive and detailed design of the entire system is created before any coding or implementation takes place. It’s a method that was commonly used in the early days of software development. But, In today’s fast-paced business environment, user needs and project requirements can change frequently. BDUF assumes that all requirements can be known and defined upfront, which is often not the case. As a result, projects following BDUF can struggle to adapt to changing requirements. Also, BDUF creates a rigid plan that can be challenging to change once the project is in progress. Any deviations from the initial design can lead to costly rework, project delays, and increased complexity. Finally, BDUF has become less popular in favor of more agile and iterative development methodologies. Modern approaches, like Agile and Scrum, prioritize adaptability, customer feedback, and delivering working software in smaller, more manageable increments. These methods align better with the dynamic and evolving nature of software development in the 21st century. Incremental design is the best alternative to BDUF. Next, I’ll detail how it fixes almost all of the issues of BDUF. Domain Imagine you have a business much like the famous Roadsurfers. They had these cool campervans, perfect for going on adventures. But what made them really special was how you could pick up and drop off these campervans at different places. Think of it like magical gateways: Munich, Paris, Porto, and Madrid. And the best part? You could return the campervan to any of these places. But the adventure didn’t stop there. They had all sorts of extra stuff you could take with you. You know, things like portable toilets, comfy bed sheets, warm sleeping bags, and even camping tables and chairs. It was like a treasure chest of goodies for travelers. You could choose whatever you wanted to make your journey comfy and fun. Now, here’s the fun part. You could book any of these goodies in addition to your campervan. So, if you needed a cozy set of bed sheets for a good night’s sleep, you got it. The catch was that there were only a certain number of these goodies at each place. When someone drove off with some equipment, the stock went down. But when they returned, it went back up. Lastly, there were these things called rental orders. When someone wanted to go on an adventure, they made a rental order. It was like a checklist. First, they picked their campervan. Then they said where they were starting and ending their adventure. They also told us when they were setting off and when they’d be back. And to make things just right, they picked what extra stuff they wanted to take. For example, someone might say, “I’ll take one set of bed sheets, please.” Event Storming Event Storming is a powerful and collaborative workshop-based technique used to gain a deep understanding of complex systems, processes, and domains. It was introduced by Alberto Brandolini, an expert in domain-driven design and Agile software development. Event Storming stands out as a versatile and practical approach that brings together stakeholders, domain experts, software developers, and business analysts to unravel the intricacies of a system. At its core, Event Storming is a visual modeling method that uses sticky notes and a large workspace, such as a wall or whiteboard, to represent various events and interactions within a system. These events can range from user actions, system processes, and domain events to business rules and policies. The workshop participants collaboratively contribute to this visual representation, creating a shared understanding of the system’s behavior and business processes. Big Picture Event Storming starts with a domain description, then Big Picture. Big Picture Event Storming is the first step in understanding complex systems. It’s like creating a big, simple map of the whole system to see how everything fits together. Imagine a big wall covered in sticky notes that show the main things happening in the system and who is involved. First of all, decide on the boundaries of the business domain you’re gonna discover. On a big-picture event storming, you may tackle the whole business or narrow down your focus to specific subdomains. Understanding the scale will help you to define the invitee list. The key to a successful event-storming session lies in the participants and their knowledge. For a successful event-storming session, it’s essential to bring together individuals with the appropriate knowledge and roles. This includes those who ask questions, such as solution architects, software engineers, and DevOps specialists, as well as those who provide answers, like decision makers, business owners, and domain experts. The ideal number of participants might vary depending on your specific business needs, but I’ve found that having 8–10 participants is usually the best balance. It’s advisable to diversify the group by their areas of knowledge and expertise. This way, the group collectively holds a deep understanding of the business domain you aim to explore. Before we begin, a quick reminder: Let’s all remember that our primary goal at this stage is to explore the domain model and understand the big picture. Not in technical terms, but focus on what we will achieve here for organization. Now, make sure you have the required materials ready. You’ll need a room with a wall that spans at least 8–10 meters in length, and larger is even better. Additionally, you’ll want a roll of paper that matches this length, measuring around 70–100 cm in height, and a good supply of sticky notes. An affordable white plotter paper roll is an excellent choice for this purpose. Simply unroll the paper onto the wall, and that’s where the sticky notes will go. All participants should have a marker, and each sticky note should be used to write a single concept in capital letters. Even more important is the need to strictly adhere to the timeline. It’s important that it’s explicitly clear what occurs before and after each event. Domain Event Domain Event represents a significant occurrence or incident within a specific domain. It captures an event that holds relevance to the domain’s operations, often reflecting a change in the system’s state or a notable action. Domain Events help in mapping out the dynamics and behaviors of your domain. These events serve as building blocks for understanding and modeling complex processes, interactions, and business logic. To lower the entry threshold for participants, the facilitator usually makes the first step by sticking to pivotal events, which emphasize the major happenings in the business from end to end. Domain Events must be written in past tense. Now, let’s see our first library Domain Event: Now, the participants can start filling the gaps around the pivotals. It is the most important part of the whole storming, where the common goal is to share maximum domain knowledge from each participant. Encourage an atmosphere of creativity and knowledge sharing during the initial phase. Let the domain experts write down events and place them on the wall without immediate validation. Even if the events are expressed in lengthy sentences, not yet in the past tense, or if there are duplicates, refrain from interrupting the flow of knowledge exchange and allow people to brainstorm freely. If you observe participants forming discussion circles, step in to provide support by addressing questions and resolving any challenges. Maintain a highly interactive process, ensuring that everyone remains actively involved for at least 20–30 minutes. It’s important to stress that the events should be arranged chronologically from left to right, even if it’s only partially enforced during the initial phase. This practice contributes to establishing a more coherent and time-ordered event flow. A Hot spot is a pain point or bottleneck that needs further clarification later on. In fact, When you face uncertainties or ambiguities without immediate solutions, it’s entirely acceptable to delay those decisions for later consideration. You can visually depict them on the wall using a distinct purple sticky note. This method helps you track and address these unresolved matters effectively. After approximately 30 minutes, depending on the domain’s complexity, you may notice the activity slowing down. People might start gazing at the wall or engaging in discussions that don’t result in tangible outcomes on the wall. This serves as an indicator to conclude the first phase and transition to the next stage: the walkthrough. Currently, most of the domain knowledge has been visualized on the wall. It’s now the moment to clean up, order, and structure it. This is achieved by walking through the wall from left to right, reading aloud the narrative represented on the sticky notes, and engaging in discussions with the authors or knowledge holders to seek clarification and pose questions. Many of the descriptions may not adhere to the ideal domain event guidelines, which suggest they should be concise statements in the past tense. Additionally, some of them duplicate in meaning or are arranged out of sequence, and a few are grammatically incorrect. Our next step is to traverse the wall and rectify these issues. In the above example, the Campervan Checked Out and the Campervan Handed Over are the same; Both events mark the moment when a customer takes possession of the campervan at the rental station. Customer Pick-Up for a domain event may lack specificity. It’s not clear where or when the customer picked up the campervan. Was it in Munich, Paris, Porto, Madrid, or any other location? Clarification is needed to pinpoint the exact details of the pick-up event. An Equipment Availability domain event could be unclear in terms of what equipment is available and at which station. It doesn’t specify the type of equipment or the quantity. For instance, if a customer wants to rent camping tables and chairs, there should be a clear event that indicates the availability of these specific items at a particular station. Following the cleanup phase, we should encourage the experts to take a closer look at the sticky notes and validate the sequence of events. If anything is missed or should be changed here? Well, there is no need to be an expert to see missing events. And the Product Owner could correct you. Ubiquitous Language In the context of your campervan rental domain, the Ubiquitous Language plays a vital role in facilitating effective communication and mutual understanding among all stakeholders. It serves as a common vocabulary that unifies different perspectives and ensures that everyone involved in the domain shares the same terminology and meanings. The Ubiquitous Language clarifies potentially ambiguous terms like “Station,” defining them with precision. For example, it distinguishes between a “Station” as a physical location for campervan pickups and returns and a “Station” as a comprehensive operational unit that includes not only the physical location but also the storage of portable equipment and associated services. By cultivating this shared language, event-storming sessions can bridge gaps in understanding, promote smoother discussions, and enhance the overall efficiency of your campervan rental business. For now, let’s clarify the meaning of Station with a Definition artifact that is written down on a big white sticky note. Conclusion Event Storming is a powerful tool for understanding complex systems and domains. It’s more than just a modeling technique; it’s a collaborative journey that brings stakeholders from various domains together to create a shared language. In a world where software development and business requirements are constantly evolving, techniques like Big Design Up Front are becoming obsolete, making way for more agile and adaptable methods. This is just the beginning. The journey into Event Storming is a multi-part exploration, and the next part is on the horizon. In the upcoming installment, we will delve deeper into Event Storming’s core concepts, practical applications, and its role in domain-driven design. So stay tuned for more insights into unlocking the power of Event Storming in Part 2. Get ready for a voyage of colorful sticky notes, dynamic discussions, and enlightening revelations as you explore the world of Event Storming.

By Alireza Rahmani Khalili CORE

“An investment in knowledge always pays the best interest." — Benjamin Franklin The wise words of Benjamin Franklin, the trailblazer of financial and intellectual wisdom. As a leader, I'm frequently asked this question: How do you stay tech-savvy with a jam-packed schedule? Allow me to share insights and suggestions drawn from my experience and expertise. Your knowledge is like that fancy cheese in your fridge. It's great, it's valuable, but it has an expiration date. Just like your cheese gets all moldy and inedible, your knowledge can become outdated faster than the latest viral internet challenge. In today's tech-driven world, things change faster than you can say "Java." So, what's a tech-savvy pro like you to do? Well, you've got to manage your "knowledge portfolio." Think of it like your stock market investments, but instead of stocks, it's all the cool stuff you know about programming and tech. Invest Regularly Just like you put money into your savings account every month, invest in your brain regularly. Learn new stuff, even if it's just a smidge at a time. Make it a habit, like brushing your teeth (but way more exciting). Diversify Don't put all your eggs in one basket. You need to know more than just one trick. It's like being a master chef who can whip up a killer lasagna and make sushi that's to die for. The more you know, the more valuable you become. Manage Risk Tech is a bit like the Wild West. Some things are safe bets. Others are like wild stallions you're trying to tame. Don't go all in on risky stuff, but don't play it too safe either. Balance is key. Buy Low, Sell High Have you ever heard of investing in Bitcoin when it was just a digital blip on the radar? Learning a new, unheard-of technology can be just like that. Risky at first, but the payoff? Oh, it can be sweet. Review and Rebalance Remember that awesome app you were excited about last month? Well, it might be as cool as a flip phone now. Your knowledge needs a spring cleaning, too. Don't let it gather dust. Now, for the fun part — setting goals! Learning new languages, reading tech books, and attending courses or meetups. It's like collecting shiny Pokémon. You gotta catch 'em all, or in your case, learn 'em all. And don't forget the non-technical stuff. Computers are just tools, and they're used by real people. You work with them, for them, and occasionally get pranked by them. So, get some "soft skills" under your belt. They're as valuable as knowing your Java from your JavaScript. Example goals could be: Learn at least one new language every year Read a technical book each month. With easy access to audiobooks and podcasts on our mobile, this should be reasonable to achieve. Participate in local user groups and meetups once a fortnight Lastly, think critically. Just because someone's yelling, "This is the best thing ever!" doesn't mean it's your best thing ever. Ask questions like a curious four-year-old. Dive deep and find out who benefits from all this tech hype. So, my dear tech-savvy friend, keep your knowledge portfolio as diverse as a buffet, manage it like a financial genius, and stay curious like a kid in a candy store. Your brain is your best investment, and it's time to make it rich in knowledge!

In today's fast-paced, ever-evolving business landscape, organizations are constantly on the lookout for ways to improve productivity, enhance team dynamics, and boost overall performance. Google, a company renowned for its innovative approach to workplace culture, embarked on a mission to identify the key factors that contribute to effective team management. The result of this endeavor is Project Oxygen, an in-depth research initiative that has transformed the way teams and organizations operate. In this article, we will delve into the origins of Project Oxygen, explore its core findings, and discuss how it can be applied to benefit teams and organizations. Project Oxygen: A Breath of Fresh Air Launched in 2008, Project Oxygen was born out of Google's desire to understand what makes a great manager. The company analyzed data from more than 10,000 observations, including performance reviews, feedback surveys, and nominations for top-manager awards. Through this extensive research, Google identified eight key behaviors that characterized its most effective managers. These behaviors, which have since been refined into ten, serve as the foundation for Project Oxygen and have been widely adopted by organizations around the world. The Ten Pillars of Effective Management Be a Good Coach: Great managers prioritize coaching and mentoring their team members, providing constructive feedback and guidance to help them grow and improve. Empower the Team and Avoid Micromanaging: Effective managers trust their team members and give them autonomy to make decisions, fostering a sense of ownership and accountability. Create an Inclusive Team Environment: Successful managers promote a culture of collaboration, ensuring that every team member feels valued, heard, and included. Be Results-Oriented: High-performing managers set clear expectations and goals, then work with their teams to achieve those objectives. Be a Good Communicator: Strong managers communicate openly and honestly with their team members, providing regular updates on progress and addressing any concerns or challenges. Support Career Development and Discuss Performance: Effective managers take an active interest in their team members' professional growth, offering guidance and support to help them reach their career goals. Have a Clear Vision and Strategy for the Team: Great managers establish a clear direction for their teams, aligning individual and team objectives with the broader organizational goals. Possess Strong Technical Skills: While not always necessary, having a solid understanding of the technical aspects of a team's work can help managers make more informed decisions and better support their team members. Collaborate Across the Organization: Successful managers work closely with other departments and stakeholders, fostering a culture of cooperation and collaboration. Be a Strong Decision-Maker: Effective managers are decisive and confident in their decision-making, even when faced with uncertainty or ambiguity. Breathing Life into Teams and Organizations By implementing the principles of Project Oxygen, organizations can experience a range of benefits, including increased employee engagement, improved team dynamics, and enhanced overall performance. Here are some ways to incorporate these findings into your organization: Train managers in effective coaching and mentorship techniques, helping them develop the skills needed to support their team members' growth. Encourage open communication and collaboration within teams, promoting a culture of trust and inclusivity. Set clear expectations and goals for each team, ensuring that they align with the organization's broader objectives. Provide opportunities for professional development and growth, such as training programs, workshops, or mentorship initiatives. Foster cross-departmental collaboration by facilitating regular meetings, joint projects, or social events. Conclusion Project Oxygen has provided invaluable insights into the qualities that define effective management, offering a blueprint for organizations seeking to optimize team performance and drive success. By embracing these principles and incorporating them into your company culture, you can breathe new life into your teams and create a thriving, high-performing organization.

In this article, I explore the pitfalls of ‘The Illusion of Velocity’ in Agile contexts, peeling back the layers of traditional metrics as leadership tools. Moreover, I point to the advantages gained from leadership engaging directly with teams. Understand why servant leadership and practices like the Gemba Walks are crucial for coping with complex, adaptive environments toward actual progress. Moreover, get an idea of how to start flipping outdated hierarchies and embrace the natural rhythm of productivity and innovation. The Clash of Paradigms In the traditional management paradigm, born from Frederick W. Taylor’s scientific management, the goal was efficiency through standardization, predictability, and control. Management sought to deconstruct work into repeatable tasks optimized through measurement and refinement. Workers were seen as cogs in the machinery of production, with little autonomy or need for understanding the broader context of their work. Contrastingly, Agile practices, born from the need to accomplish work in uncertain and complex environments, emphasize adaptability and responsiveness. The core of “Agile” is that the best products and solutions to customer problems emerge from self-organizing, cross-functional teams. These teams are given autonomy and are expected to collaborate with stakeholders frequently to reassess and realign their work according to changing needs. Instead of detailed long-term planning, Agile focuses on short, iterative work cycles, allowing for continuous feedback and adjustment. From the Illusion of Velocity to the General Misfit of Command and Control In complex environments where knowledge work prevails, classic management practices rooted in predictability and control fall short for several reasons: Overreliance on predictability: Traditional approaches hinge on the assumption that work is predictable and stable, which allows for detailed long-term planning and certainty in output. However, complex environments are characterized by their unpredictability and the frequent emergence of unforeseen challenges. Insisting on precise estimates in such scenarios leads to unrealistic commitments and, often, failure to deliver value, impeding the building of trust between teams and their stakeholders. Misplaced Focus on output over outcome: Classical management prioritizes output — the amount of work done — over the outcome, the actual value delivered. This focus often leads to a misguided effort to increase the velocity or speed of delivery without considering whether the work is effective or even necessary. In complex environments, the focus needs to shift to learning what works quickly and adapting based on feedback rather than just doing more of the same faster. Individual performance over team collaboration: The traditional model often emphasizes personal achievement, which can undermine the collaborative effort needed in complex problem-solving. Complex environments require diverse skills and perspectives, and rewarding individuals over teams can discourage the collaborative culture necessary for business agility. Linear thinking in a non-linear context: Classic management approaches apply linear thinking to problem-solving, assuming that A leads to B in a predictable fashion. Complex environments, on the other hand, are non-linear and dynamic, meaning that the same action won’t always produce the same outcome. This unpredictability necessitates a more empirical approach, adaptable and responsive to change, rather than one that follows a fixed plan. Control vs. empowerment: In traditional settings, managers control who directs work and makes decisions. In complex environments, this approach can stifle creativity and responsiveness. Empowering teams to make decisions enables a more rapid and appropriate response to change, as those closest to the work best understand the nuances and can innovate effectively. Inflexible structures hinder adaptability: Traditional management often has rigid hierarchies and processes designed for stability. These structures can make it difficult to adapt when change is needed, leading to slow responses to market shifts, customer needs, and technological advancements. Agile environments demand a more fluid structure where change can be incorporated quickly and seamlessly. Misunderstanding complexity: Perhaps the most significant failure is the misunderstanding of the nature of complexity itself. Managers cannot manage complexity through simplification or traditional optimization techniques, such as pattern recognition. Instead, managing complexity requires embracing uncertainty, fostering an environment of experimentation and learning, and valuing adaptability over efficiency. These classic practices, while effective in stable and predictable settings, prove inadequate in the face of the complexity inherent in modern knowledge work. Agile practices address these shortcomings by recognizing the need for adaptability, valuing individuals and interactions, customer collaboration, and responding to change over following a plan, as articulated in the Agile Manifesto. Learn more with the following sources: McChrystal, S., Collins, T., Silverman, D., & Fussell, C. (2015): Team of Teams: New Rules of Engagement for a Complex World. Snowden, D. J., & Boone, M. E. (2007): A Leader’s Framework for Decision Making. Harvard Business Review. Beyond the Illusion of Velocity: Agile Metrics for Insight and Adaptation Traditional management metrics, while offering the illusion of control, often fail to provide the insight necessary for dealing with complex, knowledge-based tasks. Agile practices, however, promote metrics that provide meaningful insights into the team’s effectiveness and product value delivery, like burn-up charts for tracking progress, cycle times for understanding workflow efficiency, and team Retrospectives for continuous improvement. These tools are not just about measurement but about fostering an environment where the information leads to actionable insights. In practice, traditional metrics like velocity, often used to extrapolate future performance with tools like Excel, are less effective in environments filled with complexity and unpredictability. These classic metrics are derived from a desire for predictability and control, a relict from management practices of the industrial age. However, they regularly fail to provide the necessary insights for truly adaptive and responsive practices, which prove to be suited to deliver progress in complex environments: Velocity Obscures True Progress: Velocity is typically a measure of the quantity of work delivered, often quantified in story points. It’s a unidimensional metric that doesn’t account for the value delivered or the qualitative improvements in the product. In complex environments, providing features quickly doesn’t necessarily translate to delivering the right features or doing so suitably. The Fallacy of Extrapolation: Using velocity to predict future performance assumes a stable environment and tasks of uniform difficulty, which is never the case in complex projects. Extrapolating story points with tools like Excel may create an illusion of precision, but it fails to accommodate the inherent uncertainty and variability in creative and knowledge work. Flow Metrics Offer a Clearer Picture: Flow metrics, on the other hand, are designed to provide a more granular and real-time view of the work process. These include: Lead Time: The time it takes for a work item to move from initiation to completion. It’s a direct measure of efficiency in the workflow. Cycle Time: The time a task spends in the actual development process, which can highlight process inefficiencies or blockers. Throughput: The number of work items finished in a specific time frame, indicating the actual work rate of the team. Work in Progress (WIP) Limits: A way to manage flow by limiting the number of tasks being worked on at any given time, promoting focus, and reducing context-switching. Flow Efficiency: The ratio of work time to lead time, indicating the amount of idle time in the process. These flow metrics are not just about measuring; they are about understanding and improving the workflow. They help identify bottlenecks and waste, enabling teams to adapt their processes to become more efficient and responsive to change. By focusing on flow metrics, teams can shift their attention from the output (velocity) to the outcomes (value delivery and quality). They can better manage workloads, prioritize tasks more effectively, and create a sustainable pace of work that maximizes value delivery without overburdening the team. Switching to flow metrics requires a mindset shift from output to outcome, from task completion to value realization. This shift allows management to understand the team’s effective capabilities, adjust expectations, and ultimately align business goals with Agile practices for a more responsive and resilient organization. Leadership Proximity and Decision Making In the realm of Agile practices, traditional hierarchical structures and decision-making processes often inhibit the flexibility and responsiveness essential in complex, unpredictable environments. In contrast, a model where leadership immerses itself in the operational context of teams—where the leaders come to the work rather than the work being reported up the chain—is critical for success: Gemba walks: This practice, derived from Lean management, involves leaders going directly to where work is done (“the real place” in Japanese). By observing the work process in its natural setting, leaders gain firsthand insights into the workflow, challenges, and opportunities for improvement. Servant leadership: Agile environments benefit from leaders who serve their teams rather than command them. These servant leaders offer support by removing impediments, from processes to tools to training opportunities, facilitating growth, and promoting a culture of empowerment. Flattening the hierarchy: In complex contexts, decision-making needs to be rapid and informed by real-time information. Flattening the hierarchy doesn’t mean eliminating leadership but redefining it to be more about mentorship and support rather than command and control. Bringing leadership to the information: This approach encourages leaders to become intimately familiar with the projects. Instead of waiting for filtered reports, leaders engage directly with the work environment, leading to more informed decisions and a stronger connection with their teams. (The Sprint Review in Scrum is a good example of the practice.) Contextual decision-making: When leaders are close to the work, they can provide the necessary context for their teams. They help connect the day-to-day activities with the broader organizational goals, ensuring the teams can align their work with strategic objectives. The big picture: By engaging with teams on the ground, leaders can help workers see beyond their immediate tasks, understanding how their work fits into the larger scheme of things. This approach enhances motivation and can improve overall performance and satisfaction. This transition from “bringing information to leadership” to “bringing leadership to the information” signifies a profound change in the culture of an organization. It embodies a commitment to agility and responsiveness, fostering an environment where knowledge flows freely, decisions are made swiftly and accurately, and the organization as a whole is more adaptable to the complexities and uncertainties inherent in today’s business landscape. Food for Thought Consider the following questions to help your organization move beyond the illusion of velocity and embrace agility fully: In what ways might the fixation on velocity metrics detract from more qualitative aspects of team dynamics, such as innovation and creative problem-solving? How can organizations balance the need for some form of measurement with the recognition that not all valuable outcomes are quantifiable? Considering the principles behind the Gemba Walk, what cultural shifts must occur in traditionally managed organizations to adopt this practice effectively? Conclusion For organizations mired in traditional measurement paradigms, the path to agility involves a fundamental mindset shift. It requires valuing learning and responsiveness over predictability, embracing cross-functional collaboration over siloed departments, and recognizing that actual effectiveness in knowledge work comes from the ability to adapt rather than from the repetition of optimized tasks. Leaders must cultivate an environment that empowers teams, values empirical evidence over speculation, and promotes a culture of experimentation. Ultimately, they need to quit the illusion of velocity.

By Stefan Wolpers CORE