Zero Training Budget

~ “The most effective budget for training is nothing.”

In mid-2009, I sent a large portion of my technical staff to SharePoint training held by a top notch training firm out of Dallas, Texas. The training was held in the Dallas Infomart, which is a large white-and-windowed structure designed – by no coincidence – to imitate the late Crystal Palace that graced the London Great Exhibition in Hyde Park in 1851 and which burned to the ground in 1936. At this time, SharePoint was all the rage in the corporate enterprise technical circles, so as you can imagine I selected this technology as a “must have” skill for my top developers. It didn’t hurt that we had begun development on a web portal solution which used SharePoint’s workflow, approvals, and content management systems as a foundation.

I selected what I felt was a combination of my top technical talent, and those who would likely support the system once it was fully developed and put into production, and searched for training. These folks had very little say in the training – it was selected and approved based on the perceived “need” by myself and senior management. Eventually, I settled on the training mentioned above at great expense to my company. I felt that the training was needed, and represented a very real investment by the organization, which would pay the dividends of better software and faster development in the future – and to a large extend this proved true for my team. However, this came at many thousands of dollars, and was not true for everyone in attendance.

I had sent an abnormally large group to the training class. Out of 20 or 25 slots, my team occupied close to half. The other half of the students came from different private organizations and government agencies, and were also attending – as my staff was -- at great expense to their organizations. I sat in the very back of the class where I could observe (i.e. monitor) my staff, and could also see the screens and activity of almost everyone in the class.

Early into the training activity, it became clear to me that many of the attendees did not seem interested or find value in the class. One small group of ladies, who were working in some capacity for the state of Texas, spent almost the entire 3-day course perfecting their skills at Farmville for Facebook. Hour after hour they grew cultivated digital crops and – I’m sure -- generated pages of Facebook status spam on their friends' pages.  In fact, most of the participants from other companies were checking email, surfing the internet, and pretty much doing anything but trying to absorb the training that was being provided. And this class cost the company multiple-thousands of dollars per student!

It is clear to me that selecting employees to send to a pre-selected class using “company dollars” is not the best way to get the most of your staff members-turned-pupils. They may be disinterested in the material. They may not see the value to themselves, their work, or their career. In general, people tend to place a lower value on things which are free, and these types of training activities are “free” to the employees. They pay no tuition. It is simply a “get out of work” day. It's like a mini-staycation, away from work and family. Who wants to spend a ton of energy and focus on a staycation? These problems can be compounded when the classes are pre-selected (or provided as a list of “pre-approved” classes). They are still free. They are still “closed,” in the sense that there is very limited freedom to be creative with one’s own learning and self-improvement.

In addition, there is no obvious benefit for absorbing the training content (ignore for a moment the personal growth benefits). No punishment if the training material is not learned. In many cases, there is no test, no validation, and no understanding of the value of the training. Many times management will ask the employees to review and rate the training. Inevitably, each employee will say in turn that it “was great” and that they “learned a lot.” Who wouldn’t say a free staycation away from the office was “great”? I certainly would.

Software development is a tumultuous and constantly evolving profession. Not unlike the life of a shark, to stand still is to drown in your career. One must constantly train – not just in new technologies, but also in other areas that allow the software professional to think differently and creatively about solving problems. In many ways, software development is a craft that is dependent on the individual skills of the craftsmen (and craftswomen) that create it. In order to understand how to get the most out of training, one must embrace the fact that every developer-craftsman will have different and unique training needs, and that training is only successful if there is some value to the employee, some reward for seeking and accomplishing training, and some way to measure it.

The ideal training program would cater to these differences in developers and allow them to grow along both technical and creative lines; a program with some flexibility toward seeking personal goals, which are both more rewarding and more keenly sought-after. But it should not be completely self-focused study. In order to be an effective part of a corporate training plan, there must be some level of management oversight to ensure that people are progressing, seeking training that benefits the company, and meeting their training commitments. What kind of program would enable these things?

