Tag: Agile

Most project management software solutions are excellent at capturing project detail. Simply capturing data points, however, has limited strategic value. Strategic value comes from turning data into reports that inform strategic decisions by illustrating the relationship between all of an organization’s projects, their effect on resources and ultimately profitability.

Most project management environments only inform tactical decision making. They help project teams ensure their projects are on time, within budget and done to specifications. They answer questions such as:

• Where do we stand on plan vs. actual activities?
• Are we meeting milestone and deliverable dates?
• Are we exceeding planned budgets?
• What is the overall status and where are the bottlenecks in the project?

Project management professionals live and die by project status reports that track these issues. There is a common thread that ties these reports together. They deliver monolithic views of project environments. Although this tactical data is necessary for a project’s success, status reports focus on individual projects in isolation. This siloed view does not portray the impact of a project on the rest of the organization and the other projects, programs and portfolios it may affect.

Most projects do not work in a vacuum. Actions taken on one project affect cost and available resources throughout the company. Singly and together, projects affect organizations’ strategic objectives.

A broader view of project management analytics can provide a wealth of information to turn projects into strategic activities that elevate organizations.

For organizations to take their basic project reporting from status reports based on siloed data to true project analytics, they must consolidate and organize data across all projects. Project analytics need the same ground-level data now collected at the tactical level – time sheets, budget records, plans and schedules – but they need it for all projects in progress. For analytics to have strategic value, executives and project managers need to have the ability to see the workloads and resources assigned to multiple projects. A consolidated view of that information enables project stakeholders to:

• Assess the viability of projects within a portfolio;
• Decide whether projects are meeting Key Performance Indicators (KPIs); and
• Provide clients access to relevant data for checking on their projects’ progress.

To effectively merge data analytics into project management, companies must be able to mine all of the information entered into both unstructured data sources (documents, spreadsheets and email) and structured sources (such as a project database). That breadth of data gives companies visibility across projects, resources and portfolios. It also empowers managers and executives to gauge projects’ performance and their impact on corporate objectives. Project analytics based on broad data capture also provides the strategic metrics for organizations to make well informed decisions based on a complete picture of their project activities.

Tunnel vision

Project managers must often make decisions based on partial information. This “project tunnel vision” might push projects ahead, but it does not consider the impact these tactical decisions can have on the organization as a whole.

Project tunnel vision is more than just a lack of data and limited reporting. The tunnel vision syndrome begins with the people and culture of running projects. Many project management organizations work reactively. Project leaders are assigned whatever projects are deemed most important. They are directed to focus on delivering the best possible outcome—which at the individual project level means a tactical outcome.

Strategic project management concepts are new to most organizations, and many of them are not prepared to move to a strategic mindset. This shift can only begin by first evaluating their current state of affairs and developing a plan of action to take projects to the next level.

Turning project management into a strategic asset means including analytics in Project Portfolio Management (PPM) and governance frameworks. Business Performance Management (BPM) technologies and methodologies can help.

BPM is a discipline that grew out of the Business Intelligence world. BPM allows companies to mine business data from various sources, analyze it and take appropriate action. By continuously reviewing dashboards, BPM delivers strategic information businesses need to balance specific business activities against predefined goals. BPM enables companies to identify problem areas quickly and forecast results more accurately. BPM is also used for risk analysis and to conduct what-if scenarios to improve future performance.

Although BPM is commonly used in areas such as operational performance, sales performance and financial performance, the project management world has not used it consistently. The concept of a balanced scorecard is an excellent example of a BPM methodology often not employed by project management groups.

Balanced scorecards have been at the center of the BPM world since its beginnings. They incorporate financial and non-financial metrics to monitor performance against specific targets. In addition, methodologies such as Activity-Based Costing (ABC), also popularized by BPM, can provide excellent insight to projects by assigning cost values to all activities and resources impacting projects and their stakeholders. These BPM methodologies are commonly employed by businesses to make strategic decisions and ensure that projects are performing to expectations.

In light of this, to develop a solid performance management and analytics strategy, project management professionals need to ask themselves the following questions:

• How easily accessible is project data? Is data siloed or centralized?
• What are the primary components that need to be assessed across all projects? Is it resource driven? Is it budget driven?
• What are their organizations’ goals and targets? How will they be measured? Do they have defined KPIs in place?
• What is their risk management strategy? What kind of tools do they have in place to conduct what-if analysis?

