YAGNI - Reaping the Benefits

People take different approaches to software, and we find that some of these work better for us than others. I'm a big fan of the YAGNI principle ("You Ain't Gonna Need It"), but historically it hasn't been much of a problem for me. But I came across an example of how it helped me recently -- even though I wasn't conscious of it at the time.

YAGNI: You Ain't Gonna Need It

The basic idea behind YAGNI is that we shouldn't code based on speculation of what we might need in the future. Business processes change, user needs change, and our software needs to change with it. If we build what we think we *might* need, odds are that we'll be wrong and that part of the software will remain unused. And that leaves us with code that is more difficult to navigate and debug without giving any benefit.

Historically, this has not been a big problem for me. My nature is as an under-abstractor. This means that I tend to lean away from abstraction. I add abstractions as I need them (and generally not before) because I've been burned by badly implemented abstractions that were put into an application "just in case".

So when we think about YAGNI, we think about the requirements that we have *now*. This doesn't mean that we don't think about the future; it just means that we don't build it yet. We should be thinking about the possibilities of our applications, and we should make sure that we don't code ourselves into a corner when we're writing them. But rather than adding the full abstraction (such as a plug-in architecture), we think about where we would put it if we needed it. Then we make sure that we leave a spot where we can add it later.

Making Things Easier

Old Application

One thing that I've been writing about recently is an application rewrite of my home automation software. Articles are collected here: Rewriting a Legacy Application. This is software that I've wanted to rewrite for a really long time, but I was too wrapped up in the complexities of the old application. There were a lot of features that had grown over the years, and it seemed like a daunting task to rewrite the whole thing.

So, I took a more practical approach: distilling things down to just the features that I actually needed -- the features that I used on a daily basis. This helped me create the requirements for a minimum viable product (MVP).

This process let me distill the entire application down to 3 features that I actually used. The other things (like UI, network access, and schedule editor) were all nice to have, but the more I thought about it, the more I figured that I didn't need them. For example, there's not much need for a UI. This application is always running on a machine in my house that's plugged into my TV, but I rarely look at the screen on that machine (it primarily just plays music and runs the lights while my TV does other things).

Rather than a huge, daunting task, this became fairly simple. In fact, I implemented the entire replacement in just a few days. Since then I've been refining it and adding new features, but that base replacement functionality went very quickly.

Leaving Room for Changing Priorities
So, I really took the YAGNI approach to most of the features in the old application. And that has turned out to be true. I've been running the software in production for a little over a month, and I haven't missed the features that I left out.

More importantly, I've been free to go in a different direction. The biggest example of that was when I added the ability to create schedule items relative to the current sunset or sunrise times. That original ugly code is in a much better state now (and it keeps getting better).

