Latitude 40
  • Home
  • Company
    • About Us
    • Philosophy
    • History
  • Services
  • Buzz
    • Blog
    • Case Studies
    • Testimonials
  • Contact

Latitude 40 blog

What is the best size for an Agile Team?

5/18/2020

0 Comments

 
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 at least 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. For larger projects, I’d say that 4 should be the minimum depending on the individual project's needs. These 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 from there 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 2 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.
0 Comments

On Things Packaged: Presidents and Software

8/3/2016

3 Comments

 
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!  

3 Comments

Always pushing to improve - the Sprint Retrospective Meeting

6/29/2015

3 Comments

 
No matter how good a Scrum team is, the opportunity to improve is constant. This is the overarching purpose of the Sprint Retrospective Meeting – encouraging the entire team to build on their success and address any potential challenges or issues and grow as a team.

The Sprint Retrospective is usually the last thing done in a sprint and many teams will complete the meeting immediately following the Sprint Review. The entire team, including both the Scrum Master and the Product Owner should participate. Retrospectives are usually scheduled for up to an hour but allow time for any hot topics or team conflicts that may arise as a result of this meeting. 

The environment for Sprint Retrospectives must be safe for everyone. This means attendees must be transparent while treating others with respect. This is not an opportunity for personal criticism or attack. 

While Scrum says little about the internal structure of Sprint Retrospectives, it does specify that the output of the Sprint Retrospective is any improvements the team will perform for the next Sprint. Productive Sprint Retrospectives share the following characteristics:
  • The entire team is engaged
  • Discussion focuses on the team rather than individuals
  • The team’s Definition of Done is visited and hopefully expanded
  • A list of actionable commitments is created
  • The results of the previous Sprint Retrospective are visited
  • The discussion is relevant for all attendees

In many respects, these meetings are the most effective and action-oriented form of a review meeting but they can be tricky to run in the right way. The Scrum Master can facilitate this sprint retrospective meeting by asking everyone to just shout out ideas during the scrum. Or, for example, he or she can tell everyone to focus on identifying something to stop this time because not much attention has been paid to things to stop in recent retrospectives. After an initial list of ideas has been brainstormed, teams will commonly vote on specific items to focus on during the coming sprint.

Learn more about the Sprint Retrospective Meeting and why it is considered by many to be the life-blood of a development team. Courtesy of agilemethodology.org, this video series takes you through the life-cycle of a Sprint, from planning through to retrospective. Link to Video 6 - Sprint Retrospective Meeting here.
3 Comments

Inspect and Adapt | The Sprint Review Meeting

6/24/2015

3 Comments

 
Did we do what we set out to accomplish during our sprint? Do we have a coded, tested and usable piece of software ready for the product owner?

These are just some of the questions asked during the Sprint Review Meeting. On the last day of the sprint, the team meets with the product owner, customers, and stakeholders to accept completed work and to identify new requirements. After this meeting the team plans the next sprint. In this way, the development team receives the feedback they need to move forward in the design process and provides a stronger and more functional software product.

You may be asking, “well, isn’t this just the same as the Daily Scrum Meeting but with a different name?” The short answer is “no”. One of the guiding principles of Agile is to continually improve and constantly communicate. Reviewing what has been accomplished during the active Sprint is a critical piece to ensuring that the product owner sees what the team has completed. And, in many cases, your customers will understand their additional needs more fully after seeing the demonstrations and will identify and discuss the changes that they want to see.

There will be many times where the product owner will understand additional needs more fully after seeing the demonstrations and will identify and discuss the changes that they want to see. As well, you can take advantage of this time to review any backlog stories and see if priorities have changed.

Here’s a sample agenda for the Sprint Review Meeting. Of course, your team may wish to modify it based on your needs.

Agenda

- Product Owner identifies what has and has not been done
- The Development Team talks about the Sprint and discusses:
  • What went well
  • Problems that came up
  • How the team solved those problems
- The Development Team demonstrates completed work and discussed product backlog items
- Product Owner discusses current backlog and plans completion dates with various completion rate assumptions
- All attendees discuss previous agenda items and how they could affect what to do next
- All attendees provide vital input into Sprint Retrospective Meeting or next Sprint Planning Meeting

Courtesy of agilemethodology.org, this video series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 5 - Sprint Review Meeting - and be on the lookout for more videos in this series over the next few weeks.

P.S. Let us know what you think. ​
3 Comments

Three questions to development success - the daily scrum meeting

6/19/2015

1 Comment

 
Wouldn't it be great if every morning you started off asking yourself three questions:
  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?

These three questions help to prepare and provide a guideline for your day. This is exactly what a Scrum or "stand-up meeting" accomplishes. These short meetings keep the development team on track to accomplish the goals agreed on during the Sprint Planning Meeting.

