Category Archives: Agile

Why Building Software Is Not Like Building A House

Ok, I have had this conversation too many times to count. And depending on the social setting, I have argued it from both directions. (stick with me for a minute….) I truly believe that you can build software like you do construction. It can work. BUT I firmly believe that you should not do that. Not because its hard, but because we have an awesome opportunity with software to build something together with the business and not for the business. And that is the key difference.

Now, if I could build the house the way I build software, it would look something like this. I would put up four walls and a door and have the user come stand in the house. I would then ask “What else do you need?” They would give me feed back like “Its dark in here… maybe some lights?” I would go build the lights and windows, and the rest of their “needs” list and call that their “mvh” minimum viable house. Once I was done with that, I would walk them through the house and say, “Here is your house, move in today.” but I wouldn’t stop there” I would go on to say “now tell me everything you want in order of priority and I will add them one by one until you feel like we are done.” All the while, they can live in the house. Wouldn’t that be cool? Except, you can’t do that with a house. You can’t cheaply and affordably add lighting and windows and extra rooms on to a house after construction is complete. Or change the color of the cabinets or carpet. You can however do that in software.

The conversation always seems to go “you should be able to build software like construction” and the reality is you can. But, for me, the question is “Why would you conform yourself to a process that is restrictive and painful when there is a MUCH better way?” Building software gives us the opportunity to truly create something in a collaborative environment with everyone involved. Yes, you CAN do big up front design and estimation, and contract negotiation, or I can use that same time to build something usable that we can use to get test with actual real paying customers.

The paridime is different. Don’t conform to something just because it “seems” to work in other unrelated fields.

The Elevator Pitch

Could you clearly and concisely explain to someone what the project you are working on does? Not technically, but from a business perspective? Could you, if asked, explain what the main features are and why your project is a good alternative to the status quo? In other words, can you give a business justification for the project?

If you can, fantastic. You are making good strides in setting your project up for success. If you said no however, you are unfortunately in the vast majority of development teams out there. As developers we tend to separate our teams into the “business units” and the “technical” groups. We figure that we can deal with the tech decisions and they can make the business decisions and everyone will be happy. Unfortunately for us, we forget that every decision we make, impacts the business. We are all on the business side of the project. As developers, we make hundreds of small decisions every day and it is very easy for us to get caught up in the tech, and lose sight of what the real purpose of the project is. In my Why are we here post, I talked about the importance of understanding why we are doing a project and to keep the customer in mind as we do it. The next logical step in that process is to formulate a clear and concise explanation of the “why” so we can both keep ourselves focused, but also to aid us as we engage our neighbors. I call this, “The Elevator Pitch”

Now, this concept is not new. If you stepped onto an elevator with someone and you had to explain something to them before you got to your floor, could you? Some elevators are slower than others, and in my building I could read them a 30 page document by the time I hit the 3rd floor, but you get the basic idea… And besides that, you should be taking the stairs anyway… But I digress…

In order to formulate an elevator pitch you need a few important pieces of information. If you are already working, you should have them. However, if you dont, call together the “A Team” (thats a different blog post) and the Product Owner ( Yet another post) and ask these simple questions.

    Who will be using this product?
    What is the basic thing they are trying to accomplish?
    What is the key benefit of this product?
    What is different between the current state and the new state?

Ok, now that you have all of that, you need to put it together in a clear and concise format. This seems to work well for me.

For [Customer]
Who needs to [Need]
The [Product Name]
Is a [Category]
That will [Key Benefit]
Unlike [Primary Alternative]
The new system will [Differentiator]

So,

For The Accounts Payable Team
Who needs to effectively process invoices
the paytastic 1000
is an online payment system
that will allow AP to process invoices quickly and efficiently.
Unlike the current paper based system
The New System will ensure that invoices are not lost and kept in proper workflow.

Now, with that simple explanation, you can clearly explain to anyone what it is you are trying to do and what the most important things are.

Why Are We Here?

