Welcome Changing Requirements, Even If You Don’t Want To

April 30, 2012

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Agile Manifesto, 2nd Principle

I have a confession to make: I find this particular principle hard to live up to. Let’s just face it: I don’t like surprises.

This week I’m going to try and live this principle. It turns out my kids are going to put this to the test almost immediately. We’re  getting ready for school this morning and the pre-schooler is off to a slow start. “Hey honey, can you take care of kid 2.0 while I take kid 1.0 to school?” Right off the bat I have a requirement that’s changed. Good grief!

Welcome changing requirements. So, I put on my patented Agile Smile and say, “Sure honey, no problem!”

The thing that makes last minute requirements changes tough is that you are usually so close to your goal when it happens. There I am: mentally I’ve got my coat on and one foot out the door headed to work (my goal). Here is a last minute request, a delay of game. A request for help. There is no question that I’m helping out my family by accepting this last minute request. However, it isn’t without some compromise (My own ability to get to the office in reasonable time). I think I’m juggling the needs of multiple customers in this case. Some days I do it well, other days…not so much.

One thought that occurs to me is that you have to have your customer clearly in mind (which I obviously don’t). Juggling multiple customers makes it really hard to manage changing requirements. It must suck to be product owner sometimes. The more I look at this principle, the more I want to re-write it:

“Welcome changing requirements, even if you don’t want to. Agile processes harness you to the customer’s every whim.”

And that’s probably a good thing. I think it’s going to be a long week…

Delivering Value With The Kids

April 27, 2012
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
1st principle, Agile Manifesto

No, I’m not selling the kids to the circus…yet. Actually, my wife is out of town, so I get the kids for the weekend. Aside from making it the usual “Dad weekend” with all the pizza and cake you can eat, I’ve been trying to think of some ways to share this whole “delivering value” lesson with them. Here are a few ideas I’ve come up with:

  1. Teach the children to cheat on their math homework using the Ruby interpreter
  2. Teach kids to play blackjack or 5 card stud
  3. Take kids to the horse races and show them how to place a bet
  4. Have them make my stock picks – if the numbers are up, they get desert

They are going to have a blast! I’m just getting started. It’s going to be  great weekend!

Of course what I’m doing is playing with the idea of value. Are there bad values? Is there value that we deliver that has a negative effect on our customers? How does that affect our ability to deliver?

Feeding the Value Machine

April 26, 2012

In my effort to explore living the first principle of the Agile Manifesto this week I have found myself asking the question, “How can I provide value for you?” Of course that presumes I have something useful to offer. So if I take a brief inventory of useful or valuable stuff I know, here is what I come up with:

  • Software Development knowledge & experience (programming, practices, etc.)
  • Team building (facilitation, training, negotiation, games, & other soft skills)
  • Sailing knowledge & experience
  • Boat building
  • Wood working
  • etc.

All of it has some component of knowledge and learning associated with it. I had an interest in these things and took the time to learn more about these topics and perhaps more importantly gain experience with the subjects I was passionate about. Could it be that this is the pool of value that I have to offer? If so, then an important activity here is growing that pool of useful knowledge, experience (or value). It doesn’t just happen by itself. We have to make a conscious investment in these activities in order to improve our knowledge (and the corresponding value proposition).

That means that not only do I need to  be asking how I can add value, but I also need to invest some of my time investing in growing or maturing the value that I’m able to provide. If we take a look at the first principle from the Manifesto Again:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Let’s face it, continuously providing value is a daunting task. It seems almost impossible at the individual level. Part of providing that value is going to be continuously nurturing the capability within ourselves. How can we do that?

  • Read books
  • Get out there and try out our ideas (experience)
  • Share the ideas with others
  • Expand the variety of activities we engage in

All of these actions will help to nurture the value that you may offer. In order to be providing lots of value you need to “feed the machine” and seek ways to improve or grow the value that you offer.

Shut Up and Focus

April 25, 2012

So I learned a few more things about creating value today, especially with regard to creating value with training.

First, as a trainer I’m not always creating value when I’m talking. In fact, I may actually be discouraging much more valuable input from someone else by dominating the conversation myself. So sometimes there is more value in knowing when to shut up and listen.

Shutting up is hard for me, not only because I simply adore the sound of my own voice (Me, me, me!), but also because the people attending the training want you to give them the answer. When you ask a question and then clam up, the increase in pressure in the room is almost tangible. Of course the real value in the training is when they come to a realization on their own. Then they are much more likely to retain that knowledge. That means you have to be able to ask them to work out the problem without you telling them the answer. It sounds trivial, but it can be excruciating to live in those anxious moments of silence that exist between the end of the question and the first tentative answer.

Summary: there is value in silence.

Second, focus enhances value. So today we used a timer when we did our training. The two of us each had a seven minute time limit on any given topic before we had to hand off to the other trainer. We kept this up for nearly eight hours (with some breaks). Having a deadline serves to focus the mind and accelerate the delivery of value. We were right on topic and right on time all day long. Whereas the previous day we had tended to drift off topic occasionally, now we were much more focused on making point, sharing an idea or delivering an exercise.

Another benefit of the short timeframe (also related to focus) was that we didn’t have much time to drift or daydream. You got seven minutes off while the other trainer was working with the class, but you had better be paying attention, because you were guaranteed to be back in the hot seat in just a couple of minutes. There was no time for distractions. The overall feedback from the class was that they liked the change.

Summary: focus enhances value.

Finally, we added a “yellow card” system where the members of the class could flag a topic as dragging on too long or less useful. This gave them a way to give us feedback about the value that they were getting out of the class in real time.

Summary: continuous delivery of value works best when there is a mechanism for feedback from the customer.

