The Agile Project Manager — What’s the Big Deal about Commitment?

As I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching Agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.

Another term that causes angst within Agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.

So, what does it mean to be committed?


Let’s start with a definition of the term.  From I found the following definition:

1.  the state or quality of being committed to a cause, policy, or person.
         a.  a pledge or undertaking
2.  an engagement or obligation that restricts freedom of action.

Given that definition, project leadership is always looking for a team to commit to a project—to its target date/schedule, scope, and cost. They’re looking for guarantees from the team to meet the projects’ inception views towards completion targets.

On the surface that doesn’t sound bad—does it? Bringing it back to software development methods, there’s a perceived difference in how “committed” teams are in Waterfall variants vs. Agile variants (Scrum, Extreme Programming, Lean, Kanban, etc.).

Waterfall (is) Committed?

The thought goes that since teams plan their execution thoroughly in Waterfall, to a set of documented requirements, that when the project begins they’re in a clear position to fully commit to the project.

They’re committed to the date, to the scope, and to the costs they’ve estimated. And if there is any “negative discovery” along the way, the team will somehow figure out how to “suck it up”, working harder and longer to meet their “commitment”.  No matter what happens along the way!

You’ll often hear management driving this behavior—reminding the team of their commitment and to work smarter and not harder. There might even be veiled and not so veiled threats, as to what might happen if they fail to…meet their commitment.

Agile (is not) Committed?

Conversely there’s a feeling that Agile teams lack commitment. You hear this coming from nearly every executive, technology leader, and project manager who are adopting agile and struggling with forecasting project outcomes.

This comes from the basic tenet that teams commit to projects incrementally—as they gain more understanding of the work by implementing it in small chunks. That teams narrow in on their delivery target as they gain more understanding and collaborate with their customer. That teams can commit when they’ve made some progress and understand their delivery velocity.

In lieu of simply committing without knowing, Agile teams focus on incremental delivery and incremental commitment; needing some time to truly understand the project complexity and their own capacity. Many misconstrue this prudence and transparency for a lack of commitment. But there’s also a truth to agilist’s struggling with the term.

A quick diversion to the Scrum Guide
Ken Schwaber and publish something called the Scrum Guide. They recently (2011) published an update to the Scrum Guide changing the language used to reflect the team posture at the conclusion of Sprint Planning. Previous language had used “commit”, as in the team would “commit” to the work they identified and planned as part of their sprint.

The updated language changed the word “commit” to the word “forecast”—here’s a copy of the language change that I copied from the FAQ on the site - Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

This was one of six changes or adjustments that were made within the guide. I bring it up because it amplifies a common reaction in the agile community to the word commitment. At my core, I don’t understand the issue. It’s just a word.

Back to Waterfall vs. Agile Commitment
So are Waterfall teams more committed than their Agile counterparts? In the use of language around project targets and scope, it certainly appears so. But let’s get real. Waterfall projects rarely meet their commitments. I rarely do this, but I’ll bring out some statistics to make the point…

According to the 2009 Chaos Report examining the success rate of IT projects found that – 32% of projects succeeded, 44% were challenged or failed to meet some project goals, and 24% failed completely.

The key point here is the assumption that these were committed teams, yet literally 2/3 of the projects failed in some capacity. So I contend that commitment is simply a word. Not let’s look at commitment from a different angle—probably the right angle.

The Real Nature of Commitment
I don’t think team commitment comes from a methodology or a planning process—particularly for highly complex, technology-driven projects, with tremendous up-side risk because your teams are creating novel solutions to your problems.

Commitment is created by many factors and I don’t pretend to be an expert on it. However, it seems to me that some of the following are crucial to support an environment of commitment—

  • Teams commit to each other; so fostering an environment of teamwork, mutual accountability, trust, and professionalism.
  • Teams commit to exciting and meaningful work; so communicate the ‘why’ and ‘impact’ of their work to inspire the team.
  • Teams commit to solid leaders—leaders who trust them to do their jobs and who provide sufficient support for them to succeed.
  • Teams commit to doing good work. Work that balances competitive delivery against solid designs, creativity, work-life balance, and high quality.
  • Teams commit to providing total honesty and real-time transparency so that their leaders can make congruent adjustments; to leaders that can “handle the truth”.

