All posts by starlord

About starlord

Starlord is a Software Lifecycle Architect. He has worked for 10 years in various development position including developer, Product Owner, Team manager and Scrum coach.

What is a Devops engineer ?

Devops is the new buzzword in human resources of tech companies. Jobs are popping up all over the place with the title “Devops engineer”. It shows that organizations are now interested in the subject of company end-to-end agility, and that is a good thing. The problem is that Devops is not a job. Funny thing, … Continue reading What is a Devops engineer ?

Does Devops engineer job title mean something

Devops is the new buzzword in human resources of tech companies. Jobs are popping up all over the place with the title “Devops engineer”. It shows that organizations are now interested in the subject of company end-to-end agility, and that is a good thing.

The problem is that Devops is not a job. Funny thing, assigning the responsibility of Devops execution to a job is by definition anti-Devops. Is this Devops job title a faux-pas of badly informed recruiters? Or does it hide a deeper question? Let’s have a look.

A light review of Devops

We will not detail what is Devops in this article, it would be far too long. We will do it for sure, but this will require its own set of articles.

For now, let’s just resume Devops in the following key elements:

  • - It aims at fluidify the exchange between the different functions working at creating and maintaining software artefacts. Mainly DEV-QA-OPS, but as well some other functions like management. It is a company-wide transformation
  • - It has in core increased collaboration and automation
  • - Devops proposes to implement a number of processes, like continuous deployment, continuous testing or continuous monitoring, that all going into Devops direction
  • - Some technical choices like infrastructure as code can help to migrate to Devops

A first opinion: why ''Devops engineer'' does not exist

As explained above, Devops is not a job, a function nor a process. For this reason, we can doubt that the “Devops engineer” job title actually means something.

As with Agile project manager, a Devops engineer job looks a lot like a company trying to attract people into OPS jobs by using a buzzword that they do not fully understand.

Sadly, this is confirmed by reading some job descriptions: it is a job of OPS, potentially with some recent technologies like containers, with little to no relationship with the actual Devops movement.

No, Devops does not mean that one guy has to write release pipelines or “Dockerize” the application for the development team. In a truly devops organization. These tasks are typically handled by Developers with a strong support or coaching from the operation teams.

To implement Devops, it is common to build porous organizations to encourage knowledge sharing. It is inadvisable to assign to a new person the work of implementing operational aspects of the code produced by others.

Second thought: Devops transformation

So far, we have been looking at a working Devops organization. If all is put together to be Devops in the company, no need for extra people: development, operations and other relevant functions heavily collaborate to reach the best quality of service for their users and customers.

But what about on-going transformation?

The typical starting point for a company starting a Devops transformation is hermetic Dev and OPS organizations, strict and slow deployment processes, and contradictory objectives (innovation VS stability).

In this context, Devops will transform heavily these two citadels to make them unbreakable allies towards the business objective of stable innovation. Transformation that can be complex to implement.

How this can be done? A possible answer is to recruit specifically Devops experts that will help both organizations to reconciliate. That is the Devops team concept. These guys can even play a role of intermediary at first, then progressively rollout new ways of working when people are convinced by the added value little by little.

This would better be called Devops coach.

Third thought: Distinguish “Devops-ed” OPS jobs

We discussed a first possible Devops engineer job, the one of coaching and temporary intermediate between development and operations.

With a Devops transformation, let’s be clear: the most impacted job is the one of OPS (I personally believe that QA job comes short second but more on this later).

In a Devops organization, an operator does less clicks and commands and much more coding, less manual stuff and much more automation. He is less a sentinel and more proactive in the development cycle.

For old school OPS this can be frightening. For young engineers this is a lot more attractive.

Now here is the question: as a recruiter, how do you distinguish the Devops OPS job from standard OPS? There is a vast difference in the day to day activities, and it is already difficult to staff operators. It is key to show which job you offer.

This is for me the second usage of the Devops engineer job title. It is wrong, but still probably the best way to advertise that you offer a job in an organization implementing Devops or in the processing of adopting it.

Now the job description should allow to see if we are looking at such job or a standard OPS job. It should focus less on tech stuff and more collarobation stuff. You should feel that the job is about collaborating with other roles and not taking responsability after development as finished coding. If the description does not give a clue, use the interview, here are many questions to ask.


