People are motivated in many different ways. You can probably think of situations at work where you’ve been really motivated to do awesome things. But what really motivates you if you look beyond the surface?

I’m going to use my current situation as an example. I’m currently doing maintenance on a 6 year old system with a Silverlight front end (and no one uses Silverlight anymore). From a purely technical perspective, it’s not hot new technology, and over the last couple years I’ve watched several developers get sick of doing it. I question whether they are seeing this big picture.

Here’s the thing — the maintenance that we’re doing on our 6 year old Silverlight app is providing a ridiculous amount of business value. I’m able to make changes that have an immediate impact on the users’ ability to do their job, sell new products, and reduce costs.

Are there more “fun” technologies out there? Sure! I play around with things like Ruby on Rails and React on the side because I’m not using them at work and I enjoy working with technologies like that. But my attitude at work depends on my true motivation.

A progression of thought

I’ve spent a lot of time thinking about what motivates me in my career. Am I going to get bored with software development at some point? Are there other roles that I might want to pursue? There are lots of good questions to ask.

I came to the conclusion that I’m not going to get bored with software development because it’s such a big part of our world and the things you can do with technology are too exciting. I’ve also started to understand the underlying reasons that give me motivation.

When I started out in my career, I was like a kid playing with toys. I wanted to do cool things with new technology. I had a limited understanding of what was important to the business, and I was basically just doing whatever work items were in front of me (hopefully with new technology). I had a very small and self-centered view of the world.

Later on, I realized the importance of providing business value. I got into lead roles where I had more interaction with people in the business, and I started to see what was important to them and how technology could solve their problems. I still enjoyed working with new technology, but I started placing more importance on solving business problems. But even at this point, I was missing something very important.

The real underlying motivation for me now is improving people’s lives through software. I want to improve the lives of my users by developing software that makes their job easier and makes them more successful. I want to improve the lives of my managers by helping to solve their biggest problems. I want to provide value to the business and help them achieve their mission. And I want to improve the lives of the people on my team and help us all get that good feeling that you get when you work together with people that you like to achieve something incredible.

It doesn’t really matter what technology I’m using. What really drives me are people. Without people, I’m just typing words on a screen. But when you add people into the mix, I have a much larger purpose then just developing an application. I’m using technology to change people’s lives. And that is a good reason to get up in the morning.

When I think about a lot of the efforts that we make to improve the software development process, I feel like we’re usually trying to make improvements within the system that we are currently living in. What if we could instead disrupt the world that we’re living in by changing something that dramatically changes the game?

Think of what Uber has done. I feel like everyone uses Uber. How many people do you know used taxis on a regular basis? Maybe you used a taxi when you absolutely had to, like when you’re getting from an airport to a hotel. But on a daily basis? No way. The other day a co-worker took an Uber to get to work after dropping his car off to get an oil change. When I asked him how he was going to get back to pick up his car, he said, “I’ll figure it out this afternoon.” That is a game changing idea. It makes you think about transportation in a way that you never thought of before.

Let’s think about the world of software development. I tried to think of some of the big changes I’ve seen in the last few years.

• DevOps and cloud computing – it used to take weeks to get a new server purchased and stood up, but now we can go to a site that automatically provisions a server, installs what I need, and then I can get rid of the server as soon as I’m done with it at a fraction of the cost.
• Git – I remember the first time I heard about branching per feature. In the world of centralized version control systems, branching and merging is hard enough that you would never think about branching per feature. Git makes the cost of branching and merging almost zero, which enables you to work in a completely different way.
• Dynamic languages – I can change a line of code and see the results immediately without having to compile
• Remote working – collaboration tools are improving to make it much easier to work with people that aren’t in the same location as you

Think about the application that you work on and business in which you operate. What are some things that are annoying and slow you down? Some of these things are obvious, but many are really hard to see because they’ve just become “normal” to you. You’ve accepted those things as facts. But what if there were a way to change the facts?

Let me give you some examples.

• What would happen if I didn’t have to wait so long to get answers from people in the business?
• What would happen if I had a faster development laptop?
• What would happen if we were using a different framework/platform/language?
• What would happen if our team could all sit together in the same space?

Those are good questions to ask, and those things might provide a lot of value, but that’s still operating within your current plane of thought. What if we ask more mind-blowing questions?

• What will happen when we improve smartphone battery life so that a phone can operate on a full charge for weeks/months?
• What will happen when computing and network speed increases so that web pages load instantaneously?
• What could you do if everyone had virtually unlimited data and download speeds were measured in gigabytes per second?
• What will happen when mainstream video chat is no longer a grainy, choppy FaceTime or Hangouts video and instead is a clear 4k data stream?
• What will you be able to build if all of these were true?

Will those things help you out today? No, because they mostly aren’t a reality yet. That’s not the point. By thinking about game-changing ideas, it forces you to think on another level. It forces you to think outside the box. It’s surprisingly hard to think outside the limitations of the world in which we live everyday (remember The Matrix?).

This is why I attend certain software development conferences and not others. For example, I’m writing this at the Path to Agility conference. I love going to open space conferences for the same reason.

I go to conferences like #path16 not just to hear mind-blowing ideas, but to hear things to make me think about mind-blowing ideas.

— Jon Kruger (@JonKruger) May 26, 2016

The technology world is changing at an extremely rapid pace, so we’re going to need to change the level of our thinking.

