Author: Robert Galen

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

 

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

---

As you may or may not know, I’m an active agile coach. While I have a wonderful day job, I often get asked to enter new teams and jump-start them or assess their overall level of agility. One of the ‘smells’ that I look for in a strong and healthy agile team is what I’ll call controlled chaos or perhaps a better phrase would be guided chaos.

You see, the atmosphere in these teams isn’t safe nor predicted too far in advance. The teams don’t have a false sense of security. They’re working on a short list of features in close collaboration with their product owner. They know that challenges will rise up to meet them. Risks will fire. Team members will get sick or get married or tend to ill parents. And the design approaches and code won’t always work as advertised.

They may or may not have the technical skills to interface with the new third party vendor they’ve just signed a partnership agreement with. They also struggle mightily to deliver software of sufficient quality—scratch that—they struggle to deliver solid software—even though they focus on it daily.

What I’m trying to say is that in these dynamic teams, “stuff” happens. The plans shift daily and the team must respond to this landscape. They must be undeterred in their commitments to sprint and release goals and to be creative and relentless in attacking impediments.  Agile project managers need to understand this chaotic reality. In fact, they need to create and foster it! Here are a few ideas on how to do that.

Don’t Ask for Specific Commitments

Imagine yourself in a canoe on a river you haven’t navigated before. You have a map, so you know generally where you’re going. You have a GPS, so you know specifically where you are. Now you get an emergency call from your boss and they want to know exactly when you’ll arrive at the take-out location. What do you say?

From my point-of-view, not very much. You simply don’t know how long it will take. You can guess and give your boss a sense of comfort or you can tell her the truth. I’m here and my hourly rate appears to be this. My map implies the following obstacles and journey length. I think I may get there between 4-5 pm.

A key here is that in highly variable and complex situations, we often don’t have a very clear idea of how long something will take. Instead, we need to triangulate to get to our destination. We’ll take daily samples of progress, looking ahead on our journey and then reducing the uncertainty as we gain knowledge, make progress, and get closer to our goal.

That’s the reality of complex systems. So the question for an effective Agile PM becomes, do you want the truth, with incremental triangulation, or a façade of absolute certainty? I think we need to emphasize the integrity of the former and support it with active team focus, high communication and collaboration, and full transparency. And leave the façade for those who can’t handle the truth.

Don’t Let the Team Plan Too Far in Advance

There a planning technique used in agile teams called release planning. You see it coming out of a few different methods with slightly different names:

• Extreme Programming – Planning Game
• Scrum & Jim Highsmith – Release Planning and Agile Project Management techniques
• Crystal – Blitz Planning
• Jeff Patton – StoryMapping

All of these techniques are driven towards gaining a high level, end-to-end view of your project—leading towards a release point. It turns out that they’re all incredibly useful for envisioning where your project is going. It’s like the map in my earlier canoe example!

The danger comes when you start doing detailed planning (tasking, dependency mapping, detailed design, etc.) too far ahead. You and the team will get a false sense of comfort, thinking you know where you’re going. But along the way there will be rapids and nasty weather that will surely knock you off course.

Trying to fully anticipate them is mostly a fool’s errand and can be very wasteful of your time. Being prepared for them and reacting quickly when you encounter them is the way to go. As an Agile PM, you’ll want to plot out a fair distance in your planning, but not too far. You’ll want to stay out of the micro-details too.

In my own teams I share a heuristic for this. It surrounds the following:

• Do end-to-end, release planning for your current release only! And complete it before 25% of your release execution has occurred.
  • Keep your User Stories mostly at an Epic level before release sequence entry, but early on refine them to well-sized user stories.
• Sprint or Iteration look-ahead:
  • Have your next 2-3 sprints (in User Stories relatively well defined – towards 80% clarity); Beyond that, they’re mostly high-level Epics.
  • Have your next release (User Stories) planned at an Epic level; when your within 1-2 sprints of your current release and beginning the next release. Within 1 sprint of the new release, start to do more granular decomposition—getting ready for your next round of Release Planning.

