Tag Archives: agile

Innovation doesn’t always have to be a revolution

On October 19th I will be presenting at QUBE’s inspiration session. I would like to invite you to join the virtual event. For more information and to register visit: http://qube.cc/inspiration/

I would expect that any business could innovate incrementally in the way I’ve just been describing in my blog series, and many would find it vital to do so. Yet organizations can easily find themselves stuck when it comes to innovation. They don’t always realize how much they can gain right now from moving forward, or how much they have to lose should others overtake them.

For many businesses, when it comes to IT, the type of innovation to focus on could be improving user experience, making them more efficient, by creatively using and connecting what is already there. This in turn can contribute to a virtuous circle of growing business agility and innovation. By becoming more agile about the way they innovate with technology, companies can become more responsive, freeing themselves up for business innovation.

Mobile is one of the most important ways to unlock innovation. The first step of moving existing capabilities to mobile isn’t necessarily very innovative; however, it can lead to many innovative possibilities.

Could moving some functionality to mobile unlock innovation and hence agility for your business? Is there some other evolutionary step you could take that would do the same?

This series is based on the paper: Agility and Innovation in Application and Mobile Development.

You can download the paper here.

SCRUM to strategically win from the competition as pit stops do in F1

Congratulations to Max Verstappen on winning the Malaysian Grand Prix last weekend. You see, strategy pays out when everything falls into place.

Uniface Formula 1

So, my drive 😉 is to apply scrum in your business strategy to win the race too.

So in F1 the pit stop, besides being a masterly synchronized ballet of disciplined execution and expertise, the pit stop is used strategically by the team to win the race. How? The amount of pit stops depends on the desired lap time while gauging fuel consumption, tire wearing out, undercutting (taking over a car while making the pit stop or leaving one). With the above in mind the team determines to use certain amount of pit stops, or to add one more in order to win.

In SCRUM terms, the sprints are the perfectly synchronized production of software which can be strategically used to deliver value to our customers. Whether we deliver features gradually or change the order of delivery as to meet business value.

Here at Uniface, we are busy trying to get SCRUM to the next level where alignment between business and IT are essential to make a difference. We must be aligned to adapt to change and therefore better serve our customers. In that context, we already have a track record as we have been using SCRUM for more than 9 years and have done the necessary improvements to the processes ourselves.

As an example, we have even invented our own ceremony to facilitate the alignment among teams called  a Sprint Pitch (an already 3-year-old ceremony for us).

To stress why aligning the business with IT is important, I want to emphasize the analogy from the F1 championships; I was inspired to use it when watching a Red Bull documentary about “The history of the pit stop” during my last flight.

You know the thrill of changing tires and refueling the car in the shortest amount of time possible?

In the early days, the pit stop was just a pause that took up to a minute, there was no changing of tires. That came in the 1970’s when an unplanned pit stop to change tires would take 3 to 5 minutes. In the early 1980’s Gordon Murray turned them into the strategic pit stops, considering the car weight, the tire degradation and saw a relation on how all that influenced lap times. At that moment another race began, the one to bring the pit stop’s time down to the minimum. In order, to use the pit stop more strategically and make the time necessary for a pit stop negligible.

Well, it is no surprise that to reach the shortest time, it took analysis, collaboration, improvements to get to the changing of the tires or better even the entire wheel set and refueling the car, cooling the car’s engine in just under 2 seconds. Bear in mind that actually it takes a crew of 18 to 20 highly skilled individuals to handle a pit stop.

You may wonder how do we do that in SCRUM at Uniface, but first time for a pit stop … (to be continued)!

Keeping up with technology…a lot like Formula 1

Uniface, being a low-code platform which shields developers from technology changes in the application stack, takes pride on staying on top of the leading edge of technology. To start, the application stack I refer to is based on the Open Systems Interconnection model (OSI) defined by the International Organization for Standardization (ISO) about the interoperability and communication layers. So all the technologies needed to maintain applications’ interoperability while communicating to achieve the business goal as programmed by the developers.

In Uniface development, we have a track record of keeping up with technology, nowadays more challenging than 33 years ago when Uniface started of course. 😉

Let me share how Uniface development approaches technology and technological paradigms. Uniface is a technology partner for our customers and partners. As such, we take pride in actively participating in the technological world around us, which should add value to our customers. It also reinforces our relationship with technology resulting in the Uniface direction. Additionally, and with the intention of being transparent, we blog about it.

