For help call US Flag +44 75405 52750 or Email Us

Is Agile right for you?

Project & Team Management

The startup world is synonymous with buzzwords like agile, lean, standups, scrum and other gimmicky phrases which essentially describe management best practices. In this article, I’d like to shed some light into what these actually are. I’m also going to give you a peek into how this is actually working at Hamari labs. We’d also like to know how your company is working and I’m sure that there’s plenty to learn from other industries. There must be other approaches to running projects which work differently and maybe even alternative for startups to follow. Who knows you may be holding the keys to the next best-kept secret. The tech industry might have Trello boards and base camp for the last decade, but project managers have been around for much longer. We’d like to know, how you manage projects and even new product launches? We’d also like to know what you’ve tried and hasn’t worked. So please feel free to add as much detail as you like.

(apologies in advance: I know I’m copying Ben Horowitz with the rap lyrics – but hey, you know it works)

Let’s talk about Agile.

Before we delve deep into the inner workings of Agile, it’s worth having a quick look at where it originates from; Dynamic Systems Development Method; in short DSDM. First released in 1994, originally sought to provide some discipline into rapid application development. Which later evolved into DSDM Agile which became a more generic approach to project management rather than focusing on application development and software design. The consortium behind DSDM recognized that projects were failing due to the way people worked rather than which technologies people used.

So there are 8 principles underpinning DSDM:

  1. Let’s focus on what the business needs
  2. Let’s get shit done on time
  3. Collaborate – Work together, fork together
  4. Never compromise on quality
  5. Build it in stages with a strong foundation
  6. Develop iteratively – Rome wasn’t built in a day (DUHH)
  7. Communicate continuously and clearly – just like any other healthy relationship
  8. Demonstrate control – Keep your shit together

Following from DSDM – next came extreme programming


Let’s talk about Xtreme programming


Life is a blast when you know what you’re doin’

Best to know what you’re doin’ ‘fore your life get ruined

Life is a thrill when your skill is developed

If you ain’t got a skill or trade, then shut the h*** up


– Hieroglyphics ft. Del tha Funkee Homosapien, At The Helm


The first of these projects started in 1996 and has proven to be #extremely effective in a number of organisations when implemented in it’s ideal way – which revolves around team empowerment, continuous customer feedback and finally progress is measured in terms of working software.

So what do we mean by teamwork. Rather than developers and managers working in a hierarchical manner where decisions are made in a top-down manner, in extreme programming every team member is an equal partner including the client, product manager and the developer.


The team co-ordinates itself around the problem to solve it in the most efficient manner.


Each morning begins with a standup meeting. At Hamari labs we have our own way of doing this. We sometimes go for a small walk; we discuss what problems we’re currently looking to solve; issues and challenges we are currently facing and how other team members can help out. Please note that a standup can also take place virtually. With the advent of and Google Hangouts all of your remote team members can come online and share. This is then followed by our product manager communicating the updates with the client. This includes showing working software, how they feel about the changes made, whether the feature lives up to what they expected and any changes needed to be made.

Extreme programming improves a project in 5 essential ways: communication, simplicity, feedback, respect and courage. Extreme programmers constantly communicate with clients and their fellow developers. Design tends to focus on simplicity and ease of use, delivery tends to be as early as possible and feedback is gathered by testing the software from the beginning.


There are a set of simple rules which govern this agile framework and can be thought of as pieces of a puzzle. They may not make sense on their own (and some may argue that they are awkward) but when combined together are based on a number of principles and values.


So where can things go wrong with Agile?


Agile, has definitely worked for us but that’s because of the fact that currently we’re a small nimble team knitted together. By our very nature, we can make decisions quickly, communicate effectively, be brave and courageous and most importantly get things done. However, in a bigger organisations where there’s usually a top-down structure; agile can be a tricky adventure to get right. However, there are other issues surrounding Agile…..


Example 1: Big Organisation, Lots of Poltickin’


Sometimes it’s worth looking at failed projects to learn about the traps in a particular framework. Agile promoters would argue that the reason for the failed engagement is due to the fact that Agile was never implemented in its truest form. is a prime example of where being too big – the software development project went seriously wrong. First of all, lack of real leadership meant there was no one steering the ship. This project had around 30 – 40 of the largest consultancies working on the projects. This in itself is alarming; as different organisations try and work together, quite often they have different viewpoints of how things should actually be done – for example architectural decisions and software testing.


Progress in agile project is primarily measured by working software, startups usually have a small user base when their project is small and and as they gather data and feedback, they’re able to create a better product. In gigantic programs where an entire country is involved this is not as practical.




The Obamacare project should have been released state by state. This would have given the back-end developers ample time to fix the issues surrounding the software, paving a way for continuous improvement as the project scaled up. So this was basically a case of too many chefs spoiling the broth and delivering the project all at once.