Wrapping Up

So I still like to instill in Agile teams that Sprints can either “Pass or Fail” depending on their efforts and behaviors and results relative to their sprint goal. And yes, I do expect a team to “Commit To” their plan to meet a sprint goal that they’ve established with their Product Owner.

I feel it’s not the word that is the problem. Instead, the question is—does the environment support the team in the areas I mention above in meeting their commitments? Point being—I don’t see commitment as a team only condition. I think the organization needs to establish a culture and an environment where commitment is supported. Where discovery and adjustment is supported, where honesty and transparency is honored, and where failure is tolerated.

If you have an environment that isn’t supportive, then yes, I can see changing the term and not using it. In that environment, then “forecast” would be a better term…as would dysfunctional. But I’m tremendously disappointed in the organization that can’t make congruent commitments across their teams and then deliver on those commitments.

So call me committed to An Environment of Commitment…

Till next time - Bob

1.    Top 10 Agile Phobias -
2.    Chaos Report reference –
3.    Scrum Guide reference –
4.    Wonderful article on Estimation, Prediction, and Commitment –

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at

Posted in: 

Is Your Website Future-Ready?

Maybe you already know by now that mobile web is important. There are now more than 100 million smartphone users in the U.S. and the percentage of overall web traffic that comes from mobile users just doubled in 2011.

So what does that mean for your website? If your site isn't optimized for mobile, that's a lot of people that are struggling to get the information they need from you, or worse, that are leaving to find someplace else they can. It can be overwhelming to consider all the possible ways you could try to reach this target audience. One route would be to build a mobile app, but that can be expensive to both build and update an app for several phone types—and then there's the small matter of users being able to find and download it from the app store.

Drupal Mobile

Mobile web seems to be the quickest route. Everyone with a smart phone has access to the web; and all that hard work you did building up your SEO can help mobile users find your site quickly. So how do you prepare your site for mobile users? You could build an entirely separate website using a third party tool, and try to incorporate the most important information into the mobile site. Re-route traffic to, and then struggle to keep your regular website and your new mobile site up-to-date. But device detection isn't perfect, and sometimes mobile users want to see ALL the content on your site, not the abridged version.

What if there was a way to update all your content in one place, and have it display one way to visitors on desktop computers and a different way to users on mobile devices? What if the layout could shape-shift to accommodate tablets of all sizes, and even expand to showcase a wider version for users with large monitors?

Enter the perfect couple: Drupal + Responsive Design. It's no Brangelina, but it still rocks. With Drupal, a powerful, open-source, fully customizable content management system — adding and updating your content is a snap. Photos resize themselves, formatting is taken care of for you, and multiple users can make updates and save revisions. Drupal is also ready to slip into a responsive theme like Omega or the Adaptive Theme. This means that your content is optimized for whatever screen size your visitor has got, and no one leaves grumbling and frustrated. Take a look at some of the most recent responsive sites we've launched with Drupal.

It's the real deal. Mediacurrent recently published a whitepaper, "The Mobile Web with Drupal", that expands on why organizations must move into the mobile arena. Be sure to check it out.

About the Author: 

Kendall Totten is a Drupal Designer & Theming Specialist at Mediacurrent, a Drupal web development agency based out of Atlanta, GA.  Kendall is a graduate from Eastern Michigan University, where she studied Communication Technology and Graphic Design. She worked in the layout and design department at the Eastern Echo newspaper for three years, eventually becoming the Chief of Design. Kendall grew and expanded her role as a graphic designer into Drupal front-end development, support, and client training.

Posted in: 

The Agile Project Manager—Viewing RISK Through a Different Lens

