Agile project management
Change management in the agile world - Willing, able and ready
Recently I had been feeling frustrated at home because I had clutter. Things were piling up on my desk, and I was running out of storage to put things away. I had mismatching shelves, but the thought of an entire overhaul felt like a daunting task. Then, I had an epiphany. I realised that I could apply the Agile ways of working that I was so accustomed to, in my everyday life. And here’s how I did it.
The first step was to tackle the immediate problem: the pile of clutter on my desk. As an experiment, I purchased the smallest shelf unit to tidy up. I wanted to see how it looked and how well I could fit things in one unit. Once I deemed it a success, I then thought about reorganising everything else.
To determine the viability of a product, we design with the “thinnest slice” possible. The minimal set of functionality that would allow the user to accomplish a single task (i.e. one user flow). With this way of designing, we can quickly create a prototype and test it on some users to determine whether our concept works. If users find issues with it, we can make changes without incurring too much cost (in terms of time, effort, and ultimately money). Once we get to a point where the product is viable, we can then think about how to scale up to create the full product.
These same thoughts can be parallelly translated into product building, especially when scaling up. More often than not, product owners start thinking about all the brilliant (and endless) new functionalities they can introduce to users. But is everything necessary? Thought needs to be put into how much this is going to cost versus how much additional value it will bring the user. How much more design effort will this take? Is there enough time to achieve all that is desired? What about future-phase releases of the product?
Sit down with your product owner, stakeholders, and users. Find out what are each of their needs in order to strike a balance of what to design and build that will generate the most value for everyone. Figure out how much time it will take realistically; you don’t want to surprise them with delays. A well thought out plan is crucial for a successful scale-up of a product. And more importantly, stick to the plan. Scope creep (increased work that was not accounted for) can be a death knell.
This holds true for design. In this day and age of digital products that are meant to scale up over a long time period, a design system with modular components is your best friend. (As well as making friends with your fellow developers.) We work with grids and foundational components and control the permutations of these components. Think of grids like the vertical and horizontal shelving, and foundational components like the drawer units (in the same dimensions Muji has at least five types of drawer units).
Even with such simple rules to lay the groundwork for your design system, no two designers will come up with the same design. Your grid system can be different. The types of components you define can be different. But what matters most is the consistency you can achieve with a well-implemented design system. And when you have to manage upwards of 30-50 different screens across multiple user flows, reusability of grids and components is a godsend.
Designing in Agile is a cycle. We create a part of the whole design. We test the viability of what we newly designed. We learn from the tests and adjust the design as we progress. This cycle is critical to the success of the product. We always want to be making small corrections along the way by building up our knowledge of how users interact with the product. Huge costs are incurred when we make assumptions and put off testing because we cannot be sure if we are on the right track. And when we do have to make changes, the change is on a much larger scale because the product is much bigger.
Minimum Viable Product
The first step was to tackle the immediate problem: the pile of clutter on my desk. As an experiment, I purchased the smallest shelf unit to tidy up. I wanted to see how it looked and how well I could fit things in one unit. Once I deemed it a success, I then thought about reorganising everything else.To determine the viability of a product, we design with the “thinnest slice” possible. The minimal set of functionality that would allow the user to accomplish a single task (i.e. one user flow). With this way of designing, we can quickly create a prototype and test it on some users to determine whether our concept works. If users find issues with it, we can make changes without incurring too much cost (in terms of time, effort, and ultimately money). Once we get to a point where the product is viable, we can then think about how to scale up to create the full product.
Planning and Requirements Gathering
Before I went ahead and purchased more shelving, I sat down and thought about it. How much more did I need? It was obviously going to cost me much more than the first unit I bought. How much space I had left also factored into how much shelving I could have. How much stuff did I have to put away? Did I want to think about leaving more room for expansion?These same thoughts can be parallelly translated into product building, especially when scaling up. More often than not, product owners start thinking about all the brilliant (and endless) new functionalities they can introduce to users. But is everything necessary? Thought needs to be put into how much this is going to cost versus how much additional value it will bring the user. How much more design effort will this take? Is there enough time to achieve all that is desired? What about future-phase releases of the product?
Sit down with your product owner, stakeholders, and users. Find out what are each of their needs in order to strike a balance of what to design and build that will generate the most value for everyone. Figure out how much time it will take realistically; you don’t want to surprise them with delays. A well thought out plan is crucial for a successful scale-up of a product. And more importantly, stick to the plan. Scope creep (increased work that was not accounted for) can be a death knell.
Modularity and Design Systems
Many furniture brands offer modular shelving systems these days. I happened to like Muji’s system (and also because they use humidity-resistant wood). I had the flexibility of short or long shelves, short or tall units, and as many or no drawer units as I desired. I could “scale up” the way I wanted to.This holds true for design. In this day and age of digital products that are meant to scale up over a long time period, a design system with modular components is your best friend. (As well as making friends with your fellow developers.) We work with grids and foundational components and control the permutations of these components. Think of grids like the vertical and horizontal shelving, and foundational components like the drawer units (in the same dimensions Muji has at least five types of drawer units).
Even with such simple rules to lay the groundwork for your design system, no two designers will come up with the same design. Your grid system can be different. The types of components you define can be different. But what matters most is the consistency you can achieve with a well-implemented design system. And when you have to manage upwards of 30-50 different screens across multiple user flows, reusability of grids and components is a godsend.
Iterations and Testing
The final outcome of my shelves took two installations. This, of course, pales in comparison to a large-scale project, but the underlying principle is the same: a project is not finished in one shot but rather in stages.Designing in Agile is a cycle. We create a part of the whole design. We test the viability of what we newly designed. We learn from the tests and adjust the design as we progress. This cycle is critical to the success of the product. We always want to be making small corrections along the way by building up our knowledge of how users interact with the product. Huge costs are incurred when we make assumptions and put off testing because we cannot be sure if we are on the right track. And when we do have to make changes, the change is on a much larger scale because the product is much bigger.
Satisfaction with the end result
I was very satisfied with the end result because I paced myself with research, experimentation, and feedback gathering, and could make the most optimal choices when scaling up. At the end of the day, a product is designed for users and in order to satisfy them, we need to address their wants and needs. And Agile Design is a good way to get us there with optimal effort.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
