How Relative Story Sizing Won Me Over

RJ Dela-Cruz Agile, Consulting, Dev Methodologies, Problem Solving Leave a Comment

Anyone who practices agile methodologies such as scrum is going to be very familiar with the practice of story pointing user stories (also known as poker planning). The good ole’ fashion 4, 8, 13, etc. Fibonacci sequences we assign to user stories of a sprint.

If you’re not familiar, it’s where the team gathers together to discuss the user stories to bring into a coming sprint and assigning each a number called story points. These story points are estimates that represent the level of difficulty and time it is expected to take to complete the story.

The team often will have discussions on whether a story is a particular story point number and argue their point of view until the team comes to an agreement to what story point it should be. I’ve done this type of work estimation for a long time that it’s natural for me… until we did something a bit different on a scrum team that I was a part of.

In this blog, we discuss a different way to assign poker points to user stories that could be beneficial to your scrum team – relative story sizing.

Documentation: Enough Already! Not.

Mike McCoy Consulting, Other, Problem Solving, Soft Skills Leave a Comment

Documentation. I know we all hate having to create it. I don’t like writing it and feel like I always leave something out. However, our assumptions of what other developers should think we are trying to accomplish by our masterpieces of software are usually filled with potholes (sometimes big ones). The truth of the matter is that no matter how stellar your code or software is – if you’re the only one who understands how it works, it doesn’t do any good.

These are not paintings or sculptures that would live the rest of their days in a museum, untouched by human hands and just collecting dust as they run. In reality, documentation will be added to and changed as the information they describe evolves.

In this blog, we discuss two suggested strategies for the creation of useful and concise software documentation.

Strategy: Knowledge Transfer In Consulting Projects

Josh Green Agile, Consulting, Dev Methodologies, Soft Skills Leave a Comment

Imparting Knowledge And Preparing For The End Of A Contract

In this blog, I share an example of a consulting engagement that required significant knowledge transfer to new hires. We detail an approach for teaching Spring Batch to developers with no previous experience in Java or the Spring Framework.

The goal is to provide a real-world example of closing a contract, imparting knowledge with the client and their employees, and the potential issues faced in the process.

Microservices Anti-Patterns

Dallas Monson Agile, Consulting, Microservices 1 Comment

Microservices? Yeah, you’re doing it wrong.

Microservices is a silver bullet, magic pill, instant fix, and can’t-go-wrong solution to all of software’s problems. In fact, as soon you implement even the basics of microservices all of your dreams come true; you will triple productivity, reach your ideal weight, land your dream job, win the lottery 10 times, and be able to fly, clearly.

While this sounds like a lot of hyperbole wrapped up in some BS, if you have been listening to anything around microservices recently you will most likely have heard something not too far from this exaggerated sentiment – especially if it is coming from sales folks.

As a result of this, you or someone you know will likely have been charged by management to implement a solution in microservices or refactor an existing application to take advantage of microservices to ensure that you get all the magic. With so much overinflation of the truth out there, chances are you may have also implemented a microservices antipattern. These antipatterns are actually more common in the wild than fully functional microservices architectures.

Overview
In this post we will cover the most common antipatterns that I have witnessed in the wild:

Break the Piggy Bank
Everything Micro (Except for the Data)
We are Agile! a.k.a. The Frankenstein

Each one of these results from a common misconception. We will do our best to define these patterns and their symptoms. After each, we will also show a way out of the mess so that you can recover and begin to move towards a better implementation. Let’s get started!

Keyhole Software Earns AWS Consulting Partner Status

Keyhole Software AWS, Company News, Consulting, Keyhole Leave a Comment

We are proud to announce that Keyhole Software has earned its status as an Amazon Web Service Consulting Partner.

Keyhole Software is now a Standard Tier Consulting Partner in the Amazon Web Services (AWS) Partner Network (APN), joining an elite group of technology partners nationwide. The partner network consists of professional services firms that help customers design, architect, build, migrate and manage their workloads on AWS platforms.

Keyhole earned the APN Standard Consulting Partner designation due to a demonstrated level of expertise with the AWS platform through a combination of customer testimonials, professional certifications, and investments in employee educational programs. Companies that have gained this status have demonstrated deep expertise in delivering customer solutions on AWS….