I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMPs in the audience the more spirited the discussions become.

One of the core translation areas between traditional and agile project management relates to risk management. I often get a lot of pushback from the PMPs telling me that the agile approaches to risk management simply won’t work. Their arguments are more based on traditional thinking, PMBOK guidance, and “we’ve always done it this way” pattern; rather than a situational response to individual project needs. I usually just leave it that agile risk management is “different” and move onto safer topic areas. But I usually want to add more flavor and this post seemed like a good opportunity to do so.

Traditional Risk Management

In this view, the Project Manager is managing the risk. The premise is that you need a highly skilled and experienced PM to adequately control and manage project risks. That risk can be anticipated, planned, reduced, avoided, transferred, positive, triggered, and mitigated. One of the first activities with any project is to begin the compilation of a risk list so one can manage the project risks. These risks can be gleaned in a wide variety of methods—team brainstorming, speaking directly to key stakeholders, analyzing previous projects, and from the technology and business climate. Once identified, teams often evaluate the size of each risk. A common mechanism is to gather likelihood and impact from the project team, then multiply the likelihood of the risk occurring against the impact the risk would have.

So, something like the following table:

Agile risk

Once you’ve accumulated a “complete” list of risks and analyzed their “priority”, then a plan is put in place to detect and mitigate the risks that are most likely to occur. Quite often, this is a very detailed plan that is formulated with all of the projects functional teams—expending quite a bit of time and effort towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

A Quick Point of Context

Oh, and I need to get this point out of the way. My primary context for this post is technology projects. If you’ve managed a technology-driven project, IT project, software development effort, or product integration project you will certainly agree that these beasties are “different” than other types of projects. And yes, their risks are different too. Rarely can you predict risks early on in these projects. Why? Because you simply haven’t done it before—so you have little to no experience with this specific type of project or technology within the team chartered with implementing it.

In my view, the variability in complex software projects is what undermines traditional risk management. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we know and don’t know with respect to our technologies--or specifically how do we design & code this particular widget. (i.e. do some of the project work before trying to predict risk—so let the risks emerge from our design and coding efforts rather than trying to predict them.)

It’s this focus on iterative, working code that raises agile software project risk management from conjecture to real-time risk discovery. So, let’s move onto agile risk management.

Agile Risk Management

 In traditional waterfall projects risk essentially surfaces late—usually in the latter 20% of a project and sort of all at once. For agile projects, they’re much more front-loaded. Yes, for an identical project the same risks will probably surface in agile. So, it’s not a prevention mechanism.

This nicely leads into the essence of agile risk management being an emergent approach. First of all, you rarely hear the agile methods focus on risk at all. Why? Because we flip the notion of planning risk on its ear a bit. How is that? Well instead of guessing or planning for risk, one of the central themes of the agile methodologies is to deliver, real working software, in very thin slices of functionality via time-boxed iterations.

Realization of risk occurs quickly and abruptly. It hits you in the face as a team at the earliest possible moment. Quite often it surfaces in your daily stand-up meetings—so very little lag time.

Is it solely the responsibility of the Project Manager? No, in the agile case the self-directed team is primarily responsible for detecting, acting on, and mitigating risk…and here’s the important part, in real-time, as each risk occurs. It’s a whole-team and highly reactive stance towards risk.

  • The team often engages in strategies surrounding risk by how they approach iteration planning. They have the choice of what to build first, so very often the development strategy is to load risky items first
  • To complete research oriented user stories well in advance of delivering the related feature story
  • To do early experimentation to see how the team will respond to technical challenges and the unknown.
  • To measure the velocity of the team to understand their capacity to meet business milestones.
  • To engage stakeholders in assessing requirements as they evolve…in real-time and on working software.

The Rework Balance

One of the most important aspects of agile risk management is effectively balancing your rework. This is one of the key indicators that your agile project is being run well or running off the rails. Agile teams have a tendency to either sprint too early, before they fully understand what they’re about to build, or they sprint too late, as they over-analyze the work.

