Skip to main content

Tag: Agile

From the Sponsor’s Desk; The Never Ending Project

Written by Drew Davison on . Posted in Articles. 2 Comments on From the Sponsor’s Desk; The Never Ending Project

In my last post, I reviewed a challenged undertaking due, in part, to flawed incentive compensation. Here’s another example of a project that could have used a great PM. Unfortunately, it grew from a $7 million initiative to more than $30 million with no end in sight. That’s why I call this post The Never Ending Project!

The Situation

This organization provides credit life insurance coverage for financial services companies and their customers. Antiquated business processes and technology restricted their ability to respond to clients’ demands for better products, new services and better integration of the sales and administrative processes to reduce costs and improve responsiveness.

The Goal

To upgrade technology and redesign business processes to enable improved product and service offerings and better integration with their clients’ operations. The plan was to leave the interfaces to existing client services intact to reduce costs and risk. Expected cost was $7 million.

The Project

The organization had a small IT organization and experience with small projects. They were able to acquire an experienced project manager from the parent company and selected third party software to administer the life insurance contracts. A business executive was the project’s sponsor.

The Results

The project floundered on a variety of fronts:

  • They had great difficulty defining project requirements.
  • They had limited ability to test the delivered solution to ensure it met business and client needs.
  • The original project manager was pulled by the parent company, which also pulled the replacement and supplied a third project manager.
  • The vendor reported that it was unable to deliver the requested functionality through the existing client interfaces, significantly expanding the scope of the undertaking.
  • The project returned to the board three times to approve incremental funding. The estimated cost escalated to $30 million, over four times the original estimate, with less functionality and a delayed delivery.
  • The sponsor was adversarial, dictatorial and argumentative with anyone who questioned the effectiveness of the project.

How a Great PM would have Helped

There’s nothing worse for a PM than an out of control sponsor. In this case, a great PM could have leveraged Project Pre-Check’s building blocks (see my May 12, 2010 post) to address and remedy the obvious warning signs early in the project’s life cycle:

  • A strong, fully resourced stakeholder group including the vendor, target stakeholders from other affected organizations (possibly including client representatives) and a champion or two could have offered balance to the sponsor’s belligerence and provided effective early oversight to manage the scope.
  • There are a number of Project Pre-Check decision areas that, had they been addressed, could have resulted in an entirely different outcome:
    • Worth is a decision area that is seldom tackled in project operations yet can provide huge value. Knowing what a change is worth to the organization, and going through the effort to determine that figure, influences the alternatives that are considered, the approaches taken and the oversight applied on an ongoing basis. In this case, was the value to be delivered worth $30 million? Maybe not. Should the plug have been pulled early on? Perhaps.
    • The decision areas dealing with an organization’s capability for determining and managing requirements are critical for project success. If these had been considered and addressed by the stakeholders early in the project’s life, the outcomes would have been much more palatable.
    • The decision areas that address stakeholder capability, planning and managing risks, phasing and staging delivery, among others, could all have helped guide the project to a more successful conclusion.

Projects with revolving PMs are never easy, especially if you’re the last in line. If you find yourself in this situation, put the above points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a project that was in deep trouble when a contract PM took over and by speaking truth to power, was able to deliver successfully. In the interim, if you have a project experience, either good or bad, that you’d like to have examined through the Project Pre-Check lens, send me the details and we’ll have a go.

Don’t forget to leave your comments below

Velocity Part 3 – Five Basic Steps to Effective Constraint Management

Written by Claude Emond on . Posted in Articles. 4 Comments on Velocity Part 3 – Five Basic Steps to Effective Constraint Management

Constraint management is at the heart of Goldratt’s Theory of Constraints (TOC). This management process involves five basic steps [i] :

  1. Identify the constraint
  2. Exploit the constraint
  3. Subordinate other activities to the constraint
  4. Elevate the constraint
  5. Avoid negative inertia and Go back to step 1

In my last blog entry, I identified “the capacity and the will to change” as the limiting constraint of cultural change projects. So I believe I am done with step one. I understand from steps two and three that all efforts must then be shifted to exploiting the identified constraint and that, while doing that, this constraint must be at the center of all our other decisions.

