by John Parker | Jan 27, 2014 | Agile, Uncategorized |
The term Dual-Track Scrum, invented by Jeff Patton, independent Agile Coach from AgileProductDesign.com, represents an approach to software development that assumes that there are two key tracks for agile product development: Discovery and Delivery, as shown in the diagram below: This approach has a lot of merit and can eliminate a lot of frustration and costs in agile development. Often, agile teams have long and frustrating sprint planning meetings because backlog items are not well defined, understood, or validated. This often results in slow velocity and extra development iterations because a basic understanding and design details are worked out during the sprint using code. The amount of waste and rework is very high because backlog items have not been defined and validated properly. To get around this, some agile coaches have recommended that teams spend 10% of their time grooming the backlog. Some agile coaches even recommend conducting separate meetings for grooming, sometimes referred to as “Story Time” sessions, for the sole purpose of grooming the backlog. An agile project, like other projects, is subject to “scope creep” in the form of user stories that get created but do not really yield substantial value , yet were thought to be “good ideas at the time.” Another problem is that teams and often product owners are not qualified to assess business value and validate ideas for need. A much better method to prevent these problems is to implement a dual track for discovery and delivery. I firmly believe this dual-track approach will increase velocity, provide higher quality products, and at a much lower costs. The discovery track is all about...
by John Parker | Sep 18, 2012 | Agile, Business Analysis, Product Development, Uncategorized |
There are three fundamental roles in Scrum: Product Owner, ScrumMaster, and Team. This article discusses the Product Owner in how in many cases a Business Analyst is the best person to serve this role. Product Owner is the most demanding of the Scrum roles. The Product Owner creates a vision of what needs to be built and conveys that vision to the Team. Effectively communicating this vision is key for beginning any agile software development project. In Scrum, the Product Owner is the primary person responsible for ensuring that the solution delivers business value. The Product Owner leads the development effort by conveying his or her vision to the Team, creating requirements (user stories) in the backlog, and prioritizing user stories based on business value. The Product Owner must work closely with stakeholders and the Team to make sure their interests are included in the release. The Product Owner works closely with the Team to negotiate work assignments, resolve issues, and ensure that the agreed upon work is completed by the end of the iteration. The Product Owner must be available to the Team during the sprint to answer questions and deliver direction. This combination of authority and availability to the Development Team makes it difficult for the Scrum Product Owner not to micro-manage. However, Scrum places significant value on self-organization and, as a result, the Product Owner must respect the Team’s ability to create its own plan of action. This means that a Product Owner is forbidden from assigning the Team more work in the middle of the sprint. Even if requirements change or some business dynamic arises...
by John Parker | Aug 9, 2012 | Agile, Business Analysis, Uncategorized |
Agile projects are successful three times more often than Waterfall projects, according to the 2011 CHAOS Manifesto from the Standish Group. The report indicates “The Agile process is the universal remedy for software development project failure. Software applications developed using the Agile process have three times the success rate of the traditional waterfall method, and a much lower percentage of time and cost overruns.” The Standish Group defines project success as a project that delivers on time, on budget, and includes all planned features. Even though the Standish research shows the chances of success are much greater with Agile than using traditional Waterfall methodology, there remains a high chance (58%) that a project will be challenged, failed, or cancelled. Let’s examine some reasons why Agile projects may have problems. Poor Stakeholder Communication Poor communication between stakeholders and IT is a common downfall of any project; Agile projects are not exempt. Poor communications can result at several levels including product owner to stakeholder, product owner to team, and even team to team. Unfortunately, stakeholders are frequently not be clear about what they expect from team members. Requirements and Specifications are Incomplete or Not Clear A major cause for failed Agile projects is that the requirements have not been thoroughly defined. Agile classes teach us to garner user stories; you are also taught to elaborate user stories with test cases and conversations. Many teams seem to forget the test cases and conversations. I have seen this as a major problem on many projects. To avoid having a project with incomplete requirements, or an abstract scope, take the time to carefully define...
by John Parker | Feb 9, 2012 | Agile, Business Analysis, Uncategorized |
The best-of-breed vs. integrated suite has been an ongoing battle since integrated ERP software suites were first introduced. In the early days, buyers were forced to choose between multiple standalone systems that performed single functions very well or one integrated system that offered modules for most functions, but with varying degrees of functional depth. Over time, however, the functional gaps between best-of-breed offerings and integrated suites has narrowed. However as business models are beginning to change rather rapidly, the gaps are starting to widen again as smaller more agile vendors are able to focus on best of breed software for key processes with high rewards and quick paybacks. Software as a Service (SaaS) offerings are also threatening traditional business models. Large expenditures for ERP software solutions may be a thing of the past. For most organizations, there is stiff resistance against long-term and high-cost ERP maintenance contracts. Companies typically spend 16-22% of their software license fees on maintenance and support each year. This maintenance cost is becoming too high for many organizations as they look for other alternatives. Some organizations have simply cancelled their software maintenance contracts while others have sought alternative support mechanisms. However, these strategies are not advised and together present many risks for an organizations, including, among others: Inability to upgrade the software Lack of support for critical situations Difficulty in supporting changes in business processes without new software functionality Proliferation of workarounds, and Conflicts with other contractual arrangements The cost of upgrading ERP software to current versions is extremely high, often in the millions or tens of millions of dollars, especially if the package has...
