Agile Software Development

It is now official. Since the beginning of the year I moved from the Chief Engineer role in a department doing speech recognition and synthesis to product management in the my company internal tools department.

Reasons

For the last couple of years I was more, than full-time focused on making the agile software development methods work for our team, our company and myself (heavy amount of practical scrum mastering and teaching included). It was a fascinating story full of learning, excitement and success though not without some failures and disappointment. I still believe that at the moment Agile and Lean Thinking are one of the top topics many SW development organizations should invest into.

However, the more I got into the topic, the more I realized that after some initial improvements within the team, these are not the in-team practices that are of the biggest waste. Whatever fast and effective the team is, it doesn't matter if it goes in the wrong direction. It is a common problem or at least major improvement possibility in many companies. That's why I decided to move into a role, where I can try helping teams build software that the customer really wants. Amazingly in some agile/lean oriented companies the person playing the similar role is actually called Chief Engineer - therefore in a way I am not changing gears that much.

Effects to this blog

At the moment the only thing I can be 100% sure about is that the new job is going to be full of learning, both on-the-job and in the classroom. I am planning to get acquainted with the new colleagues and practices, refresh my understanding of the agile requirements and learn some product management specific tricks. I am not going to tell a lot about the actual work I am doing unless some of the tools we make find its way to the general public. However, in the course of my learning, expect more coverage on the Product Owner role, product management and link to the customer. It doesn't mean I or other permanent writers are going to stop writing about the team issues, practices or Scrum Master area, but there is going to be more about understanding the end customer problems. Then anyway I am not the only

Just though you might like to know the development plans for the site or more precisely for the parts of the site authored by me. Feel free to adjust the plans by making your voice heard.