Agile Business Transformation Q&A

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:...

Collaboration: Working together through Product Discovery (Part 2)

For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post The question of when teams need to collaborate in the product development lifecycle has an easy answer: always. But, there are key activities that take place within a product development lifecycle where collaboration is absolutely necessary. Collaboration through Product Discovery and Product Delivery  There is an emerging concept in product management called dual-track agile that essentially looks at product development as two tracks: the product discovery track, and the product delivery track. On the product discovery track, teams collaborate to understand what the right product is to build. On the product delivery track, teams collaborate to make sure the product is built right. (Source: Jeff Patton, www.agileproductdesign.com) Both tracks require a foundation of collaboration and validation in order to be successful. In today’s blog post we’re going to talk about the importance of collaboration through the product discovery phase of product development—when teams are  trying to figure out ‘what’ actually needs to be built in order to be of value to the market. Traditionally, in the product development lifecycle the validation of a product doesn’t tend to happen until after the launch of a product or during the validation of a developed prototype. Usually by that time, a significant amount time and money has already been spent on defining and developing the product to some degree—without completely validating that the product will meet a market need. On the product discovery track of the dual track agile approach, the focus is on validation, validation, and validation. Validation that the right problem has been identified, validation that...

Business Analysis and Project Management Trends in 2014

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...

Guidelines for Dual-Track Agile Project Management

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...