• Why Agile Methodologies?

    I started on managerial roles by necessity. I was an associate professor at UPSLP conducting research on Human Computer Interaction. I was used to working with colleagues where we had weekly meetings to discuss approaches and ideas, and then have the rest of the week to develop the ideas, run experiments, develop software, write papers.

    As I started collaborating with undergraduate students,  I needed to change the way I collaborated with them. It is a strange management process, because I was also their teacher and my role was to help them thrive and learn, but we also needed to get things done on time. As the students work on projects as part of their process, it is expected that sometimes things don't work out. I don't like to micromanage because it hinders the ability of people of explore new ideas or propose new concepts; also, there is not enough time in the world to micromanage a project. Traditional management tools did not work, Gantt charts were never a reflection of what has happening, and I found out that long term planning was more intimidating than beneficial.

    Talking to my students, I started to develop my own way of managing team. I put into practise my HCI background to understand their needs, and then propose their solution. They needed:

    • To be fostered 
    • To help them thrive
    • To put in practice what they have learned
    • To be allowed to fail
    • To explore and learn new things
    • To bring their own ideas and materials
    • To get the project done
    • To be in constant communication
    • To be part of a team
    From then I started working with them to address those issues. I liked the Agile Manifiesto, because I thought it addressed solutions to my needs, but I was not 100% committed to following a methodology, rather I liked the philosophy and continued doing my own thing.

    Then I joined the City Administration and instead of leading a team of students, I was in charge of 40+ professionals. I realised that they had the same needs, but they were more coy about brining their own ideas to a project.

    I tried to foster the same way of working, but eventually I noticed that I needed more structure. I former student who joined the administration as software developer pushed us to use Scrum. We started using it for one project, I liked that it addressed the needs of the team and it helped to get stuff done. I think Scrum is not very forgiving towards failure, i.e. "Or thy name is mud", but I liked that it allowed the team to be in constant communication, helping and fostering each other, and with clear visibility  of what each person is doing and were the is project standing.

    In my role as CTO, where I lead a very small team of 2, we have been using a modified version of scrum. We had to adapt it to meet our needs as a startup.

    I am believer of adapting methodologies to our reality, if I apply them to the note then I am not following a human centered approach. I think Scrum is not lenient towards failure, as I said earlier, and the speed of the development can start slow when the team members are getting to know each other at the beginning of the project, which can set a low bar. But hungry team members can eventually push the bar up.

    I like Agile Methodologies, and in particular Scrum, because it addresses what I believe are the core needs of a team to accomplish a project. At the end, I think they bring:

    Visibility, Communication, Fostering and Support towards getting things done.


    Rheinsberger Str. 76-77, 10115, Berlin, Germany