Agile Candor

  Thesis: In complex programs, the thing that moves systems to production isn’t a perfect plan, it’s a daily discipline of reducing risk. “ Design ” isn’t a kickoff artifact; it’s how we make safer, smaller, more reversible decisions every day. Related: my earlier post on estimation argued for  appetite → slicing → triggers  (“ estimate to decide, then revisit on signals ”). This post is the companion playbook:  how to run the day-to-day so delivery stays safe and sane.

Ever participated in a backlog grooming or an estimation meeting that took forever? Ever worked on a project where leadership judges you for delivery only against your original estimates? Read on! If so, you are not alone. This post has some ideas I have found to work most of the times. Have you applied any or all of these ideas before? What is your go to idea? References:   http://bit.ly/3HVbuE8  and  LinkedIn post  [By Alistair Cockburn] Thesis: Estimation is unavoidable, but the win is making it cheap, decision-oriented, and revisited on signals (not on a calendar). Here is an approach I have adopted repeatedly, with a reasonable amount of success. 1) Start with an appetite (timebox) Decide what the work is worth before shaping it. Example: “Two weeks max; scope flexes to fit.” Effect: Shifts the conversation from perfect prediction to value and trade-offs. 2) Shrink variance by slicing Smaller batches beat clever estimates. Slice work in...

 A practical map for faster system-design decisions Intro The database landscape has exploded—in a good way. Instead of hunting for a single “best” engine, modern teams compose the right categories for the job: transactional integrity, low-latency reads, high-throughput writes, full-text search, batch analytics, and durable object storage. This post summarizes the trade-space I use in design reviews and includes a one-page visual you can share with your team. The Category Map (quick reference) Relational (RDBMS) — Strong consistency, complex queries, auditability. Examples: PostgreSQL, MySQL, Aurora (AWS), SQL Server, Oracle. NoSQL: Key-Value & Wide Column — Massive scale, predictable keys, high write throughput. Examples: DynamoDB, Cosmos DB, FoundationDB; Cassandra/ScyllaDB/HBase; Bigtable/InfluxDB/VictoriaMetrics. Document Stores — Flexible schema, nested JSON, fast iteration. Examples: MongoDB, Couchbase, Amazon DocumentDB; Firebase Firestore, Realm; CouchDB/PouchD...

When tackling large-scale, complex initiatives, the notion of “flawless execution” sets up leaders and teams for disappointment. Complexity guarantees surprises: dependencies shift, risks emerge, and trade-offs appear late in the game. From my experience leading programs at Amazon, Citrix, Philips and beyond, I’ve learned that the right aspiration isn’t flawless execution, but fearless execution. Fearless execution doesn’t mean chasing perfection. It means leading with clarity, transparency, and adaptability, while creating an environment where teams feel safe and empowered to do their best work. Or as I like to say: flawless is the enemy of good.   Here are five key drivers that consistently define fearless execution: 1. Clear Vision A compelling north star aligns decision-making. Without it, teams drift. Vision isn’t just a tagline—it’s a narrative that helps individuals understand how their day-to-day work maps to long-term outcomes. Fearless leaders repeat the vision often and ...

There are many terms and concepts that are important for an engineer to be familiar with, in order to effectively build software. This post includes some of those terms. I will continually add to or update this list. Agile. A flexible and iterative approach to software development that emphasizes collaboration, customer feedback, and adaptive planning. My experience and success with agile development was the inspiration behind starting this blog. DevOps. A set of practices and tools that improve efficiency, speed, and reliability of the product through automation and optimization of the software development and delivery process where operational efficiency is part of the development process. Continuous Integration and Continuous Delivery/Deployment (CI/CD). A set of practices and tools that result in faster and more frequent releases, through automation of building, testing, and deployment of software. A key part of CI/CD is to deliver software to production frequently and using tec...

Consider This Someone is presenting the work that they have just completed. Compare and contrast the two scenarios below: ONE. "This is freaking awesome!", you think. At one moment, everyone in the room was listening intently - not a word was spoken by the audience. At another, multiple hands went up for questions. Then, there was debate, many questions answered, some actions noted. Finally, the whole room erupted with applause and appreciation for the presenter and for each other. TWO. "Is that all you got?", you can't help but wonder. The room is low energy - the audience is either trying hard to listen, is distracted - only pretending to listen, or just busy chatting with someone else. There are no questions asked, and of course, none answered.   Which of the above scenarios would you like be a part of - in either role, as presenter or as audience? If you have worked in software development for few years, with different teams or organizations where they demo ...