# Development Methodology Doesn’t Matter (So Just Make Up Your Own) | LinearB Blog > Dev methodology… a lot of people are fussy about it, but we’re not. In fact, we made up our own. You should too. Here’s why and how. _This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._ [Blog](https://linearb.io/blog) / Development Methodology Doesn’t Matter (So Just Make Up Your Own) # Development Methodology Doesn’t Matter (So Just Make Up Your Own) ![Photo of Dan Lines](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Dan_Lines_3fb5152de2?_a=BAVMn6ID0) By [Dan Lines](https://linearb.io/blog/dev-methodology-doesnt-matter#dan-lines) | October 20, 2020 ![1_Blog_Methodology_1_1_8eeafdca35](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/1_Blog_Methodology_1_1_8eeafdca35?_a=BAVMn6ID0) I worked as a developer using Waterfall for exactly 9 months. I was 22 years old, and it was my first programmer job and first corporate environment. This place was _old school_. Like suit-wearing, personal-cubicle-type old school. Our CEO would hold all-hands meetings where everyone was required to stand the whole time, and he would call people up to give speeches at random because he believed everyone should be good at public speaking. ![I was 22 years old and it was my first programmer job and first corporate environment.](https://assets.linearb.io/uploads/2-Blog-Methodology-1024x488.png) _22-year-old Dan was NOT good at public speaking 🙂_ At one offsite event, the CEO designated me as the company’s “Complaint Manager.” During the 4-day event, employees were directed to give me their complaints. Of course, my friends dropped anonymous, hilarious complaints because they knew that, at the end of each day, I was going to be called up to the stage to repeat back all of the complaints. What?!? Super old school. One time, I was sent to work at a client’s office for a week, just so they could visibly see my team working on their project. And I mean that in the most literal sense. We didn’t have any meetings or recent project updates, they just wanted to make sure we were actually working. I never saw a single line of my code in production during the 9 months I spent working there. I actually remember learning that my project was finally being sent to QA for testing the week I left. After 9 months. Old. School. But I didn’t know any better at the time. I hadn’t heard of Agile development methodology yet, and no one told me we were using the Waterfall model. Luckily, I got out of there and found a job at Cloudlock where I learned about Agile and eventually worked my way up to VP of Engineering. But I’ll never forget my first year as a Waterfall programmer. So does methodology matter? Absolutely. But… ## **We Do Agile, But…** If you ask a software developer what methodology they follow, 95% of us will say, “We do Agile, but…”, usually followed by some version of Scrum or Kanban. While this sounds like a worldwide consensus, the reality is that every dev team I’ve worked on or managed has had a different software development process. During my time as VP of Engineering at Cloudlock, I looked after 75 developers across 5 teams. Each team had their own unique process. There were team leads who had been working in software development for 25+ years and others that had [just gotten promoted](https://linearb.io/blog/promoted-from-dev-to-team-lead-8-things-they-didnt-tell-me/). The younger leads liked having a more strict process to follow, whereas the more senior managers had a process they had customized over the years. All of those teams built amazing software even though their methods differed per team. Why? Because software development is not a zero-sum game. Just because one team is successful using Agile Scrum doesn’t mean another team will be less successful using Agile Kanban. Or Scrumban. Or SAFe. There’s a lot of options out there, so instead of focusing on methodology, I find it makes sense to start with what you’re trying to do and work backward. [![Summer Series. A 3Part Summer Workshop Series for Engineering Executives](https://assets.linearb.io/uploads/2023-summer-series-1024x538.png)](https://linearb.io/events/2023-summer-series/) Join our 3-part summer workshop series for engineering leaders ## **A Bespoke Development Process – The GigSmart Dev Team** I caught up with my friend[ Chris Downard, VP of Engineering at GigSmart](https://linearb.io/blog/our-dev-culture-is-based-on-bushido-samurai-code-my-interview-with-the-vp-of-engineering-at-gigsmart/), to chat about dev methodology. I was completely taken aback when the first thing he said to me was that he just got rid of teams in his software engineering department. _“You got rid of teams?!?”_ ![Meet Chris Downard, VP of Engineering at GigSmart](https://assets.linearb.io/uploads/3-Blog-Methodology-1024x488.png) I’m not personally strict about following this or that development method, but getting _rid_ of teams felt a little extreme. > Chris: “It naturally evolved that way. Because of this remote culture that we adopted very rapidly, we just found that the backend people tended to support each other on their backend tickets; whether or not it was on their direct team or a direct feature they were working on. They were helping each other, committing to each other’s code, etc. So we kept the team thing going up until last month, and we were measuring that way, so we just eliminated it because it didn’t make sense anymore.” Getting rid of teams works for Chris for two reasons: 1) He runs a small-ish team of 14 developers; and 2) The team uses a Kanban-style framework. If there are 3 or 4 features in flight, each team member is assigned to one as their dominant project, but they’re all on one team. Many of the [classic Scrum ceremonies](https://linearb.io/blog/an-elite-teams-guide-to-the-5-scrum-ceremonies/) are still followed, but he’s working on making them more effective as well. > “We do one large standup and it takes us 15 minutes to get through. People give their standup updates in order based on their dominant feature. So the first set of people who go, are the ones who are working on Feature A, and the second group that goes are all working on Feature B.” On top of no teams and restructuring their daily, Chris says they work in sprints but use a Kanban board to increase speed. > “The product team loves that because if they decide that something is suddenly really hot because sales has run into this or that, we can address it immediately.” Listen to the full interview with Chris below. ![GigSmart Engineering Overview. Tactical: one engineering team, twoweek sprints, kanban board, feature based standup Values: datadriven, continuous improvement, trustbased autonomy, speed and quality](https://assets.linearb.io/uploads/4-Blog-Methodology-1024x488.png) ## Why Does GigSmart Work This Way? **Reason No. 1:** **Chris believes in continuous improvement based on team feedback.** When he runs sprint retros, anything that engineering brings up that isn’t working, they have a conversation about. He brings in the product owner, and they chat about ways to make it better, and then they test it. And if it doesn’t work, Chris readjusts and tries to fix it. Since he started at GigSmart, there hasn’t been a 4-week period where their process has stayed the same. **Reason No. 2: GigSmart’s most valuable outcome is speed.** The methodology, process, or ethos that drives your team needs to be purpose-built to achieve the outcome you want. At GigSmart their defined outcome was high quality and speed. As an on-demand staffing platform, they choose to prioritize hotfixes and bugs. Other companies might need to be more predictable, quality-driven, stable, consistent, etc. based on their business type and needed outcome. **Reason No. 3:** **GigSmart is culture-driven** “Build better, more engaged engineering teams… That’s probably what my actual official job description is. So culture really matters.” [Chris and GigSmart CTO, Jason Waldrip, modeled their team’s cultural values](https://linearb.io/blog/our-dev-culture-is-based-on-bushido-samurai-code-my-interview-with-the-vp-of-engineering-at-gigsmart/) on the ancient samurai code of Bushido, eight values that they’ve written down and strive to live and work by every day. **Reason No. 4: GigSmart is data-driven** Measuring is not enough, you have to measure with a purpose. You get what you measure. Everyone is familiar with this saying. Chris takes it a step further and actually encourages the team to look at data about how they work in all of their day-to-day practices and [ceremonies](https://linearb.io/blog/how-to-improve-your-agile-ceremonies/). By defining his company’s most valuable outcome and listening to his developers, Chris has created a development process that is bespoke to his team today. Just like a custom-tailored suit, his development method cannot be easily used by another company. It had to be made up. ## **Make Up Your Own Dev Methodology: 4 Guiding Ideas** ![Make Up Your Own Development Methodology: 4 Guiding Ideas](https://assets.linearb.io/uploads/5-Blog-Methodology-1-1-1024x488.gif) Sometimes I just like building my own thing from the ground up. It’s why I started [LinearB](https://landing.blog.linearb.io/get-started). Do you need to create your own development method? Definitely not. It’s much easier to start with Scrum or Kanban and adapt from there. But times, they are a changin’, and maybe this is a good year to go through the exercise of redefining how you work. After we started full-time remote back in March 2020, my co-founder, Ori Keren, and I did just that. We created [Asynchronous Development](https://linearb.io/blog/asynchronous-development/), a development methodology designed around async communication and purpose-built for hybrid remote teams. Here’s the recipe: * A dash of Agile methods (only the best parts) * A dash of Scrum * A heaping cup of what Ori and I have learned really works for us * A pound of where we think the future of software development teamwork is headed Hundreds of teams started following the Async Development methodology, and we’ve evolved it in the last two years to bake in our [Developer Workflow Optimization tooling](https://linearb.io/workflow-optimization/) to further improve workflow. If we can make up our own dev methodology, you can too! Here are 4 guiding ideas that will help you make up your own dev methodology: ### 1\. Know Your “Why” What matters to you? If it’s aligning to your company’s most important business goals, do you know what they are? Startups tend to want lots of new features as quickly as possible. More mature companies like predictability and quality. Find out and work backward from there. For Ori and I, it’s more than just visibility for senior leaders, but it’s helping developers deliver code every day. ### 2\. Don’t Be Dogmatic Forget about the rules and just ask yourself, “How do we really want to work?” Ask your people. Especially your out-of-the-box thinkers. The more crazy ideas you throw in the mix, the more discussion you’ll create, and the more you’ll end up with something that is really bespoke. For example, the Agile Manifesto says face-to-face communication is the most efficient way to transfer information. Is that still true for your team? ### 3\. Retro Your Current Process Ask, “Why are we doing all of these things we do every day?” Do you really need a daily standup? Do you really need two-week sprints? Are you really getting value from them? The answer may be yes. But I bet if your team will have a lot of ideas of how they could be more dev-friendly and more efficient. ### 4\. Bring Data to the Conversation After you’re done exploring all of the pain from step 3, see if you can prove or disprove any of the assumptions and anecdotes with actual data. This might be the hard part, actually. The type of data you need is not necessarily accessible in your Git or project management system. If you need help, check out LinearB. Our [free-forever plan](https://linearb.io/pricing/) provides tons of metrics and process visualizations to show you what’s working, bottlenecks and how you can improve efficiency, quality and teamwork. ## What’s Your Made-up Methodology? I know many of you have already customized your own dev methodology. I’d love to hear about it! What pieces of existing methods did you use? What new things did you invent? What is special about your approach? [![Improve your engineering organization at every level with LinearB](https://assets.linearb.io/uploads/GenericLineaRB3Pillars-1024x497.png)](https://linearb.io/get-started/) Want to improve your engineering processes at every level? [Get started with a LinearB free-forever account today!](https://linearb.io/get-started/) ## Improve developer productivity with LinearB Find us on [](https://www.linkedin.com/company/linearb) [](https://devinterrupted.substack.com/) ## Your next read [![Cover image for AI as a value multiplier: a human-centric approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Servant_Leadership_2400x1256_0cfd4e2a0c?_a=BAVMn6ID0)](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership) Leadership [AI as a value multiplier: a human-centric approach to engineering leadership](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership) Super.com's Matt Culver explains why AI should be used as a value multiplier, not a cost-cutter, advocating for a human-centric approach to engineering... [![Cover image for The Moneyball approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Balancing_Technical_Depth_2400x1256_b56d93a733?_a=BAVMn6ID0)](https://linearb.io/blog/moneyball-approach-engineering-leadership) Leadership [The Moneyball approach to engineering leadership](https://linearb.io/blog/moneyball-approach-engineering-leadership) Rethink engineering leadership with Transcend's Minh Nguyen and learn how to balance hands-on technical work with strategic leadership, communicate with a... [![Cover image for Strategic lessons from Google on improving engineering teams](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Strategic_Lessons_From_Google_2400x1256_1_cd28b7242d?_a=BAVMn6ID0)](https://linearb.io/blog/strategic-lessons-google-engineering-teams) Leadership [Strategic lessons from Google on improving engineering teams](https://linearb.io/blog/strategic-lessons-google-engineering-teams) Learn key lessons from Google on aligning engineering with business goals, boosting developer productivity, and building sustainable team culture. ## Structured data _Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._ ```json { "@context": "https://schema.org", "@type": "Organization", "name": "LinearB", "url": "https://linearb.io", "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg", "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.", "sameAs": [ "https://www.linkedin.com/company/linearb" ], "award": [ { "@type": "Award", "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms", "dateAwarded": "2026", "awardedBy": { "@type": "Organization", "name": "Gartner®" } }, { "@type": "Award", "name": "Great Place to Work Certification", "dateAwarded": "2025-2027", "awardedBy": { "@type": "Organization", "name": "Great Place to Work" } }, { "@type": "Award", "name": "America's Best Startup Employers 2025", "dateAwarded": "2025", "awardedBy": { "@type": "Organization", "name": "Forbes Magazine" } } ], "hasCertification": [ { "@type": "Certification", "name": "SOC 1 Type 2" }, { "@type": "Certification", "name": "SOC 2 Type 2" }, { "@type": "Certification", "name": "GDPR Compliance certification" }, { "@type": "Certification", "name": "ISO 27001" } ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Development Methodology Doesn’t Matter (So Just Make Up Your Own)", "url": "https://linearb.io/blog/dev-methodology-doesnt-matter", "author": { "@type": "Person", "name": "Dan Lines" }, "datePublished": "2020-10-20T15:34:32.000Z", "dateModified": "2020-10-20T15:34:32.000Z", "image": "https://assets.linearb.io/image/upload/v1720000000/1_Blog_Methodology_1_1_8eeafdca35.png", "publisher": { "@type": "Organization", "name": "LinearB", "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png" }, "description": "Dev methodology… a lot of people are fussy about it, but we’re not. In fact, we made up our own. You should too. Here’s why and how.\n" } ``` ## More on linearb.io ### Top navigation - [Book a Demo](https://linearb.io/book-a-demo) - [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews) - [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights) - [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact) - [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server) - [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation) - [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization) - [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting) - [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance) - [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support) - [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience) - [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience) - [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys) - [Platform overview](https://linearb.io/platform/overview) - [Register now](https://linearb.io/event/engineering-productivity-gap) - [Customers](https://linearb.io/customers) - [Pricing](https://linearb.io/pricing) - [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb) - [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework) - [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq) - [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security) - [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy) - [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts) - [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources) - [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops) - [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report) - [Blog — Product updates and practical insights](https://linearb.io/blog) - [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io) - [API Docs](https://docs.linearb.io/api-overview) - [Status](https://www.linearbstatus.com/) - [Integrations](https://linearb.io/integrations) - [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026) - [Sign in](https://app.linearb.io/login) - [Enterprise](https://linearb.io/solutions/enterprise) - [Contact](https://linearb.io/contact-us) - [About us](https://linearb.io/about-us) - [Careers](https://linearb.io/careers) - [Service agreement](https://linearb.io/services-agreement) - [Privacy policy](https://linearb.io/privacy-policy) - [DPA](https://linearb.io/data-processing-agreement) - [Security FAQ](https://linearb.io/security-faq) - [Substack](https://devinterrupted.substack.com/) ### Footer _Additional links from the site footer, not repeated from the top navigation above._ - [GitHub](https://github.com/linear-b) - [LinkedIn](https://www.linkedin.com/company/linearb) - [Twitter](https://twitter.com/LinearB_Inc)