|Door:||Stephan van Rooden, 17-12-2014|
The last couple of weeks I have noticed how often messages don’t come across as intended. This is not only destroying relationships but can also limit an organisation trying to empower their employees to show their professionalism. The reason people say something, the ‘why’, is usually correct. You don’t open your mouth just because you feel like it. Especially not in a professional environment. Also, what they want to bring across usually is very good. However, where most things go wrong is ‘How’ it's phrased. It’s how you say it! Here are some examples.
|Door:||Stephan van Rooden, 16-12-2014|
If you are about to start changing your organisation to become more Agile or if you are right in the middle of an Agile transition, you should read this story! It might prevent you from making an expensive mistake.
Let me paint a picture of how organisations used to operate. There is a (project)manager and this manager has a couple of resources (usually people) to his disposal which he tells what to do. This has been the case for decades. Everytime I enter an organisation, I am shocked to see how effective organisations can be in demoralising and reprogramming these highly educated people. Efficiently punished with stick and highly motivated by carrots to perform the tasks assigned by the manager.
However, nowadays these ‘resources’ are highly educated and fully trained to be capable of bringing something extra into an organisation. And this is where it is starting to get painful. Often these people completely forget who is paying their paycheck. It’s (and this might surprise you) not the manager! It’s the customer! This is usually the state of the people in an organisation I am hired to help. I see people so focussed on doing what they are being told that they are almost willing to fight not to change anything. Luckily more and more managers and executives see that this is no longer sustainable to survive as an organisation. This way of working is actually putting their organization at risk of being run over by small, fast and agile organisations.
|Door:||Martijn van Asseldonk, 12-12-2014|
|Onderwerp:||Definition of Done|
I see teams struggle with the application of the Definition of Done (DoD). They want to have a clear and sharp DoD that defines a truly shippable increment. But often they cannot fulfil this agreement on their own. They are part of value stream and cannot deliver end-to-end functionality on their own. A team is for instance dependent on other teams to perform integration testing.
At the end of every sprint, only a small part of their stories comply with the definition of done, resulting in a flat burn-down and a velocity that is way of the mark. Then every now and then, when the teams they depend on do their part, a lot of near done stories are finished and velocity triples.
|Door:||Barry Overeem, 05-12-2014|
After working a couple of years as a Scrum Master for the web agency Enrise I made the switch to Prowareness at the beginning of 2014. At Prowareness, a company that helps organizations meet their challenges in the field of software development, I fulfill the role of Agile Coach / Trainer. In this role I help individuals create great teams by applying host leadership, and learn organizations to adapt and respond to a constantly evolving world.
This is quite a challenge. Not only because working in the field of software development means working with complex products in complex environments. But mostly because creating a truly lasting change is difficult. Not only implement some best practices, but really build awesome teams and create responsive organizations.
The toolkit of an Agile Coach should therefore contain more than a few skills, competences and best practices. Gathering them will require training, hands-on experience and most important: the willingness to constantly improve yourself. For me personally it helps to continuously reflect my daily practices and translate it to a list of 'lessons learned'. This list grows on weekly basis, with this blog I want to share the most important ones I've learned since I started working for Prowareness. And for sure, there might be some very obvious lessons, but often these are the ones you're not always aware of. Note: not all of these lessons are related to the role of an Agile Coach. But fulfilling this role, they've proven to be valuable for me.