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 21, 2014 | Collaboration, Product Development, Uncategorized |
For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post For Part 2: Working Together through Product Discovery, read previous blog post In the last blog post we talked about the importance and the opportunities for collaborating during the product discovery phase of the product development lifecycle. In today’s blog post, we take a look at collaboration through the product delivery phase of the product development lifecycle. Collaboration during Product Delivery The second track in the dual track agile approach to product development is the product delivery track. Once a feature has made it onto the product delivery track, it will have been validated for viability and an understanding that the right feature has been defined — but now needs to be built correctly. Easy right? Not without collaboration and validation from your development team, your users, your marketing ream, your design team … well, you get the picture. Just the same as product disovery requires a collaborative validation effort to be successful, so does product delivery. The difference in the product delivery phase is that the focus becomes less of ‘are we building the right product’ — and more of ‘are we building the product right?’ This means the focus shifts towards ensuring a product will be adopted — in other words, the focus is on the usability of a product and ensuring the features that are developed, are developed in such a way that they will actually be used. User adoption is driven by understanding what the user needs Once a product reaches the delivery phase, we know that it is the right product, but that...
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 Jenny Boronyak | Feb 11, 2014 | Business Analysis, Uncategorized |
User stories provide agile practitioners with great success because they help focus on the value being delivered to users. As Mike Cohn writes in his book, User Stories Applied: For Agile Software Development: “Rather than allowing product backlog items to describe new features, issues to investigate, defects to be fixed, and so on, the product backlog must describe some item of value to a user or to the product owner.” And that’s why a key component to agile software development is effectively managing the user story backlog. Typically in an agile operation, an initial set of user stories is defined as part of the discovery process, and additional user stories are continuously added by the team as needed during delivery. Defining user stories is a convenient way of capturing requirements at a high level of detail while focusing on user goals—which is why they can be so successful at helping you determine what is valuable to your uers. Good user stories are much more than just statements. A good user story consists of three elements, commonly referred to as the three C’s: 1. Card The user story should be able to fit on a 3”x5” note card, efficiently capturing the most important information. While this “C” sometimes refers to an actual note card, we mean it to refer to the optimal size of a user story. As Jeffries writes, the card should not contain all information about the requirement, but rather just enough to be used in planning to identify the requirement and remind the project team of the story. Each user story should follow the standardized format of:...
