About me

30. October 2009

I have been a Solution Architect and Project Manager for years and have signed the Agile Manifesto some years ago. Only a few years ago I discovered Scrum and Agile as my favorite way to bring people and projects to success.

Within the company (CSC) I worked at that time I was working as an Scrum “Evangelist” and established and nourished the internal community to bring forward the idea as an alternative to the “normal” project management. I was leading several major projects and coached others as a ScrumMaster as well as I taught/coached management, project leaders and scrum teams world-wide to get them up and running quickly in the sense of agile thinking.

2012/2013 I joined AOE which was a great move for me. This was a move from an 80000+ people enterprise corporation to a midsize company. By the time I moved we were around 40 and have grown since then to more than 120 people. AOE is fantastic mostly because of its culture and how we work with our clients. We really try as best as we can to be an agile organization. My role is manyfold: Agile coaching and training, Architecture and being a Product Owner.

Besides that I am part of the Xing Agile Rhein Community, I give talks and trainings (“Scrum in Practice”, “Advanced ScrumMaster”, “Managing Agile Project Performance”, “Kanban”) from time to time here and there.

I set up this blog to share my experiences that I have in my agile daily life. Scrum and other Agile Methods are frameworks that have to be adapted based on our own and others lessons learned. So let’s embrace change and exchange what we have learned so far.

  • 1 comment

1 comment zu “About me”

  1. Abdulam 15. July 2013 um 12:04 am Uhr

    Hi,According to our findings, I agree that one of the bigsget benefits of the review is to have a ceremony to celebrate what was done. It maintains a positive flow within the team, and keeps things going. It also helps setting a pace to iterative development, and promoting done done stories.However, you don’t necessarily get this by making developers demonstrate features. As long as you have a team that feels one, the team will be proud of what it did, whoever presents the work.There’s another option that we successfully use in some projects: make the testers demonstrate. They’re in the middle of dev and PO, they must understand both aspects, and they already used the features. This can help having a more fluid review, e.g. if the product is a bit tricky to set up or use, which can happen in a complicated technical environment.

Trackback URI | Kommentare als RSS

Write a comment