Tag: Agile

Agile methodologies have achieved mass market status for many different types of projects, demonstrating that they are applicable beyond their roots in technology.  Significant coverage at conferences, courses, and in online content have cemented their reputation as a best practice.  This does not imply that an organization hoping to transform itself from traditional to agile approaches can do so without facing some hurdles.  A lot has been written about the organization change management challenges associated with the transition, but here are some other road blocks to realizing the benefits from agile methods.

 1. Executing Iteratively, but Delivering Waterfall

 An attribute of agile methods is that project scope is delivered regularly over the project lifetime.  Some organizations might structure their projects into a set of iterations, but do not deliver customer usable products as an outcome of these iterations (documentation is usually not considered a true business value deliverable).  This limits a customer’s ability to refine or reprioritize remaining work items and can incur opportunity costs if the project team continues to enhance certain “in progress” deliverables which the customer might have considered good enough.  A variant on this issue is a project team that delivers frequently, but the customer insists on waiting till the end of the project instead of evaluating whether their business needs have been sufficiently met.

 2. Insufficient Involvement of the Customer

 Agile methods work best when the distance between the customer and the project team is reduced so that refining and prioritizing the work item backlog, decision making and deliverables review can occur in a timely fashion.  This can require a significant commitment of effort on the part of the customer but selling the necessity for this involvement is preferable to accepting the risks associated with compromises such as having a project team member act as a proxy for the real customer.

 3. Multitasking Impacts both Velocity and Team Cohesion

 Excessive multi-tasking hurts projects, regardless of their delivery approach.  However, it can be lethal for agile projects as the context switching and knowledge gaps that result will reduce productivity, introduce quality issues and make it difficult to predictably calculate or use delivery velocity.  These outcomes can cause organizations to lose faith in their agile initiatives and revert to more traditional approaches without understanding that the issue is not one of methodology

4. Agile does not Imply “just do it”

 Contradictory to the manager’s doctrine from this Dilbert cartoon (http://www.dilbert.com/fast/2007-11-26/), planning is not wholly replaced by execution in agile projects.  While the depth of planning is inversely related to the “nearness” of an activity or decision, a lack of pragmatic, right-sized planning will result in chaos for any project.  This is a part of the agile transition change management process – learning to strike the right balance between too much and too little planning.

Adopting agile approaches can be a positive step towards increasing business value realization and project throughput, but ignoring the potholes along the journey will give your transformation initiative a flat tire!

Lately I’ve been getting questions from Agile seminar participants about how to apply Scrum to “real life,” as though these methods are “good in theory, but not at my company!” Some organizations may not be ready to adopt agile methods completely, so I encourage students to take an organizational readiness self-assessment to see if Agile in general and Scrum in particular is right for them. The questions on the self-assessment can be used to begin conversations as a way to raise issues that need to be resolved in organizations thinking about adopting Scrum.

Will your organization provide a dedicated product owner for each scrum team?

A key role on a Scrum effort is the product owner (PO). This is the role that represents the business community, particularly the project sponsor (sometimes called business owner or the stakeholder), and therefore is tasked with answering the business questions and making the business decisions. This is the go-to person for the requirements, for answers to the team’s questions about the features and functions that the business wants out of the end product. This is also the role that prioritizes the items on the product backlog. It seems to me that in the heat of the iteration or sprint, the team needs immediate access to the person making the business decisions. In order to complete the sprint in a short time-frame, such as two weeks, the team cannot wait for the PO to get back to them at their convenience. They cannot wait for the PO to check with other SMEs to come to consensus. The team needs immediate answers. Having a dedicated PO is critical to the success of a scrum team.

Will your organization provide dedicated team members?

Many organizations allocate resources to multiple projects. I often get the question “do the team members ever work on multiple projects in Agile?” When I answer that, in order to complete sprints every few weeks, it is necessary to have dedicated resources, I often get pushback. “Everyone at my organization,” I’m told, “has to work on multiple projects.” In some organizations the motto is “we’ve always done it that way” but we want you to do it faster, which we’re going to call Agile. But you need to continue to do things the old way.

There are huge advantages to having a dedicated team, such as time wasted trying to keep track of where we left off another project or dealing with team dynamics that are wildly different from one team to another. It is hard to create a self-organizing team when members float from one team to another. And team members who have been part of a high-performing, self-initiating, and self-motivated team, all of whom do whatever is needed to get the job done, rarely want to return to a more traditional team. This is particularly true when they have to jump back and forth between the two.

Does your organization support time boxing each iteration?

One of the most frequent questions I get asked is “are Agile time boxes fixed,” going on to explain that at their company the powers that be keep adding features that extend the number of days in the sprint. In these organizations the time boxes become fluid and it’s hard to plan what can get done during the sprint. In order for a team to establish its velocity, that is, how many user stories can get completed during a sprint, it is necessary to have a fixed number of days in each sprint. Organizations insisting on throwing additional features and extending the current sprint may not be ready to take full advantage of Agile projects.

Does your organizational culture support just-in-time requirements?

Organizations that have a one-process-fits-all set of business analysis processes might not be ready for an Agile environment, particularly when those processes have proven burdensome for some projects. I have worked with clients who have proudly showed me their new requirements process. Some of these companies do not differentiate between project types, approaches, and final product, so that the processes for developing software are the same as for new processes, and new product development, marketing campaigns, new bridges, etc., and processes for large projects are the same as for small ones. On the flip side, teams often struggle when organizations don’t recognize the importance of requirements, or the role of the business analyst, or why we need any requirements processes at all. In these companies, doing just-in-time requirements means moving straight to design.

Just-in-time requirements mean that requirements for upcoming sprints are defined completely before the beginning current sprint. One clear advantage is that when requirements are “groomed” or defined before each sprint, time is not wasted during the sprint trying to figure out what each user story means. The PO does not need to take time away from the Team to meet separately with other subject matter experts (SMEs) to uncover needs and expectations. That work has already been completed. As I’ve said in past blogs, who is better to groom the backlog than the BA?

Next month we’ll explore other questions that organizations can use to help them decide whether they are ready to make the necessary commitment to ensure the success of agile adoption.

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!