Agile, Startups

Proof of Concept? MVP? Just tell me when it’s done!

The meeting between iterative product development and a company used to approaching product development through the project-lens can be quite harsh.

On one hand, you have set budgets and revenue targets. The project deliveries have been planned out in detail for the coming months, quarters or even years, with a chain of dependencies for the rest of the year.

On the other hand, you need to follow up deliveries and make day-to-day decisions that affect the scope and the end product drastically in a true agile manner.

All the while nobody can give an answer to whether you’ll hit your targets or not. And you, as a stakeholder or project owner, just want to know when it will be done!

Here’s the deal…

There are a few things to note when moving into this world of digitalising organisations and iterative product development.

  • Agile™️ doesn’t mean faster or cheaper.
  • You decide when it’s done.
  • Product development is hard.

If you’re willing to take my word for it then you can stop reading now. Otherwise, please continue…

Agile / DevOps / Lean doesn’t mean faster, cheaper or easier

Digitisation has been sold into organisations as the “way to go” and alongside this the notion of some form of agile software development. The implication (or outright promise) is that this form of development will be faster, cheaper or both. There are no guarantees of this.

Instead, what these practices mean is that you are able to test your assumptions in a more iterative manner. This means you can create just enough of a product that will allow a customer to use it and give you feedback before your next iteration. So, in this sense, it’s a lot cheaper to verify you are on the right path, and the cost of course-correcting is a lower than if this was a project going over several months or years.

Working this way is more demanding of your time, as you are now part of the team that builds and discovers the product — you need to be available on a more ad-hoc schedule. There are more small follow-up meetings and constant changes to priorities based on customer feedback, or new opportunities. Working like this is engaging and fun, but it can also be draining. Especially if you’re used to the more traditional “ordering” of software through larger “waterfall” -projects.

Product Development is Hard

The hardest part of building a software product is knowing what to build. You may have an idea of what you want to create, but will that actually meet people’s needs? Saying you need an app or a service doesn’t instantly make it something that people want to use. The only way to find the market-fit is to test it out with real customers and users. This is what an iterative development methodology offers — the chance to test assumptions before you run out of budget (money, time, goodwill, etc).

Gone are the days where business and in-house customers accepted sub-par products to be able to get their work done. Consumers are used to sleek, intuitive apps on the web and their devices. There’s no magic switch that causes these same people to lower the bar of what they expect when they enter their work setting.

This expectation of quality becomes a challenge for businesses wanting to raise the bar. As the quality of the products improves, so does the need to build the right thing. It is crucial to verify whether the pain you are trying to address is one the people using your product actually feel, and want dealt with.

To keep up with this pace means focusing more on product development as a core discipline, instead of something to be outsourced or managed from afar.

You decide when it’s done.

The dirty secret is that “it” is never really done — the elusive product remains a moving target. Getting something out the door is just the first step. Instead, the focus should be:

  • When is the product good enough to be valuable to the people using it?
  • How much are you willing to spend to find out how close you are to fulfilling those needs?
  • How do you know the product is actually attending to the needs and delivering value?

With an iterative process, you have the opportunity to approach answering these questions and respond by changing the direction of your product. But the only way I’ve found to get real feedback is to give full slices of functionality in front of real users.

Sketches, prototypes, proofs of concepts and minimum viable products are all viable approaches to elicit feedback — the earlier the better. Pick your flavour, be harsh with the scope, and get a working product out there!


Organisations’ need for fixed budgets, scopes and roadmaps can hinder you from realising the tantalising promise of value in a truly iterative product development cycle. That value is the agility to be able to respond to changing needs, and new opportunities.

Embrace experimentation through continuous feedback cycles and adjust the reality of where you are with a product based on them. Based on these feedback cycles you’ll know when you’re done.

Clap 👏 or follow Dolittle to read more about how we believe in enabling others to create products that help users feel like superheroes.

Cover Photo byJosé Alejandro Cuffia on Unsplash

This post appeared originally on the Dolittle blog

Communication, General, Teams

Hitting Refresh

Unlearning is one of the hardest parts with any transition. You bring with you many years of experiences, expectations and biases. These have built up over time through different work situations you have adapted to. Past experiences allow you to hit the ground running when it comes to work and communication. They can also be heavy baggage, slowing you down. In a startup this baggage could be the very thing that’s holding you back. You’re looking at completely new problems with views that don’t match your situation.

Here at Dolittle, we’re hitting refresh on many of our previous assumptions. Looking at old problems with fresh eyes. How we approach our coding practices. How we are working with customers. How we are approaching contracts. How we are building products. We’re re-learning, and allowing our culture to grow.

“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind there are few. ” –Shunryu Suzuki

An example is communication. Coming from a very distributed team, a few of us wanted a more formal process. More documentation, more written communication. This is important down the line as we grow, but not so much in the beginning when priorities change almost daily.