Agile speed is a rework balancing act. If you have zero rework, then you’re playing it too safe. You analyzing everything in advance and taking no risk. For example, you deliver a fully operational messaging framework component for use without ever having sent a message through it. This is sort of that BDUF (Big Design Up Front) waterfall-esque approach to architecture. It appears less risky, but it isn’t. You’ve just delayed your information gathering on how well your strategy works.

But if you start too early, without even thinking about some of the dynamics of your messaging architecture, instead simply slinging code, then your rework is likely to be high. As you make discoveries in your testing you’ll need to go back and rework large swatches of your framework ideas.

So somewhere in between these two end-points lies an appropriate rework balance for each unique agile team. If they don’t think, then they’ll suffer from too much rework risk. If they go to slow, then they’ll not achieve the delivery and speed promises of agility. They’ll also still have rework—as they will not have anticipated every eventuality.

Wrapping Up

Now all of that being said, I don’t think we throw out all of the traditional risk approaches in agile contexts. For example, I think it a very healthy exercise for larger-scale agile projects to assess and understand the Top 10 risks they might be facing. In addition, to also look for more systemic or organizational risks and do a bit of up-front planning for them.

But don’t spend too much time there. Nor in exhaustive detection strategies or mitigation plans. Set up a straw man risk structure and then start leveraging the emergent nature of agile iterations to surface risks quickly. And once they surface, then ACT immediately on the risk that are real risks and not those you planned or anticipated.

Now for you traditional project managers listening in, I wonder if some of these agile approaches might be applicable in your current project contexts. I’d guess yes!

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at

Posted in: 

Dependency Injection in ASP.NET MVC

Welcome to part one of a two part series on dependency injection in ASP.NET MVC. Part one of this series will focus on the basics of dependency injection and code structure. In part two, we will dive into the specifics of DI in an ASP.NET MVC application.

Although dependency injection frameworks (DI/IoC containers) have been in use for quite some time in many development platforms, it has grown in popularity in recent years within the .NET community. Many of the early DI frameworks were ports of their Java brethren. Some of those early ports still exist today such as Spring.NET, albeit with several differences from the Java version. Microsoft released their own framework some time ago called Unity, although it's future is uncertain. Microsoft's focus in recent years on solid design patterns such as MVVM in the Silverlight/WPF world and MVC in the more recent incarnations of ASP.NET, has really brought the use of dependency injection into the spotlight as a tool for writing loosely coupled code.

For those unfamiliar with dependency injection or the more general principle of inversion of control, here is a brief example. Suppose we have the following AlbumSearch class. Given an album name, this fictitious class will return a track listing.

dependency inj _1








As you can see, the FindTracksByAlbum method creates an instance of FreeDBService. Presumably, this FreeDBService goes out on the web and retrieves the appropriate track listing from the FreeDB internet database of CD data. Since we are creating an instance of the FreeDBService directly, we can classify its use as a dependency for our AlbumSearch class.

While functional, there is an issue with this approach. What if we wanted to use the CDDB instead of FreeDB for some or all of our searches? What if we wanted to write a unit test for our Find method that could take advantage of mock data? Why would we want to do either of those two things? Although this is a trivial example, let's assume our AlbumSearch class is part of a larger library that will be consumed by an unknown application. Further, let's say that the unknown application will be responsible for deciding which CD database to use.

How do we fix this? First, we need to make a few simple modifications to our sample code.


dependency inj _2
























Note that we have introduced an interface, IDBService, to represent our track listing service. Plus we have added two implementations of IDBService, one for the FreeDB database and one for the CDDB database. This allows our AlbumSearch class to rely on a generic implementation internally rather than a hard-coded instance of the FreeDBService. Finally, notice that we now have a constructor that requires an instance of IDBService. This is where the magic or “injection” occurs. By structuring our class this way, we have given the consuming application the ability to determine what implementation of IDBService is appropriate.

