I received a serious wake-up call just a couple of weeks ago…

It started with me being given the responsibility for a team of maintenance engineers dealing with old-fashioned maintenance contracts. The team was located across India and the Netherlands and a majority of the applications they were dealing with were developed years ago and maintained using traditional waterfall models.

As a true-blue believer in Agile, I wanted to change from the traditional way of working towards a more agile mindset. That immediately gave rise to a host of problems as all the conditions for implementing agile were either absent or very difficult to implement. Anyhow, as the team and the customers started getting enthusiastic, we started implementing a number of agile practices at work. Given the global nature of our team, we paid particular attention to the technological requirements that would support such practices. We set up stand-up calls, made a backlog and planned sprints. Then we got to work…

…that is when the trouble started. The stand-up call was dominated by the Dutch team members. The information shared was done in solely those 15 minutes of the stand-up call. And of course, the planned sprint became  a mini-waterfall and ended up combining all the bad things from both waterfall as well as agile. The team members started to blame each other for everything that was going wrong and the customer had no clue of what was going on.

In other words, it was a disaster however a great learning curve.

So how does one deal with maintenance contracts of such legacy applications, especially when the teams dealing with it are geographically distributed? There are situations where the customers are interested in reaping the benefits of agile and DevOps, even though the applications are at a stage of life where there is no continuous development anymore. In other words, the basic conditions for agile or DevOps are not there, development happens maybe once or twice a year and yet the customer requests benefits like faster time to market, dedicated teams and increased business value.

Fortunately, I have seen a few such cases in the past and based on my experiences, here are a few broad steps/actions that can help optimize such situations:

  1. Putting in place the required infrastructure: If you want a multi-functional team in different locations to work on the same source code, you must put in place the infrastructure that allows this to happen. I am talking about things like environments in the cloud, automated testing and very good Video conference applications. This is especially true when we are talking about teams distributed across different locations. This is the first step towards ensuring that agile practices can be properly implemented. The infrastructure in place must make sure that continuous contact is possible not just by phone but through an interface where people can see each other. The ‘agile mindset’ means not just calling in on scheduled times like daily standup but having the team work as one with every single person being responsible for adding value to the customers business.
  2. Paying attention to culture: Changing the culture of teams that have long been used to a waterfall model can be a huge challenge. Yet, this is one of the most critical factors for the success or failure of agile and DevOps in any organization. For instance, in the current team that I am handling, one of the most difficult challenges we face is making everyone feel part of the same team and feel comfortable talking to each other as well as raising alerts. We tackle this by having sessions on the different cultures with each other and learning to know each other. Get away from the business. Another step we took was to directly involve the customer in our meetings and work. For teams that have been used to working under the waterfall model, where they take in a change request from the customer, work on it for months and finally put it in the production environment and that’s that, this change can be tough to make. However, the agile mindset requires testing within a very short period of time, or even testing while developing it.  This requires a complete change of work culture along with very active participation from the customer. This again underscores the need for high-quality infrastructure not just internally but also between the team and the customer. Consolidating development work within dedicated teams. As already mentioned, such maintenance projects do not involve a continuous flow of development work but rather a few such requests in a year. To deal with these sort of workflows, it is better to consolidate all the development work across multiple applications within single dedicated development teams.
  3. You need team members with a mix of different skills and talents: Once you have started implementing agile principles in your team, you need people who have knowledge of multiple applications and skill sets. The traditional maintenance work is not sufficient to form dedicated teams per applications. This is a larger challenge for the team! It requires proper hiring, training and planning.

Coming back to the wake-up call which started this post, I am glad to report that we are putting in place almost all of the points given above and are already seeing specific, measurable improvements in our work.

The points given above are in no way a comprehensive list but just a start towards implementing the agile mindset in such scenarios. The way you choose to tackle such issues in your team will definitely differ depending upon your particular circumstances. There is no one right way to move towards DevOps and agile and in fact, under DevOps making mistakes is not just allowed but celebrated! So one of the first things I did after our first few disastrous sprints was to set up a mini-celebration before we kick-started our transformation journey.

Just another reason why I love the agile and DevOps way of working!

Sandra Rijswijk AUTHOR:
Sandra Rijswijk is currently working as manager of Sogeti PMO. She has been working for Sogeti since 2008. She worked for several customers in several industries in roles as Information Security Officer, Delivery Manager and PMO-Consultant and Program Officer.

Posted in: Agile, Behaviour Driven Development, Business Intelligence, Cloud, Collaboration, communication, DevOps, Human Behaviour, Human Interaction Testing, Human Resources, Innovation, IT strategy, Opinion, Test environment, waterfall      
Comments: 0
Tags: , , , , , , , , , , ,