This code has been in production for a few weeks now. I currently have 2 items that are scheduled relative to sunset. A light in the living room goes on 30 minutes prior to sunset (when it's just starting to get dark), and a light in the bedroom goes on 1 hour after sunset. These are both ambient lights, and I've enjoyed watching them come on at different times as the days get longer. When I put the code in, the first light came on around 4:45 p.m., and now it comes on a little after 5:00 p.m.

But since the application is fairly "raw" as far as the architecture is concerned, I haven't committed to going in a particular direction. This has made it easy to implement this new feature (which had nothing to do with the old application). And I look forward to adding more features as I need them.

Wrap Up
So rather than getting bogged down in things I *might* need or I think I *should* need, I'm able to focus on the features that I *actually* need.

I do have some examples of where YAGNI has helped me in the past, but it's nice to see that the principle still helps me in my current coding activities -- even when I'm not consciously thinking about it.

For more information on YAGNI and other principles to help us with abstraction, check out the materials I have for Abstract Art: Getting Things "Just Right", including a Pluralsight course, slides, and a variety of blog articles.

Happy Coding!

No Estimates Minus Continuous Delivery Equals ???

I'm still thinking about No Estimates. So far, I've talked about how the business already behaves with a No Estimates mindset, about how developers need to be an integral part of the business, and about how organically grown software adds value to the business (and more here).

There are a lot of things that attract me to this mindset. And I also have quite a few reservations. I understand that tools have their pros and cons and that no tool is the right answer for every situation. The same is true of No Estimates. It definitely has a set of problems that it targets, but there are some other problems that aren't addressed. I don't expect that No Estimates has an answer to these problems, but I'm wondering if there are elements that we can incorporate into these other environments.

Continuous Delivery (or not)
Continuous Delivery is an amazing thing. If we can release updates to our software with a regular cadence at (hopefully) brief intervals, we can keep adding value to the business without having to wait for quarterly releases or "big bang" updates.

The examples of the organically grown software fit in nicely with the idea of continuous delivery. Although there wasn't a regular cadence, we did keep adding functionality in small pieces which gave the company value on an ongoing basis.

And for many of the other projects that I've worked on, many of them could have been split up into small chunks that were delivered on a regular basis (after hitting that "minimum viable product" stage). But there are some other projects that are more difficult to break down to fit into a continuous delivery process.

Quarterly Releases
As an example, I worked for a company that produced authorization software. Anything security related is already under high scrutiny. And on top of that, this was software that is installed at the client's site (and often isolated from external networks).

In this environment, there is no way that we could do weekly or monthly releases. When we had a new release, our clients would set up development and QA environments to test the new product. This included both functionality tests and penetration tests. Only after the software had gone through this process would they install it in the production environment. This process could take several weeks. So even if we were doing weekly releases, none of our clients would upgrade on that schedule.

So, you might suggest that we do the weekly releases, and then the clients can pick which features are important to them and upgrade when they find something compelling. And that initially sounds like a good idea. But our support system made this nonviable. When a client called with an issue, we would need to replicate their environment in the lab and then possibly provide a patch if the software had a problem.

This meant that we needed to keep working branches of prior releases available so that we could patch that particular release (without forcing the client to upgrade to the latest version).

"Big Bang" Release
As another example, at a large company, there was a project to replace an aging scheduling system. Scheduling tens of thousands of employees on a regular basis is difficult enough, but when you add the various rule sets that come from state regulation, company policy, and union contracts, things get complicated. (Fortunately, I was not on this particular project, but I did get to interact with a lot of people who were.)

This is where it becomes difficult to come up with the "minimum viable product" for the initial release. If you target one group of employees, you find out that their particular union covers more than just that group, so you need to expand the scope of employees included. If you manage to find an isolated group, you find that some of the employees move back and forth between departments (depending on how busy things are).

When you take the variables into account, the "minimum viable product" comes so close to "full replacement" that it doesn't make sense to do things incrementally.

And I'll be the first to say that this is a difficult way of doing things. There's no way to get everything right the first time (especially with this type of release), which means that the first six months after release are going to be a bit painful for the users and the development team.

Moving Into The Ridiculous
This can stray into the territory of "What the heck are you thinking?!?" I came across a group of business analysts who were collecting requirements for one of these large, company-wide projects. They were on a 24-month requirement gathering mission. Let me repeat that: 24-month requirement gathering mission.

That's 2 years! Even in a slow-moving corporation, things are going to change faster than that. By the time you get to the end of 2 years of requirements gathering, you'll just find that the business has changed, many of the features are no longer needed. And there will be a gap for features that are truly needed but came up too late to be included.

No Estimates - Continuous Delivery = ???
Now some of these examples are extreme, but it does bring up the question: can we get benefit from the principles behind No Estimates even if we are not in an environment where we can implement Continuous Delivery?

For example, in the quarterly release scenario, each of our clients had features that were important to them. It's not really possible to give each of them a "yes that's in this release" or "that will be in the next release" unless we are doing estimates on how long the various features will take, how much bandwidth we have from our development team, and what our planned release looks like. Definitely not a "No Estimates" mindset.

I don't have the answer to this. It may be that we need to come up with better ways of determining what the "minimum viable product" is. This is not too hard when working with green-field development. But when working on system-replacement projects, it's a bit harder to convince the business area that they need to stop using one function in the old system so that they can use it in the new system (especially when there is no practical way of actually disabling the feature in the old system).

It may be that we need to have better delivery mechanisms. If you are deploying just to your own servers, then it becomes much more practical to do weekly or daily releases. And there are some web-based companies that do multiple releases throughout each day.

This is a viable solution for server-based software that we run on our own servers or put into the cloud. It is more difficult if the software needs to be installed on servers at a client location. (And I would bet the majority of clients don't really like the idea of "auto-update" on their servers -- but that thinking will gradually change as people integrate more cloud solutions and see more and more successful updates.)

Wrap Up
As you can see, I've been thinking quite a bit about this. I really like the idea of No Estimates, development by subscription, and continuously adding value to the business. I think that I've identified a number of scenarios where this works well, and it really just requires buy-in from everyone involved.

But there are some scenarios where it doesn't seem to fit at all. I don't want to abandon the ideas (because they are good ones), and I'd like to see if there are small elements that we can bring in to these projects to improve the development process.

No tool is perfect for every job. But there's got to be some good principles that we can bring over into these other environments.

For more info, feel free to join the #NoEstimates discussion on Twitter, or look up Neil Killick or Woody Zuill. And I'll be glad to hear any of your insights on this topic.

Happy Coding!

More Organic Software: Escaping Into the Wild

A couple days ago, I wrote about how an application I wrote for myself escaped into the wild and became added value for the company. But I also had this happen with another piece of software that I wrote for myself. The way it grew organically based on business needs makes me think about how No Estimates can be appropriately applied in similar situations.

Working with Time Clocks
In addition to working with automated turnstiles, I also worked with the time clock system. Specifically, I worked with the time clock hardware and data collection. This was then transferred to the time tracking system (which was the "system of record" when it came to time tracking).

The time clocks worked with similar hardware as the turnstiles, and so I would check them every morning to make sure that the everything was online. Initially, I used a set of SQL scripts to check this, but as you can imagine, I ended up writing a little application to help me out with this.

This application had a drop-down box that listed all of the time clocks and a data grid to show the latest transactions. Again, I could easily scroll through the drop-down and see which time clocks were reporting data. This required a bit more thought, though -- some time clock locations were used more heavily than others. For example, the time clocks at the site entrances had a steady stream of transactions, but the time clocks that were in the maintenance shops were only used by a small group of people, so it was normal to have sporadic transactions.

Escaping into the Wild
The scheduling team would use the time tracking system throughout the day. They would make adjustments if someone clocked incorrectly (or forgot to clock in/out). And they would also check for "no shows" -- people who did not show up for a scheduled shift.

Because of this, the scheduling team was more dependent on having the data consistently sent to the time tracking system throughout the day.

One of the schedulers saw my application and said, "Can I have that?"

And the reason turned out to be pretty simple. If he saw a gap in the time tracking system, he could check to see if a particular time clock was off-line. If an employee regularly clocked in at the west entrance, he could check the 3 time clocks at that location to see if they were all reporting data.

If one of the time clocks appeared to be off-line, then the scheduler could contact my team to have it reset. This gave them better visibility to the system, and they knew that if a time clock was off-line, they would not necessarily mark "no shows" for people who normally clock at that location.

More Features
I think it's good when a business area asks for more features. It shows that they are thinking about the technology and data that we have provided to them and coming up with new ways to use it. So, I wasn't really surprised when I got a request for more features in the time clock viewer application.

We had security swipes at the entrances to the site. This would allow the security team to easily check that people were allowed to enter the property. The employees would swipe their card, and get a "go" or "no go" based on whether they were an active employee (cards would get automatically disabled if someone quit or was let go). But this also meant that people who needed to clock in had to swipe again at a time clock.

To streamline this process, we combined the security system and the time clocks. We used the time clock to collect the card swipe (either a bar code or RFID) and then pass the card information along to the security system for validation. This resulted in a single swipe for people who needed to clock in as well.

But there was a process issue: the employee would need to press the "Clock In" button the time clock before swiping his card. If you did not press the button, the security swipe would be processed and you would be allowed on property, but a time clock record would not be generated.

"I Forgot"
As you can imagine, when people do this everyday, sometimes they forget to push the button (as they are maybe rushing too quickly one day), or they think they pushed the button but it didn't register, or they simply forgot to check for the "clock in accepted" message that would normally display.

If someone forgot to clock in, the schedulers could manually add a record to the time tracking system. But because this was a common occurrence (especially when there are several thousand people clocking in throughout any particular day), the schedulers wanted a bit more information.

You see, some employees had figured out a way to game the system. If they got to the clocking location and found that they were 2 minutes late, they could "forget" to press the "Clock In" button and ask their scheduler to override it. This would mean they wouldn't get penalized for being late.

So the schedulers asked if there was a way for them to get the time clock data combined with the data from the security system. This way, they could look up an individual and see what time the security swipe went through. This would let them check to see if people were actually late when they came in, and it would allow them to separate the people who forgot to clock in from the people who "forgot" to clock in.

Business Changes - Things Get Complicated
Whenever you deal with time tracking, things get really complicated. There are federal and state regulations, there are company policies, and there are union rules -- all of which need to be followed.

One change that came about was the ability to clock in and out at your work location (instead of the property entrance). The reason is that it could take 10 to 15 minutes to get to your actual work location from the property entrance. You were supposed to be at your location and ready to work at your scheduled time, so having a time clock at the location would help better track that.

Unfortunately, the time tracking system didn't have this level of granularity. It kept track of "clock in" and "clock out", but not the particular time clock that was used.

So, we were asked to come up with some printable reports that could be used by the location managers based on the raw time clock data. These reports would allow a manager to see all of the clock transactions for employees in their area (based on their department identifier). The manager could double-check that their employees were clocking at the right locations, and they could coach employees who needed a reminder on procedures.

Later on, we extended the functionality of these reports to show "exceptions" -- such as people who clocked in but forgot to clock out, or for people who clocked in and out at different locations. This let the management teams focus on where specific problems lie.

And all of this helped the company comply with the various contractual rules and legal regulations that governed the time tracking of employees.

Wrap Up
So, here's another example of an application that grew organically as the business areas saw places where we could add value. And it's another good example of how No Estimates could work well in a changing environment.

And even though I've come up with some good examples of where No Estimates would be effective in projects I've worked on, I've also been thinking about some situations where it would not be a good choice. (I'll be writing about these soon.)

This doesn't bother me, though. No tool is perfect for every situation. I wouldn't expect that No Estimates would be a good choice for every situation, either. What's important is that we take a look at our current processes, determine what's working and what's not working, and look toward improving things where we can.

Happy Coding!

Organic Software: Spreading Usefulness

I've often mentioned that I've built the most successful software by understanding the users and their day-to-day business. But sometimes, I make something that is useful for myself, and it grows in unexpected ways.

Working with Turnstile Counts
I spent may years working for a major theme park. I actually worked at the company for 5 years before joining the I.T. team as a junior developer and hardware assistant. As an assistant, I worked with Doug (the technical lead) on automating the attraction turnstiles. Prior to automation, turnstile counts were collected on the device (usually a mechanical turnstile with an LCD screen), and the employees working at the location were responsible for writing down the counts from the LCD screen every hour. Then they would manually enter the counts into a tracking system.

The automated turnstiles were network-connected and sent their counts to a server every 15 minutes. This was great for the people working at the location because they no longer had to do the manual recording process. On top of that, we could automatically transfer the counts to the tracking system.

But there was a problem: the early versions of the network modules were a little flaky and would go off-line. None of the data would be lost, but the network module would need to be reset to send the data to the server.

One of my jobs was to check the turnstile controllers every morning. This involved running some SQL scripts against the database and looking for "gaps" in the data. If a particular controller had not reported data for a while, I knew that the controller needed to be reset.

Lazy Programmer - Productive Developer
As we converted more and more attractions, this process became a bit more tedious. When there are just a few controllers to look for, the gaps were very obvious. But when there are several dozen controllers, the gaps in the data are harder to find.

I'm a lazy programmer, and so I did what any lazy programmer would do when faced with a repetitive task: automate it.

Okay, so I didn't go full automation. But what I did was put together a simple application. It just had a drop-down box and a data grid.

The drop-down box had a list of all of the turnstile controllers. When a controller was selected, the grid would show the data for that one controller (with the most recent record on top). This made the job of checking the controllers very easy: I could just scroll through the drop-down box and look to see which items did not have current data.

The Application Escapes
One day I was reviewing the data with one of the managers from the area. When she saw my little helper application, she said, "Hey, what's that?"

I demoed the application and showed the raw data that came from the turnstile controllers. And she said, "Can I get that?"

The reason for this was simple: the manager had access to the tracking system which gave data that was one day old (yesterday's data). The little application that I had provided current data (well from the latest 15 minute data block, anyway). The manager really liked the idea of being able to access the data throughout the day. This way, it could be acted upon immediately.

For example, if the counts were zero, that may indicate that that the attraction was down (maybe due to a mechanical fault). If the counts were lower than expected, it could indicate that there is a staffing problem at the location that lowered the throughput. For either of these situations, the manager may want to go to the location to check what's going on.

So, I cleaned up the application a bit. I parsed the raw data into columns that the operations folks could easily understand. And I also added some total columns (for example, if there were 3 turnstiles at a location, they came through as separate records, but the operations folks were more interested in the total counts for the location. Another example, the counts came in 15 minute intervals, but they wanted to see hourly totals since that's what their operational metrics were based on).

Soon, there was an application that I had originally built for myself that was now being used by about 50 people to help them do their jobs better.

More Functionality
After the conversion from manual turnstiles to automated turnstiles was complete, this application now had all of the raw data for the locations. The managers and leads could check the data throughout the day.

As expected, the operations folks came up with some new ideas for the data. First was the idea of notifications.

At regular intervals throughout the day, they wanted to receive email or pages that had the current data. This meant that people working in the area (and not at a computer) could still take advantage of the data.

This wasn't difficult for us. We already had a notification system that could send out email or pages to different groups and individuals (we had lots of Blackberrys and Motorola pagers in use at the time). In fact, the biggest part of adding this task was to build some maintenance screens. Each person could choose which data they wanted (they could select just a few attractions or all of them) as well as the times they wanted to be notified (for example, every hour during normal operating hours) as well as the days of the week to be notified (so they would only get the information on days they were working).

This added about 50 more people who could access the data on a regular basis to help them keep the business functioning efficiently.

Yet Another Feature
The next step was to add "alerts". For each location, they could enter a target number and a warning threshold. For each page, we would include the current count plus the target number for reference. And if the current count fell below the warning threshold, that would trigger a separate set of "alert" pages.

And Another
The last major feature that we added was a summary email that was sent out every morning. This would include a summary of the prior day's data so that directors and area managers could track how things were going. This replaced a manual process that the attractions staff was doing.

Now the leadership team was able to directly benefit from the data collected.

Organically Grown
Now this isn't a process that happened overnight. These features grew over a period of several years. But the interesting thing about this is that it was not a set of features that was originally requested by the business area. It was something that I built for my own use that happened to have usefulness beyond just me.

And I think that's why I have such an affection for this particular application. This wasn't a "project" that the business area came up with. When the turnstiles were being automated, the primary benefit was to eliminate the labor spent collecting the counts manually (and the potential for transcription error) and putting the data into the tracking system (with potential for more errors).

No one asked for a system that would page (near) real-time numbers to the operating areas. But once we had the data, and the users in the business area started to see the how they could benefit from it, things just grew naturally.

We discovered value incrementally over time. And the end result had a lot more benefit than anyone had anticipated.

Wrap Up
So, this brings us back to the idea of "No Estimates". It's not just that we are bad at estimating features that are asked for by the business area. It's that we don't even know where the real value lies when we start out on a project.

This really shouldn't be a surprise. One of the major tenets of Agile is that we adjust our direction when we need to. When we see potential value, we're allowed to shift our current direction to pursue that. And these feature requests came in small chunks. At the beginning, I never would have been able to put together a viable estimate/plan for "send out current turnstile counts to selected individuals". But because we took things one step at a time (raw data, formatted data, summarized data, notifications), we were able to get to this unexpected result that added value to the company.

I guess I'm convincing myself more and more that I like the idea of No Estimates. When I look at projects that added real value to the company (like this one), it seems like we pretty much worked that way. (There was some project overhead, but minimal compared to most of the applications we worked on.)

I've got a couple more stories like this one that I'll be sharing soon. In the meantime, keep thinking about ways that you can be an effective developer and add the most value to the company.

Happy Coding!

I Am Not A Supplier

Based on yesterday's thoughts on No Estimates, the discussion rolls back around to how I see myself as a developer:

I am not a supplier.
I do not simply provide services.
I am part of the business.
I provide value that moves the business forward.

As a developer, my goals are the same as the business I work for. I want to see the company succeed. The way I do that is to make the business run easier, more smoothly, and economically through the software that I build.

I am just as much a part of the business as Marketing, Strategic Planning, Operations, Sales, HR, and Maintenance. My role as a developer moves the company forward just like every employee of the company.

But this is not necessarily how the company sees me.

Just a Supplier?
This is a topic that I've written about before, and my thoughts have been coalescing over the years. At a company that I worked for, there was a Vice President of I.T. who had a goal: he wanted to be asked about the color of the carpeting in the new building.

What does this have to do with I.T.? Absolutely nothing. And that's exactly the point. In the executive meetings, the VP of Marketing was asked these types of questions, even though it has nothing to do with marketing. The VP of HR was asked these types of questions, even though it has nothing to do with HR. These groups were seen as integral parts of the company.

The VP of I.T., however, was only asked questions that had to do with technology. And this is indicative of the overall issue: I.T. as a supplier rather than a part of the company.

Coding to Specification Only

Unfortunately, many software developers see themselves as suppliers. They are not interested in understanding the business but are perfectly happy to simply code to a specification that someone else gave them. I've never been successful working that way. Only by being part of the business (and understanding the goals and how it works on a day-to-day basis) have I provided significant value as a software developer.

Common Goals & Vested Interest
This attitude of "just a supplier" has led to some issues that many companies are just now realizing. And it really comes to light with the phenomenon of outsourcing.

When you think of I.T. as a supplier, then it makes perfect sense to outsource it. It's not part of our core business, so we can get it from somewhere else -- like a utility. But then the reality of the decisions set in.

When a group is outsourced, they no longer share the goals of your company. Let's take a look at a scenario: your company sells consumer products on-line. The primary sales time is Christmas season (with a huge influx of sales on Cyber Monday).

Scenario 1: Common Goals
When the I.T. department is part of the company, then there is a common goal: success of on-line sales. So if credit card processing goes down on Cyber Monday, it's an "all hands on deck" situation where everyone is troubleshooting the issue. The network team is checking connections to the card processor; the server team is making sure that that servers are not overloaded; the database team is making sure that transactions are being committed; and the development team is checking to see how the applications are handling the loads.

Everyone is working toward one thing: getting on-line sales back up. It's what we do. It's the whole purpose for being there.

Scenario 2: Disparate Goals
Let's run that situation again, but with an outsourced I.T. department. Now the goals are different. The goal of the company is still the success of on-line sales, but the goal of the outsource company is to fulfill the service level agreements (SLAs) that are in the contract. The success of the outsource company is not dependent on the success of your company.

So if credit card processing goes down, there are trouble tickets that are opened. The company is concerned about every minute of outage due to lost sales. But the outsource company is concerned about making sure they fulfill their contractual obligations. This probably does *not* result in an "all hands on deck" situation (because that would have made the cost of the contract too high to be practical).

Unfortunately, I have seen this happen. Before outsourcing, we had dozens of team members troubleshooting various issues. After outsourcing, there was a conference call with the account managers and very little actually gets done.

There Is No "Us" and "Them"
One reason that the company treats I.T. as a supplier is because that's how we often act. We don't even act like a cohesive team within I.T. For some reason, we (as technologists) don't like to be seen as the party at fault. It may just be a side-effect of the other traits that make us good at working with technology. We like to be seen as infallible problem-solvers.

This leads to an "us" and "them" attitude with other teams inside I.T. So when a user calls in an issue with an application, we might say, "The application is working fine, so it's not us. It might be the network or database that's having problems. I'll forward you to the network team."

But we need to look at things from the user's perspective. The user doesn't care what the exact problem is or who is responsible for it. All he knows is that the application is not working, and he cannot do his job.

We need to react to the users with this in mind. If someone calls in an issue with an application, we should say, "I can't find the problem in the parts that I can see. Let me work with some other members of our team to figure out what's going on." Then work with the networking or database teams to try to nail down the issue.

And after solving the issue, the proper response to the user is, "We fixed the issue, and we're working to make sure that it doesn't happen again. But be sure to let us know if you run into the same thing." The user does not need to know whether the problem was the application, the database, or the network. The user doesn't care. All he wants to hear is that "we" (the I.T. team) have things under control.

Forming a Partnership
I've written many times about forming a partnership with the business areas. And I have been most successful as a developer when I had a good understanding of what my users needed to do on a daily basis -- the steps they went through to do their jobs. When I understood this, I could automate the little things to make their jobs easier. And I could make suggestions on bigger things that could streamline processes.

I knew that I was successful at building these partnerships when our company was hit by a round of layoffs. Most departments took a 10% staff cut. The first thing that happened was that my users were calling me for help, "We just lost 40 hours of labor; can you help us automate this process that takes 8 hours a week? That will take off some of the strain as we re-distribute work and re-prioritize."

It was these partnerships that kept us all moving forward in the same direction.

Wrap Up
What does this have to do with No Estimates? It's really a first step. Last time, we talked about the trust that is required between the business and development teams. But what if we eliminate that line that divides these two concepts? What if instead of having "the business" and "the developers", it was all just "us" -- a group of people all working toward the same goal.

I don't think of myself as a supplier. I am part of the business. I add business value. And when the business moves forward, I move forward with it.

There are times that I wished I ruled the world. I would try to spread this attitude to all of the developers who think of themselves as suppliers. And I would try to spread this attitude to all of the companies that think of their I.T. departments as suppliers.

In this world, everyone would be working toward the same goals. I.T. teams would be a true part of the business and continually add value. And companies would be more successful.

These changes are made one person at a time. I hope that you join me in this quest.

Happy Coding!

No Estimates: Development by Subscription

Last week, I spent a couple of days at Agile Open SoCal. It was a great time to talk about various issues and successes and get some great advice from other people who are in similar situations. There's a lot for me to process, and a couple of topics really stuck out.

One of these was No Estimates. I'll have to admit that I've been following this discussion from the sidelines. If you want to catch up on what No Estimates is, check out what Neil Killick and Woody Zuill have to say. I will not do the description justice, so you'll want to go to these guys who have been thinking about it for a long time.

I know Woody from the SoCal developer community, and I had a chance to sit down and talk to him a bit last week. (He's also known for showing the success his team has had with Mob Programming).

We Suck at Estimation
One of the basic truths is that we (as developers) suck at estimation. But that's not really a surprise. We are constantly being asked to do things that we've never done before.

An experienced cook will be able to tell you how long it will take a bake a cake. After all, he's done it a dozen times and knows what to expect. But for someone who's never baked a cake (like me), I would end up "padding the estimate" on how long it will take me. Is it because I don't know how to follow a recipe? No. It's because I'm working with unfamiliar tools -- I don't know exactly how to use the mixer or if I'm going to mess up a batch by over-mixing or under-mixing.

And this is true in software. Whenever I'm looking at a new project, it usually contains 4 things I've done before and 1 thing that's new to me. Now, I'm not completely ignorant of the technology (I've seen someone use the mixer), but I don't know what problems to expect (if you don't grease the bowl before you start, you won't get an even mixture).

I do not like to not deliver on my commitments -- meaning, I would rather over-estimate and deliver early than under-estimate and deliver late. The same is true in the rest of my life: I'd rather arrive at an event an hour early than 5 minutes late.

This means that I have a tendency to over-estimate:



I don't do this so that people will think of me as a miracle worker. I do this because I want to make sure I deliver on my commitments.

But this doesn't make my estimates any better than someone who under-estimates. In both cases, our estimates are wrong.

Eliminating Estimates
So, the idea of No Estimates is that we get rid of the estimation process. Instead of coming up with a huge project plan with lots of incorrect estimates (that end up compounding the problem), we focus on continually delivering small pieces of value.

I like the idea of this. And as a responsible developer, I think that it would work well for me and my development style -- I like to make my users happy, and I can best do that by constantly giving them features that make their jobs easier.

But I have been skeptical for a number of reasons. First, not all developers can work this way. There are some developers who would take advantage of the situation and slow down their delivery. There's no longer things like "story points" and "velocity" that measure productivity. And even though those measurements are probably wrong, people like to have something tangible to look at. The solution to this is to have managers who can keep track of productivity (in other ways) and know the capabilities and output of their teams.

Second, many companies cannot work this way due to their budgeting process. The financial systems are built around large projects and schedules. Marketing wants this and Sales wants that and Operations needs this other thing. So let's figure out how long each thing will take, how much our development team can handle at one time, and then prioritize everything. On top of that, money for the projects comes out of different buckets depending on whether it is a capital or expense project. I have no idea how to resolve this issue.

No Estimates is more of a subscription model for development. Instead of the business areas putting aside money for Project X that will cost $50,000 (maybe), the development team is funded on an on-going basis -- just like the other teams (finance, sales, operations, maintenance) that add value to the company.

The Business Areas Already Do This
I had a realization about this based on my experience: even though the company does not work this way, the business areas do.

I worked at a large company (20,000 people on site, 100,000 people in the division), and I built software for the various business areas based on what came down from project planning. And this was a hassle for many of the business areas. Sometimes a department just needed a small piece of functionality. It wasn't large enough to justify an entire project -- maybe just a report to collate data. And even if it were big enough, it probably would not be prioritized near the top of the list. So it may take a year or more to get it on the schedule.

The solution: Shadow IT. I don't know if there's an industry name for this phenomenon, but this is what we called it in our company. A department would have someone on staff who was more technical than most and probably good at something like Microsoft Access. This person would then build all of these small pieces of functionality that the department wanted to make their job easier.

So the business areas have already bought into the idea of development by subscription. They have decided that it was worthwhile to pay someone in their department to handle these types of things. And this Shadow IT person was paid out of the same budget as all of the other employees in the department.

(And this arrangement isn't all puppies and rainbows. Since the majority of the Shadow IT people did not have any formal technical training or experience, some of the projects would run into scaling issues or simply stop working when the data got too large. At this point, the systems were critical to the department, so they would often turn to the development team to fix the issues or rewrite the system.)

So the business areas have recognized this as a way to add value to the company. Now we just need to get the company itself to realize it.

This would give the opportunity for the business areas to have access to actual developers who can deliver functionality quickly in a supportable way.

Wrap Up
I really like the idea of No Estimates, and I hope that it gains traction. There is a lot of trust required between the company and the development teams (but I've wanted to have better integration between the company and the development teams for a long time -- that trust is needed anyway).

It was an eye-opener when I realized that the business areas had already implemented their own version of No Estimates by having a Shadow IT person on staff. Next, we need to figure out how to formalize this so that the right people (developers) are doing the right work.

Happy Coding!

2013 in Review

The end of the year is a good time to reflect. It gives us a chance to look at how we've grown and how we can make improvements for the following year. It's been a really good year for me. I'm not where I expected to be, but that's okay. I think I'm actually in a better place than I had planned.

Things I've Done
It's been a busy year. I love teaching, and I love watching people learn. I've had a lot of opportunities for that.

Speaking
I spoke at 19 events this year and gave a total of 27 presentations (details here). In addition, I gave my 100th presentation since I started speaking publicly in January 2010 (pretty good for 4 years work).

I managed to make it to 4 states this year (California, Nevada, Arizona, and Utah), and I'm looking to branch out further. I met a ton of great people at the various events. Code Camps are really great because it gives you a chance to spend a full day (or even a couple of days) with people. My network of developers keeps expanding, and I'm planning on continuing that expansion.

Silicon Valley Code Camp - October 2013

Blogging
I didn't write as many technical articles on my blog as I had hoped. Even so, I still managed to publish 63 articles. These are a combination of technical articles, announcements, and book reviews. I've been getting over 3,000 hits a month since April (with a few months over 4,000). This is double what I was getting the previous year.

Here are the top three articles from the year:

• Dependency Injection: The Service Locator Pattern
• BackgroundWorker Component Compared to .NET Tasks
• Book Review: Pro ASP.NET MVC 4

And for some reason (still), I'm on the first page of Google results when looking for MVVM Design Pattern. I'm not complaining, just surprised.

Pluralsight Authoring
The unplanned part of the year was creating courses for Pluralsight. I talked to some folks I know that have authored courses for Pluralsight, so I decided to give it a try. It has gone way further than I ever expected. This year I had 5 courses published (details here). I actually produced 6 courses, but the last one hasn't published yet -- maybe later this week.

The response that I've received from people watching my courses has been really good. And it's great to be able to reach thousands of developers through a single medium.

YouTubing
During my 2012 review, I said that I was going to produce some YouTube videos. And I did (well, a few anyway). I currently have 4 videos on my channel. And I would probably have more if I wasn't concentrating on making Pluralsight videos. I'm planning on bulking up my YouTube channel during 2014.

Things I've Learned
I am a constant learner. My preferred method is through books, but I've picked up some interesting things through presentations and podcasts.

I reviewed 8 books this year (details here). These were on various topics, including asynchronous programming, refactoring, test driven development, JavaScript, agile development, user interface design, Windows Store Apps, and ASP.NET MVC.

I didn't quite make it to my goal of 1 book per month. But I was close: I read a 9th book that I didn't review, and I'm halfway through another. We'll see how many books I get through next year.

I've been stretching my ways of thinking. I've started to learn functional programming. I was inspired by attending presentations from some really smart developers (who I'm happy to call friends as well). And I've also been working through a book on Haskell along with the Euler problems.

Whatever the method, I make sure that I'm never standing still. And one of the best ways to learn is to teach. In creating my presentations and videos, I've had to dig into the details of the topics and expand my own knowledge. And I also have developers ask me questions on topics. When I don't know the answer, I roll up my sleeves and find out.

Cool Stuff
I've had some really great opportunities this year, and some really cool stuff has come from it.

I was renewed as a Microsoft MVP for C#. This has given me the chance to attend the Microsoft MVP Summit in Washington (actually, because of a scheduling change, I got to attend 2 summits: one in February and another in November).

At the MVP Summit, I got to talk to MVPs from all over the world (in addition to seeing some really cool NDA stuff). This gave me a chance to expand my network even further, and now I have new friends in Sweden, Australia, and Washington. And I also got to meet up with friends I know from around the country from various Code Camps.

I also got an award for the C# Interfaces course that I did for Pluralsight. Since it was #1 for the month of July, I was given the Crystal Microphone. That was an unexpected surprise. I'm really happy that thousands of people have been able to benefit from the course.

And that really gets to the point of what keeps me going. I'm not looking for recognition (although that's really cool). I like to help other developers. Here are a few of the comments that keep me going. I'm not putting in names because these comments have come through various public and private forums.

Regarding a Clean Code presentation:

I immediately applied incremental refactoring on the project I am working on at work and I am making it a general rule of thumb to look for needed refactoring whenever I touch a source code file for a feature addition or defect fix.

And here's another comment from a presentation:

This session was fantastic. I have been using Lambda's for quite some time but now I know how it functions internally. The example with event handlers was something I never would have thought of. Jeremy, thank you for such a nice presentation.

And here's one more from a Code Camp this year:

Thanks again for another great class (generics). My only regret is that we get you only for an hour. Your explanations are clear and your examples are concise. Your delivery is fun, light, understandable, and conversational, even when your subject matter is anything but. Your classes are one of the highlights of attending [this Code Camp].

More comments can been seen on my SpeakerRate page. And, of course, just drop me a note if you'd like me to come speak at your event.

Things I Didn't Get To
There are some things that I didn't get to. As mentioned earlier, I didn't read as many books as I wanted, and I didn't produce as many videos as I planned. But that's okay.

I'm also still struggling with the Agile Mindset (which I talked about earlier). I still can't solve a Rubik's Cube, and I still find myself limiting myself unnecessarily. But this is a personal growth thing that I'm putting at the top of the list for the coming year. I recognize how I limit myself with the fixed mindset, but I haven't always been able to overcome it. I don't limit other people; I shouldn't limit myself.

I still have a problem with names. I've never been very good with names, and when I speak in different places (often returning to the same event a year later), I have trouble keeping track. I'm pretty good with faces, so I recognize people but can't place the name. I usually tell people, "I need to meet you 5 times before I remember your name." It's not always that bad, but I do get it eventually. I don't know if there's a solution for this, but I'll keep trying.

I'm not the only one with this problem. At the last MVP Summit, I ran into someone who looked familiar. He thought I looked familiar, too. And neither of us could remember where we met before. We had talked at some previous developer event, but we weren't sure which one. The important thing is that we recognized each other, and it let us start up a conversation (and we'll probably both remember when we see each other again).

More To Come
So, it's been an interesting year. At the beginning of the year, I was planning on doing some classroom developer training and working on contract projects. Instead, the classroom training didn't work out, and I ended up producing a couple of courses for Pluralsight and then was asked to produce some more.

2014 should be an exciting year. I'm starting to fill in my speaking calendar (7 events scheduled so far). And I'm looking forward to what's next.

My plan is to find a way to help development teams get better. I'd love to be in a consulting / mentoring position that helps a company implement projects and gets the development team up-to-speed on technologies and processes. These aren't always the latest and greatest; sometimes it is just getting a good handle on the intermediate-level stuff that helps us work efficiently.

I know what I'm good at: making intermediate-to-advanced level topics accessible to developers of all skill levels. I love exploiting that talent, and I love watching people learn.

Move forward. Learn constantly. And above all...

Happy Coding!

How Do I Change Someone Else's Code?

I had an interesting question come up at my Clean Code session at Silicon Valley Code Camp:

How do I change someone else's code?

This question came up as we were talking about refactoring code to improve the readability. And the question was not coming from the technical standpoint, it was coming from the interpersonal standpoint. So, the question could really be stated several different ways:

How do I deal with a developer who is possessive about the changes made to "his" (or "her") code?

How do I tell a developer that his/her code could be more readable?

Let's start with the first question.

Code Ownership
If people are possessive of "their" code in the codebase, this is a sign of a larger issue.

Note: I'm approaching this from a standpoint of developers on a team working for a company just so we have an idea of the environment. But this applies to other types of teams as well.

Our focus really should be on the business -- how the applications we build move the business forward. And the most productive environments I've worked in have this mindset.

In the agile world (and I'm reluctant to use that word since a lot of people who are "Agile" really aren't), everyone on the team is responsible for the code. If someone sees a problem in an application, he is empowered to fix it (or alert someone about it if he is not capable of fixing it himself) -- and arguably, he would be irresponsible to not do anything about it.

So, if you find yourself in a situation where you can't touch a certain module because "that's Jim's code", it might be time to bring in someone to help with the dynamics of the team.

We don't always have control over the team, but we do have control over ourselves. If you find that you're offended that someone changed "your" code, then it's time to take a step back and re-evaluate your own attitude.

Controlling the Ego
Developers are known for having large egos. This really isn't surprising because at its heart, development is more of a creative process than a technical process. The last thing that an artist wants to hear is that you think his painting is ugly. Developers generally react the same way.

But we need to take a step back and look at what we're really doing: we are building tools that propel a business forward. And we don't even own the code we write (from a legal standpoint), the company owns it. This means that the company can do whatever it wants with the code, including rewriting it, breaking it, using it incorrectly, or even never using it at all. So, we cannot get personally attached to any particular function that we create.

I won't say that this is an easy thing to do as a developer. I put a lot of thought and effort into the software that I write. When I see that it is not being used or being used improperly, it really annoys me. But then I take a step back. In my experience, there is very little benefit that comes out getting worked up over these things. I voice my opinion and then let it go (sometimes more successfully than others).

Learn from Other Developers
The same holds true if another developer makes changes to code that you originally wrote. Instead of having a kneejerk reaction, understand that the other developer is not calling your painting ugly. He (hopefully) has the same goal that we all do, to propel the business forward.

So, stop and look at the changes that were made. If you think they are good, learn from them. If you think they are bad, talk to the other developer. Communication goes a very long way in the development world. We don't always approach problems the same way (actually, we probably never approach problems the same way). It's good to understand what someone else is thinking. I've used this several times as a learning experience. And sometimes by working together, we come up with something that neither one would have come up with separately.

It's All in the Approach
So, now let's deal with the second question: How do I tell a developer that his/her code could be more readable?

A great way to approach this is to ask the developer to explain the code. "Hey, Jim, I'm having a little trouble understanding this block of code. Could you help me out?"

If he asks why you're looking at "his" code, tell him that you're just trying to get a better understanding of the system overall.

This may or may not work. It all depends on the other developer. We don't have any control over how other developers react. Just remember to keep your own reactions in check.

If he does explain the code, then you can offer some suggestions to make it more clear to someone just walking up to the code for the first time. Hopefully, you'll be able to work together on making the code better.

Sometimes We're Stuck
If we are part of a dysfunctional development team, sometimes there's nothing we can directly do about it.

But there is a big difference between being *on* a dysfunctional team and being *part of* a dysfunctional team. It is very easy to be overwhelmed by the things going on around you and let them affect you. I've had that experience. I let the problems of a team I was working with get the better of me, and it affected my attitude. I was lucky enough to have someone point this out to me, so I was able to readjust how I was reacting to things.

Attitude is Infectious
Just like a negative attitude is infectious, so is a positive attitude. We can't control others, but we can control ourselves. I've found that if I take a certain attitude toward development (focusing on the business, checking my ego, constant learning), it rubs off on other members of the team.

We *can* change the attitudes on our team. It starts with us re-evaluating our own attitudes. From there, we set a good example, pump out some excellent code, and focus on the goal. Others will want to follow. (And if that doesn't work, polish up the resume. If this is your approach to development, I want to work with you.)

Happy Coding!

Fixed Mindset vs. Agile Mindset

I was impacted pretty sharply by a podcast that I listened to a couple weeks ago: Hanselminutes #389 - The Agile Mindset with Linda Rising. If you haven't heard this conversation, you should go listen to it right now.

Based on this, I went out and watched a keynote given by Linda Rising (in the links of the podcast): The Power of the Agile Mindset.

This got me thinking about my attitudes toward others and toward myself.

The Short Version
The short version (if you don't want to listen to these talks) is that there are two basic mindsets: a fixed mindset and a growth (or agile) mindset.

The fixed mindset says that we have a specific potential that we can live up to. If we succeed at something, it's because we are smart or are meeting our potential. If we fail at something, maybe we just aren't smart enough. But the general idea is that everyone can be grouped by what he/she can be good at and not good at. Someone can learn something new, but there's a ceiling at which he/she will stop getting better. One very telling result is that people with a fixed mindset will often meet failure with helplessness -- "I failed; I guess I'm just not good enough."

The growth/agile mindset says that we are all capable of constantly learning. If we succeed at something, it's because we worked at it. If we fail at something, that's okay. We can use it as a learning experience and do better next time. With this mindset, we continually improve at whatever we work at.

Now there are limits. Not everyone can be an Einstein or a Bach or a Michael Jordan. But we can learn to be competent (and possibly excel) at whatever we set our minds to. And there isn't a "hard cap" on what we can learn. We can keep getting better even if it's just in small steps.

This is a really bad summary, so go and click on the links at the top of the article to find out from the expert.

Mindset in Business
In the Hanselmintues podcast, there was a discussion of how certain companies have the fixed mindset and others have the agile mindset. I've seen this first-hand (although I never thought about it this way).

I was at a company that had two distinct teams and two distinct approaches to software development. I was (thankfully) on the team with the agile mindset. We were constantly learning from our previous projects, looking for things that we could do better, and helping each other grow. From the way that we treated each other, it was obvious that our team embraced the agile mindset. We saw potential growth in each one of our team members.

The other team had a fixed mindset. This team was always looking for the tool or process that would make their development idiot-proof. This really bothered me. If I was in charge of that team, I would have focused on how to make the developers better -- to find out where the gaps were and bring everyone up a level. But it seemed to me (as an outside observer) that the management team had given up on improving the developers. The mindset was that the developers were "only so good" -- they had reached their potential as developers.

I have always treated other developers with an agile mindset. That's not really surprising since I spend so much time helping other developers get better. If I didn't believe this, then I wouldn't spend so much time speaking and writing and teaching.

Mindset in Myself
I did find something surprising about myself though. Even though I treat others with the agile mindset (the potential to continuously get better), I treat myself with the fixed mindset.

I've never really struggled with something. When I was growing up, I was told that I was smart. I did well in school. I did well in sports. I did put a lot of work in. For example, I practiced basketball a lot when I was in high school. But I never struggled with it. I was never overcoming challenges, I was simply putting in time.

There are things that I consider myself to be "not good at." These are things that I have not put much effort into. Music is one of these things. I play the keyboard and guitar very basically. I don't play a lot. And I considered myself to "not be a natural" when it comes to music. Maybe I was missing a trait that would allow me to play really well. And I never really put in a lot of time to learn.

So, I've managed to put limits on myself in some areas but not others. For example, in development, I'm constantly learning, usually through books (that's how I learn best). When I'm speaking, I elicit feedback from the people who attend, and I try to incorporate their suggestions. When I completely blow a presentation (which has happened a couple of times), I try to figure out what I did wrong so that it doesn't happen again. I think that this makes me a better presenter as time goes on.

The Rubik's Cube
I grew up in the era of the Rubik's Cube. If you've never seen one, here you go:

The goal is to get the each side to be a solid color (at the same time). I was never good at this. There were 2 ways that I could solve it: (1) follow step-by-step directions, or (2) take it apart. When I followed the directions, I wasn't really learning the concepts behind the cube, just following the numbers.

Since then, I've been content to think "my brain doesn't work that way." I never thought that I could learn to solve it.

This came up a few weeks back. I was standing around talking with a group of devs after a user group. Someone picked up a Rubik's Cube on a desk and proceeded to solve it in a few minutes. I admitted that I'm not capable (and I don't think I ever would be).

Guitar Hero
So, let's go the other way. Many years back, I saw Guitar Hero (the video game) and decided that it looked like fun. I even went out and bought a PlayStation 2 so I could play it.

The first time I tried to play, I was awful. The beginner level only uses 3 buttons (out of 5) and goes very slowly. But still, I was awful. After playing for a while, I simply turned if off and thought "well, that was a waste of money."

But for some reason I went back to it. And over the years I got really good (which isn't that hard if you have free time). I got to the point where I could not play the beginner level anymore because it went too slowly. And I continued to play through many more iterations of the game (I think I have almost all of them). And when I started a new version, I would start on the "Hard" level.

I even used this to my advantage. The first time I spoke publicly was at the So Cal Code Camp in Orange County in January 2010. I was nervous as heck, and I wasn't sure that I could actually go through with the presentations that I had planned. There was a speaker dinner the night before at Dave and Buster's, and I ended up at the Guitar Hero game there. I played a bit, did very well, and other people commented on it. There was even a teenager who asked to play head-to-head with me. That boosted my confidence -- I could perform well in public. And I was successful in my presentations the next day.

My Challenge
Many times I find myself getting frustrated at things or thinking "I'm not good enough." There's no logical reason for this based on my past performance, but that fixed mindset keeps creeping back in.

So, I'm challenging myself. I will learn how to solve a Rubik's Cube. I know that doesn't sound like a very big challenge, but it really is. In order to solve the cube consistently, I will need to break out of the mindset that says "my brain doesn't work that way."

So, the next time you see me at an event, ask me how I'm doing with that. Hopefully, I'll pull a cube out of my pocket and solve it right in front of you.

The fixed mindset vs. the agile mindset is not simply about how we treat other people. It's also about how we treat ourselves. Keep learning and keep growing.

Happy Coding!

Book Review: The Agile Samurai

I'm continuing to burn through my reading list this year.  I recently finished reading The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson (Amazon link).

Rasmusson provides a very good introduction to the Agile process and how to implement it in your projects. The approach is friendly and conversational -- which ends up underlining the point that much of Agile is about communication.  The book itself is filled with diagrams that reinforce the points at hand and each section ends with a conversation with the Master Sensei to review points and answer questions that the "aspiring warrior" may have.

Ultimately, this leads to a set of reinforced principles that describe how to be successful with Agile.

The Parts
The book is broken down into sections that provide a logical procession through a typical project.

Part 1 - Introducing Agile
The first two chapters give an overview of what Agile is and some of the primary principles.  One example is "Done means done".  There is no 80% complete.  A feature is either done or it is not -- this includes everything through acceptance testing.  A feature is not done until it is ready to be deployed.

Another key feature of Agile is the self-organizing team.  Chapter 2 talks about the different members of the team, how each of them are vital to the project success, and how people fall into these roles naturally or by choice.

Ultimately, everything is the responsibility of the Team.  So, if you see something that needs to be done, go ahead and do it (with proper communication, of course).

Part 2 - Agile Project Inception
The next three chapters talk about how to get an Agile project started.  This starts with getting everyone on board with the process.  The next thing is to make sure that everyone is on the same page with the proposed project.

This book has a very practical approach to starting a project: The Inception Deck.  These are 10 items that need to be completed before the project is actually started.  These items make sure that we (as a Team) know where we are going, where we are not going, and start to determine how we are going to get there.

One of these items is creating the Elevator Pitch.  If you only have 30 seconds to describe your project, how would you do it?  Think about your current project; how would you describe it?  If you struggle with this, it could mean that your project does not have a clear purpose.  It could mean that your project is trying to do too many things at once.  It could mean that you're not quite sure where you are going.

Another item is to create a "Not List".  This is a list of things that the project is not going to do.  This again helps make sure that everyone has the same expectations.  If we say up front that we are not going to try to integrate with the legacy system, then we have that out in the open for everyone to see.  If any of these "not" items are an issue, then we have a discussion to determine whether they should be moved to the list of things we do want in the project.

These are just 2 of the items in the Inception Deck to determine whether the project will give us the benefits that we expect and to make sure we're all headed in the same direction.

Part 3 - Agile Project Planning
The next three chapters have to do with planning.  We've figured out what our project is all about (with the Inception Deck), now it's time to start planning.

Estimation is always a big part of any planning.  One of the things that makes estimation a bit harder with Agile is that we don't have all of the requirements up-front.  We have a general idea of the pieces that we need, but the specific "this function needs to do this, this, and this" comes later.  So where do we start?

We start by creating User Stories.  These are the functions that we want in our project.  It could be things like logging in to the system, things that are a bit bigger like showing an inventory list, or things that are much bigger such as checking out a shopping cart.

The idea is that we take these user stories and assign relative levels of effort.  We don't know exactly how long each item will take, but we do know which items are bigger or smaller than other items.  We take this information and organize these according to some system.  A point system (1 for small, 3 for medium, 5 for large) will give us an idea of how long (relatively) each feature will take.

At this point, we don't know how long the project will take to complete because we don't know how many "points" our team can handle on a regular basis.  It may seem odd to say "we don't know how long this will take to complete."  But the reality is that even if we give a hard answer in the beginning, things change so much that that original estimate is almost always wrong.

Part 4 - Agile Project Execution
The next three chapters are all about execution.  Now that we have our general plan, how do we execute on it?  An important tenant is to "Deliver something of value every week."  Now this many not always be practical (and it may be that we are delivering value every two or three weeks, depending on our plans).  But the general idea is that we are constantly moving forward with completed features.

This doesn't mean that we necessarily have a useful product.  Usually, we need a critical mass of features before the final product is useful to the end users.  But we are completing the features.

And remember "Done means done".  When we get to the delivery part of the process, we have completed features that are ready to deploy.  We don't have a whole bunch of 90% complete features.  If we find that we aren't actually finishing everything, then we need to stop any new development and go back to finish up the things we have in progress.

Once we start delivering, we find out the velocity of our team -- how many "points" we are able to handle during each of our development cycles.  This will take a couple of cycles to figure out (the first one will be slow, and there will always be things that either speed-up or slow-down the process).

As mentioned earlier, communication is a huge part of Agile.  The customer is part of the Team.  Face-to-face communication should be happening regularly (ideally daily).  But in addition to the people who are part of the team, we need to communicate with the larger group.  The recommendation is to set up regular "showcases" with the larger team -- this is often the user group, stakeholders, project funders, and others.  This gives the project team a chance to show off the regular progress on the project.  When the project is visibly moving forward, people are happy.  This is much better than a team disappearing for 6 months and coming back with the wrong thing.

This showcase accomplishes a couple of things.  First, (as mentioned), it creates a trust in the team.  Forward progress is seen as a good thing.  Second, there is more immediate feedback.  If a feature comes out differently than expected, there is a chance to adjust the feature to better fit the users' needs.  Third, if there is no progress, don't cancel the meeting.  This gives the Team a chance to get up and say "nothing significant was done."  Yes, it's embarrassing.  But it is honest communication, and the Team will not want to go through that again, if possible.

Agile is all about change.  We need to figure out what to do when the users want new features, or one of the items in the low-priority list gets moved to the top of the list.  Again, communication is the key.  If the expectations were set during the project inception, everyone knows what happens next: compromise.  We figure out (as a Team), if we want to do a swap (trade a high-priority feature for a low-priority one) or extend the scope by adding the new feature (this is generally not recommended as it leads to scope-creep and a project that never gets released).

Part 5 - Creating Agile Software
The four chapters of the book talk about processes that help with Agile development.  These include Unit Testing, Refactoring, Test-Driven Development (TDD), and Continuous Integration.  These are all introductions to the topics at hand with recommendations to look into them further.

One thing that I appreciated about these chapters is that Rasmusson emphasized that these techniques may or may not work in your environment.  Take and use what works and leave the rest (but be sure to give them a try to see if they do work).

Wrap Up
The Agile Samurai is a very practical introduction to Agile and techniques that can help you be successful.  Throughout the book are useful examples and specific things that we can do to keep moving forward in a productive way.

The general approach of "do what works for you" is a good one.  The book provides a number of techniques but advises that you determine which are appropriate for your environment.  I would recommend this book to folks who are interested in looking further into Agile techniques and how they can be successful with them.

Happy Coding!

Development and the Business - A Partnership

A couple of months ago, I posted some thoughts on The Clean Coder.  Part of this included how developers should be in a partnership with the business area.

This was reinforced in a recent episode of .NET Rocks! (Is Agile Dead at CodeMash).  A panel member (sorry, I don't remember which one) polled the audience.  First, he asked how many people were part of the "business".  Result: one or two people.  Then, he asked how many people were part of "I.T."  The result was most of the audience.  He immediately said that this was wrong -- that everyone is part of the business.  That's why we (as developers) exist.

As another example, we can look at the Principles behind the Agile Manifesto. Specifically, "Business people and developers must work together daily throughout the project."

Forming a Partnership
So, how do we go about forming this partnership?  Previously, I mentioned that I really didn't know.  But it turns out, I did.  I just needed to look at my experiences in a bit of a different way.  I mentioned how I have worked in an environment where the development teams and business areas had very good relationships.  But even if we don't have this particular environment, we can work towards it.

Note: I'm approaching this from the standpoint of a corporate developer -- a developer who is building applications to help the company get work done.  You will need to modify these ideas just a bit if you work for a software company or build products for people who don't work for your company.

Watch: Learn How the Business Works Today
The first step is to see how your users do their day-to-day work.  Start by spending a day with one of your users.  Watch everything that he or she does.  Your job at this stage is to simply see how the folks in the business area get their job done.

Keep your mouth shut.  Think of yourself as a wildlife photographer -- you record what takes place in front of you, but you're not allowed to intervene.  If you see someone fumbling with a process or a piece of software, make a note of it, but let him fumble.  You're not there to give advice; you are there to see how things are done.

Take notes, but don't immediately start thinking about how you would change things.  As developers and problem solvers, we have a tendency to let our brains run wild.  But this distraction can keep us from making some important observations.  So, just keep watching.

Listen: Learn How the Business Wants to Work
The next step is to talk to your users.  Ask them what they think would make their jobs easier.  Find out how they want to work.  This is still part of the observation stage.  Don't immediately start trying to solve problems; just keep collecting information.  The key is to listen to how they would change things.  Periodically review your notes with the people you are talking to.  This will ensure that you are collecting the correct information and has the added bonus of giving the users confidence that you are really there to listen and help.

If you're dealing with front-line workers, also talk with their management team.  Ask the managers what they think works well and what doesn't work well.  You may find out that the management team would like the front-line workers to focus on different priorities -- maybe there are short-term goals that change from time to time.  If you can, try to sit in on one of their team meetings.  This will give you better feel for what is important to them.

As before, don't let your brain start problem solving.  You're still collecting information.

Analyze: Review What You Learned
After you've collected your information, it's time to start analyzing.  Now is time to let your brain run wild.  Think about the software that is being used (or not used).  Review the stumbling blocks the users may have had (for example, did they have trouble finding a particular function?).  Think about the processes that were not automated that could be.  Maybe you noticed that someone took data from an email attachment and re-keyed it into a different system.

At this stage, don't be afraid to follow up with anyone that you've talked to out in the business area.  Often, after you start analysis, you find out that you don't have all of the information that you need.  You can use some quick follow-up questions to fill in the gaps.

Contribute: Take Your Plan to the Business
Now that you've had a chance to come up with some suggestions, it's time to take them to the business.  Start by grouping your solutions into "quick wins", short-term, and long-term time frames.  Once you have this, go back to talk to the folks in the business area.

Hopefully you have a couple of "quick wins" to start with.  These are items that would be easy to implement from a technological standpoint (with minimal cost and resources) and would add good value to the business area.  This is where you start to build trust.  The quick wins show that you understand the business and that you are able to help.

If you "missed" on the quick wins, don't get discouraged.  If the business area did not like your ideas, it's your chance to gather some more information.  Ask some clarification questions and listen.  Figure out what you misunderstood and work toward correcting that.

If the "quick wins" are a hit, then give brief descriptions of your short-term and long-term solutions.  This is an opportunity to plant some ideas for future projects.

Continue: Constant Interaction
Congratulations, if you've gotten this far, then you are well on your way toward a good partnership.  Now you need to make sure that you continue this relationship.  If you start implementing some of the solutions, stay in constant contact with the business area throughout the process.  Give them prototypes and get feedback as you go.  Back to the principle we mentioned earlier: "Business people and developers must work together daily throughout the process".

Benefits of a Partnership
Ultimately, the business benefits from this relationship.  As a developer, you are more in tune with how the folks in the business area think.  Your software will naturally head in the direction that the business needs.  In addition, the folks in the business area will trust your judgment.  Once they see that you are all working toward the same goal (the improvement of the business), then they are more likely to accept your suggestions.

A partnership is about building on the strengths of both members.  The business area has operational experience -- they know what work needs to be done.  The development area has technical experience -- they know how to automate processes and build working software solutions.  Working together, the entire business benefits.

Getting Buy-In
One of the issues you may face is getting buy-in from your management team.  It may sound like you will be spending a lot of time "not developing" as you are doing "partnership" work.  But this really isn't the case.  Plan on spending one day a month in the field -- this really isn't all that much.  The rest of the time is touching base from a few minutes to an hour at a time.  You might spend a bit more time getting things started, but it will just become a natural part of your work after that.

"Agile" is a very popular term to use.  Many development teams claim to be Agile, but often they are only using a couple of buzzwords and work in "sprints".  But ultimately, Agile is about getting working (and useful) software into the hands of your users as efficiently as possible.  If you don't understand how the business works, then this becomes very difficult.  (Note: this is part of the discussion of "Is Agile Dead" from the .NET Rocks! episode mentioned above.)

Wrap Up
I have been fortunate enough to work in a very productive environment where I was able to form strong partnerships with my users.  In that position, my management team understood the importance of these relationships.  I was able to respond quickly to my users' requests (since I understood what direction they were headed), and I was also able to make relevant suggestions to improve the process.

Just remember:

• Watch
• Listen
• Analyze
• Contribute
• Continue

It's important to remember that we are all working toward the same goal: the success of the business.  The better that we understand it, the better we will be able to contribute.  And, ultimately, we will all succeed together.

Happy Coding!