Posted on

How Data and Analysis Can Power Agile Teams

When working on projects in an Agile framework, it can be easy to fall into a routine of simply ‘going through the motions’ during Scrum rituals. A project team can settle into a plateau with the repetitive nature of Sprint cycles and associated practices. You may notice that your team performs the rituals as scheduled, yet the core goal of each method has been forgotten. This creates a risk that little value is extracted from each activity, meaning that they no longer provide insight and incremental improvement.

This risk is exceptionally high and standard during Retrospective rituals, especially if the team becomes focused on their achievements during the Sprint rather than exploring opportunities for improvement. When Retros are not conducted in-depth, a huge opportunity is missed – to keep the team performing well and take their performance to higher levels.

Posted on

How Automation Activates Agile

Harsh, yes... but too often true. Certainly, Agile is a great start for business user collaboration to ensure requirements fit, but it depends on Working Software. This is exactly what automation provides: Working Software, Now. Here's how.

Overview

This article illustrates how Automation, coupled with an Agile Process, can dramatically improve time to market, and reduce requirements risk:

Posted on

How Prototyping Saves You Key Development Time

Developing websites and apps for your business takes time. Don’t waste precious time relying only on developing alpha, beta, and final release models. There are more than 3 stages when developing a website or app. Prototyping is the blueprint stage of creating a product when designers go from laying the foundation for the design to creating a lifelike replica of how the website or app should work.

When prototyping, there are many stages, such as creating the user journey, creating basic sketch outlines, and creating the prototype app with real animations and interactions. Using prototyping is faster than developing because of basic concepts such as drag and drop that help product teams quickly develop a webpage from scratch. Below are five ways prototyping helps a product team and the overall product be more impactful on the targeted audience.

Posted on

The Case for Software Architecture Makeover

A few years ago, a friend of mine shared with me a white paper that he thought would interest me. This paper described the concept of distributed application architecture through small self-contained application components deployed across a larger corporate network. Eager to impress my friend, I put down the article and exclaimed: “I know where this is going, microservices.” He smiled and replied, “Look at the published date.” To my astonishment, the white paper was published in the late ’90s on the subject of the then relatively new technology called Enterprise Java Beans (EJB).

Sometime later, I hosted a technology leadership forum at a major insurance company in New York. One of the key discussion points included emerging technologies, and of course, microservices. I used the “EJB” anecdote with a profound (sarcastic) conclusion that software architecture styles and patterns do not drastically change, but rather evolve, while software reference application architecture based on a particular technology stack has a lifecycle of emerging, mainstream, and legacy.

Posted on

Use the 7 Product Dimensions Model to Guide Product Discovery and MMP Design

In their book Discover to Deliver: Agile Product Planning and Analysis, authors Ellen Gottesdiener and Mary Gorman introduced a simple and powerful model to guide product discovery effort – The 7 Product Dimensions model. This model identifies 7 areas (product dimensions) that we will need to explore – through collaborative questioning and reflection – in order to learn more about the product. The dimensions are User (who the users are), Interface (how they interact with the product), Actions (what they can do), Data (what data the product needs/stores in order to work), Control (rules & constraints), Environment (platforms that would host the product/on which value will be delivered), and Quality Attribute (customer’s expectations around quality, usability, etc.). The premise is simple: if we ask good, powerful questions about each of these dimensions, we’ll learn a great deal about this product we want to build, which will help us build a better product. You can find more information about the 7 Product Dimensions framework and canvas Here[1]

Here are some of the questions that we could ask to discover more about each product dimension:

Posted on

Agile Localization: What Is It and How Is It Managed?

Today everything that can be agile is going agile. Agility has become a bonafide IT mantra for every process in the software development life cycle. Localization, as an essential part of product creation, is no exception.

Localization is often treated as an after-thought. Only when the development and testing are finished do teams start to think about localizing their software. However, when you relegate the localization step to the last minute, you risk missing deadlines and, worse, releasing a product that is not quite ready for worldwide launch. 

Posted on

Velocity is the Most Dangerous Metric for Dev Teams

Agile Velocity is arguably the most popular software development metric in the world. It's a very powerful metric when used for individual team sprint capacity planning. And there are two things we know about power... it comes with great responsibility and it corrupts.

When agile velocity is used for anything other than individual team sprint capacity planning, very bad things can occur. In fact, when misused, Agile Velocity is the most dangerous metric for software development organizations. Unfortunately, every day Velocity is abused by executives, engineering leaders, product leaders and even developers.