Back in the early 2000s, Toyota had a vision of building the number one best selling minivan in North America. Their current minivan, the Sienna, was small, underpowered, and badly needed help.  Yuji Yokoya was given the job of re-engineering the Sienna. There was just one problem, Yuji, lived in Japan. He did not know the people or places that he would be engineering for. Believe it or not, Japan is nothing like North America. So, what does a chief engineer do in a situation like that? He packed up his team and flew halfway around the world. He made a commitment to drive through every state in the US, every province in Canada, and Mexico. He met the people and drove the roads that the Sienna would be driving. And guess what, what he learned on that trip revolutionized the Sienna. The innovations he made, sent the Sienna to number one. Why? Because he knew who he was building his product for. He knew, why he was there.

Let me ask you this, do you know why you are building what you are building? As a member of a product team, can you tell me how your product will be used in the real world? As you are writing code, building test plans, writing stories, or any of the other project tasks, can you picture the face of a person who will be using what you are building? All to often, the answer to those questions is, no. Why is it important? Because, every day, project team members make assumptions. Over a given project, it is safe to say project team members will make thousands of assumptions about what they are doing. And all to often, those assumptions are not quite right. Its not that they are not good at their job, its just that they don’t really know why they are there.

So, what to do? First and foremost, stop doing what you are doing. Yes, really. Schedule some time to go visit the people who will be using your product. Don’t invite them to you, go to them. Watch them work. Interact with them. Ask them questions. Maybe even try it out yourself. This serves two purposes. One, It shows them that you care about them. They will be far more engaged in your project if they feel like you care. And nothing says you care more that spending some time. Second, it gives you the proper frame of reference for you work. It gives you something tangible to go back to as you are building your product. As you make the thousands of assumptions that you will make over the life of your project, it gives you something to see in your mind that makes it real to you.

Ultimately, setting a proper frame of reference is critical to the overall success of a project. The funny thing is, it really does not even take that long. In most cases, a 2-3 hour session will give you most of what you need to get the right insight. For the project, it will be the best 2 hours you could spend. 

TFS In The Cloud

I am starting a new blog series over at geeks with blogs about TFS in the cloud. What I have found is that one of the greatest barriers to entry for many developers getting into TFS is the setup and install of the system. Fortunately, Microsoft has made it possible for anyone to stand up an their own private instance of TFS in the cloud. Just a few clicks of the mouse and you can have a fully functional TFS instance including source control, work item tracking, and all the dash boarding you could ask for.

Read the whole post here.

Is It Done? Really?

Everyone has done it, you know you have too. When someone asks you for a status update on a new feature you just finished coding, you say “That’s Done!” Think about what you just said for a minute, is it really done? Can someone use that feature in production for its intended purpose? That’s really what done means, right? To the end user, done means its up and running, in production, providing value. Code complete is just another stage in the pipeline getting us out to really done.

You may say, that is a semantic argument. Your piece is done, so you get to say done. I would argue, its a mindset discussion. As developers, if we think about our piece, and only our piece, we say done when our piece is done. Agile is about picking your head up and looking at more than just your piece. Collaboration and a sense of unity across the entire product team is critical to a successful agile organization. We as developers need to move away from our tasks as “in dev” and “done”. We have to get to the point where we think of a feature in development, or in test, or in requirements. We need to pick our heads up and see the whole picture, not just our piece. Next time your manager or scrum master asks you for a status on a feature you just completed coding, resist the urge. Instead of saying, “that’s done”, give them the actual status of the feature. Your larger team will thank you for it.

Agile Principles — Continuous Delivery

Probably the most important principle in all of agile development reads like this…

Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.

I like to sum this up in one succinct statement, software that is sitting in QA is not providing value to anyone.

The most important thing an agile practitioner can do is identify valuble pieces of software and get them to production as fast as posible. Notice that this principle does not specify a timebox, or iteration length or any other such thing. The key is in the term continuously. As soon as you have something that could be providing value, get it out the door.

Agile is not what you do, its what you are.

Agile is one of those super buzzwords that everyone knows. The problem starts when you ask people what it means. It seems that the more people I ask, the more answers I get. One of my standard interview questions is, what development process do you use where you are today? I am always frustrated when they say, we “do” agile. My canned response is “What does that mean?” Very few developers can answer that question. I get the standard, “we have daily meetings and we don’t do requirements.” That hardly sounds like a development process. It sounds more like chaos. And unfortunately, many shops that “do” agile are nothing more than cowboy shops that use agile as an excuse to not plan. They are missing the whole point of what agile is.

