All signals

The lean start-up movement

The Lean Start-up was coined by Eric Ries to describe new trends in the start-up landscape as a combination of the use of open-source software, agile development methodologies and ferocious, customer-centric, rapid iteration. This signal explores the value of the approach, how we apply it to our work and how it can form a new philosophy for product development for agencies.

It's not how fast we deliver, it's how fast we learn

In an iterative process like software development, over time what defines winners and losers is not how fast teams deliver features. It's how fast they learn about what works and what doesn't for their businesses.

Delivering less in each cycle actually helps them to learn faster. In software development, most of the value comes from acting on customer/user/market feedback.

Every feature we're asked to deliver is at best a guess. And we can cram as many guesses as we like into each cycle of delivery, but our productivity is not defined by this. It's defined by how readily we can act on the feedback we get with each delivery. The more frequent the feedback, and the longer we can sustain our ability to act on feedback, the sooner we will arrive at the real value in what we're creating.

In a market like Video-On-Demand, we can be sure of one thing. Whatever strategies work today, they will probably be irrelevant tomorrow. The challenge of products like YouTube, iPlayer and Canvas is in recognising that continuous, sustained evolution in years to come is what will define the market leaders, not fast delivery to gain market share in the short term.

Extract from Jason Gorman, you can read the rest of his post here. He is focusing on the obvious deficiencies in the UK government's "Digital Strategy" which has so far totally failed to take into account these principals. His post is mainly from a coding perspective but the 'learn fast' model he outlines is one we try and stick to at Made by Many in all aspects of what we do. Equally, we can face similar challenges when we work with clients who are not used to approaching service delivery from the perspective of 'sustained evolution'.

source http://parlezuml.com/blog/?postid=932

We don't need no stinkin' process

Just discovered this excellent post from Energized Works, who recently gave us some Agile training, on sacking off the ritual in favour of a natural flow.

Another thing is ... we don't need no stinkin' process . I reckon it's because our team is small, has only generalising specialists who have worked together for ages, we trust one another implicitly, and our environment is extremely collaborative and fun-packed. Ok, it's not entirely accurate that we have no process. I just wanted to use the Blazing Saddles clip. There is some semblance of a process but, honestly, it really, really doesn't feel like it. It just feels like the natural flow a conversation takes. Perhaps it's that the interactions are so second nature to us it just seems like everything is a conversation triggered by something that's happened or has been discovered: 

  • Discuss a story in a pomodoro.
  • Pair up and pull its card into play.
  • Start slicing - working inwards from behaviour-driven Selenium acceptance tests, incorporating any non-functional and sysadmin work, while iterating the interaction design work.
  • Call a timeout and talk in a pomodoro when something important happens.
  • Deploy the accepted story to production.
  • Go again.
I guess it's essentially Kanban and one piece flow, perhaps with a few twists we've introduced over the years. We just say keep it moving - keep it working - keep it together - keep it real - and keep it coming. (We evolved to our kanban-like thing independent of the Kanban movement . Hopefully David Anderson will corroborate that claim. I think this is interesting because a mulitude of separated parties, working independently, have concurrently evolved their process, given their own interpretations of the Toyota systems, to arrive at something with similar properties. It may be plausible to argue that this was predictable given the specifics of the Toyota systems.) 
source http://bit.ly/ceR11k

Technical Debt versus Product Design Debt

In this post Andrew Chen discusses both technical debt and product design debt.

Most startups these days build products using the various philosophies of agile – both in the formal sense but also the informal sayings of “deploy early and often,” “fail fast,” “ship and iterate,” etc. Coupled with A/B testing, customer development, and thinking through business problems in a scientific, hypothesis-driven way, you end up with a powerful cocktail of techniques to build a modern startup in the most iterative way possible. This kind of incrementalism is mostly great, and people should generally do more of it.
 
The interesting part is when you get a couple months into your product cycle. You often end up with lots of half-done experiments lying around, an infrastructure that isn’t built to scale, and a mishmash of code that needs to be refactored. Most engineers know that in this kind of a case, the best practice is NOT to rewrite your code, but rather refactor it continually and take down the so-called “Technical debt” so that it’s always under control.
 
However, there’s the other side of the coin, which is the product design. After you’ve added a ton of new features and stuck them all on the homepage, you create Product Design debt. The Amazon tabs at the top are a great example of this – you have a design philosophy built around tabs, you scale it as far as you can, and then you have torefactor your design.
 
Arguably, MySpace is a company that never paid down their product design debt, and their traffic has been impacted as a result.
source http://bit.ly/crdPhw