Monthly Archives: May 2012

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.

The Why of Scrum — The Standup

A wise man once told me that most developers dont care about the why, they only care about the how. That is especially true around process and agile development. Developers want to know “how” to do scrum, but rarely want to know “why” they do it. The issue with this mindset is that scrum and agile in general are highly adaptable. Scrum is full of independent concepts that can be adapted to your individual circumstances in order to achieve a highly efficient and productive team. However, when you don’t understand why you are doing them, you tend to adapt out the good stuff and miss the whole point of what you are trying to accomplish with Scrum.

Probably the most misunderstood and abused concept in Scrum is the daily stand-up. I have seen many instances where developers go through the motions of the stand-up, they even ask and answer all the right questions, but they are doing it for all the wrong reasons. Ultimately, the purpose of the stand-up is for the team to know what the team is doing. The purpose is not for the scrum master, project manager, or team lead to know what the team is doing. When you pull a team together for a daily stand-up, that is their opportunity to listen to what is going on, understand where the pieces they are waiting on are at, know what struggles their teammates are going through, and be able to voice what your own struggles are in an attempt to get assistance or understanding from the team.

At its core, the stand-up is about forming a group of people that are all in this together. In other words, a team… If you are checking your email while your peer is giving a status report to the team lead, you are not part of a team. You are an individual who may or may not contribute to the overall success of the group. If you are “tweeting” instead of listening to the struggles of your peers, you may be doomed to repeat their pitfalls.

So, tomorrow in your stand-up, put your phone down and make eye contact with every person that gives their update. Ask yourself, “How does that impact me?” or “Have I struggled with that before?” Have your first response be, how can I help these people out to contribute to the overall success of the group. That ultimately is what a team does.

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.

Kanban, Writing Code is Like Building a Car

The first step in improving your environment and taking steps to become more agile is understanding what is going on in your pipeline. Many shops today have no concept of where all their various changes are, what state they are in, and when they can expect to get stuff out the door. Dev churns out code as fast as they can and then they lob it over the wall to QA. QA is almost always understaffed and can’t keep up with the mass of code that keeps being flung at them from the developers. When you throw in architecture and user acceptance testing, you can end up with a real logistics issue. The question is, how do you fix it?

Back in the 1940’s Toyota had similar issue with their manufacturing plants. They had inefficiencies all throughout their pipeline but had real trouble sorting them out. They found a solution in an unlikely place, Supermarkets. They began to study the way the supermarket pipeline worked. First, a customer buys items off the shelf, then the items are restocked from the back, then that inventory is ordered from the vendor. It would seem ridiculous for the stock guy to randomly deliver more cans of beans to the front of the store. He only delivers enough to replenish what had been sold.

Toyota applied that same concept to cars. When a certain amount of doors had been put onto cars, a request is put in to build more doors. Those doors are delivered just in time to be used on the next group of cars. This is referred to as “Pulling the demand.” Starting at the end of the process, each step pulls what they need from the process upstream.

All too often in software development, we “Push” instead of pull. We get stuff done as fast as we can and push it up to the next level with no concept of what that means downstream. Our developer stockers keep wheeling out cans of beans to the front of the store, even though there is no room on the shelf for it to sit. We do this, mostly because we don’t understand where our limits are and how to streamline.

This is where the Kanban board comes in. The Kanban board is a way to track all the moving parts in your pipeline. Take a big piece of paper and mark 5 columns on it. Label the columns something like “Architecture”, “Development”, “QA”, “UAT”, and “Deploy”. Take that board and publish it in a public place. Now write down everything that is currently in process. Put each item on a card and stick it up on the board in the proper sections. That exercise alone can be eye opening. In many shops, you will have 4 items in “Development” and 27 items in “QA” or past. In this case, Dev is pushing out code as fast as they can, but nothing is getting done because it gets stuck downstream.

That is the simple beauty of the Kanban board. It gives you a very visual indication of what is going on in your process. It is very simple to see where the bottle necks are and gives you some tools to start fixing that problem.

Now, what do you do with that information? It really depends on where your issues are. Do you stop development and have you developers start automating test plans? That could work. Maybe help out UAT by sitting down with the business partner and doing working sessions. Fix defects proactively instead of waiting for QA to find them. All are reasonable options, but whatever you do, don’t perpetuate the problem. Once you see an area over worked, stop adding to it.

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.