The first time I saw a Devops job title I was horrified, just like most people would be by knowing what Devops is about. After some though, I consider that the job title “Devops Engineer” is either:

  • - Designating a Devops coach job (and should definitely be called like that)
  • - Designating a Devopsed OPS job (and I do not see a better way to call it)
  • - Wrongly used, it is an OPS job trying to look better but still implementing ideas like taking care of all operational aspects of the product being built in isolation of the dev team


Carefully reading the description, or asking questions during the interview, should bring the information needed to distinguish the cases.

Devops is a brilliant movement, and at Stenusys we hate to see its image degraded by companies using the term badly. It happened to Scrum and agile in general, pity if Devops falls in the same pitfall.

Recruiters, use the term wisely.

Candidates, read the job description to see if this is a coaching job, an OPS job in a Devops organization or a standard OPS job with some new tech.

But please, if a mismatch happens, don't blame Devops !

You can get help to implement Devops!

 Visit our website for more information on our offers

Scrum hoax #2: the Scrum master handles all conflicts

Any activity done in group may create conflicts between individuals.Scrum, by proposing self-organized teams synchronized by ceremonies and pair-reviews, may bring to the surface conflicts within the team and outside the team. A common thinking is that it relies on the Scrum master to solve these conflicts.  In this article we will review where the … Continue reading Scrum hoax #2: the Scrum master handles all conflicts

The role of Scrum master regarding team conflicts

Any activity done in group may create conflicts between individuals.

Scrum, by proposing self-organized teams synchronized by ceremonies and pair-reviews, may bring to the surface conflicts within the team and outside the team. A common thinking is that it relies on the Scrum master to solve these conflicts.  In this article we will review where the role of Scrum master lies regarding conflict resolution.

Last week, there was a conflict between two members in a team that I coach. Apparently the organization, including the team members, were expecting the Scrum master to take care of that conflict. He was not so sure about his role into it.

So we discussed about that question: is it the responsability of the Scrum master to solve conflicts in Scrum?

It is common for organizations to miss the soft skills required by the job of the Scrum master. Conflict is an opportunity to review this part of the role.

Conflicts within the team regarding the work to do

This first situation occurs when several people in the team cannot agree at all on a subject that relates to the work to be done.

It can occur on a very large set of topics, from trivial like code formating, to more in depth subject like architectural style, aesthetics, columns definition of the sprint board or branching strategies.

See our article on branching strategies in Scrum if you are in this case.

Under these circumstances, the conflict can block the team to progress. It is then an impediment. It is the role of the Scrum master to help fluidify collaboration and solve the conflict.

Many tools, not specific to Scrum by the way, can be used for this, depending on the situation.

Here are a few techniques, more or less sophisticated:

  • - rediscussing roles and expectations. No, a senior developer should not assign work. Yes, a PO should write understandable, coherent and scoped stories...
  • - getting back to the actual need. Many architecture discussions can be solved by reviewing non functional requirements or product vision with the PO
  • - the technique of the three amigos to add a new perspective to the topic
  • - one-to-one coaching session can be helpful
  • - rationalize the conflict is as well a top priority. Easier said than done, but still required
  • - the help of an expert can be interesting in some cases

In that area, the role of Scrum master as facilitator, oriented towards maximizing team collaboration, will play a key role.

To establish mutual respect and active listening within the team may require sharp soft skills and emotional intelligence on the Scrum master side. It is crucial to get a happy and high performing team.

Scrum ceremonies speed up conflict emergence (and resolution)

As we mentionned, Scrum strongly relies on interpersonal communication to build a product. Many ceremonies are made to enable autoregulation within the team, with peer-to-peer discussions on a very regular basis. It is efficient but if not properly handled, it can lead to bad situations.

Take the example of a newcomer that is not motivated because he feels completly lost in the product. He is not working very efficiently so he does not progress much on what he is working on.

On a regular V-model project, he may have the opportunity to hide a bit the lack of progress. He may keep the problem to himself as he does not feel comfortable in sharing its difficulties. Result is that he will leave the team or that few weeks or months later, someone will realize that planning is at stake.

In Scrum, he will have to stand in front of the team and answer the question of what he did the day before. That again and again every day up to the end of the sprint, ie between 10 and 20 times! This will for sure catch his mates' attention as that situation endangers the team's objectives. And that is great if the setup is good: the team can quickly move to the resolution of the problem and improve the situation of that newcomer: let's work in pair on your story!