In February 2001, Kent Beck and Bob Martin pulled a group of “lightweight” method leaders into one room at the Snowbird ski resort in Utah. Their purpose was to come to a consensus on lightweight methodologies and what the core principles are. What resulted from those discussions was called “The Agile Manifesto.” They concluded that the agile movement can be boiled down to four core principles. Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, and Responding to change over following a plan. This is the very essence of agile. It is very important that developers understand the core principles of agile before embracing one of the many agile methodologies out there.

These tenants basically come to this, if you have the right people, they will do the right thing. Processes should be in place to equip developers to get their jobs done, not hold them back. Documentation is useful but only if people are going to read it and respond to it. Agile is not about swapping one rigid mindless process for another. Can I run waterfall in an agile fashion? Yes, as long as I understand change is coming and include change procedures in my process I am well within the spirit of agile. As long as I understand developers can’t work in a vacuum and encourage them to ask questions and have interaction with the business partner, I am being agile. If I am running Scrum and throw a fit when something interrupts my well laid out sprint, I have missed the point.
The bottom line here is this, Agile is not a process, it is not something you do. Agile is a philosophy. You bring the agile tenants to whatever process you have in place today. In my last post I talked about the agile approach to doing agile. The idea there is, over time, insert these core concepts into your process. Agile is not a process change, it’s a mentality change.

I will leave it to Jim Highsmith to summarize,

The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.We hope that our work together as the Agile Alliance helps others in our profession to think about software development, methodologies, and organizations, in new, more agile, ways. If so, we’ve accomplished our goals.

The Agile Approach to “Doing” Agile

Over the past few years, I have watched developers go to conferences and be filled with excitement over agile development. We love the thought of the rapid changes and better feedback. We get into the buzzwords like Scrum, and Kanban, and the term Burndown list excites every developer’s inner pyromaniac. Then, we take all that excitement back to our day to day lives and quickly find out that we are not in a position to change the process that is in place. Developers talk to me all the time about wanting to “do” agile, wanting to do that lean development that everyone is talking about, but they can’t because their boss, or manager, or the project manager say no.
The biggest mistake we make is trying to sell a whole agile process (Scrum, lean, Kanban, etc…) all at once. We are essentially walking up to our boss and saying, “let’s throw our process away and try a new one.” I can understand how this can be met with some reluctance. At this point there is almost no incentive for the manager to switch. You can promise him all the standard agile talking points, “working code more often”, “more communication”, etc, but to him it’s all just smoke with no substance. More often than not you have to prove to him that it will work before the people who make those decisions will say yes.
Now you find yourself in a difficult position, you can’t “do” agile without showing management that it works. You can’t show management that it works without “doing” agile. What is a developer to do?
One of the core agile tenants is small iterative changes delivered often. Write a small piece of functionality, then deploy it. Write the next piece, and deploy that. Repeat until you are done. It would seem that using the same process to implement agile methodologies into you organization would just make sense. What if, instead of walking in and saying “I want to do Scrum!” you just start doing it. What if you sat down and created a list of everything you had to do? Don’t call it a “product backlog,” just call it a list. Then, what if you meet every day among your team to discuss how the work on the list is going? Don’t call it a “stand-up”, just call it a meeting. Then, what if you start letting QA and the BU see what you have completed. Invite them to a meeting and say,” we just wanted to show you what we have been doing.” Don’t call it a “Sprint Review Meeting”, just call it a demo.
I hope it is obvious where this is going. At some point you can walk into your boss’s office and say, why don’t you just let me keep doing what I am doing? That seems so much easier than asking him to let you change the current process.
For that reason, don’t hide what you are doing. Let everyone know what you are doing and how it is going. You want to build some legitimate excitement around what is going on. Having the conversation with management that you are now tracking what is coming up in a list and meeting daily to talk about how that list is going is critical to getting them to buy in to the process.