I have 1,408 emails to answer now–prioritizing is important. The younger generation is constantly looking at their phones, so they don’t have time to think strategically.

— Cheryl Krueger, founder of Cheryl & Co.

In a world where we seem to value busy-ness, I feel like we frequently got lost because we don’t often take time to think about where we’re going. I’ve fallen into this trap many times.

Every time this happens to me, I eventually work my way out of the insanity and then wonder what happened that got me so busy in the first place. The thing is I’m almost always bringing it on myself. It’s not like someone’s working me into the ground or anything, I’m just not taking time for downtime.

Not only is over-working yourself tiring, it’s a huge mistake. I find that when I’m constantly consumed by doing things and getting things done, I have no time to think strategically. Some of my best ideas come to me because I my mind is clear and I give myself time and space to think.

Reading

My wife loves to give me a hard time for not reading books. I’m not much a fiction reader, I can’t remember the last time I read a fiction book (it’s probably been since college!). Most of my reading these days is related to technology and business, which some would say is not light reading.

I find it inspirational. I love reading about what people are learning and how people are using technology to change how we do things. We live in an amazing time when anyone with a good idea can turn it into something that changes the world. I’m probably not going to be that guy, but I like being reminded that anything’s possible.

Conferences

I’ve been burned out on conferences for the last couple years. I’ve stopped attending several conferences and user groups that I used to attend on a regular basis. I’m not someone who typically likes to sit in one place and listen to someone talk for an hour, especially when it’s a topic where I could spend 20 minutes reading on the internet and get all of the same information.

I still go to some conferences, but I don’t go planning to learn anything specific. I go because it gives me a space to process ideas and think clearly. I go to talks just to give my mind a trigger for my thoughts. I love talking to people at conferences to hear the ideas that are floating around in their heads.

Free thinking at work

This is a tough one. When I’m at work, I’m putting a lot of effort into focusing on a specific task. I’ll put headphones on so that I can focus on writing a certain piece of code. When we’re in meetings, we try to have a very focused agenda. Everything is focused on completing tasks. So what can you do to promote free thinking at work?

We’ve started doing book clubs at work to promote learning. Some of these are technology focused, some are focused on business acumen. A lot of good conversations happen at the bar after work when people are more inclined to open up about what’s going on in their lives. It’s not that we come up with amazing ideas during these times, but it clears a little space in our head for thoughts to come in.

This is important

I’m starting to make a conscious effort to find ways to stimulate thinking. When I find myself with extra free time, I’m not trying to find projects to fill that time. I’m reading less about “how to use technology X” and I’m starting to read things that will expand my horizons.

What works best for you? That’s up to you to find out, but make sure you’re giving your mind some space to find it.

I find that as software developers, we sometimes lose sight of what it is like to be a user of the systems that we develop. This is ironic since software developers probably consume more software than the average user.

For the apps and systems that I use, I have two very high level yet very important requirements for updates to the application:

• 1. Works as designed (i.e. not buggy, doesn’t crash, etc.)
• 2. Is at least as fast and easy to use as the last version (hopefully faster, but definitely not slower)

Taking the pain

It’s been a rough week for me, mostly due to the fact that we decided to upgrade our solution from Visual Studio 2012/ReSharper 7 to Visual Studio 2015/ReSharper 10. At first, I got excited when I typed “?.” for the first time, but the excitement quickly faded.

• Everything in the IDE felt slower
• Visual Studio would often chew up 60%+ CPU on all cores, even when it seemed like nothing was happening
• ReSharper wouldn’t show me the results of my tests until ALL THE TESTS were done running
• The ReSharper test runner would die a slow death and crash if I ran a lot of tests
• If I open a solution that has a Git repository, I can’t connect to TFS to open work items in the same solution

All of this made me long for the good old days of VS2012 and a version of ReSharper that worked (not to mention that we gave these companies money for these new versions!).

Don’t get me wrong, these newer versions have a lot more features than the old versions. The problem is, I don’t use 90% of them, and they failed to meet my two most important requirements that I mentioned.

I can see how this happens.

Executive: “We need features X and Y so that we can release a new version and sell software!”
Dev team: “But we don’t have enough time to do that well.”
Executive: “That’s OK, just ship it anyway, they’ll purchase it and then we’ll fix the issues.”

In my case, they’re going to get away with it because I don’t have an alternative to Visual Studio and ReSharper right now. But it still feels wrong.

Running through mud

Another example: Why does every new version of an operating system have to get slower? I have a 5 year old MacBook Pro that I had to upgrade from Snow Leopard (which was working great, BTW) to El Capitan because no one was supporting Snow Leopard anymore. Now my MBP feels 5 years old and it’s much slower.

If you’re a Linux person, you’re probably laughing at everything that I’m saying because everything for you is lightning fast with the command line, simple user interfaces, etc. When I was last doing Ruby, we used gVim as our IDE (basically a simple text editor with basic highlighting, basic autocomplete, tabbed windows, and of course the power of Vim). Contrast that with the bloat of Visual Studio.

The opposite experience

This morning, I got the Android Marshmallow update for my LG G4. When I read up on Android Marshmallow, the general sentiment out there seemed to be, “There’s nothing big in this release, just some minor features, increased performance, and better battery life.”

What!!!! I’ve only had Marshmallow for about 4 hours, but I can tell that it’s a little snappier than before. They made minor usability changes in the OS that are nice. I can’t speak for the battery life after just 4 hours, but it doesn’t seem to be any worse than before from what I can tell.

