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 John Parker | May 16, 2014 | Agile, Uncategorized |
There were a few great questions asked at the end of our webinar yesterday, Agile Business Transformation. While I didn’t have time to answer them in the information-packed webinar, here are your answers. Q: Does Enfocus know of publications on Agile transformations for business with products with HW as well as SW products? A: –Agile Development has been used for both the development of hardware and software products. One of the best-known examples is the development of Nokia phones. In Enterprises, many infrastructure groups are also starting to use agile. Many organizations are starting to adopt DevOps which is an umbrella concept that refers to anything that facilitates a smoother interaction between development and operations. The best information for large agile transformations is at www.scaledagileframework.com. There is also a major movement toward integrating Lean with agile and there are several good books on this subject. A very good book on this subject is Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck. Q: I find it challenging to differentiate a Feature from An Epic! For example, how would you determine if a BR is a feature or an Epic? A: — Great Question. A feature has to be small enough to fit into a Release. An epic spans multiple releases. Epics are approved by Portfolio management, whereas Features are defined by program management and are used to decompose an Epic into manageable components. View an epic as a project and a feature as a component of a project. Q: Most of the time, we find the stories changing to be a Feature or Epic! A:...
by Enfocus Solutions | Apr 29, 2014 | Agile, Uncategorized |
In today’s world business leaders are demanding IT organizations deliver high value mobile applications at little cost and lightning speed. And if you’ve worked on any mobile application project, then you know that mobile application development projects can be a challenge. Mobile apps and websites used to simply be a replica of the desktop version of a website, but today they are much more. They are productivity tools, information lifelines and are central to how successful companies are conducting business. For example, in the past marketers used to have to wait and gather campaign statistics – in this day and age, marketing and sales use mobile apps to track campaigns, manage promotions, track inventory – in real-time! By now we’ve all heard of Pinterest and have seen how much growth they have experienced since they first popped up on our social media radar a couple years ago. From inception, Pinterest has seen visits skyrocket by 5,124 percent to more than 28 million visits per week in their second year of business. The result? As an organization, they had to move quickly to successfully support their growth spurts, or risk the trap of ‘growing too fast’ and not being able to keep up with the market demands. They did this through automation, agile tools and strong collaboration between developers and all other operations. In other words, Pinterest was successful because they were able to move quickly and had established an agile development environment early on. One of the key principles of Agile Development is the ability to handle changing requirements even late in the project, and minimize the risk usually...
by Enfocus Solutions | Apr 17, 2014 | Agile, ITIL and Service Design, Uncategorized |
Join us for two of the newest webinars in our Enfocus Solutions webinar series! Agile Business Transformation May 15th 2014 at 12 PM Eastern Standard Time (US & Canada) Agile has become mainstream for developing software. Organizations that have adopted agile have seen improvements in quality, cycle time, and customer satisfaction. Standish Group research shows that agile projects are three times more successful than traditional plan driven projects. However using Agile Development practices does not make an agile organization. Frequent delivery of software provides little value if the software cannot be deployed because of rigid release and change management processes. Another significant challenge facing enterprises is how to coordinate agile teams across multiple projects in multi-disciplined environments. Companies are appointing agile coaches to individual projects, but there is little or no company-wide coordination. In addition, little has been done to help transform the business to be able to respond more rapidly to change. Agile transformation requires focus on four key areas: Agile Discovery Agile Delivery DevOps Agile Business Change In this webinar, John Parker will address these four topics with heavy emphasis on Agile Discovery and Agile Business Change. He will also discuss how BAs and PMs will need to transform to operate in the agile environment. Target Audience: PMOs, Agile Project Managers, Agile Business Analysts, Enterprise Portfolio Managers, and Product Owners Agile & ITIL June 10th 2014 at 12 PM Eastern Standard Time (US & Canada) At first Agile and ITIL seem at odds because of the rigid release and change management process of ITIL and the rapid delivery of software in agile. However, the two frameworks are actually...
by Jenny Boronyak | Mar 5, 2014 | Agile, Project Management, Uncategorized |
In our previous blog on Dual-Track Agile, John Parker described the benefits of this emerging concept. Dual-track agile is an approach to agile development in which project teams are constantly working on the discovery and delivery of solutions that will deliver business value and obtain user adoption. By following the principles of dual-track agile, project managers and their teams can eliminate a lot of frustration and costs in agile development. Below are the key guidelines to implementing dual-track agile in your projects. 1. Put together a proficient discovery team with expert capabilities who are able to blend entrepreneurial skills and research gathered from the market. Your team needs to have the following skills so they can thoroughly and effectively understand the problem, recommend the best solution, and align the project with business needs: User Experience/User-Centered Design Business Analysis Pricing and Financial Analysis Customer Discovery Impact/Gap Analysis Focus on Collaboration Experimentation Attitude 2. Have the discovery team working one or more months ahead of the development team. The discovery team should be constantly populating the backlog with validated ideas and user stories. 3. With the help of the discovery team, create an understanding of your customers’ core problem before gathering ideas/features. Do not start putting together a solution until you have a complete understanding of the problem. Use Root Cause Analysis techniques like Fishbone Diagrams or The Five Whys to dig deep into the source of the problem and set the context for the project. 4. Develop a shared vision by hosting a vision planning workshop. Invite the product owner, business stakeholders, technical subject matter experts (SMEs), user-centered designers, and...
by John Parker | Feb 21, 2014 | Agile, Business Analysis, Project Management, Uncategorized |
The questions below came from our latest webinar on KPIs for Agile Project Managers and Business Analysts. What are some leading BA KPIs? Stakeholder satisfaction by Feature (Satisfaction) Stakeholder activity by Feature (Engagement) Cycle time from ideation to Feature approval Business value per Feature (Value) Test coverage for Feature (Quality) Number of defects per Feature (Quality) Feature Completeness (Inspection or Peer Review) Is it common practice to have stakeholders sign off on KPIs prior to development? Yes, however, stakeholders should also be actively involved in their development. Getting stakeholder approval is key for all KPIs. What is a good way to minimize the time to get signoff on requirements WITHOUT getting poor/missing/misunderstood requirements? Optimally, requirements should be reviewed as they are being created. To do this requires an automated requirements tool such as Enfocus Requirements Suite™. Here are some specific recommendations: Break down the solution scope into separate independent components (Features). Validate each Feature and eliminate Features that provide little or no value. Define solution requirements only for validated features. Assign a BA and a Sponsor to each Feature Allow stakeholders to review and comment on each requirement as they are being developed using an automated tool such as Enfocus Requirements Suite.™ Obtain review and signoff on a Feature by Feature basis using stakeholders that are involved in that feature. This procedure can prevent a lot of noise. Measure the cycle time from Ideation to validation and validation to acceptance. Where can I get the benchmark for any metric? There are many benchmarking services, including: APQC The Hackett Group InfoTech Enfocus Requirements Suite™ (RequirementCoach™) Process Intelligence What tool was...
