Working Agile
Some of the criticism that agile frameworks receive is that it is just a nice theory. I set out on a planned six week sprint to try my hand at development work. The point of the exercise was to put myself in the shoes of a developer and see what happened. Now, I don’t code, but I found a way to put together a mobile app using a low code solution. With this solution, I was able to try working agile principles in my development efforts.
For 6 weeks I worked on a mobile phone app. I released Tradekick in beta to the public in 7 weeks. I’m still working on this app (which you can find here), but here are some things that I noticed being on the developer side of a development effort as it relates to agile development.
Performance and Priorities
One of the things that makes the process a bit easier is having someone work from a priority-based backlog. It is really easy to start working on a feature, run into a roadblock, and just pivot to something else. If you do this long enough, you will end up with a half-baked application with no working features. The application will never get out of development.
Without a set priorities and focus, your performance in developing something will suffer. One of the traps you can fall into is thinking of performance as a function of your effort. Really, in development, your performance is actually a function of your releases. If you think about performance in terms of what your customers see, things change. I wasn’t productive, from a customer perspective, until I had a first ship-able release despite pouring in a lot of hours of development prior to that point.
You need to either have the discipline to keep your focus on one feature/piece of functionality at a time, or have someone to help you do that. But regardless of how it is done, prioritization is a task that needs to happen regardless of the team composition. It’s a lot easier, however, having someone independent of development doing the prioritization (which is why the scrum framework advocates for a Product Owner).
Vertically Slicing For Success
Closely related to the issue of prioritization and performance, is that of vertically slicing your work. Vertically slicing means that you have all necessary components in your stack together and working to deliver a piece of functionality to a customer. In traditional development efforts, the work was sliced horizontally. Meaning, we would develop all the tables and relationships within the application before touching the UI, business layer, security or other aspects of the application. The difference between the two is the speed at which the customer can see your work. Vertically slicing means that users can see a piece of functionality pretty quick. Horizontally means that a user can see a complete working application at some point.
A real-world example
In the application I developed, I have a concept of users, market lists, and watchlists. A user can login, view the latest market data for the top 50 cryptocurrencies, view details for a single coin, save a coin to a watchlist, and adjust sorting parameters for the market data. Slicing this horizontally, I would want to create all the relevant tables and relationships within the database layers for my users, user profiles, market data, and watchlist. Once I have those setup, I can then begin on working on the server actions/logic for each of these tables. The logic I created would provide the necessary components I would need to complete my UI. Once I have those components done, I’m ready to release my final application.
Note, this could also be done in reverse UI → Client → Server → Database. The order of development really doesn’t matter; just the fact that you deal with each layer in the development stack separately. What happens, though, when you work your app horizontally is that you end up not having a working app until the end of development. You can’t have a running app without the UI in place, nor could you have a slick UI without server/client interaction and logic, and tables to supply the application.
Enhancing delivery through vertical slicing
The only way to get an application in the hands of your customers/stakeholders is to vertically slice the work. So, in the case of my application, my first release was going to allow a user to login and see list data from my coin ranking API. So, I had to build a couple of tables, I had to build the logic of what is supposed to happen when a user logs in, and also build out the REST API call with coin ranking to compile my list. I was able to publish my first release in four days. Had I done my work the other way, a customer would have been able to use the application in 7 weeks. Even though they couldn’t do anything with the coin market list, it was still a functioning and capable application.
My next slice builds on top of the functionality originally delivered. So, having a list is great, now I want to save a coin to a watchlist. That was my next functional slice of work. So, I had to create an additional table in the database to hold that, define how it relates to the user table I already created, define the server/client actions that would populate the table, and then reflect that logic in the UI for my user. I had that piece done in two days.
Why vertical slicing works
In creating Tradekick I didn’t know what I was doing. I didn’t have the advantage of building something that was completely known from the bottom up via a well documented set of requirements. I didn’t really know how the entities in the database where going to relate together or even what entities I was going to need. That’s why vertical slicing is a good idea. When you need to discover the answers as you go, vertical slicing manages the risk of that discovery better.
When I completed my first release, internal users could test my application to provide feedback. While they were actually using Tradekick, I could continue to work on the next feature and collect valuable feedback about the application during the process. I could step incrementally forward to the next vertical slice without risk of architecting something unusable. Or, I could make enhancements to original features while the code base and process was fresh and pretty changeable. Most importantly, I had something I can physically show customers and stakeholders. That brings an initial excitement and motivation boost to all involved. You don’t get those benefits in work that is completed horizontally.
Shipped Not Perfect
At the end of my 7 weeks worth of development, I had put together 825 releases. Each release built on the capabilities of the application, or corrected some inefficiencies or bugs that the user was experiencing. Overall, I did around 3 rewrites or overhauled the application in a significant way. In an agile vs. traditional development methodology, my application was essentially better than the one final release I would have made under a waterfall methodologies. My application still is not perfect, but it is usable and shipped to customers.
Often times we get caught in the trap that everything must be done and finished to ship. If you are waiting for things to be perfect, you will never ship your solution. It will be stuck in development. The focus needs to be on usable rather than perfect. If you can manage the expectations of your customers to that standard, you will be well on your way to building a robust, value-adding solution to the world.
The Value of Feedback
During the 7 weeks of development I collected feedback and ideas from my colleagues to enhance and improve my application. Any one of them could have used the application on their device. At the end of the 7 weeks, I had my application in the app store ready to be accessed by anyone interested as a beta version in the Google App Store. A friend downloaded the app onto his device and quickly began running through it. In the two minutes that he had scoured the app, I had another weeks worth of work to improve the application. The two minutes of feedback were enourmous in terms of enhancing my application for general public use.
In any of the agile frameworks, the need for feedback is vital. You will not be able to realize value if you don’t have feedback because you will be ignorant of where the value lies. You have to get the application out to your users/customers as soon as possible; it doesn’t have to be perfect, just usable. You only get to “usable” by vertical slicing your work; vertical slicing is best under iterative development. You can only be successfully iterative if you have a priority or focus in your backlog. Do those things, and you will find yourself and your team becoming a high performing team that agile frameworks champion.
Thanks for reading,
David Bjarnson
Agile ⇑
One Comment