​About ten years ago, I wrote a series of blog posts that explored the core meetings of Scrum: Sprint Planning, Daily Scrum, Sprint Review, Retrospective, and Backlog Refinement. Each post focused on the mechanics of these ceremonies, but the deeper message was about Agile mindset itself, one built on adaptability, transparency, and continuous improvement. Over time, this approach has proven more enduring than any single framework.

Fast forward to today, and that mindset hasn’t lost a bit of relevance.

While the Agile landscape has expanded to include countless frameworks and hybrid models, I’ve found that the fundamentals still hold up. For most teams, that means starting with Scrum, evolving into Kanban, and eventually moving beyond frameworks altogether into a more fluid, principle-driven approach to Agile where the mindset matters more than the method. Scrum and Kanban remain excellent starting points, teaching core Agile principles without the overhead and dilution that often come with hybrid approaches.

These posts reflect the foundational practices that helped many teams, including ours, begin their Agile journey. They remain relevant today, even as teams evolve toward more fluid, principle-driven approaches:

Here’s a look back at the original posts:

• Sprint Planning: Where alignment begins.
• Daily Scrum: A daily check-in that keeps teams focused and connected.
• Sprint Review: A moment to inspect progress and adapt based on real feedback.
• Retrospective: The engine of continuous improvement.
• Backlog Refinement: Keeping the work ahead clear and actionable.

​
Agile isn’t about chasing trends or layering on complexity. It’s about staying responsive, building trust, and delivering value. Scrum and Kanban continue to teach these principles effectively, but the real power of Agile emerges when teams internalize the mindset and apply it fluidly, beyond any single framework.

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.
​
Agility starts with the right team. Talk to us about building custom solutions that deliver.

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. A long-time Certified Scrum Product Owner, he works with teams embedded in client organizations building custom applications and teaching Agile through hands-on collaboration. Andrew promotes sustainable agility rooted in principles, not rigid frameworks.

​When choosing software to run your business, for your own safety, it may be wise to avoid creating dependencies on other companies. Those dependencies create specific types of risk that can lead to undesired consequences down the road.

When choosing an off-the-shelf software package, you do not own the product in any way, shape or form. This means you do not have control over its future. It may do what you need now, but there is no way to know for certain what it will turn into later or how long it will last before being sold to another company or simply discontinued.

We had a customer years ago needing quick help to build a custom ERP solution after having used another popular industry-specific off-the-shelf product for many years that was abruptly discontinued. The product was purchased by another company who then immediately discontinued it and tried to force its clientele onto another completely different (and expensive) platform without giving them much time to come up with an alternate solution. While we can hope that most companies will not resort to this type of unethical behavior, it does illustrate what can happen when you don’t control the product you use.

Aside from that extreme example, other common complaints include:

• Unwanted changes to your product are suddenly forced through, sometimes causing disruption to your business.
• You may want specific changes that you can never get approved. This means you are not free to change anything within your company when you’d like to. Any major changes within your business may require a completely new software package.

​By commissioning your own custom software, you can stay in better control. You can change the product whenever you’d like, and you won’t ever be subject to unwanted changes. There are still some things to watch out for, though.

It’s a good idea to try and limit any 3rd party tooling being used within the app. There can be a tendency to try to plug in pre-built components into your app to save some time and money. Sometimes this is still the right thing to do, but some of these tools are so simple that it may be easy to build them yourself so you aren’t subject to the same problems described above with off-the-shelf software packages, albeit on a smaller scale.

​A while back, we were using a popular database technology internally within some of our custom software applications we’d written for various customers, and one day that technology was purchased by a large firm to be used internally and was taken off the market completely. This left our customers in an emergency situation and they needed quick help to adapt.