I want to start by making an analogy between Uniface and Formula 1 (F1 Championships). In F1 racing there are also a lot of technological developments on which all car manufacturers and teams rely on (powertrains, ERS, ES, power units, tire compound, telemetry, DRS, KERS, chassis, etc.). Actually all of the participants follow the evolution of these developments actively or passively depending on their area of expertise (additionally sanctioned by the FIA).

It is the same in our application development world, there is a lot of technology involved and we do actively follow it. Essential to that and following the Uniface value proposition, we need to be up to par with the latest trends in what applications need from technology.

Following our analogy, the Uniface car might today have a power unit from Mercedes, while we simultaneously look at the power units from Ferrari and Renault.

The Lab and the engineers look at all technologies and we make sure that the leading edge in technology is used by the car we build (Uniface) because that is what makes us different. Product Management makes sure that our customer requirements plus the technology innovations are included in the Uniface portfolio.

I think that all of the above confirms to our customers the value Uniface provides is much more than one mere technology, but they can be confident we are looking at a much broader spectrum of the application technology stack.

Rest assured that the direction that Uniface takes will be defined and determined by Product Management and reflected in the Uniface roadmap.

 

If innovation is so important, why isn’t everyone doing it? 

So why isn’t everyone innovating? Sometimes people simply get too comfortable with the status quo to try something new. Think how many users were reluctant to move from Windows 7, which admittedly let them do their job fine, to Windows 8, which some considered less perfect. But, once they were through the Windows 7/8 mourning curve, it was easy to change to Windows 10, with very quick emotional acceptance and significant benefits.

Another major reason for not innovating is that people have more pressing things to do, and this is no doubt true. Throughout life, we often hear phrases like: “I’m too busy,” “I’ve got higher priorities,” and “We have to clear the backlog.” Within the IT function, some technical teams are big enough only to keep up with day-to-day maintenance, leaving no scope to craft new solutions or modernize legacy applications. Large organizations may also find they spend too much time and resources “keeping the lights on,” with little left for innovation.

Innovation

A Catch 22 situation then arises, because by not moving forward, it becomes harder to deliver. This can lead to a failure to give the organization the business agility it needs.

Another reason for failure to innovate at the right pace, is that for many organizations, it’s difficult to make innovation work. As discussed in a recent article by Anderee Berengian, the innovation lab model has often failed. I’m going to elaborate on Berengian’s conclusion that “real innovation comes from outside your company,” as although that may be true for some, for the rest of us there is an alternative.

In my first blog post I addressed the question: What comes first—innovation or agility? In my next post I will look at 3 approaches to innovation for organizations.

This series is based on the paper: Agility and Innovation in Application and Mobile Development.  

You can download the paper here.

What comes first: innovation or agility?

The question of why innovation and business agility are vital –and independent is one that is top of mind for many organizations.

Business agility is essential to survival. With economic uncertainty everywhere, and disruption in many marketplaces, businesses need to respond fast to change. A key enabler for this ability is an IT function that is inherently good at innovating. IT must produce ingenious ideas that will facilitate the required fast business response, for example by equipping the workforce for mobile working. There are any number of innovative uses of mobile technology: for example, a sales person can take and personalize an order while walking around a shop with a customer; a doctor can receive real-time information about a patient’s vital signs.

IT innovation is essential to business agility. However, you also need agility before you can innovate in IT or anywhere else. Which comes first is hard to judge. Organizations tend to start life with both agility and innovation. However, as they get bigger, their agility tends to become constrained for various reasons. Hence their rate of innovation declines, creating a vicious circle.

Innovation and agility

Complex though the relationship between innovation and agility is, we can probably agree that both are vital to a healthy business, and particularly vital when a business is contemplating digital transformation (where the organization rethinks aspects of its existence to take full advantage of digital technology, rather than simply automate the existing way of working). Digital transformation implies that a business must be able to innovate digitally to overtake the competition, with enough agility to reshape itself around the resultant landscape. An agile IT department has the ability and opportunity to create what the business needs – or else to go out and find it fast.

This blog post is the first in a series based on the paper: Agility and Innovation in Application and Mobile Development.

You can download the paper here.