The consuming application or code can use a variety of techniques and frameworks to determine what implementation of IDBService to use at runtime. This could simply be an implementation of the service locator pattern or preferably some sort of dependency injection framework such as Structure Map, Unity, or Ninject. Modern DI frameworks rely on configuration to determine what the appropriate implementation of a given interface should be at runtime. Configuration is generally xml file based or code-based using some sort of fluent API. If we were using Ninject, you may find a fluent API line like this somewhere in our applications configuration code;

dependency inj _3



When we actually create an instance of our AlbumSearch class, you may find some code like this:

dependency inj _4







This is a simplistic example, but you get the point. Within the Ninject Kernel or registry we have basically said that all requests for an instance of IDBService will actually return an instance of FreeDBService. We could have implemented this a multitude of ways, but this is the most straightforward. In part two, we will take a look at a cleaner approach in ASP.NET MVC.

We now have a handle on the general code structure needed to support some simple dependency injection scenarios. Check back for part two of this series to learn how to implement dependency injection in an actual ASP.NET MVC application.

About the Author: 

Russell Thatcher is a Software Architect for a medical software provider. He possesses over 10 years of software development experience in a variety of industries, including healthcare, financial, and defense industries. With expertise in the latest Microsoft technologies and Agile development practices, Russell consistently delivers high quality, on target software solutions for his clients.

Posted in: 

Ten Years Working at MATRIX, Whoa!

I will be celebrating a milestone at the end this year that many people rarely achieve.

In December, I will have been with MATRIX for 10 years. While this tenure is not the norm for most, it’s actually fairly commonplace here where celebrating those with 10 or more years of service is an annual event.  Each tenured employee is recognized (and roasted to a degree) at the event that includes speeches from peers and managers, funny photos from our past, food and drinks, and the opportunity to mingle and reminisce about our time with MATRIX.

At the event, I had several people ask me why I had stayed at the company for so long. It got me thinking. I suppose the answer is pretty simple yet vague – I’m happy here. With the economy showing signs of improvement, companies need to work harder to retain their best employees. Compensation, bonuses, and perks are certainly factors, but there are many other intangibles that should not be overlooked.  I can share the factors that contribute most to my “happiness” here and are likely important to a lot of people:

  • Advancement. I’m currently in my fourth role at MATRIX. Started as the receptionist, moved on to support the executive team, transitioned into marketing leading proposal development, and now I focus on our CRM Marketing strategy. Moving into new roles, gaining new skills, and challenging myself are key to my tenure here.
  • Appreciation. I’ve always been made to feel that my contributions are appreciated and the work I do here is highly valued. We have various recognition programs here, but more than that, I am actually told this on a frequent basis from my manager and upper management.
  • Willingness to Listen. Over the years, I’ve become more apt to share my opinion here and I am made to feel my opinion matters. I work with people who are willing to make changes to help me do my job better including access to training and resources.
  • Great People. I genuinely enjoy the people I work with on a daily basis and feel my co-workers have a similar work ethic and value system to me. I’ve made many great friends here that I spend time with outside of work. He doesn’t work here anymore, but my husband met me at MATRIX, and he was a Recruiter here for seven years.
  • Work-Life Balance. This has been a popular buzz phrase for years. For me, it means I have a flexible schedule when needed and can work from home or leave for a doctor’s appointment, and I have accrued vacation time to take time off when I need to (and, I’m not made to feel guilty when I take my time off!).

When it comes down to it, I think truly valuing each employee and making them feel appreciated goes a very long way in their retention. As the economy continues to improve, I’d recommend taking note of these factors and how well the needs of your employees are being met.

About the Author: 

Michelle Spears is CRM Manager at MATRIX Resources. She coordinates targeted candidate, consultant, and client campaigns and oversees the proposal development process for MATRIX. She also researches and creates quarterly briefings on IT market and compiles a bi-annual IT salary survey.

Posted in: 
Hiring Manager