Usually taking place at the same time and place every working day, scrum meetings also promote closer working relationships between team members, which, in turn, creates a better product for the customer.

While there are a lot (and we mean a lot) of examples out there on how to best conduct a daily coordination meeting, the best advice we can give is to find the outline and platform that works best for you and your team. Sometimes, just a quick 15-minute meeting every morning is enough to get the juices flowing as it were for the day. Sometimes, you’ll have to pass around a token for the person speaking to hold and limit their time. And sometimes, you’ll actually need to have your team stand. Use whatever works for you just as long as you follow the three questions of the meeting:

  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?

Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 4 – Daily Scrum Meeting - and be on the lookout for more videos in this series over the next few weeks.
1 Comment

Coordinated planning = project success

6/16/2015

2 Comments

 
When you’re working within the agile development process, the team’s goals and tasks are accomplished within a “sprint” framework. Simply put, a “sprint” is a designated amount of time – usually two weeks – where your team decides together what will be completed during that time. On the first day of each sprint — often a Monday morning — the scrum team holds the sprint planning meeting.

Very much a collaborative effort, the Product Owner describes the highest ordered product backlog items then the team determines and prioritizes what is necessary to complete those particular tasks. Team members volunteer to own the work and work owners estimate the ideal hours they need to finish.

Sprint Planning Meetings are made up of two different parts. Part 1 focuses on what the team is being asked to build and is attended by both the product owner and the team. Part 2 focuses on how the team plans to build the desired functionality. And, although the entire team must attend Part 2, attendance by the product owner is optional. 

In Part 1, the product owner has the opportunity to describe a desired set of “stories” to the team. This is a deep-dive session on what the product owner would like to see developed. The product owner presents the stories, shows how things interact and walks through the interface. Additionally they may review infrastructure or architectural items. The goal is to inform the team with as much information as possible so they can determine how to best build the functionality. Types of questions typically asked include: 


  1. “What is the acceptance criterion of all of these stories?”
  2. “What data sources do you think we are using?”
  3. “How should the interface look on this component?”
  4. “What are you expecting from the user experience?”

During Part 2 the team then turns its attention to building the “sprint backlog”. This is the list of stories and the tasks required to complete them during the sprint. To build the backlog, the team breaks down each story that the product owner has requested to the task level and then each task is given an hourly estimate. By the end of Part 2, the team decides which stories it can commit to completing during the sprint. Together, the two parts of the sprint planning meeting can take anywhere from two to eight hours. 

Accomplishing what you set out to do

As long as the team leaves the Sprint Planning Meeting committed to completing a list of stories, the team has accomplished what they set out to do. Getting the team to the point where each team member feels comfortable making that commitment, however, requires a bit of pre-planning and facilitation.


The product owner must come to the meeting able to describe a set of desired stories. The team’s objective, then, is to understand the stories from the product owner’s point of view and share in the product owner’s vision. The ScrumMaster should ensure that the team is asking enough questions and capturing all of the resulting data, including acceptance criteria, sketches, and any assumptions. The ScrumMaster should also let the product owner know that the team might have additional questions after it begins to break the questions down into tasks. And finally, although the product owner presents stories s/he believe the team can complete within a given sprint, the development team will ultimately decide whether it can, in fact, take on all of the stories based on what it learns during Part 1 and Part 2 of the sprint planning meeting.

Here’s a sample Sprint Planning Meeting agenda


  1. Product Vision and Roadmap [Product Owner]
  2. Development status, state of our architecture, results of previous iterations [Team members]
  3. Iteration name and theme [ScrumMaster]
  4. Velocity in previous iteration(s) [ScrumMaster]
  5. Iteration timebox (dates, working days) [ScrumMaster]
  6. Team capacity (availability) [Team members]
  7. Issues and concerns? [ScrumMaster]
  8. Review and update definition of Done [Team members]
  9. Stories/items from the backlog to consider [Product Owner]
  10. Tasking out [Agile Team]
  11. Issues, Dependencies and Assumptions [ScrumMaster]
  12. Commit! [Agile Team]
 
Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 3 - Sprint Planning Meeting - and be on the lookout for more videos in this series over the next few weeks

2 Comments

A little trimming never hurt anyone... backlog refinement

6/11/2015

3 Comments

 
We've all seen overgrown gardens; plants that have grown in all directions and are completely unmanageable. A little bit of trimming here, removing dead leaves there and you now have healthy plants. It's the same principle in Agile software development with "backlog refinement".  

Backlog refinement is a core planning activity in Scrum and is an on-going activity throughout the project to constantly improve the process and ultimately output a better product.  Most projects will have a product backlog (that which is wanted but not a priority during a sprint). Product backlogs are constant and ever changing as new ideas flow in, existing product needs are refined, new discoveries are made, and priorities and business need change throughout the project timeframe.

