Agile is essentially a human centric way to approach development. The alternative waterfall methodology is a predictable way to manage a project that centers around the business and supply chain processes. Waterfall makes it easy to manage, fix scope, budget, and time. It does not consider the very human nature of burnout, turnover, human error, new ideas, and feedback loops into consideration. Waterfall treats the “maker,” or in software, the “developer,” as fixed and predictable resources who can be replaced with an exact replica. Waterfall is quite useful in building skyscrapers since plans are rarely changed once committed. It is also a useful method for the misunderstood genius coder who has a brilliant idea, burning the late night oil on her own to launch her product from her parent’s garage. In that context, it works; a fixed set of requirements by a fixed resource. We certainly can’t argue with the efficacy in this scenario. I say this often, but one should not be dogmatic about methods of management. There is theory and there is practice. Coming closer to the theory incrementally is more important than struggling with the imperfection of the practice.
However, agile, and in particular agile scrum and agile kanban is best for uncertain requirements and adapting to feedback in a team-based environment. In software, agile serves as a way to respond to new information, requirements, and unpredictable development challenges. Agile’s many ceremonies are also a reflection of the need for developers to gather to discuss obstacles and collaborate. An important factor to note is that being agile and deploying more code alone should not be the standard of success for your organization. This is because the success of software should not be the quantity of features but the quality of useful features that improve a user’s life or job.
In other words, agile can probably ensure you deploy, but not whether you deploy the right features that users want. A major shift your organization must make is the conversion of software development to become user centric is by adopting the principles of user-centered design (UCD.) Most central to this shift is changing the measure of success. User centric measure of success for software is whether useful software features are deployed and adopted by the user, not by the number of features it contains. However, agile can ensure you can launch your product into the hands of the user faster, which will allow the ability to receive feedback quicker, allowing your organization to be lean. You can apply design thinking at every phase of the software development life cycle, as well as in agile environments.
What changes with user centered design in software development?
|You advocate for the needs of the user, not your ideas.|
You remove your biases, experiences, and preferences in order to solve the problem, not defend your understanding of the problem.
Your team speaks the same language and are on the same page.
You prioritize work based on the true needs of the user, not you or your team’s urgency or preferences.Your meetings are mostly collaborative, not informative.
You find creative ways to problem solve, not justify the solution.
You can look at the application and describe each feature in a user story form. You stop making “vaporware.”You don’t get nervous if the customer will like or use something, because you made it together.
Remember: Though UCD seeks success for the user, HCD encompasses all humans, meaning each other. Seek to make software human centrically to involve all members of the team and all stakeholders, in order to design the best user experience, together.
User Centered Design is the application of Human Centered Design within the SDLC process.