Unless you can see all the competing sources of demand on the teams and on the organisation-and treat all of this as first-class work-you will continue to be disappointed that your expectations go unmet as all that unmanaged “ghost” work gets in the way. Whether you model your product development work as features, epics, stories, experiments or goals, this still represents only one type of work, namely customer-facing delivery.
You can only do this if you understand all the different demands on the teams. Sometimes teams may disperse and new teams form as the profile of the work changes. Based on these new goals, there may be some movement of people between teams. We also use these sessions as an excuse to celebrate what we have achieved. So where does all this “day job” work happen? How do we ensure it does not fall through the cracks, or derail the teams’ efforts to provide new business capabilities? Make all the work visible ¶įor programme-scale product development-typically in the 50-200 person range-we run quarterly planning sessions where we review progress, align on direction and strategy, and set ourselves challenging goals using OKRs. Again, they have sales and marketing folks in the team, who also need to carry out customer research and manage campaigns. Another team is mining customer data from various fragmented sources to provide sales and marketing insights. This team has a couple of invoicing staff in it who, while helping to shape the solution, still need to send invoices out. One of the teams is helping the finance department to streamline their invoicing processes and automate the repetitive parts. We are adopting this terminology to distinguish them from the development-only teams we tend to find in organisations that have a Technology or IT function separate from “The Business”. One of my clients has reorganised into genuine “value stream teams”. The original XP project was a payroll system at Chrysler, and the customer in that team was the payroll supervisor, who was still responsible for people being paid! The real On-site Customer is there to act as both a subject matter expert and a “model user”, helping the team to understand their priorities and needs. This is literally the person who will use the product the team is developing! Scrum attempted to model this as a Product Owner, but the dynamics of that relationship are totally dysfunctional: the PO is only a proxy customer but they wield a disproportionate amount of influence within the process. Back in the 1990s, XP proposed that the “customer” for the team should sit with the team. Create genuine cross-functional teams ¶įor all the talk of cross-functional teams, most digital product teams only comprise the development side of the equation: developers, testers, product managers, and so on none of their users or business stakeholders are in the team.
It turns out that working harder or longer hours was not the solution after all. The real win is that they can achieve this at a sustainable pace. Teams report feeling more empowered, more focused, more autonomous, more self-reliant more able to see the impact that their contribution is making. This feels disruptive at first but quickly pays for itself. People soon realise how much faster work can move through the system–how much sooner we can realise value–by moving the people to the work rearranging people into teams aligned with these value streams. Something else needs testing first something else needs a firewall port opened first something else needs a change to a database schema first, or a security review, or an API change in someone else’s service. Often, we discover that work items are bouncing around all over the organisation, joining queue after queue of work, sitting for days or weeks blocked by completely unrelated work items ahead of them in these queues.
I like Event Storming as a way to get a group of people to understand a value stream, and Wardley maps to visualise and help guide the conversation. One of the first things we do when we start working with a new organisation is model its value streams: “How does the work work?” how do people collaborate to provide value to their customers, and how does work move through the organisation? There are many ways to do this. Making all the work visible means we can measure our real capacity and prioritise for changing business needs, rather than having “ghost” work hiding in the system. I like to make this kind of work explicit, as one of several types of demand.
Network topology diagram how to#
Less obvious is where the day-to-day “Business As Usual” work sits, how it gets prioritised and measured, and how to ensure it is not neglected. It is easy to see how this work adds value and where it should live. When people work in product-based teams, the product development work is front and centre. When you make all the work explicit, you get fewer surprises.
0 kommentar(er)