Example 2: How are there so many defaults – ‘I thought we were following Scrum?’


Before I delve deeper into this scenario, it’s worth recapping what Scrum actually is for those of you who haven’t heard about it before.


  1. The product owner/manager creates a prioritized wish list called a product backlog.
  2. The team pulls small chunks called user stories which are most important , a sprint back long, and works on developing them features.
  3. The team keeps to a certain amount of time per sprint. At Hamari Labs, we keep to a weekly sprint. However, the team meets each day to assess its progress (daily scrum).
  4. Along, the way, the Scrum Master keeps the team focused on its goal.
  5. At the end of the sprint – you should be able to ship the product to the end user or at least be able to showcase it to your product owner.
  6. This sprint ends with a retrospective and sprint review. The way we handle retrospectives can be learnt from Radical Candour – Challenge Directly but care personally.



A team was claiming to follow scrum but in the later stages of the release a number of defects were surfacing. Closer scrutiny revealed a number of issues with the project, one of them being the process behind accepting a user story to be dev-complete. The dev in charge would simply claim a user story to be done and move on to the next user story without any verification from an analyst. When a tester finds it incomplete and/or buggy it would later show up on the defect tracking system.


This team claimed to be following Scrum but were struggling with the issue of lots of defects surfacing at a late stage of the release. Closer scrutiny revealed several problems, one of which was the way a story was accepted to be dev-complete. A developer would simply claim a story as dev-complete and move on to the next story without any verification by an analyst. When a tester took the story up for testing a couple of days later, she would find it incomplete or buggy and start raising defects in the defect tracking system.


The project manager, suggested that once a feature is finished, they must have it approved by an business analyst – (a client facing stakeholder). His suggestion was that only the main feature was required to be approved, not the entire boundary condition and nook and cranny. This would be called dev-box testing – 20 minutes on a computer testing the main features. Any issues that would surface would be recorded on a sticky note, and the developer would start to fix them immediately. This would eliminate testers and developers going back and forth – empowering developers and leaving testers to work on bugs which were hard to notice.


However, this was a difficult pill to swallow for the team. This where the organization can-of-worms showed up:


  1. Traceability

The testers were worried losing track of the bugs. The PM suggested that if TDD

Is done right this shouldn’t be an issue. For every bug found, the developer would write a unit-test and then the write the code to fix it. The test would form a part of the regression suite. However, the organisation was use to using external devices and were uncomfortable with the idea of code-based traceability.


  1. Idealogy

The spirit of ‘working software’ is more important than wide-ranging documentation. However, the organization followed the ‘process-quality’ group and the need for process compliance. ‘Dev box testing’ was being viewed by the auditors as non-compliant from the ‘process quality group’.

  1. Organizational Structure and Metrics

The testers were a part of the QA organization whilst the developers were part of Engineering organization – #ITMatrix. The QA had a performance metric which was measured in terms of number of defects reported within a week. No wonder, the testers were hesitant about ‘dev box testing’. The PM would have to ask for an increase in scope or their engagement to influence the governance team on how they designed their KPI’s.

This is a prime example of where a poor implementation of agile; organizational structure, their KPI’s and documentation ideology can stop organization in actually benefitting from Agile.


When Agile Shouldn’t be used – A Googler’s Perspective


There is also another domain where Agile may not necessarily be the ideal framework for delivering software. David Jeske,  a former director at Google offers his insights why at Google – the Agile framework isn’t ideal solution. Business-led engineering is great for projects which require short-term planning, direct customer contact and continuous iteration which usually has a simple core and lots of customer visible features that are incrementally useful. However, more technically challenging software could have a simple user interface but tonnes of hidden technical complexity, which isn’t useful until it is more or less complete.


Google is known for building world-changing products which haven’t been made previously. These products won’t work until their complex subcomponents are written. Jeske, draws upon two examples which are of distributed databases: Borg and Bigtable. Bigtable is a widely copied design for a distributed database, and Borg was one of the first extremely large scale cluster/cloud managers. Projects like these take significant up-front design time (anyone remember Waterfall), where one working on 2-week sprints just doesn’t work. Most of the complexities would never be visible to the end user – so the idea of Agile user stories and customer journeys just doesn’t work. These projects can be thought of as anti-scrum, they require extremely long term thinking from their respective technical leaders. Essentially they were laying the foundation of how cluster based software was developed. This architecture has changed how the entire industry works.


There are also a number of other industries where shipping products fast just doesn’t work; such as tax-accounting software. If any of you are aware of the complexities surrounding the UK tax code, shipping a product fast may not only be problematic but may also find you on the wrong side of the law!

Post a comment