Since we are talking about humans here as being part of the identified constraint, and not about a machine or a piece of equipment, the use of the word Exploits in step 2 of TOC could certainly start us on the wrong foot, in our efforts to promote change. I believe that, for cultural/organisational change projects, it should be replaced by the word Recognise. Recognise what? The existence of this capacity and will to change of those affected, which is the very least we can do when contemplating any change. Once we have recognised this and accepted it, all our decisions will have to go towards analysing this constraint and doing everything to improve its current condition…or at least maintain it, if the way it behaves is acceptable. This is the key to making the contemplated change a success and, if possible, accelerating the benefits associated with this change.

In most change management endeavours, it is rare that we speak very positively of the initial conditions met, people wise, at the beginning of the project. The words that come to mind are not desire to change but rather resistance to change. The capacity and will to change constraint is not seen as something positive we can use, but rather as something negative we have to fight. So, while no one is talking about exploiting resistance to change, not many recognise the positive aspect of one’s capacity and will to change.

I believe most people have a desire to change, if the right conditions are met. According to the Change Gap model, for any group in a given change situation, roughly 10% are change enablers and are seeking change.  Eighty percent of the group are waiting to see how things evolve but are still open to persuasion. The remaining 10% would prefer to die rather than admit they can be in a better position if they accept the change. So I believe we can build part of our change strategy on the desire to change of the change enablers. We must also recognize the high potential of the 80% to be change agents with the right persuasion.. For that, we have to do the right things and find the right conditions to increase both their capacity and will to change

The next step, once we recognise that we are not dealing with negative resistance to change but rather with positive potential desire to change, is to work towards changing this potential into real desire. We have to elevate the capacity and will to change of those 80% who are open to persuasion and ready to get their own benefits from this change…if they recognize the benefits and have the means to get to them. This can only be done by working on both parameters of the constraint, the capacity and the will to change. In my next blog entry, I will propose means and strategies to elevate or increase the capacity to change. In the entry after that, I will propose means and strategies to elevate the will to change.

Anyone, invited to manage a cultural/organisational change project, has to look at it very positively. So, instead of fearing and fighting resistance to change, this person should see desire to change as a positive force to harness and, hence, should design ways to elevate current capacity and will to change.

[i] http://en.wikipedia.org/wiki/TOC_Lean_Six_Sigma

Don’t forget to leave your comments below

Is the Business Analyst a Product Owner or Tester on Agile Projects?

Written by Elizabeth Larson on . Posted in Articles. 5 Comments on Is the Business Analyst a Product Owner or Tester on Agile Projects?

There have been many articles lately about the role of the BA on Agile projects. Some postulate that the BA role is closest to the product owner. After all, it is often suggested, they reside with and represent the business. They are in the best position to be the final voice when defining and prioritizing requirements. Others believe that the key role for the BA on Agile projects relates to testing. Since they define the requirements, they should complete the appropriate testing processes to ensure the final solution meets the requirements. I believe that neither of these is a business analyst role. That’s not to say that someone with the title of BA cannot play other roles as well. It’s just that when they are playing these other roles, they are not doing business analysis work.

BA as Product Owner.

The role of the product owner is essentially that of the business subject matter expert (SME). Their main accountability on the project is to articulate the vision and define and prioritize product requirements. Their role, as the sponsor’s key delegate, is to make business decisions. The BA has accountability to both the business and the project. On the one hand BAs need to ensure that the end product or service meets the business objectives, and that the requirements are defined completely and correctly. However, they also need to ensure that the end product or service meets the project objectives and that it is delivered within the project constraints. Finally and maybe most importantly, BAs are not decision-makers. They are facilitators, consultants and, hopefully, trusted advisors.

BAs as Testers.

Testing on Agile projects is an essential role. While theoretically the delivery team wears multiple hats, one of which would be that of tester, practically speaking I have seen more instances where outside testers fulfill this role. With the wide-spread use of automated testing tools on many agile projects, it is helpful to pay attention to testing on its own with its own resource(s) devoted to it. It seems to me that, as with any approach, separating both business analysis and testing from development work, makes a great deal of sense.

BAs as BAs.