​The quality of the source code is another critical factor that is often overlooked. Custom software should be clean and architected in a way that makes it easy to maintain/change later when you need it to. How to accomplish this as an architect and developer is a large topic that has been evolving for years. There are literally thousands of books that have been published over the last many decades on this subject and the best technical people will always be looking for further improvement. It’s an important aspect of quality that ensures any future developer will be able to easily pick up and continue working on the platform when needed. This reduces the risk of being locked into a single development firm and allows for smoother transitions if you decide to change providers. 

Another thing to make sure of, is that you retain the ownership of the source code itself. We still occasionally have customers find us after paying quite a sum of money to another company to develop their applications, only to find out later that they didn’t own it and would have to pay much more to get their hands on the source code. This has led to many legal battles, so before starting a new project with a development firm, be sure to check the fine print. If you discover the clause that does not give you ownership, run for the hills. This is a relatively common, although disdainful and underhanded practice that says a lot about the firm.
​
If you follow this advice, you will always have the option to move on to another development firm in the future for any reason whatsoever. You may also want to bring the development in-house someday.

​Custom software solutions offer numerous benefits that help businesses maintain their independence compared to off-the-shelf software. By owning the source code and ensuring maintainable code quality, businesses can avoid unnecessary dependencies and retain control over their software. Consider custom software solutions to enhance your operational flexibility and control, and to stay ahead in your competitive market.

​Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Secure your business against software uncertainty--talk to us about custom solutions

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps businesses build maintainable, high-quality custom applications while fostering agility through collaborative, principle-driven development practices.

Quality as an objective has diminished as companies have jumped onto the offshoring bandwagon, subscribing to the idea that this type of development is both cost-effective and efficient. However, reality says something different. This approach often leads to miscommunicated requirements and subpar results where you are left with a product that doesn't meet expectations. This forces you to either cope with the flawed outcome or abandon the project at a substantial loss. Abandoning your investment is rarely appealing, so companies often end up spending more money on ongoing support for buggy software. In the end, you spend much more than you should for an inferior product. We have seen this scenario play out repeatedly over the last couple of decades.

To be fair, some projects do succeed, but the success rate is poor. By offshoring, you leave your success up to chance rather than building something that guarantees an advantage over your competition. Quality software is still a noble objective and is achievable despite the widespread shift towards the “cheaper” offshoring model.

1. Communication Gaps: The distance and language barriers create significant communication issues. Misunderstandings and delays are common, leading to misaligned expectations and outcomes.
2. Overhead Costs: Larger consulting firms often sell you on the idea that increasing headcount will speed up the project. However, this adds unnecessary overhead, making the process less efficient. Smaller, more focused teams are often much more effective despite what they may have told you.
3. Cultural Differences: Different working cultures and time zones can lead to misaligned work ethics and expectations, further complicating things.
4. Lack of Accountability: When working with offshore teams, accountability can become diluted. A good team will feel a sense of self-responsibility for the product they are creating, but that is difficult to have when they feel so far removed from their client and the people they are trying to help. This is escalated in cases where your team is scattered around the world. All the other barriers listed here expound on this problem.
5. Hidden Costs: While hourly rates may be lower, hidden costs such as extended timelines, additional management, and other overhead can quickly add up, making the project more expensive in the long run.
6. Quality of Developers: There are certainly quality developers all over the world, but since you are so far removed, you may be leaving this crucial aspect up to chance.

Local teams well versed in agile practices working together in a cohesive environment offer a stark contrast to the pitfalls of offshoring. Here’s why:

1. Direct Communication: Being in the same location allows for face-to-face meetings as needed, real-time collaboration, and immediate feedback. This minimizes misunderstandings and ensures everyone is on the same page, reducing the communication gaps that plague offshore projects. Agile practices rely on such direct and continuous communication.
2. Empowered Teams: Local teams can take full ownership of their work, fostering a sense of self-responsibility and accountability. Teams learn to manage their progress and quality standards leading to a lack of the need to micro-manage.
3. Cultural Alignment: Sharing the same working culture and time zone eliminates the friction caused by cultural differences and asynchronous communication. This alignment leads to more cohesive and efficient teamwork, which is essential for agile practices that rely on close collaboration and quick iterations.
4. Stronger Team Dynamics: Working closely together fosters a sense of camaraderie and teamwork. This leads to higher morale, better problem-solving, and a more dedicated effort towards achieving the right results. Smaller, focused teams can be more effective and agile, avoiding the overhead costs associated with larger offshore teams.
5. Consistent Quality: With local teams, you have better control and insight into the development team, ensuring that you get skilled developers who are committed to delivering high-quality work. This reduces the risk of leaving the quality of developers up to chance. Agile practices emphasize continuous improvement and high standards of quality.
6. Long-term Relationships: Building a local team allows for the development of long-term working relationships, which can lead to more consistent and reliable project outcomes. These relationships are harder to establish and maintain with offshore teams. Agile teams benefit from stable, long-term collaborations that enhance their effectiveness over time.

​Investing in local agile teams is not just about avoiding the pitfalls of offshoring; it's about ensuring the success and quality of your projects. By working with a local team that embraces agile principles, self-responsibility, and self-organization, you can build something that is truly excellent and that you can control better over the long-term.

​​Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Stop gambling with your software quality. Build with a local team you can trust.

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps businesses build high-quality custom applications by forming collaborative, onshore teams that apply Agile principles to improve communication, accountability, and long-term success.

One common question our customers have been asking for years is, “Can we just start with 10 devs to get our app done quickly?” While it is true that adding resources can speed things up, you have to be aware that you will not get a linear increase in overall productivity. The law of diminishing returns definitely applies here. In other words, if a team of 3 developers can finish a project in 4 months, you will not cut that time in half (deliver after just 2 months) by doubling down on developers. Every project is different, but 3 extra devs might not even buy you 1 month which means that you need to budget financially for the difference.

Why is this the case? Every developer you add creates a certain amount of overhead. There is simply more coordination required within the team, more “management” time (yes, even when handled collectively by the team itself), more opinions that need to be discussed during sprint meetings, potential conflict among team members that needs to be resolved, etc. This overhead increases exponentially as each developer is added.

What this means is that at a certain point, adding another development resource might actually start slowing the team down. We’ve experienced these types of situations where the performance solution was to reduce the size of the team.

So is there any other way to speed up your project? Well you might be able to find ways to increase efficiency within a team, but most professional agile teams are constantly doing so already. So really the practical answer is no. If you need to speed up, you might just have to add resources and pay for the overhead. Just be mindful of how far you take it because the strategy could backfire.

For larger projects, you might consider creating multiple teams instead of one very large one. If you do so, make sure you make each team responsible for separate bounded contexts to help reduce potential conflicts between the work that each team is doing.

On the flip side, we have customers ask, “How can we keep this as cheap as possible?” Well, you might now think that hiring a single developer would be the most economical way to get your project done when the timeline isn’t a concern. Disregarding the inherent risk in having just one developer involved in your project, this also isn’t the case. Getting your project done will likely require many skillsets which will not be found in one developer alone. Also, one developer working alone, regardless of skill level, is not nearly as impactful as he/she would be within a team. As a social species, we all need other people to talk to, bounce ideas off of and get general advice and support from. If your goal is to create a quality piece of software that works well, is maintainable, and can handle changes that you’ll throw at it over a long period of time, then you should give your developers what they need to be productive, which is a good cross-functional team to work in.

Therefore, at a minimum you should consider a team of 2-3 developers for your small project. A team of 2 is very minimal, but is infinitely better than 1 if funds are lacking. Scale up (with caution) as needed to meet your timeline and other requirements. Larger projects tend to have more complexity and require more skillsets. If you are missing a required skillset, that will negatively impact quality and the timeline. Again, cautiously build up as needed, and be mindful of the potentially negative impact any added team members might have.