So how do you successfully refine project backlog? Here are a few tips to get you started:
 
  1. Prioritize, prioritize, prioritize. Everyone wants everything in their project. If you follow a few items, such as customer and business value, along with improving the quality of the project, you’ll be well on your way.
  2. Examine stories frequently. The great thing about Agile development is that it can change based on your priorities. Never again must development teams wait until the very end to see if what they’ve developed is right. The trick is to scrutinize stories to ensure they are getting you the best result.
  3. Schedule refinement meetings frequently. This keeps the entire team engaged on what should be occurring and what could occur (see #1).
  4. Refining is planning. If you refine what you are doing, chances are, you’ll get to your successful end goal quicker.
  5. Never cancel refinement. Ever. Seriously. The team has to be able to refine their priorities (see #1) to ensure that the best product / project is produced. One expert suggests that if you find your spring planning meetings lasting longer and longer, you’ve probably been under-refining. However, if you are doing enough refining, your sprint planning meetings should be effective, focused and short.

We take backlog refinement one step further and work with you to take care of the product by removing unwanted features and defects and other items that are no longer necessary. This ensures that that only valuable features are prioritized and move forward.

Link to video 2 here. Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Let us know what you think about backlog refinement in the comments below.
3 Comments

Best practices in agile development - blog series

6/9/2015

1 Comment

 
At Latitude 40, we develop your custom software development projects using the agile development methodology. This is very different from traditional development approaches where you must wait until the end to view the completed software project. Agile empowers you to be involved in the development process from day one. The benefit is that projects are completed more efficiently and with better quality than traditional methods of developing software.

Because we use this method of software development, we thought we'd bring you a series of videos through our blog that take you through the stages of the Agile process. Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 1 and stay tuned for more videos in this series over the coming weeks.

I also want to hear from you; your thoughts and musings on Agile. Let me know what you think.
1 Comment

Musings on common tech stacks for the IoT (Internet of Things)

6/4/2015

1 Comment

 
In a series of new reports released this week, the industry analyst group IDC stated the worldwide market for IoT spending will grow from $655.8 billion in 2014 to $1.7 trillion in 2020. That spending includes devices, connectivity, sensors, platforms, and software. What’s interesting to me about this number is that the majority of the spending will come from the enterprise and not from the general consumer which tells me that the enterprise has made the decision that IoT is here to stay.

Which leads me to think about the notion of a common tech stack for IoT applications. The IoT vision is vast, but there’s little consensus around best practices and those all-important common tech stacks. Most of today’s IoT projects are highly custom and project teams are forced to choose between proprietary platforms or re-invent the wheel each time. And while that is not optimum, that is where we are in the development world.

There are those out there that want to create, or even force a common tech stack for IoT technology. I understand the desire but frankly I question the viability, especially at these early stages. We are at the point now where software development cycles have moved from six-nine months to three-four months and sometimes even quicker than that. The new demands of our "always on" society is insisting on new and better ways to deliver software and all of the benefits behind it so the argument could be made that a common stack would lead to even quicker development timelines.

I’m just not so sure about this. The bottom line for me is that we are truly at the early stages of this. IoT conferences and hackathons are popping up like so many new websites did back in the mid-90s. And this is great. Developers get to participate with industry experts to begin to define what the standard may look like in addition to all of the interoperability requirements that will help to drive IoT forward and continue to make it viable.

For those of us that have been around a few “development generations”, this is yet just another juicy problem to be solved. As developers, we love taking seemingly complex and impossible tasks and turning them into viable solutions. Candidly, these complex problems are what we are solving for the business anyway… without the Internet of Things. 

So what does all of this mean for the average business – or for that matter – the development community? First off, don’t panic and don’t believe as though you can’t do anything right now. You can still develop IoT applications and technology. Second, contribute. The only way we as developers and thought leaders will solve these challenges is if we all work together; talk to your fellow developers and the business. Find out what’s needed and what problems they are trying to solve. And last, but certainly not least; don’t let any of this stop you. We all have a passion for problem solving and we will all fall many times before we walk and then run. 

We can do this
1 Comment

I've got a couple of thoughts... CQRS and custom development

5/23/2015

2 Comments

 
When marketing asks me to write “thought leadership” blogs, I generally cringe. I’m a developer at heart and not necessarily a thought leader. I think about ways to use my skills as a technologist and a software developer to create thoughtful and impactful software applications that help businesses grow, evolve, better use processes and so on. Thought leader? Meh.

But then the thought struck me. What if, with all of the applications Latitude 40 has built over the years, I did have some ideas I could impart to the general interweb as it were. I mean, the reason why I got into custom software development – and built a business around it – in the first place, was because I saw and experienced the severe limitations of forcing businesses within an industry to run on the same packaged software and therefore the same processes as well. Businesses need to at least have the option of working on their internal processes as that is one of the best ways to outdo your competition. Now granted, there are some circumstances where packaged applications make complete sense; word processing is one example. But even in that instance, it could be argued that organizations could deploy many open source and custom developed word processing applications that better fit a particular industry or use case.

But I digress…

Here in the Denver area, we have a burgeoning custom software development community and I regularly attend and participate in developer forums and conferences so that I can keep up to date on some of the latest and greatest that’s out there and what my developer colleagues are working on within some of the most well-known brands. One such architecture is Command Query Responsibility Segregation (CQRS). Now for those of you in the business community, you may have no idea what that means – but you can absolutely benefit from it. My developer colleagues will say, “but that’s been around for a while now… what’s so new about that?”

To start, let me give a quick rundown of what CQRS is and then put it into context. The main purpose of CQRS is to assist in building high performance, scalable systems potentially with large amounts of data. The pattern states there should be complete separation between "commands" that perform actions and "queries" that read data. Traditionally, all of these functions are built into a single set of components utilizing a single data store.  CQRS has you build those commands and queries out into completely separate architectures so you never have one side bottlenecking the other.  

So what does this mean to a business person? Well, simply put, this concept is solving traditional software problems in a new way that can help provide higher transactional volume and greater performance with lower infrastructure costs. Let’s take an online merchant as an example. As we know, the customer does many different things when deciding what (and when) to make a purchase. They may browse inventory, put items into their online shopping cart, take other items out, set up multiple shipping addresses and payment methods, etc. These are mainly actions, but the user requires sophisticated pages presenting all the information they need (by querying) to decide how to act. By keeping the queries needed to generate these user-friendly pages segregated, it’s easy to optimize them for ultimate performance without having to fit action requirements into the same models.  As you can probably imagine, all of these “queries” and “commands” put a lot of strain on the system. By segregating these types of actions, not only can the online merchant improve the overall customer experience, they can also optimize the infrastructure for each by adding/removing cloud resources, as needed, for the queries and commands separately as transactional volume increases/decreases.

Another idea which I find fascinating is the strengthening of task-based user interfaces (UI). Let’s go back to the example of the order. A tasked-based UI is more about capturing the “intent” of the user. Those events – changes to shipping addresses, added/dropped shopping cart items and so on – can be recorded and saved in a way that can be analyzed to better understand the customer and their intentions.

These types of analysis certainly sound like business intelligence of old. Does this mean that business intelligence is back? It certainly is but from a more interesting perspective. As we know, BI is an amazing concept and data mining tools are now extremely prolific. In terms of actually implementing it, things have fallen really short or have only been available to the largest of companies because of its complexity and cost. Also, these mining tools are great, but are only as valuable as the data available to mine. By storing all of these events as a historical representation of state, you gain the ability to recreate the entire history of that aforementioned order at will, allowing you to analyze it at every single state it’s ever been in, not just its current state. This gives us the ability to ask questions in the future that we might not even be thinking about asking now. Utilizing these techniques, what was super expensive and difficult just a decade ago is now possible for most businesses of many sizes.

I really enjoy looking at these types of business challenges with technology – custom application development at that. Custom application development is happening now at some of the largest online merchant organizations, one’s that sponsor Thanksgiving Day Parades and others that had their start in selling shoes. The great thing for businesses that may not have a multi-million dollar development budget is that they can take advantage of these types of solutions now as well. What I always tell people who are looking to solve these types of business challenges with technology is to partner with someone who will be your trusted advisor for the long term and someone who can see the bigger picture, rather than a one-off development project. 

I’m interested to hear what you think about where custom software could take businesses and organizations. Email me or comment below
2 Comments
<<Previous

    Author

    Andrew Anderson
    President - Latitude 40

    Archives

    May 2020
    August 2016
    June 2015
    May 2015
    September 2014
    July 2014
    June 2014
    January 2014

    Categories

    All
    Agile
    CQRS
    Custom Vs. Off-the-shelf
    Data Mining
    Event Sourcing
    IoT
    Scrum
    Task Based UI

    RSS Feed

Copyright © 2020 Latitude 40 Consulting, Inc.  All rights reserved.
Latitude 40® is a trademark of Latitude 40 Consulting, Inc. All other trademarks are the property of their respective owners.
privacy policy
terms of service
customer login
Picture
11001 W. 120th Ave. ​Suite 400
Broomfield, CO 80021
303-544-2191
CONTACT US
Colorado - Entrepreneurial by Nature
  • Home
  • Company
    • About Us
    • Philosophy
    • History
  • Services
  • Buzz
    • Blog
    • Case Studies
    • Testimonials
  • Contact