Individuals and interactions over processes and tools

Says the Manifesto for Agile Software Development. How much time have your team spent on discussing Agile processes and tools like story points and time-based estimation, the nature of true user stories, standing or sitting during a standup meeting, using Jira or a whiteboard, roles and responsibilities? And how much time have your team spent on understanding your stakeholders’ needs?

Agile principles and the practice are often lightyears form each other, and often, even if principles and processes are followed properly, the results are suboptimal. Since companies, people, projects, products and customers differ in many ways, then maybe values, tools, techniques, and processes should also differ in order to deliver the highest value for the lowest price.

I was working for a small company which did fixed price projects for financial institutes and telecom companies. Flexibility and adaptation were essential for success, and, as a matter of fact, survival in the highly competitive environment.

Agile is not for us

It was not long before that we started the reporting project that we held an internal workshop on Agile. We knew only a little about it and we wanted to see if there is anything we can use in our projects. The workshop covered the Agile Manifesto, Scrum, and XP. That time the company counted no more than 30 employees and all of us were there. After a heated debate we concluded that Agile/Scrum is not for us: it is way too heavy weight and inefficient compared to how we were working that time.

Cross-functional band of brothers

The daily standups seemed waste of time: we could not afford to have a daily meeting and wait for a whole day to identify and mitigate impediments. We were sitting in the same space and we heard each others thoughts, literally. If someone faced an issue, he started grumbling about it. The issue could be anything the potentially endangered the deadline: sloppy use case or requirement, bad architecture design, code, test, GUI, documentation. Help came almost instantly from a team member, and the issue was solved or escalated to the customer. We had direct channels to our customers and when we needed feedback, we contacted them right away.

Fast problem solving was supported by the true cross-functional nature of the team. Everyone had at least one backup, and everyone were willing to do whatever was necessary to get the product delivered on time.

Fixed length sprints?

Similarly, we felt that the concept of fixed length sprints conflicts with our customers’ needs and the very nature of software development.

We have delivered drops to our customers that they could install and play with. Each drop contained a new feature or improvement of an existing one. We aimed to deliver something which made it worth to spend a few hours in our customer’s office doing a demo instead of writing the code, and which was interesting enough for our always busy customer to spend a few hours to see what we were working on recently. It was hard to arrange demos and it was hard to squeeze the features into uniform sprints; flexibility was the key. The distance between drops varied between a month or just 5–7 working days depending on the complexity of the feature.

Estimation based on data

Since we were doing fixed price projects we could not afford inaccurate estimates or late actions mitigating potential slippages in schedule. We had an internal tool which collected data per team member regarding time spent on different activities from requirements analysis through coding, testing, documentation, … Every activity of the project was covered. In a new project we took the statistics of the previous projects and used them as an input for effort estimation.

Although sprint burndown charts seemed to be fancy tools, we regarded them mainly useless as were more interested in the end of the project, i.e. if we can keep the deadline (we preferred avoiding penalty). Therefore, at every drop we re-visited our task breakdown: we have added/deleted tasks, and updated the effort estimates. The updated effort estimates were based on the original numbers and the actual costs registered with our internal tool which allowed us to easily calculate the estimation inaccuracy.

We were agile, after all

Looking back, when we concluded that Agile is not for us, we made the same mistake like those who try to introduce Agile now: we focused primarily on the processes as opposed to the principles and values. Agility is not about whiteboards, user story breakdown, fixed teams and fixed length processes, etc.

Agility is about delivering value for the customers in a cost-effective way. It is a never-ending process, which requires the following:

Understand the customers’ problems in full context. Be aware of the stakeholders’ needs and constraints. The stakeholders included users, customers, our own developers and testers, the whole company. Communicate with the stakeholders continuously. Communication included the review of use cases with the users, developers, testers, open discussion about the architecture, asking help during coding from each other. Foster the culture of flexibility and openness. Foster the culture of taking responsibility and ownership. Data to measure success. Data to estimate costs.

Liked this post?

If you enjoyed this post, please help out your friends with a *clap* or a share.