So where do BAs most effectively fit into an agile project. BAs are most effective doing BA work, but the work needs to be done just-in-time.[1] Here are just a few ways the BA can support the agile project:

  1. Help the sponsor and product owner define and articulate the business problem and product vision
  2. Elicit requirements using a variety of techniques, including facilitating cross-functional requirements workshops
  3. Assist the product owner in developing user stories and the associated acceptance criteria so the delivery team will know when they’re done.  These criteria need to be more complete than, for example, “the order has been placed.” I have found that creating specific criterion tends to be difficult for product owners.
  4. Trace user stories to business objectives and the product vision and throughout the sprint to ensure it’s actually been delivered as imagined.
  5. Model the “as-is” and “to-be” business processes.
  6. Model the expected system interactions, particularly when software is being developed.
  7. Look for gaps in data requirements between what is in place and what is needed. Model the data requirements or work with the appropriate people to ensure that the data will support the new solution.
  8. Create mock-ups of the new user interfaces.
  9. Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions. 
  10. Assess how ready the organization is to accept the change.

“Grooming” the Backlog.

So how can BAs do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks? By ensuring requirements are defined completely and correctly before each sprint begins. The BA can work with the product owner and other business and technical SMES as the delivery team completes each sprint. However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.

While many organizations use the term “agile” to mean doing things in a quick and dirty way without adding a layer of business analysis bureaucracy, others have considered the consequences of omitting the role of the BA and are now recognizing the vital role BAs can play.