A well-thought-out governance framework and a PPM strategy is the first step in identifying what metrics and analytics are needed to improve project performance. PPM means mining the mission-critical project data captured throughout your organization and measuring it against corporate goals and KPIs. Although many models of measurement are available, the biggest challenge lies in quickly accessing the data from multiple sources, processing the information, then providing the results to the appropriate decision makers. Consequently, true project analytics means that organizations need to respond to their project information with the same conviction and care as their colleagues are currently doing in sales, operations and finance.

---

Neil Stolovitsky has 10 years of IT experience with end-user, consulting, and vendor organizations, along with extensive expertise in business development, software selection, and channel strategies. Neil is a Senior Solution Specialist with Genius Inside and can be reached at [email protected]. For more information, please visit www.geniusinside.com.

I recently attended the Business Analyst World conference in Ottawa, Canada. The audience was comprised of mostly (no surprise here) business analysts but also included project managers, technical leads, and a few project sponsors. What I found intriguing was that about one third of the track sessions were concerned with agile-related topics, and the buzz in the hallways between sessions and at lunch seemed to lean towards agile. I guess this means that agile is now solidly on the radar of the mainstream project community.

Having delivered a presentation and participating in a panel discussion on agile, many came to me during the lunch sessions and breaks to answer questions they had about the implementation of agile methods on real projects. A theme that commonly emerged was the chaos that project teams were facing in the face of inadequate project startup activities. Some believed that project startup work was essential to traditional (a.k.a. “waterfall”) approaches, while these activities were not required for agile approaches. Let me summarize for you the answer I shared over and over again during these discussions.

First off, for there even to be a project in the first place, some up front work needs to take place. For executives to approve the expenditure of resources on a project, they want to know three things: what are they going to get, for how much money, and when will it be delivered – the old iron triangle of scope, time, and budget. Typical governance policies in organizations will not allow a project to begin without appropriate approval, and those providing such approvals require this basic information to make their Yes/No decisions. Such decisions are usually based on some type of business case analysis. The level of rigor in developing the business case depends upon the size of the project, the organization’s industry, and its level of maturity. Generally speaking, however, the business cases should quantify the benefits expected from a project and the costs required to create the environment wherein those benefits can be realized. Using that information, a business executive can then decide if the project is “worth it” – i.e. do the benefits outweigh the costs enough to justify the risk and investment in the project. The work required to gather information on benefits and costs is required no matter which project delivery method is being used: traditional or agile. This information is needed to decide whether or not the organization should bother launching the project (traditional or agile) at all.

Developing the benefits analysis for a business case is one piece of work that I won’t go into detail here. The process is the same whether one is using a traditional or agile approach. Developing the cost case, however, differs somewhat.

A cost case is developed by gathering the prices of materials and labour inputs to the project. Labour input estimates from external vendors are usually provided in dollars, and internal service teams may provide their estimates in either dollars or hours/days. Regardless of whether these estimates are coming from internal or external service providers, think for a moment on what work is required to create them. In both cases, the underlying number is an effort estimate measured in hours or days. External vendors will then apply contingencies and multiply this by some type of cost rate in dollars. Effort estimates can then be translated into a project schedule/timeline. To come up with the effort estimate, however, requires a much deeper analysis.

A team being asked to estimate the effort to do some work first needs to understand the nature of the work (overall solution design or approach) and enough details (scope or estimating assumptions) about the work that they have a reasonable basis upon which to base their estimates. It is clear then that before estimates can be prepared, some amount of solution design work must be done; else, how will the team be able to prepare their estimates – they would not know what it is that they are being asked to estimate.

The overall solution design, in turn, is based on an even earlier analysis of requirements. We need to understand the business requirements that are driving the need for the project’s output in order to make sure that we understand all of the required aspects of the solution. These requirements can then be transformed in the context of an overall solution design into a list of solution features for which the project delivery team can then provide estimates.

Under most organizational governance models, all of this work is required to be completed before a project can begin. This work all leads to the completion of a business case that the project funding person or group within an organization needs in order to conduct a reasonable assessment and make its Yes/No decision on whether or not to proceed with the project.

