You may have a process or way of working in your agile team, but what do you do when you have to interface with other kinds of teams? Perhaps they’re not agile, or perhaps they want to be agile. How do you learn to work with each other?
Here is an approach that might help. These are things that most teams that I’ve worked with either believe in or aim towards. It’s more than a manifesto—it’s some things that explain some specific common practices. The idea is that if you can say “we believe in these things” then it’s the first step to finding a way of working that is consistent with both your approach and the other party’s. These aren’t in a very strict order, and your own list might be slightly different…
We start implementing while retaining uncertainty. Unlike a more traditional approach to project delivery a lot of implementation kicks off without knowing all the details.
Overarching plans are valuable. Despite the last point, it would be wrong to say that all long term planning is verboten. High level visual and engineering designs, for example, are still valuable, as is a clear project outcome or strategy.
We will change course constantly. This is reality, and valuable to any organisation that operates within a shifting context (i.e. any organisation). Handling this needs to built into any process.
We want high “walkawayability”. We need to be able to walk away from any work in progress with minimal cost. If we deliver nothing of value for a period and we walk away at that point, we’ve lost everything done over the period. We want that period always to be as small as possible.
We must minimise our reliance on particular individuals. This is because we want to deliver consistently and sustainably. We want people to be able to take holidays or change role. So we share skills and experience as much as possible. This is one of the advantages of pair programming.
We always prioritise by value. This is because we expect things to change. So if we’ve done the most valuable things already then the changes have minimal impact.
We deliver in the smallest possible pieces. This helps us deliver more frequently. It also helps us prioritise by value, because by splitting one piece of work into two smaller pieces we will most likely find that one piece is more valuable (to be done sooner) while the other can be done a bit later.
We want to minimise the cost of change. This is a major motivation behind extreme programming. This principle ensures we can handle change much more comfortably.
We want to deliver value continuously. Since we expect change, and since we want the option to always walk away, then delivering continuously makes that a reality.
The product manager/owner is final arbiter of value (after listening to all the stakeholders and experts). This ensures clarity of vision, and simplifies things. Scrum has this principle embodied in the product owner. This also presents a challenge to scaling up our process.
We want to push decision-making right down the hierarchy. We want to trust people, and this aids speedier, more intelligent delivery. We need to ensure the people on the ground have the right guidance and skills, and the feedback loop is tight and continuous.
You may have different principles. In fact, I’ll probably think of some different ones tomorrow. The point, though, is that a list like this can be useful for explaining how and why we work like we do, and so act as a useful way of finding out how to work effectively with others.
niksilver.com 