What a breath of fresh air. I don’t have to sacrifice performance for unnecessary feature bloat. I don’t have to buy a new phone to make the latest OS work as designed (right, older iPhone users?). All this makes me a happy user.

You do this to people too

What do your users have to say about the updates you release? Sure, you’re going to have the curmudgeons that don’t like any change, and you can’t please everyone. But too often we ignore the non-functional requirements like performance, usability, and user happiness. Those things might just be more important to your users than those new shiny features you’re working on.

What happens when a user of your application makes a mistake that has negative repercussions? Let’s say this was not a conscious mistake or an act of negligence, it was just an accident, a simple typo, or clicking the wrong button. Whose fault is it?

Is it the user’s fault for being too careless? Is it the developer’s fault for designing a system that doesn’t protect against such mistakes?

What if we’re asking the wrong questions?

This happened to me recently and a light bulb went off in my head. The reason I was asking the wrong questions was due to the way I was viewing my relationship with the users of my application.

Go read those two questions again.

Is it the user’s fault for being too careless? Is it the developer’s fault for designing a system that doesn’t protect against such mistakes?

The key word is fault. We get so obsessed about figuring out who is responsible for a mistake. What if my mistake was not expecting fallible people to make mistakes?

We say things like, “It’s the users’ job to make sure the data is correct.” Maybe it’s their primary responsibility to make sure the data is correct. But when the data is wrong, IT ends us getting partially blamed.

He’s the crux of the matter – you and your users are on the same team. This changes everything.

Shared responsibility

Everyone is responsible for quality, whether that’s the quality of the code, the way that the system is used, or how people consume the data downstream. This doesn’t mean that it’s all on you, but as a member of a software development team, you are a part of the process.

With that being said, what can you do to ensure that the system is used correctly? You could build checks into the system, write audits to check for issues, educate users on how to use the system better, and be aware of how changes to the application might affect people that use it or consume the data. More importantly, you care about all of these things and don’t dismiss things as someone else’s problem.

Care about what your users care about

You know that feeling you get when the smartphone app that you love releases a new version with a fancy UI redesign, more features, and promises of rainbows and unicorns, yet you hate it because it’s slower and the new features make it harder to use it in the way you like? This happens to me all the time!

That’s probably how your users have felt more than a few times. You probably didn’t mean to do it. But it probably happened because you didn’t know the repercussions of your design decisions.

I just spent two months being a user of my application. Not as a tester or a coder, I joined the users’ team. I sat on their floor, I went to their meetings, I did their job along with them. Now I often used SQL to solve problems, but I lived their life and watched how they did things. I had several moments where I groaned because I had to wait for the next release for something to be fixed, and I realized there are many situations where the system doesn’t allow a user to do something the “right” way and they have to find less than optimal ways to get their job done. I saw them spend days doing mind numbingly boring repetitive tasks because IT didn’t have time to help them.

The reason I ended up joining the users’ team is that we wanted to break down the walls that caused all of these inefficiencies. Many of you have had the aha moment when your developers and testers start communicating and owning quality together and you are able to drastically streamline the software development process. We applied to same principle of working together to drastically streamline the business process as well. And along the way, it shifted my mindset as well.

I’m not there yet, but I’m starting to get a better grasp (maybe even a good grasp) of what my users care about. I’m not sitting with them doing their work anymore, but now I go up and ask them a lot more questions, we’re doing more training and user acceptance testing, and I can relate when they have struggles. But even more importantly, the users are starting to realize that I get it.

Prioritize your users

One thing that surprised me when I sat with the users is how many system issues they knew about that I had no idea existed. “Why didn’t they just tell us?”, I would think. Sometimes they would create tickets for us to fix them, sometimes they might send an email, but the tickets often got lost in the backlog and the issues wouldn’t get resolved. So they just stopped telling anyone about the issues because they felt that no one was listening.

How frustrating! Believe me, in IT we were getting A LOT done. But we weren’t prioritizing our users, and they didn’t think they could count on us.

The other day, I got an email from one of the users explaining some problems they were having. I was ecstatic! They took the time to write that email because they actually think that it might do some good.

I can’t always drop everything to cater to their every whim, but we need a process that will allow users to raise issues and get them resolved. What’s the point of releasing all kinds of new functionality if the existing functionality isn’t sufficient?

I’m hoping to be much more available to the users so that they see me as someone that they can count on. That doesn’t mean just waiting for them to raise issues, but also proactively trying to find issues, show them how they can use the system better, and even volunteering to assist when I see a way that we can use technology to help them do their jobs.

Every business cares about making money and reducing costs. Yet every day I press a button and sit idly while I watch a little progress bar move. This happens every time I want to run an application or run a test.

Compiling code is something we’ve just gotten used to. Maybe that’s not the right phrase — we’ve learned how to put up with it. Granted, things are a lot better than they used to be. My first job after college was working on a C++ application where changing some of the foundational header files meant 30 minutes of compiling just to rebuild the application!

When .NET came out, they said that it compiled so fast that you would wonder if it actually did anything. That was true on demo apps that only had a few source files, but as your application grows and grows over time, those compilation times are quite noticeable. Certainly it was better than it was in C++, but that only makes you feel good for so long.

