SOGETI UK BLOG

Microsoft Branch Revolution

Achieving some Windows 10 migrations, Sogeti Luxembourg is glad to announce its customers it tastes like a piece of cake  (compared to Windows7 ghost train). Sounds good to you? Sorry to inform that your Yepaaaa! won’t last. The reason?Microsoft Branch Revolution.

Some months ago, I shared with you 3 things to keep in mind for enterprises about Windows 10 migrations. And even if this new OS brings a myriad of new features, it remains a Workplace project with it’s so classical concerns: mobility, security, ergonomic and collaboration.

Remember Windows 10 will be your last real & global migration project. Microsoft introduced a new concept:Upgrades.
From now, Microsoft pushes new features on a regular basis.

Don’t be mistaken by Updates which remain
     (the 2nd Tuesday of each month)
and fix bugs and security vulnerabilities.

After a global survey, Microsoft went through 42% of its customers’ strongest request: no more bid deployment. So, they created a new Upgrade program. The kernel of your OS is indeed upgraded all the time. Meaning that your computer will be continuously migrated in a certain sense. You’ll get new features and new environment all the time.

Preoccupied by business continuity and the impact of such frequent changes, Microsoft has set up 3 different branches. Understand 3 different upgrade-run rhythms: CB, CBB and LTSB. I won’t go deep into each of them (just google these acronym and you’ll get all the details). Just keep in mind the following statement:

The Branch you choose will have a big impact on your business, your internal IT service management and your licensing bill. And you know what? You can’t elude the question.

You must choose between
  • Current Branch – MS gives the beat: Ongoing Automatic upgrades
  • Current Branch for Business – Slowing down the beat: Upgrades can be postponed up to 8 months before mandatory application
  • Long Term Service Branch – You give the tempo: No automatic upgrade application / Massive migration to envisage for future

Windows Branch Migration PathMoving from LTSB (the slowest upgrade program) to a higher Branch (CBB or even CB) can be done easily and seamlessly. On the other hand, if a company feels too overflowed by these frequent upgrades and wants to go slower (let say from CBB to LTSB) the only way to go is to operate a massive Windows migration from Windows 10 to… Windows 10. You have correctly read. There’s no typing mistake.

Everybody will migrate to Windows 10 for sure. Everybody. This being said, even if in the past Windows migrations used to bring its technical issues (compatibility, packaging…), today with this revolutionary Upgrade concept, CIO will be more facing out strategical issues. And the first one will be the Branch choice. Next, upgrade application strategy.  Then Devices, Windows lifecycle, BYOD…

You have called Workplace Experts, please hold on. You will shortly be answering…

Kamel Abid AUTHOR:
In summer 2014, Kamel Abid celebrated his 20th year as an IT professional, while swimming among computers and keyboards since the age of 5. Today, he manages tens of experts & architects, involved in complex transformation and integration of IT infrastructures in Grand-Duchy of Luxembourg. In parallel, as an Expert leader, Kamel animates Desktop & Unified Communication PMP through events, workshops, articles in newspapers, social media, etc. A native of Nice (french riviera), Kamel previously worked as Developer, System Administrator, Support Engineer, Project Leader, Bid Manager and then Delivery Manager. Hired at Sogeti Luxembourg in 2008, he passed through several in-house activities: Consulting, Bidding, Team Leading and now sharing knowledge as a domain Expert.

Posted in: Business Intelligence, Collaboration, Digital strategy, Innovation, IT strategy, Microsoft, Mobility, project management, Quality Assurance, Requirements, Research, Security, Software Development      
Comments: 0
Tags: , , , , , ,

 

people the key to success

As a tester, I have been involved in several software projects. Most of them have been successful, but I have also lived the other side of the story. Speaking from my own experience, I can say that there are different factors that can determine the success or the failure of a project:

  • Tools
  • Processes
  • Techniques and methodologies
  • Available technologies
  • Planning

Nevertheless, no matter how important those factors might be, the key that determines the success of a project is the team of people responsible for its fulfillment. In the end, software is made by people, not by machines. This seems pretty obvious, but we usually forget it and we keep on giving more importance to tools, processes and techniques. And what’s the point of having the most expensive and complete tool of the market and applying the newest technique if our team consists of unprepared people, who neither have team spirit nor motivation? How are we going to build high quality software if we don’t have a good team of developers and testers responsible for its design and its maintenance? Without this good team, our project has every chance of failing.

