Posts in Agile (20 found)
Lewis Campbell's Blog 5 days ago

Waterfall Reconsidered

We all know waterfall is bad. It's outdated, bureaucratic, ineffective, and makes you late for dinner. It's just a stupid thing we did in the bad old days, before we were taught better by a group of consultants at a mountain retreat. Or so the Agilists would have us believe. Today agile apologists claim the true meaning of agile has been distorted. What we commonly think of as Agile - bureaucratic processes, standups, backlogs, product owners, sprints etc etc - is actually Industrial Agile, sometimes or Big-A Agile. But, actually , the original agile (small-a!) is wonderful, and contains only what's in agile manifesto. I will show we can make the exact same argument for waterfall; that there is an original, uncorrupted kernel we have neglected, and that the horrible nasty Industrial Waterfall - held up as a bogeyman by agilists - is a distortion of the initial, elegant idea. You have been lied to, dear reader - and if you would learn more of the truth of small-w waterfall, read forth! Today "Waterfall" is taken to mean a one pass development process. First all the requirements are done, then the specs, then the coding, then the tests - in more or less granularity. You can only go forward between these phases - never backwards. Problem in the specs? Too bad, they've been signed off on. But it did not mean this to the men who coined it. The first mention of "Waterfall" was the 1976 paper Software Requirements: Are They Really a Problem? by Bell & Thayer. In it they argue that software requirements do not just "arise naturally", but need an engineering effort to define well (a finding that still eludes many software teams some 50 years thence), and early in the second page they write of "software development systems"; what we might today call methodologies: ...practicioneers have concluded that a top-down approach is superior to the bottom-up approach of the past. The Military Standard set MIL- STD 490/483 recognized this newer approach by specifying a system requirements document, a "design-to" requirements document that is created in response to the system requirements, and then a "code-to" requirements document for each software module in the design. Each of these is at a lower level of detail than the former, so the system developers are led through a top-down process. The same top-down approach to a series of requirements statements is explained, without the specialized military jargon, in an excellent paper by Royce [5]; he introduced the concept of the "waterfall" of development activities. In this approach software is developed in the disciplined sequence of activities shown in Figure I. Each of the documents in the early phases of the waterfall can be considered as stating a set of requirements. At each level a set of requirements serve as the input and a design is produced as output. This design then becomes the requirements set for the designer at the next level down. Their Figure I is based on the infamous "Waterfall Diagram" (retroactively named) of Royce's 1970 paper Managing the Development of Large Software Systems (Royce, 1970) : (First off, let me state clearly - I've read the Royce paper, yes I know he wasn't arguing for phase-gated development, yes I know he didn't coin the term waterfall, and yes I know the people most angry at the title of the article won't read this far and will still comment that I am ignorant of all the above. Back to the article.) So what impressed Bell & Thayer was not some notion of a rigid gated process, but just how clearly the top-down software development process had been illustrated, showing clearly that higher designs naturally flowed down to lower. Indeed they took it for granted that requirements development must be iterative; writing on page 6: The importance of continually reviewing requirements for their impact on design solutions is obvious, especially in a top-down environment where each iteration through the development cycle affords the opportunity to deal with changing or incorrect requirements, and to factor these changes into the evolving design. So if phase-gating gremlins are not an integral part of waterfall (more lies from the Agile-Industrial complex), what's left is what Bell & Thayer immediately zeroed in on: Top-Down design. The papers I am drawing from were written in the 70s, and many of the terms may be strange to us today. So let's break down a modern top-down design into three phases: REQUIREMENTS DESIGN DEVELOPMENT Note how inherent direction of the whole thing. If there's a change in the design, it likely means more development work. If there's a change in requirements, then the design must change, and hence more development - it quite literally flows as surely as water does. This is of course a heuristic and not an absolute rule; in a well functioning organisation with effective testing an issue in development can definitely propagate its way up and cause higher level designs to be debugged. From Bell & Thayer, page 5: However, reports documenting requirement-related problems or needed change can be generated throughout the development cycle, not just during appropriate requirement reviews. In fact, such information also comes from the design phase and as late as the formal testing phase... While the principal activity may be software design or testing, documented problems at any point in the development cycle may identify the source of the problem as any previous activity, e.g., a requirement error documented on a software problem report written during formal testing. Does it then follow that their waterfall is purely circular? I argue not - there's a directionality to it, and design flows downwards. All software is judged by problems it solves in the real world, how it is to use, and how well developed it is - in that order. That issues lower in the waterfall (ie, slow unmaintainable code) can affect things further up does not change this. Rarely will a technical development issue change high level requirements - there is a direction, a gravity drawing us towards the implementation, and waterfall describes it. As Fred Brooks said in No Silver Bullet : The hardest single part of building a software system is deciding precisely what to build...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. The agile manifesto is a slippery piece of work - hinting at much and saying little - but I think even they acknowledge this: Anyone who's been a contract dev on a day rate will confirm that changing requirements are absolutely a thing to welcome. Bell & Thayer's "waterfall of development activities" exists, whether a team produces artefacts for it or not. A failure to acknowledge a phenomenon does not make it go away. We are told to judge agile in its purist form, and in the most charitable way; but the ideas behind waterfall have a clarity of thought and a clearness of metaphor that far surpasses anything in that dreary "manifesto". So, why not carry the name proudly? Waterfall is just top-down iterative development, and that is an sensible, effective approach. A brave new world of waterfall coaches, waterfall consulting and waterfall conferences await us, if only we would reach out our hands to grasp it.

agile Agile programming Programming business Business
0 views
Lambda Land 2 weeks ago

Be Careful What You Measure

Goodhart’s Law states that, “when a measure becomes a target, it ceases to be a good measure.” A corollary to this that I thought of today is: Only measure that which you are comfortable turning into a target. Some targets are useful, some are not, and they often have unforeseen consequences . So be very careful with what you measure: what you measure easily becomes a target, and what you make a target changes incentives. I think this is a useful way to steer organizations: you can often tell what an organization is going to do by considering its access to information as well as its incentives . 1 If you alter what kind of information an organization has, you will naturally alter its behavior as well. This isn’t a silver bullet to all the ills of perverse incentives by any means. But I think there is some good you can accomplish by keeping this in mind. I once worked for a company where of the higher-ups posted in the general engineering channel a celebration that, relative to the previous year, commits were up 2×, pull requests were up 5×, and lines of code changed were also up 5×. This disturbed me. It’s been well known for decades now that tracking lines-of-code added is a great way to torpedo the quality of your software: if programmers are paid by the line, you will quickly have an unmaintainable mess on you hands. Therefore, why celebrate these numbers? I called this out as a bad idea . I asked, if we’re submitting 5× the PRs, does that mean that we understand our codebase ⅕ as well as we used to? The original poster backed down a little bit and said that they were happy to see that we were experimenting with AI so much. That’s a fair thing to celebrate, I think, but that was not what they said originally. These numbers are easy to measure—I think there might be a place on GitHub where you can see statistics like the above for an organization. It’s tempting to make a target out of figures like that. The best way to avoid that happening is to not measure it in the first place . What I said was appreciated—several of my fellow engineers thanked me personally. I doubt this will be the last time they will have to fend off metric encroachment. What you choose measure has consequences: be careful. I heard this first from Mike Munger . ↩ I heard this first from Mike Munger . ↩

business Business agile Agile Github
0 views
Martin Fowler 3 weeks ago

Healthy Feedback

