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!