Always remember that backlog grooming is an iterative process that needs continuous attention. These tend to guide teams towards the right level of look-ahead and appropriate granular planning.

Don’t Write Everything Down

Here I’m speaking to requirements and other project artifacts. You’ll want to apply the 80:20 rule or Pareto Principle in both directions here. From a writing things down perspective in project artifacts, I would contend that only the most important parts of the project needs recording. Serious design elements, important bugs, retrospective results, user stories or other agile requirements, acceptance tests, are good examples of what might fall into this category.

As a heuristic, try to influence your team to record only 20% of the things that they would normally try to record. Guide them towards the more important artifacts, while trimming out the excess. You know the ones; usually driven by some process checklist or the team’s false desire to leave more legacy details than anyone will ever read.

The other rationale here is that software changes. Quickly! So information surrounding it has a very short half life and decays quickly. You’ll want to ensure that you are keeping the most important bits up-to-date and with that comes a cost.

Turning it around, another heuristic is to target 80% completeness of your user stories prior to their execution. We never want fully vetted, zero ambiguity, stories hitting our teams. Stories where everyone looks around and thinks they have a “complete understanding”. When that occurs, conversation and collaboration stops, which is the enemy of agile requirements.

In both of these situations or directions, Agile project managers take on the role of fighting for ambiguity in documentation. You should fight for terseness and for just-in-time and just-enough thinking and action within your agile teams. You want to hear lots of conversations. Heated debates around a particular feature and lots of discussion surrounding quality. Your first and second levels of documentation surround the code, the tests, and the stories. So keep you priorities focused there.

Back to Chaos

Wrapping up, healthy agile teams need to be uncomfortable, leaning into the unknown, and tense with anticipation. They need to be on the edge of chaos with just-enough clarity to get their canoe to the next segment in the river. And with an eye towards impediments and risks that might be right around the corner. In a word, they need to be agile and adaptive. Great Agile PMs continuously foster this environment within their teams, looking to stay on the hairy edge of chaos. Now doesn’t that sound like fun?

 Don’t forget to leave your comments below

---

Far too often lately I see published materials surrounding traditional and agile project management take the middle road. I see the following sorts of positions taken:

• Yes, the two approaches are different, but they’re also very much the same
• Or, Agile PM is simply a slight twist on old, tried an true techniques
• Or, they are simply a set of new tools for your tool-box
• Or some sort of chart-based comparison, exemplifying them as largely situational or context-based choices
  
  

Let me be clear. From my perspective, Traditional and Agile PM are at two grandly opposed ends of the spectrum. The techniques are widely separated. The practitioners couldn’t be more opposite in skill and approach. Even the overall goals are incredibly different. And I don’t believe you can practice both at the same time. Not, and truly be agile in your thinking and behavior.

As someone with direct experience on both sides of this chasm, I want to take a few posts and really explore the nuance of Agile Project Management. But not from some middle of the road, let’s all play together perspective. Instead from the perspective of Agile PM as something that is disruptive, different, and undeniably successful. If you’re a Traditional PM, you need to STOP what you’re doing and pay attention to the new kid in town. We’re bad, we’re brash, and we’re a killer for software projects!

So, let’s go…

Agile Project Management; First, Break a Few Eggs

In traditional software projects, far too much effort is focused towards getting the beginning well-defined and fully planned. Effort is spent towards:

• Establishing a charter
• Crafting a detailed project plan
• Refining and re-refining the Gantt chart
• Exhaustively looking at dependencies and critical paths
• Planning for every potential risk
• Estimating every task with ultra fine granularity
• And generally feeling like up-front planning drives project success…

It’s as if we think we can create a perfect snap-shot for future events. We simply ignore all of the complexity surrounding software development and software team dynamics, and prefer to pull together a hypothetical view that we think is solid and complete. That will hypothetically guide the team towards delighting their stakeholders and driving business value. Doing all that while still empowering the team to creatively solve all challenges and problems they might encounter!

