SOGETI UK BLOG

Waterfall modelI have led many Agile transformations in the past few years for our clients. These clients, both IT and the business, were ready to change the way they developed solutions. The change required for such a shift caused much ‘pain’ in the organisation, but these clients knew that they needed to make the change.

During one of these engagements, someone on the client team told me that they had tried to convince another group at the company into making the move to Agile from their Waterfall approach. When the Waterfall group manager said he had looked at Agile and did not see the benefits for the business and systems he supported, the Agile advocate chided the manager for being “stuck in the mud” and that Agile would benefit the group greatly.

That’s not always right.

Agile has many great benefits, and I run all my projects that way … but that does not mean, “one size will fit all.” I have discussed with some groups, which were seriously considering Agile, but I dissuaded them from doing so, because they would have disrupted their business partners and throw away a lot of really good functioning processes.

The types of projects that benefit from Waterfall are:

  • Infrastructure migrations or installations
  • Application migrations
  • Enhancements for applications that have been in place for a long time

Waterfall projects work best when all or the majority of major requirements are known. Waterfall is a very rigid process, so by defining the scope and requirements upfront, the project manager/leader can define the project plan and create a clear vision and path to the end state. Additionally, having that clear vision allows the business or project funders to allocate the right amount of budget.

The key element of a Waterfall project approach is the scope. Once the project plan is defined and all things are known, then the scope of the project cannot change. Additionally, scope items can be added after the initial project is ended, or maybe in parallel by another project team.

So, if things are running well in your IT organisation, meaning the business is happy, projects deliver on time and under/on budget. Then I think you have a pretty good thing going and don’t need to “unstick yourself from the mud” anytime soon.

To read the original post and add comments, please visit the SogetiLabs blog: Sometimes it’s OK to “Waterfall”

Related Posts:

  1. Large, complex projects benefit most from Agile
  2. Agile series: The misconceptions
  3. 5 ways to get your Scrumteam gimped
  4. Will project managers survive the agile trend?

Leigh Sperberg AUTHOR:
Leigh Sperberg has been a consultant in the Dallas office since 2007. During that time, he has served as practice lead for Advisory Services, Microsoft and Business Applications practice. In those roles, he has supported customer engagements in the Texas region and nationally focusing on Microsoft technologies and enterprise architecture.

Posted in: Agile, Behaviour Driven Development, Business Intelligence, communication, Developers, Digital strategy, Infrastructure, Opinion, waterfall      
Comments: 0
Tags: , , , ,

 

handshakeI have been working with a company that is attempting to create repeatable innovation. So far, we have defined the innovation iteration (experiment, measure, decide, repeat) and have determined that we had the wrong approach for working with partners. These are the partners who provide services, software, hardware or ideas. The partners are not doing anything wrong; we just aren’t working with them in the right way.

The beginning of the innovation cycle is defining the vision/purpose of the experiment. What we failed to do was fit the right partner with the right experiment vision. It’s not that the partner did not offer the right thing, it is that we did not find the right partner personality fit for the experiment. The innovation lab is within a larger company, and we worked with partners from the perspective of the larger company… not the small, startup that the innovation lab really is. By doing that, we dealt with partners who expected defined process and solid direction. We don’t have that currently, so there was a miss on some of the innovation execution.

Below are some of the things we now keep in mind when looking for a partner, or to tell an existing partner about what we need from them. Even though these items were devised for a small startup organisation, I think these ideas are valid expectations of a partner working with larger organisations… or even internal groups dealing with each other.

Manage yourself – The startup has limited resources – not only people but time. The startup is trying to do many things at once and doesn’t always have time to keep a vigilant eye on the partner. There are times when the management of a project is in auto-pilot mode. That’s when a trusted partner keeps moving in the decided direction, without prompting, and over-communicates the status.

Be flexible – Small organisations are nimble since they don’t “weigh much”. The nimbleness can be a benefit that allows the project to discover requirements on the fly and to change directions easily. By not expecting a rigid process or static direction, the partner can be more flexible when changes come to the project. Because, that’s what innovation is about.

Tell me what you can do for me – In the beginning of the partnership, the partner does not know a lot about the customer. But in a short period of time, the customer’s needs become clearer. Instead of telling me about the services or solution you sell, tell me what you can do for me. Don’t sell, explain your abilities and how those fit with the project vision, or the organisation’s vision on the whole.