In that case, the conflict can be resolved by the team itself thanks to the framework.

When conflicts between team members become toxic

Helping to resolve conflicts that arise during the crafting of the product is one thing. But when toxicity steps in that is a totally different story.

Team members can have strong incompatibilities, far beyond a temporary divergence on the best solution.

This kind of conflict is not only a timebounded impediment of the team, it is a fundamental long term issue in the team and beyond.

In such a situation, the role of the Scrum master is typically to:

  1. 1. Identify the situation as a conflict
  2. 2. Try to solve with various conflict management techniques (see this good article for example)
  3. 3. Diagnose that the problem goes beyond temporary impediments
  4. 4. Hand-over the problem to a role in the organization that is typically fit for people management (People Manager, HR, ...)
  5. 5. Follow-up the situation and mitigate the impact on the team

Hopefully by applying this simple method the Scrum master will manage to minimize the damages such a conflict may create in the team. Preserving team coherence under these circumstances is a real challenge.

Wrap-up: the Scrum master role facing conflicts

To summarize, we can say that no, the Scrum master does not have to handle all conflicts within the team.

As a facilitator, he has to take care of the potential difficulties team members have to collaborate in the day-to-day life of the team. For that, he has to demonstrate extensive soft skills and should continuously work to setup a good atmosphere.

When things goes beyond the resolution of temporary conflicts, the Scrum master should raise alarms within the organization that a recurring and potentially toxic situation is in progress and should be taken care of.

You can get help to implement Scrum !

 Visit our website for more information on our offers

Retrospective of Vivatech 2018

A return of experience from Vivatech, the biggest startup conference in Europe We had the chance to be invited by the Institut Mines-Telecom to participate to the 3rd Vivatech conference in Paris. We attended mostly to meet with various companies and discuss about Stenusys Scrumboard but we also took time to attend few conferences and … Continue reading Retrospective of Vivatech 2018

A return of experience from Vivatech, the biggest startup conference in Europe

We had the chance to be invited by the Institut Mines-Telecom to participate to the 3rd Vivatech conference in Paris.

We attended mostly to meet with various companies and discuss about Stenusys Scrumboard but we also took time to attend few conferences and look at many awesome innovations. Here are few highlights of our visit. 

Part 1: Vivatech as a startup

On our booth

We had a stand on IMT booth to present our product, Scrumboard.

They were many (many) stands like ours, and obviously visitors (academic, investors, executives, press) focus mainly on startups they already know about, so entrepreneurs should not expect to have all visitors stopping by.

Yet we had many interesting visits and discussions around our product and software engineering in general, like what we discuss in our series Scrum hoax.

Our booth at 7:30 am (!) on the first day

We had also visits of students looking for a job or an internship. Less so from more senior developers. So if your startup is searching for new young talents, Vivatech may bring some valuable contacts.

Visiting companies' booths

This is however not really how you make most connections at Vivatech. Most of them are coming by visiting the booths of the companies you want to meet.

It is our biggest take-away from Vivatech: the accessibility of the executives and the warm welcome startupers receive from very large companies. This is absolutely incredible.


A very popular option to present your startup is the pitch. There are many stages on which startups can pitch their products and services. The selection is done prior to the show by the organizer of the contest.

You can pitch either on dedicated stages or on the stand of some companies. The audience is rather kindly, which is appreciated.


There is a strong media presence at Vivatech. Many interviews are run directly on the booth or the stand of the interviewee. We have seen some journalists looking for a particular startup to get a pitch.

Some others are done on media booths, setup as real studios:

Afterwork: Viva on the docks

Networking does not stop at the gate of the venue. Nothing better than relaxing around a free drink on the Seine's docks after such busy days.

Part 2: Vivatech as a visitor

We took time to visit the tradeshow as regular visitors.

And for sure there are some great things to see from that angle as well !

Innovation of all sorts

For sure, innovation is not always about fancy demos and drones and Virtual Reality. But as sure as this is true, the more the innovation is visual the more success you get in such tradeshow.

Here are some of the most awesome looking innovations we have seen.

A flying car from Airbus:

A flying ... boat?  from SeaBubbles:

The IBM Quantic computer (hard to tell how it works, but that is absolutely beautiful right?):

All sorts of VR experiences, here at Vinci

VR bubbles

IA playing starcraft by Facebook

Nice talks from world leaders

Nowadays, the biggest influencers of the world are leaders of large companies. They are by far in majority among the speakers at Vivatech. There are as well great institutional leaders stepping in. Here are few people that gave a talk that time:

From US tech giants:

  • - Satya Nadella - CEO of Microsoft,
  • - Mark Zuckerberg - CEO of Facebook,
  • - Virginia Rometty - CEO of IBM,
  • - Stewart Butterfield - CEO of Slack,
  • - David Gurle - CEO of Symphony,
  • - Dara Khosrowshahi - CEO of Uber,
  • - William Levi - CEO of Dow Jones,
  • - Bill McDermott - CEO of SAP,
  • - Chuck Robbins - CEO of Cisco

From French companies and institutions:

  • - Emmanuel Macron - President of France,
  • - Isabelle Falque-Pierrotin - Chair of CNIL,
  • - Patrice Caine - CEO of Thales,
  • - Bernard Arnaud - CEO of LVMH,
  • - Jean-Paul Agon - CEO of L'Oreal,
  • - Nathalie Collin - CEO of La Poste,
  • - Cathering Guillouard - CEO of RATP,
  • - Sylvie Jehanno - CEO of SNCF,
  • - Octave Kabla - CEO of OVH,
  • - Isabelle Kocher - CEO of Engie,
  • - Mari-Noelle Jego-Laveissiere - CTO of Orange,
  • - Denis Machuel - CEO of Sodexo

That is just an extract, from the biggest names. You will as well see very diverse profiles on stage to discuss tech in all possible ways.

However the biggest star this year was...


As the GDPR day was right in the middle of the conference, many talks were discussing that subject. From tech giants' point of view (Facebook) and from regulation one (the CNIL, the French Government). Very interesting indeed.

Few talks we attended to:


You can seize the opportunity to take selfies with famous people visiting.

We have seen many politics and leaders, but if this is not your taste, you can as well find some alternatives:


At Stenusys we did not enroll for the hackathon organized during Vivatech. But it looked pretty cool as well ! 1000 participants had 24h to tackle one among several challenges proposed by few companies. The winners of each challenge wins 5000e and recognition from their fellow hackers.


All in all Vivatech has been an awesome event. Very well organized (except food supply, nearly impossible to get food in a resonnable timing), with very good speakers, 9000 startups from the whole spectrum of the tech industry, 100 000 visitors, 2000 investors, many great large companies opening their doors and their minds to this ecosystem.

A must for startups, especially for B2B and B2B2C.

See you next year !

 Visit our website for more information on our offers

Scrum hoax #1: The black box syndrome

Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a … Continue reading Scrum hoax #1: The black box syndrome

Fighting lack of transparency in your Scum implementation

Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a perfect opportunity to open this series of articles around the Scrum hoaxes. In today’s article we will discuss the black box syndrome some organizations encounter while implementing Scrum, and cover the possible causes and solutions.

Some times ago, I had a discussion with a senior product analyst about how Scrum impacted its organization. Like some people complaining here and there, he was not happy at all with the methodology. Bottom line, the issue was that since the implementation of Scrum, the teams around him were completely black boxes. A common issue indeed, that may come at very different stages of Scrum adoption. It is very sad because it is usually due to a bad way to Scrum. This situation, like all the others of this series of article, is not due to Scrum but to how it is implemented.

So how a team, after implementing Scrum, can be perceived as less transparent than what it was before?

Obviously, it comes from the fact that some aspects of Scrum are missed, but it is not so trivial to see what is wrong.

I will share below the most common category of mistakes I have encountered.

Case 1: No (or ghost) Product Owner

Yes, I have met teams where the role of PO was simply not filled. The Product Owner being in charge of the product backlog, the issue is obvious and immediate.

A very similar flavor is the Product Owner is appointed but too busy to take care of the backlog, or not trained to or convinced by Scrum. At best there are a bunch of badly written stories, at worst nothing at all and the Product Owner sends an email to the Scrum master here and there to ask for things.

Without a proper and up-to-date backlog, no visibility on the product, either inside or outside of the team.

