Saturday, February 28, 2015

Agile guest lecture series: Principles

In the first entry in this series, I talked a little bit about the Agile Manifesto. The manifesto deals with the spirit and intent of an Agile approach, but the authors didn't stop there. They also included a set of twelve principles that, when followed, fulfill the purpose of the manifesto.



For the students, most of these principles are not easily applicable. They have other classes and extra-curricular activities. This project is not their full-time job. Likewise, if you're trying to do an Agile transformation, enacting all of the principles all at once can be very challenging. There are lots of personnel and organizational resistances to change. As such, I suggest digesting these principles in smaller chunks. For the students, the first four principles can typically be applied to their projects in fairly straight-forward ways. If you're interested in taking an incremental, iterative approach to Agile adoption, you can do the same thing. Practical application of the first four principles are covered here.

Principle 1!

There are so many important words in this principle. Satisfy. Customer. Early. Continuous. Valuable. While they are all important, the one I focus on the most is valuable. I ask the students, given what they already know about the manifesto, how they might achieve this. The suggestion I offer to them is to participate in and help the client prioritize the work.

Helping clients prioritize work has two net effects. First of all, you stand a much better chance of delivering more valuable things than less valuable things by simply asking the question "is this the most important thing we can be doing right now?" Secondly, and this is especially important for students, is that you have a chance to say "no, that's too much work." Students are in the habit of doing what they are told to do, especially if part of the assignment is "do what the client wants." It's important to realize that agreeing to a lot of work and then not delivering is far worse than being honest about your capacity, delivering a smaller set of work, and having that set of work be valuable.

Principle 2!

This one is a little more challenging to apply to students, mainly because the projects that are taken on during the semester have a deliberately small scope. However, I typically suggest that the students put thought into their change management process (or create one if they don't have one). When your scope is small enough, the likelihood of it changing small as well. However, priorities might change, especially if they are regularly asking the client "is this the most important thing we can be doing right now?"

The other reason priorities might change is because these type of projects always have a two-headed client master. One head is the client that is sponsoring the project, but the other head is the course instructor. The students don't always take into account that the instructors are in the business of selling the brand of UT to the participating project sponsors. As such, they might need the students to do things that they haven't adequately planned for. When that happens, they need to be able to communicate with the project sponsor in such a way that the project can continue to move forward and not have the change negatively affect the relationship with the project team or the class instructor. Serving two masters that might have competing agendas is something that the students typically haven't dealt with much, so having a mechanism to do so is very valuable.

Principle 3! Deliver working software frequently, from a couple of weeks to couple of months, with a preference to the shorter timescale.

Most of the students don't differentiate between "demonstrate" and "deliver." My advice here is to push code to the production environment more than once

Getting code off of a student's machine or a development environment and working properly in a production context is typically pretty hard work. Figuring out how to do that early on has lots of advantages. It exposes you to the pitfalls in the client production release process (like QA, deployment, and maintenance). It also introduces the students to the people that will likely have a hand in maintaining the software after the project is over (more on that later). Finally, it gets you into the habit of delivering working software prior to the project deadline, forcing a focus on quality that might be delayed until the end of the project otherwise.

Principle 4! Business people and developers must work together daily throughout the project.

This one is probably the biggest challenge for students. Most of these students don't even work together amongst themselves daily, much less consider bringing a client representative into the mix. Since it's not pragmatic for the students to fulfill this principle completely, I suggest two things here: set up a regular communication method and schedule, and set up a sensible escalation path.

Setting up a regular communication method and schedule is something that will already be mandated by the course instructor. I suggest to the students to make that schedule as frequent as they and their clients can tolerate, especially considering they won't be co-located in most cases. Most students are thinking "a weekly phone call is good enough," but I'll suggest to them that every time they meet to work on the project (including class time), they should pull the client in. Half-hours are actually pretty hard for clients to dedicate to student projects, but a five or ten minute phone call right after lunch is very consumable, since in the real world people like to ease back into work after lunch anyway. In any case, get a regular method (phone call, email, on-site visit) and schedule (every Monday and Wednesday from 1:10 - 1:15 pm) agreed to by all parties.

So what happens when you've got a decision to make or a question you need answered and you aren't anywhere close to your regular meeting time? Have an escalation path to cover communication outside of regular meetings. For lots of clients, having a one-off phone call, text, or email is just fine. What's missing from this communication is a closing feedback loop. Clients in the real world are notoriously unavailable when you really need them. I'll typically suggest the following:

  • Start with an email or whatever is the least intrusive for the client, but which they are likely to respond to.
  • Escalate to a phone call/text or whatever is somewhat intrusive for the client, that will demand more immediate attention.
  • If the client becomes totally unresponsive, escalate to the course instructor. It's important information for the instructor, and they can facilitate with the client project sponsor (or higher ranking folks) as necessary.
The last component of the communication loop is to include timeboxes for responses and default actions with each communication. For the first attempt, include something like "...if I don't hear back from you by <X>, I'll <do the escalation communication>...". On the second attempt, include something like "...if I don't hear back from you by <Y>, we're going ahead and <doing a default action/making a default decision>...". At this point, it's far better to be moving forward, even in the wrong direction, than to get stuck. The client agreed to do their part in making the project successful, so they should be accountable for participation.

Typically by this point, I see looks of confusion on the students' faces. They aren't accustomed to having not only the right, but the responsibility to push back on clients for accountability. This is a very powerful concept that serves them well throughout the rest of the project, and hopefully as they get out into the working world.

The next thing we cover, however, immediately disheartens them. :) Stay tuned for that post!