Human collaboration, like most things, improves with feedback. But it's not obvious how to make feedback effective. Anuja Karnik and Sumeet Gayathri Moghe pass on a bevy of tips for healthy feedback, based on the principle that both praise and criticism should be seen as positive.

career Career agile Agile
0 views
Dan Moore! 5 months ago

Meetings are forcing functions

A recurring meeting serves as a powerful forcing function for long-running projects. Many organizations face a common challenge: a complex project that requires effort and perspectives from multiple people, moves through definition and execution phases, and unfolds over weeks, months, or years. But one where the tasks to accomplish the project are not anyone’s full-time job. Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list. One effective solution is to schedule a standing meeting. Whether in person or video, it doesn’t matter. The key to making progress is maintaining an agenda and, critically, opening each meeting by reviewing the to-dos from the previous one. This creates pressure on everyone to make progress. When people know they’ll be asked “what’s the status of X that we talked about last wee?” at an upcoming meeting, it is easier, though not easy, to carve out time for that work amid the daily chaos. This approach works across organizational boundaries too. If you’re a consulting firm, a regular cadence of meetings with your client is especially valuable. You’re  motivated to deliver., but people on the client’s team may be less so. A meeting where you consistently show progress while they haven’t made any creates gentle but real accountability. If you’re managing a large, complex, multi-person effort, consider the standing meeting. As far as schedule, weekly, bi-weekly, or monthly all have worked for me in the past. Pick whatever fits the urgency. Use a meeting as a forcing function to ensure people actually make time to move the project forward.

business Business agile Agile
0 views
Allen Pike 7 months ago

Launch Now

Inside us are two wolves. One wolf wants to craft, polish and refine – make things of exceptional quality. The other wolf wants to move fast and get feedback now. The two wolves don’t always get along. For years, I’ve balanced this by working toward exceptional products but constantly collecting private feedback along the way. Then, once we’ve built something excellent, something worthy of attention, we launch it to the world with appropriate fanfare. Videos, marketing campaigns, polished onboarding, and so on. “Here’s something worth trying, we think you’ll really like it.” This totally works. At least, it works as a path to eventually ship high-quality software. Polished, usable, even delightful software. But when it comes to building something people will pay for, it’s neither reliable nor fast. Our first product at Forestwalk was a developer tool – a platform for building and running evaluations of LLM-powered apps . We learned a ton building it, but after a few months – as we approached our first pilot projects – feedback from demos and potential first customers convinced us that this was the wrong path. It was more likely to lead us into a lifestyle business than something big. So we pivoted. We spent a few weeks building a prototype a week, showing demos, doing customer research, and found a second promising product path. Our second product was a productivity tool – a work assistant that could capture, organize, and rationalize teams’ tasks . We learned a ton building it, but after a few months – as we approached a public beta – feedback from private testers and our investors convinced us that this was the wrong path. It was more likely to lead us into a lifestyle business than something big. So we pivoted. The third time purports to be the charm. But at the same time, doing the same thing over and over typically gets the same results. We need to build something profoundly useful, something people really want. We can’t keep hiding away, sending out private demos and prototypes, not fully shipping anything! So, we decided to push harder into the discomfort of showing our work early. Just before Christmas, we decided to commit to something and work towards getting it shipped. This third product is codenamed Cedarloop 1 . It’s a realtime meeting agent. Unlike AIs that passively listen in to meetings and just write up notes after the fact, Cedar joins calls and uses “voice in, visuals out” to screen-share useful observations and perform routine tasks live during a Google Meet or Zoom meeting. The vision is to build a kind of agentic PM assistant. It can respond within a second of you talking 2 , which – when it works – feels like magic. We’ve been learning a lot building it. Recently, we started working with an excellent designer here in Vancouver who was keen to get going. I’d like to do some user testing. What do people say when you let them try it? Well, obviously it’s so early right now. They won’t like it. The inference and onboarding need more work. But we’ve been doing research about problems, needs, willingness to pay, and things like that. Sure… but we should also let people try it. What if we launched now? Well, obviously we can’t launch now . I mean… obviously. Launching now would be embarrassing. It’s not my brand to launch something publicly that’s not ready. On the other hand… I keep a printed copy of Y Combinator’s list of essential startup advice on my desk. And if you know YC, you’ll know that the first point of advice is “Launch now”. Only last month I was interviewing Brett Huneycutt, Wealthsimple’s co-founder . He had a lot of great stories, but one that sticks out is that even as a $10B company, they prioritize launching “now”, for as close as they can get to that definition. It’s not just about speed: a rapid feedback loop is a core ingredient in getting to quality. So we launched now. As of today, people can check out our research-preview realtime meeting agent at Cedarloop.ai . With luck, they’ll report issues, inform what we should prioritize next, and tell us what problems they’d love to have automated away. We’re only a few hours in, and yep – people are reporting issues. Linear integration had an OAuth issue. Login didn’t work in social-media webviews. We’ve been so focused on the desktop experience that we’ve let the mobile layout get janky. This is embarrassing! But also, there’s signal. People are trying the Linear integration. Our desktop-focused app is being discovered on mobile. Folks care enough to click at all. And in a week or so, we’ll have a smoother onboarding flow than we would have gotten to with weeks of private user tests. So it’s worth the pain. We’re going to take the feedback, follow the signal, learn and re-learn, and do better. We’ll use it to forge the best damn live agent ever – or, if the feedback peters out, we’ll know we’re on the wrong path, and find the right one. In the meantime, there’s a lot to do. 3 Back to work! This is not a good name yet. For example, sometimes iOS mishears “Hey Cedar” as “Hey Siri”. But part of our move-fast strategy is to worry more about names once we’ve proven something has traction. At that point, we’ll put in the work to give it the right name – and eventually rename the company after it. ↩ It’s fascinating how much you can do to get LLM response times down. Our first prototype often took over 8000ms to respond, which doesn’t feel live at all. Once we got it under ~1200ms, voice-in-vision-out suddenly felt alive – a step change. We have a lot of work planned to get Cedarloop even faster and much more reliable, which I’m keen to write about when I can. ↩ Speaking of having a lot to do: if you’re an experienced product-minded developer in Vancouver who would be excited to iterate and build out realtime agents using LLMs and TypeScript, we’re hiring a Founding Engineer . Just sayin’. ↩ This is not a good name yet. For example, sometimes iOS mishears “Hey Cedar” as “Hey Siri”. But part of our move-fast strategy is to worry more about names once we’ve proven something has traction. At that point, we’ll put in the work to give it the right name – and eventually rename the company after it. ↩ It’s fascinating how much you can do to get LLM response times down. Our first prototype often took over 8000ms to respond, which doesn’t feel live at all. Once we got it under ~1200ms, voice-in-vision-out suddenly felt alive – a step change. We have a lot of work planned to get Cedarloop even faster and much more reliable, which I’m keen to write about when I can. ↩ Speaking of having a lot to do: if you’re an experienced product-minded developer in Vancouver who would be excited to iterate and build out realtime agents using LLMs and TypeScript, we’re hiring a Founding Engineer . Just sayin’. ↩

ai AI typescript TypeScript business Business agile Agile
0 views
iDiallo 7 months ago

We Need Process, But Process Gets in the Way

