Makers Academy Experiment

My partner, Henrik, and I have spent a fair amount of time discussing how to improve the IT market in Göteborg, and really how to improve the IT industry in general. This is one of our main motivations in creating www.RebelAlliance.se and structuring it so that we never have any incentive to lower our quality standards (http://www.rebelalliance.se/about-us.html).

We are facing a lot of different issues in the IT industry not the least of which revolves around technical excellence.

The question is not one of intelligence, we have absolutely no shortage of brilliant people in our industry, but one of environment and practice. Most people do not enter the workforce with knowledge of modern engineering practices like test driven development, continuous integration and delivery. Once they enter the workforce there is a lot of stress and pressure which results in virtually no time to learn new skills. Sure, they will need to learn things everyday to solve the problems they face, but what about doing more than just solving the immediate issue? What about a larger shift in the way you think or work?

Most day-to-day environments don’t allow for systematic improvement and addressing root causes of problems. Obviously, this leaves underlying problems in place instead of them being fixed once and for all. We can all agree on that this is a great waste. This is especially true in our industry where demand is ever increasing – addressing the symptom will not save us. We need to attack the root cause.

This is why, when we were approached by www.makersacademy.se, we were intrigued. The concept is simple, it is a 12 week intensive coding camp, aimed at teaching people the fundamentals, enabling them to hit the ground running – and keep running. But what is important is that modern engineering practices are considered to be part of this foundation. Students work from day one with automated testing, continuous deployment, and other such skills. Meaning when they enter the workforce and are faced with problem, their instinct will be to solve right rather than just hacking a solution together.

Our hope is that this will contribute to a changing culture in the world of software development, which has already begun, and improve our technical excellence for the better.

But, we have never done this before and there are a lot of unknowns.
Can someone become a good coder in the course of 12 weeks?
Is this program the best way to go about that?
Will it provide value to those who attend it?
Will it be something we are proud to have our names on?
Do we have something to contribute?

As we always do when uncertainty is high, we decided to perform an experiment. We will work with www.makersacademy.se for their first 12 week camp. We will be doing this free of charge and during our spare time. At the end of the 12 weeks we will know a lot more than we do today!

Wish us luck, I will keep you up to date!

Annonser

Meeting the team

Edit: If you are reading this article, please read this one afterwards as they are a set.

The horror story

I once started working as a Scrum Master with a new team in about the worst possible way.

The team had not been informed that I would be working with them beforehand, so the first word they had of a new team member was when I was standing in front of them.

What’s more, there was a team member who had been serving as Scrum Master in a part time capacity, I was being brought in so that he could focus more on development work. Which he didn’t know until I was standing there in front of him. It actually turned out he was very upset and had clearly stated in the past that he was keen to remain Scrum Master.

This team was already very frustrated with the way their organisation was handling this transition and now I was just one more part of that problem. I am sad to say it was a blow I was never able to recover from. I worked with them for about 6 months, and I don’t feel I was every actually accepted into the team and as a result was unable to help them move forward.

This was really tough for me, as I am an extremely sociable person, and am usually accepted into new groups very easily and consider the trust that builds to be an essential component in my ability to do my job.

More often than not

Even when the story isn’t that bad I find there are a few things that hold me back when starting with new teams.

I’m a consultant

This tends to put me on bad footing right from the start which I think you can’t blame people for. Here is a person who is being paid what they believe to be a lot of money (not nearly as much as people think, but that’s another subject 😉 ) and also works with something a lot of people consider to be very ”buzzwordy”.

They don’t know me. They don’t know that I do what I do because I love it. They don’t know that I would do it for free. They don’t know that I take what I do very seriously and work very hard at making sure I am the best I can be at it.

I listen

I am a very firm believer that the worst thing you can possibly do when joining a new team is to come in and start talking about change right away. Not only is this dangerous as you lack the proper context to know what is needed, but it’s incredibly arrogant to think that you know better than people who have been working in this context a lot longer. I believe doing this will erode trust before it has ever started to build.

So, when I join a new team I generally spend a few weeks simply listening and asking questions before I offer any kind of opinion, doing the ”inspect” of ”inspect and adapt”. I usually keep a document I call ”inspect” which holds my observations and questions during this period.

While I think this is a good practice sometimes I feel it comes off as I am shy (which could not be further from the truth), that I am intimidated, and that maybe I don’t really know what I’m doing.

How can I improve this?

When I started with my latest team I was determined to improve this situation.

I told the person I was meeting with the horror story, explained I was not ever going to repeat that situation and that it was very important I meet and get the blessing of anyone I would be ”replacing” before hand. Happily both those individuals were excited to get the chance to focus on development work again.

To alleviate the more common issues I opted for transparency and honesty. I had a meeting with the team the very first day to introduce myself.

I explained what experience I had, that I was a ”Scrum Master” by profession and that I enjoyed it very much. I told them about the communities I have founded and helped to build www.ScrumBeers.com and www.BrewingAgile.org.

I explained that I would be simply listening and asking for a few weeks and precisely why I would be doing that. I also explained that I would keep this document of my observations, but that it was purely for my own use and would not be shared with anyone directly.

Finally, I said that eventually I would have some ideas and suggestions and I would appreciate if they gave them a fair chance and tried them out, but that ultimately the process was theirs and theirs alone and I would never attempt to enforce anything that they did not agree to.

Did it work?

I have been very pleased with the result of this.

I think that the explanation of why I was going to be remaining quiet for a while earned me a lot of respect from people and that it greatly accelerated the building of trust. One team member even took the time to tell me how good he thought this way of thinking was.

I think that explaining who I was also helped to establish my credentials so they knew that I wasn’t just some guy who took a two day course and called myself a Scrum Master. And I think that talking about the communities helped to establish this was something I was very passionate about, and not just in it for the money.

But at the end of the day, I ended up with a great group of people and the credit is really theirs, they were very welcoming and open.

How do I do it even better the next time?

One thing I was not happy with was the meeting of the team members I would replace, it happened later than it should of and I am not sure it came across that they actually had a choice in this. I will work on this from meeting one next time.

Also, I think I may start sending this blog post as an introduction in the future.

And of course, keep looking for ways to do this better!