Learn fast & Agile Development
I'm an Austrian student. For the summer 2013 I had the a idea of doing an internship in a foreign country - I chose Berlin and I got accepted - I had the pleasure of doing an internship as a product manager at Project A Ventures for the last 3 months.
Now my internship is nearly over and I want to recap and summarize my experiences. But first things first. Let's start at the beginning.
How everything started
I applied in march. In that time I didn't know a lot about product management. The reason I applied for the position is that I was afraid that I am not skilled enough for being a developer and business development didn't sound exciting enough to me. I only knew about 80% percent of the requirements on the list for being a product manager, but I was pretty confident that my CV looks at least interesting enough to get a response.
As usual I delayed the actual creation of the letter of motivation for about 2 weeks. Then I just had the idea of creating a one-take video. I knew that I wasn't able to fly to Berlin for an interview, so I had to mock the actual interview process and just recorded a 20 minute video of me talking about the standard questions I might receive during an interview conversation. I talked about my education, my previous internships and some current ideas which came to my mind.
If I would record the video again I would limit it to 5 minutes and would only talk about product management, startup and web, related experience and knowledge.
During my telephone interview with Tamer El-Hawari and Florian Heinemann we basically talked about my cv again. On questions like: 'Do you know what SCRUM is about?' I had to answer 'no'. At that time I really had no clue about what I really will do in my internship or what a typical day of a product manager looks like.
I think my biggest advantage was watching every Project A related video and read a lot of articles about their funders. Florian Heinemann talked in his videos about the importance of making data-driven decisions. I heard also about the importance of motivation and product love.
So I just tried to put this keywords into the interview and finished the interview with the sentence: 'The reason why I applied at project-a is that project-a seems to be really data-driven, thats what we have in common and is really important to me and I like the concept.'
Before I actually started the internship I setup some custom-events in Google Analytics for http://pmig.at and attended lectures about Software-engineering and Project-management, which contained SCRUM, Kanban and traditional concepts like the waterfall or V-Model, so in the end I passed the requirements. But I really wanted to get things started.
Learn fast by breaking the ssytem into little pieces
One week before I started the internship I got the information that I will work with the LATAM (LATin AMerican) Team. During that time Natue1 (A Brazilian E-Commerce Shop that sells products to provide customers a more healthy lifestyle) was the only publicly announced LATAM venture.
At first I wasn't excited about e-commerce. I already knew some shop-systems like Magento, OXID4 or JTL and felt the pain of developing plug-ins without real PHP skills (It really hurts). I had the strong opinion that the most stupid thing you can probably do as an e-commerce store is to create your own e-commerce platform.
And I was so wrong...
On my first day I made contact with the Project A e-commerce platform Yves & Zed2. It's a complex architecture between Solr, Memcached and 2 different PHP-Frameworks. It believes in a strong separation between the front-end and the back-end. From a front-end perspective you hardly have to do any backend-requests. Instead you get all the information from Memcached and Solr. And that's scalable.
I was reading the documentation the whole day while setting up my Ubuntu Box (free choice of OS is awesome) and the deeper I went in the documentation and the more pages I read in the project-a knowledgebase the I happier I was with being part of an e-commerce team and having 3 days to explore everything by myself, because there was so much new and exciting stuff out there I couldn't wait to get my fingers on.
And I needed the time. For me Yves & Zed is still a black box in some cases after 3 months working with it and that's good like that. I tried to learn as much as fast as possible. To do so I tried to break down the whole system into small parts. At the beginning I didn't need to know everything. I was satisfied that I knew how the back-end and how the front-end is called and what's their main purpose, so I could look for other things I needed to know. For me knowing the workflow and the people in the team was equally important to knowing the system and the product itself.
And after some time I I felt there was even a benefit of not knowing every detail about the system. So you can think about new features and improvements with less restrictions and without worrying about classnames and models. If something is really impossible or not worth the effort the developer will say it anyway and for bigger changes a dev needs to participate in the specification process.
The concept of breaking big things into small molecular parts helps me to get an overview about all the pieces. For every molecule you can ignore the HOW for the beginning. You just care about what they do. As soon as you have an overview about a lot of molecules you can start to connect them. I really try to focus on the linking instead of asking myself how a molecule works. Maybe I will discover some patterns between two molecules which helps me to understand them better and break them down into little atoms.
So I tried to perform a breadth-first approach and did not bother with details.
And it actually worked quite well for me. Slowly I discovered new parts about the system, the people, my actual tasks and the workflow. And the workflow was agile.
After 3 days I knew to which product I will contribute: Natue, at that point 9 months old and epicerie, an open e-commerce shopping club selling wine in Brazil, at that point 3 months old.
And I finally got introduced to the Product Manager that I could sting with questions and learn form, all the time.
The LATAM team does a mix between SCRUM3 and Kanban4. There is one prioritized Kanban Backlog for business to have an overview about their needs and a prioritized Ticket backlog for developers with detailed specification. Now the PM has to juggle around cards with business and tickets with devs. Once a week an estimated amount of cards which is ready to start will be moved to the backlog for the week. This Kanban column kind of represents a kind of sprint, but it isn't really strict. It's OK if a ticket takes longer than the week to be finished. Everyday there is the stand-up meeting where everybody talks about what he has done and what he will do today.
I personally think that software really benefits from an agile processes, if it fits the team.
I neither have experience with strict SRUM nor with strict Kanban, but people say real SCRUM slows you down. They also say you need big teams to do it right. All your tickets need to have a time-expensive effort estimation, often called 'Story points'.
This time estimation is used for calculating the right amount of tickets for the sprint depending on how many story points the developers can handle.
During a sprint you are not allowed to add tickets to sprint and all the tickets have to be done in the sprint and will be deployed by the end of the sprint, so you are not really flexible for the duration of the sprint (usually 2 weeks) and there is a possibility that you could end up with a separated 'Bug-Fix-Team' that only has to resolve bugs and maintain the code. Maintaining a system is probably a good way to understand it, but every senior developer will try to get into the feature team as soon as possible and creating a rockstar-feature-team and an average-bugfix-team is probably not what you want to do.
Besides the fix sprints and strong processes SCRUM is agile. The iterative way of development should allow you to bring a lot of features live, often.
On the other hand you must be aware that iterative development often forces you to write code that you will throw away later. So you could either write super reusable and abstract code and assume you will need it again or just hack your prototypes into master. But I'm sure that there are developers out there will make good decisions.
_Today we actually had a good discussion about our agile process and how to improve it. We wanted to rethink about a few points:
How can we integrate developers more in process?
For me the right question to ask is, if developers want to care about business decision. In the end new features should try to fulfill business needs. And business must know what's going on and prioritize the needs. So who should decide which tickets will be started this week? On the one hand this job could be done by a PM and the IT-team-lead, because they have experience and can estimate accurately.
On the other hand the developers can have a look at the backlog and decide by them-selfs which tickets they can start in the following week. But does the team gain something from this process? It's definitely more involved in creating the actual product. But they also have to deal with nasty business needs and maybe some deadlines or pressure to deploy.
Do we have use deadlines?
I personally think: No. Coding is more similar to creating art than to do some manual work. So it's always difficult to reach these deadlines if you lack of inspiration or aren't satisfied with your current solution.
If a developer has to care about deadlines too, code quality will decrease and it will fire back in the longterm.
If you really want to get it rid of deadlines, you must trust the developers that they keep focused on the main issue itself and won't try to fix problems that are out of the current ticket's scope. If they do so the project may slow down and work will be done twice, because there should be a different ticket for a different task.
SCRUM vs Kanban?
After 3 months working agile, I would prefer of taking the best of both: A separation between business and developers. I think business needs a rough estimations when they can expect features to go live. Developers should always have the possibility to grab a ticket from the top of the backlog and have dashboard where they have a detailed overview which tickets are in which status including bugs.
It's not over
This was the first article on my recap of my internship at Project A. I talked about my first days and agile development. And I still want to write about:
- Create Products customers love
- my imagination of the role of the CEO
- how the add the most value to your products as a PM
- How I imagine the future of Product Management
I would be pleased if you sent me feedback and ideas how to improve, so I can follow the agile way! Just use you favorite social media channel.
Thank you for reading!