How do you manage a company with 50,000 employees? You need processes that give you visibility and control across every function such as technology, logistics, operations, and more. But the moment you try to create a single process to govern everyone, it stops working for anyone. One system can't cater to every team, every workflow, every context. When implemented you start seeing in-fighting, projects missing deadlines, people quitting. Compromises get made, and in my experience, it almost always becomes overwhelming. The first time I was part of a merger, I was naïve about how it would go. The narrative we were sold was reassuring. The larger company was acquiring us because we were successful. The last thing they'd want to do was get in the way of that success. But that's not how it went. It doesn't matter what made you successful before you join a larger organization. The principles and processes of the acquiring company are what will dominate. Your past success is acknowledged, maybe even celebrated, but it doesn't protect you from assimilation. One of the first things we had to adopt was Scrum. It may be standard practice now, but at the time it was still making its way through the industry. Our team, developers and product managers, already had a process that worked. We knew how to communicate, how to prioritize, how to ship. Adopting this new set of ceremonies felt counterproductive. It didn't make us faster. It didn't improve communication. What it did do was increase administrative overhead. Standups, sprints, retrospectives, layer after layer of structure added on top of work that was already getting done. But there was no going back. We were never going to return to being that nimble, ad hoc team that could resolve issues quickly and move on. We had to adopt methods that got in the way. Eventually, we adapted. We adopted the process. And in doing so, we became less efficient at the local level. A lot of people, frustrated by the slowdown, left for other opportunities. But as far as the larger company was concerned, that was acceptable. Our product was just one of many in their portfolio. Slowing down one team to get everyone aligned was a price they were willing to pay. It wasn't efficient, but it was manageable from their perspective. The math made sense at the organizational level, even if it felt like a loss from where we were standing. I understand that logic. I just don't think it's the best way forward. Think about how a computer works. A CPU doesn't concern itself with how a hard drive retrieves data. Whether it's spinning magnetic disks or a solid state drive, the internal mechanics are irrelevant to the CPU. All it knows is that it can make a request, and the response will come back in the expected format. If the CPU had to get involved in the actual process of fetching data, it would waste enormous processing power on something that isn't its concern. Organizations can work the same way. Rather than imposing a single process across every team, a company can treat its departments as independent components. You make a request, the department delivers an output. How they produce that output like what tools they use, how they run their meetings, how they structure their work, that shouldn't be a concern, as long as the result meets the requirement. There are places where unified processes make sense. Legal and compliance, for example, probably need to be consistent across the whole organization. But for how individual teams operate day to day, autonomy is often the better choice. Will every team's process be perfectly aligned with every other team's? No. But they'll actually work. And the people doing the work will be far less likely to walk out the door. Sometimes in large organizations, it's important to identify which process works, and which team is better left alone.

agile Agile business Business
0 views
Zak Knill 7 months ago

If code is cheap, intent is the currency

Apparently writing code is cheap now . So since the barrier to producing code is gone, the intent behind the code is the most important bit. Intent is the new scarce resource, and commit messages are where that intent lives. Agents are still, for now, working inside human processes. The software development lifecycle (I’m getting flashbacks to every agile coach ever!) is still the same: we still have commits, pull requests, code review. We still have humans responsible for the agent’s output. But generating the code is cheaper, so the code review carries more of the weight and responsibility for good code .

ai AI programming Programming agile Agile
0 views
Martin Fowler 7 months ago

Bliki: Host Leadership

If you've hung around agile circles for long, you've probably heard about the concept of servant leadership , that managers should think of themselves as supporting the team, removing blocks, protecting them from the vagaries of corporate life. That's never sounded quite right to me, and a recent conversation with Kent Beck nailed why - it's gaslighting. The manager claims to be a servant, but everyone knows who really has the power. My colleague Giles Edwards-Alexander told me about an alternative way of thinking about leadership, one that he came across working with mental-health professionals. This casts the leader as a host: preparing a suitable space, inviting the team in, providing ideas and problems, and then stepping back to let them work. The host looks after the team, rather as the ideal servant leader does, but still has the power to intervene should things go awry.

business Business agile Agile career Career
0 views
Martin Fowler 9 months ago

Stop Picking Sides: Manage the Tension Between Adaptation and Optimization

Jim Highsmith notes that many teams have turned into tribes wedded to exclusively adaptation or optimization. But he feels this misses the point that both of these are important, and we need to manage the tension between them. We can do this by thinking of two operating modes: explore (adaptation-dominant) and exploit (optimization dominant). We tailor a team's operating model to a particular blend of the two - considering uncertainty, risk, cost of change, and an evidence threshold. We should be particularly careful at the points where there is a handoff between the two modes

business Business agile Agile
0 views
Hugo 9 months ago

Alignment, Autonomy and context