I posit that in doing all of this up-front definition and focusing on “Planning”, that we miss some things that are critically important. Things that are amplified in agile projects and that, at least I for one believe, are important for ultimate project and team health.

Taking Risks

One thing I see in traditional projects is very little risk-taking. It’s as if risk is a dirty word in these projects and to be avoided at all costs. Now this presupposes that we can easily avoid or manage risk in the first place, which is sort of a fools errand in my view. All projects incur risk, so why not embrace it to some degree and leverage it to our advantage to learn things early-on and make early, better informed adjustments.

Instead of padding estimates or doing exhaustive range-based estimation or exhaustive planning, why don’t we simply pull a strawman plan together and then “go for it”? My experience suggests that these early planning views end up roughly with the same level of effort and the same space in time as the exhaustively planned variants. It’s just that the journey is so much more meaningful.

Then load up the early stages of the plan with exploratory, risk-based activities and try to use them to reduce the overall scope or level of effort for the project. Instead of implementing features in a by-rote fashion, look to leverage the risk discovery towards better 80:20 business decision-making, while understanding and driving minimal marketable feature sets.

The net-net here is to use risk to your advantage. To surface it in all it’s glory early on and then, with your business and technical partners, make adjustment decisions based on this knowledge This is exactly the approach of Agile Project Management.

Looking to Fail

Another thing we try to avoid in traditional project management is failure. We try to avoid it, hide it, or ignore it as much as possible. One terrible side-effect of this is that it creeps into the thinking and actions of every team member. Nobody tries anything new. They stay with the tried and true practices that have historically led them towards a 34.5% project success rate. Woohoo!

And when I say fail in this sense, I’m implying that we fail small, we fail early, we make quick adjustments and try again and most importantly…we fail forward! John Maxwell wrote an entire book about the concept of failing with an eye towards learning and improvement. I think this is one of the strengths of solid agile teams—that they push themselves incessantly to improve by inspecting their results and adapting towards more efficient and effective practices.

It’s this open mindedness to try new things that I admire in mature agile teams. It energizes me much more than teams’ who are simply playing it safe.

Stretching! Please Sir, May I Have Some More?

One attribute I love about agile teams is that, if they get more done in any iteration than was planned, they’ll deliver more than they committed to. Show me the last traditional project you were on when team members consistently over-delivered…and told you that they over delivered?

Instead, what usually happens is they’ll either goldplate the deliverable they’re working on to fill the allotted time or they’ll hold onto it until the point when they planned for delivery—good old Parkinson’s Law coming into play. You remember Parkinson’s Law don’t you?

Work expands so as to fill the time available for its completion.

It, and the complimentary Student Syndrome, work against you in this regard. Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment after a deadline. So call it procrastination.

The mind-set in agile teams is entirely the reverse of these patterns. Teams will constantly ask themselves the just-enough question along the way in delivering on functionality. What is the just enough design proposition, or documentation requirement, or minimal set of tests that need to be performed? Why? So that they can deliver an acceptable feature as quickly as possible, calling it complete or done, and then moving onto the next feature.

Wrap-up

There were three key notions that I explored in this initial post—aggressive risk-taking, embracing failure, and stretching to deliver more within agile teams. These are truly special attributes of successful agile teams and Agile Project Managers. Traditionalists typically struggle with or ignore them entirely. My advice to you would be, if you struggle with these characteristics, take a look at agile practices and embrace them.

In future posts, we’ll continue the views surrounding areas where agile projects are not only different, but far better. Some exploration topics might include:

1. Team-Driven Responsibility
2. Done-Ness Criteria; AKA “No Partial Credit”
3. Agile PM “is” Controlled Chaos
4. Iron Triangle be Damned – Quality is First
5. Read my Lips – No upfront Estimates!
6. Driving Value – Where’s the Beef?
7. Others that you might suggest or that I find interesting…

So hop on the bus. It should be a bumpy ride!