by Jenny Boronyak | Sep 10, 2014 | Agile, Uncategorized |
When the term “agile” comes up in a conversation these days, the mind often jumps to agile software development. But there’s so much more to being agile than delivering software products iteratively and incrementally. If our planning or change strategies aren’t agile, we can forget about being able to deliver the maximum amount of business value possible to our customers. Our entire organization must be agile in order to be able to “keep our finger on the pulse” and rapidly adapt to meet today’s demands. On top of being agile, the most successful organizations out there are also lean mean machines, capable of effectively managing the portfolio to avoid surprises and respond to threats quickly and efficiently. In our webinar last month, The Path to Business Agility, Enfocus Solutions’ CEO John Parker discussed the four components that make up a lean agile business: Enterprise Agile Delivery The agile organization must have the ability to deliver products and services iteratively and incrementally based on discovered and validated customer needs. Agile software delivery is usually the first place organizations start when adopting agile. Many organizations have yet to move onto implementing agile in other areas of the organization, and limit their focus to the responsibilities of the agile team. In reality, the agile team only makes up one part of Enterprise Agile Delivery, and Enterprise Agile Delivery only makes up one of four fundamentals that must be addressed for the organization to be considered agile. In the Lean Business Agility Framework, Enterprise Agile Delivery is achieved via three key elements: Agile Teams (Scrum or Kanban)—Support day-to-day work of self-organized teams (using...
by Jenny Boronyak | Jul 25, 2014 | Agile, Uncategorized |
Business agility is more important now than ever, according to a recent report by Forrester Research. In the report, they define business agility as “the quality that allows an enterprise to embrace market and operational changes as a matter of routine.” As Forrester astutely points out, seventy percent of the companies that existed on the Fortune 1000 list ten years ago are no longer in service—the number one cause being the inability to adapt to change. Many organizations have adopted agile methods for software or product development. Agile methods have helped organizations deliver more rapidly, increase customer satisfaction, and improve quality. However, agile development alone does not make the enterprise agile. An agile business must be able to make rapid changes that affect people, processes, data, technology, and rules to support threats and opportunities in the market. The Lean Business Agility Framework™ is here to guide you through choosing the methods that will enable change and achieve business agility in your organization. There are many great existing frameworks and methodologies for implementing agile best practices. However, the Lean Business Agility Framework combines all best practices into one comprehensive guide. The Lean Business Agility Framework was developed by Enfocus Solutions to help organizations visualize what is needed to transform to an agile enterprise. The framework incorporates current trends and integrates various methods from sources such as the Scaled Agile Framework® (SAFe), ITIL®, Lean Thinking, and Lean Startup® into a cohesive approach for moving to business agility. The framework is intended to serve only as a guide and requires an organization to selectively choose the methods that best fit their organization...
by Jenny Boronyak | May 22, 2014 | Agile, Uncategorized |
When it comes to software development projects, agility should be focused on delivering business value in increments, and not developing software in cycles. While software development is a major aspect, it’s not the end goal of our projects. Too often when following agile development, the team is uncertain or unclear of what to build that will actually deliver the value set out for at project inception. Then, what happens is the team starts coding before understanding what really needs to be built, which is a very expensive way to validate that the solution meets customer and business needs. If there is no feedback until the end of a big project, it might be too late or costly to adjust. Instead, it is prudent to get as much feedback as possible, as early in the project as possible. As Eric Ries, author of Lean Startup, puts it, don’t we all want to “avoid building products that nobody wants?” Recent Standish Group research shows that 20% of Features are used regularly and 50% of Features are hardly ever or never used. According to the study, the gray area is the 30% of Features and functions that get used sometimes or infrequently. All of these Features and functions that are never or barely used are causing higher costs, lower value, and longer cycle times, resulting in lower customer satisfaction. Focusing on the 20% of the Features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. To focus on the 20% of Features that give the most value, you need to validate early....
by Jenny Boronyak | May 2, 2014 | ITIL and Service Design, Uncategorized |
When we attended Knowledge14 in San Francisco earlier this week, one thing we noticed is how amazingly far organizations have gotten in adopting IT Service Management (ITSM). But while it does seem organizations have caught onto the fact that moving towards ITSM provides a lot of value, many have still not yet adopted or placed enough emphasis on the ITIL practices of Service Strategy and Service Design. This is a huge mistake, as ITIL offers valuable guidelines to service providers on the best ways to design and maintain services for the business. Image from ITIL Service Design One of those guidelines is to create a Service Design Package (SDP). It seems that many new service providers either neglect the SDP or create one that’s lacking in all the necessary elements. However, creating an SDP ensures your services are designed well, and according to the authors of ITIL Service Design “the better and more careful the design, the better the solution taken into live operation,” so creating a SDP is not a step you want to skip The Service Design Package (SDP) follows a service through its lifecycle from initial proposal to retirement. It contains all the information required to manage an IT service. The SDP specifies the requirements from the viewpoint of the client (not IT) and defines how these are actually fulfilled from a technical and organizational point of view. When created properly, SDPs bring a lot of value to the business. A SDP… Improves the quality of services Improves decision-making Makes implementation of new or changed services easier Improves alignment of services to the business Makes service...