The difference between traditional and agile methods is the level of detail that goes in to the preparation of the business case. Because traditional methods perform most of its analysis and design work up front in order to come up with a detailed project implementation plan, these methods need to spend a lot of time conducting detailed analysis in order to prepare a detailed business case. Agile methods differ in that they begin with only a high-level understanding of requirements and solution design before the team prepares rough estimates that can be put into an initial business case. Initial funding may begin with only a high level business case, but typically the detailed business case is required before the full project funding can be released. In traditional approaches, the detailed work is usually completed before developing the project solution can begin, while under agile approaches, the solution development work can begin right away and the more accurate estimates and plan are delivered after a prototype/proof of concept phase wherein the delivery team gains experience with the technology, the other team members, and the stakeholders before committing to a more firm set of effort estimates and timeline.

With the greater level of detail required, traditional approaches tend to spend more resources in preparing business cases for the Yes/No funding decision. Agile methods tend to work at a higher level of detail, avoiding deep analysis until just before the work on an element of the solution begins. This means that the organization can get to a Yes/No decision much more quickly and cheaply using agile methods. Yet, it is important to point out that a business case for an agile project still needs up-front requirements analysis and solution design, just at a higher level of detail.

Adequate performance on these project startup activities of requirements analysis, solution design, estimating and planning can mean the difference between success and failure on your project – regardless which delivery method (traditional or agile) that you use. If you are using traditional methods and do a poor job on your project startup activities, your estimates and plans will be wrong and your project will struggle right from the moment that real project begins. Similarly, and agile project that does not spend adequate time with up-front work (before the first solution development iteration) will not only have a difficult time getting funding approved, but also the team will struggle in trying to build the right solution and in providing meaningful tracking and forecast metrics to help manage the project delivery.

Many agile proponents minimize the importance of project startup activities to the overall success of the project. In part, this is due to the fear that teams will be tempted to do a full, detailed up-front requirements analysis and solution design, wasting resources on items that may change before they get implemented later in the project. In other words, they are afraid that teams will migrate back towards doing a big design up front (BDUF) – a less than agile approach. As a consequence of this, many inexperienced agile project leaders then try to launch projects without adequately performing the project startup activities, leading to failing or troubled projects and demoralized teams. Many organizations have attempted and failed at their adoption of agile methods for this very reason.

It is absolutely critical that our project leaders understand the differences in the level of detail required in traditional and agile approaches and to ensure that they expend the right amount of effort in these project startup activities. Failure to do so means that your project may not only be significantly challenged throughout its lifecycle but also its business case may never be approved in the first place.

I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.

All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.

The odd thing, at least in my experience was that no matter how hard I tried nor how much effort I expended on estimation and planning, over 60% of my projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.

I guess my point is—estimation is incredibly hard.

Now you may say, well Bob, you simply were poor at estimation and didn’t really perform it all that well. My counter is that I am really good at estimation. I’ve studied a wide variety of techniques and applied them diligently. I’ve even taught software estimation at international conferences. So, while I still have much to learn, I’m not a tool-less novice.

And I guess my other more crucial point is—estimation was the wrong place to be focusing my efforts!

What the Agile Methods Taught Me

When I first was introduced to the agile methods I was struck with the practicality of the planning. Instead of focusing on planning & estimation, the methods broke things down into two levels—high level release forecasting and low level detailed iterative planning. More importantly, it was the interplay between these two levels over time that refined your estimates.

No longer did you try to predict a guaranteed endpoint for a project. Instead you gave a reasonable, high level view that you promised to refine every time you got real-time performance results from your team. You would then narrow your view over time as you iteratively gained traction delivering real, working software. At each point of actual data, you would update your release plan / model and re-communicate to stakeholders where things actually stood in relation to their expectations and your previous views.

If you were behind schedule, stakeholders had the option of dropping, reducing, or re-framing scope based on business value and priority. But in order to hold to a date, they would have to adjust something. If you were ahead of schedule, a not so rare event, they could pull in more value-based scope and deliver more than anticipated.

High Level – Release Planning

The methods don’t spend a lot of time estimating in excruciating detail at the high level. Instead you estimate work (usually expressed as User Stories) in generic level of effort/complexity units (usually expressed as Story Points) so that you can plan the number of stories you can fit into a series of sprints to meet a content commitment for your stakeholder.

