Praxent

What do software projects and watermelons have in common? Green on the outside (status reports 🟩 🟩 🟩). Red on the inside (an abrupt 🟥 🔥 💣 the week before launch). Looking for a LEADING INDICATOR that tells a more realistic story than your burndown? What if you could visualize which BEST PRACTICES might be getting skipped? Here’s how we did just that at Praxent: 1. SIMPLIFY your definition of best practices into a short checklist In the fast-moving world of NOVEL feature development, good habits are at constant risk. On paper everyone knows how to build good software, but in practice there are hectic meeting days, clumsy async communication, and any other number of factors that make it difficult to follow best practices. So: we simplified those expectations. Borrowing from the best practices of surgeons and aviators, we created 7-item checklists for every role in a sprint that represent the most critical expectations. 2. REINFORCE those expectations with a sprintly self-assessment The cognitive load of remembering your responsibilities — while also navigating the massive complexity of knowledge work – is immense. And – though I hate to admit it as the author of so much of our wiki – no one looks at the wiki.  So reinforce those responsibilities with a weekly survey. 5-minutes, 7-questions. Did I perform the best practices or not? We found that a checklist every sprint provided a level of clarity and confidence that boosted performance AND engagement. 3. VISUALIZE which best practices are strong with a habit heatmap By aggregating our weekly self-surveys, we found we could create a real-time HEATMAP of which best practices are strong – and which ones might be getting missed. Knowledge is everything: once you see which best practices might be skipped (for any number of great reasons, by the way) you are able to influence the project in ways you never thought possible. #softwaredevelopment #fintechnews #digitaltransformation #agiledevelopment

Found several significant architectural issues that were impacting the modernization effort of an enterprise insurance carrier. Here are seven of the common mistakes we found: 1.  🚩Problem: Forced downtime during deployments due to coupling with the database 💡Solution: Make your database backward compatible with your microservice. Automate schema updates with a migration tool like Flyway or Knex. Orchestrate application updates and database migrations such that integrity constraint enforcement doesn't occur until consumers are ready. 2.  🚩Problem: Over-reliance on REST calls between services causing poor performance 💡Solution: Redundant data is ok. Map what data each microservice requires and its tolerance for eventual consistency. Use tools like Kafka or RabbitMQ to deliver events. Answer the questions of why, when, and how events are used to update each service's data. 3.  🚩Problem: Business workflows are difficult to update due to dispersed business logic 💡Solution: Centralize business rules in an orchestration layer using purpose-built tools such as Lambda step functions, Camunda, or Netflix Conductor. Optimize for being able to update business rules in a single location. 4. 🚩Problem: Rising maintenance cost due to too many unique tech stacks across microservices 💡Solution: Reduce unnecessary variance by providing a compelling developer experience for a standard tech stack. Establish this "golden path" through searchable documentation, intuitive tooling, and self-service access.   5. 🚩Problem: Big bang releases due to inefficient testing strategy 💡Solution: Design an automated testing strategy that allows you to test one change at a time without requiring an entire test environment to be held hostage for the duration of test execution. Fail fast with unit tests, prevent deployments through contract-based testing with tools like Pact, and design your automated tests to be feature toggle aware.  6. 🚩Problem: API First development stifles user experience 💡Solution: The design of your microservices should be completely abstracted from your client code. Utilize experience API patterns such as backend for frontend or GraphQL to accelerate frontend development without burdening microservices with the concerns of your presentation layer. 7.  🚩Problem: Observables don’t represent reality 💡Solution: Observables need something to observe. If you don’t have a sustained load, generate synthetic traffic so your monitoring has something to measure. Otherwise, your client’s request may be the first one to fail, and you learn of an outage at the same time as your users. #microservices #enterprisearchitecture #softwareengineering #fintech #technicaldebt #digitaltransformation #softwarearchitect #modernization

3 ways trouble with translating business requirements shows up in software development teams and how to solve them. 1. Your team heads off hiking without a map = rework. Assuming engineers can figure out what customers want rarely works out well. 2. Your team gets stuck in the mud = unexpected timeline delays. Status is green until it isn’t. Then it’s bright red. 3. Your team goes off on a different hike = low priority features delivered. Undefined requirements are sabotaging your digital products and ROI. Stop the costly reworks, feature stalls, and endless firefighting. Assuming your team is doing the basics, i.e. you have a backlog, you do standup, etc. Focusing on translating business requirements helps prevent bad outcomes that decelerate sprint teams. Here’s what we do at Praxent to create better feature specs from business requirements to unblock the team. #scrum #digitaltransformation #agile #userexperience #businessrequirements #definitionofdone

A mistake most scrum teams make that causes missed milestones (add these expectations to your job descriptions)... Not having EVERYONE accountable for definition of done, with explicitly defined responsibilities for each role. “DONE” in software can’t be defined like a dictionary. DONE is not determined by a singular expert. And DONE is certainly not static. EVERYONE on the project team plays a CONTINUOUS role in defining DONE. Why? Defining DONE is a Collaborative Activity Understanding of requirements can only happen thru dialogue – not just because documenting acceptance criteria is HARD, but also because input and suggestions MAKE IT BETTER. “Have you thought of this?” “Could we reuse that?” “Could we do it in half the time if we consider it this way?” Why? Defining DONE is a Continuous Activity Forget about the pristine order that your requirements seek to create – they are surrounded by chaos. Software development, in fact, *benefits* from change, pivots, and even variability. No amount of planning can make the acceptance criteria less fragile — instead, build a team that embraces a continuous refinement of DONE. At Praxent, we know that EVERYONE needs to play a HABITUAL role in defining, shaping, and championing a great definition of done. That drove us to define ONE responsibility for every role in order to prevent this failure. Now everyone knows SPECIFICALLY what they can do every single sprint to ensure our Definition of Done… is.. done. Better still: we identified the 7 root causes (including “Unclear Definition of Done”) that result in most teams missing milestones — and built out a series of behaviors that help us consistently avoid every one of them. It’s all part of our software delivery operating model, which we call CanDone.os.  [For avoiding the “Unclear definition of done” hazard, I'll link a high res version you can download in the comments]. How do you do this with your team? As always, feel free to DM me with any questions about managing software delivery teams! I love chatting about this stuff! #agile #scrum #agiletransformation #digitaltransformation #engineeringleadership #engineeringmanagement #PMO #productmanagement