Let’s compare this to working with a dynamic language like JavaScript. When I’m coding JavaScript, it runs my tests in less than a second whenever I save a file!! No compiling, no loss of momentum, and oddly enough, dynamic languages don’t run noticeably slower than compiled languages for the kinds of applications that most of us are building.

Scary math

How much is compiling costing you? I decided to find out. The application that I’m in is 5 years old and has a fairly sizable codebase. Rebuilding the entire solution takes about 2 minutes, but usually I don’t need to rebuild everything. If I change a test file and run the tests, it still takes 30 seconds to compile what it needs to run the test. My machine is a year or two old, but it’s a pretty solid development machine with plenty of RAM and everything running on SSD. Your codebase may be smaller (or larger) than mine, so the compile times will vary. If you codebase is smaller because you app is younger, think about what it might be when your app is 5 years old.

There is a Visual Studio extension called Build Monitor that will record the compilation time every time you compile and then dump it to a json file. We all installed this and we recorded compile times from several different developers over a couple weeks, and here’s how it came out:

99 hours of dev time
5.4 hours spent compiling

… which means that 5.45% of our time was spent waiting for the code to compile.

Let’s put this in perspective:

If I code for 8 hours, I lose 26 minutes to compiling each day.

If I code 6 hours a day on a 6 month project, I lose a whole week to compiling.

Spread that across your entire team and multiply that by the average hourly rate of your employees.

5 days lost x 6 hours of coding time per day x 5 devs x $60/hr = $9,000

That’s real money!

Note that we haven’t taken into account that I can’t take advantage of my tests as much when the cost to run them is higher, so I’ll write a bunch of code before I run the tests, which makes diagnosing problems harder.

We also aren’t taking into account the slowdown that comes from having to stop for 30 seconds and go find something else to do like check email while I wait.

We also aren’t taking into account the lost business value because we can’t deliver features faster.

We also aren’t taking into account that someone out there is writing code that is trying to take away your market share, and if they can do it faster than you, they have an advantage.

What can we do about this?

Here are some things you can try to reduce compile times.

Get an SSD

There’s absolutely no reason why you should not be using a solid state drive at this point. When I switched to an SSD, my code compiled 3 times faster. You can get a 128GB SSD on Amazon for under $50. If your company won’t buy one for you, buy it yourself.

Get a faster machine

A new machine isn’t as cheap as an SSD, but if you can get a faster machine and speed up compilation time, the machine is going to pay for itself very quickly. At least make sure that your current machine isn’t strapped for RAM (which is really cheap).

Check your build settings

Once you download your nuget packages, you don’t need to check for them on every build! I like to leave this box unchecked.

Make sure the number of parallel project builds matches the number of threads your machine can run at one time. Also, when you run your code, you should only be building the projects that you need to run the code.

Split up your solution

If your solution contains a bunch of projects that you don’t ever edit, they’re just taking up memory and compile time. I like having one solution that has everything, but it can’t hurt to make smaller solutions that only have subsets of the code that you need in certain circumstances.

Unload projects

If you don’t split up your big solution, you can unload projects by right-clicking on the project in the Solution Explorer and selecting Unload Project. This will essentially remove the project from the solution that you have open without actually removing it (unloading is a user-level thing, so you can unload what you want without affecting your other team members).

Consolidate projects

I see lots of solutions where there’s a project for the data layer, a project for the business layer, a web project, and many more. The problem with this approach is that every time you compile, it has to copy .DLLs around to all of those different bin\debug folders, which takes time.

I would recommend consolidating projects whenever you can. Yeah, this might allow someone to reference the data layer from a controller instead of going through the business layer, but we all should know what you should or shouldn’t do in a codebase without having to have project boundaries enforcing it.

There is one caveat here… if you consolidate projects, then you can’t unload them anymore and you’ll have to compile them all the time. So while you might save time by consolidating projects, in some cases you could increase people’s compile time because you force them to compile code that they might otherwise unload.

Rethink your language choice

If you’re using a dynamic language like Ruby or Python or JavaScript and you’re still reading this, you may be mocking .NET developers right now. People that use dynamic languages can run their tests anytime they save a file. They can deploy changes to code by just deploying a single code file instead of compiling all of the code and deploying it. They can change a line of code, hit F5 in the browser, and immediately see what will happen. They don’t have to spend $500 for their IDE. They don’t absolutely need to have super high end machines to do development. And oh by the way, they aren’t spending 5% of their day watching their code compile.

(Yes, I know there’s a free version of Visual Studio, but how many of you are using that at work?)

I did Ruby on Rails for a year, and not only was it nice to not have to compile, I just loved the language. You really can do a lot more with less code. I felt like someone took off the training wheels and I could just write code that did what I wanted to do without all of the ceremony.

I realize that it doesn’t make sense for most teams to rewrite an existing codebase in another language just to avoid compilation. However, I will say this – someone else is competing against your company, and by using another language, they could have a 5% (or more) advantage. Ruby on Rails is very widely used by startups, and no one is more pressed for time and money than a startup.

C’mon .NET

I’m sure there are reasons that .NET can’t become an interpreted language like Ruby, but why can’t it? You can already make dynamic method calls in .NET using reflection, and at runtime it will attempt to call the method that you specified and will throw an exception if it can’t find the method. So why can’t everything work that way? Compilation may still have value as a sort of test to make sure that everything does link up, and it probably makes runtime faster if I can compile my code before I deploy it. But the real win will come when I can write .NET code and run it without having to check every method call and check every line for syntax errors when I’m only going to execute a few lines of code in a test.