Remember, release planning isn’t a firm commitment. Nor is it exhaustive, detailed planning. It’s a best guess, high level view to packing work into iteration sized time-boxes. However, there’s a missing point to accurately planning a release. What you might ask?

It’s the teams’ own velocity. Put another way, the teams’ ability to execute and deliver fully done stories within your iteration time-box. The first time your team actually delivers work from a 2-week sprint you have a wonderful data point—actual team velocity! Please don’t undervalue it.

Low Level – Sprint Planning

But I got a bit ahead of myself.

In the agile methods, where does the team dig into the details? Refining tasks, looking at dependencies, breaking things down into smaller, quantified (hourly) units of real work to be completed? They do that on an iteration (Sprint) by iteration basis—grabbing a small “chunk” of the work, always the highest priority and most urgent work, and breaking it down for the very next Sprint.

If you ever get the chance to attend a proper Sprint Planning session, you’ll have transparent access into a software team breaking down work into very small tasks. You’ll begin to understand all of the complexity and nuance for each story. You’ll hear the testers challenging the developers on testability and how challenging this piece of code will be to test—which will add more tasks for testing and quality.

If the team feels a more detailed design is required, you’ll hear them discuss it. How much? Who should be a part of it? And what does the review look like? Etc.

In general, you’ll experience all of the complex gory details of software development—the real work involved for a single sprint. Then they’ll do something wonderful. They’ll commit to the work and deliver what they can (fully done) at the end of the sprint. You’ll now have an actual data point for the teams’ capacity that you can compare and contrast against the overall release plan—with full transparency into the plans and details and with no extra padding allowed.

How cool is that?

Wrapping Up

I do quite a bit of sharing on agile methods nowadays—via presentations, formal training, and coaching. Believe it or not, I often get challenged on some critical aspects or techniques surrounding agile. None more than the point being made here.

The challenge goes – “There’s no way my boss will put up with a non-committed date for a project” or a “We’ll know how long it will take when we see it” approach to project estimation will not work in my company because we live in the “real world”.

My counter then is usually the same—“Fine, do what you’ve always done”. Try to predict the future on a highly complex software project without doing any real development. If you can guess correctly, then great—stick with your practices.

BUT, if you notice that you often fail. And by often I mean 50%, 60%, 70% or even 80% of the time to successfully meet your stakeholders expectations, THEN you’re practices are clearly not working for you. 

Admit that and try something a bit different. Agile Project Managers make the above approach work every day in a wide variety of business, customer, and technology contexts. It’s no longer a bleeding edge technique! It simply drives more real-time transparency into project progress. It helps with adjustment based decision-making. And it leads to more collaborative and successful outcomes.

From my perspective, if your methods aren’t working that well for you then what do you have to lose? So, what DO you have to lose?

Don’t forget to leave your comments below

 

Last month’s blog was the first in a series about organizational readiness-ready, that is, to provide resources necessary to succeed in an agile environment. We asked these four questions on our Agile organizational readiness checklist:

1. Will your organization provide a dedicated product owner for each scrum team?
2. Will your organization provide dedicated team members?
3. Does your organization support time-boxing each iteration?
4. Does your organizational culture support just-in-time requirements?
   
   

This month we’re going to look at Agile organizational readiness from the perspective of false expectations for some organizations that have decided to implement Agile methods.

Does your organization support “cowboy” development?

Some organizations adopt what they call an “agile methodology” as an excuse to eliminate discipline, commitment, and ownership. They have the mistaken belief that a lack of discipline equates to getting the work completed sooner. In some organizations senior leadership decides to adopt “Agile” without understanding what it entails and the commitment that is required to make it work effectively. The term “Agile” becomes an excuse for adopting a chaotic, free-for-all environment. Management in these organizations can boast that they’re “doing Agile,” but might not be aware of the frustration such a chaotic environment causes the team.

Does your organization expect that eliminating the role of the BA will eliminate documentation?