People like games. Playing games is a sign of intelligence, and small children learn much about their world through the playing of games. Even adults benefit from the participation in game-like activities, through which the drive to win enforces learning and performance (think “Trivial Pursuit”). What is it about games that attract people? First, there is a clear goal. It’s always about winning and achievement, but the methods differ wildly. Sometimes games require strong teamwork, and sometimes it is individual achievement. Either way, the game is fixed on a set of clear objectives. With clearly defined goals and set rules, people can find enjoyment at playing – even if they don’t outperform their rivals and ultimately lose. I think this idea of gamesmanship should be taken into the corporate training arena.

What I have found effective in my organization is to define a game of sorts, where each employee is required to collect “points” towards training with a specific point value due at the end of the year. These “training points” would be assigned at different amounts for different types of activities. The activities would be broad categories of training activities to allow the individual developer to be self-directed in the exact training that they pursue. The training point goals are also flexible; so that there is a gradient scale of points required based on the seniority or level of the developer (i.e. architects require more points than junior programmers). The training activities must be approved my management (i.e. corporate management oversight) so that they in some way are applicable to the individual’s job, and then completed and rewarded with point.

For example, let’s pretend that a junior developer needs 100 points by the end of the year. We may define points for categories of training, such as “posting to the company blog is worth 1 point,” or “reading a technical book” is worth 10. Maybe even achieving a certification or presenting a “lunch and learn” to their fellow developers would be worth points. Assume that the junior developer is really interested in UI development, and wants to read a book about how people perceive color, so that they can learn more about laying-out and designing the main login pages for a large application. This is not a “technical” book, in the sense that it is “C# Programmer’s Guide,” but it is related to the job, so the manager approves. The employee reads the book, records the points, and now is 10% completed towards their year-end training goal. Did the employee get something out of it to help their career and along the lines of their interests? Yes. Did the company get anything out of this? Yes – a programmer better able to put together a top-notch login page. How much did this cost the company? Zero dollars (excluding the cost of the book, of course).

The nice thing about this point system it is becomes very easy to identify those employees that are not seeking self-improvement through training. Although the points should not be used as an absolute system of judgment, it can help to initiate a conversation between a manager (or the team) and the individual. “Why are you not seeking training? Why are your points so low midway through the year?” It also makes it easier to identify high achievement, and take this into account during year-end performance reviews or when increasing merit-based compensation. I usually set the expectation that individuals should be plus-or-minus 10% of their training point goal; anything under that does not meet my expectation, anything over that exceeds it. However, it is up to you to put into place a point system and review process that makes sense for your organization.

Now, is “the most effective budget for training is nothing”? Not really. It is better to have an unlimited training budget and to spend lavishly on your employees (and have the revenue to support it!). But I feel that the best way to put together a training plan for technical staff is to start with a budget of $0 and construct a program which follows the lead of the developer, and does not force it. That allows for creativity in learning and flexibility in achieving one’s own training goals. And then any training budget after that is gravy.

Poor IE6