Yeah, I know, now there’s ASP.NET Dynamic Compilation, but when I read about it, it just sounds like moving the slow compilation to the web server, which is convenient but isn’t going to save a lot of time when developing from what I can tell. But I haven’t actually tried it, so I suppose I could be wrong (I hope I am).

What else am I missing?

Do you have any ideas, tips, or tricks for how you’ve reduced compilation time on your team? I’d love to hear your thoughts! We’re all tired of watching progress bars.

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

Iteration management tends to be very fast paced. I find this exciting, but at first it feels a little overwhelming. Several different analogies come to mind.

In the NFL, quarterbacks that come in to the league from college often have a hard time adjusting the pace of the pro game as opposed to what they were used to in college. Early on they tend to struggle, but as they get more experience, the game starts to “slow down” as they get used to the pace and they start to have more success.

When you try to ride waves in the ocean, you wait for the wave to come and then you start swimming as fast as you can with the wave to try and catch it. If you go too late, the wave will pass you by. If you go too early, the wave may pick you up, slam you into the ocean floor, and churn you around like you’re in a washing machine. But if you get it just right, it’s an exhilarating ride.

When you’re leading a team, there’s a lot to keep track of. You have to be able to juggle multiple things at one time, and things can get out of control very quickly. The trick is to try and keep everything in front of you, and as soon as you see things getting out of control, come up with a plan to address the issues and get things back on track.

If I had to boil all of the Agile practices and ideas down to one sentence, it would be this: Do more of what works, and less of what doesn’t. I don’t care if you do things “by the book” or not. All that matters is that you find the best way to be successful and keep trying to get better.

I think of Agile as a giant toolbox of practices, principles, and ideas that I can draw from to help me with whatever situation I’m dealing with. I follow many practices that are associated with agile methodologies, but most of the time I don’t think of our process as “doing Agile” anymore. Most people would say that we are “doing Agile”, but we’re just trying to apply common sense and creative thinking to find better ways to develop software.

I’m constantly trying to find new ways to improve the software development process. I hope that this series of blog posts have given you some good ideas for your toolbox that you can use to help your team be more successful.

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

If I could pick one thing that will most impact whether your project will be successful, it would be how well you work with your stakeholders. I don’t know how many times I’ve heard people say that they key to their team’s success is the involvement of a good product owner from the business. As an iteration manager, your responsibilities might include working with stakeholders to involve them in the process.

Product owners

When I refer to a “product owner”, I’m talking about one person in the business who is the primary person to make decisions about the project. While you will likely get input from many people in the business, the product owner is the go-to person who will make decisions when people disagree and make sure that you are getting the information that you need.

What happens when you don’t have a good product owner? Any number of things.

• Getting behind because you’re waiting for answers
• Lack of detailed requirements
• Lots of requirements changes due to people changing their mind
• Getting conflicting messages from people in the business

That’s not to say that you won’t be successful if you don’t have a good product owner, but if you don’t have one, there are a lot more things that can go wrong.

Here’s what I tell management when we don’t have a defined product owner: requirements have to come from somewhere, and someone needs to answer questions, fill in the details, and settle disputes. That can either be someone in the business who has the knowledge and ability to make those decisions, or it can be people on the development team. I don’t know that you always want developers making decisions about how things should work, and I don’t think developers really want to do that either.

Often times I’ve seen a BA end up being the de facto product owner. If you have a good BA that really understands the business, this is probably your best choice if you can’t get someone from the business to step up. It’s still a risk that should be monitored and mentioned to the people who are paying for the project. You can write the best application in the world, but if you build the wrong thing, it was all a waste of time.

Iteration planning

If you’re working within the context of iterations, you’ll want to meet with people in the business before the iteration starts so that you can discuss the project and let them decide what you should work on. This is also a good time to ask clarification questions and make sure that you have everything that you’re going to need to do the next iteration’s work.

How you do this is up to you. Maybe you have a scheduled meeting before the iteration, or maybe you have a backlog of tickets that the business keeps prioritized. It really helps if you’ve estimated the work before you do this exercise so that everyone understands how what each feature is going to cost. Maybe they asked for something but when they realize how hard it is, they might decide that it’s not worth it anymore.

Even if you’re on a project where all or most of the work was scoped out before the project started, it’s still a good idea to have this meeting. Things are always changing, so the business might have different priorities now than they did a few months ago.

By letting your stakeholders choose what you work on, it involves them in the process and lets them have some skin in the game. If you’re not involving the stakeholders on a regular basis, they might assume that everything is going great when in reality the project might have all kinds of problems. At some point those problems are going to surface, and the sooner you can make people aware of them, the sooner you can work together on a solution to get things back on track.

Handling changes within the iteration

Even if you have short iterations, things are going to come up during the iteration and the business might want to change things mid-iteration. Some teams might find this annoying. I find it necessary. Successful businesses able to adapt quickly and respond to change quickly, but if IT is unable to keep up with the changes, then IT is keeping the business from being successful.

That’s why I welcome people asking if they can bring something new into the iteration – provided that they take an equal amount of work out and that they understand the impact of the change of focus (for example, if they want to remove something that is already half done, they should understand the impact of having the development team stop working on that feature). One of the reasons I like having a physical board instead of an online tool is that it’s much easier for business people to do this because they can just come over on their own and see what’s available to swap out for new work.