Over the years, I've met and observed teams that were competent and yet failed: working on the wrong priorities, sometimes working on the right objectives, but with unsuitable solutions, sometimes working with no priorities at all. The root cause of these problems can be articulated around these 3 words: autonomy, alignment, and context . If these words seem relatively simple to understand, in practice, their implementation is not trivial. How do you ensure that everyone in a team is trying to solve the same problems? What does autonomy mean within a group, and what are its limits? Perhaps you've heard the term "empowered teams"? And thought it was yet another new consultant concept? The expression gained popularity via the book Empowered by Marty Cagan . In simple terms, an empowered team works on a problem to be solved, as opposed to a feature team which works on a list of functionalities (the famous roadmap). We also speak of a team that prioritizes outcomes (impacts) over outputs (deliverables). The first thing I'd like to stress is that this isn't just a topic for product managers. Any senior person in Engineering should be involved in decision-making, for example : I'm writing this chapter for any technical leader looking to create impact. To do this, we'll see that creating autonomy, alignment and knowing how to communicate the context are levers for achieving this. Here, as a Tech Leader you can be in two situations, but often in both at the same time: To tackle this subject, I'm going to start from a drawing by Henrik Kniberg about alignment and empowerment. "Empowered teams" being the teams in the top right-hand corner. This drawing is part of a keynote given in 2016 that I invite you to watch. In this keynote, it's about a group, whose goal is to cross a river to settle on the other side of the bank. The lower-left corner shows a group with little autonomy, no alignment and no precise directions. No one in this part of the quadrant has taken the initial problem of crossing the river personally. The symptoms of such an organization in a technological context : What can be done about it? It's a tough job on this part of the quadrant. Even before talking about autonomy, the first issue will be to get people to agree on a common goal. The role of a tech leader is to get close to the business, or its closest representative, and understand the issues that need to be addressed. In this type of organization, the business is often far away and/or difficult to access. Breaking the distance can be difficult, and is not part of the company's culture. Technique and "best practices" are likely to be the least of your worries in this context, as the importance of connecting Engineering to the business is paramount. If we move to the right, we come across organizations made up of individuals or groups of individuals, each of whom has defined objectives, but all of which are different. If the group's objective is to cross a river, everyone is working on different things: some are growing vegetables, others are fishing, and a few leaders are wondering whether someone is working on crossing the river. There's a misunderstanding of autonomy here. Autonomy does not mean independence. A team that decides its priorities in its own corner doesn't make an impact, or does so by accident, and this success is hard to repeat many times over. And this doesn't mean that individual groups can't be highly effective. Unfortunately, impact is measured in global terms. The symptoms of such an organization in a technological context: What can be done about it? The observation is fairly similar to the previous one, but the work will be less arduous due to the highly entrepreneurial nature of the company. Here, the tech leader will be able to rely on committed teams. We'll need to work on alignment. But let's define this notion a little better. Alignment defines the ability of a group to all seek solutions to the same problem. Objective: A European company decides to enter the US market. Each team will seek to contribute to the same objective. However, in the drawing in the upper left corner, we can see a clear alignment without autonomy. One or more leaders can decide exactly what needs to be done to achieve an objective. The leader explicitly asks to build a bridge across the river. This mode of operation can be very effective, especially on a small scale with a visionary leader. But scaling up can cause problems, as the visionary leader can't spread out across the company and follow all the decisions. On several occasions, I've observed companies with very good leaders, but with great difficulty in managing rapid growth. They recruited people who were more junior than they were, more capable of carrying out a task than making decisions. These people then failed to scale up in the time available. Symptoms of such an organization in a technological context: What to do about it: If you're a tech leader, one of your responsibilities is recruitment. You have to recruit people who are better than you in certain areas. You have to learn to share your legos . The second important thing is to get out of the vicious circle: At stage 2, you have a major responsibility for coaching/mentoring to educate and provide the necessary context for more effective decision-making. If you're a tech leader, but you're in a situation where the work is delegated to you, you'll need to show that the team can be autonomous. To do this, two things are important: In our example above, a group that chose to build a catapult to hurl individuals to the other side would be showing a certain lack of understanding of the effect of gravity on human bodies :) Hopefully, the initiative would be stopped. Don't be the one to suggest the catapult . Bad: there are too few of us in the team, so we can't finish the project on time. Good: given the size of our team and our current speed, I've decided to cut back on some of the functionalities to meet the deadline. Bad: We're drowning in support. The team can't deliver project A on time. Good: We carried out a support analysis and noted a sharp increase in support cases linked to a bug in a recent feature. We decided to assign one person for a week to fix this bug and regain velocity on project A. Before I talk about the last quadrant, I need to talk a little about the "context". "Lead with context, not control" is a quote you'll find in the excellent book "No rules rules" by Erin Meyer and Reed Hastings. For a person or a group to make a good decision, they need to know the whole context. If we go back to our group, which has to cross a river, we lack the context to propose initiatives. Maybe we have to cross the river to find food. In which case, why didn't we decide to settle on this side? The leader failed to mention that we're in the territory of another tribe who has asked us to leave before autumn. Okay, and if the leader had told us that this tribe wasn't against trading with us after all, having a bridge would probably be more interesting in the future than just building a boat. Having the context allows you to make the right decisions. And in the corporate world, there are plenty of occasions when you neglect to give the full context, sometimes for the sake of speed, sometimes to protect your team, sometimes because you've forgotten. But without context, you can't expect people to make the right decisions. Context gives you the constraints that will enable you to propose the most appropriate technological solution. In this corner of the quadrant, the objective is clearly defined, such as crossing the river. The constraints are known, and each group is invited to contribute to the common goal. In theory, this is the most efficient type of organization, especially at scale. I'd like to point out two pitfalls at this stage: It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do. You have to accept the unexpected, accept that the solutions you come up with may not be the ones you originally imagined. If a group suggests crossing the river with a boat or a tunnel, or has spotted a ford a hundred meters downstream, it may be different from what you had in mind, but it may be more effective. Accept that not everything is as it seems in your head. BUT, if there are several groups working, one on building a tunnel, another on building a bridge, another on building a boat, you've got a problem. If everyone is working on the same problem with different solutions, that's also a form of misalignment . Again, autonomy doesn't mean independence, and there needs to be regular discussion around the initiatives launched to ensure overall coherence. Don't be the one working on creating a tunnel while everyone else is trying to build a bridge. Certain methodologies, such as OKRs for example, help to materialize this periodic discussion. Objective: The product should enable the acquisition of 10,000 prospects in the USA. Quarter 1 initiatives: Quarter 2 initiatives: The coherence of the initiatives is linked to a discussion at the beginning of the quarter of what each group has come up with to contribute to the initial lead acquisition objective. This step, designed to ensure the coherence of initiatives, can be found in many methodologies: I must stress once again that autonomy does not mean independence. If, during these discussions, a decision is made to favor a bet, and it's not the solution you had in mind, too bad but you have to commit to this decision. This is the famous "disagree and commit" . And that doesn't take anything away from team autonomy. Teams can be the driving force behind initiatives to solve a given problem, but in the end, we'll be looking for alignment. Otherwise, we're back in the bottom right quadrant. If your aim is to create more autonomous product teams, you may come up against the following difficulties: These 3 subjects create deadlocks. A good PM and/or Tech Leader will be reluctant to join an organization where he/she feels a lack of autonomy. Management will find it hard to trust a team that they don't feel is business-oriented enough. Top management who don't have confidence in a team will continue to demand a high degree of predictability in development via detailed roadmaps. As a Tech Leader, you have your hands on several levers that I've already covered in the first chapters: The aim of all these actions is to increase the trust placed in Engineering's actions. This confidence will be transformed into the delegation of autonomy . Would you say that you have all the constraints in mind for your current projects? How much time do you spend explaining the context to the people who work with you? What is your team/department's objective for the year? How are you contributing to this objective this quarter? an empowered team's mission is to work on acquiring new users a "feature team" has to come up with a sponsorship program an "empowered team" is tasked with improving the developer experience by reducing dev cycle times a feature team is tasked with implementing a new CI (continuous integration) solution. avoiding the construction of unnecessarily complex solutions, demonstrating a misunderstanding of objectives checking that these priorities are built with the right constraints in mind ensuring that these priorities contribute to the group's objectives. the person seeking to develop his or her group's autonomy the person who belongs to a group with limited autonomy, and is seeking to gain independence. reaction-only teams, i.e. whose work is driven by support and bugs, upgrades to end-of-life components, and so on. no hyper-clear objectives, but a kanban (a big todo list) that feeds itself organically micromanagement, with tasks assigned by a manager/project leader a technical team that works in isolation from users, often in supplier mode for a team that defines the product, but itself far from the business. several groups work on defined topics, but without collaboration with other teams. a large number of projects are underway, stretching out over months. This is linked to the "one-man army" phenomenon: if a single person can move fast, he or she ends up burning out faster than a larger group. This slowness makes teams weary, as they continue to pile new subjects on top of the list. the multiplicity of topics creates vagueness throughout the organization, which becomes a black box for the rest of the company the perceived impact is low The sales department will invest to open a sales office in the USA. The finance department will open a subsidiary in the USA and modify its invoicing model to comply with current regulations. The engineering department will study how to reduce product latency through a better geographical distribution of its infrastructure the leader is the most experienced member of the group, with a significant gap between them there is a strong imbalance between junior and senior staff, to the detriment of the latter the team is not involved in decision-making, and the backlog is fed by a single person the people I work with don't make the right decisions or don't know how to make decisions, so I step in to make them for them for the sake of speed I don't spend much time on the explanation the people in question end up concentrating more on their expertise than on decision-making. Develop your business understanding . You need to step outside the team to better understand the challenges and constraints of the company and/or your customers. Develop your decision-making skills. To re-establish the symmetry of exchanges with your management, you need to keep one thing in mind: you need to provide more solutions than problems . You won't be trusted if you only come up with problems to solve, and your discussions will systematically turn into basic reporting, so you'll have to make choices. Team A works on improving SEO through multi-domain management and regionalization. Team B sets up several new domain names for multi-domain management Team C works on SEA to refine geographic targeting of campaigns. Team A works on a sponsorship program Team B works on sharing mechanisms on social networks Team C works on affiliation mechanisms The objective is defined in advance. Teams propose initiatives to contribute to it After discussion, a set of initiatives is chosen. in OKR via the OKR Quarterly review fixing appetites in the ShapeUp method the construction of "bet boards" by Henrik Kniberg Program Increment Planning in SAFe recruitment. To get started, you need very good PMs and Tech leaders who have an entrepreneurial mindset as well as a technical one. Transformation is all about people. top management buy-in and a change of mindset are essential. They must agree to delegate the "how" to product teams, and focus on the "what" (objectives). And that's a lot harder than it sounds. Many say they want to move to autonomous product teams, but are very frustrated at not being able to tell them what to do agreeing to abandon traditional roadmaps in favor of strategies based on objectives (OKR or other, it doesn't matter). Develop your understanding of the business Measuring everything Know how to prioritize Create time for ideation Know how to communicate Give away your legos and other commandments for scaling startups No rules rules keynote from Henrik Kniberg en 2016 Empowered from Marty Cagan

