Triple Constraints – When nothing can give, what does?

Triple Constraints
The Triple Constraints or “Iron Triangle”

In project management, people often talk about the triple constraints, or the “Iron Triangle”.  It describes the concept that when a project encounters obstacles there are a limited number of things that can be adjusted; the schedule can be slipped, the scope can be decreased or money can be spent to purchase additional resources or tooling.  There aren’t a lot of options outside those three, but sometimes a project sponsor is unwilling to bend any of the edges of the triangle.  What happens then?

People who have been involved in more than a few projects understand that unforeseen  things will happen.  When a project sponsor is unwilling to be flexible on schedule, scope or cost the team often goes into hero mode in order to bring the project back on track.  The unfortunate truth is that this rarely works.  As people start putting in longer hours they get tired and start making mistakes.  This typically has the effect of putting the project even further behind.

In reality, when we’re not willing to bend one of the three sides of the iron triangle, we are actually bending the hidden fourth edge: quality.  People will start advocating decisions to cut corners.  Testing often gets thrown out the window in the interest of saving time.  In the end, quality suffers, and in many cases the project misses its schedule, scope or cost goals anyway.

My recommendation for every project you work on is to have the project sponsor decide which of the constraints they are willing to let bend when difficulties arise.  I also recommend that instead of including just schedule, scope and cost in the  list of options, that quality is also one of the choices.  Most people are not willing to sign their name to slipping quality when the project starts failing.  Furthermore, explicitly listing it as an option will drive home the reality that that’s what will suffer if one of the other options isn’t chosen.

In the next few posts, I’ll talk about different techniques that can be used to plan Scrum projects once we’ve chosen which edge of the triangle we’re willing to flex.

Unexpected Allies – the users

I’ve been working on an Agile (Scrum) transformation at my company for about a year now.  I knew that most of the developers here were ready for a little more structure around how code is written, tested and delivered.  I expected the team members to be fairly welcoming, but for some reason, I’d planned on the users and stakeholders being somewhat resistant to the change.  I’m not really sure why I felt that way; I likely didn’t think about it as much as I should have.

It turns out I was completely wrong.

Part of our plan was to take small steps in our roll-out of Scrum across development teams and make sure that we are able to demonstrate benefits before moving on.  My hope was that as developers, users and customers had positive experiences, the word would start getting out.  It turns out that it’s working just as I’d planned, and as I’m starting to hear the buzz in the back-channels, the biggest accolades are coming from users.

The biggest change they say they’re experiencing is with the level of involvement and ownership they’re feeling.  The users love the fact that they can understand the user stories that are being written.  They like being able to help set acceptance criteria to make sure what is being delivered is what they need to get their jobs done.  Project owners and stakeholders like the fact that requirements are being broken down into smaller components than they’re used to.  This is helping them understand what is being built and how much work is really involved in delivering each feature.

They’re enjoying transparency.

I had planned on meeting with users and stakeholders who would be impacted by our Scrum teams at some nebulous point in the future.  It seems that I need to rethink that idea, and start going out into the user community much sooner.  Like tomorrow.  Time to get some training time scheduled!

I’ll write more later about how that goes.

Vienna Service Design Jam 2012” by _dChris is licensed under CC BY 2.0 / Cropped from original

Agile Transformation – Just Keep Swimming… Just Keep Swimming…

Regal Tang - croppedOne of the most important things I’ve learned as I’ve been working through the Agile transformation at IDT is that not everything is going to go as smoothly as I would have liked it to.  I have to remember that I’m introducing (sometimes very significant) changes to how people do their job, and it’s not unreasonable for people to have some resistance to that.

Forcing change on people or saying, “you will do this simply because I say so” is not a winning strategy.  I remember days I would head home feeling defeated and beat down.  It’s important not to give up.  Keep as positive an outlook as you can, and plan your strategy for the next discussion.  Don’t keep repeating the same tired arguments over and over.  If they didn’t convince someone before, that person is not likely to suddenly change his or her mind about it.  Try to understand where people are coming from and what their concerns are.  Find ways to address their concerns.  If you can’t, it might not be a bad idea to question your approach.  Above all, challenge issues and not people.

