The startup world is synonymous with buzzwords such as agile, lean, standup, scrum and other phrases which essentially describe management best practices. In this article I’d like to shed some light into what these actually are. We'll also 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 we're sure that there’s plenty to learn from other industries too. There will inevitably be different 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.
Extreme Programming
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 coordinates 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 may go for a walk, where we discuss 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 Zoom.us 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.
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…..
When Agile Fails
1. Politics in large organisations
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. Healthcare.gov 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 was 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 projects is primarily measured by working software, startups usually have a small user base when project are 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.
2. When there are many default best practices
Scrum Recap
The product owner/manager creates a prioritized wish list called a product backlog.
The team pulls small chunks called user stories which are most important , a sprint back long, and works on developing them features.
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).
Along, the way, the scrum master keeps the team focused on its goal.
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 a product owner.
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 developer 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 found 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 defects surfacing at the later stages of the release. 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 difficult to notice. However, this was a difficult pill to swallow for the team. This where the organization can-of-worms showed up:
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 apart of the regression suite. However, the organisation was use to using external devices and were uncomfortable with the idea of code-based traceability.
Ideology The spirit of ‘working software’ is more important than wide-ranging documentation. However, the organisation 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’.
Organisational Structure and Metrics The testers were a part of the QA organization whilst the developers were part of Engineering organization – a traditional IT matrix. The QA department 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 benefiting from Agile.
