How to build and deliver working software
To build working software we need to understand Agile software development.
The very first principle in the Agile Manifesto states that our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The terms priority and values are crucial to consider when considering this theory.
So, what does prioritizing high-value software imply? Surprisingly, one of the answers to this issue can be traced back to an Italian economist called Vilfredo Pareto in the nineteenth century. When he was harvesting peas in his greenhouse, he found that 20% of his pea pods produced 80% of his peas.
He was an economist so he compared this ratio to the wealth distribution in Rome. He discovered that 20% of the population owned 80% of the land in the city. As a result, this 80/20 ratio is now known as the Pareto principle or the 80/20 law. 80% of the effects come from 20% of the causes.
Quick forward to the 1990s, a consulting firm called the Standish Group released a report stating that the majority of software projects failed. This is because they spent much too much time building software features that no one would use.
Think of it this way: If you use a program like Microsoft Word, you may only be using a small portion of its features. You may have used spellcheck, print, or copy and paste, but you might never use mailmerge or any of the hundreds of language packs. That’s true with most software products.
In reality, according to the study, 45% of the features in a software product are never used by most customers. The 19% is seldom used, while the 16 percent is used on occasion. Finally, 13% are often used, and 7% are always used. The Pareto rule can be seen if you look closely. Just 20% of the product’s features are used often or often.
So if you’re working in an agile team, this 20% is the most valuable part of the software, so you would want to start here first. This would be part of the highest priority feature delivered in the very first sprint.
This might not seem to be a big deal, but it differs from how most software development teams work. Consider your options if you’re designing a simple website with a contact form. Typically, a project manager would split this into two milestones. The first milestone will be to build a website with all of the form fields, and the second could be to enter certain form fields into a database.
Now, imagine you were working on the website with an agile team. The first thing you would do is ask the customer which one of the form fields is most valuable. They would probably say it’s the customer’s first name and email address.
So instead of a milestone that finishes all of the form fields, you would create a simple website that only captures the customer’s first name and email address. The development team will work on the most valuable and highest priority features and then move their way down to lower priority features until the whole product is complete.
Use a Taskboard to Prioritize
Now you know how important it is for agile teams to prioritize high-value activities. They must first concentrate on the functionality that the consumer would use regularly. They can then move on to less important or lower-priority work once those features are complete.
The design of a task board is one way that these agile teams assist in the visualization of their work. As seen below, a task board is a basic swim lane diagram. It’s called a swim lane diagram because it resembles the vertical columns of a swimming pool.
Now each of these columns or swim lanes holds a small batch of work. Typically, these are called tasks. Whichever column the task is in shows the status of that task. The simplest task board would only have three columns. To-Do, In Progress or Doing, and Done. If your team has a background in lean thinking, then they might call these columns work queues.
Now a typical agile team will write broad statements of customer value in the form of a user story. The team would then create a User Stories column on the task board. These user stories will be prioritized from top to bottom, much like tasks.
Then, in the To-Do column, the job of completing such user stories will be gathered next to it. It’s important to remember that many agile teams misuse the task board. They’ll simply begin working on whatever assignment they’re most comfortable with and transfer it around the board. That’s why it’s usually best for the team to start with a real board with cards and stickies.
Now remember that the task board is not just a way to show what you’re working on, instead, it’s a key part of verifying that the team is working on the highest value features.
Avoid PowerPoint Software
This concept of delivering high-value working software is one aspect that many agile teams get tripped upon. Note that working software is the primary indicator of success, according to principle seven of the manifesto. But how can working software be distributed every few weeks? To do that, you need to deliver small, fully functional features of the product to the customer in iterations or sprints.
Let’s consider creating a basic website. We simply need a web form that collects and stores the customer’s contact details in a database. That’s a whole project, and there are some potential milestones if you think about it. You must first build the database for the first milestone.
The software that links the form to the database will then need to be developed. Then you might need to develop the software that connects the form to the database. Finally, you have to create a form that captures the information. You might also need extra code to make sure that you have the correct data in the forms.
So, if you consider the website to be a project, you would expect it to have a lot of milestones. However, an agile team does not consider software to be a project; rather, it considers it a product of prioritized value delivered to the consumer in short sprints. As a result, you’re not attempting to solve all at once. So you’re not trying to tackle everything at once.
Remember, we’re not multitasking. Instead, you’re zeroing in on high-value features to deliver. So you might have a simple webpage that just captures the customer’s first name and email address. The key thing to keep in mind is that this form would be fully working software.
That means that if you enter your first name and email address, this simple website will verify that they are correct, save your name and address to a database, and back up the data regularly. While few consumers will consider this as a fully functional product, it is possible. As a result, when operating on an agile team, you can only show customers working software.
Some teams make the mistake of presenting PowerPoint presentations or wireframes to customers. However, these are all stories; they aren’t actual software that customers can use. The customer should be able to bring the software into production and end development at the end of each sprint. They shouldn’t have to wait for deployment, testing, or other ways to finalize the product. The teams should always be building and pushing working software.
Now there are a lot of reasons why agile teams do this. But one of the most important is that these teams find that working software is the best way to communicate progress. Does it keep the customer from asking questions like when can we ship this? Every time they see the software, it’s potentially shippable.
Another reason is that it reinforces the agile team’s commitment to work on the highest value features. It means that the most used features will be the first ones that are finished.
Yay! You’ve reached the end of this article.
We have gone through vital points and lessons for software developers who want to build working software and eliminate PowerPoint software.
It’s time to take action and begin applying lessons learned in your next software project.