I love seeing this happen because it means that people in the business get it. I love when they come over and say, “We have this issue that just came up, can we swap out these two tickets for this new one?” I’m sure they love being able to have that level of control, and the development team can adapt to the change without having to get slammed with extra work.

Demos/user acceptance testing

Towards the end of the iteration, take some time to do a demo for your stakeholders and show them what you’ve been working on. This lets them know what you’ve been up to, and it also gives you (and them) a chance to make sure that you built the right thing. Maybe you even have some users try out the new functionality see if they’re able to do what they need to do. This feedback is essential because it’s so important that we build the right thing and that we build something is going to make the users’ life better.

How many times have you had an app on your phone that you really liked, but then a major update was released with UI changes that made the experience worse? I’ve had this happen multiple times with apps that I liked, and most times it led me to uninstall the updates or switch to another app altogether. You don’t want to do this to your users. It’s not about you or building what you want to build, it’s about what they want and what they need to do their job.

This stuff is important!

Your user base is hopefully very interested in seeing your project succeed, and if you can develop a good working relationship with people in the business, everyone will be happy in the end.

My current project has a very strong project owner. She is very involved in the process and is very in tune with everything that is going on, both on her team and the development team. She’s always willing to make decisions when the development team has questions and actively manages the backlog of work for future iterations. As a result, we’re able to get a lot of work done, and the users have been very happy with the outcome, and that might just be the most important part.

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

The goal of capacity planning is to figure out how much work the team can get done in a given amount of time (usually an iteration). This will allow us to make sure we plan a reasonable amount of work for the iteration, and it will help us make a commitment to the business and actually keep the commitment.

It’s important to remember that we need to have a good reason for everything that we do, and we need to understand why we do it so that so that we only do the things that provide value. I feel that when people are afraid to try Agile, they are afraid of having to adopt a prescriptive process that dictates that they must do something in a way that is not the best way for their team. If we don’t know why we need to do something, we need to figure out why or start questioning whether it’s worth it.

The ultimate goal of most teams is to deliver working software, and to do it in a timely manner. The goal is not to cram in as much as possible, the goal is to move things through the system as fast as possible. We ultimately want to decrease the time between the time when a stakeholder thinks of an idea and the time when it’s live in production.

We also want to be able to predictably deliver software. Sure, your superior likes it when you get things done quickly, but if you make overly ambitious promises but then keep having to push release dates back, it doesn’t look good. This is where capacity planning comes in — we want to figure out how much we can realistically get done in a given period of time.

In order to do this accurately, you need to get really good at data analysis. This doesn’t mean that you need to go take a class in statistics, but it’s in your best interest to collect data and use it to your advantage. I can’t tell you how many times I’ve made an assumption about something related to software development and how long it takes, only to find out that I was way wrong once I looked at the data. That could be the difference in your project succeeding or failing.

Small

The magic word when it comes to capacity planning is small. Capacity planning gets easier as the tickets get smaller, the iteration length gets smaller, and the team size gets smaller. Remember that as we go through the rest of this.

Anyone who has ever tried to plan future work for a team of 10+ people will know what I’m talking about. It is possible and sometimes you get it right, but if your planning is off for even a couple weeks, you can waste a lot of time and money before you know it. But planning for two people? That’s much easier and your chance of being accurate is much higher.

Things to consider

Here are some things that I like to consider when doing capacity planning.

What the stakeholders want

This is obvious, right? When I say “stakeholders”, that could be “the business” or your user base (if you’re building/selling a product), or whoever is going to use the software that you’re going to build. What do they care about?

The word “stakeholders” implies that they have a stake in the game. So the first step should be to talk to whoever the stakeholders are and let them choose what you work on during the next iteration.

Keep in mind, that there could be multiple stakeholders, and they could include your manager, other teams, or your team. You might have technical debt that you really need to pay off.

Expected time off

Does anyone on the team have vacation coming up? Is anyone going to training for a day or two? Is there a 3 hour meeting coming up about health insurance benefits that everyone is going to attend? All of these factor into how much time each person has to spend each iteration.

Utilization %

What percentage of each person’s time is spent on working towards completing tickets? No one spends 100% of their time working on tickets. We all have meetings, bathroom breaks, hallway conversations, and other things that don’t directly contribute towards moving tickets (however important they might be). I want to minimize the amount of this untracked time. Obviously, you want your people working on the task at hand instead of whatever distractions might come up, but I also want people to be creating tickets for things that come up during the iteration so that I can get a better picture of what goes on during an iteration (more on this later in the post).

Also, many people on the team, whether they notice or not, may perform multiple different functions. You might have a developer that does some testing, a QA person that does some analysis, and so on. So I don’t just want to know the percentage of time that goes towards moving tickets, I want to know the percentage of time spent on analysis, development, testing, and project/iteration management.

Normal working hours

Most employers assume a 40 hour work week, but that doesn’t mean that everyone works that. We’ve all worked with that person who puts 40 hours on their timesheet but works 50 hours. I’m sure employers and managers appreciate that person going the extra mile, but this really skews the capacity plan. If you use past iterations’ results as an indicator to help you predict how much work you can get done given a number of available hours, now you’re making assumptions off of data that isn’t accurate. What happens when the “dedicated” worker goes on vacation, or has something come up in his or her life and now they can’t work 50 hours anymore? You’re going to come up short.

