My Advice to the Graduates of 2012

I’ve been away from my blog so long I think it’s appropriate to throw in another quick post to redeem myself. Given that it’s around the time of high school and college graduations, I thought I would share a few words of advice the next generation may find helpful as they embark on their new careers.

1. Work backwards on what skills and experience you need to develop.
Career-wise, you have to have a goal in mind. You have to know where you want to go, what it takes to get there, and then start working on the journey. Work backwards.

What I’ve often seen is that people float through school, graduate, then enter the job market with no clear idea of what they want to do or what they are qualified to do. My advice is to start looking at job postings early, ideally while you’re still in school. Look at job postings that are way above your present level, but that you would like to get some day. Look at the requested qualifications  across a variety of companies. Now you know what kind of skills and experience you need to develop to compete for these positions.

2. Expect to keep reading, learning, and testing yourself—both on the job and on your own time.
Here’s the bad news: most of what you learned in school isn’t that useful in the “real world”. Here’s the worse news: if you want to be competitive, you must be prepared to continue to study and learn just as hard as you did in school, only most of it will be on your own time.

Look at people successfully advancing in their fields and you’ll find people who are putting in the time to learn software programs, reading books on new trends, reading industry blogs and magazines, filling in gaps in their knowledge and keeping their skills up to date. It takes time and effort. Get used to the idea.

3. Create something.
Distinguishing yourself these days, more and more, is about creating something. Again, look at the people at the top and you’ll find people with blogs, websites, articles, books, open source projects, YouTube videos, etc. Heck, I’m trying to catch up myself with all of my own works-in-progress.

This is a principle I’m partial to as I pretty much got my own career started this way; it’s a lot easier to demonstrate that you know your stuff when you can show off the website you built, the article you wrote, or the software you developed. Adapt this principle to the field you’re in—the important thing is that something tangible speaks for you better than you can speak for yourself!

4. Focus your energy on finding what you’re good at.
It may take you a while to settle in to something you’re good at. It took me a while. You may have to change jobs or even careers. It’s a about self-discovery and opportunity. The opportunity is something which you can help create, and is what I covered in the three items above (re-read them if necessary)!

The self-discovery part is about being aware of how you are doing in every situation you are in. Although we can be good at different things, finding the work that you’re good at will, I think, have these qualities:
    •    You will find the work easy and natural even though others may find it challenging and stressful.
    •    The work aligns with your own passions and enthusiasm so that your motivation to do it is sustained.
    •    Your can be successful on your inherent strengths and avoid dependence on any of your weaknesses.

Finally, be persistent. I slogged through a quite a few years in my career where I did find the work difficult (for me personally), where I didn’t have any real interest in what I was doing, and where my weaknesses were put more to the test that my strengths. However, I eventually worked my way out using the principles I’ve described here, so I know they work if you meditate on them and apply them. Remember that the journey is alway on-going—I’m still working on my own plans for the future, and still discovering what I’d like to do and where I’d like to go next.

Whether you’re still in school, recently graduated, or you graduated a long time ago, I hope there’s something useful you gleaned from this blog post. Here’s to your success!

Real World Keys to Practicing Agile

Agile process is great in theory, but can be tough to implement in practice. This is especially true in large, corporate environments where top-down planning and Waterfall methodology is the de facto standard. These environments often wrestle with an array of inefficiencies, and although Agile may be beneficial, for reasons cultural, political, and organizational, it can be a real challenge to introduce.

It’s also a challenge when working in a consulting capacity, as I do. Most clients will ask for a contract with a fixed price, a fixed schedule, and a fixed list of deliverables. We often begin a project with a detailed spec, an elaborate GANTT chart, and a final phase of “user acceptance testing”. Not the ideal setup for the Agile practitioner!

Nevertheless, I believe it IS possible to be “more Agile” even under these conditions—in an isolated way—but as a starting point. In my experience, whether or not the process is possible boils down to the absence or presence of the right attitude and a few key ingredients. A recent project I completed comes to mind.

This was a small project, but for a big company, and had common “enterprise” project characteristics:
    •    The project had a long and detailed list of business rules driving its functionality;
    •    The project called for a very rich UI with many usability concerns;
    •    Integration was required with an enterprise-class e-commerce system;
    •    The project was one of a portfolio of components that would be combined and released together.

With this particular project, as is often the case, I was handed the marching orders up front. The client had already prepared detailed requirements, the project was already estimated, a schedule was already prepared, and resources were already assigned. My job was simply to make it happen.