Agile PMONowadays, in the Netherlands, we see more and more organisations working with Agile Scrum or other Agile ways, leading to increased number of full Agile Transformations. And, over the past couple of months, discussions on the Agile Way of Working and PMO have increased exponentially.

So, questions concerning the role of project management, program management and PMO have surfaced time and again. As per the definition of PMO, Project Program or Portfolio Management Office, one cannot run an Agile environment without Project and Program managers.

On the internet, you can read a lot of articles on this topic, written by both supporters and non-supporters of PMO, but very few, actually, talk about real experiences. In this article, I’d like to share my experience with respect to PMO-work in an Agile environment.

PMO is all about doing the right things, in the right way. Theories about PMO do not state or claim to know what the right way is. PMOs support and facilitate the structure and way-of-work that are best suitable for the organisation.

Originally, organisations were very project-based. However, over the past few years, they have moved toward becoming product-focused and eventually, business value-focused. Adding value to business is the ultimate goal of a PMO! That’s what we’re here for.

Most of the work is also being tackled within the scrum teams or tribes. To be quite honest, I am very happy with this progression. Now the activities, risks, lessons learned are being owned, registered and felt by those who deal with them every day. That only improves quality and it makes no sense whatsoever to include a PM Officer in this process.

This doesn’t mean there is no role for PMO.

Experience has taught us that an officer is very much needed by the product owner. Therefore, not a PMO (due to lack of a PM), but a P.O.O. – Product Owner Office is needed.

The tasks of the P.O.O. (don’t forget the dots…) can be grouped into four categories:

  1. Supplying information to senior management: Guard your teams and guide you Senior Management in the new way of management!
  2. Managing cumulative knowledge: Best Practices for your  organisation, spread across the organisation and over teams and tribes
  3. Translating the results to the auditors
  4. Supporting and facilitating the Product Owner in the vast amount of work he/she has.

Our biggest eye-opener and issue was the third category. Even when you have transformed your whole organisation into Agile way of working and thinking, with focus on quality without investing too much time and money, your external auditors most likely are yet to do so.

Most companies will still have departments working in non-Agile ways. Auditors want to compare everything in the same format.

The last thing you need is the PO or the teams to invest time in translating your product backlog into a traditional business case; or have the PO spend all his/her time figuring out the financial details. These are the tasks that the P.O.O. can and should take on.

To read the original post and add comments, please visit the SogetiLabs blog: From PMO to P.O.O. … ?

Related Posts:

  1. Projects are dead!
  2. Agile (testing) – the final solution?
  3. 5 ways to get your Scrumteam gimped
  4. Agile Test Improvement: contradiction or two sides of a coin?

Sandra Rijswijk AUTHOR:
Sandra Rijswijk is currently working as manager of Sogeti PMO. She has been working for Sogeti since 2008. She worked for several customers in several industries in roles as Information Security Officer, Delivery Manager and PMO-Consultant and Program Officer.

Posted in: Agile, Behaviour Driven Development, Business Intelligence, communication, Enterprise Architecture, Human Interaction Testing, IT strategy, Scrum      
Comments: 0
Tags: , , , , , , , ,


Image credit: www.mylifeinthetrenches.comRecently, I was reading an article, [published in one of the Netherlands’ popular newspapers Kalshoven, 2014] about switching from the ‘aftercare’  to the ‘precare’ mode of delivering services/taking actions in our economy, government and in our life.

It referred to the trend that firefighters started. Instead of  focusing only on fighting actual fires, they also focus on how to prevent fires. The reason is that it costs less money to make people aware of fire hazards and take precautionary measures, than it costs to fight the actual fire and repair all the damages after the incident. Over the last 10 years, Dutch firefighters have been able to reduce the number of fires by one third by adopting such an approach.

The same is happening in the Netherlands’ healthcare sector. More and more insurance companies are focusing on preventing health issues than just curing it. Again because, preventive actions, eventually, cost less money.

The Bottom line is: Investing in fire-safe environments prevents high costs in the future.

PMO - quote

It was ironical that in the same week (when I read the article), my manager called me a firefighter, because I spent the whole week dousing little fires. Then I wondered, can a PMO (Project, Program of Portfolio Office) perhaps prevent project-fires as well? Is that how a PMO can add/bring the best value to any business?

Until now, most PMOs functioned in a reactive fashion… i.e. assisting the P-manager in what he or she needs. This automatically leads to questions, discussions and search for the added value that a PMO can bring.