Agile evangelists state that a team of 5-9 is the optimal size for a team, but 5 devs on a really small project is overkill. We also don't like to go above 7 devs on larger projects. If your project is large enough to require that many developers, then you should be able to create separate teams which would likely be more effective. Again, there are always exceptions and each project is different but this is what we've found to be most successful.

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Don’t just add developers—add direction. Latitude 40 builds teams that deliver.
​
Contact us today to discuss how we may be of help to your organization.

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps organizations build right-sized development teams that deliver high-quality software through collaborative, principle-driven Agile practices.

I’m certainly not wanting to engage in a political discussion here, but it did occur to me that what we’re dealing with in this upcoming election… and every election of my lifetime, are two ‘packaged’ candidates.  They never seem to really ‘fit’ exactly what I’m looking for in a candidate for president.  In fact, that seems to be the theme for everything out there… houses, cars, packaged software!
 
Here’s a thought.  What if you could have a custom presidential candidate?  What if you could choose what experience they had?  What if you could align their political beliefs and strategies to ‘fit’ exactly what you need in a president?  That would be pretty awesome!  Of course, we may have 150 million candidates for president in each election!
 
Since we’re stuck with ‘packaged’ presidential candidates, why should we be stuck with ‘packaged’ software?  It may seem like that is often the only option.  After all, building a custom house is so much more expensive and only for people with lots of money, right?  Same thing with software, right?  Well, I don’t have to tell you the ‘cost’ of something is only in the price tag.  Is it more expensive to buy a house that doesn’t have the kitchen you want, the flooring you want, the basement you want, the landscape you want, the deck you want, the paint you want?   These are all things you could ‘pay’ to improve… or customize and get at some point.  Or you could just settle and deal with what you bought.
 
Or, what about finding the right architect, the right home builder and having them build you a home that has the right kitchen, flooring, basement, landscape, that ‘fits’ your needs exactly?  Or better yet, what about partnering with a custom software development firm (insert shameless Latitude 40 plug here) to build a software application that ‘fits’ your business processes… exactly?
 
So this November (actually every month), choose custom software over packaged software and move your business forward into the future with software built specifically for you… and vote for whichever candidate ‘fits’ you best!  

In Agile environments, improvement isn’t a one-time event—it’s a mindset. No matter how effective a team is, there’s always room to refine workflows, strengthen collaboration, and deliver better outcomes. That’s why retrospectives are a cornerstone of Agile practice.

Held regularly—often at the end of a work cycle—retrospectives give teams a chance to reflect on recent efforts and identify ways to improve. These meetings are most impactful when they include the entire team and are facilitated in a way that encourages open, respectful dialogue.

For retrospectives to be meaningful, the environment must support psychological safety. Team members should feel comfortable sharing honest feedback, knowing the goal is to improve—not to assign blame. Respect, transparency, and empathy are essential.

One effective way to guide retrospective discussions is to use a structured format. This helps keep the conversation focused and inclusive. A popular and practical approach includes four key questions:

This format encourages balanced reflection and helps teams generate actionable insights without getting stuck in negativity or vague feedback. Feel free to try other formats, though, like “Start, Stop, Continue” or “4Ls: Liked, Learned, Lacked, Longed For.”

Whether you're a team lead, coach, or facilitator, your role is to guide the conversation and ensure it stays constructive. Here are a few tips:

• Start with a check-in: Invite each team member to share a quick thought or feeling about the last cycle.
• Use visual aids or boards: Digital tools like GroupMap or even sticky notes can help organize thoughts.
• Encourage prioritization: After brainstorming, vote on the most impactful items to address.
• Follow up​: Revisit previous retrospective commitments to track progress and accountability.

Agile retrospectives are more than just meetings—they’re a powerful tool for team learning and growth. When done well, they foster trust, adaptability, and continuous improvement, helping teams deliver better results with each cycle.​

The Sprint Review is a key Scrum event held at the end of each sprint. Its purpose is to inspect the product increment and adapt the product backlog based on feedback. It’s a working session—not a status meeting—where the Scrum Team and stakeholders come together to review what was completed and discuss what’s next.

