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 John Parker | Mar 14, 2014 | Business Analysis, Project Management, Uncategorized |
Normally, trends and projections come out in December or January. These are a little late, but at least they still make the first quarter in 2014. Here are my predictions of key trends that we will see affect business analysis and project management in 2014. 1. Agile Continues to Grow – Agile adoption will continue to grow. This will mean many changes in terms of how requirements are developed and managed. Requirement “shall” statements will be replaced with user stories. The three C’s model of users stories: Card, Confirmation, and Conversations will continue to grow. PMs and BAs will continue to redefine their roles in the agile world of self-managing teams and product backlogs. 2. Managing Data not Documents – As agile adoption continues, the need for large paper based requirement documents will go away. Requirements will be managed as data in a backlog, not as long paper-based business requirement documents (BRDs) or Functional Requirement Specifications (FRS). 3. Dual-Track Agile Takes Off – Agile will be difficult and a cultural challenge for many organizations where there are multiple teams and resources are not collocated. “User story hell” will become a reality for many organizations as teams continue to spend more and more time grooming the backlog. Many organizations will adopt dual-track agile or some variant to better manage discovery activities. This will enable lower costs as requirements will be validated using less expensive methods than code. 4. More Emphasis on Business Change – The BABOK Version 3 will be released sometime in 2014. There are big changes coming to the role of business analysis. The focus will be much...
by Enfocus Solutions | Mar 12, 2014 | Business Analysis, Product Development, Uncategorized |
I was recently reading an article about a company featured in Fast Company magazine, who has become very successful with a very simple business model: give customers only what they want. You might be thinking: “well, that’s what every company does.” But, the 2013 Chaos Manifesto published by The Standish Group presents a very different story. They report that only 20% of any given product’s features are used often, 50% are hardly ever used, and the remaining 30% are used infrequently. Yikes. That literally means that about 70% of the functionality most companies are spending their money to discover and deliver to the market are not really even being used—and by extension, one can assume, needed. As a consumer I know I can relate to that—I’m pretty sure my phone does much more than I ever use, know how to use, or care to use. You can probably relate. But this company I was reading about in Fast Company, they didn’t really seem to have that issue because either a) they did not build anything not explicitly asked for by the market, or b) they quickly tossed any products that were not being used and moved onto research what else to develop. Now maybe that in and of itself is not that interesting, but what I did find interesting was they approach they used to do it. And how easily they seemed to have done it—as well as how cheaply. Some organizations spend thousands of dollars a year on market-sensing activities trying to figure out what the right product and features are to build—focus groups, surveys, market research service...
by John Parker | Mar 10, 2014 | Project Management, Uncategorized |
According to the Standish Group, over 60% of projects fail or are challenged. Gartner Group 2011 research shows the same story; only it paints a slightly worse picture. Based on these statistics, program/portfolio managers and PMOs need to have skills for rescuing troubled projects. Determining if You Have a Troubled Project It is important to determine if you have a troubled project before any significant intervention is taken. It is best to do this using predefined criterion that are administered at the PMO or portfolio level. The following criteria provide some examples: Project Planning The project does not have an agreed upon vision and clear set of objectives. Impacts that the project will have on the business architecture have not been identified and defined. A thorough stakeholder analysis has not been performed. Discovery The solution scope has not been clearly defined as a set of features that can be delivered independently. Customers and users are not adequately engaged in project discovery activities. Delivery Delivery team satisfaction is low. Agile team commitments have not been met. Velocity is decreasing. Project Performance The project is trending 20% or more over its estimated budget. The project is trending 20% or more over its estimated deadline. Benefits Realization The client is extremely dissatisfied with the performance of the project team. Benefits as defined in the business case are not being achieved. Project Recovery Process Turning around a troubled project is never easy, but there are approaches that can be used that provide a good chance for success. It is important to note that success may not mean delivering the project within the original time and budget constraints. Rather the focus must now be on salvaging the project to ensure that the project addresses the business need and achieves the expected business outcomes. If...
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...