I’m a big believer in sustainable pace and the idea that if we figure out how to work smarter in a reasonable amount of hours, we will outsmart and outpace the people who just throw more hours at a problem. I think of team members like washing machines — they work great, but if you put too much into it, everything they do needs to be redone. And of course, I want people on the team to have a good work/life balance. I want them to work hard, but I want them to enjoy their work and their life outside of work.

If you do have that person who wants to work extra hours for whatever reason, the important thing when it comes to capacity planning is that you’re aware of how much everyone is working so that you can factor that into your analysis. This means telling that guy who is working 50 hours to actually put 50 hours on his timesheet so that time doesn’t get lost for planning purposes.

Work coming into the iteration

This is a big one. This can come from some obvious sources, such as production support, bugs found during the iteration, or new work that gets “discovered” when you realize that a certain feature needs some other things to be done in order for it to work. It can also come from less obvious sources, such as impromptu email requests for help, adhoc query help, or time spent having to help someone on another team. You want to track all of this.

I’ve started becoming ridiculously meticulous about this. You might think that it’s no big deal if you spend 1 hour writing an adhoc query for your boss and not creating a ticket for it, but now you have unaccounted for time where you were working on something and you don’t have a record of it. I’ve started creating tickets for this sort of thing when these come up just so that I can have a record of the time that I spent doing that task.

When I’m doing capacity planning, I run queries to find out how what tickets were completed in the previous iteration that were created after the start of the previous iteration and I total up the number of hours/points that were in those tickets. Over time, you will start to see a trend that will help you predict approximately how much work you need to account for that you don’t know about yet.

Getting this right can really be a life saver. Last year, the project I was on was constantly falling short of their iteration commitments and we kept having to push tickets out to the next iteration. This was frustrating people in the business because they didn’t actually know when things would get done, and they couldn’t do their own planning because they couldn’t count on us to deliver. When we started adding up the hours spent on work that came into the iteration, it was pretty clear why we weren’t able to get all of the work done — because we had other things come up that were deemed to be more important.

Agile people will tell you that work coming into the iteration is OK because the business can choose to swap out items for more important tickets at any time. This is true, but too often the work that comes into the iteration is a production issue or high priority item for someone in the business and this will negatively impact other people whose tickets get moved out (whether they like it not). There’s always going to be some amount of this, but I would rather try to minimize it by expecting the unexpected up front.

Multiple projects

In many cases, one team might be responsible for different projects of kinds of work. A common example is when one team handles both maintenance/production support and new features. If you have any division of work on your team, then you need to track time at the same level. For example, let’s say that you have 2 people working on production support and maintenance and 4 people working on new features. You’re basically doing 2 mini-capacity plans for 2 mini-teams at this point. This is actually a really good thing, because like I said before, the smaller the team size, the easier it is to plan.

Analysis and testing

A common trap that managers fall into is thinking that there is a linear correlation between number of developers and the amount of work that gets done. If you have two developers working on a project and you add a third, you aren’t necessarily going to get 50% more done because someone has to analyze and test that work. When you’re estimating tickets, make sure you also get estimates for the analysis and testing! This can be especially hard for business analysts because analysis is sometimes a somewhat nebulous activity that involves meetings, reading, writing requirements, and any number of other activities. Some estimate is better than no estimate, and this in the best interest of the person whose time is being estimated, otherwise they could end up with way too much work to do in not enough time, and that’s not good for anybody.

Another common trap is not leaving enough time to adequately test the work that is being done. The definition of “adequate testing” can vary widely, and depending on the situation, you might want to do more or less testing. But too often testing gets ignored and people only look at the development estimates when they do their planning (and remember, if you develop something on the last day of the iteration, you probably won’t have time to test it). Your definition of done should include testing, not just development. Remember, we are trying to figure out how much work we can complete in an iteration, not just write code for.

Past performance

Is the team consistenly over-committing (or under-committing)? Do you notice that someone on the team consistently over-estimates how much work they can get done each iteration? No one estimates correctly 100% of the time, and usually people tend to consistenly over-estimate or (more likely) under-estimate. Over time, your data will begin to paint a picture for you so that you can make the necessary adjustments.

Team consistency

Analyzing past performance is much easier if the team remains consistent. If you are adding or removing team members or if your team members can randomly get pulled off to work on other projects, your data from past iterations won’t be applicable and you’ll be a lot closer to flying blind.

You’ll be much better off by keeping teams intact and bringing work to teams. It’s OK to have one team responsible for multiple projects because you’ll do one capacity plan that covers all of them. But if the makeup of the team itself is changing, you’re job is going to very difficult. Teams tend to work better when they work with the same people over a longer period of time (not to mention it’s good for morale).

Gut feel estimates

So what if you have all of this data, how do you actually come up with a number of tickets/points/hours that a team can complete in the next iteration? Some people might advocate taking the average velocity over a significant period of time and using that as the estimate. If you feel that you velocity data is steady and reliable enough, then maybe that works for you. More often than not, that hasn’t been the case for me.