Unfortunately, at least in Spain, this is usual in a lot of companies. For them, professionals are just an accessory that contributes developing programs and they count on teams that don’t have the appropriate training, profile and qualifications required to fulfill their tasks, driven by the motto of minimizing the expense. That is, they look for the highest profitability, ignoring and despising quality. What turns out to be curious is that, when they fail, they don’t realize that the root of the problem is that they don’t have the right team and they keep on tripping over and over again on the same stone instead of changing the strategy.

So, if we want to have success in our projects, we must count on a team of professionals who have the required knowledge and who have the necessary experience. Besides, every person involved in the project must be completely committed with the group, must be clear about his role and his tasks and must work together to reach the common goal and, therefore, success.

AUTHOR:
Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

Posted in: architecture, Developers, DevOps, Digital, Digital strategy, High Tech, Human Interaction Testing, Infrastructure, Innovation, IT strategy, project management, Quality Assurance, Requirements, Research, Software Development, Test environment, Test Tools, Testing and innovation, Transformation, User Experience, User Interface      
Comments: 0
Tags: , , , , , , , ,

 

As we will have realized by now, DevOps is not a goal. It is merely a means (even better, a mindset) to achieve high-performance teams and organizations. DevOps enables cross-functional (x-silo) collaboration in and between your teams to support a continuously improving digital value chain. As a matter of fact, I rather speak of Value Flow than DevOps. But in the end, it doesn’t really matter how you call it. As long as you achieve your goal. So if it’s high-performance teams we want to achieve, which path leads us there?

I would say the path to high-performance has two axes: Value and Flow. If both value and flow are executed and adopted effectively, you will achieve high-performance. If there’s no flow in the team, but value is high, the organization will lack innovative power and feel bureaucratic. A team delivering low value, but high flow, focus on the wrong work, leading to burnout. A team without both flow and value is bound to become extinct.

27thjune-1

Value

So how can a team, or team-of-teams, deliver high value outcomes? In my opinion, just like the realization of value is a team effort, the same should apply to value definition. Specifically in complex environments, designed to deliver high-performing products and services, value is multidimensional. Surely, the business (the customer, the user) have a crucial voice in determining the required value. But we also need to utilize the knowledge and innovative strength which resides in the team and in its environment (e.g. suppliers, architecture, security). Most of the experiments and technology innovations do not come from the business. IT has an ever more relevant role in keeping the business competitive. The same goes for the prioritization of value. If we want to eliminate the burden and potential lead time damage of technical debt, IT will need to help the customer/business establish the right priorities and highlight the real value of work like refactoring or experimenting with new technology opportunities.