To get out of this situation, the organization needs just to take the subject seriously: the role of PO is critical to a working Scrum team. He should be knowledgeable, accountable, available and invested in the product. You could be interested in reading about the technical skills of the PO.

I would love to say that this is the least frequent case, but sadly it is much more common than you think.

Case 2: No (public) demo

The sprint review meeting is the opportunity for the Scrum team to demo the proposed product increment to itself and potentially key stakeholders. It is as well the opportunity for the PO to decide to release this increment or not.

The first possibility is for this meeting not to be held or to be badly run. Relating to the previous case, if the Procut Owner does not attend this meeting it will be extremely hard to discuss with stakeholders what has arrived and what should come next.

In the situation where the PO is there, but if no stakeholders attend to this demo meeting and if there is no other way for them to see the increment and provide feedback, it naturally results in poor transparency on the Scrum team output.

Our advice here would be to invite key stakeholders to the review meetings to provide them the best visibility.

In addition, especially if the point above is not doable in your particular setup, you should put in place the means for the feedback loop to be available. It depends heavily on what comes next to “Product Increment is shippable”, i.e. the path to users after the sprint.

A solution can be a webinar (for very large audience), a platform to demo your new version, a recorded demo sent to stakeholders or even some canary testing on your production environment. We will cover more on these possibilities with articles on release management but in any case you need to put in place a feedback loop.

Case 3: Private backlog

If with the situation of secret project put aside (military or equivalent), this is astonishingly frequent: the team has a backlog that no one can see outside of the team.

You cannot expect the stakeholders to participate if they cannot see what the product owner has in mind and how their feedback is taken into account.

The solution is obviously to make sure the backlog is available to your stakeholders. The clearer the backlog is the best, so the tool selected should have a good navigability and it should be obvious how to find your backlog.

Case 4: No roadmap

With case 1, 2 and 3 covered, you have a reasonably well written backlog and a two-way communication is established between the stakeholders and the team about newly built product increments. The next source of issue is trickier: what comes beyond the current sprint.

Most organizations and actors in the field of software edition (and engineering in general) are expecting a form of roadmap. Yes, it is usually not reliable and not adaptable. It is not meant to be a commitment on the few next months, but it is valuable to give some visibility on what you hope to accomplish.  

Looking at a way to get Scrum roadmap easily? Check out Stenusys Scrumboard that provides an automatic planning on your product backlog.

Case 5: No readability on what the stakeholders want

A backlog gets denser and denser as long as you are getting closer to the next sprint items, as you will detail more and more the content of the stories. From an external point of view, it may be very hard to find out how a suggestion or request has turned into a list of stories.

A good way to do it is to differentiate the stakeholders’ requests from the stories themselves. You can use epics, but it can get complicated for different requests fulfilled by the same stories.

The best option is to distinguish the requests from the stories of the backlog and make sure each request is updated based on the status of the stories implementing it.

Find out how this works in request management of Stenusys Scrumboard.

Case 6: Private Sprint Board

When some critical stories are under implementation, stakeholders may be interested to see if everything goes ok. It is not that they can do a lot about it in most cases but that sure means they may not appreciate to wait until the sprint demo to get news from you.

To make sure the information is available at any time, without a need to compute manually reports, it is a good idea to have a sprint board fully open and easily accessible. The best option is to have your backlog browsable in your Scrum tool.


Closing up, transparency is one the key value in a business relationship. It is required to setup the viable working environment you need to work efficiently, based on trust between the team and its stakeholders. 

If well applied, Scrum is a great enabler of transparency. By following the suggestions proposed in this article you should get one brick to put in place a healthy product engineering team. More to come...

You can get help to implement Scrum !

 Visit our website for more information on our offers

Why software engineering matters

What Spotify, Criteo, Uber, Airbnb and Netflix have in common? Of course, they are young tech companies extremely successful in their fields. But beyond that, they have invested a lot in software engineering. Just like other great tech companies like Google, Facebook or Amazon. And they are very vocal about it: Google Developers, Spotify Labs, … Continue reading Why software engineering matters

From startup to leader, the secret truth of software engineering

What Spotify, Criteo, Uber, Airbnb and Netflix have in common? Of course, they are young tech companies extremely successful in their fields. But beyond that, they have invested a lot in software engineering. Just like other great tech companies like Google, Facebook or Amazon. And they are very vocal about it: Google Developers, Spotify Labs, Facebook Engineering Blog, Criteo Labs (and many more), the engineering is clearly a primary concern.