[1] In the 2010 survey, The State of Business Analysis in Agile IT Practices, participants indicate that “requirements for Agile projects should be immediately consumable by IT project teams. 72% of companies surveyed indicated that requirements should consist of process flows (or visual use cases) or visual story boards in lieu of only textual lists and paragraphs. Requirements that include visual assets (such as business process diagrams, use cases, user interface mock-ups, and data relationships) require less interpretation from project teams and are more accurately leveraged for project direction” (Executive summary p. 4 http://www.requirements.net/2010/06/30/now-available-the-state-of-business-analysis-in-agile-it-projects-survey-report/)

Don’t forget to leave your comments below

The ‘Essence’ of Agile Metrics. Part 2.

Written by Robert Galen on . Posted in Articles. 7 Comments on The ‘Essence’ of Agile Metrics. Part 2.

Let’s go back to the example I gave at the end of my last post. What is wrong with measuring story volatility? On the surface it appears fine. We can see how well the product owner staged the sprint and also how well the team is interpreting stories for execution. For example, if they “signed up” for 10 stories, but only delivered seven because of story (requirement) volatility, then they have a lot of improvement to do…right? Well, that could be the case.

But it could also be the case that the team trimmed those stories because they were superfluous to the customer’s needs. Meaning they were essentially waste. Or another positive interpretation of it could be the team became very creative and figured out a way to meet the spirit of the sprint goal with fewer stories. In fact, they may have even trimmed out some previous code in order to simply the application – so the overall related LOC count might be quite low too.

Can you see the point I’m making? I find that leading indicator metrics can sometimes be more prone to metrics dysfunction than trailing, results oriented metrics.

In his book, Measuring and Managing Performance in Organizations, Robert Austin coined and explored the term metrics dysfunction. In simple terms, it’s a metric whose collection influences the very behavior being measured, leading to metrics dysfunction. One of the classic examples of it is measuring software testers by the number of bugs they find. In this case, testers would report more trivial, non-germane bugs simply to hit the metric. In the meantime, they’d miss truly important bugs. Clearly not what the measurer intended!

In our example, the leading metrics might influence the team towards not changing stories that need to be changed, simply to hit the metric of stories being consistent with the views from planning. I can see nothing more destructive to the agile mindset of the team than having metrics that drive negative behavior within the team simply to meet or game the metrics.

So, what are some unhealthy leading metrics to avoid within agile teams?

  • Planning quality – Measuring how well you planned. An important part of this is change control, i.e. measuring how little or much change is ongoing.
  • Requirement quality – Measuring whether each requirement meets some sort of baseline definition of completeness. Or that each has a specific number of acceptance tests.
  • Estimation quality – I’ve sort of beaten this down in the article. Effectively it’s anything that tries to measure estimation variance with actual effort.
  • Arbitrary results – Counting LOC produced, or Bugs found, or Requirements written, virtually anything that is materially produced by the team that negates the quality of the result and the application of common sense, since not all results need the same level of attention and thinking.

Conversely, what are some healthier trailing metrics to concentrate on within agile teams?

  • Team agitation levels – capturing multi-tasking events, # of committed hours per sprint and variance from expected levels, recruiting support for team members
  • Team velocity levels – trending over time, improvement trending (implying improved team dynamics), paying attention when team composition changes
  • Impediment handling – #’s per team, avg. time to resolve, # that impacted the Sprint Goals
  • Retrospective actions – is the team improving themselves based on retrospective results, how many improvements per sprint, average time to resolve
  • Escapes per sprint – bugs found post-sprint, adherence levels to Done-ness Criteria
  • Sprint Success / Failure – from the perspective of the Sprint Goal. Not so much focused at a Story or Task completeness level, but at an overall work delivered level

One of the things you’ll notice with trailing indicator metrics is that there is an inherent real-time nature to them. We want to be sampling them (observing, discussing, driving action) each and every day during each iteration or sprint.

It’s this level of team awareness of their performance (metrics) and active engagement towards continuous improvement that is a key for functional metrics in an agile context.

The ‘Essence’ of Agile Metrics. Part 1.

Written by Robert Galen on . Posted in Articles. 3 Comments on The ‘Essence’ of Agile Metrics. Part 1.

AgileMetricsThis is my initial blog for Project Times and I’m certainly happy to be joining the community. So, a little about me.

My name is Bob Galen and I’m from Cary, North Carolina. I’ve spent the greater part of 25 years doing software development—in roles such as Developer, Software Director/ Manager, Test and QA Director/Manager, and Project Manager.

For the past 10 years, I’ve been moving my thinking and practices towards those espoused by the Agile Methodologies. I’ve found them to be the most congruent, humane, and effective approaches for delivering software and I try to share my insights and excitement with everyone I meet.

Perspectives – you’ll see a strong skew in my posts related to the following topic areas:

  • Implications of agility for the project manager
  • Implications of software testing for the project manager
  • And leadership and soft skills topics for the project manager

and I also blog for Business Analyst Times on similar topic areas. So that gives you a feeling for coming attractions. But, enough of that…

I’ve been struggling for quite some time figuring out the “essence” of agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning, should we measure the processes (at the beginning or leading edge) or should we more so focus on the results and learning (at the end or from the trailing edge)?

For example—

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?

I’m thinking of it from the point of view of what you’re trying to improve. In this case, you’re measuring estimates and actuals to improve your overall planning and estimation processes. These activities are typically front-loaded actions and are often static…meaning they are completed once at the beginning of the project.

The other challenge with this metric is taking corrective action for improvement. Effectively, you can only effect a change with the next planning interval for a project. Depending on the length of that interval, improvements could be infrequent and delayed. Or depending on project success, they might not be useful at all.

So I’ve seen some agile teams that try to measure various things. Let’s take a typical example.

How about if we measure user story volatility in the sprint? What we’re trying to focus on is how many times do stories change (get added to, become reframed or reduced in scope, or removed entirely) within any particular sprint. To what end? Well, we’d like to improve our story grooming process and monitor how the team is delivering on their sprint planning commitments.

Ah, there’s a key! Sprint planning is sort of a leading indicator, in this case you’re measuring the quality of story entry. What if we turn this into a trailing, more results oriented, measurement? Let’s measure the velocity of the team as they exit the sprint. We can measure velocity in stories produced and in story points delivered.

An even better trailing metric is to measure how the team delivered value towards their sprint goals. Meaning, did they deliver what they committed to? Not in tasks or in stories, but in content that exactly met the spirit of their customers needs and the level of their commitment.

You notice that I reframed the notion of a trailing metric to a results oriented metric. Another way of thinking about it is measuring at the “outbound side” of the team’s work. That way, you’re leaving the doing of the work up to the team and simply measuring results or outcomes. To be continued…

Don’t forget to leave your comments below