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: –This is very common.  Teams have to groom the backlog to ensure that stories are small enough to fit into a sprint. Some Scrum trainers recommend that Teams spend 10% of their time each week grooming the backlog.  It is much better to have a separate backlog for Features and another backlog for Stories.  The Feature backlog is maintained by Program management.  The Features are validated and prioritized and given to Teams when ready.  The Team Product Owner and Team Members break the Features into stories that comply with INVEST.  One backlog for both does not work well for most teams.  Many people refer to this problem as “user story hell.”

Q: Question: My team consists of system integrators. Before we can engage them, we need an SOW and they need requirements. With agile, there’s no sets of requirements, how do you guys address this gap?

A:  Enfocus Solutions fully addresses this gap. There are two basic ways to do this. It really depends on who provides the Product Owner.

If your organization provides the Product Owner, then the Product Owner defines stories for the backlog and works with development teams to negotiate what will be done for each sprint.  You are basically negotiating for a fixed number of sprints. The Product Owner’s job is to define the user stories and associated tests in enough detail to maximize the velocity of the Team.  The Product Owner will also need to serve as the SME for the team.

If the Product Owner is provided by the Systems Integrator. Then you will be defining a set of Features which represents the project scope.  The validated set of Features is placed in a Statement of Work and are given to a System Integrator. The SOW is done for each Release. Our software fully supports both of these methods.

Q: Could you update the presentation so that on slide 11 with all those stats, could you provide the link to the source, or at least the dates of the report?

A: A copy of the updated slide is shown below. (Also note all slides will be sent to registrants and available in the archive within a few days.)

Q: Slide 13: Any stats on how many organizations actually use paper? Versus Word or other docs that are stored electronically.

A: — I do not have stats on this.  I think the number will grow continually as organizations become more agile.  There is a huge growth in collaboration and agile development tools. Producing paper documents is slow and anti-agile.