​The goal of the Sprint Review is to:
​

• Demonstrate completed work
• Gather feedback from stakeholders
• Discuss progress toward the product goal
• Adapt the backlog based on new insights

It’s an opportunity for the team to show what’s done, and for stakeholders to provide input that may influence future priorities.

• Scrum Team: Developers, Scrum Maters, and Product Owner
• Stakeholders: Customers, users, business representatives, or anyone with a vested interest in the product

The Sprint Review centers around collaboration and inspection. The Development Team presents the completed product increment to stakeholders, and together they discuss what was delivered and what might come next.

Here’s what that typically looks like:
​

• Demonstration of Completed Work: The Development Team showcases work that meets the Definition of Done. This is a live,  working demonstration—not a slide deck or abstract summary. The goal is to show what’s usable and potentially shippable.
• Stakeholder Feedback and Discussion: Stakeholders respond to what they’ve seen, ask questions, and offer insights. This feedback helps the Product Owner refine the Product Backlog and may lead to new ideas, changes in priorities, or clarification of future needs.

​This shared inspection helps ensure the product is evolving in a direction that delivers value and meets user expectations. It also strengthens transparency and trust between the team and stakeholders.

​The Sprint Review is more than a demo—it’s a collaborative checkpoint that helps Scrum Teams stay aligned, adapt quickly, and deliver value. When facilitated well, it strengthens relationships, clarifies direction, and sets the stage for a successful next sprint.

Imagine starting each workday with clarity and focus—knowing what you accomplished yesterday, what you’re tackling today, and what might stand in your way. That’s exactly what the Daily Scrum, often called the daily stand-up, is designed to achieve.

This short, focused meeting helps the Scrum Team stay aligned, adapt quickly, and maintain momentum toward the Sprint Goal.

The Daily Scrum is a 15-minute time-boxed event held every working day of the sprint. It’s for the Developers to inspect progress and plan the next 24 hours. It’s not a status meeting for managers—it’s a coordination tool for the team.

The classic format revolves around three guiding questions:

• What did I accomplish yesterday? Helps the team understand progress and build accountability.
• What will I do today? Sets intentions and keeps everyone aligned on short-term goals.
• What obstacles are impeding my progress? This is the most powerful question—it opens the door for collaboration. When a team member shares an impediment, it invites others to offer help, share context, or remove blockers. It keeps communication flowing and reinforces the team’s shared responsibility for success.

While the structure is simple, teams often adapt the format to suit their style and needs. Here are a few tips:

• Keep it consistent: Hold the meeting at the same time and place each day.
  
• Keep it focused: Stick to the purpose—coordination, not problem-solving.
  
• Keep it lightweight: Standing up is optional, but the meeting should stay short and energetic.
  
• Keep it flexible: Some teams use a speaking token, a round-robin format, or digital boards to guide the conversation.

​The key is to ensure the meeting helps the team stay aligned and move forward together.

​The Daily Scrum is a simple yet powerful habit that fosters communication, accountability, and agility. When done well, it becomes a daily rhythm that keeps the team connected, clears roadblocks, and drives progress toward the Sprint Goal.

The Sprint Planning Meeting marks the beginning of each sprint in Scrum. It’s a collaborative session where the Scrum Team aligns on what will be delivered and how the work will be accomplished. The outcome is a clear, achievable plan that guides the team throughout the sprint.​

Sprint Planning answers two key questions:

1. What can we deliver in this sprint?
   
2. How will we get it done?

The meeting sets the tone for the sprint by establishing a shared understanding of the work and a commitment to the Sprint Goal.

The entire Scrum Team participates in Sprint Planning: the Product Owner, the Scrum Master, and the Developers.

• The Product Owner presents the highest-priority items from the Product Backlog, explaining the desired functionality, business value, and context.
  
• The Developers ask clarifying questions, assess feasibility, and begin breaking down the work into tasks.
  
• The Scrum Master facilitates the meeting, ensuring focus and helping the team stay aligned with Scrum principles.

