Archive for the ‘agile’ Category

  • The more you try and practice Agile the less agile you become. And vice versa

    This Agile has a capital A. It can also have a lower case a, in which case it is an adjective, to be lean/nimble but that’s not what I’m talking about. Agile with a capital A is a noun, a name used for the philosophy described in the the Manifesto for Agile Software Development and the suite of methodologies primarily used for software development such as SCRUM and Extreme Programming.

    Tim’s post on Agile as a ‘Cargo Cult’ highlights a problem in the adoption of Agile, not only for software development but for creative and business processes. Everyone is trying to adapt to a rapid and disruptive world screwing with business models in every category. Organisations are looking to close the gap with nimble digital start-ups who are out-innovating them at a fraction of the cost-base. Agile seems to offer a well-packaged magic ability to compete in a new way.

    Unfortunately, a lot of confusion happens between being Agile as an adjective and a noun. Without understanding both, without the philosophy of being nimble and the processes of an Agile methodology, failure is assured.

    At it’s best Agile is fluid and rigorous, it can be more controlled and structured than a waterfall project but open to adaption and change. There is a necessary tension between the rigour on one side and it’s resistance to codification on the other so the more you try and practice Agile the less agile you become.

    When it comes to adoption lots of people suffer from the McLuhanesque mistake of appropriating the shape of the previous medium as the content for the next (props to Scott McCloud). In this I mean that they try to fit some of the rhetoric of agile around their existing people, culture, process and tools. This normally happens in one of two ways:

    Read full post

  • Tear down this wall! Crowdsourcing comes of age

    Hello. I’m Sara and I joined Made by Many last month. My forte is content, so it seems appropriate that my first post should be all about conversation… specifically the two conversations that go with just about every digital project.

    Never simple, is it?

    The first of these is all about the customers, the people for whom we’re building this product or service. This conversation is pretty user-centric: essentially, what do they need? What are their problems, and how can we help solve — or at least minimise — them?

    Then there’s a second conversation — the behind-the-scenes, creative-type stuff about how things actually work. What functionality do we offer? Do our user stories tell the whole story, and does it have a happy ending? What about typeface and layout? And finally, how the hell do we iterate this beast? Read full post

  • “Get Excited And Make Things”

    That’s the line that unpacks ‘Planning-ness‘ – an ‘un-planning’ conference held recently in San Francisco.

    The idea of “making” things as a way of exploring ideas and developing and articulating strategy is close to our hearts at Made by Many and Planning-ness sounds like a veritable Festival of Awesomeness. I’d love to go next time.

    But it was this provocative deck by Jason Oke and Gareth Kay that got us really excited. It’s about the failure of ‘Connections Planning’, the discipline’s historical context, and what it seems to be mutating into – or at least needs to turn into in order to continue mutating.

    As someone who is not a planner of any description and doesn’t even work in advertising, I’m not sure I am that entitled to talk about it – although that’s never stopped me before.

    It feels like we (the MxM ‘we’) have lots in common with the kind of problems Jason and Gareth are trying to solve, and with the agenda of Planning-ness in general. We come at these problems from a slightly different set of perspectives: Interaction Design, Service Design and Agile Methodologies, but everything is converging – seemingly even our job titles, what we do, and certainly the industries we work in.

    Here’s the deck, below. I’ve also picked out some of the highlights (from our MxM perspective). I’m hoping it will provoke a debate inside our company about what we do and how we talk about it – and so, I’m not going to comment too much right now.

    I’m also hoping to write something more about the ways we’ve been working experimentally with BBH in very integrated teams on some projects. Mixing what BBH call Engagement Planning up with Interaction Design and Software Development, all within a broadly Agile process, has been really rewarding – and is very relevant to ideas Jason and Gareth set up in Connections Planningness.

  • Pulling Off The Optimal Platform Job

    Another week, another blog post on the subject of “why creative advertising folk need to embrace ‘technologists and their geeky ways’” once again ignites vigorous debate.

    The post in question is by Joe Mele, VP Client Partner at Razorfish, and received a great many comments and a huge number of re-tweets of the @BBHLabs‘ tweet that contained a link to it. The citizens of Twitter seem to react with a combination of self-loathing and schadenfreudian glee to the disruption that social technologies are wreaking on advertising. It’s a little bit dull and frankly misses the point – and it wasn’t quite (I don’t think) what Joe was saying.

    Of course, how advertising responds to the digital challenge is a roasting hot topic. Joe’s blog post quotes a recent article from Ad Age provocatively titled ‘Agencies Need To Start Thinking Like Software Companies’ that talks about hybrid creative techies bringing digital know-how to Madison Avenue. If only it were that easy. It seems overly simplistic to claim that everything will be okay if they hire in some digital savvy, perhaps even ‘developers’ – let them attend client meetings and, you know, even help out with creative ideas and stuff.

    Unfortunately, I think it’s a lot more complex than that – and whilst I totally agree with everything Barbarian Group Co-founder Rick Webb, says in the Ad Age article, I’m not convinced he *totally* nails it either:

    What they should have been taking away all of this time — and have increasingly begun to — are the concepts of the constant beta and agile development. Marketers need to abandon the time-limited campaign online and start to think of it as a constant application of a rigorous discipline.

    Rick’s completely right about needing an agile, adaptive, evolutionary approach, but I’m starting to believe that you need more than that to deliver the kind of long-term living platforms and platform-campaigns – and value – that clients need and agencies must get better at creating. I’m starting to believe you need four things, the first two of which are well-known and increasingly often quoted:

    Read full post

  • Agile measurement

    Anjali’s blog post on ‘Measurement versus engagement‘ made me think.

    We’ve spent a great deal of effort over the last two years smashing painstakingly integrating Agile thinking into the strategy and design practices, but at the other end – the delivery end of the process – Agile is too often neglected soon after launch.

    This shouldn’t be surprising.

    It’s difficult, if not impossible, to keep all that innovationism going for extended periods of time. Often, the innovation team within a client organisation moves off onto new projects and hands the service to less risk-friendly teams, where people have KPIs set by line-managers who don’t know about very much about the project and almost certainly have no idea of probably much less understanding of the Customer Value.

    Sometimes the fervent adoption of Agile methodologies that happened during the Vision and Service Definition phases turns out to be superficial and temporary. Who doesn’t like Agile when there’s tons of new code and excitement being demonstrated on a daily basis, and when you can get things done with less pain and far more rapidly than you ever did before? It’s definitely more difficult infinitely more challenging to adopt Agile as a culture, over the long term. “Iterative” and “emergent” are best intention ideas that make total sense during the Vision phase – but are VERY difficult to do on an ongoing basis, especially if the culture at large within the client business doesn’t get it, which is a big ask let’s face it!

    But occasionally, even on innovation-geared projects, it’s the metrics what kills it.

    Typically, there may have been a conversation early on in the project where you were asked to make some guesses about traffic and registered users. You may have been reassured that these would not be treated as promises, and you probably made the point that it’s very risky to make those kind of predictions with an innovative and emergent service like yours, I mean – how could you possibly predict these things, and they’re not the right things to measure anyway..? Whatever. A metrics time-bomb has started ticking.

    Agile gets rid of fixed scope/fixed budget which is great – but that means nothing if you replace them with some dumb fixed metrics. So, I’m arguing here not for less measurement or no measurement, but for an Agile approach to measurement – which, obviously, I absolutely understand the need for.

    Agile measurement should focus on simplicity and Customer Value. It should make it easier to measure the things that matter to make the service better for its users – to improve the value exchange. Instead of asking what success looks like, ask what value looks like.

    It follows then that Agile measurement should measure fewer things. There is a risk – especially with all the new tools and dashboards and diagnostics – of measuring far too much. Measurement is in danger of becoming an end in itself. A smaller set of metrics and diagnostics – “just enough”, in exactly the way as Agile methodologies treat other types of documentation – should help. Even trying to find the “one key metric” that rules them all – and is tied to the economics investment and supported by executive management – is suggested in this awesome paper I found online and have plundered ruthlessly for this blog post. That makes so much sense.

    You should also try and measure “outcome” rather than “output”. It’s not about big numbers, it’s about having the biggest impact on Customer Value. A small community of incredibly engaged, high-value customers is much more valuable than 1 million people who registered to win a car. Obviously, you’ll have first needed to have defined upfront what Customer Value actually is – for you, your project and the business sponsoring it. If you’ve been working Agile from the outset, you should have a pretty good idea of your customer/end-user and their needs, and the value exchange that’ll get them returning hopelessly addicted.

    Maintaining a living, ongoing dialogue with users will certainly help – and is essential where the one key metric is for example a softie, like brand perception. But you should generally focus on a small set of engagement health indicators: like the number of visits per user per month, dwell time,  participation, recommendations to friends, positive buzz across other social networks leading to sustained referrals. I’ll also add receiving offers of help from partners and people wanting to be involved, and good ideas from users – and the holy grail: people start using the site for purposes never envisaged. Remember, EBay realised there was an online market for cars when they found customers selling grown-up cars in the toy section.

    Lastly, you should be able to review targets, metrics and diagnostics to optimise your ability to understand Customer Value as the service evolves. Within an emergent, iterative innovation-geared project, you may not even understand the true value and how to achieve it until much later.

    What does anyone else think?

You are currently browsing the archives for the agile category.

Our latest tweets

Categories

Archives

Find us on the web