Tell me what I will get out of it – After learning more about each other, the partner should have a good idea of the benefits the customer should expect from the partner’s capabilities. The benefits need to be more tangible that soft, like cost savings as opposed to time savings. Also, improvements or better stability are welcome benefits.

What does success look like? – The partner is more familiar with its capabilities than the customer is, so the partner should be able to tell when their capabilities are starting to be used correctly to gain the benefit. So, the partner should tell the customer how to measure success, like better throughput or achieving a stated goal. The customer will also provide measurements of their own to describe when they are satisfied, but those measurements need to come after the partner defines their own.

To read the original post and add comments, please visit the SogetiLabs blog: THE POWER OF PARTNERSHIP

Related Posts:

  1. Repeatable innovation
  2. The Power of Prediction
  3. Using the power of networking to boost women in IT
  4. Competition on the web reshapes software product development strategies

 

 

 

Leigh Sperberg AUTHOR:
Leigh Sperberg has been a consultant in the Dallas office since 2007. During that time, he has served as practice lead for Advisory Services, Microsoft and Business Applications practice. In those roles, he has supported customer engagements in the Texas region and nationally focusing on Microsoft technologies and enterprise architecture.

Posted in: Business Intelligence, Innovation, Open Innovation, Opinion, project management      
Comments: 0
Tags: , , , , , , ,

 

at-your-serviceI was talking with some developers about overloaded terminology – like innovation, iteration, and agile – and the word “services” came up. Services means different things based on the context of the conversation, it could be an abstract term for some things that needs to provide some data or processing. It could also mean a technology choice, like a web service. A conversation about services with developers and business folks can get confusing since the concepts are much the same when developing a technical or a business service.

The technology of services has been around for a while, and the design pattern is relatively well known. But, I have found that many developers and architects have forgotten that to gain the benefits of a service, they must design the service in a specific way. Often, you find code that implements some framework, like Representational State Transfer (REST) or Web Services Description Language (WSDL), but the design and implementation is just a tightly coupled, single use remote procedure call (RPC).

So, as a public service, here’s a refresher of some service design principles. Keep these items in mind the next time you design or build a service, technical or otherwise:

Contract first – Determine how the service will provide and how other services can communicate with it. Sometimes a domain-specific language can be helpful in defining the interface, like a modeling language such as Business Process Execution Language (BPEL).

Loosely coupled/minimise dependencies – the service should stand on its own and not have a dependency on any other application or service. This principle can be implemented by making sure the service exists for one purpose. The service can interact with other services, but can still provide its purpose without any help.

Reusability – Some services are what I call “chunky” – they are very large interfaces and returns, and look like a ‘Select *’ query from a huge table. Reusability is not just “everything and the kitchen sink”. It means that many intra- and inter-domain will gain benefit from the service.

Stateless – The service should be able to finish its work and signal when done. The service should not have to keep track of time or state. That’s not to say that a service can’t be asynchronous … but let some other framework or platform service worry about state and let the service provide its function.

Discoverable – Within organisations, developers will email interface and functionality notes to others to allow them to use the service. Well, that doesn’t work outside the organisation’s walls. Use Universal Description, Discovery Integration (UDDI) to allow others to find the service’s interface and purpose “on-the-fly”.

To read the original post and add comments, please visit the SogetiLabs blog: AT YOUR SERVICE…

Related Posts:

  1. In the Architecture Office: Service-portfoliozation
  2. Service virtualization: new or old news for software testers?
  3. Taking the “Service” out of Customer Service
  4. Sensible sensing as a service, the moment is now

 

Leigh Sperberg AUTHOR:
Leigh Sperberg has been a consultant in the Dallas office since 2007. During that time, he has served as practice lead for Advisory Services, Microsoft and Business Applications practice. In those roles, he has supported customer engagements in the Texas region and nationally focusing on Microsoft technologies and enterprise architecture.

Posted in: Business Intelligence, communication, Developers, Innovation, Opinion, Technology Outlook      
Comments: 0
Tags: , , , , , , , , , , , ,

 

InnovationAs we all know, “innovation” is a popular buzzword for companies to describe how they are developing new services/merchandise for their customers. How they approach this development can differ: some  have full-time research and development (R&D) departments; some conduct focus groups with their customers; and some hold employee idea “jams” or brainstorming sessions. These companies are all trying to find the “next big thing” or to get ahead of their competition.

However, it is tough to create inspiration out of nowhere. And it is even tougher to try to manage it.

