Agile Transformation of an organisation

As I am not an expert in agile methodology (at least I do not have any certifications but more than 5 years of using and living agile) the following observation and opinion may just be view on the world but I think anyway that it is worth sharing.
I think at the moment there is no real alternative to use either Scrum or Kanban in successful software engineering / product management. But in my opinion it is really are long and hard journey for any company to become a real agile company. I think that there are three phases in this journey:

1. Agile Teams

This is the first and easiest part and normally the start of the agile journey. Normally you hire an agile coach that your IT / Product teams use Scrum to do product development. Normally especially in the beginning this really hurts because the rest of the organisation is still not agile but after a while the pain gets less and teams start to gain speed but still there are lots of obstacles in the organisation. In my opinion this phase normally lasts one to two years.

2. Agile management

Oh, that is not possible… This is what I thought in the beginning. Management will always be management, telling the people what and how to do it. Now 5 years later, me being a manager, I changed my mind. Agile management is possible. Definitly and it is even better than classical management because it does mean encouraging people and real delegation instead of giving orders. Of course this is not always easy and also needs really a change in mind of the management. But how to get here? To be honest, I do not think that every manager is capable of becoming agile because it means somehow jump into the uncertain, giving away your power to where it belongs and accepting that your employees are at least as important for the success as you are. So what helped me was really to consider myself as somekind of a Scrummaster for the employees and teams. So really focusing on removing impediments and enabling people to do their work. Also that might mean for people that are not capable of doing so to leave the company. Especially in higher management I observed that this is hard for the people. This phase is definitly harder and lasts longer because exchanging people in management normally is hard for any kind of organisation. I would say that two to three years might be a time for that change to happen. The main problem is that the longer that lasts the more the people in the teams are getting frustrated and perhaps leaving the company. That might lead to the observation that agile is not working.

3. Agile stakeholders

This is the hardest nut to crack. Most of the organisations I know that have a product (so not agencies or companies that do mainly consulting) have really large stakeholder organisations. There are the experts located. In my opinion thy are used to a way of work where they define the features and then put them to the teams that implement them. Definitly this is not my understanding of an optimal way of product development. I think that in an optimal world the Product Owner owns a product and this is really his „baby“. So he is working together with the teams on ways to improve it. And for the how he should consult the stakeholders (e.g. SEO department, …). This is a workflow that from my point of view is really a key to success because teams are for example used to think pareto whether stakeholders tend to strive for 140% of perfection. As I said this is the hardest part and we are currently right in the middle of that phase. I think this will last for three to five years and the success is still open.

So finally what is my proposal for the third phase. So how to be succeful in this phase? I think that it is crucial that good and motivated stakeholders turn into Product Owners because who can have more passion for a product than a guy that has worked on the topic for a long time. But of course that means learning and adapting to modern software engineering and product development. These are skills that can be learned if you like to. I really believe that successful organisations in the future will have also stakeholders but these will be much less than in „traditional“ organisations.

What do you think about this view?

GD Star Rating

Managment by walking around

As promised some thoughts about managment. For those that do not know currently I am working as a „Head of Engineering“ which means 25 engineers and 2 Scrum Masters are my direct reports.
One of the main challenges I am facing is how to get at least a glympse about how people are feeling and what they do to be able to provide feedback and advice at the right moment. On the other hand people want to know what I am doing because also this is mostly not obvious to the people. And this os not their fault because beside people managment I have some projects and also I am quite often on the road either becuase of the projects or also th show face in one of the other locations.
Basically the question is how to take care about a certain level of interaction and providing information to the people. Yes, regular one-to-ones are one option and I do it. But to be honest I am not capable of do that more often than once a month with each of them.
People als tend not to come and ask their „boss“: What are you doing? Or stating: Mhhh, today I feel not well today.
So, it might sound funny, but I really try to spend half an hour a day, walking around the office and the kitchen, drinking a coffee with the guys or just approaching them at their desk talking to them about projects or even work unrelated stuff. One might think that really distrubs them and distracts them from their current work but you get a really good feeling if they are in the tunnel or have some minutes for chat. From my point of view it is even the other way around so they really appreciate me, coming around and being interested in what they are doing. And this is not pretending because I am interested. Sometimes it is even enough to stick your head in the office and have a look around and you feel if something is going on or everything is okay.
For me this is really super important and this half an hour has imho one of the best ROIs of all management tools that I know so far.

GD Star Rating

TDBF – The bottom line of TDD?

I think that the question what the best approach of developing software is nearly as old as software development itself is. And additionally it can not be answered because in my opinion it is totally dependent on the environment. That means if you are working in an agency on projects or in an enterprise company on products, which language and tools you are using, how mature you and your team are, …

So for the last few years test driven development seems to be the rising star in IT industry especially when you would like to have good quality. But for me it is kind of curious because it seems to me that if you have a look in the software in the market there are two kinds of software: Well tested and successful from a business point of view. Okay, this might be really black and white thinking but to be honest I have never seen a successful enterprise software that has 100% test coverage with automated tests. But of course everyone in the industry with a technical background strives for TDD. I would rather say that most of the software I have seen is mainly tested manually. Imho the reason for this that mostly I have seen some legacy software that is in the market for 3 or more years.

I think that if you start something new that a TDD approach gives you plenty of advantages, e.g. you can implement software against a specification. This comes especially handy for ETL or REST services in my opinion. But I do not think that there is really a good KPI what good quality of a software means especially stuff like Code Coverage really are the wrong approach. Additionally testing is expensive: From my point of view if you really go test driven and also write tests in all levels of the test pyramid it is easy to spent 60% of the total effort in testing. Yes this pays back. But this takes time and also might not pay back if for example you do an experiment and decide to remove a feature because it is not successful.So I think that a good team really knows best what to test and what not and if TDD makes sense for them. And especially when to do it, in the proof of concept or later.

But for me the main question is how to get to a certain level of tests and to convince people of the advantages of tests. And also if you follow my approach to do an experiment with not so good tested code and later on decide that the feature stays live the question is how to improve quality and amount of tests?

I see only one way to approach that and that also might be a good way to improve legacy software: TDBF – test driven bug fixing. That means as soon as there is a bug the first task is not to fix the bug but to be able to reproduce it in an automated way. And this should be done ideally on the developers machine. I think the advantages are clear. On the one hand the developer is able to determine if his fix works already early in the development process, root cause analysis becomes much easier and additionally the bug will not appear a second time if that test is run automatically e.g. after each merge. It sounds easy but often different environments behave completely different and writing good tests is a hard task. But definitely for me that is the thing to do to be able to maintain software and also to improve the skills of your engineers. And of course this is much more pragmatic than just saying „Now we do TDD“. Lets hope that usefull and pragmatic TDD  evolves out of TDBF.

Please feel free to share your thoughts and have a nice week!

GD Star Rating