(If you want to learn more on how to define and measure value, please have a look at this series of blog posts from Julya van Berkel: http://labs.sogeti.com/how-to-measure-value-part-4/).

Flow

And what about flow? What does a team need to do to achieve a state of high flow? My experience reflects a lot from the practical application of the major principles from Don Reinertsen’s essential work ‘The Principles of Product Development Flow’. Think about the reduction of batch size, which is critical to achieving an end-to-flow in complex delivery networks. Although not all teams have an optimal batch size of 1, reducing the team’s batch size (also while deploying and releasing) has led to considerable improvements in lead times and MTTR (Mean Time To Recover).

Visualizing and limiting WIP (Work in Progress) is yet another fundamental instrument, which has given many of my teams an extreme boost in optimizing their flow. I found out that consistently visualizing the work and identifying/exploiting bottlenecks helps any team in achieving flow.

Finally, flow is achieved through eliminating as much queues as possible. In any organization queues are everywhere, eg. Product Backlogs, service desk call queues, personal to-do- lists, etcetera. The more you apply DevOps principles (such as fast feedback and multidisciplinary teams), the more you will be able to consolidate and reduce queues in the entire end-to-end system.

So, if your CIO turns to you and asks for your view on ‘how to move towards DevOps’, make sure to emphasize the need for an optimal balance between value and flow. More information on DevOps, flow and high-performance value networks, inlcuding several examples, please have a look at this recent report on DevOps and Digital Disruption.

AUTHOR:

Posted in: architecture, Business Intelligence, DevOps, Digital, Digital strategy, Innovation, IT strategy, project management, Quality Assurance, Requirements, Research, Security, Software Development, Technology Outlook, Test Driven Development, Transformation, User Experience, User Interface      
Comments: 0
Tags: , , , , , , , , , , ,

 

Building great apps and achieving high ratings isn’t easy. Developing apps require new skills in different fields of expertise as I have already explained in one of my earlier blog posts. But how can you improve once your apps have been pushed out to the stores? There are many ways to find improvements for your apps and analyzing your feedback loop could be good starting point.

Collecting feedback is an important activity as it will help you prioritizing on app improvements in your product roadmap and release planning. This feedback can be used to support your business case for necessary changes and updates. And this is crucial to obtain budget for new releases and keep on innovating your app. There is not an unlimited source of money available so the development team should figure out where to focus on and how to report this to the respective business owners.

app-feedback-loop

The product owner will eventually convert improvements into epics or stories on the backlog for the development team. Once prioritized both the product owner and scrum master can start working on a clear set of requirements for the developers and add the stories to the sprint backlog. Getting the right information out of your feedback loop is a continues activity in your app development process and crucial to maintain focus. Below are a few pointers that should help you getting the most out of your feedback loop.

1. Learn from other apps

There are plenty of existing apps out there and in most cases you will find similar apps in the same category that have very good ratings and a high adoption rate. You can use these as a benchmark for your apps. Most apps use common design patterns for i.e. registrations, integration with 3rd party apps and services. Next to that Google and Apple regularly promote apps with a successful implementation of platform specific design guidelines that app users are familiar with.

When useful?
Doing benchmark research doesn’t require much time and it is very useful to get inspired for improvement.

Any cautions?
Manage expectations correctly towards the business owner and your team. To get to the point of 4/5 star ratings, app developers have been failing, learning and improving for a longer period of time. Prepare yourself and the team to release and improve in iterations instead of aiming for a 4 star app right from the beginning.

2. Learn from feedback in the app store

The most accessible feedback would be the user reviews in the app store (readable by everyone).

When usefull?
If you have a very active user population they will rate your app and sometimes write reviews.

Any cautions?
By only looking at the ratings (whether those are low or high ratings) you could miss essentials details on why your app is good or bad. Collecting app store reviews might not give you the complete picture. Apple currently does not offer options in iTunes Connect to respond on feedback from the Appstore (the Google Playstore does) so you will need to think of other ways (see below) of interaction. For all published apps you can use the release notes section of the app store to announce new features and improvements based on user feedback.

bad-review

3. Implement in-app feedback options

Offer the user a feedback option inside your app. The most simple way is to trigger an email with pre filled text (variables) from your app like high level information about the user, the screen flow and even technical information about i.e. the app version and device used. Of course there are more advanced ways to embed feedback forms in your app but triggering an email is easier to implement and most users have at least one email app configured on their device.

When useful?
In-app feedback options should be the most accessible feedback option for the app user. Submitting feedback should not require more than 2 or 3 taps. Because there are options to add variables from the app in the feedback template the feedback is more contextual.

Any cautions?
Before adding in-app feedback options discuss with your design team on how to add this option in a discrete way preventing any annoyances (i.e. if it uses an external email app for sending feedback the user should be informed about leaving the app). For the simple email implementation you need your support admins to create a shared mailbox to receive the feedback. Make sure that your product support team is moderating the email questions. The product owner should have access to the shared mail box to collect feedback and use it for reporting if necessary.

4. Learn from appstore analytics data

Analytics data for your app is available for everyone who has been publishing an app to the stores by simply logging on to your app store account and access the analytics/statistics section.

When useful?
General app performance data and metrics can be obtained from the app stores but is mostly limited to high level information such as app store views, app downloads, app sales and (high level) crash reporting. If this is good enough for your reporting you are good to go and use this data.

Any cautions?
Again there is a big difference between Apple and Google here. If you need to get insights on platform specific analytics for i.e. your Android apps you can get a tons of information from the Google Playstore. The same is more or less valid for iOS apps in Apple iTunes Connect with the big difference that Apple is collecting data based on opt-ins. This means that only some users, with data sharing switched on, are contributing to detailed app store analytics. When you need to get more insights on the performance of your apps (independent of the platform used) switching to a more detailed analytics tool could be necessary (see next item #5).
opt-in-ios

5. Learn from in-app metrics

In this case metrics are collected in analytics tools such as i.e the Adobe, Google Analytics or other solutions. Most of the analytics tool require embedding of an SDK component in your app which have to be available cross platform. With this your are able to receive out of the box analytics data (like available in the App Store ) but on top of that you can manually add events in your app that generate specific in-app metrics.

When useful?
A big difference from the standard analytics data out of the App Store is that there are technically no opt-in limitations as described before. You have much more flexibility on getting cross platform metrics all well as detailed and specific in-app metrics per platform type. Examples are screen hits, button presses and funnels for conversion data reports. Collecting in-app metrics requires more efforts but is great for getting more in-depth insights on how your app is performing.

Any cautions?
Data collection should only be used for optimizing and improving apps and limited to anonymized data. Before implementing in-app analytics make sure that you discuss with your legal department on the data that you can or cannot collect and how to inform the user about data collection in your app. Due to privacy rules, storing personal identifiable information in analytics clouds is not allowed in a lot of cases. Special agreements can be made to switch off certain data collection options on the vendor side (such as measuring the source ip). Your test/audit team can validate this before pushing the app live.

funnels

6. Do beta testing.

60% of the most popular apps on the Google Playstore run beta programs according to Google. The nice thing about the Google Playstore and Apple Appstore that both can support you in running a beta program for a limited group of testers that you select. Most of your users already have an App Store account which makes beta testing through the App Store very accessible (no additional registration work is needed).

When useful?
Beta testing offers you a way to test prereleases of your app in a controlled fashion. Apps can be installed on lots of different devices with different form factors. Although there are ways to do automated UI testing in the cloud, beta testing allows you to get feedback from a relatively big group of real users on usability, performance matters or even crashes. And this is valuable information for the development team as users can share their feedback one-to-one with the developers. Involving users in beta testing allows you to get feedback at first hand and tackle the the bigger errors before pushing your app to a bigger crowd. This could save you some nasty reviews in the app store.

Any cautions?
Before running beta programs make sure that you have release management processes and tooling in place. Your team should be able to deliver automated builds of your app, signed with the right certificates and stored with logical version number in the file name and app properties. This allows the testers to give feedback and report bugs linked to specific version of the app. A tool like  Hockeyapp allows you to setup continues deployments for your app but requires beta testers of iOS apps to register their device UDIDs separately. Running a beta program through Apple’s TestFlight is more user friendly since the TestFlight app makes installing beta apps simple, with no need to keep track of UDIDs or provisioning profiles.

If your app launch date is time critical you could consider internal beta testing as soon as you have a minimal viable version of your app. Once your app is complete enough to be useful for a bigger crowd you can scale up to a public beta test. During beta testing period you can monitor both the app and the backend performance by checking the (in-app) analytics and the server side logging.

Announce your beta tests through different channels. The Google Playstore offers a promotion banner and button for users to opt in. Use your website or other channels like mailings or print (QR codes) to promote a beta program for your target audience. Give yourself enough time to collect feedback and prepare improvements in several releases for your app.

beta-opt-in

7. Do usability testing
If certain features are not yet released and still in a design/concepting phase important feedback can be gathered from usability tests in a (closed) lab environment or just by interviewing users in public. Professional usability labs have equipment such as test devices, eye tracker camera’s and video recording tools.

When useful?
Organizing a usability test makes sense when your app is getting a design overhaul or if you are introducing large extensions that requires multiple iterations of design work. Usability tests can be done with clickable prototypes or fully functional apps. If you don’t feel like burning all your money on development, there are lots of tools available to create clickable prototypes that can run in full screen mode so that the tester (to some extent) can experience the look and feel of real app.

Any cautions?
To get the most out of your usability tests make sure that you reserve enough time for the preparations. This means that if demo accounts and devices are available and have been setup correctly to support your test scripts. Because a clickable prototype is not behaving the same as a fully functional app prevent any complicated tasks for the usability testers. When developing a clickable prototype the most of the work is in designing and implementing the flow.
Depending on the type of app and uses cases make sure that you invite the right testers. You might need to define persona’s first so that you will invite testers that represent your user base.

ui-x-lab

Thomas Wesseling AUTHOR:
Thomas Wesseling is a Manager Consultant in the Sogeti Global Mobility Practice. He is the initiator of the Sogeti Global Mobility Practice community on Sogeti Teampark that has grown to 500+ members over the last four years.

Posted in: Application Lifecycle Management, beta testing, Business Intelligence, Cloud, Data structure, Developers, Digital strategy, Human Interaction Testing, Innovation, IT strategy, Outsourced testing, Quality Assurance, Research, Scrum, Test Tools, Testing and innovation, Transformation, User Experience, User Interface      
Comments: 0
Tags: , , , , , , , , , , , , , , , , , , , ,

 

Questioning Automation
Improved efficiency, enhanced quality, faster delivery, and a better ROI – are the results of effective test automation. Indeed 88% of World Quality Report (WQR) respondents who are using automation have seen a significant reduction in test cycle times with automation, and 84% have benefited from cost reductions. So if automation has such potential, why does the WQR also reveal the proportion of automated test cases in the UK, standing at 42%, is 3% lower than the global average?
At Sogeti some of the most common questions we hear from our clients are: What are the main barriers to automation and how do we overcome them? What constitutes a higher quality delivery of automation? What are the dependencies for successful automation? How can we address technical debt in our regression suites?
Let’s Face it Automation isn’t Easy
One reason behind these uncertainties is that when adopting an automation strategy many businesses assume test automation, once set up, and means that they can test ad infinitum with little or no effort – as if on autopilot – but this simply isn’t the case. With the increasing speed and magnitude of changes in functionality automated scripts will require constant maintenance, otherwise they risk becoming increasingly redundant as the product transforms. Effective automation also requires a more agile way of thinking and this can therefore be a major business disruptor before you start to see the benefits. Not all testers have specialist automation or scripting skills, which is another major requirement for success. Developers are achieving continuous delivery through continuous integration, continuous deployment and the emergence of DevOps disciplines, but this speed of delivery can come at the cost of quality, and lead to reputational damage if your testers are not working in the same way and at the same speed as your developers.
Shift Left to Get it Right
Initially introducing automation into small projects and ensuring testers are trained in scripting will get you off to a good start. However the real game-changer is to adopt an approach to development which integrates testing. This not only shifts testing left, and therefore increases quality (or risk-reduction), but incorporates thinking about and creating test and automation strategies as an integral part of the development process from the very outset of the project. This test-first approach stabilises the underlying manual test strategy, gives clarity on what to test and when, and reveals what can be legitimately automated. Bugs can then be found and fixed in the script development stage as opposed to later on in the regression suite, reducing overall technical debt and ensuring a higher quality output. This requires a very high degree of collaboration and understanding between your test and development teams, with developers, end-users, and testers all contributing to the test automation strategy. The other crucial factor is to realise that automation is not “automation forever”; “autopilot” mode will not lead to automation success. As the software develops the automated tests will need to monitored, re-evaluated and changed to ensure automation remains effective.
Automation Webinar
So this is an overview of the right approach to automation but to really implement it effectively we need to take a deeper dive into the barriers, the solutions, and how to achieve Test-Driven and Behaviour-Driven Development, and how to alleviate technical debt. To help you achieve this we’re hosting a webinar on 28th July at 3.30pm BST entitled “Increasing the Efficiency, Productivity and Overall Quality of Your Test Automation”. If you are keen to get more value from your test automation strategy then you can register for this webinar here.

AUTHOR:

Posted in: Automation Testing, Behaviour Driven Development, Business Intelligence, Developers, DevOps, Digital strategy, IT strategy, Quality Assurance, Requirements, Research, Software Development, Test Driven Development, Testing and innovation, User Experience, World Quality Report      
Comments: 0
Tags: , , , , , , ,