I have heard organizational leaders say something to the effect of “we’re going Agile so we no longer need a business analyst” or “don’t put a BA on this Agile project. BAs will just produce a mountain of unnecessary documentation.” They see business analysis as unnecessary work and the BA as a role whose only goal is to produce a massive requirements specification at the end of one long business analysis phase. In reality, the business analyst is a kind of management consultant, someone who acts “as a liaison among stakeholders ..to recommend solutions that enable organizations to reach their goals” (BABOK Guide ® Version 2.0. As wonderfully articulated by Kevin Brennan of the IIBA, organizations which undertake Agile projects still need help understanding their underlying business problems and figuring out the best ways to solve them. They still need projects to help them solve those problems. And they still need a role that will focus on the requirements of the end product (solution), ensuring that the end result of the project provides the expected business value. In other words, the role of the BA is not to produce documentation, but to help ensure that the end product and its associated requirements help the organization reach its goals. In that capacity, every BA is obligated to produce documentation as appropriate to the project at hand.

Does your organizations have realistic expectations of the Scrum Master?

• Does your organization expect the technical team “leader?” to be the Scrum Master, providing technical expertise and direction to the delivery team? Having any formal lead role on the Scrum project is problematic. When teams are truly self-organizing as ideally they are on Scrum teams, leaders emerge, rather than being designated. In addition, any time that the Scrum Master spends focused on the technical aspects of the project and directing the delivery team is time not being spent on facilitating, removing roadblocks, calculating the resource capacity and burn down rate, and generally doing the work that Scrum Masters need to do. There is a reason why on some Agile projects the role is called “coach,” not leader. Finally, the Scrum Master who works as the technical lead is at risk of providing a more a technical rather than a business solution.
• Does your organization expect the Product Owner to be the Scrum Master? The Product Owner (PO) is a critical role on an Agile project. It represents the business, making the business decisions required to move forward developing the end product. Last month we addressed the importance of having organizational commitment for a full-time PO because it is a full-time position. When the Scrum Master is doing PO work, the Scrum Master work is not getting done. And the decisions made run the risk of ignoring important technical considerations.
• Does your organization expect the Scrum Master to play other roles such as business analyst? I attended a presentation recently promoting the idea of BA as Scrum Master. The central theme of the presentation was that because both Scrum Masters and business analysts are facilitators, the BA is in the best position to be the Scrum Master. I found the premise intriguing and well-intentioned, but misguided. The facilitation that is required of a Scrum Master is different from that of a BA. The former focuses on facilitating the team and its ceremonies, the latter facilitating requirements workshops among subject matter experts. And there is vastly more to both roles. It’s almost like saying that because an insurance agent, a bank teller, and a city ombudsman all interface with customers, that one could easily step into any of the other roles.
• Does your organization expect the Scrum Master to play multiple roles? All but the smallest Agile projects deserve full-time Scrum Masters. Organizations which believe that they can get by “on the cheap” by combining roles on Agile projects may well suffer disappointment in the results that get produced. As on any other project, each will suffer.

There are many more areas that we could cover, but we’ll leave it for now in the hopes that you’ll add your own ideas and experiences to the topic.

Don’t forget to leave your comments below

I can’t say how many times I have heard software practitioners talk about the Triple Constraints of Scope, Time/Schedule, and Cost as a triangle and suggest mental games of adjusting one and fixing the other two. Often you see quality as a fourth constraint that is dependent on the other three, which is very true.

In my traditional project experience, stakeholders try to fix all three constraints—dictatorially fix them. This inevitably leaves quality as the only variable. And as teams flex on quality, the trade-offs are often hidden from the business until after the software is deployed.

From an agile perspective, we want to turn this pyramid on its side. We want to fix cost with a relatively stable and well-defined team dynamic. We want to fix time/schedule by releasing in well-defined and measured time-boxes or sprints. We also want to fix quality in that we don’t short-shrift it in our efforts to deliver quickly. So what does that truly leave as a variable? Clearly scope!

Agile project managers are continuously focusing on two key dynamics:

• Maintaining a quality focus with their team so that no feature leaves the line as undone or with known defects
• Passionately varying scope with their business partners—while always looking to deliver a high value and minimal marketable feature

It’s holding to this modification in the triangle that differentiates agile projects and agile project managers. Let’s explore some of the aspects of quality in more detail so that you can understand and refine the role the agile project manager fills in team quality activity and decision-making.

What Do I Mean by Quality?

First of all, it’s not simply testing. You don’t test in quality, you build it in. Quality and testing practitioners have been telling us that for many years. We simply haven’t been listening. So part of the focus is on testing practices—applying different approaches in context and doing plenty of risk-based testing with the entire team and the customer fully engaged in the decision-making around what to test, when and how much.

I could go on forever explaining some of the many test techniques that great agile testers leverage while performing testing. But there are some other practices, outside of testing, that truly influence the teams’ thinking when to come to quality work. The following four come to mind as important practices for the agile team and project anager

1. Holding/Stopping the Line

One of the key aspects of agile quality is fostering an environment where the team is detecting quality issues, faults, bugs, missed steps, etc. very quickly. So you have some very tight feedback loops, reinforced by the iterations themselves, from a quality perspective. But beyond simple detection, what’s important is what you do with the events.

Lean thinking tells us that allowing these defects to escape and cumulate is the wrong approach. Instead you want any member of the team to be able to “Stop the Line” and make a repair right there—before things get worse replicate. From an agile project manager perspective, you’ll want to look for and embrace these events as quality focused learning’s that will enable the team to improve.

Trust me, it usually feels counterintuitive to stop the team and work to fix a system problem when the project pressure is on. But the repair and more importantly the message this sends to the team—that you care about quality work efforts is, according to American Express, priceless!

2. Encouraging Pairing and Code Reviews

One of the key practices of agile development is the notion of pair-programming or informal code reviews. It came out of the Extreme Programming space. I remember when I first implemented XP in 2001 at Lucent. I read Kent Beck’s book and took everything way too literally. Pair programming was one of those. I was a Software Director at the time leading the effort to move towards XP. I directed that all team members adhere to ALL XP practices immediately—including pair Programming.

What a disaster! I recall about 40% of my programming staff threatening to resign over this edict. I think the words were along the lines “over my cold dead hands” . An effective agile project manager encourages pairing when it makes sense and tries to broaden the notion towards a whole-team view—meaning any and all pairings are helpful.

Another focus is on review and inspection, of code, documents, test cases, everything! Don’t think of these as traditional and formal inspections. Instead foster an environment of transparent and informal team inspections, were all artifacts are examined for quality and value. An environment where feedback is welcome and immediately acted upon.

3. Don’t Forget Planning

We’ve all heard that old expression that you get what you plan for. Many think that there is minimal to no planning within the agile methods, but nothing could be further from the truth. The planning however usually stays at a higher level—with the details being explored on an iteration by iteration basis.

That being said, sprint planning should receive a strong focus on quality attributes. For each user story or work item the team will be taking on, all of the work should be broken out into tasks and the overall team, not just the testers, are responsible for the quality of the delivered story. It’s important to explore the functional requirements as well as the non-functional (performance, security, reliability, usability, etc.) requirements when fleshing out ALL of the work.

The agile project manager can have a strong influence on quality simply by guiding their teams towards more complete thinking when it comes to story quality and more complete Sprint Planning.

4. Clear Notion of Done! with NO Partial Credit

A common quality practice within agile teams is defining doneness criteria for the teams’ work. This helps the team to understand their internal and external expectations with respect to quality and professionalism in developing project software. Quite often the doneness takes on different levels along the following lines:

• Work doneness: focuses on the quality of individual work products at the developer, tester, BA, etc. level. For example: It defines coding standards and check-in practices for the individual developer.
• Story doneness: focuses on the individual User Story. Usually each story has “acceptance tests” run against them for approval. Minimally these would be run and pass. However, often there are other levels of testing that is required to be completed.
• Sprint doneness: focuses on the results that the team committed to as part of their Sprint Planning. And determining if they have achieved their Sprint Goal and delivered a cohesive set of high quality stories for their customer.

But in all of these cases, the result is the same. The team only gains credit for the work if it passes the appropriate levels of doneness. If not, they are held accountable to cleaning things up and meeting their own quality agreements. Think of it as the best of earned value—in that you only gain credit for “working software”.

Wrapping Up

Experienced agile project managers have learned the hard way that quality is the Prime Directive for software projects. Learned that all of the dimensions of the triple constraint need attention, but not at the expense of quality. In fact, within agile they powerfully realize that now Scope is the target.

That varying it in small and large quantities based on business priority, but under all circumstances—varying it. That this is the single lever to be used in making meaningful and pragmatic project adjustments. And that these adjustments are always vetted and driven by the stakeholders & customers.

Don’t forget to leave your comments below

---