The waterfall nature of the client was apparent from their documents—their GANTT charts were elaborately constructed in Excel, and their “Specifications Matrix” was impressively detailed. We provided our own detailed project plan to match, and the stage, as they say, was set.

Nevertheless, over the course of the next three months, I and my team not only managed this project in a fairly Agile manner, in everyone’s estimation we produced a deliverable that was better than the original spec, we needed no “UAT” phase and relatively minor QA effort. The client was not only very pleased with the end result, they were equally pleased with the process itself.

As I will explain below, I can’t take full credit for this. The reason this happened is that the client was willing to collaborate with us in an Agile manner. They “got it” (lucky for us). The right attitude and the right ingredients were there. Here are the points that I think made the difference:

1. We accepted that the final requirements would emerge from interacting with actual code.
The client initially provided us with a long and detailed list of requirements, which seemed very comprehensive. They had done a lot of analysis.

Nevertheless, I knew many of these requirements would change, many would be found to not be needed, and many more would be “discovered” as we progressed from concept to reality. I was not proved wrong.

Of course it was great to have those specs as a starting point—but I set the expectation early that, given the complexity of this particular project, we would likely not “see” all the requirements until we actually had something to look at and play around with.

This proved to be the case each time we took a forward step. Many new realizations emerged from simply doing wireframes; more still from doing visual designs; and many more from working prototypes and code iterations. The client realized this to be the case quickly, and after a few iterations, adopted the approach of documenting just what was needed for the next iteration. The key to this, of course, was frequent reviews of progress—which I will touch on shortly.

2. We inspected and adapted instead of rigidly following the the project plan.
Don’t get me wrong—I always take careful note of when we need to hit major milestones. But I also know that real project schedules have an inherent volatility, driven by feedback and subject to the uncertainties of the development process itself. Adjusting the plan based on constant evaluation of your progress is how the game really works.

Of course, there’s an important point here: if both sides collaborate on adjusting the plan throughout, it is “Agile”, the right decisions usually get made, and everyone stays happy.

If only one side adjusts the plan, it is considered “breaking the terms of the contract” and somebody (or everybody) may be upset.

Thus “inspecting and adapting” is something which the entire group must do as a team. It means looking at actual progress frequently and deciding how best to proceed, frequently. Non-collaborative parties just want a status report of how progress is relative to the schedule—that’s neither inspecting or adapting. Where there is no real involvement, there are assumptions, arbitrary decisions, and finger-pointing—and the “fixed plan” works against you when reality inevitably varies from it.

Fortunately for us, our client was deeply involved with evaluating and providing direction every step of the way. We varied a bit from the initial project plan, but the corresponding adjustments were appropriate and reflective of the fact that we were actually involving and listening to our customer.

3. We frequently reviewed work-in-progress with the client and with all key stakeholders.
We reviewed working code three times a week with the client. Whoever heard of having iterative reviews three times a week? Well, you just did.

There’s no hard rule that a “sprint” has to be 30 days, or two weeks long. Review progress at whatever interval is helpful to the project.

When I say “review progress” I’m not talking about a status report. I’m talking about walking through a demo of something tangible. In our case, we had twice weekly “technical reviews”with the client’s integration and business analysis team. These reviews would often be “working sessions” where we would screen-share the IDE and “pair-program” with the client to respond to their feedback in real-time and work through solutions together. We also had weekly reviews with all stakeholders, including marketing and executive folks, to show them the latest progress and gather input and feedback.

Since this was a fast moving project, this level of review was greatly beneficial, as it kept everyone on the same page and the project moving forward as efficiently as possible.

4. We had highly available, dedicated teams on both sides assigned to the project.
This is an important detail. Having both a dedicated and cross-functional team—with all the key stakeholders—on both sides of the project is critical. Without it, you won’t be able to make progress quickly enough and predictably enough to have frequent reviews. You won’t get accurate and complete feedback to move efficiently from iteration to iteration. You won’t be able to sustain the flow of interaction and results that is needed to really make this work. It’s very difficult to do Agile in slow-motion, or without everyone participating.

Some firms ask the question, “how can we do Agile if our resources are torn between projects, or the key stakeholders can’t afford to be fully involved”? My simple answer is that if you want to succeed, then you must focus, you must make the time, and you must get the involvement. Being Agile requires an organizational commitment!