agile Agile business Business
0 views
Nick Khami 9 months ago

Replace Your Standup with a Todo List

Note: You can watch me write this blog post on video here on x.com! Standups create anxiety. You hoard updates during the day because you need content for the meeting. You forget your blockers. You adjust your schedule to be in early, even if you work better at night. I ran into this when I started my company. People join startups to escape corporate bureaucracy. When I tried to introduce morning standups, the early hires pushed back hard. It didn't feel like a startup move to them. Given that, I went back to the drawing board to break down the actual utility of the meeting. A standup exists to distribute context so a team can parallelize work and maintain synchronization. If that's the goal, you don't need a meeting. Here's what one of those messages looks like. As you work, you come back and edit the message to cross things off. Add timestamps if you want to track how long things are taking you or otherwise provide more context. That's it. Everyone sees what you're working on. No meeting required. Post your task list in a channel like first thing in the morning Edit the message to cross off tasks as you complete them throughout the day

agile Agile
0 views
Chaotic-Good Engineering Management 9 months ago

Let Your Teams Own Their Processes

When it comes to team operating principles, I'm sure we've all encountered the leader who values uniformity seemingly for the sake of it. Every team has the same ceremonies, on the same days. Status reports are via a templated slide deck with the same format and the same information as all the other teams. I get it, this can be comforting. I worked at a place like that. Every team used Scrum, estimated with story points, sprints all started and ended on the same day, and the last day of the sprint featured a full day of sprint-reviews presented via PowerPoint decks that all basically looked the same save for maybe some screenshots of whatever feature the team was working on. One of my teams, however, was really struggling. Because of the nature of their scope of ownership and who their stakeholders were, they could rarely get through a sprint without some new information or requirements coming to light that either injected new, urgent work or made some of the work they had planned pointless. Going by the book, this should have caused us to cancel nearly every sprint (we didn't, we just soldiered on). During a retro, we all concluded that this team would be better served by using Kanban and tracking Cycle Time as the primary metric for doing estimations. The story points method was proving pretty wasteful because we'd often break down and estimate work that we didn't end up doing, then have to point some new work on the fly mostly because we needed the stats for our sprint review deck. I could talk all day about how we could have handled things differently, but that's not the point of this post. The upshot is, the proposal to switch to Kanban was shot down by the execs since it proposed reporting cycle time and throughput metrics rather than the points-based velocity they were used to. (We agreed to keep doing "Sprint" reviews on the same cadence even though we weren't planning to do sprints). The perceived control they got from seeing a graph showing whether or not velocity was going up or down was too valuable to them to give up and having two systems of measurement was a bridge too far, I guess. Ultimately, a path that could have improved the satisfaction of both the team and its stakeholders was cut off to them. This is the failure mode that uniform process creates. A concept I first heard from Jean-Michel Lemieux when he was leading engineering at Shopify was creating an "API For Teams". Like an API in software, the API For Teams defines a contract for interfacing with the rest of the business, but leaves the implementation up to the implementors. A good basic interface would be something like: This information should be available any time, with reasonable expectations on around staleness for things like estimates and health. (Put it in a Slack integration or some other info delivery system and people can even query it without interrupting anyone). In an organization with good, aligned incentives , something like that can give stakeholders the information they need to make decisions without over-specifying the processes in a way that removes so much autonomy from the team that they cease taking any interest in finding ways to improve. The less you demonstrate that you trust your team, the less they'll try. The API concept lets teams decide for themselves what processes best match their skills, the type of work they do, the way they deploy software to customers. I've had teams choose to switch to Kanban from Scrum because in the world of continuous delivery they found the starting and stopping of sprints was a weird artificial construct that caused things like code reviews to bunch up until later in the sprint. I've had other teams fully embrace sprints because they could divide up a couple week's work among themselves and mostly stay heads down without a lot of coordination overhead. No one system or way of working ever emerged as "the best" in a way that I would have imposed it on every other team. Keep the API minimal and be mindful that you're not adding things on to the point where you've dictated the implementation. This is where the API concept shines. The information that's expected should be clear, non-negotiable, and where metrics are involved, not easily gamed. The incentives should be aligned around extracting truthful, honest data. Don't give teams the incentive to lie, don't punish them if they report out data you don't like. Try to help when teams are struggling, and encourage a culture of sharing so that when one team finds something that works, they can share that with other teams who might also benefit. For their part, teams need to be accountable to the outcomes, not just providing the data. If they keep missing their target dates, that's a contract violation and they probably need to change their implementation. They should hear that. Again, I understand the comfort that uniformity can bring but taking it too far will be stifling and counterproductive. On the flip side, getting too into the details s a bad use of a leader's time and they'll never have the amount of information needed to make decisions that the team doing the work has. The chaotic-good manager embraces some ambiguity and loss of control and in exchange they'll often find they get a better outcome. " Tangye instrument panel " by Elsie esq. is licensed under CC BY 2.0 . Like this? Please feel free to share it on your favourite social media or link site! Share it with friends! Hit subscribe to get new posts delivered to your inbox automatically. Feedback? Topics you want to hear about? Get in touch ! Project Current Project or Deliverable Health of the project. Phase of the project (preview, beta, GA, etc) Current estimate for next delivery People Open roles on the team Who is on-call and/or handling support escalations? Risk Current level of Planned vs. Unplanned work. Any escalations from their last retrospective that need addressing.

agile Agile
0 views
The Coder Cafe 11 months ago

Speed vs. Velocity

☕ Welcome to The Coder Cafe! Today, we discuss the difference between speed and velocity in team productivity, illustrating that tracking speed alone can be misleading. Get cozy, grab a coffee, and let’s begin! We often celebrate teams for moving fast. But speed alone can be a trap. A rush of fast changes that barely move the product toward the real goal shouldn’t count as a win. When we talk about team productivity, we should understand that speed ≠ velocity : Speed is how quickly a team ship changes. Velocity is speed with direction, the movement toward a defined goal. Let’s look at three teams to illustrate these definitions. Team A has ideal velocity. Each iteration is represented by an arrow: its length shows speed, and its angle shows direction. Every iteration moves the team consistently closer to the goal. Team A shows ideal velocity: steady speed and consistent direction. Team B has a speed problem. Each iteration is well-aligned (correct angle), but the team delivers too slowly (small length), resulting in a lower velocity. They finish only halfway to the goal. Team B has the right direction but low speed, so they only reach halfway to the goal. Team C ships as rapidly as team A (same arrow length). However, various factors such as frequent bug fixes and changing targets make their direction inconsistent. Despite high speed, their velocity is low, and they end only halfway to the goal, just like team B. Team C moves fast but changes direction often, so velocity stays low and progress stops halfway. As we can see, velocity requires both speed and direction. A team moving too slowly or in inconsistent directions will make little progress, even if they’re busy . Only when speed is high and direction is aligned do teams reach their goals efficiently. Measuring team speed isn’t useless, though. We can track speed by considering various metrics such as deployment frequency, average time in code review, or mean time to recovery (MTTR) following a production bug. These metrics are interesting to track and provide a certain perspective to understand a team's productivity. Yet, speed shouldn’t be the sole dimension to track. The danger of tracking speed only is that a team might become organized in a way to optimize short-term delivery . The team might focus on delivering many changes that, together, do not move the product in a meaningful way. Instead, teams should track speed and velocity. As we said, velocity is speed with direction. We already discussed metrics to track speed; what is missing is monitoring direction. Setting clear and factual objectives that align with the business strategy helps us track direction. For example: Payment success rate above 99 percent. Signup to activation above 50 percent within 7 days. Retention after week 4 is above 40 percent. The easier a metric is to measure, the easier it is to track the direction over time. One caveat is how to report progress. In a past team, we used to set OKRs (Objectives and Key Results) every semester. Some objectives were difficult to measure, so we tracked progress differently. Say we created 50 tickets and closed 45. In that case, we reported that we reached 90% of the OKR. That number said nothing about real progress toward the objective. Key results should be outcomes, not ticket counts. Something else to mention, I read here and there that we should track velocity by counting the number of story points delivered within a timeframe (e.g., during a sprint). I strongly disagree with this. Let me give an example: A team ships a first change ← 3 story points The team finds a bug and ships a fix ← 2 story points Later, the team learns the initial approach is not the best, so it ships another change ← 5 story points On paper, the team delivered 10 story points. That is only speed, though, not velocity. If we care about direction as well, the team only delivered a single feature. Story points measure effort; they don’t measure progress toward the objective. Speed is how fast we ship. Velocity is speed with direction toward a goal. The goal of a team shouldn’t be to reach high speed; it should be to reach high velocity, where rapid iterations translate into real system-level improvements. Tracking story points, for example, is a measure of speed, not velocity. Objectives tracking should use outcomes, not ticket counts. Reporting 90 percent of tickets done is not a good measure of progress toward the objective. Missing direction in your tech career? At The Coder Cafe, we serve timeless concepts with your coffee to help you master the fundamentals. Written by a Google SWE and trusted by thousands of readers, we support your growth as an engineer, one coffee at a time. Keeping a Mistake Journal Streetlight Effect Survivor Bias Sprint Velocity in Scrum: How to Measure and Improve Performance // The velocity definition I disagree with. ❤️ If you enjoyed this post, please hit the like button. 💬 What’s your take on speed vs. velocity? How do you measure velocity in your team? Leave a comment We often celebrate teams for moving fast. But speed alone can be a trap. A rush of fast changes that barely move the product toward the real goal shouldn’t count as a win. When we talk about team productivity, we should understand that speed ≠ velocity : Speed is how quickly a team ship changes. Velocity is speed with direction, the movement toward a defined goal. Team A has ideal velocity. Each iteration is represented by an arrow: its length shows speed, and its angle shows direction. Every iteration moves the team consistently closer to the goal. Team A shows ideal velocity: steady speed and consistent direction. Team B has a speed problem. Each iteration is well-aligned (correct angle), but the team delivers too slowly (small length), resulting in a lower velocity. They finish only halfway to the goal. Team B has the right direction but low speed, so they only reach halfway to the goal. Team C ships as rapidly as team A (same arrow length). However, various factors such as frequent bug fixes and changing targets make their direction inconsistent. Despite high speed, their velocity is low, and they end only halfway to the goal, just like team B. Team C moves fast but changes direction often, so velocity stays low and progress stops halfway. Payment success rate above 99 percent. Signup to activation above 50 percent within 7 days. Retention after week 4 is above 40 percent. A team ships a first change ← 3 story points The team finds a bug and ships a fix ← 2 story points Later, the team learns the initial approach is not the best, so it ships another change ← 5 story points Speed is how fast we ship. Velocity is speed with direction toward a goal. The goal of a team shouldn’t be to reach high speed; it should be to reach high velocity, where rapid iterations translate into real system-level improvements. Tracking story points, for example, is a measure of speed, not velocity. Objectives tracking should use outcomes, not ticket counts. Reporting 90 percent of tickets done is not a good measure of progress toward the objective. Keeping a Mistake Journal Streetlight Effect Survivor Bias Sprint Velocity in Scrum: How to Measure and Improve Performance // The velocity definition I disagree with.

business Business agile Agile
0 views
The Coder Cafe 1 years ago

Organic Growth vs. Controlled Growth

☕ Welcome to The Coder Cafe! Today, we will discuss the concept of organic growth vs. controlled growth. Get cozy, grab a coffee, and let’s begin! A few months ago, I was in a meeting discussing the state of a codebase and heard myself say: This codebase has grown organically. After reflecting on my own words, I began questioning myself: I don’t even know what organic growth really means and whether it is ultimately positive or negative. Discussing the concept with various colleagues, I noticed we had different interpretations. I also created a poll on X that went viral (# irony ), showing that most people see organic growth as something positive. If Perplexity is correct, the term organic growth was used first in Bushido: The Soul of Japan , published in 1899. The author, Inazo Nitobe, describes Bushido (aka the way of the samurai) as something that developed through organic growth rather than being the invention of a single person or the result of a single event. In other words, Bushido emerged gradually over decades and centuries as a collective experience, not the product of one individual. It’s easy to draw parallels with the many codebases we maintain at work. The older the codebase and the more developers it has had, each with their own vision of how the code should look. Differences in perception arise from factors like developers’ varied mental models based on the parts of the code they know best. Developers come and go, making changes, introducing biases about what the future should be, and after years, the codebase reflects hundreds or even thousands of such incremental changes. This is organic growth in software: incremental delivery driven by agile methodology that shapes codebases, often in a bottom-up manner. So, is organic growth good or bad? Let’s use the garden metaphor: imagine a public garden where anyone can plant whatever they want and wherever they want. Over time, sure, it’s colorful, but there’s little harmony, with a lack of overall guidance or direction: Now imagine we control what can be planted and where, and periodically review and rearrange what’s growing. Our garden will likely look harmonious and well-maintained: In my opinion, organic growth carries a somewhat negative connotation, implying a lack of direction, with systems growing out of ad hoc solutions and quick fixes rather than intentional design. So, how can we move from a messy garden to a harmonious one? By transitioning from organic to controlled growth. Controlled growth is the deliberate and reflective process of evolving a codebase. With controlled growth, we should also embrace progress that is not always perfect but consistently guided by shared patterns and standards, fostering sustainable, manageable, and harmonious development over time. Here are five main rules for controlled growth: Be consistent . Follow agreed conventions and standards to build maintainable and predictable codebases. Many standards aren’t explicit, so strive to follow even the implicit ones. For example, if an entity is consistently named X, don’t be a cowboy and name it Y; stick to X. Plan ahead for large changes. Think strategically and collectively about big transitions such as significant new features. Avoid chaos and technical debt by breaking ambitious changes into smaller phases, communicating plans early, and leveraging documentation assets such as design docs (see Explore Further section). Hold regular retrospectives. After major development milestones, gather the team to review what went well and what could improve. Retrospectives foster a culture of learning and continuous improvement, a strategic pillar of controlled growth. Apply the Boy Scout rule. Frequent changes are inevitable and often rushed under pressure. Remember: “Always leave the campground cleaner than you found it.” When making a pull request, spend a little time refactoring small bits, cleaning legacy code, removing dead code, or renaming variables. This keeps the garden harmonious over time. Build a team where everyone shares responsibility and speaks openly. Controlled growth shouldn’t fall only on tech leads; it should be everyone’s job. When all team members feel heard and share responsibility for the health and quality of the codebase, the team grows on a stronger, more sustainable foundation. Subscribe now Tidy First? // We already discussed organic growth in this post. Focus on Product Ideas, Not Requirements Cognitive Load Bushido: The Soul of Japan Design Docs at Google ❤️ If you enjoyed this post, please hit the like button. 💬 When you say a codebase grew organically, what do you mean? Leave a comment A few months ago, I was in a meeting discussing the state of a codebase and heard myself say: This codebase has grown organically. After reflecting on my own words, I began questioning myself: I don’t even know what organic growth really means and whether it is ultimately positive or negative. Discussing the concept with various colleagues, I noticed we had different interpretations. I also created a poll on X that went viral (# irony ), showing that most people see organic growth as something positive. If Perplexity is correct, the term organic growth was used first in Bushido: The Soul of Japan , published in 1899. The author, Inazo Nitobe, describes Bushido (aka the way of the samurai) as something that developed through organic growth rather than being the invention of a single person or the result of a single event. In other words, Bushido emerged gradually over decades and centuries as a collective experience, not the product of one individual. It’s easy to draw parallels with the many codebases we maintain at work. The older the codebase and the more developers it has had, each with their own vision of how the code should look. Differences in perception arise from factors like developers’ varied mental models based on the parts of the code they know best. Developers come and go, making changes, introducing biases about what the future should be, and after years, the codebase reflects hundreds or even thousands of such incremental changes. This is organic growth in software: incremental delivery driven by agile methodology that shapes codebases, often in a bottom-up manner. So, is organic growth good or bad? Let’s use the garden metaphor: imagine a public garden where anyone can plant whatever they want and wherever they want. Over time, sure, it’s colorful, but there’s little harmony, with a lack of overall guidance or direction: Now imagine we control what can be planted and where, and periodically review and rearrange what’s growing. Our garden will likely look harmonious and well-maintained: In my opinion, organic growth carries a somewhat negative connotation, implying a lack of direction, with systems growing out of ad hoc solutions and quick fixes rather than intentional design. So, how can we move from a messy garden to a harmonious one? By transitioning from organic to controlled growth. Controlled growth is the deliberate and reflective process of evolving a codebase. With controlled growth, we should also embrace progress that is not always perfect but consistently guided by shared patterns and standards, fostering sustainable, manageable, and harmonious development over time. Here are five main rules for controlled growth: Be consistent . Follow agreed conventions and standards to build maintainable and predictable codebases. Many standards aren’t explicit, so strive to follow even the implicit ones. For example, if an entity is consistently named X, don’t be a cowboy and name it Y; stick to X. Plan ahead for large changes. Think strategically and collectively about big transitions such as significant new features. Avoid chaos and technical debt by breaking ambitious changes into smaller phases, communicating plans early, and leveraging documentation assets such as design docs (see Explore Further section). Hold regular retrospectives. After major development milestones, gather the team to review what went well and what could improve. Retrospectives foster a culture of learning and continuous improvement, a strategic pillar of controlled growth. Apply the Boy Scout rule. Frequent changes are inevitable and often rushed under pressure. Remember: “Always leave the campground cleaner than you found it.” When making a pull request, spend a little time refactoring small bits, cleaning legacy code, removing dead code, or renaming variables. This keeps the garden harmonious over time. Build a team where everyone shares responsibility and speaks openly. Controlled growth shouldn’t fall only on tech leads; it should be everyone’s job. When all team members feel heard and share responsibility for the health and quality of the codebase, the team grows on a stronger, more sustainable foundation. Tidy First? // We already discussed organic growth in this post. Focus on Product Ideas, Not Requirements Cognitive Load Bushido: The Soul of Japan Design Docs at Google

agile Agile
0 views
A Working Library 1 years ago

Everything

It’s common to talk about Taylorism—the practice of so-called “scientific management” that’s most known for it’s reviled use of stopwatches—as if it were a thing of the past, as if we had somehow moved beyond it. But like a lot of coercive practices, Taylorism didn’t so much retire as rebrand. As workers rebelled against oppressive bureaucracies, the postindustrial work ethic shifted from work as a moral imperative to work as self-realization in a process that Nikil Saval grimly calls “ self-Taylorization .” In essence, the timekeeper was internalized. Whereas, for Taylorism, the self-organization, ingenuity, and creativity of the workers were to be combated as the source of all dangers of rebellion and disorder, for Toyotism these things were a resource to be developed and exploited. The total and entirely repressive domination of the worker’s personality was to be replaced by the total mobilization of that personality. Toyotism—contrasted with Ford ism, which adopted Taylor’s model—involved a practice where small teams of people would manage a limited amount of work-in-progress through communication with teams up- and downstream of their work. Versions of it were subsequently adopted in “agile” software development and have become so engrained in product organizations that they are often barely remarked upon; it’s just how things are done. But as with most just-so stories, it’s worth considering how it came to be—and who benefits from the way things are. [The head of training at Volkswagen] first explains that “transferring entrepreneurial skills to the shopfloor” makes it possible “largely to eliminate the antagonisms between labor and capital…If the work teams have great independence to plan, carry out, and monitor processes, material flows, staffing, and skills…then you have a large enterprise made up of independent small entrepreneurs, and that constitutes a cultural revolution.” That is, by offering “elite” status to some workers, and building a system in which they monitored their own work in excruciating detail, Toyota could keep the administrators in their offices while remaining confident that the same surveillance, operational focus, and company-first perspective would be maintained—this time by the workers themselves. Giving some workers permission to perform as entrepreneurs just meant they worked harder for the company even as they became convinced they were working for themselves . Men in stopwatches are unnecessary when the worker’s own conscience will do the job. And of course, that “elite” status is, by definition, scarce. It depends on other workers continuing to toil in the old, Taylorist ways, performatively monitored and repressed. (Gorz points out that at the time he was writing about Toyota, the workers organized under the entrepreneurial model represented a mere 10-15% of the workforce; the rest were subcontractors, who were “increasingly Taylorized” as they moved down the ladder.) And, more to the point, it depends on a system in which fewer and fewer people are employed at all. It could hardly be more clearly stated that the workers taken in by the big companies are a small “elite,” not because they have higher levels of skill, but because they have been chosen from a mass of equally able individuals in such a way as to perpetuate the work ethic in an economic context in which work is objectively losing its “centrality”: the economy has less and less need of it. The passion for, devotion to, and identification with work would be diminishing if everyone were able to work less and less. It is economically more advantageous to concentrate the small amount of necessary work in the hands of a few, who will be imbued with the sense of being a deservedly privileged elite by virtue of the eagerness which distinguishes them from the “losers.” Technically, there really is nothing to prevent the firm from sharing out the work between a larger number of people who would work only 20 hours a week. But then those people would not have the “correct” attitude to work which consists in regarding themselves as small entrepreneurs turning their knowledge capital to good effect. So the firm “largely…eliminates the antagonisms between work and labor” for the stable core of its elite workers and shifts those antagonisms outside its field of vision, to the peripheral, insecure, or unemployed workers. Post-Fordism produces its elite by producing unemployment; the latter is the precondition for the former. The “social utility” of the elite cannot, for that reason, be assessed solely from the angle of the use-value of its production or the “service rendered to users.” Its members can no longer believe themselves useful in a general way, since they produce wealth and unemployment in the self-same act. The greater their productivity and eagerness for work, the greater also will be unemployment, poverty, inequality, social marginalization, and the rate of profit. The more they identify with work and with their company’s successes, the more they contribute to producing and reproducing the conditions of their own subjection, to intensifying the competition between firms, and hence to making the battle for productivity the more lethal, the threat to everyone’s employment—including their own—the more menacing, and the domination of capital over workers and society the more irresistible. That is, the existence of an elite workforce—whether it’s workers managing a kanban process in a Toyota factory, or workers driving agile development at a product company—is predicated on an underclass of people who either work in less sustainable conditions or else are proscribed from work at all. The former has come into some awareness in recent years, as workers at Google and elsewhere have organized not only well-paid engineers and designers but also support staff and contractors who are paid in a year what an engineer makes in a month. Those very highly-paid engineering roles simply couldn’t exist without the people toiling in the support mines or tagging text and images for AI training —often dreadful work that’s barely remunerated at all. But what Gorz is calling out here is that isn’t only bad work that the elite work depends on—it’s also the absence of work. The “disruption” that the tech industry has so long prided itself on is just another word for “unemployment.” But there’s also a gesture here towards another way: the less that elite identifies with their work and with their companies’ successes, the more they admit of their own insecurity and of their collaboration in creating it, the less menacing that threat becomes, the more space is opened up for different futures. I am not saying, however, that post-Fordist workers cannot or ought not to identify with what they do. I am saying that what they do cannot and should not be reduced solely to the immediately productive work they accomplish, irrespective of the consequences and mediate effects which it engenders in the social environment. I say, therefore, that they must identify with everything they do, that they must make their work their own and assume responsibility for it as subjects, not excluding from this the consequences it produces in the social field. I say that they ought to be the subjects of—and also the actors in—the abolition of work, the abolition of employment, the abolition of wage labor, instead of abandoning all these macroeconomic and macro-social dimensions of their productive activity to market forces and capital. They ought, therefore, to make the redistribution of work, the diminution of its intensity, the reduction of working hours, the self-management of the hours and pace of work, and the guarantee of purchasing power demands inherent in the meaning of their work. Abolition is both destruction and reconstruction; in abolishing work, you become able to create it anew. For too long, “work” has been synonymous with waged work, with the work we long for an escape from. And everything else becomes the “life” that stands in opposition to work, as if work were somehow an equal to the life it sucks dry. But what if work was all the change we make in the world, with all the people we make that change with—colleagues and comrades, neighbors and friends, kin in all the kingdoms. What if work wasn’t only what we do at work, but all the ways that work moves out into the world, and all the work we do elsewhere—whether in our homes or in our streets. What if our work is all the things we give a fuck about ? What becomes possible then? View this post on the web , subscribe to the newsletter , or reply via email .

business Business agile Agile
0 views
Chaotic-Good Engineering Management 1 years ago

‘Labs’ teams, Skunkworks, and Special Projects: Beware

In a previous post , I talked about balancing ‘creating work’ and ‘destroying work’ such that the backlog does not become a huge mental burden on everyone to the point that it gives the impression that “the dev team is slow” or “we’re not making enough progress”. These are common themes at most of the places I’ve worked. One typical reaction to that is to pick a particular project and try to run it differently than “business as usual”. The projects chosen are often something other than just an incremental feature for the existing project. It might be an idea for an entirely new product or business unit or some grand re-imagining of the existing product. Often a founder is nostalgic for the days when they were coding entire features in a matter of days. Unencumbered by meetings, customers, existing code, internal stakeholders, compliance concerns, and everything else that comes along for the ride, they truly could crank out product in a way they’ve never seen all these expensive devs do since. To try to recapture some of that velocity that was ‘lost’ and get back to ‘the scrappy start-up days’, someone will inevitably propose cordoning off a special squad that can behave like they used to ‘back in the basement/garage’. They go by many names: Skunkworks , Tiger-Team, Startup-within-a-Startup, “Project Mayhem” and the like. I’m here to rain on the parade and tell you why this is almost always going to go poorly. If you’re an engineering manager or product manager asked to participate you should almost always push back against this type of idea. There is one exception though, which I will get to. The typical setup for a team like this:

agile Agile
0 views
underlap 1 years ago

Software convergence

The fact that such limits turn out to be members of the semantic domain is one of the pleasing results of denotational semantics. That kind of convergence is all very well, but it’s not what I had in mind. I was more interested in code which converges, to some kind of limit, as it is developed over time. The limit could be a specification of some kind, probably formal. But how would we measure the distance of code from the specification. How about number of tests passing? This seems to make two assumptions: Each test really does reflect part of the specification. The more distinct tests there are, the more closely the whole set of tests would reflect the specification. The second assumption, as stated, is clearly false unless the notion of “distinct tests” is firmed up. Perhaps we could define two tests to be distinct if it is possible to write a piece of code which passes one of the tests, but not the other. There’s still a gap. It’s possible to write many tests, but still not test some part of the specification. Let’s assume we can always discover untested gaps and fill them in with more tests. With this notion of a potentially growing series of tests, how would we actually go about developing convergent software? The key is deciding which tests should pass. This can be done en masse , a classic example being when there is a Compliance Test Suite (CTS) that needs to pass. In that case, the number/percentage of tests of the CTS passing is a good measure of the convergence of the code to the CTS requirements. But often, especially with an agile development process, the full set of tests is not known ahead of time. So the approach there is to spot an untested gap, write some (failing) tests to cover the gap, make those (and any previously existing) tests pass, and then look for another gap, and so on. The number of passing tests should increase monotonically, but unfortunately, there is no concept of “done”, like there is when a CTS is available. Essentially, with an agile process, there could be many possible specifications and the process of making more tests pass simply reduces the number of possible specifications remaining. I’m still mulling over the notion of software convergence. I’m interested in any ideas you may have. One of nice property of convergent software should be that releases are backward compatible. Or, I suppose, if tests are changed so that backward incompatible behaviour is introduced, that’s the time to bump the major version of the next release, and warn the users. I’m grateful to some good friends for giving me tips on LaTeX \LaTeX markup. [2] In particular, produces a “curly” epsilon: ε \varepsilon . Tom M. Apostol, “Mathematical Analysis”, 2nd ed., 1977, Addison-Wesley. ↩︎ I’m actually using KaTeX \KaTeX , but it’s very similar to LaTeX \LaTeX . ↩︎

programming Programming testing Testing agile Agile
0 views
Martin Fowler 1 years ago

Team OKRs in Action

OKRs have become a popular way to connect strategy with execution in large organizations. But when they are set in a top‑down cascade, they often lose their meaning. Teams receive objectives they didn’t help create, and the result is weak commitment and little real change. Paulo Caroli describes how high‑performing teams can work in another way. They define their own objectives in an organization that uses a collaborative process to align the team’s OKRs with the broader strategy. With these Team OKRs in place, they create a shared purpose and become the base for a regular cycle of planning, check‑ins, and retrospectives.

Scrum agile Agile business Business
0 views
Martin Fowler 1 years ago

Impact Intelligence, addressing common objections

Sriram Narayan concludes his article in impact intelligence by addressing five common objections to this activity, including slowing down, lack of agility and collaboration, and the unpredictability of innovation.

agile Agile business Business
0 views