I believe that there is a trend here: for a tech startup to become a leader, it takes many things, among which good software crafting practices play major role.

You are an entrepreneur? An investor? A CTO? Here are some reasons why you should really focus on software engineering.

First, let’s try to provide a definition of software engineering.

“Engineering” first (well actually second), is “the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations.” [Wikipedia]. In short, it means that we try here to use a scientific and rational approach to do stuff.

“Software” is the actual domain on which we apply this, ie any artefact of any size composed of code. That means anything from a simple command in a script to a fully distributed system of million of lines of code, from a desktop application to a web application, from a device driver to a social network etc.

Basically, software engineering focuses on the way software is produced and run by logically implement all the steps involved from the very first idea to operation of the running code.

When you start a software oriented business, or a new IT team in your company, the temptation to just skip all software engineering practices and jump only into the coding itself is strong. And for a (very) short period of time that can actually be OK. But soon enough, I would say you have a proof of concept, when you have few functionalities or when you reach more than few thousands lines of code, you cannot postpone anymore. Here are the reasons why.

#1 Because it saves time

Software creation, in many minds, is typing lines of code, and for this you do not need much than a text editor (we do not recommend MS Word). But many other activities are around, such as:

  • - Building my code and working with different versions
  • - Testing my code
  • - Publishing or distributing the code
  • - Assembling peace of codes together
  • - Installing the code on-to where it should run
  • - Documenting what the code change I just did is meant for

Software engineering has defined further the concepts around these needs. Packaging, releasing, loading… All these processes have to be carefully designed so that your R&D will not spent most of its time handling low level tasks.

A common solution is to invest in Continuous integration, Continuous delivery or even Continuous deployment. In a nutshell:

  • - Continuous integration: build, test
  • - Continuous delivery: build, test, publish
  • - Continuous deployment: build, test, publish, assemble, deploy

Without entering into too much details (more on this in later articles), the concept in all cases is than the developer’s actions are limited to writing the adequate test and code and all the rest is just automatically done. And it saves time. A lot. There is no much figures around it, but it can hardly be much less than 50% gain. Some companies have reported moving from months’ to minutes’ time-to-market releasing on their services implementing correctly Continuous Deployment.

Most of the time it makes a huge difference in any market.

#2 Because you want to get the right product at the right time

Two years plans never met, extremely complex requirement phase, very long and painful test phases, a final product arriving after the users have changed their mind ten times… This model, inspired by industrial projects, is nowadays generally replaced by agile methods.

Collaboration, short feedback loop, constant inspection and adaptation is now supposed to be the norm. If well applied, the agile methods will bring you a lot. If badly applied, not much.

But not wondering how to work together is by far the worst choice.

#3 Because your product is here for a while

In our industry, it is pretty rare to work on short-lived products. It means that as long as you take shortcuts, you accumulate technical debt (in your coding and architecture) and “engineering debt” (in your practices).

Debt that you will pay at some point, either as large payment (large refactoring) or as interests (more and more difficult to change, maintain, deliver new versions).

Many companies, even among the largest editors in the world, have suffered very heavily by procrastinating the reduction of debt.

Investing in test coverage and test strategy and maintaining a good code sanity is vital for the durability of your products and by extension your company.

#4 Because you want the service to be up

Sadly, it is not enough to create the exact application your users need. The quality of service is as important as the provided functionalities.

How Google beat Yahoo? Among other things, the googlers invested in infrastructure as code and by this practice were able to scale, rationalize their hardware, to be faster and always up and running.

Scalability, availability, operability, response time… The so called non-functional requirements are nowadays key to any software provider that hopes to disrupt its market.

Once again, it is a serious investment that has to be done, but it can very well be the X factor between success and failure.

#5 Because it saves money

Good engineering practices dictates an automatic application of software changes. The reasons: faster, more reliable. There is no leader in this industry that apply changes manually.

Globally, many engineering practices, especially in the areas of operations and tests, advocate for automation. The era of agility encourages efficient methods to do low added value actions and to focus your energy on high added value actions.

It sounds obvious, but it is still common to see entire systems tested manually (which is not always better than not tested at all) or code deployment triggered by clicks from overloaded operators.

