Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Agile Today: An Interview with Jim Highsmith
|
Q. Let’s start off with an update on you. We all know about your involvement with the Agile Manifesto a decade ago. Could you bring us up to speed on how you feel Agile has evolved and your current focus within the space? There are three areas that I think have evolved over the last 10 years or are evolving now. 1. A move from Project Team to Organizations. The first is a change in who drives these efforts from project teams to organizations. During the first 4-5 years things were project team oriented. Someone within an organization, usually with permission, would conduct a Agile “rogue project” really on a team-by-team basis. In the last 4-5 five years you have, CIOs, CTOs, Directors of Product Development, VPs of Engineering – those kinds of people –saying “we want to transform major parts of our organization” and making [Agile] more of a combination of bottom up and top down. All of this with much larger organizations getting into Agile over the last five years.
2. A move from engineering and team practices to management practices. In parallel, we’re seeing a move from engineering, engineering practices and team practices to something that is more focused on management and management practices. This is something that is really just getting underway in the last few years, where management and executives have taken a look at this and said, “What do we need to do to make our organizations more Agile?” (as opposed to just making our software engineering practices more Agile) This sort of change from an engineering to a management focus is further demonstrated by the Project Management Institute getting into Agile and Agile certification; not everyone in the Agile community is happy with this, but at least it shows that there is a lot of interest within the project management community as well as within the technical community. 3. A move from Agile development to continuous innovation.The last thing that I would talk about is Agile Development moving from strictly development to continuous delivery and deployment. So your software, in addition to being developed on a short cycle, is being released on a very short cycle in those situations where it makes the most sense. So you have a situation where you are automating that last mile. On the front end of that, the exploratory or discovery phase, the lean startup movement has provided some practices and philosophy around getting starting faster with product inception and product requirements. Agile development to continuous innovation. I’ve been focused on the management side of these changes, which I call adaptive leadership:
Q. Could you expand a bit on what it means to be Agile? In fact, I just wrote a blog posting yesterday entitled “What is Agility?”. To me there are two aspects of Agility: 1. The ability to create or respond to change in order to profit in a turbulent business environment. So it’s not just responding to change, but the ability to create change in innovative ways to challenge competitors. 2. The ability to balance flexibility and stability. A lot of people think that agility promotes sort of a lack of structure. But really, if you don't have any structure at all you just kind of go off into chaos. So you really do need structure. The really critical management capability here is to decide how much structure you need and balancing that with the flexibility that you need to respond to the marketplace. Traditional approaches have come down on the side of more structure, more process and more standards, and have really restricted our ability to innovate because we don't have that flexibility, adaptability and learning ability that we need to be competitive.
Q. When trying to understand the limits of Agile practices, most people focus on project size. Yet you talk more about complexity and uncertainty, which are related but not as easy to get your head around. Generally speaking, what is the best way for practitioners to think about these two attributes of programs and projects and how each of them should affect their approach? Any thoughts on this specific to planning? I think that there’s sort of a myth in the community around project size. Part of this comes from the early Agile work that focused more on small teams and small projects. So the idea was that Agile worked well on small projects, but didn’t scale well to larger projects – but there are plenty of examples now of Agile working well in very large projects and large organizations. You should really think about this is terms of a few key questions that Agile helps answer:
So there are a lot of reasons that we want to be able to apply Agile as we scale. So we want to scale Agile, but what are some of the things that we need to do to make that happen? That’s where complexity and uncertainty come into play. Complexity and uncertainty are two dimensions that we need to think about. The complexity dimension is the one that we are most familiar with; team size, distribution, domain knowledge, computational complexity all play into overall complexity. Common uncertainty factors can include the newness of the technology you are using, business and marketing uncertainty, new/emerging product requirements. You can have any combination of high and low complexity and uncertainty on any given project, but the general strategy for scaling projects are as follows:
Obviously, the more difficult projects are the ones that have high complexity and high uncertainty. With those kinds of projects you usually have a smaller subset with high uncertainty that you can deal with separately. I think the real message here is that you have to adapt and use some more traditional strategies and some Agile strategies as appropriate. Often you end up using an Agile strategy overall and incorporate traditional elements into it as needed.
Q. A key challenge for organizations that we often hear about is marrying Agile projects with more traditional Project Portfolio Management efforts. The clear goal is to gain the benefits of Agile approaches while attempting to maximize and manage return on investment. Do you have any thoughts, guidance or best practices that you could share in this area? I think in terms of exploration (certainty) factors with my projects along two dimensions: technology and requirements. If the technology is very familiar to me, the technology exploration factor is low. If the technology is new, the exploration factor is high. The same is true for the project’s requirements. If I have an exploration factor 10 project, things are pretty uncertain. If I’m dealing with a factor of 1, things are pretty certain. Most PPM approaches standardize/homogenize projects, making them seem equally predictable – which doesn't make any sense. For example, to expect predictability within +/-10% of time or cost on a exploration factor 10 project just isn’t reasonable. So we need to change governance structures and govern different types of projects based on different criteria. With projects that have a low exploration factor, we can use more traditional portfolio measures like scope, schedule and cost. With higher exploration factor projects, we have to ask:
Then the other things like cost and scope become constraints – not drivers. So you have to either run two different types of portfolio management systems or one governance process that combines both traditional systems and Agile. One of the things that I’ve seen lately is continuous monitoring and management of the portfolio, using sort of a Kanban approach. It’s very similar to a traditional approach in some ways, but all of the actions are continuous.
Q. Uncertainty is something that every company is dealing with today. It’s a key concern for every executive. Moving Agile up the food chain, are there steps that can be taken to make a traditional PPM process more adaptive and perhaps more effective that are usually well received by the executive team? Are there ways of coaching executives to make them more Agile-friendly and ultimately more effective in a world that is filled with uncertainty? The transition is more a management transition than it is a project or portfolio management transition. There is more of a realization now that managers themselves need to learn to be more adaptive. In the past, we’ve seen the attitude that the development teams need to be more Agile and adaptive, but managers thought, “It doesn't really impact me.” I think people are struggling with changes in the marketplace. For example, Amazon fought for years against applying state taxes to Internet sales. Now they’ve changed strategies entirely because they are moving toward same-day delivery. That’s an industry-wide disruption and an example of management thinking in a more Agile way. So that’s how the mindset changes. The “doing” side of it really involves creating a continuous stream of value:
The “being” side of that (management behaviors) has to do with creating an innovative culture:
With a plan-do mindset, I plan out everything that I want to do – then I do it. With an envision-explore mindset, I envision where I want to go and how I might get there. With envision-explore, I'm creating an innovative culture. With plan-do, you’re really not. So in terms of dealing with uncertainty, the things that I just talked about help you deliver a continuous stream of value, while creating an innovative culture.
Q. Following the theme of uncertainty, what are your thoughts on planning in an uncertain environment? I think planning is definitely something you do, but really you’re “speculating”. In my book, I actually replace the word “planning” with “speculating”, because that’s what you’re really doing in a highly uncertain environment. When a lot of people think about planning, they think about a Microsoft Project plan with 6,000 tasks and someone is going through and checking them off as they are completed. I think that kind of plan isn’t really appropriate in a rapidly changing environment. What is appropriate is a higher level of planning where you are dealing with shorter periods of time and you’re dealing with larger chunks of work. Again, you would plan an exploration factor 10 project differently than you would plan an exploration factor 5 project. If it’s a 10, you might just run an iteration at a time with a broad goal in mind and a few constraints – then run a series of experimentations on it until you figure out what it's all about. With a 5, you might be able to lay out a reasonably detailed plan for three or six months. Another key difference between traditional an Agile planning is what you are actually tracking. Traditional planning tends to be task or activity based. In Agile planning, you are doing a product breakdown. So you’re tracking pieces of the product that have value to the customer versus activities where their value is less clear.
Q. Organizational effectiveness has also been a popular theme in recent years. At various levels you see Agile, Lean and even Six Sigma playing roles in helping organizations produce more with less. Do you see these disciplines becoming more integrated or even somewhat merging at some point in the future? How do you see them complementing or detracting from one another? The ones that I see complementing each other are more the Agile and Lean – particularly the Lean startup movement. The idea of doing less and focusing on high-value stuff is really a complement to Agile. I haven’t had as much experience with Six Sigma, but it’s more about operational efficiency. There may be places where you want to be more operationally efficient. Then it’s a matter of creating a balance. Organizations have to think about:
Q. Organizational effectiveness often means standardization. Many large organizations struggle to "standardize" their teams. What are your thoughts on this type of standardization? I think it depends on whether your focal point is responsiveness or efficiency. If your focus is on becoming more efficient, then standardization probably helps with that. Unfortunately, that drive toward standardization often operates against the ability to be more adaptable, flexible or responsive. The more standard you get, the less flexibility you have. In many large organizations, this drive to be standard encompasses too many things. There may be some areas where standardization is appropriate, but “teams” is not one of them. You need diversity and a set of guidelines, but not much in terms of standardization.
Q. Customer value is obviously critical, but maximizing it sometimes feels in conflict with getting things done. If you had one piece of advice for those trying to maximize value in a tough environment, what would that be? I would go back to two of the four things that I think adaptive leaders need to do:
One of the things traditional approaches assume is that you’re successful if you’ve delivered all of the scope in whatever you’ve defined. There have been studies that say that 60% of all software developed is rarely or never used. So the measure really needs to be, “Have I delivered value to the customer today?” not “Have I delivered everything in scope?” Then you might ask the question, “What offers value now?” Then you can grow that value over time. So the Lean idea of doing more with less, combined with an Agile approach, really produces more meaningful results. |
Posted on: August 15, 2012 11:15 AM
| Permalink |
Comments (3)
Have You Outgrown Basecamp?
| Situation: You need a few more features in your PM software.
Q. Basecamp is a terrific, inexpensive starting point for many. However, at some point most organizations grow out of it. Can you talk a bit about the triggers that prompt users to start looking at more capable products?Yes. We think of the market for portfolio and project management solutions as having three basic tiers: the low end tools, mid-market solutions and high end systems. Basecamp is a great low end tool that offers collaboration and task management in a web-based application. High end systems are those designed for very mature project teams. They are more involved in terms of implementation timeline, more expensive and, in general, designed for more ‘top-down’ organizational cultures. Microsoft Project Server is a good example of such a system. Mid-market project solutions are more robust than the low end, but not as overwhelming as the high end systems. Project Insight is one example of project software that is robust enough for experienced project managers, yet easy for team members to adopt. We talk to a lot of people that have started to manage tasks and collaborate in Basecamp. They like the alerts and the ability to see the tasks they are to work on. However, as you say, many project teams outgrow this tool. The initial trigger points that prompt teams to look at mid-market portfolio and project management solutions include the need for: -Intelligent scheduling -Gantt charts What do I mean by intelligent scheduling? This is the need for something more than a simple task manager. As teams hire more professional project managers, they find they need the ability to link tasks together using dependencies. While some low end tools have the notion, not even all mid-market solutions have the MSP-like dependencies and constraints that more experienced project managers are familiar with. In many cases, the more experienced project manager has utilized MS Project desktop and wants task dependencies, constraints and splits. At the same time, the organizations we help talk about having project managers of mixed experience levels, so they also want the newer project managers to be able to create projects from templates. Gantt charts, of course, provide a visual view of one’s project and task flow. As projects get more complex, there’s nothing like being able to see the tasks on the critical path. Basecamp and other low end tools do not concern themselves with something as esoteric as a critical path or a baseline.
Q. There are always the problems you see and opportunities that you don't. Can you talk a bit about capabilities that most of these organizations could use that they are not looking for right away? What sort of quantifiable impact could these functions have?Sure. When teams finally get their hands on a product that performs intelligent scheduling and they have set up some project templates, they often feel that sense of relief. So, what’s next? At this point, they can benefit from resource allocation views and portfolio reports. If you are only looking at a bunch of tasks that are unrelated, it makes it impossible to shift schedules easily. It also makes it challenging to truly understand what people are working on and when. Demand management, capacity planning, resource allocation…no matter what you call it, as project teams become more successful, they need a way to see what everyone is working on and when. Because growing organizations are successful, they often have the business challenge of not knowing if and when they can deliver a project on time. Proper resource views in mid-market resource management solutions are needed when organizations hit these levels of success. As for the quantifiable measurements of the benefits of resource balancing and proper allocation, that is probably the ‘holy grail’ most PPM vendors are looking for. If it were easy to find an ROI measurement that every organization could utilize, then our lives would be much, much simpler. As far as I know, no vendor can offer up a simple ROI calculator that is applicable to most organizations. That said, I can offer you some anecdotes from customers that lead us toward impacts. For example, one organization had a team of high powered software developers that he was losing. They were leaving for ‘greener pastures’ because the organization was constantly working late on their client deliverables. They would have a 600 pound gorilla customer call in and then everyone would work a fire drill. All of this due to not being able to see the planned work and allocate it properly. Once they implemented Project Insight, they began to plan every team members’ work two weeks ahead. Once that was mastered, they began looking out a quarter and forecasting. The customer found that his attrition rate of his specialized resources was lower. Why? Because people could plan their lives. They went from working 80 hours per week to 40-50 hours per week. The employees were happier and remained with the company. Last, but certainly not least, executives want a simple way to oversee all the projects in their portfolio. Low end tools do not always concern themselves with the needs of project managers or executives. Basecamp and others are more focused on team member needs, sacrificing other levels of the team. Now this functional set is probably easier to quantify. We often hear of project managers spending a certain number of hours aggregating information for executive reports, and then someone else spend another set of hours formatting these reports. That is more easily quantified and can often, in itself, bring in the ROI for a mid-market solution.
Q. Are there staffing considerations when making this sort of (upgrade from Basecamp) move? Should you not take it on unless you have a specific set of skills and competencies in house?Yes, that’s probably true. If an organization does not have anyone that understands task dependencies, or is willing to learn about the power of intelligent scheduling, then it is probably not wise to upgrade as of yet. It seems that Basecamp appeals to organizations that are small and work with a lot of sub-contractors or freelancers, for example, tiny ad agencies that extend their workforce with subs. In these cases, it is probably overkill for them to worry about anything in the mid-market.
Q. At the other end of the spectrum from Basecamp, there are very high-end complex tools to manage project portfolios. These are often six figure investments. At what point do you need to start looking at these?There are many organizations that are ready for a high end system. They have certain characteristics to be sure. For example, I attended a PMI chapter even with a Microsoft Project Server consultant as the guest speaker. He was firm and clear when he said, “Don’t even try to implement this unless your organization has a CMM ranking of 3.5 or better.” I would say that is probably good advice for any organization. Do not embark upon a high end system until you are mature enough to benefit from that system. In May, at the Gartner conference, it was said that a solution like Clarity takes at least six months to configure, so you need to be at the stage where your team can dedicate the resources to analyze the business processes and spend that time configuring the system. A couple of good examples of companies that use high end systems are Proctor & Gamble and Boeing. P&G has literally 1000s of products and tens of thousands of opportunities for improving these products, or launching new products. They have an entire department that analyzes the risk of each potential program and project. These opportunities are mapped onto a bubble chart and the like. The team has the resources to review the project/idea intake process, and analyze, and quantify well in advance. Many of our customers do not have the luxury of an entire risk management department. Thank goodness Boeing and other airline manufacturers have mature processes, as our lives depend on it. The type of business requires stringent adherence to standards and processes in order to develop and manufacture their products.
Q. Project Insight has an established migration path from Basecamp. Can you talk a bit about the data that is migrated over, how it's used, and where the gaps are?Yes, as we upgrade lots of teams from Basecamp, we’ve developed a data migration for these customers so they can have their historical information available to them. We map the following fields:
The gaps are the features that Basecamp does not offer like dependencies. So, if the project is in progress, and migrated into Project Insight, then the project manager needs to relate those tasks or just adjust each task manually. We did not migrate files, but one may simply use multiple file upload to pull the files into Project Insight. Everything else is good to go. |
Posted on: July 26, 2012 05:11 PM
| Permalink |
Comments (0)
Time To Move PPM To The Cloud?
| Situation: You think "the cloud" could be a solution for you, but you're still not sure...
Q. When you talk about faster and less costly Project Server Deployments online, what's really driving the speed of implementation and cost savings? What are you giving up in return for those advantages when you compare it to a more traditional implementation? A. Hosted deployments lead to faster implementations by avoiding three main roadblocks commonly encountered in onsite deployments: i) procurement delays in acquiring new hardware (or software), ii) delays to approve software for deployment (often requiring IT to have the training to support it), and iii) security delays in granting consultants the access they need to configure a solution. By avoiding these delays, online environments become operational more quickly, saving money through more effective and efficient project and portfolio management. Online environments also save money by allowing customers to only pay for what they need – starting small and scaling as needed. The main things that customers give up in an online PPM environment are i) data being inside their corporate firewall, ii) integration to their onsite Exchange server, and iii) automatic corporate authentication. Some organizations will not consider online services in the first place, simple because their data would reside outside their firewall. But many organizations are OK with hosted project management information as long as the hosting provider has the correct security certifications (e.g. SAS70, ISO 27001, PCI). Although email alerts from Project Server and SharePoint work from online services, the Exchange integration that allows a user to update Project Server tasks from within Outlook does not work when connecting online PPM to onsite Exchange. Although it is possible to integrate online authentication with a customer’s corporate Active Directory, it does involve some customer IT work and is not automatic like in an onsite deployment.
Q. When do you have issues with security in the cloud? How do you ensure your PPM data in the cloud is secure? A. Security is (and should be) the number one concern of most cloud customers. Many customers have their own checklists, assessments, or surveys that ask all the questions they need answered to ensure the safety of their data. Others use standard checklists like those for ISO 27001 or FISMA (Federal IT standards). It is important to make sure that a cloud service provider has had their security audited by a third party and to be able to see the results. Some customers will even perform their own audits, which may include penetration testing (ethical hacking) and other verification techniques.
Q. What do you give up in terms of customization with a cloud based solution vs one onsite? Can you give some examples? A. If the cloud based solution is restricted to shared servers, then there are typically quite a few restrictions on customizations: One typically cannot add 3rd-party applications or custom webparts, and it may not even be possible to develop custom workflow or certain types of BI reports. If the cloud based solution involves dedicated servers, then the above-mentioned customizations are possible, but there may still be limitations with integrations to onsite resources where the integration requires everything to be in the same domain (e.g. Exchange integration to Project Server).
Q. What are the licensing challenges that you need to be aware of as you integrate your PPM cloud implementation with all of the other MS applications that are present in most organizations? A. If a customer provides their own licenses for a cloud solution (to reduce hosting fees), the customer will need to remember to account for those licenses along with their onsite licenses when they do periodic licensing “true-ups” with Microsoft. |
Posted on: March 07, 2012 06:29 PM
| Permalink |
Comments (1)
Do You Need a Project Management Survival Plan?
| Situation: You need a fresh perspective on Project Management in general.
Dave: How did you come up with the idea of applying survival principles to project management? Surviving is about achieving a minimum threshold –presumably in a difficult environment. Are you taking a project view that says, "achieve the stated goal and no more?" (I.e. - stay entirely within scope) Steve: A key to surviving many of life’s situations involves mental toughness. Essentially, knowing how to think through a problem and develop action plans. If you think about your project as a survival mission in which it’s your responsibility to save and lead members of your team to safety, you may change your approach to managing your projects. You may start to understand your team members better: their strengths, weaknesses, and the environment in which they perform best. You may also have a new sense of urgency considering what’s on the line. Many times on survival missions you only have one shot to get it right. You could say the same thing about planning and managing a project. If you don’t get it right up front, you may find yourself and the team in front of the CEO explaining the failure, missing customer expectations, and hurting your career. With the role of the project manager, there’s a lot at stake and no room to take chances. Corporations are counting on project managers more than ever. Dave, the view I am taking is that project managers, especially those involved with developing new and innovative products, must be mentally tough! Project Managers must mentally train themselves to think through alternatives before tackling any of them. As critical situations develop during a project, the project manager needs to physically stop and think to consider all their options. Next, they need to observe their environment and consult with their team members to determine the best plan of action - thinking through how the plan is going to be accomplished. A project manager must also know when to recommend stopping the project. Stopping isn’t something a lot of organizations do well. In a recent study, the Accept Corporation and the Association for International Product Marketing and Management (AIPMM) found that more than 60 percent of executives say they struggle making kill/ go decisions. There is a tendency to continue projects and activities even when most people involved realize it’s not an optimal use of their time. The S.T.O.P. principles were designed to ensure that critical thinking occurs in high pressure situations (sound familiar?). I have taken those same principles and constructed a framework for project management. Giving the project manager guidance and direction on what that minimum threshold should be for being successful if their project is viable – and if it’s not viable, then what it takes to stop it!
Dave: When we thing of managing scope, schedule, and cost we are really balancing those things against on another in many ways. In your version of the triangle, do you see project managers needing to balance value, team performance, and communication? How does that work? Steve: If project management is to survive as a profession, then we as project managers need to realize that our job is more than just managing scope, schedule, and cost – it’s about delivering value. The iron triangle still exists; don’t get me wrong. But to truly be effective as a project manager I believe a new triangle must emerge. A triangle based on managing value, team performance, and communication. I developed equations in the book to help identify and quantify the variables where more focus and management need to be applied on our projects. Let me give an example on how this works in regards to determining and managing project value: You’re raised as a project manager with a visual implanted in your head of a triangle that flexes and constrains as you move through your project. You force your sponsors to make decisions and tradeoffs against the three (scope, schedule, and cost), but based on what? The answer should be value. When creating, developing, and delivering a product to the market, you seek to maximize its value. You want to maximize the customer benefit and experience while maximizing the return on investment. When you adjust your perspective around the triangle like this, you realize it’s more of an equation based on deriving value. I call this the project management value equation. It’s designed to give context to “scope, schedule, and cost,” ensuring that you’re weighing all that you do against the overall value of the project and keeping your sponsor and team focused on the prize. Said another way, it’s an equation meant to quantify and assess the value of a project and identify — if value has been decreased — whether the project should be stopped. The equation is the following: Value = Scope ÷ (Schedule + Cost) By understanding this concept, you bring more depth and meaning to what you really need your sponsors to trade off against. By assigning a value to each of your success criterion, you in essence are quantifying the value of the project. Increases to schedule and cost will decrease the value of the project if more scope is not being delivered to offset it. Ensure that your scale for scope, schedule, and cost are the same. Assigning either a percentage value or using a 1–10 scale can work if each variable is quantified consistently. The idea is that, at the start of the project, as you determine its overall value, it should equal 100 percent. As tradeoffs are made between each of the three variables, the project value will change. Together with your sponsor, determine what the threshold value is for stopping your project.
Dave: Can you give us your top 3 tips for understanding and creating value on projects? Which tools do you apply and why are they important? Steve: You bet, they are the following:
Dave: Can you give us your top 3 tips for managing team performance on projects? Which tools do you apply and why are they important? Steve:
Dave: Can you give us your top 3 tips for ensuring effective communication on projects? Which tools do you apply and why are they important? Steve:
|
Posted on: January 10, 2012 10:49 AM
| Permalink |
Comments (0)
Do You Need a Delegation Document?
| Situation: It's unclear which decisions you can take and which ones must be escalated.
At their best, a good delegation document will:
Our version helps you record decision-making authority for the following types of decisions:
We've seen various types of delegation documents and developed our version of a template this past week (a premium template, available to all gantthead members through 1/15/2012). If you think you might find it useful, take a look at the template and tell us what you think.
|
Posted on: January 08, 2012 10:02 PM
| Permalink |
Comments (2)