Tuesday, February 24, 2015

Agile guest lecture series: Manifesto

A couple of times a year, I'm fortunate enough to be invited to give a guest lecture to the graduating seniors in the MIS department at the University of Texas at Austin. The lecture is typically over Agile principles. Given that it's only a single lecture, I try to focus on things that can be immediately applied to the projects that the students are working on. It occurs to me that the things the students and I talk about are things that might interest anyone that is looking for low-hanging fruit towards making a transition to or simply getting started with Agile methodologies.

 The lecture begins with a simple question: What is Agile? Agile methodologies, in their simplest forms, are popular alternatives to Waterfall methodologies in the software development life cycle. They allow us to adapt to changing technologies and requirements far better than traditional approaches to software development. Agile methodologies are inspired by the tenets of the Agile Manifesto (http://www.agilemanifesto.org/).

 The above question is, unfortunately, immediately followed by perhaps a more important question: *WHY* is Agile? As it turns out, the folks that originally wrote the Agile Manifesto did so because they were tired of doing software projects as if they were "fixed" projects. When I say "fixed," I mean that all three sides of the project management pyramid are fixed but the project is still expected to be successful.

These folks were (and are) pretty brilliant, yet despite their brilliance they still experienced far more failure in software projects (or re-definition of "success" such that it fit whatever was delivered) than actual success. The projects went over budget, or over deadline, or didn't deliver the full scope, or some combination of two or three of these three. And inevitably, the quality was never good enough. There had to be a better way to make software, specifically business software, more successful. When they put their heads together can came up with the original Agile Manifesto, they did so with an eye toward which precepts and principles would actually lead to working, valuable software in a reasonable amount of time which allowing the delivery team to learn, grow, and enjoy professional life along the way.

So what are these vaunted tenets? Adherents to the Agile Manifest value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Do you see the big, boldy words? That's for extra emphasis! 

To be clear, it's not that the words on the right aren't valuable -- they most certainly are valuable. The direction here is that you have to make a decision between the two choices, favor the choice on the left. Favor individuals and interactions over processes and tools. Favor working software over comprehensive documentation.

One of the most important things to recognize here is that the tenets are very much attitudinal and behavioral; they aren't meant to be only procedural. In order to have a healthy Agile environment, you need to have the right attitude and approach. Some teams can't make that change, and that's nothing to beat yourself up about. For the teams that CAN make the change, however... it's a brave, new world!

Stay tuned for the Principles in the next post! 



Sunday, February 8, 2015

Dancing

Ah, dancing! Who hasn't contemplated the image of themselves and their partner spinning madly across the dance floor, leaving Fred Astaire and Ginger Rogers wondering where those two got such awesome moves? I certainly have, and the images in my head were even in technicolor!

"Gosh, Fred! Do you think we'll ever look as good as Tanya and Rusty?"

For our fourth anniversary, I purchased beginner ballroom dancing lessons for Tanya and myself. It was a package deal containing four group lessons and one private lesson, beginning in January and ending this past Monday. Overall, it was a great experience and I think we would do it again, with a caveat.

First, the good points:

  • Group lessons were very effective and enjoyable. We had an informative, entertaining, friendly, and encouraging instructor that quickly introduced us to basic steps for several dances, including the Foxtrot, Texas Two-Step, Rumba, and Jitterbug. Each week dove a little deeper into more advanced moves in each dance. In case you were wondering, our favorite was Rumba. 
    Rumba's basic steps
  • Group lessons were approximately 40 minutes long. This is actually a very good length for people that haven't ever danced before, as it gives the instructor time to get into two or three moves via demonstration while providing time to the couples to practice. Two or three is not an overwhelming number and gives you a small set of things to practice at home.
  • The group was a manageable size (5 couples). This is also really important, as the instructor has to be able to communicate with everyone audibly as well as visually. It's a dance studio, so there is always music playing that needs to be spoken over. Ten people is a small enough group that this wasn't a challenge. It also meant that we all occupied a small enough dance floor space that the instructor could easily pay attention to all of us as we practiced.
  • We actually practiced at home (a little). This is essential to progressing given the way our instructor went from basic to more advanced stuff every week. You actually don't need that much room to practice, as most of the basic steps are boxy. Practicing dancing with someone you love is a pleasant way to spend a few minutes in the evening.
And now, the bad points:
  • We weren't the only students in the studio. I mentioned above that there was music the instructor had to speak over. There were also other instructions going on on the dance floor, so that had to be contended with as well. We were constrained to a spot on the floor which seemed adequate, but it would have been interesting to see how the instruction might've been different if we'd had full use of the studio.
  • We missed one group lesson due to work. Given that we weren't practicing at home in a really dedicated manner, missing one of the lessons had a tangible effect on our progress. If you only have four group lessons to begin with and you miss one... you do the math. 
  • The private lesson was a sales pitch instead of a real lesson.
The last point is where the caveat comes from. We suspected that the last lesson would be heavy on salesmanship, but didn't think it would be the focus at the cost of ineffective instruction. 

As opposed to our great experiences in group lessons, the private lesson was a completely turn-off. The instructor was not the same as the one from the group lessons. This one was fake-friendly (the way sales people are), didn't spend any time determining how much we knew/didn't know about dancing already, and didn't seem aware of the fact that we had just completed the group classes at all. The result was that we spent 20 minutes doing basic steps from dances we either didn't care about or already knew from group lessons. The exception was the Tango, which I'm certain would have been our favorite if we didn't already have a sour taste in our mouth from the first 15 minutes of review.

The last 20 minutes of our session were spent trying to sell us the next package of lessons/studio membership. I won't bore you with the details of the pitch. Suffice to say that we declined as politely as we could after talking about it amongst ourselves. NOTE: if you want to sell something to Tanya, do NOT try to pressure her into making an immediate decision. The answer will ALWAYS be NO in that case. :-)

You might have noticed that I didn't include the either the studio's name or instuctors' names. I did this purposefully, as the studio is part of a franchise and other people's mileage may vary. If you're really interested in the details, drop me a line and I'll gladly supply them.

With all this said, we are still really interested in ballroom dancing and will probably look around at other studios for other beginners packages. We might even invite some friends to join with us. If you haven't ever given it a try, you should definitely consider it. Ballroom dancing is athletic artistry, after all, and a worthy pursuit of self-expression. 


Sunday, February 1, 2015

Book review: Slaughterhouse-Five

I actually "read" the audiobook, narrated by Ethan Hawke. Let me cover the content first, since it's the most important. This was my first exposure to Vonnegut, and I intend to read more based solely on this exposure. The story has some really interesting sci-fi elements but keeps the focus on the horrors Vonnegut experienced during World War II. The wordsmithing is impressive. On more than one occasion I found myself saying "that was terribly and beautifully said." The four-star review is a reflection of 4.5 star content.

The audiobook, however, was less appealing. Ethan Hawke's narration, which a lot of people thought was very well done in a whispery breath, I found pretty annoying. Having to turn the volume up because the narrator is trying to be conspiratorial is a bad job in two parts -- narrator and production. Hawke's vocal variance range left something to be desired as well. At least twice I had to wait until the end of a conversation to figure out which characters had actually said what. Combine these with the always ridiculous SUDDEN OMINOUS MUSICAL CHORDS played at the most random and jarring times, and the recording is one of the least pleasant I've listened to recently.

With this said, I strongly recommend the book. I do not recommend the audible.com recording narrated by Ethan Hawke. The book is short enough to read. Do yourself a favor and do so. :)