In future posts, I’ll cover some ways to help overcome objections to agile and dispel some pernicious agile myths.

Most importantly, keep a positive attitude and don’t give up!

Creative Commons Regal Tang” by Kevin Chan is licensed under CC BY 2.0 / Cropped from original

Write user stories, not developer stories

User StoryIf your team uses user stories to define requirements, I highly recommend making sure you keep the user at the center of the stories.  Let’s say a user comes to you and says, “We need to enhance the system to make sure we send certain key customers gifts on their birthday.”

Developers are technical folks, and it’s natural for them to immediately start thinking about how they’re going to implement this new feature.  Because of this, their first instinct is often to write what I call a developer story rather than a user story.  It will likely sound something like this:

As a developer
I need to add the field DateOfBirth to the customer table
so the system can know to send them a birthday gift

The problem with this is that when you work with the user to validate the story and gather acceptance criteria, these technical stories often cause them to disengage and feel they can’t contribute.  If instead, stories are written from the viewpoint of the user, they’ll be much more likely to feel ownership and provide more useful feedback.

Given the birthday gift requirement above, a better user story might be.

As a customer service employee
I need to be able to record a customer's date of birth
so I can ensure we send them a gift for their birthday.


As a customer service employee
I want to receive a notification two weeks before a key customer's birthday
so I can ensure I have time to write a personal card for them.

rather than

As a developer
I need to create a notification service
in order to get notifications to customer service employees.

Of course, there are always exceptions.  Sometimes a user story really is for the developer, but these cases are typically reserved for internal team or infrastructure stories.  If the story is that the developers want a framework to start using ATDD, for example, writing that story from the standpoint of the developer is absolutely natural.  In this case, the developers are the users receiving the benefits of the work.

Give it a shot.  Your users and stakeholders will thank you.

Playing around with SpecFlow

I’m starting to do some tinkering with SpecFlow. I’m pretty excited to learn the tool so I can start adding ATDD style testing to my solutions. I’ll follow up with my progress.

UPDATE:  So far, so good.  I got the necessary packages added to my solution and got a couple SpecFlow features up and running.  Watched about 30 minutes of a Pluralsight video and was up and running.  I wouldn’t say I’m ready to do anything super fancy, but in that time, I was able to learn how to set up some basic parameterized tests using the framework.  And it was easy.  I like easy.  I’ll post up some examples in a bit.

Eastern Iowa Agile presentation – Selling Agile to Executives

On Thursday, March 26th, I gave a presentation about selling agile to your organization at the Eastern Iowa Agile meetup.

I’m not a big fan of presentations that just get read to the audience, so some of my slides could you some additional narrative.  I’ll follow this up with some additional posts to do just that.

If you’re interested in the presentation deck, feel free to grab it here.

Getting students excited about coding!

Over the last month or so, I’ve been working with a smart group of 8th graders at Clear Creek Amana Middle School, teaching them how to program. We’ve been using Smart Basic, and I’m super proud of the progress they’re making.

My next step is to start working with some older students as well. I’m hoping to kick things off in a couple weeks and I’m planning on blogging about the process. Wish me luck!

Follow Up: Why Isn’t My Linq Query Working

My friend Bill gave me some good feedback on my last post where I talked about making sure you have some kind of value equality implementation on your business objects so Linq queries work the way you expect them to.  Bill informed me that anonymous types’ default implementation of Equals() is very similar to that of structs.  Two objects of an anonymous type are considered equals if all of their properties’ Equals() calls return true.  So if you can get away with using anonymous types in your Linq queries, things should work as expected.  Be careful, though, if you have properties in your anonymous types that are using reference equality.  If so, you may still see some strange behavior.