The team considers its capacity, past velocity, and any known constraints to determine how much work it can realistically commit to. The selected items form the Sprint Backlog, along with a clear Sprint Goal that provides focus and purpose.

Effective Sprint Planning requires preparation and active participation:

• The Product Owner should come ready with well-refined backlog items and a clear sense of priorities.
  
• The Scrum Master ensures the meeting stays productive and that the team uncovers dependencies, assumptions, and risks.
  
• The Developers own the commitment. While the Product Owner proposes what they’d like to see delivered, the team decides what’s feasible based on their understanding and capacity.

• Product Vision and Roadmap [Product Owner]
  
• Sprint Goal and Theme [Scrum Master]
  
• Team Capacity and Availability [Team]
  
• Present and Discuss Backlog Items [Product Owner]
  
• Break Down Items into Tasks [Team]
  
• Identify Dependencies and Assumptions [Team & Scrum Master]
  
• Finalize Commitment [Team]

​Sprint Planning is more than just selecting tasks—it’s about building shared understanding, fostering ownership, and setting the team up for success. When done well, it creates clarity, alignment, and confidence in the sprint ahead.

In Scrum, the Product Backlog is a dynamic, evolving list of everything that might be needed in the product. To keep it useful and actionable, the Scrum Team engages in Backlog Refinement—a collaborative activity that ensures the backlog remains clear, prioritized, and ready for Sprint Planning.

Backlog Refinement (sometimes called “backlog grooming” and even “story time”) is an ongoing process where the Scrum Team reviews and adjusts Product Backlog items. It’s not a formal Scrum event, but it’s a recommended practice that helps maintain a healthy backlog and supports effective sprint planning.

During refinement, the team:
​

• Clarifies and elaborates Product Backlog items
• Breaks down large items into smaller, more manageable ones
• Estimates effort (typically in story points)
• Reorders items based on priority and value
• Removes outdated or irrelevant items

Regular backlog refinement helps the team:
​

• Ensure items are ready for selection in Sprint Planning
  
• Improve forecasting and planning accuracy
  
• Adapt quickly to changing business needs
  
• Reduce surprises and confusion during sprints

Without refinement, Sprint Planning meetings can become long and inefficient, and teams may struggle to commit confidently to work.

One of the most valuable outcomes of backlog refinement is better forecasting. When backlog items are consistently reviewed, clarified, and estimated, the team builds a more reliable understanding of:
​

• Effort required for upcoming work
• Team capacity and velocity trends
• Dependencies and risks that could affect delivery

This enables the Product Owner and Scrum Team to make more informed decisions about what can be delivered in future sprints. It also helps stakeholders set realistic expectations and plan releases with greater confidence. Without refinement, forecasting becomes guesswork—leading to missed commitments and unpredictable outcomes.

Backlog Refinement is a collaborative effort involving:
​

• Product Owner: Leads the refinement by clarifying items and setting priorities
• Developers: Ask questions, provide technical input, and estimate effort
• Scrum Master: Facilitates the process and ensures it aligns with Scrum principles

Refinement should happen regularly, often once per sprint. It can be scheduled as a recurring meeting or done ad hoc as needed. The goal is to keep the top items in the backlog “ready” for planning—clear, well-understood, and appropriately sized.

• Keep it focused: Limit refinement to the highest-priority items
• Use the INVEST criteria: Ensure items are Independent, Negotiable, Valuable, Estimable, Small, and Testable
• Time-box the session: Avoid turning refinement into a planning meeting
• Encourage collaboration: Developers and Product Owners should work together to clarify and shape items
• Don’t skip it: Under-refined backlogs lead to inefficient planning and unclear sprint goals

​Backlog Refinement is essential for maintaining a clear, actionable, and prioritized Product Backlog. It supports better planning, smoother sprints, and more predictable delivery. When done consistently, it helps Scrum Teams stay aligned with business goals and deliver value with confidence.