I think we would see the difference, if this aspect – changing from being reactive to proactive – is factored in when restating the activities of a PMO. Hopefully, this article will inspire both officers and P-managers to redefine the position and tasks of a PMO and actually state a strong business case for them.

From a firefighter to a PMO

As stated in our previous blog post, we see PMOs playing a vital role in reaching your strategic goals by aligning and implementing tools, people and processes. This requires PMOs to have a proactive mindset.

The office needs to actively provide information and advices to people. It needs to challenge each manager and part of the (change) organisation with how and what they are doing and can do.

Proactive efforts from PMOs can be expected in services like benefits management, reporting and monitoring, consultancy and knowledge management.

But, perhaps, the largest transformation that needs to happen is within the mindset of the office itself. So, step out!

PMO Business Case

Still, stating a business case for a PMO remains difficult. I strongly believe that this has to do with the fact that a solid and well implemented PMO puts a lot of effort in prevention.

There is little to no direct causal link between prevention and the fires not happening…. It’s quite hard to measure something, which isn’t there. Therefore, measuring the effectiveness of a PMO is hard, though not impossible. What is vital is that you state what you want to achieve with the PMO and state solid Key Performance Indicators. Measure your performance before and during working with a PMO.

All these, together, will make sure that you are taking the right actions and doing them right!

That’s how we can facilitate in implementing your strategic goals.


Kalshoven, F. (2014, 12 27). Het spel en de knikkers. Van een nazorg naar een voorzorg economie. . de Volkskrant.

To read the original post and add comments, please visit the SogetiLabs blog: PMOs: Change mindset, Adopt the firefighter approach

Related Posts:

  1. Digital Usability (Part 1): Discard Standard Systems, Adopt Portal Approach
  2. How does coaching work in a business approach?
  3. Results from our Executive Summit: CIO’s see big data as a slow but fundamental business change
  4. The Winds of Change in Cloud Security


Sandra Rijswijk AUTHOR:
Sandra Rijswijk is currently working as manager of Sogeti PMO. She has been working for Sogeti since 2008. She worked for several customers in several industries in roles as Information Security Officer, Delivery Manager and PMO-Consultant and Program Officer.

Posted in: Behaviour Driven Development, Big data, Business Intelligence, communication, Developers, Digital, IT strategy, Managed Testing      
Comments: 0
Tags: , , , , , , , , ,


500px-Cadenas-ferme-rouge.svgConsumers allow all kinds of apps to collect data from their mobile devices without reading the general agreement. We place our most personal information in a public Cloud, which we don’t check for security. We share personal details on Facebook, Twitter, and Instagram without a moment of hesitation.

Nevertheless, we worry about our privacy the moment we notice that a company or government uses this information. In the media more and more articles discuss privacy issues on how companies and government use, for instance, Big Data to serve their clients and citizens. In Europe there is now legislation coming to protect customer on-line privacy. This is following discussions on actions of companies using online data without specific permission. For companies, this puts a strain on how to develop, keep up with, or use digital transformation in their way-of-business.

Can you refuse from using, for example, Google Analytics? No! You’ll most likely lose-out on your competition. You’ll have to find a way in which you are able to use all the benefits of technology and avoid the downside.

The greatest challenge of using technology/ Big Data is not how to collect and use information, but how the community perceives the company or government. Do customers trust you? The digital revolution brought impulsive, short-term contact moments with customers and at the same time the need to build an in-depth relationship with the customers. They have to trust you to provide them with the best services for their benefit. And that just might be the key in establishing customer loyalty again. Use the possibilities of Digital Transformation consciously to build a relationship with your customers in which they provide you voluntarily with the exact information you need to provide profitable products and services: a true win-win situation.

To read the full post and add comments, please visit the SogetiLabs blog: PRIVACY: TURNING AN ISSUE INTO A U.S.P.

Related Posts:

  1. Big Data or Big Brother? 10 Ways Marketing Organizations Can Balance a Compelling Experience with Privacy
  2. Our top 10 2014: Big Data or Big Brother? 10 Ways Marketing Organizations Can Balance a Compelling Experience with Privacy
  3. Big Data: Privacy, Technology and the Law [Download]
  4. “Privacy may be an anomaly”

Sandra Rijswijk AUTHOR:
Sandra Rijswijk is currently working as manager of Sogeti PMO. She has been working for Sogeti since 2008. She worked for several customers in several industries in roles as Information Security Officer, Delivery Manager and PMO-Consultant and Program Officer.

Posted in: Big data, communication, Security, Technology Outlook      
Comments: 0
Tags: , , , , , , ,