Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why departmental egoism doesn't work and how we're trying to overcome it

Why departmental egoism doesn't work and how we're trying to overcome it

Luisa Faßbender (Project Manager) and Christian Spoo (Senior Developer) have been working alongside each other at Marketing Factory Consulting GmbH in Düsseldorf for almost 4 years. Manpower Shortage and Inquisitiveness led them down the road of rethinking departmental egoism, where the idea of the “programming PM” was born. Tune it to hear, how they established the idea within the existing company structure, which steps they’ve already taken and which results have already been accomplished!

Christian Spoo

August 02, 2020
Tweet

More Decks by Christian Spoo

Other Decks in Business

Transcript

  1. Why departmental egoism doesn't
    work and how we're trying to
    overcome it
    Luisa Faßbender & Christian Spoo
    Marketing Factory Consulting GmbH

    View Slide

  2. Introduction: Who are we?
    @luisasofiexoxo @teh_plague
    Luisa Faßbender
    Project Manager
    Christian Spoo
    Senior Developer

    View Slide

  3. Background: What led us down that road in the first place?
    ● Manpower Shortage
    ○ Monkey Work shouldn’t have to be done by experienced developers
    ● Expand Knowledge
    ○ Enable a more comprehensive project understanding for PMs
    ○ Also: Some PMs don’t just want to organize projects, but also contribute to the project
    ● Tear Down Barriers
    ○ Stop the “That’s a developer job” / “I can’t do that” mindset
    ● Improve Customer Support
    ○ PMs should be able to respond to customer questions more proficiently than “I’ll ask a developer”

    View Slide

  4. First Steps: How did we start?
    ● Engaging PMs in project development was not planned beforehand
    ● PMs approached our devs on their own initiative
    ● Together we looked for tasks they could help us with.
    ○ Translation files
    ○ Symfony form definitions (error messages, validation constraints)
    ○ replacing or adding versioned images and other project assets
    ○ later, HTML templating tasks, depending on the PMs’ prior knowledge
    ○ creation of Gherkin-based acceptance tests
    ● Since then we spend some time on internal trainings on various topics

    View Slide

  5. Setbacks: Which problems did we run into?
    ● Taking part in the development usually comes with a steep learning curve
    ○ Version Control Systems (e.g. Git)
    ○ PMs suddenly took part in day-to-day VCS workflows (e.g. Git Flow)
    ○ various languages (PHP, HTML) or syntaxes (YAML, XML, JSON) need to be learned
    ○ deep knowledge in the technologies used is required
    ○ How should we onboard people?
    ● Each developer takes responsibility for his/her work
    ○ What about security aspects?
    ○ What about our two-man rule?
    and also..

    View Slide

  6. Setbacks: Which problems did (I) run into?
    .. even just a single missing
    comma can break your neck and
    literally make you go insane.

    View Slide

  7. Current status: Which tasks are handled by PMs?
    ● PMs are actively working with Git
    ○ They contribute own commits
    ○ They work with branches and tags
    ● For small changes GitLab’s Web IDE comes in handy
    ● Depending on the very project they even have local dev environments at hand
    ● PMs use GitLab’s Merge Requests to coordinate and track merge efforts
    ● PMs deploy finished development iterations by means of GitLab CI pipelines

    View Slide

  8. Next steps: What are our future goals?
    ● Continue decoupling deployment processes from the developers
    ● Enable PMs to handle even larger parts of the overall project lifecycle
    ○ Let them gather requirements, realize them and deploy the finished results completely on their own
    ● Spread deep technical understanding among people
    ○ More in-depth knowledge leads to better recommendations
    ○ Customers love PMs who immediately can deal with matters of detail when asked on the phone ;-)
    ○ Knowing how the building blocks work together greatly improves QA iterations

    View Slide

  9. Learnings: What went well and what could we’ve done better?
    ● Give it a try!
    ○ Usually it is far more satisfying to help doing things instead of just selling the final product
    ○ Even seemingly “small” tasks can help with the ongoing process of the project
    ○ There really isn’t a reason why you shouldn’t give it a try ;-)
    ● A Continuous Integration system is definitely a must-have
    ● If your project can afford it: use test-driven development
    ○ TDD safeguards people in that it helps to avoid frustration at start
    ○ Mistakes can be spotted earlier in the process and before they accidentally go to production

    View Slide

  10. Want to join us?
    We’re always looking for new people to join our team in Düsseldorf!
    So if you’re down for complex, varying projects, a fun team and great coffee – come and join us!

    View Slide

  11. Thanks for listening!
    Questions?

    View Slide