no more cubes

Tag: Agile

  • Agile Theatre

    Agile Theatre Naming Convention v3
    Agile Theatre Naming Convention

    Did you ever work in waterfall managed projects? Coming to a company that introduced agile just recently, chances are you will recognise plenty of behavioural patterns. Playing the waterfall game to pretend to be agile is called an agile theatre.

    The phenomenon of this agile theater is not new. And in fact, a misunderstanding of fundamental principles in agile is one of the major issues with the introduction of this approach. Going full agile requires a fundamental change of culture, a lot of trust and self-sufficiency, that most companies cannot find easily, in particular coming from traditional industry best practices and established waterfall procedures. Most often the introduction of agile methods for project- and product management ends with the introduction of new language.

    In this matter, smharter.com was kind enough to collect and publish a collection of translation helpers, to help you identify an agile theatre. The terms and their translations will help you identify agile theater much quicker.

    via www.smharter.com

  • Product Management Predictions

    Product Management Predictions: With January already over, it’s a bit late for annual forecasts. But then again, looking into the future is a secret superpower every Product Manager should look to develop. Therefore, it’s never too late to have an understanding of what comes up next. Mason Adair of Digital Product People did so for the profession itself.

    Product Management Predictions for 2020

    Ten Wild Predictions, One True Story and some Solid Career Advice

    From the article

    Just like the industry is changing. And the article makes an effort to put into relation the different aspects Product Management has. Mason starts his thoughts by looking into public available metrics that indicate the importance and projected relevance related to management of products. In this analysis, related topics range from Agile, Minimum Viable Product, Design Thinking, Lean Startup, Product Market Fit, Rice Prioritisation and Net Promoter Score all the way to Jira, Trello and Asana. With an analysis of how relevance for these topics changed over time, the article goes into setting the scenes for professional trends that influenced the past years. These include economic environment, the introduction of new technology, a demographic shift, increasing societal fragmentation and climatic change.

    Product Management Predictions shape the conclusion in his article: 10 wild predictions I believe are not that wild. The top most prediction, Product arriving at the C-Level, is almost no prediction anymore. Digital companies already have recognised the importance to actively influence direction towards customers.

    Read more: The Future of Product Management in the 2020s – Mason Adair – Medium

  • The possibility to understand: SaaS Product Metrics

    Colorful Rulers to Measure
    Do you measure up?

    Part of the compelling nature of SaaS Products is the possibility to understand the user and improve on the go. Any Product Manager will literally have to understand what are the use-cases for customers and how to focus on the important areas. Just recently our team led the debate which metrics would be the right ones to focus on.

    Nancy Wang, Head of Product Management at Amazon Web Services, highlights six product metrics enterprise SaaS companies should track.

    In this Article, Nancy Wang, head of Product Management at the most successful cloud service providers, shares her insights on important metrics to keep an eye on. The possibility to understand often goes overboard and requires focus.

    The case under discussion in the article revolves around paid products. Derived metrics are a foundation that serves as a blueprint to other products in the SaaS space. Goals differ, but ultimately, to make a product successful, it requires an understanding of how successful customers were, using the product. Following the established funnel pattern, users are being segmented into funnel. Along that funnel, the metrics acquired need to reflect the stage of the journey the user is on.

    At the top of the funnel, most often the interaction is anonymous and requires profiling to understand the audience coming in. Further down in the funnel, metrics capture engagement and transaction. Towards the end of the funnel, the metric needs to relate to retention.

    Source: Do You Measure Up? Metrics for Enterprise SaaS Product Managers

  • Do away with the Product Owner Role

    Mike Cohn of Mountain Goat Software has an opinion on Scrum’s Product Owner Role. It’s controversial, and Product people will disagree.

  • Why Would You NEVER Apply Agile Software Development Processes?

    A central statement in the Agile Manifesto is to put Individuals and interactions over processes and tools. Many development teams, in particular those with less experience, lack the self sufficiency to deal with this freedom. It’s probably not the exact answer to the question, but it makes Agile a lot more difficult.

    Here is the original blog: Herding Cats: Why Would You NEVER Apply Agile Software Development Processes?

  • Culture and Organizational Change

    Culture and Organizational Change

    Just a small observation I made during AWS Transformation Day. While the entire theme for the event was on transforming business, the schedule had one track for “Culture and Organizational Change” alone. While Culture and Organizational Change is a broad and huge topic, but it is necessary and makes the difference for agility in rapidly changing and competitive markets. Amazon has been talking about this for years and they share their knowledge with their partners.

    On an attempt to find out how organizations actually master this, the perspective most consultants and companies I talked to during the event shared with me was rather sobering. Anyone exhibiting at that event merely offered to run any software project under an agile management. No support, consultancy or even efforts to drive actual change, whatsoever, at least nothing that would exceed a traditional software project scope.

    Cultural and Organizational Change is something requiring executive buy in and is killed quickly by means of exhaustive efforts to plan ahead. Culture needs to embrace the possibility to change quickly, throughout the process. And the wish for management is human, to have transparency and perspective early in the process, it is just as natural in the process for developers to stay vague for items that are not yet clear.

    Any cultural change needs to embrace bi-directual communication and the ability to break down complex. On first thought this sounds easy, but requires plenty of cooperation and trust in a clearly defined team. Culture is rooted in clear understanding of roles, responsibilities and not to mention last, trust of all members.

  • Product Management vs Product Ownership

    The organisation that I am part of introduced an overlaying Product Management department only fairly recently, less than a year ago. Early in the time it was exciting to see this role dedicated to market and customer perspective, but it raised questions over how this was different from Product Ownership from day one.

    Over the course of the past year many discussions have been led and lot’s of articles have been led. This week Anthony Murphy shared his perspective and experiences on the Product Coalition. While my own experiences with this separated role have been predominantly positive, I tend to see the necessity to split responsibilities for larger organisations. The article is reflecting on why the Agile movement created the Product Owner in the way it did and how it was meant to abolish the Product Manager to start with.

    A story of love, hate, oppression and triumph

    Source: The Collision of Product Management and Product Ownership

  • DIB_DETECTING_AGILE_BS_2018.10.05.PDF

    Das Pentagon hat sich vom Defense Innovation Boards ein Papier erarbeiten lassen, wie Agile BS zu erkennen ist. Die ein oder andere Frage wird dem geneigten Leser aus der Softwarebranche sicher bekannt vorkommen.

    Das Paper ist hier: DIB_DETECTING_AGILE_BS_2018.10.05.PDF

  • Fixing issues in Software

    So machen Profis das.

  • Agile Werte

    Mein Team führt schon seit geraumer Zeit eine Diskussion darüber, wie man den Prozess verbessern kann. Und das ist auch gut, denn ständige Verbesserung ist ein zentraler Bestandteil jeden agilen Handelns.

    Allerdings liegt die Antwort auf die Frage nie in Werkzeugen und deren Möglichkeiten. Um das Problem zu lösen muss dessen Ursache verstanden werden. Jira bietet sicher viele Möglichkeiten, noch ein Feld einzuführen. Wenn die Diskussion sich darum dreht, welches Feld am besten ergänzt wird und wie ein Zustandsübergang abzubilden ist, ist das agile vollkommen aus den Augen verloren.

    Eine unmittelbare Konsequenz von Werkzeugen ist, dass sie es Teammitgliedern erlaubt, Verantwortung abzugeben. Der Zustand wird möglicherweise richtig abgebildet, das Feld richtig gefüllt. Nun ist es an jemand anderem das technische Problem zu identifizieren, die Person weiss möglicherweise nicht einmal über den Zustand Bescheid.

    Agil soll heissen, das Vertrauen aller Mitglieder im Team soweit herzustellen, dass notwendige Arbeit in Standup Meetings oder spätestens im Review transparent gemacht wird. Dabei kann kein Tool helfen.