Our working methodology is inefficient. What should we do?
One gets to learn a lot about cultural differences and various mindsets of employees while working with teams located all over the world. Considering that all of us are human beings with different opinions, culture, experience and desires, isn’t it natural that one working methodology won’t be a perfect fit for everyone? And once you find yourself in a situation where you spend most of the time trying to follow the rules while the rest of the organisation simply fails to comply, how should you change things for the better? Let’s take a look at a real example and learn from it.
Meet Daario Naharis, the technical QA manager in our startup:
Daario feels that the team isn’t very efficient, and he is absolutely right:
- Planning meetings don’t go as planned
- User stories are not baked
- Designs are not ready
- Dev teams don’t finish anything on time
- QA team mostly waits for features that suddenly arrive in a bulk
- When testing them, Daario’s team discovers that acceptance criteria is missing many details, so nothing gets deployed on time
This makes Daario feel very sad.
Daario has several options now:
- Refresh his CV
- Write an angry tweet
- Understanding the reason and changing from within
Let’s explore the last option —
Understanding the reason
To make any methodology work, people need to follow some rules. The rules will differ between each methodology, but everything relies on the employees following these rules.
In most scenarios, Agile, Scrum, Kanban and anything else will fail because of people not following the rules.
Meet Missandei — our product owner and one of the cofounders of the company
Missandei usually meets the clients on Monday morning, every two weeks. She has some tea with them, listens to their stories, understands their pain and genuinely wants to make their life easier. Missandei is familiar with all the competitors and their products, and based on data analytics she knows exactly what the next feature should be.
The problem is that Missandei wants the features implemented immediately. She knows that the clients of our company are desperate to pay for their wine using bitcoins. All the competitors are supporting regular currency only, but such functionality will give our company some serious competitive advantage, as well as technological show-off for the investors.
So, we now have:
QA manager — who is on hold at the moment
Product owner — who has an urgent business need that has to be implemented
Let’s meet Bronn, our software engineer
Bronn is sitting at his desk, as usual.
On Tuesday, at 10.00am, Missandei approaches Bronn’s desk and tells him that she needs an urgent feature which allows receiving payments using bitcoin. Project codename “castle”, deadline in 10 days.
Bronn is good at following orders, so he says “But wait, we haven’t had planning yet, how can we develop this thing? I need a ticket please with acceptance criteria”.
Missandei thinks that should the official procedure of grooming, pre-planning, planning and kicking start — the feature will not see the daylight fast enough to have the competitive advantage, so she puts pressure on Bronn to start coding anyway, as he does.
So now we have:
A product owner who pressured the software developer to code something he doesn’t fully understand, while the QA manager is still on hold.
5 days later
Missandei finds out that there was a competitor who actually implemented paying for wine using bitcoin and this project has failed miserably. She also understands that the global trend and value of bitcoin aren’t as positive as they should be, while an alternative in the form of Etherium is actually growing quite well and predictible.
So, what does Missandei do? She asks Bronn to produce 2 versions of the platform, one supporting Etherium and another supporting Bitcoin, and both will be part of an AB test.
So we are 5 days into the project, and we already have:
An anxious product owner, suffocating software developer, pending QA manager.
Bronn has been working on this feature for 3 weeks. Since there is no organised story structure, Bronn is receiving different versions of graphics and texts via e-mail and Slack.
3 weeks later, Bronn finishes his work and deploys the 2 versions to QA:
The QA manager understands that he has 2 undocumented, unplanned and unbaked products to test, without any written rules or proper designs and texts. Even though Daario raised the flag several times during the 3 weeks, the business pressured to continue the development the way it is in order to gain competitive advantage.
The QA team starts testing the products, and what do they find out?
Both of the versions do not integrate well with the rest of the platform, so the feature is completely useless.
Not only that, there is no backoffice integration of the new payments system, so the CS department and business analysts will have no idea about transactions taking place in the app.
That is when the feature is declined and gets back to Missandei, who now understands that certain actions should have taken place before directly approaching the developer.
We are 1 month into the project. A valuable and expensive time that has been lost, since the feature is going back to the beginning of the Agile pipeline.
It took 3 more weeks to plan the feature, design it, write proper acceptance criteria for it, develop and test it. Only at that stage everyone worked together in an efficient manner following the principles set by the methodology, but it was too late; other competitors spotted the opportunity and filled the gap in their own products before our app made it to the app stores.
The issue
The issue was that the team hasn’t followed the principles. The company in our example decided to follow AGILE methodology, but not all employees had the discipline to do so. And sometimes, especially in a startup environment, it would be inefficient to always strictly follow the rules without looking around.
It’s not that Missandei was not aware of the Agile protocol; she thought that it could be skipped in favour of quick delivery and competitive advantage.
Missandei didn’t predict that this move would actually waste 4 weeks of the team’s work.
The solution
Understanding the reasons and purpose. Emphasising them way more than the protocol itself. This mindset+ creativity = dynamic and efficient work of the company.
Strictly following the rules while ignoring the reality would kill almost any product, the same way as ignoring the reason these rules exist in the first place (As in our example with the product owner).
One approach to this issue is called Scrumban — a combination of Scrum and Kanban. One sentence describing the methodology:
Let’s take the flow and rules of Kanban and combine them with the rituals and roles of SCRUM.
This is how a typical Scrumban board looks like:
You can notice the direction of the board and the limits in each column. The prioritisation is taken from the Kanban methodology, but the rituals (daily standup, grooming, planning, etc) are taken from Scrum.
Here is a comparison of Kanban to Scrumban which, in my opinion, explains the methodology in the best possible way:
I am not an advocate of Scrum, Kabnan or Scrumban. I am an advocate of being open-minded. There are many aspects to consider when choosing a methodology for a company:
- Company size
- Company stage
- Goals
- Efficiency of the team
- Discipline of the employees
- Culture
- Internation sites
- Communication between teams and sites
- Transparency
and more.
And even after we chose a methodology, we must always keep analysing its efficiency. It’s not a decision made once and kept forever.
Scrum retrospective meetings will assist you in improving the work of the teams, but you also need a retrospective for the whole methodology. How well do teams communicate and collaborate? Do they follow the rules? Are they enjoying it? Do they understand why it is needed?
Never stop monitoring the methodology. Measure its efficiency by feedback and delivery.
Thank you, dear reader! 🙌
To find out more about Agile, Scrum, Kanban, Scrumban, etc — please visit AgileAlliance.org
To find out more about the author, please visit https://whoismrperlman.com️
