Christian is a father of three kids with a passion for software development, geeky/techy stuff, personal as well as team collaboration and development and lean thinking.
He is part of the ERNI team since November 2017 as Principal Consultant and Service Leader “Agile Transformation and DevOps”. His professional career started off as Software Developer with various programming languages with scope ranging from measurement equipment to standalone internal development tools, joining the first Scrum Team. Later he changed to Project Management, leading software as well as interdisciplinary teams and transforming them into Scrum teams. Based on those experiences he changed to the role of an Agile Coach, supporting teams as well as organizations.
Tanja, being with ERNI since September 2018 as Professional Consultant is an eternal optimist who finds happiness in the little things. She is passionate about helping people and businesses grow and achieve their goals.
She started her career with an apprenticeship in software engineering. After this, Tanja focused on test automation and test management for a while to broaden her horizons.
Having finished her bachelor’s degree in computer science she was looking for a new challenge and joined ERNI in 2018. Since then she has had multiple mandates in various roles like test manager, business analyst and product owner.
In her leisure time, she loves to watch a movie or tv show from her ever-growing collection.
Joffrey joined ERNI in May 9 years ago. He started his career as a security and network consultant, then went on to systems engineering and finally became a developer again.
Since being with ERNI, he worked as Requirements Engineer and Requirements Manager in Pharma projects, Business Analyst and Agile Coach in government projects and right now as PO at a large telecommunications provider. Joffrey is always eager to learn something new and to pass his knowledge on to others. He likes to read a good book, ride single trails in the forest and work with his hands as a balance to his head-heavy work.
What’s part of the transformation to become agile?
We start with a team – usually developers. At first, developers and testers start to work together. When the need arises, we take requirements engineers and others in. In that process you may recognize, that involving only development isn’t that beneficial and you need to involve business as well. Then you start to think about value streams and hopefully you integrate them, too. This is kind of a bottom-up approach. But if you want to be faster, you need a top-down approach as well. Having a management team that supports the agile transformation helps to drive the transition forward.
On a higher level: it should all start by adapting the mindset. Again, don’t use it as a buzzword, understand why you do it, why you want to become agile and what the benefits are.
It’s also important to know, this isn’t something you finish in a year – it’s a continuous process. It’s something that needs to grow over time and people need to change their minds. You can’t decide to have a different culture. The culture changes in the end, after people saw the benefits and started to believe in it. It’s a journey.
Can agile be implemented in times like these when almost everyone is working remotely?
I think that actually helps you currently.
We are implementing it with a customer at the moment and we won’t stop because of the current situation.
Any tips for doing scrum remotely?
Things like a working infrastructure. Seems easy but isn’t always. Also, people need to adapt to working remotely. If you work in the same room, you can walk over to a person and ask something. Now you need to either call or send a message. For information and knowledge distribution, you need one channel for the whole team, otherwise, you have multiple parallel streams. Regarding daily stand-ups, refinements, retrospectives and demos, it doesn’t really matter if it’s in person or remotely.
It’s also important to know, you don’t need to reinvent the wheel. People have been working remotely for years. In my team the developers are in Bratislava and I’m in Switzerland. We have been working like that for years. There are a lot of tools you can use, e.g. MS Teams for the daily stand up or one of the many interactive tools online for interesting retrospectives.
Where are the pitfalls? Not only implementing but also in daily business.
For me one of the biggest pitfalls is communication in general. Transparent and honest communication is important. Not just in the team and during retrospectives but also with stakeholders about their expectations. Some people fear setbacks and want to hide them to only show positive results. But you can learn a lot from failures, probably even more than from accomplishments.
Also, agile won’t work, if you hold on to current ways of thinking, e.g. in a waterfall mode. You need to change your mindset as well. If you change the mindset, the culture change is inevitable. You can’t go on as you did in the past, that just won’t work.
What are the best practices in scrum?
For me, that everybody is involved and understands each other. The developers, why the business side requests something and the business side, that the developers need some sort of flexibility, in order to fulfill that business need. Mutual understanding and trust are really essential.
I think in the end it’s about communication, focusing on the customer, and having a clear goal or vision. Also, trusting the process of continuous learning, supporting each other, and growing as a team. For me, it’s more about the mindset.
What do you miss about traditional project management methods?
I don’t miss it too much. Upper management may miss e.g. the exact facts and figures to see where they’re standing right now. They’re used to Gantt charts and things like that. Now they see a project where 50% of the budget is spent, but don’t know what they really get. By definition, you get something at the end of every sprint, but is a feature really done now? Because you adapt to changes, you can change multiple times and also run in circles. It just doesn’t bring you closer to the end goal, so keep your customer please in mind. It’s more difficult to have status reports.
I miss the understanding of the necessity of a long-term road map. Without it you just work from iteration to iteration. This for sure can be done, but you should have a long-term goal in mind. What do you want to achieve in the release in a half year? Put it differently: If you have longer release cycles, you should really think about your roadmap before you start.
So basically, to know what the end goal is?
Yes, for longer release cycles. At least to understand that this is still needed. You don’t just start and see where it will lead you.
That doesn’t mean you can’t change the plan. You need to be able to adapt to changes but, as Christian said, you need a long-term goal. You can change that, if you have to, it’s not a problem at all. In scrum we usually talk about 2-week-cycles, it’s very short-sighted. So, you need to have a mid- and long-range view, too. I think it’s absolutely crucial.