A lack of efficiency in these areas can quickly become a major issue: while you spend energy (ie money and resources) doing this, you do not invest in operational concerns, exploratory testing, non-functional requirements testing or other among many relevant practices where these professionals can help so much.

It is not a surprise that Netflix, followed by Amazon or Github are investing in Chaos Monkey testing[1]. They understand the importance to go further in automation to test even the one thing that no-one wants to see in a datacenter: crashing hardware.

#6 Because it is simpler

Say you are launching a startup or a new software product in your company. You recruit the team to work on this new awesome stuff and let them self-organize to build it.

The team has then two choices: define together how to work from scratch or reuse methodologies most adapted to the setup and elaborate from there the team unique ways. Guess which one goes faster and is more efficient?

Obviously, there are such alternatives only if in the team or elsewhere you find some strong knowledge of software engineering. Otherwise you are stuck with reinventing the wheel.

And that is actually the point: it is a lot simpler to rely on decades of accumulated wisdom on how to build a product or how to test or how to ship than to have to figure it out from scratch. It allows to focus on delivering the product and not on which branching strategy is the best suited for this or that purpose.

#7 Because you want your teams to be happy

So far we have covered time to market, durability, quality of service and obviously, money. All what an executive is concerned with for the profitability of his company.

I believe that the very first reason why some significant investment should be done on software engineering is for your staff.

As Richard Branson said, Companies Should Put Employees First[2]. The reason is easy to get: happy employees are doing a better job in all areas, including customer care, quality of service etc.

Can you imagine how frustrating it can be for a developer to see that his organization is so underperforming and so slow that the products he builds every day are condemned to mediocrity? That no matter what, it will always be a nightmare to see value reaching users and customers?

I know it sounds over-dramatic, but the last thing you want to see as a manager is your team turning into a disillusioned self-interested organization where nobody seem to care about what is effectively delivered at the end of the day.

And yes, a software company scaling with bad practices in its core will leave plenty of room for such situation to develop. Target happiness, use expertise in software engineering, you will get the rest.


In this article we have seen that software engineering has to be at the heart of the creation and maintenance of any software development unit. It is critical to put in place as soon as possible the right environment in which the team can continue to perform. It is crucial to balance the urge of deadlines and other business-related constraints with the mid term impacts shortcuts can have on your ability to deliver value.

We do not say that shortcuts are impossible and that to be efficient you have to follow every methodology around. We say that software engineering should follow a strategy, aligned with your business strategy, and that any choice needs to be carefully taken as it could impact the company viability pretty fast.

In this journey, you may need some support. In form of consulting to define the way to go or tools to simplify the implementation of a given methodology, Stenusys can help! Do not hesitate to contact us for more details.



You can get help to leverage your software engineering !

 Visit our website for more information on our offers

Should a Scrum Product Owner have technical skills?

In agile transformation projects, the position and scope of the Product Owner role is often source of confusion. Most agilists get that it is about translating user wishes into stories. Functionally it seems OK (thus it is not always easy to do). But a software product is more than a bunch of features. If you … Continue reading Should a Scrum Product Owner have technical skills?

The difficulties of dealing with technical requirements in Scrum

In agile transformation projects, the position and scope of the Product Owner role is often source of confusion. Most agilists get that it is about translating user wishes into stories. Functionally it seems OK (thus it is not always easy to do). But a software product is more than a bunch of features.

If you have seen conflicts between the Product Owner and the development team about a technical change (refactoring, framework updates are common ones), you are at the right place. In this article we will propose a review of what the role of PO consists in with a focus on technical aspects. We discuss then how it impacts the staffing for this position. 

The obvious

All Scrum practitioners know that the PO is in charge of maintaining the product backlog. It includes defining the functional solutions to answer the customer needs. The Product Backlog Items (PBI), often called stories, are designed vertically so that each of them brings value. They are arranged by priorities in the product backlog.

When we describe the PO role, the first answer is that the PO has to understand the customer needs and drag from it the actual functionalities that the product team should develop. The PO incarnates here the customer and transform its needs into small chunks that brings each a piece of value.

This is absolutely correct yet incomplete. The tendency to see only this part of the role is the root of the issue faced with technical developments.

What is a product?

Scrum methodology makes an extensive use of the word “product”. It does not give any detail on what the word encompasses. In fact it will vastly depend on the context in which Scrum is used.