5. We began testing the integration immediately and with each iteration.
I know well the headaches integration points can cause. Incorrect or overly optimistic assumptions are frequent, and QA can be lengthy and troublesome. This is a common problem when integration is saved for the end of a project, and a lot of backtracking has to occur to figure out why things aren’t working.

To address this, we delivered our prototype code on a weekly basis for the client to integrate into their test environment. Sure, it wasn’t the complete enchilada, and not every integration point was there, but we reasoned that the sooner we started checking things the better. The benefit was that each week the client could give us QA feedback from inside their environment, and we could work through issues during our twice-weekly technical reviews. It was time well spent.

6. We did “UAT” all throughout the project instead of at the end.
This is really part of my earlier point about having weekly reviews, but it’s worth calling out specifically. In a truly agile process, user acceptance testing happens all throughout the project, with each review of each iteration. Each review should have something the stakeholders can look at, and ideally, interact with. At each review, requirements may change, new requirements may emerge—but some requirements will be considered satisified.

By the end of the project the client will be looking at something they’ve seen and tested numerous times before—they know exactly what they’re getting, why it is the way it is, and how it got there. Having followed this process, our client was very comfortable calling the project complete.

To put it simply, if you still have a lengthy “UAT” phase at the end of your project you’re still largely following a waterfall process. The key is to get the stakeholder involvement to perform UAT on a frequent, iterative basis. Not always possible, I know—but that is often the difference between a truly agile process and one that only approximates it.

Conclusion

The part I like best about Agile is that it makes things easier for everyone involved. Development is easier and less stressful, project management is more straightforward, and the client is happier with the results and the process. We were fortunate to fall into this category, and develop both an amazing deliverable as well as a great working relationship with our client. Of course, I can’t do this every time, on every project—remember, we have to have the right ingredients! Hopefully, however, this simple example points to some of the high-level things you need—(outside of developer enthusiasm!) to help practice Agile in any environment.

Don't Let Your Tools Dictate the Way You Work

I laughed when I first read about what some Agile coaches recommend using as “tools” for managing projects. Pens and notecards? Sticky notes and whiteboards? Isn’t this what software is for?

Why use “stone age” methods of keeping a backlog or tracking project information when software should be easier to update, is more convenient, secure, and allows remote access?

Of course, I’m not the first to think this way—for most companies wanting to adopt any kind of project management process, an early initiative is to find the “right software” to manage the effort.

This often results in a lengthy vetting process as multiple software vendors are evaluated. Organizational factors of many types are brought to bear on the decision. Will it run on our infrastructure? Will it play nicely with our accounting system? Do we like where and how our data will be stored? What about support and upgrades? It dawns on us that the tool will become a “centerpiece” of our operation, and much is weighed into the decision.

Usually, as the result of all this evaluation, despite our assumption that there must be plenty of solutions to choose from, we eventually only find a couple or even just one option that really fits—or should I say passes “group consensus”. Once selected at this point, the “tool” becomes an investment.

However, as the tool gains more adoption within an organization, as processes grow around it, and workflows are tied to it, it becomes more than an investment; it becomes an institution.

I’ve seen this occur at large organizations that have come to rely on platforms offered by some well-known software companies we’ve all heard of. While the salespeople for these products promise health, wealth, and wisdom upon their adoption, I’ve come to the conclusion that the folks advocating a “return” to simpler tools such as notecards and whiteboards are on to something. Why?

The simple truth is that we romanticize the idea of software, particularly in the abstract. In reality, every application, though offering great capability in certain areas, will also enforce dictates and limits shaped by the perceptions, experiences, circumstances, philosophies, and capabilities of its creators. It’s therefore rare that a software tool offers a workflow that matches our needs exactly; instead it becomes an exercise in adapting our workflow to the tool.

Another side effect is that software, particularly those rich in features, encourage us to build processes that use the tool as a substitute for personal interaction. This is efficiency, right? Can’t we can use the tool to avoid a lot of “unnecessary” conversation? Just update the statuses, attach the notes, run the reports…

This is one of the reasons project management is so interesting to me; there is often a remarkable difference between theory and practice. If there really was a tool out there that could “automate success” I’m certain it’s creators would have won a Nobel prize by now. The reality is software and web development is a human-centric, not a tool-centric or even process-centric activity. It’s as complex, nuanced, and volatile as humans are. Herein lies the key principle that I believe Agile seeks to address, and correctly so.

“Individuals and interactions over processes and tools”. The very first principle of the Agile Manifesto! What it’s striking at, I believe, is this very phenomenon that I’ve described:

• Changing our workflow and process to fit a tool, even if not ideal, instead of thinking of a tool as something which improves our ability to execute a workflow and process of our own evolution and design.
• Using a tool to build a process-centric workflow instead of a human-centric one based on interaction and collaboration.

In a way, going back to the “sitting around a table with pen and paper” approach emphasizes that we are in control and it’s up to us to solve the problems together. More importantly, less “prescriptive” tools (i.e. simpler) afford us the room to be more adaptive in solving problems, while at same time making things more accessible. Two examples are the scrum taskboard and burndown chart, both of which not only work brilliantly for projects of all sizes, but can be created and maintained with simply a writing instrument and a surface.

In my own experience, I’ve found that the process of writing requirements down on notecards and shuffling them around, or planning on a whiteboard, results in a collaborative, creative energy which can’t be duplicated with a software tool. Folks like Mike Cohn and Kent Beck—founding fathers of the Agile movement, recommend using mainly notecards and a physical wall for managing even complex, enterprise projects. This doesn’t mean that there aren’t other artifacts in digital form such as spreadsheets, documents, Visio diagrams, etc.—but that the main workflow of managing a project can be done, and done well, using simple, physical artifacts and frequent, collaborative interactions.

This is my proposition: that any project can be managed using simple tools such as a whiteboard, notecards, a simple text document or a simple spreadsheet. The reason we don’t think so is because we don’t know how. We’ve been conditioned to think project management requires fancy certifications, fancy terminology, fancy tools, and processes with fancy names.

If you don’t know, or can’t figure out, how to manage a project without a fancy tool, what makes you thing you can manage one with it? The fact is the “tool” is more likely to get in your way without you even recognizing that it’s the problem. What I’ve often seen happen in these situations is that we blame people for not using the tool correctly rather then devising a better way to deal with the way people actually operate!

That being said, I have used and I do like some of the popular Agile tools that are offered today, that do make it easier to generate a scrum taskboard or burndown chart, or other features. I’ve also found some “special purpose” tools that are particularly brilliant in individual areas such as time-tracking or group collaboration. The tools I prefer, however, tend to be simple, specialized and don’t prescribe any particular process or workflow. Half of the problem is when we try to find an “all-in-one” solution that will do everything for us. Be wary of any such claims, and question its necessity.  To truly understand our craft, I think it’s important to know how to be effective with simple tools, and to always question at what point a tool has stopped serving us and we have started to serve it.

Learning to Take a Break

I recently returned from a 9-day trip to Italy, my first “real” vacation in nearly 5 years.  It was an enlightening experience, on many levels. For the first time in a long time, I had time to think. I was free from the demands of the office, and I was unreachable by either cell phone or email. Sure, I knew there were things going on back there that I could worry about, but with no way for me to be reached or do anything about it, why bother?

It seems nearly a blasphemous statement. Our modern culture of work expects us to be “always on”. Armed with our smartphones, we are expected to react to emails and text messages at any time of the day and night. Waiting is a thing of the past. We carry laptops with us at all times so we can jump on the latest “crisis” at a moment’s notice.

Perhaps this is all well and good, and like many of us, I don’t often give it much thought. If there’s one thing our workplace always offers, it’s a good reason why we can’t take a break or afford to go on vacation. Having fallen into this trap for a long time, and having finally forced myself to take a vacation, I have found myself with a better perspective.

Fatigue is a funny thing. We tend to think of fatigue as a short-term condition—easily recovered after a frenzy of effort with just a short rest. But what is the long-term impact of constantly pushing oneself? Certainly, it makes our organizations happy, and I believe it is possible to “keep pushing forward”—after all, many of our colleagues do so day in and day out. Pushing forward, of course, means a lot of things—not just physically doing work, but also dealing with the ups and downs of an organization, stresses, conflicts, politics, and everything else that business life today entails.

Where I find myself is recognizing how my “surplus” of mental energy has waned from my own experience of this, and its subtle, but gradual impact.

Take this blog for example; for the past few months—there is no denying it—I have fallen down on the job of posting new articles. Why? It simply became harder. Many months ago, new ideas for blog articles were popping into my head faster than I could write them down. Gradually, however, the ideas began to dwindle, as well as my energy to write new posts.

More disturbingly, however, I can see in retrospect how my energy diminished in a number of areas:

• Sharpening my skills
• Developing new ideas
• Making sure my work was aligned with my goals

I know this is an epidemic for many of us, because most organizations I’ve seen are unable to stick to the practice of “continuous improvement” for any length of time. We’re all just too busy treading water, and we’re too fatigued to effectively do much beyond that.

