Over the past few years, the rise of software development and the importance of it in organizations, have given way to Agile methodologies. It encourages frequent feedback and adaptation to current situations where downtime is minimized through team collaboration, including business owners and software engineers. This blog will show you how to maximize your development potential.
Planning and estimation is done by engineers and they are responsible for deliveries within that time frame. Agile teams are composed of software engineers that are committed with each other and most importantly, at an individual level, with themselves. They care about their product quality and what their product says about them not as developers but as a professional peer.
Product quality and prompt deliveries are at the core of their beliefs. These values are what drive and mark a team, and finally, what makes the customer satisfied.
Deliveries are divided by sprints and sprints by user stories. A user story is presented to the customer as he would normally know it, without any technical details.
So for example, a web application where users would need to get registered, could be presented as: “Build user registration module”, and that could be decomposed into more specific stories:
…or many others. Maybe the customer does not care right now that users can sign up with Facebook, but she does care about users signing up with their email address.
The important point here is that a customer will precisely know what’s being worked on and he will have given his input on what to work at that moment since financial resources are limited most of the time, and the goal is to maximize delivery. These user stories are estimated and ultimately, the customer will give a green light on the suggested user stories to work on.
Grounding those user stories to a non-developer language is just the beginning of getting to know the customer’s domain language. Most probably a customer will not know about databases, APIs, etc.
So instead of presenting him with a user story that says “Build an API that allows requests to register users”, he is presented to a more down-to-earth story for him to know exactly what his money is doing.
It’s important that both, programmer and customer, be able to have a conversation using a common language, referring to what would be a programming object, as what it really represents in real and business life.
Some blocking will occur for many reasons, sometimes it will be as simple as a lack of knowledge of the business context, some other times external dependencies change, or many other situations.
What’s important here, is that even though Agile or non-Agile teams have those blockages, an Agile developer will know how to adapt or even communicate that to his team and finally to the customer.
When the team hits a wall, a choice is taken and communicated to the customer, either to continue on the blockage or carry on with another user story while the external factor gets resolved. This will maximize coding time and keep the customer satisfied with deliveries.
By now, a point has been made and shown, quick feedback is the key to Agile development. I’ve witnessed non-software companies start a project with a few engineers, as time goes on, these teams usually grow from a couple of engineers to a small army, taking a big bite of profits.
This happens mostly because a bad misconception is handed down to the customer, “we need more manpower”. This would make sense probably if the business has grown and more requirements are needed, but in many cases a big blob of code starts to take life of its own and more and more engineers are needed to handle the same modules for the same business.
Having a disorganized team is not the answer, efficiency per developer diminishes and this translates to a bad allocation of money per resource. So be sure of this, hiring more developers is not the solution, but having a good Agile team is. If one more developer is needed, an informed and sustained reason is communicated to the customer. He will finally either give it a go or not.
One of the key features of having rapid feedback is testing. So, should a programmer write hundreds of lines of code to see its final product working? No! Agile development says: “test your code ASAP!”.
For this, Test-Driven Development is the answer. I won’t get into much detail since this blog’s objective is to educate the customer on the Agile methodology, but if you are interested you can find an excellent blog on this subject named “On TDD & Writing Good Tests”.
Having a good testing suite allows engineers and business owners to know the product being delivered works. As user stories, tests must be written for the customer to know what is going on in the inner piece of code.
describe "TimeMachine" do before(:each) do @time_machine = TimeMachine.new(:date => Time.now) end it "travels ahead of time" do @time_machine.travel_days(2) expect(@time_machine.current_time).to equal(Time.now.day + 2) end end
Running this test and having a green output, assures the customer this functionality works. The test is a literal description of what
TimeMachine does. I can assume the customer has given the team a project to work on a TimeMachine and what he finally cares about is, it can travel ahead in time.
In this case the test gets read by the customer as “test TimeMachine can travel ahead in time”. Easy to understand it works right? The heavy work will be done by the engineer and he will have to make it pass. Many more tests will get written for this module and the customer, being a non-technical person, can be assured that the module he paid for works.
We live in a world where new technological advances are almost a day to day challenge. These cause new trends, demands, and requirements that present a challenge to existing systems to adapt.
Dynamic.Tech offers scalable, adaptable, and growable solutions that adhere to consumer needs. Being a hiring customer, this MUST be in your radar when hiring a team. Does this team follow best practices to write pluggable and scalable code? Or will I have to hire another team to fix and adapt new modules to the product?
This is one of the key features a good developer must pay attention to when writing code and such coding practices are probably not known by a non-technical customer.
My blog on abstractions tries to explain this in a simple way, as well as some other pointers for non-technical users. Take a look at it and be sure your team follows these principles, known as SOLID. Having this type of code, clean and tidy, is an Agile team characteristic. This team will leave your code prepared for them or for future developers to grow more modules or functionality.
I hope I have made clear the short & long-term advantages of having an Agile team. But most importantly, team leaders and business owners should take some notion and sense of what they must look and ask for when hiring a team.
Code will linger on for future developers and having a good structure will last while the business lives. This sets the base and the tone for future deliveries and hopefully leaders will know when new developers are needed, and the benefits of good programming practices on their businesses.