Why Event Storming?

John Hoestje Dev Methodologies, Opinion, Problem Solving Leave a Comment

My last Event Storming blog was like a stew I made by throwing in everything from the fridge and pantry. Maybe the stew was okay, but most of the individual ingredients got lost in the mix.

This time, I’m including the points to back my position as to why you should start using Event Storming now. Although, in my opinion, choosing Event Storming doesn’t take a lot of convincing to make it sound more appealing than other techniques.

So why should Event Storming be used in place of other more established domain modeling processes?

While it isn’t beneficial to always try out the latest and greatest whiz-bang gadgets, not keeping tabs on emerging and promising trends can prevent your team from becoming more efficient…

Java Development Using Visual Studio Code

Todd Horn Design, Dev Methodologies, Java, Problem Solving, Programming Leave a Comment

Over the last few years, I have worked on several .NET and JavaScript projects. My go-to IDE for Angular, Node, and (in starting to learn) React has been Visual Studio Code, along with Visual Studio Enterprise for C#.

Recently, I started on a new team and project that was in Java. Our initial thought was to switch back over to Spring Tool Suite or IntelliJ. But, there are some really good extensions now for Java in VS Code that made that transition unnecessary. So we decided to take a look at what Visual Studio code could do for us – we were very pleasantly surprised!

In this post, I provide links and information to get you started down the right path for Java in Visual Studio Code.

Web Development Business

Refreshing Your Scrum

Keith Shakib Agile, Consulting, Design, Dev Methodologies, Problem Solving, Soft Skills 3 Comments

Most of us now have some experience with Agile Scrum practices. Many of us have had years of practice on multiple processes. As a consultant, I have the opportunity to see many differences in how organizations implement and practice the most popular development process methodologies.

While the prescription for good practices is well-documented, many of us have lost our “mojo” at least once and seen many of the benefits of using the process decline.

In this blog, I will indicate some key points required to return to optimal agile performance. I will highlight three common pitfalls, some common causes of those problems, and reminders of how to get back to a high-performance Scrum implementation. Let’s dive in.

Agile Perspective

Tim Broyles Agile, Dev Methodologies Leave a Comment

You may think of Agile as just another process. While this is incorrect (as it is a framework created to help developers create processes), there is a fundamental difference between this methodology and most methodologies that have come before.

Agile–done the way it was intended–is revolutionary. Fundamentally, Agile is an advocate of a bottom-up development process. I believe this is why it is often proposed with good intention, however then implemented with a top-down, fixed idea of what the Agile team (and hence the process) will be like.

If you take time to read the Agile Manifesto you will read statements like: ”The best architectures, requirements, and designs emerge from self-organizing teams.” Just consider that for a second. The team has the power to keep what works and dispose of what does not.

There are some basic concepts that allow Agile development to be successful. In this post, I highlight the key parts of Agile that appeal to me (as a reluctant process advocate) and have enabled successful Agile development in recent projects…

user story mapping

Every Agile Software Project Needs a User Story Map

Rusty Divine Agile, Microservices Leave a Comment

In this blog, I share an example of a real-world, agile enterprise modernization project that benefited from a User Story Map.

I’m the team lead for a project to convert a business solution from COBOL to a .NET microservices architecture. Other than some interesting challenges with designing a robust microservices solution, the business logic is very straightforward – input files are processed, databases queried, output files are produced and dropped in a folder, and our goal is to match the output produced by the COBOL solution perfectly.

Yet, we lost our way fairly early on in the project because we had a typical prioritized backlog. Unfortunately, even on a straightforward, well-defined project with an engaged team, we still managed to veer off course.

Our project manager started asking questions about where we were in the project and where we were going. I struggled to answer those questions because I couldn’t make sense of all that was in our backlog. It was around this time that I took a spreadsheet and created our first User Story Map….