It’s a trap! For most of us, we must take our own initiative to break out of it, as we can’t rely on our organizations to give us the time or opportunity to rejuvenate. I freely admit that this is not always easy, as I have felt the strong obligation to always be at the office, and even a sense of guilt when taking time away from it. 

Companies measure the cost of employee vacations in dollars, and are constantly scheming ways to minimize it. That might have been effective with the old industrial economy. In the new “knowledge” economy, however, where creativity defines competitive advantage, what are companies doing to ensure that they keep their workers fresh, motivated and energized? What are they doing to make sure employees don’t lose their “surplus” capacity to come up with great new ideas and insights? Hopefully, it’s to allow the appropriate downtime—and make it possible for us to take it! Having benefited from my own refresher, I resolve a return to my own personal development and blog updates, forthwith!

Moving from a Low Trust to a High Trust Organization

An important goal of Agile is to move towards being a “high trust” organization. What does this mean?

The easiest way to explain it is to compare it to a “low trust” organization, whose characteristics we have all likely experienced:

• Departmental silos
• Political “turfs”
• Waterfall processes
• Red tape and bureaucracy
• Forms and documents which must be completed to initiate or record every action
• Limited visibility into other areas, “black boxes”, “privileged knowledge”

Because of a lack of visibility and collaboration, problems occur frequently in these types of organizations--but they lack good systems for communicating and quickly solving them. Employees work as independent actors, responsible for their share of the pie. They are aware of problems, and would like them to be solved, but--there are plenty of reasons they don’t get addressed:

• “I don’t have the authority”
• “That is someone else’s responsibility”
• “It’s ______’s fault, they should do something about it”
• “If they just filled out the form/used the tool/followed the process properly we wouldn’t be in this mess!”

As a result, problems may not be effectively identified until they are quite large or late in the schedule, and even then corrective action may be difficult to take.

How did we get here? The folks involved in the development of Agile clearly studied this phenomenon quite a bit, because the first rule of the Agile Manifesto speaks to this issue:

“Individuals and interactions over processes and tools”

Individuals and Interactions. Discussions over documentation. Cross-functional collaboration. The “secrets” of Agile have much to do with nothing more than communicating better with our fellows!

The problem is, many organizations emphasize the exact opposite--tools and processes over individuals and interactions. Doesn’t it feel disempowering to be stuck in a process you can’t control? Does it feel like others in your organization behave in a way that is stupid, irrational, or irresponsible when their group gets in the way of what your group is trying to achieve? Such feelings are the byproducts of the “silo” heavy organization.

It’s a failed concept that more formalized processes, more forms, more documents, more sign-offs lead to better and more predictable business results. What it leads to instead is a cumbersome, slow-moving organization that is unable to react well to dynamic and changing circumstances. Worse, however, it sets the organization on a downward trend—because it fosters low morale and low trust between its employees.

I wonder how many millions—or even billions—of dollars in cost companies pay for their companies to produce documentation whose main purpose is to replace face-to-face communication. I would wager it takes probably an hour or more to write a good substitute to a 15-minute conversation! Even then, I expect the lost nuances in interpreting the written substitute may result in 3 or more hours of lost productivity later down the line when the misperception is caught and corrected. For those issues that are not communicated at all, the costs rise exponentially. As a result of this, the finger-pointing begins, which takes us to the root of this whole “low trust” thing.

Getting out of this trap requires discipline—and a little courage. Learning to solve problems as a team takes practice. Working together cross-functionally takes practice. Opening your work and status to the team takes practice. And it takes trust—because in order to work this way, team members have to not only trust each other, but trust that the spirit of collaboration and shared ownership will be maintained, that there is integrity in the system.

This is an important point. In order for folks to believe in a collaborative process they have to trust that it will be respected, kept intact, and adhered to, consistently. When they don’t, it’s back to filling out forms, pointing fingers, and protecting their share of the pie.

If, however, the collaborative process is maintained, with discipline and consistency, people will not only being to trust in it, but also start trusting in each other. As they work together they will begin to understand and appreciate each other’s point of view, and the practice of solving problems as a team will “gel” them.

Easy to get there? Not always. Possible? Absolutely. One of the reasons I’m such a big fan of Agile is that underneath all the techniques and best practices is simply a better way for people to work together. We measure our organizations on speed, productivity, profitability—but what about trust? If we consider it carefully, I think we will find the latter precedes the former.