Hitting refresh is an important part of starting anything new. Making it explicit that you need to take a step back and reconsider your expectations. You’re going to have new problems and you can’t deal with them if your focusing on solving the problems you had in the past. At the same time, it’s importatnt to leverage universal learnings and principles. It’s also important to recognise the context in which those are valid.

Are they really valid to you now?

Photo by rawpixel on Unsplash

This post appeared originally on the Dolittle blog

Developer growth

Tribes – a search for belonging

Finding your tribe isn’t easy. It’s a long journey of many missteps. You may be part of a tribe your entire life. You may wander to look for other tribes out there and dive back into your old tribe for safety. Other times you need to find another to call your own. Sometimes you need to start your own with your closest around you. Other times you need to just start, and hope others will follow.


But, what do I mean with a tribe? In this context I’m using it as a community where you feel a sense of belonging. Originally, tribes were defined by proximity, the land you belonged to. So changing tribes was a physical action. Moving from one area to another. Going through rituals and sacrifices to leave your original tribe and be accepted in your new one. It took a lot of friction.

In society today the sense of belonging to a certain part of land isn’t what defines our tribe any longer. We define it in other ways like: race, nationality, gender, faith, community, workplace, hobbies etc. Some are hierarchical, like your team, that resides within your department in your organization and others are virtual, like social media groups, forums, interests, programming languages.

In our digital age there is a lot less friction to switch between tribes. You can find a virtual tribe, where switching could be as simple as joining another group. You can physically move across the world and still stay in the same virtual tribe, even though you may change your physical one.

A sense of belonging

As we grow and mature, we all go through our own versions of “the hero’s journey”. Moving through life, searching for a place of belonging.

My family tribe has always been important to me, it’s the most rock-solid tribe I belong to. Our shared values define the core of my belief and value system, and in extension is the lens I see the world through.

Another tribe that gives me a sense of fulfilment is meaningful work alongside caring individuals. Working to make a change in this world for the better. It’s what’s guided me unconsciously so far, and now what I’m starting to become more aware of and act upon.

The search

It’s become easier than ever to find and change tribes. It’s also easier than ever to get distracted in your search. The best we can do is follow our heart, and not settle. As we grow, so do our needs and finding a tribe that allows you to grow to your full potential is something I think is worth searching for.

As I’ve become more aware of my journey and what is important to me, I’ve also been more aware of what I want from my tribe. I’m sure this will evolve and change as I grow, and I’m sure that no tribe will be a perfect match. I do know that when I see something that is closer to my own values I need to make the move. How else will I know if it’s what I need?

“If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on.” ― Steve Jobs

So, if you’ve found your tribe – cherish it, nourish it and consider yourself lucky. If not, work through the friction and don’t settle.

Communication, Teams

Please, break the build!

The feeling when you hit the button and push the code to server. You’re done! You’ve implemented a new feature that’s going to be ready for the end-user. Soon. You see that the code has reached the build machine, and a new build gets scheduled. You get up to take a quick break and end up chatting with a few colleagues on the way. When you get back you see there are 10 messages in your inbox and the same number of notifications on your team chat.

Looking around, you see that the scheduled build has failed. And now there are 5 other schedules builds that ended up failing. It looks like you’ve just broken the build. The rest of the team of 20 developers are now blocked from committing in their code.

You sit down feeling… Continue Reading

Developer growth, Practice Empathy

Rituals of Shaming in the Software Industry

The career of being a software developer can be a bumpy one. From the very start you are challenged by technical challenges you have no idea how to solve. Some grasp the concepts and principles easily, while others struggle. It’s an uphill climb of continuous learning. Constant failure, and success just a semi-colon away.

One of the biggest challenges during this process isn’t technical, but rather social. Around each turn you uncover new wonders, and new challenges. When you start a new job or position, publish a blog post, submit a pull request or even make a product. There will be people lined up to tell you how wrong you are and as a result; how you’re not good enough. I’m here to tell you, that you are!

Continue Reading

Communication, Practice Empathy

Adding more Empathy to Pull Requests

Using tools like GitHub or BitBucket allow developers to able to submit their changes through pull requests. One of the challenges with pull requests is that they often contain very little information, apart from the change itself and perhaps the issue or case in question. Bad pull requests make the lives of reviewers a lot harder, and mean they need to spend a lot of time understanding the context. Instead of focusing on the change itself.

So, how can you improve your pull requests? Continue Reading

Community, Valuable Resources

Reflecting on 2016

We’re coming upon the end of another year. An eventful year that may have left you with a mix of feelings. Some people wish for 2016 to just get over with and hope for a more positive 2017. I won’t dwell on those aspects. Let’s let the years events be and do what we must to improve and make it better.

On a personal note, I’ve come a long way in the past year and as a result, so has this blog. It’s hard to imagine I was just coming out of a period of burnout, struggle and depression. My recovery manifested itself into the journey that is this blog and everything that’s spawned out of it. I’ve made some wonderful connections along the way, and what better way to celebrate the end of the year than to celebrate these connections? Continue Reading