Products, not projectsIn a digital business, agile management is about products, not just projects. Projects have a defined end-point, after which teams move on to other work. Products, meanwhile, have a much longer lifecycle. Where projects require temporary teams, a product needs lasting support. If you apply a project mentality and remove all support for a product once it hits the market, you confound the agile practice of launching minimally-viable products to be adapted and improved once live. Not only does this result in a failed product, but it also means management will be less willing to invest in future test-and-learn experiments, instead putting all their money behind a single launch. Of course, this defeats the whole concept of agile, which looks to deliver value early and iterate upon it.
Give teams autonomyFor agile to work, teams must be given the autonomy to make decisions. If they have to wait for management, they will end up wasting time and not delivering. There’s also an added risk if decisions are passed up the chain: the further you are from the product, the less you understand the potential impact of your decisions, making poor choices more likely.
Get management on board
Too often, executive teams stick with a traditional “waterfall” approach to project management – that is, a sequential design process in which once a step has been completed, developers can’t go back to a previous step. Unfortunately, this way of working simply doesn’t map onto agile practices, and much time and effort is wasted as managers ask the wrong questions of agile teams, or try to translate between the two styles. Managers’ focus can end up on timings, plotting out accurate dates for delivery rather than helping teams to get on with their work. Of course, product development must run to timelines where required, but it’s important that managers understand the impact of such deadlines on the scope of work delivered.