Poor IE6 just won't die. Microsoft used it as a club during the browser wars 1.0 to try and beat down the competition. Did it work? For me it didn't (I'm writing this blog in Chrome 10 at the moment). Microsoft, like a spoiled child itching for his inheritance and just waiting for his parents to pass on, has created a really nice "IE6 countdown to death." Dear readers, you can find it here:

http://www.ie6countdown.com/

The College Way

~“Scrum is only useful in a college programming environment”

When I was in college, doing full-blown project management seemed like a far-off dream that was only available to “professional” software engineers.  I had studied hard about the science of software engineering. I read all those books that talked about the 5 phases of software engineering: requirements, design, implementation, verification, and maintenance. It was clear that this was the process that “real” software engineering projects used to achieve success.

In the “real world” of software engineering, a development team would take months putting together the perfect requirements document that would drive the entire development project.  There were many different ways to denote requirements and an entire language to describe them:  BRDs and MRDs, Use Cases and UML diagrams. These requirements would be paired with a development timeline that would perfectly, and elegantly, lay out the entire development schedule. Requirements documents would flow into Gantt charts, Gantt charts would describe features and dates. PMPs would feel the rush of victory as the development team put together meticulously thought-out designs and fed a team of programmers with requirements as the software architects churned-out technical specifications. I knew in my heart that this is how aircraft control systems and rockets were built!

I read deeply into Frederick Brooks’, “The Mythical Man Month” and the first edition of Steve McConnell’s, “Code Complete.” I learned about requirements and design, estimation and planning. By the end of my studies in college, I felt that I had read enough about the foundations of software engineering that I would one day grow up to be a fine programmer. Unfortunately, none of this mirrored my actual college experience building software products for my various engineering classes.

My real experience building software in college went something like this: time-box everything and do all the “required” stuff first. As a student, you know when your project starts (you get the assignment) and you know when it ends (the due date). There was no “letting the date slip” in this environment.  Failure to deliver working code resulted in a grade of “F.” Because you couldn’t let the date slip, it was important to focus on the most critical functions first. Do the 20 percent of the work first that yielded the 80 percent of what the professor was looking for in the assignment. If there was time left over, you would focus on the “polish.” This sometimes left time for other activities like LAN parties, sports, or dating.

This programming work was usually done alone or in small teams; it was the team assignments that were always the most challenging. The team would take the assignment (requirements), break it up to a high-level design, and divide up the work that needed to be complete by feature or technical area. Then everyone would code like crazy to get their part done and merge all the code back together. Then test everything and fix any obvious bugs. This usually left the minimum amount of time for documentation, which was always required for a project submission. So the documents would be very focused on specific aspects of the software and usually done at a high-enough level that if the software had to change at the last minute, the documentation would still be accurate. This documentation would basically be used to remind myself what I did and explain to the professor the purpose of the software and design. I did a lot of diagrams and high-level feature explanation back then. This “just get it done” mindset, where we tried to get the most important requirements from the assignment complete and submitted to the professor before the due date, did not fit into my vision for how software engineering should really happen. This was just “college work.”

Fast-forward to “the real world” of software development in the mid-to-late 90s. Before the Internet bubble burst. Back when IE3 and Netscape were battling it out on the desktop for the soul of the Internet. Back then I was working in Seattle at a company called IDX Systems. IDX had recently purchased a company called PHAMIS in the mid-1990s, and I was a widget in that acquisition. I had worked on a number of different projects, and they were all run in a similar way. Start with the business requirements document (BRDs), put together technical specifications, estimate timelines and put these timelines and milestones into Microsoft Project. This was followed by development and testing, then into the maintenance phase.

This was just like I expected software engineering to be done when I was in college, except for one thing – the results were not what I had expected. Instead of an elegant flow from requirements to software, all flowing through a tightly controlled project plan, I had encountered the realities of software projects. Pinning-down both the requirements and the release dates lead to a number of strange circumstances. Often times the release date slipped. It simply took longer than expected to get all the requirements completed. Sometimes there were “missing” requirements and a special team had to be put together to do the gap analysis, leading to further project delays. Sometimes the projects were released on time, but since the development time ran longer than expected, some “optional” phases were compressed, such as testing or documentation. Was this better than slipping the date? Who knows? At least we were able to say we delivered all the features on time. Sometimes all the pieces would come together perfectly, but this was a rare event worth celebrating.

IDX was a company who had its headquarters in Burlington, Vermont. One day in 1997, the technical leadership in Burlington sent a guy by the name of Jeff Sutherland to Seattle to talk to the engineers about a new way of doing software development. He had this “crazy idea” that software development should be done more like I did it in college and less like we did it in “the real world.” He didn’t call it “the college way,” like I thought it mirrored. Instead, he called it “Scrum.”

Developing business-focused software applications is more like programming projects in college than I would ever have imagined. It is important to deliver software early and often to get that critical feedback needed from the business owners. Did the new features meet their needs? Have their needs/wants changed with the delivery of new functions? The only way that you’ll know if your customer’s will give you an “A” is by ensuring that you are on-track with their needs and vision. I know that in college, I regularly discussed the state of my projects with my professors to try to understand what was needed to achieve an “A” in the course.

Time-boxing the development (called the “sprint” in the language of Scrum) is as critical in professional software development as it was in a college classroom setting. When you say that you are going to deliver software, you’d better be delivering software. Failure to deliver is one sure way to get an “F” from your customers, especially if they have changes to their business processes dependent on a software release. What exactly will be in the hands of your customers? It’s sometimes hard to say, because it is possible that not everything that was put into your backlog was completed. But one thing is likely: if you focus on doing the most critical features first, your stand a good chance of making your customers happy. Something is better than nothing, both in college courses and in software development. And if your customers derive 80 percent of the value from 20 percent of the features (like most customers do), then delivering features early and often will provide maximum benefit, in the same way that this allowed your professor to provide maximum guidance to your programming class software project. Additionally, time-boxing the development cycles will also leave time for other activities, such as keg parties, family functions, or more time at the Aikido dojo.

One important factor that allows professional software development to be run more like college is the rise of web-based applications run over the Internet (or intranet) in the browser.  Since, in this environment, every user can be upgraded or updated simultaneously with very little effort, it has changed the economics of software deployments. In the web space, there is no ability for users to “opt out” of an upgrade or to have multiple users with different versions of the software. The software is just a single version, and it can be refreshed very frequently so it makes sense to release software as often as possible. In this environment, bug fixes have a lower cost, the benefits of incremental product improvements can be realized almost immediately, and users can be involved in constant, ongoing self-training on these incremental improvements rather than waiting for a huge class on new versions.

In this way, software – like people – is constantly evolving and improving. It is less focused on the “end product,” and more focused on continual improvement; both for the software features and for the customers who consume them. Constant incremental improvement of the software allows the software to closely mirror the needs of the customer and follow them as their needs and desires change. To me, this is the Zen of the Scrum development process; process over product.

For Advanced Readers

~"This blog is for advanced readers only"


The purpose and framework of this blog is to provide a counter-intuitive statement about the Scrum software development process or about software in general, and then provide some tongue-in-cheek response and/or explanation. It is my attempt at humor and sharing, and I hope that – at the least – it is a fun blog to read. Even better would be if it helped me to crystalize my thoughts on software development. An ideal situation would be if it helped you to understand Scrum in a unique and fun way.

I plan to drive directly into the details of Scrum and software development from the very first blogs. Because of this, I must assume that you – the reader – already have a good working knowledge of both areas. Therefore this blog is for “advanced” readers only.

Unfortunately, since every software environment is different, every development team has a different cadence and need, and every organization has different drivers and goals, no purely proscriptive approach will work in all scenarios. Because of this, no one is “advanced” enough in software development to be considered an expert in every aspect of Scrum for every environment. Learning how to use Scrum in the world of software development is an ongoing processes. To me, this is the Zen of Scrum. This is why Scrum focuses on “responding to change over following a plan.” Get done what is needed to deliver great software.

Because we are all novices in some areas of Scrum and software development, here are a few learning resources:

• Manifesto for Agile Software Development
• http://agilemanifesto.org/
• A great video to learn Scrum in 10 minutes
• http://www.youtube.com/watch?v=Q5k7a9YEoUI
• Scrum guides from Scrum.org
• http://www.scrum.org/scrumguides/
• The Agile Alliance Scrum learning page
• http://www.scrumalliance.org/learn_about_scrum
• Mountain Goat Software Scrum topics
• http://www.mountaingoatsoftware.com/topics/scrum

Welcome

Welcome to Zen and the Art of Scrum! I don't mean "welcome" like I would say to my best friend who is visiting after a long absence, because I really don't know you that well.  I also don't mean "welcome" like I would say to a perfect stranger who I am meeting in a clandestine way on the first day in some 12-step program. This "welcome" is somewhere in between; it is a welcome of shared knowledge and experiences that can only be achieved after working for years in this crazy, turbulent, and wild world of professional software development.

I, like you, have been fighting the battles and driving towards success in the non-stop, fast-paced, and usually insane world of software development. I have been working with software for most of my life. In the time that I have been doing this, I have seen technologies come and go – only to return again like a rewrapped and regifted Snuggie at a white elephant party. I have also met many brilliant minds in the field, some of whom have burned-out and moved thousands of miles away to escape. I have seen – and been a part of – some great software successes and a few total catastrophic failures. I tend to obsess mostly on the failures. These are the battle scars that all software development vets wear with pride. It is these experiences that let me understand the complex and often misunderstood art of managing software development teams.

As an American, I know that we have trouble driving in certain situations. This is especially true when encountering a “roundabout.”  A roundabout is elegant in its design and brilliant in its simplicity. It’s a circular junction where multiple roads converge. It is simple in that you only need to yield to the traffic to your left (or right in the UK) and you can connect to any of the adjoining roadways. It keeps traffic flowing, reduces stops, and even saves on fuel. Unfortunately, it is almost totally alien to Americans and for that brief moment when one is encountered, completely baffling. I once sat on a patio at a Gloria’s restaurant that overlooked a roundabout in the middle of an outdoor mall in Garland, Texas for almost 2 hours watching the traffic. It was possibly the most hilarious study of traffic patterns ever devised (of course the sangria didn’t hurt). I watched cars stop before entering, which backed-up traffic for blocks. Time and time again, I saw cars that refused to yield, almost causing a pileup. I even caught a few cars that went the wrong way in the roundabout! If you can think of a wrong way to use a roundabout, I’m sure there was a car using it on that day.

Why does all of this roundabout stuff matter? Well, because many times business leaders and IT managers have grand visions for how they will run their software product teams. They have great maps about how much ground they will cover and how fast they will get their product / enhancement / customization to market. Unfortunately, these lengthy, tightly-designed road maps often overlook the simplest details, and the development teams fail to reach their destination because they get stuck in a roundabout somewhere along the way. They spin round-and-round on the path instead of focusing on the destination. It is important that everyone who is involved in the creation of software in these teams understand the processes and expectations (i.e. rules of the road) before a development team can truly be successful. Unfortunately, the rules of the road change in every country, and the best software development practices tend to be slightly different at each company, and within each development team.

In recent years, "agile" has become the software craze. "Go agile and everything will be better" is what development teams and software managers sell to their executives as a way to get better results in a faster timeline. To many under-experienced business folks, “agile” means “go faster”, which in turn means “more profit.” It is easy to take aim at the neophyte, “non-programmer” types in business as some type of necessary overhead, obviously unaware of the needs of the development community. But it turns out that these folks who do not contribute a line to the codebase actually care about something meaningful; winning against the competition which wants nothing more than to put you (and your company) out of business. For the business leaders, it is important to understand what agile is, and is not, so that its benefits can be realized in an organization focused on software and profit.

To some in the software development world, “agile” means “no processes.” I have interviewed hundreds of prospective employees who’s resumes assure me of their “expertise in agile.” But many of these candidates seem to think that agile means that they write no documentation and meet every day for 15 minutes. Although it is certainly possible to be a successful software company only following these two rules, I have always felt that it was important to understand why I was doing what I was doing – not to just do it.

For many software professionals who have read deeply on agile and followed its steady rise over the past decade, the agile philosophy just seems to Make Sense. Trust people over processes. Working software is the best form of documentation. Stay close to your customers and adapt. Unfortunately, many of the truisms of these agile approaches are completely lost on the decision-makers within an organization. Many times, some of the details are even lost on the teams! A battle-cry of "go agile" that yields an initial failure can have catastrophic consequences to a development team, or even an entire IT organization. In this blog, I hope to explore some of those truisms in an irreverent and whimsical way, and try to get to the underlying reality that is the processes and management of software development teams.