I am currently working with a client that is trying to create new ways to communicate with its customers and to excite them about interacting with the organisation. The client has several strong competitors, and even competes with several of its own partners for market share. While my client is top in its industry, they know they cannot just wait for new ideas to come to them … they must create them.

One of the first hurdles they faced was: “How can you be results-oriented with something as ethereal as inspiration?” It seems counter-intuitive to put structure around brainstorms is it tough enough deciding how to choose the idea that is the right one to pursue, let alone choosing it.

The client did their research with University students, consulting companies and entrepreneurs to find out how others had been successful with innovation. They found that no one had a good answer, so they ‘innovated’ a way to do it.

Here’s a high-level view into how they have been running a results-oriented innovation lab:

Keep it small – the organisation can’t be so big that it loses flexibility and cannot change direction quickly. The client has many partners who do a lot of work for them, but the client only has 2 people in their group.

Remember the purpose – define what you are trying to accomplish, then measure all ideas against that vision. Sounds simple, but you can spread yourself very thin very quickly if you lose focus.

Experiment – get the idea out into the real world fast. The world does not always work or react in the way you think it should.

Measure – look at the results of your experiment. What did you learn that was new? Does your idea of success look different retrospectively?

Decide – now that you have results, then what do you do? Keep going down the same path? Tweak something? Or just throw it away and try something completely new?

Rinse and repeat – if you stick with the original idea, then experiment again, measure it and learn again. Keep this cycle short in order to get results quickly.

Learn – success or failure all render education that must be used to influence the next iteration.

So far, my client is poised to put one of its first innovations into the marketplace, with two others just going into the ‘Experiment’ phase. This process is clearly working for them, and thso they plan to continue the innovation effort for the long term.

How does your company approach innovation? Let us know!

Leigh Sperberg AUTHOR:
Leigh Sperberg has been a consultant in the Dallas office since 2007. During that time, he has served as practice lead for Advisory Services, Microsoft and Business Applications practice. In those roles, he has supported customer engagements in the Texas region and nationally focusing on Microsoft technologies and enterprise architecture.

Posted in: Business Intelligence, Innovation, Opinion, Research      
Comments: 0
Tags: , , , , ,

 

Augmented_Reality_Marketing_San_DiegoLots of press has been generated on virtual and augmented reality devices and software recently. Two of the most commonly referenced devices are Oculus Rift, a virtual reality hardware and software company, and Google Glass, an augmented reality device. When Facebook bought Oculus Rift for $2B US, it signaled that these reality enhancing/replacing technologies were no longer just something for sci-fi novels. They are serious products that can be used in wide ranging ways.

First of all, what is the difference between augmented and virtual reality?Augmented reality (AR) is a layer on top of your surroundings – a mediated reality that enhances the view of reality with, for example, sound, video, graphics or GPS data. Virtual reality (VR) replaces the real world with a simulated one and totally immerses the individual in the generated world with sound, graphics and other sensory input.

Hardware – glasses, goggles and cowls – and software are being developed and improved rapidly. Battery life, and the size and weight of the devices are two priority enhancements that must be improved in order to guarantee wide-ranging acceptance by the public. So, who are the target audiences?

Initially, VR is aimed at gamers. The popular massive multi-player online space simulator, EVE, will be one of the first commercial products for Oculus Rift. Also, older games, like Doom from the 1990’s, are being revised to be played in a VR world.

Both AR and VR are being used in retail today to allow shoppers to see what furniture would look like in their home, how paint color looks on their walls and to try on clothes in a virtual changing booth. Also, in medicine, doctors are using AR devices to overlay a patient’s vital statistics and history during a consultation. And, a surgery has been performed remotely with the doctor viewing the patient and controlling a laser scalpel miles away with VR.

Construction, transportation, industrial design and many other industries will need AR and VR technology to improve their capabilities. Also, supporting business functions can benefit as well from heads-up displays, virtual meetings and real-time language translation.

In my office in Dallas, Texas, we have worked on several AR proofs of concept applications for retail customers. What are you working on in this realm or what are your customers saying about this technology?

 

Leigh Sperberg AUTHOR:
Leigh Sperberg has been a consultant in the Dallas office since 2007. During that time, he has served as practice lead for Advisory Services, Microsoft and Business Applications practice. In those roles, he has supported customer engagements in the Texas region and nationally focusing on Microsoft technologies and enterprise architecture.

Posted in: communication, Innovation, SogetiLabs, Technology Outlook, Wearable technology      
Comments: 0
Tags: , , , , , , , , , , , , , , , , ,