If your velocity data isn’t giving you an obvious answer, there are alternatives. If I’ve been on a project for long enough and I feel like I have a good grasp of things, then I might take a gut feel estimate of how much we can get done (velocity), but I’m also going to take a gut feel estimate of other factors, like amount of work coming into the iteration, % of time people spend moving tickets, % of time spent on analysis vs. development vs. testing, etc. Then at the end of the iteration, I can adjust my velocity estimate based on how accurate I was both on the large-scale estimate and the estimate I had for smaller, more measurable data points. Over time, my “gut feel” will become less of a gut feel and more based on several data points. I like this approach because I feel that it gets me to accurate capacity planning faster than relying on velocity, which we know can vary based on lots of factors.

The end result

Ultimately we want to come up with a list of features that we can commit to getting done in an iteration. Obviously everything is subject to change, but the more confidence we have in being able to complete what we’ve committed to, the better. Everything that I’ve talked about in this post to this point all points towards this goal, but the process to get there can be quite complicated. Over time, your team should be able to deliver quality work in a predictable manner, which makes everyone happy.

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

In my last post, I talked about metrics and how they can positively and negatively affect your project. In this post, I wanted to focus specifically on burndown charts.

Burndown charts are a commonly used way to show the progress of a project. Here is a really basic burndown:

The green line shows the expected progress of the project. The line starts with the total amount of scope (measured in hours, points, # of tickets, etc.) and draws a line to the planned completion date. The red line shows the actual progress of the project over time. This is an easy and effective way to see if we’re ahead or behind and when we have large increases or decreases in the amount of scope, among other things. The x-axis of the chart can be measured in days, weeks, iterations, or however often you want to measure the progress.

People often show other data on burndowns as well. For example:

• Total scope
• Total work completed (“burn-up”)
• Work completed each iteration (velocity)
• Expected total scope (if you expect a significant amount of work to be added over time)
• Notes about significant events

Here are some burndowns that I’ve used over time.

Project level burndowns vs. iteration level burndowns

You can use burndowns to track the progress of a project over multiple iterations, but some people also use burndowns to track progress of work in a given iteration. In this post is going to focus primarily on project-level burndowns.

Learning experiences

Here are some burndowns that I’ve used in the past. I call these “learning experiences” because some worked better than others.

There are some interesting things going on here. First of all, the red line represents “Ideal Remaining Work” and instead of this being a straight line, it’s quite jagged. On this project (and many projects), the number of people focusing on the project was going to change over time. For a couple iterations, it was going to be one business analyst working on the project. Eventually we added in a few devs and testers, then didn’t have much work for an iteration or two (waiting for other teams to do their part, but no work for us). Then in the last iteration we completed a bunch of work that had to be done at the last minute. A straight downward line would not have reflected this schedule, so I made the red line reflect what we were planning for.

There were also a few hiccups along the way that pulled our focus from the project and made us focus on other things. Since we adjusted our plan, I adjusted the burndown accordingly and added some notes to explain what happened. One of my main points in my last post about metrics was that you have to be careful about people misinterpreting raw data from burndown charts, which is where the callouts come in handy.

This is the burndown from the last post. On this project, we had some scope defined but we also knew that there was going to be a significant amount of more scope that we would uncover along the way. So I added an “Expected Total Hours” line that projected the scope increases over time (we based this line on the amount of scope increases from our previous project which was very similar to this one). The “Total Hours” line showed the total actual scope over time. As you can see, we were extremely accurate on the scope increases over time (because we tracked everything that we could and based our estimates on past data).

As I mentioned in that post, on this project the burndown was showing that we were ahead, but I knew that things had gone smoother than expected and as soon as we hit one bump in the road we would be behind. When you look at this chart, it’s really tempting to see a trend in the “Hours Remaining” line and visualize that heading down towards an early completion date. I felt that this was optimistic, but that’s the message that the burndown was sending.

In reality, this was more accurate:

Here I added two more lines that showed that you would end up at different result depending on whether things were to go well or go poorly. The closer you get to the release date, the more certain you become of the result, but when you’re farther away, lots can change. This more accurately reflects that there was good chance of finishing on time, but there was still a risk of not making it.

Lo and behold, this happened the next day.

BOOM! The bump in the road that I expected happened. Suddenly things weren’t so rosy. In fact it didn’t look good at all. Thanks to my burndown chart, I (and everyone else that cared) immediately knew about it. Now look at my chances of finishing on time — not so good.

The learning experience here is that if I had had the dotted lines earlier showing the potential range of finishing points, I probably would’ve been able to show earlier that the project was at risk.

(Side note: this post is from awhile ago but it illustrates the same concept with some other cool ideas.)

Should you post a burndown chart?

I’ve had a lot of learning experiences with burndown charts, but the main takeaway is that you have to be careful posting charts and data that leave the interpretation up to the person who is looking at it. In my opinion, if someone misinterprets a burndown chart, that’s a lot worse than them not being able to see the burndown at all, because now they think they know the status of the project when what they think they know isn’t the truth. Not only that, you won’t necessarily know that they made an incorrect interpretation.

Because of this, I would be careful about sharing a burndown chart with others. I’m all for sharing information about a project with others, especially management. But I want to know exactly what it is that they want to know and then figure out the best way to communicate to them. Maybe that’s with a burndown chart (potentially with lots of callouts and accompanying explanations). But it might also be an email or a meeting where I use red/yellow/green indicators to indicate whether I think we’re on track, or maybe I just have a conversation.

I think creating a burndown and collecting all of the data needed to create it are invaluable, but that doesn’t mean that you need to publicize that information. You should certainly use the information to help with your own planning.