“So little to do, so much time. Wait, strike that. Reverse it.” I love that quote from Willy Wonka in Willy Wonka and the Chocolate Factory. I know I can attest to being so busy sometimes that I cannot express it correctly. We, after all, only have limited time and resources to do a limited number of things. Organizations must sometimes make tough decisions on where they wish to allocate those limited resources. This is even more pronounced in the technology industries in which most agile managed projects are conducted.
In order for organizations to use their resources wisely, they must determine the most valuable use of those resources. If there is no value gained from how the time and resources are used, then what’s the point? Something that provides no value can be considered waste. Wasted time, effort, and energy does not make good economical or business sense. With too much waste, a company cannot stay in business. When managing an agile project, it is important that we drive development towards value.
First off, we must clarify value.
There has been discussions all over the enterprise about the need for employees to be able to better manage their employee benefits and compensation. The employees that reside in your department have the skill set to produce apps on various devices that could address that. Your company’s CEO has even announced it as a primary objective for the upcoming fiscal year. Should your team work on this product? Is there any value in doing so?
But at the same time, there are concerns from the legal team that certain things the department should be doing have not been done. There is one pressing concern around a security need in many of the software systems your department manages and develops. You are not currently out of compliance, but do you work on the modifications that may or may not keep the systems compliant in the future? Is there any value in addressing this compliance issue?
At the same time, the primary system you have built for the organization as a whole and do support daily is always in need of improvements and new features. Some of the improvements are really on the need to scale the system to accommodate the pending growth of the organization and its operations. Is this the project your team works on next? Any value in doing this?
Then there has also been a request from a client for your team to produce a similar system in their environment. They think they want what you have and maybe a little more. They are not exactly sure. But they do know they need something and are willing to pay kindly for their needs. Is this the ideal next project to invest time and resources in? Does this bring the most value to the organization?
These are tough choices. Why not just work on them all? Deliver a little bit of everything and make everybody happy? We are agile, right? We can jump around. Well no, not really. So what do we do?
One of the advantages of managing projects in an agile project management approach is that we can deliver value earlier rather than later. Our aim should be to give value early and often. The project team can deliver some of the highest valued items first or the pieces that lead to the realization of the most prized items earlier in the development cycle rather than much later on — or, as in some more traditionally managed projects, delivering all of it only at the very end of the project.
Realizing and delivering value earlier helps direct the project where it needs to go. The course is corrected earlier instead of when it is too late or when the costs are much higher. As projects progress, so do the risks and points of failures. Extending the delivery of value to later points in time when it is fuller and more thoroughly developed may sound good in theory, but may be detrimental or provide less benefit.
Following the agile practice of delivering earlier — even if incomplete or errored — gives you that feedback loop that is so powerful. You gain that buyin from customers and users. That ability for those outside the immediate development team to see and experience the creations builds confidence of the development team’s work and abilities. It builds excitement. It demonstrates progress. And most importantly, it gives something for the stakeholders to work with to give feedback, input, and visualization of what is or is not possible.
I am sure I am not the only one who has worked with a client or business team who said I need to do XYZ by doing X first, then doing Y, and getting to Z. When asked why, the answer is most commonly “because that is the how I have always done it.” But when showing them that doing XYZ in the new system does not work as well, or that we have the option of doing WX to get to Z or even the possibility of just doing Z without the need to do X and Y at all, their eyes will open to new possibilities and new thinking.
Something I have experienced — and I am sure many of you out there have experienced it too — is thinking I understand exactly what they want and wanting to achieve from what you are designing and delivering, only to be completely off the mark. Sometimes it is matter of “same page . . . different book.” Spending time in the wrong book often does little good. The longer you are in the wrong book, the less good that can come from it.
On the flipside, if you are in the right book and the right page that produces something good, that good can be put to use straightaway. Value from the development can be experienced before waiting for the entirety to be complete. Early value-driven development of agile is what makes this possible and has numerous benefits.
One way that agile project management methodologies deliver early and frequent value is from incremental delivery. Incremental delivery is developing and presenting small pieces or layers of a product as they are ready to share instead of waiting until the whole product is complete. Full delivery of a product would require full completion of all the product and project requirements, as well as fully internally reviewing and testing. With incremental delivery, value can be delivered in regular, ever increasing sizes, extents, or quantities. There are many benefits to that and is a way to optimize the delivery of value in agile project management.
In traditional project management, there is an expectation that you deliver the entire deliverable at predetermined states of the project and/or completely at the end of the project. Within the knowledge-based fields, agile project management is more commonplace, there is the ability to deliver small doses of value, building up to a full complete deliverable or set of deliverables.
You would not expect to order an item on Amazon and have them ship small pieces at time with the eventual end goal of the product you were expecting or desired. Incremental delivery does not work in all situations, but it’s common in agile projects.
Each increment is not going to be fully complete. Increments are most likely not going to be as pretty or polished as the final product. Nonetheless, it drives the conversation of where the product should be headed, what is working currently, and where changes are to be made. As each small increment is delivered, there is an opportunity for feedback with validation that work is being done. Instead of a development team working in a dark room, only to emerge when all is said and done, the customer can see work progressing. Since agile projects are best centered on projects that have not been completed as such previously, they demand manipulation and molding as the project progresses.
Sometimes customers do not know what they really want until they can see it. They may be unable to accurately articulate what they are seeking — possibly there are no words or examples to pull from that can express their vision or expectations. It’s the same for the development team; sometimes they don’t know what the customer or end users really want until they start building some workable examples for the customer to confirm or deny. There are other times where the development team is envisioning one thing and working towards building it, but the customers are thinking of an entirely different thing. Incremental delivery alleviates some of that lag time between assumption and confirmation. By addressing issues earlier rather than later, rework is limited and less time is wasted by fixing or changing work that has spent a lot of resources on building.
Incremental delivery is developing and presenting small pieces or layers of a product as they are ready to share instead of waiting until the whole product is complete Agile projects should be driven to deliver value, and delivering in an incremental fashion is a powerful way to do so. It is kind of like getting something up front and then working out the finer details later. For example, in the company compensation and benefit app agile project, our ability to launch an app that allows the department to see the benefit plans offered by the company and doctors in the approved network is not the full product we are envisioning, but it is a major part that is regularly requested by our employees. By delivering just that information in a convenient format, we can start getting feedback not only on the information that we are setting up for them, but also the general user interface. We can start collecting metrics about which sections are used most. Input and suggestions in the form of emails and messages can then start streaming in from customers. Concurrently, the customers receive value in what has been delivered so far. That value drives more development, etc.
Project Justification and Selection:
In our situation, we have a lot of projects we could be working on. But which one do you choose? Why is time and effort spent on one project more important than time and effort spent on another project or initiative? Who is to say that your project is more important? Maybe you have the most money to throw at the project. Or maybe you have the loudest voice. Those could, technically, be ways for us to select a project. Although, as you may guess, there are problems rooted in those highlighted methods. We will look at a few methods and best practices rooted in valuedriven development.
As you may recall from earlier, there are four major project considerations for our organization. Here they are in quick summary:
- A new system for employees to manage their benefits and compensation
- A concern from the legal team to secure a security issue currently present but not exploited in a company system
- Improvement sand new feature requests for the current company system
- Client funded requests to produce a similar system in their corporate environment
On the surface, these all seem to be valid project ideas. Let’s play with these project suggestions as we explore the various concepts related to selecting agile projects.