Value Creation is a Dialog

April 25, 2012

Day two of trying to live the first principle of the 12 principles of the Agile Manifesto (“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”). So far so good. I spent much of the day co-training a class. It was a unique training because we asked the attendees to pick the topics that were most valuable to them, prioritize them, then taught the material. Finally we finished up with periodic retrospectives throughout the day. It seemed fairly obvious that this was a great example of asking the customer what they value, delivering the value, then checking to see if they thought it was really useful. After an entire rather exhausting day of this, it occurs to me that continuously providing value is actually a dialog (or perhaps an ongoing experiment) that works like this

  1. Ask what value you can provide
  2. Attempt to provide that value
  3. Ask the customer if they got the expected value
  4. Adjust and repeat

I think that value cycle lies at the heart of a lot of Agile processes. You see this in the sprint reviews and retrospectives on projects. It really is the PDCA cycle all over again. But speaking for myself, I think I’m going to have to modify my approach this week. Here’s a sample:

  • Ask friend: How can I provide value
  • Friend: Buy me a beer
  • Beer provided
  • Ask friend: So, how’s that beer?
  • Friend: Excellent! Too warm! Too foamy! bitter, etc.

Value delivered.

Early Continuous Delivery of Value

April 23, 2012

This is the first week of my experiment to try and live each of the 12 principles of the Agile Manifesto. It’s day one of the first week, principle #1:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

So what does that actually mean? Right now I don’t have any plans to go out and write valuable software every day. That could change, but it looks like this may take some rethinking on my part. So how can I live by this principle in a meaningful way? There are a few questions that arose for me as I considered this principle. First, who is the customer? In my case there are many possible candidates for the customer:

  • My Family
  • My Team
  • The Folks Who Read My Blog (both of you)
  • My Friends

That’s actually not such a bad list. The big question is what do they really value? If I intend to deliver value for these folks early and often, then I better figure out what they want. As I pondered that thought I realized that I was going to have to ask a lot of questions. So, with more than a little trepidation I spent my day asking the question, “How can I add value for you?” As you’ll see, results were mixed:

  • My wife: “Don’t ever wake me up to ask that question again. And put on a pot of coffee.” Done and done! This is going to be easier than I thought!
  • My kids: “What’s value? You mean like candy? And TV? Can I have an American Girl doll?” No, no, no. This is not going well. I’ll write you a nice story kid.
  • The folks who read my blog: So what represents value in this blog? I presume it has something to do with the writing. Maybe I can do more of that?
  • My team: Oh boy…I’ve got a lot more questions to ask
  • My friends: “You add value when you buy the beer.” OK, point taken.

You know, this sort of inquiry could easily lead you to the conclusion that most customers have no idea what value is. It seems as though this is going to require some of my own vision of what providing value is. Otherwise I will end up chasing my own tail in short order. Maybe I just need to focus?

All of this running around asking people questions seems to lead to a very external sort of mindset. I spent much of my day concerned with what was valuable to others rather than what was valuable to me. It was a curious sort of re-orientation that took place. Of course it is just day one. The good news: so far no one has asked me to deliver software. But the next challenge is perhaps more daunting, “How do I deliver value early and continuously to my customers” Identifying the value is only the first step. Now I have to figure out how to deliver value – a LOT of value. Fast.

Living The 12 Principles

April 20, 2012

As someone who professes to value agility in software development and all that goes with it, I occasionally catch myself in that dreadful, “do as I say, not as I do…” scenario with the teams I work with. Actually it happens with alarming regularity. I’ll just admit it: I’m a weak man. Of course I suspect that there are others who are the same way too.

Of course we should all walk the walk if we are going to talk the talk. If we are going to foist off these principles on poor unsuspecting teams, then I suppose we should make at least a token effort to be an exemplar. As an example, I’ve always been a firm believer in the value to keeping a sustainable pace and the importance of doing that for our teams. However, I came to the rather startling realization that I do a remarkably poor job of keeping a sustainable pace in my personal life (Full disclosure: it’s an unmitigated disaster of competing commitments and overlapping priorities). It has led me to question why any team would listen to me preach about sustainable pace, when I appear to be utterly incapable of demonstrating that value in my own life. Frankly, when it comes to keeping a sustainable pace, I’m the last guy you should listen to.

So with that in mind I’ve decided that it’s high time that I make a sincere effort to internalize the principles of the Agile Manifesto by trying to live them myself. I have to admit to more than a little trepidation at the very thought of trying to live according such noble goals. I really don’t do noble well. With me, noble fits like a Hawaiian shirt in church.

The Agile Manifesto contains a list of 12 principles that agile teams hold dear. You’ve probably seen them before, but just in case you haven’t, here they are in all of their agile glory:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Now I don’t think any reasonable person would try to jump into all twelve principles at once. That and I’m really just astonishingly lazy. So I’ve decided that I should take a more iterative approach: 1 principle per week. Yup, that’s right, each week I’m going to do everything I can to live one principle on the list of the famous twelve. 

But Tom, you say, those principles were created for software development teams! One man can’t possibly exemplify those principles in any meaningful way! Pish tosh! Yes I can! Oh I admit that I’m going to have to take a bit of creative license with some of them, but I’m a creative guy, so I should be able to come up with something interesting.

Actually, if I’m honest, I’m much more worried about trying to live consistently according to any sort of principles. Not that my life is entirely principle free (well, actually…) but keeping focused on anything for an entire week just sounds exhausting! Oh well, I’m just going to have to put on my big boy pants and prepare myself for 12 weeks of living the principled life!

First up, principle #1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Oof! Maybe I should start from the bottom of the list…