Collaboration: Working together through Product Delivery (Part 3 of 3)

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

Two new webinars: Agile Business Transformation and Agile & ITIL

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

Requirements Management Tools versus Robust Business Analysis Tools

In one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance.  Standish Group Research shows that the top five reasons for failed or challenged projects are: Lack of user involvement Lack of transparency Poor or incomplete requirements Changing requirements Lack of business alignment Now, examine these problems carefully; all of them are related to poor business analysis.  Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK. Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements. Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and...