For the sake of defining the boundaries of the Product Owner role, it may however be of some help reviewing what a product can be.

Limiting ourselves to software, we can already have a wild variety of product size and complexity. Let’s present few examples:

  • - A mobile application executing basic functions like a hangman game
  • - A mobile application executing basic functions, and connected to several backends to ensure communication and data persistence like a messaging system
  • - A library executing a rather simple set of functions like a logger or a connector
  • - A library executing complex functions like facial recognition or a video game graphical engine
  • - A service of low functional complexity like a basic e-commerce site
  • - The same service but scaled to the extreme and running on thousands of nodes with failover
  • - A complex framework handling complex use cases like an application server
  • - A distributed system offering sophisticated services like a Global Distribution System

Obviously, if all these type of software systems answer functional needs, the technical complexity of each is hugely varying. The importance of technical knowledge at Product Owner level varies with it.

All in all, a product is not only a set of functionalities but a software artifact with many characteristics like performance, security, portability, extensibility, etc. This may or may not be a major concern for the PO depending on the very nature of the product itself, but it sure requires to be assessed.

Back to responsibilities in Scrum

The development team is responsible for proposing a product increment fulfilling predefined done criteria. It covers any aspects of the software, both functional and non-functional.

The PO has to express the needs, including non-functional aspects, and accepting the increments, i.e. to understand how the team addressed these points.

The technical aspects can come in two flavors: as acceptance criteria of stories or as standalone stories.

Non-functional acceptance criteria

A software artefact is more than a bunch functionality. Depending on the business environment you are in, the constraints will be different. But if a feature increases by 200% the memory consumption of Google search Engine, I doubt it will reach Google production servers.

The Product Owner is in charge of writing product backlog items. It includes writing technical acceptance criteria (response time, memory footprint, deployability..., the list is long). As with any criteria, this is a subject that can be discussed with all stakeholders, included the development team itself. But all in all the PO is accountable for it.

Back to the different type of products, it can clearly see that the frequency to which the PO has to work on these acceptance criteria will vary a lot.

Technical stories

This is the most common case of issues: the development team wants to rewrite a part of the product, independently of any functional stories. And the PO does not accept it. In some cases a story is written but never prioritize in a way to allow an implementation.

First, let's evacuate a common misunderstanding: a story is not necessarily functional. The backlog contains Product Backlog Items that can very well be technical. However, a PBI must have a business value, including the technical ones.

And there is the difficult but necessary part: assessing the business value of a technical story. It means that the request of this story (usually the development team) must explain the proposed technical change by its justification (the WHY) and not by its content (the WHAT). By experience it is very difficult and may lead to challenge the fundamentals of developers's ways, yet it has to be done.

You propose to migrate from JBoss 7 to Wildfly 10? Why?

You propose to refactor the payment module? Why?

You propose to deploy via Docker containers? Why?

They are good reasons to do these three things. We could imagine discussions around continued support from the community, speed of integration of new payment providers or ease of deployment. But they have to be valued against features asked by the users. 

Again collaboration is probable and wishable, but if the PO is fully hermetic to any form of technical discussions, it will be virtually impossible to get anything done.

Skills: who could become Product Owner

We see around many agile transformation with very different results. A usual source of issues is the appointment of the Product Owner in the newly formed organization.

As you might have guessed, there is no unique way to select a PO. It does depend a lot on the product but as well on the company context, the support the PO could get from its organization and how impacting it could be if he needs to answer team’ questions with a delay…

As far as the technical subjects are concerned, it is important that the technical skills of the PO are aligned with the technicality, complexity and ambition of the product. These three axes will define how much technical stories and non-functional acceptance criteria will show up.

In any case it can be difficult to get rid of the habits acquired in one position when taking a Product Owner role. And this is one of the reason to avoid “Scrum, but”: if a PO goes beyond or below the expected scope of its position, it can damage the organization a great deal.

The role of the Product Owner in Scrum is absolutely critical. If a member of the development team can be challenged rather quickly by its peers during ceremonies, the effects of a poorly chosen PO are not immediately visible and often extremely harmful.

And no, in most cases a good relationship with customers and management is not enough to be a good PO. 

You can get help to implement Scrum !

 Visit our website for more information on our offers