Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
One problem all IT departments face is the difficulty of providing early, frequent and clear signs of both progress and value delivery. Has this happened to you?... You continue to move forward month after month until a year or more has passed with only limited evidence of your impact. Your customer is frustrated and you feel your work is overlooked. Agile is designed to get better feedback, sooner, especially with our larger systems. In fact, Agile Down-to-Earth states that delivering high value software is the most important measure of project success. But, how do we go from a great vision to delivering high value, sooner? Our largest systems may take many months to build. Agile works even better when those systems are built and delivered in small increments, but where do you start? And, how do we keep building value early and often? The first release is the most important. Before we go too far, we must be sure that we are building what the business wants and will use. Look for high-value features, but keep your first release's scope very small so it can be built quickly - never more than six months from Feasibility to Realization. Get it implemented; learn from it, gathering as much customer feedback as possible. This is the goal: we need to hear more feedback from more users, earlier. Keep your teams and stories small, so we can move quickly and accept change more easily. As they say, "do not bite off more than you can chew". But, How Small is Small Enough?The Minimum Viable Product There is a new(ish) wave in systems development that is designed to address the problem of size, adapted from The Lean Startup methodology, called Minimum Viable Product (MVP) or Minimally Viable Product. Agile embraces change. Enterprise systems are large and often the vision for their functionality is broadly spread across different users and departments. The impact of change on a large system is costly and leads to customer dissatisfaction. What pleases one group may not please another, and if the product being built is new, it is not always easy to identify exactly what features are most important to all and in exactly what shape and size. So, plan for change. One answer to this is to shorten the "time-to-market" of our new products. But shortening the first delivery is not enough. We must try to deliver the most valuable features early. What makes this package "minimum viable" depends on certain factors. Can we deliver the functionality without integrating with a current platform while that integration is being built? Can we deliver a modified solution that can be used to prove its true value while the more complete solution is being designed and developed? Can we do this in stages? Imagine your Project, only Smaller When you know you are going to take an incremental approach, it helps to think "smaller". If it takes more than six months to deliver your first release, you are starting too large. That means that only two or at most three months of development Sprints will be possible. Your product vision is still the same total size, but your definition of scope for the first Agile cycle is the most valuable increment. Dedicated Feasibility TeamIn order to get to high-value sooner, we want to drive for great clarity in Feasibility, and agree on what is most "valuable". Consider using a full-time core team on Feasibility and keep it short by dedicating two to five days for full-day vision and design sessions. If this product is new to the company and meets an important need, the commitment to gather the entire business vision must be high for both IT and the business sponsor. But it is impossible to represent all users in these sessions. The secret to the MVP approach is to look for the broadest value that can be delivered soonest and get it into the hands of the users to begin the feedback process. Broad Customer Feedback One of the most important keys to success with the MVP approach comes from The Lean Start-up, created by Eric Ries. Get your product into as many hands as possible, as soon as possible. Then, ask them what they want. This can apply to enterprise solutions, too. Customers often need to see, touch, and use a product before they know what special features will make it most useful to them. Pictures and prototypes can be essential, but broad customer feedback can lead to the best adoption rates. Don't Stop Designing While Feasibility is a distinct Agile phase, it is not intended to be a "once-and-done" phase. It is completely valid to go back to Feasibility as you plan your next release. What have you learned from your prior release? Have business priorities changed? You may want to begin the Feasibility phase for the next release as soon after your initial release as you can gather quality feedback from your customers. Build, Measure, Learn The goal of this approach is to get through all the phases of initial development faster. Build only what is essential to the product's success, measure everything, and learn in larger groups to apply the broadest view to the next product release. Gather and record your measurements and feedback. Use them to drive approval discussions for the next product release. Consult everyone and share it broadly. Stay one Release Ahead The Agile Sprint methodology assumes that we can deliver an increment now that does not need to be the entire feature, because we can build additional capabilities in future Sprints if the priority still exists. That same allowance for change and value judgment is part of the MVP approach. Keep your business partners looking forward to the complete product while leaving room for much more feedback and re-evaluating the value of the next incremental release. Stay one release ahead in the mind of the business and be sure to focus on flexibility to develop exactly what the larger audience will embrace and adopt. No matter what, if the MVP has not been a success be open to change or stopping the project. Article SummaryMany IT projects bring large new capabilities to your product mix. With new products, as with large ones, the probability of change is high. It would take a much larger up-front investment to evaluate what every user would likely want and even then, it has been proven that you may not develop what is most likely to be used. Bringing new functionality to the business requires an approach that embraces change. That is a fundamental feature of Agile. We embrace change. This article proposes carrying that to the next higher level. Rather than gathering a detailed fine-line vision for the entire product and then taking a year or more to deliver it, try designing a Minimum Viable Product (MVP) that can be delivered in six months or less. Then, carefully gather broad customer feedback before adding the features that may change once the end-customer has evaluated the new product. The keys are speed and value. Commit the time and resources to design the MVP in a focused, short time, and get it in the hands of the user as soon as possible. Keep the business sponsors aware of the total vision, especially if the MVP does not include important integration with current platforms, but get something out that they can touch and see. New products often need this flexibility to encourage adoption and embrace change.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
September 2014
Categories
All
(c) 2016 - Agile Down-to-Earth All rights reserved |