“We are not working in this a ‘Agile‘-mode that you’re working in.” she said. She actually tried to disparage the lack of structure in the other team she has been assigned to work with. The team this lady belongs to consider themselves a marketing team. In a high-tech company. Marketing, but still: for technology.
After the assignment to the new team, this lady actually tried to mock the lack or absence of procedures in the new team. Her comment meant to refer to any processes but literally trying to differentiate herself.
The team she is working with initially tracks their tasks of deliverables in a so-called Kanban board. The same team conducts daily standup meetings, that are facilitated by a process owner. About once every other week there are so-called review meetings with the team manager and external stakeholders.
Of course, it is conjecture. At the same time, this pattern that can be observed in many places. People try to differentiate themselves from the working class, the programmers, the technical guys. While in reality, all colleagues contribute to the same product.
So ultimately, the differentiation between being technical and the business ends up being more hurtful to the companies culture. Not to mention the effects of digitalization, that is based on the assumption that technology will improve everybody’s life. Assuming more technical acumen, even as a business person, will make you a better, more efficient person. Being technical is independent of working in agile mode.
In Softwareprojekten an sich Aufgabe des Scrum Masters gegenüber dem Team und dem Product Owner oder dem allgemeinen Management. Häufig wird die Rolle als “Beschützer des Teams” wahrgenommen. Der Scrum Master soll dem Team helfen, eine realistische Einschätzung Ihrer Fähigkeiten abzugeben und nur Aufgaben zu committen, die realistisch in einem definierten Zeitrahmen geliefert werden können. Unter anderen Aufgaben dient diese dem Zweck, Erwartungshaltungen der Stakeholder zu managen und das Team vor überzogenen Ansprüchen zu schützen. Längerfristig führt das zu einem guten oder besseren Verhältnis zwischen allen Beteiligten, mit einem Vertrauen in gegenseitige Erwartungen und Aufgaben. Ein gutes Verhältnis wiederum hilft dabei, produktiver Software zu schreiben und Mehrwert zu liefern, anstatt Diskussionen zu führen.
Die paar Worte auf einer Fliese in einem Schaufenster beziehen sich mutmaßlich eher auf rein zwischenmenschliche Beziehungen. Dort ist es aber genau so wichtig, sich gegenseitig zu verstehen.
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.
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.
One question that somebody asked me a few days back keeps me thinking for a while now. Mostly, because it should not have a clear answer. Have you ever had to ask yourself, what to do when your heart-project is at risk to come to an end? A project that just dies, has had some serious problems. A dead-end, that leaves no next steps, along a final decision. In a way that no project goal materialized and no other milestone is reachable? If that is looming to happen, one should consider to check the project plan and answer a couple of questions about the failure. How did all the tasks and work packages depend on each other, that they made an entire project fail? Were some assumptions to optimistic? Was budget too tight? Was the project to ambitious?
The show must go on
Depending on size, no project is barely ever dead. Typically, a project consists of multiple components. Milestones, Tasks, Work-Packages, are just common terms for break downs structures of a project. Such fragments, re-used or re-arranged, can help achieving a modified goal. There are reasons, one or another milestone had difficulties. There are hard facts, like budgets, technical dependencies or necessities, required skills, availability of material or combinations of anything. And there are soft facts, like project team engagement, stakeholder opinion, even hubris may result in milestones not being reached.
A roadblock, identified early enough, allows to realign a project plan, to cope with any trouble, endangering tasks and milestones. In an iterative project approach, the project lead can change a goal, aligning with changing requirements. This way, the project may not reach it’s initially intended goal, but it will not fail in its totality. When a project dies, it will leave bad feelings with the budget owner, with stakeholder and the team. A goal that the team reached, maybe through a more creative approach, will still be a goal reached.
Nach dem Artikel über Projekt-Management Software von letzter Woche sind noch Verweise auf weiteres Angebote eingegangen, die nicht alle frei im Sinn von “Free Beer” sind, aber trotzdem so interssante Ansätze verfolgen, dass Sie hier genannt sein sollen. Die folgenden Lösungen fokusieren sich stark auf agile Ansätze und machen sich Scrum wie auch Kanban zu Thema.