Tuesday, February 10, 2009

Short iterations are the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work. Some of the benefits of short iterations include working software that you can show to people in order to get their feedback and having nothing in progress at the end of the iteration so you can change your plans to take into account market changes, feedback from customers, or information you discovered while implementing that iteration. Also, all of the tests for the functionality implemented during the iteration have been written and run and you have a well known starting point for the next iteration.

There are some assumptions hiding in this practice. It assumes that you believe that incremental design is possible and that you believe that any refactoring you have to do in subsequent iterations is worth the benefits as described above.

So, if you were starting a company with your own hard-earned cash, would you use short iterations or wouldn't you?

A product backlog is a list of high-level product requirements (or user stories), prioritized by business value (typically determined by a product manager or product owner). It contains entries for any and all work that is performed, including bug fixes. As new requirements are gathered or submitted, they are inserted into the backlog at the position that best represents their business value with respect to requirements that have already been entered. As requirements are met, they are removed from the product backlog.

A backlog gives a clear context to discussions of priority. Anybody can go and look at the backlog to see the position of something they have a stake in. If it is lower than they think it should be, they can examine the backlog to see what is higher in order to help frame a discussion around either moving it higher or moving other things lower.

So, if you were starting a software company with your own hard-earned cash, would you use a product backlog or wouldn't you?

User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

So, if you were starting a software company with your own hard-earned cash, would you use user stories or not?

Collocation is simply having everybody on a whole team in close proximity to each other. This compounds the coordination benefit of whole teams. This is not related to using or not using outsourcing. Whether you are outsourcing or not, collocation only refers to whether your whole teams are sitting near each other.

So, if you were starting your own software company with your own hard-earned cash, would you use collocation or wouldn't you?

A whole team is a small group of people (no more than 12) that work together towards a common purpose, primarily spend their time as part of the team, and as a team have all of the skills they need in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

So, if you were starting a new software company with your own hard-earned cash, would you use whole teams or wouldn't you?

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on. Unit testing and refactoring are often done hand in hand.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

So, if you were starting a new software company with your own hard-earned cash, would you use unit tests or wouldn't you?

Incremental design is the practice of designing as you implement. You may do some upfront work to sketch out the basic ideas and groundwork, but don't have a fully fleshed out design up front. The basic idea is that you only implement what you absolutely need to satisfy the user-centered work that you have committed to for the current milestone/iteration. That way, you don't spend time designing for work that you never do.

If you aren't doing incremental design, don’t you end up having to make changes to your software during the next release to take into account all of the feedback and requests for new features that you get from customers? Don’t you have to rework the software (including the design) anyway? Aren't you already doing incremental design on a macro scale anyway?

One of the points of incremental design is that design changes are inevitable and that you are better off writing your code in ways that make it more amenable to design changes. For instance, unit tests encourage the creation of mock objects and the use of mock objects encourage the creation of abstraction layers which as we all know are a good thing.

And let’s not forget that dirty little “major overhaul” secret. You show me some software developed without incremental design that hasn’t had a “major overhaul” and I’ll buy you dinner. So, if you agree that you are going to have to make changes to your design anyway, sometimes major changes, why wouldn’t you want to do incremental design?

Last question. With the exception of change reviews, all of the practices listed are the core of Agile development. Sure, there's that whole philosophy and manifesto stuff. But IMHO, if you are doing short iterations (for real) and many or most of the other practices, you are doing Agile development. No 3x5 cards, pair programming, certification, or manifesto required. Just don't like the idea of a new word or "joining a movement?" No problem, improving your dev process is the goal, not "doing Agile right" or anything else for that matter.

For any of the practices that you are not currently doing but that you believe have a significant benefit, think about what the combined effect would be if you implemented all of them. It may take time to achieve, but it will definitely be worth the investment.

So, you are starting a new software company with your own hard-earned cash. What software development methodology will you use?

A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.

So, if you were starting a software company with your own money, would you use retrospectives or wouldn't you?

Milestone, or iteration reviews, are done at the end of each milestone or iteration. It is a demonstration to key stakeholders including one or more customers that you have completed the work for that milestone. It is also an opportunity for the stakeholders to provide feedback on the work. Reviews provide a test of the functionality, show progress towards goals, and build confidence in the work. The demonstration is a visible, trustworthy, and confidence building way of showing progress. If you can’t demo the work, how do you know how much real progress you are making?

So, if you were starting a software company with your own money, would you do milestone reviews or wouldn't you?

A change review, aka a code review, is a review of the changes (code or otherwise) that were done in order to fix a bug or produce an enhancement. This can be as simple as having an engineer other than the author review the changes and provide comments to the author to something as sophisticated as using a specific code review methodology and/or a code review tool such as Smart Bear. So, if you were starting a software company with your own money, would you do code reviews or wouldn't you?

A stand-up meeting is a quick daily meeting of the whole team where you answer three questions: what did you do since the last meeting, what will you do until the next meeting, and what impediments do you have. Everybody gets a quick sense of how things are going and who needs help. The benefits are that problems don’t fester for long and it removes the need for most other meetings.

So, if you were starting a new software company with your own hard-earned cash, would you use stand-up meetings or wouldn't you?

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don't have adequate testing in place.

If you were starting a software company with your own hard-earned cash, would you use refactoring or wouldn't you?

With Continuous Integration, all work from all teams is integrated into a single codeline as frequently as possible. Every check-in automatically triggers a build and usually a subsequent run of the test suite. This provides instant feedback about problems to all interested parties and helps to keep the code base free of build and test failures. It also reduces the integration headaches just prior to release.

There are two benefits of Continuous Integration. The first is that it forces you to break work down into small, manageable pieces. The second is that it spreads the integration work out over the entire development timeframe instead of just a short period at the end. Thus, you have more time to find and fix issues instead of a compressed high-stress window at the end of the release.

So, if you were starting a software company with your own money, would you use continuous integration or wouldn’t you?

If there are other practices you would like me to add to this survey, or other general comments you'd like to make, please comment below. If you think there are practices that just don't belong on here, I'd be interested to hear which ones and why.

Thursday, February 05, 2009

If you are in the Boston area, consider going to the Agile Transformation Seminar on Thursday February 26th in Lexington. The seminar is a 1/2 day in-depth look at the business benefits of Agile and includes a case study on Avid's Agile transformation. My session will be about the effects of Agile on the needs of your tool infrastructure.

Before I get too far into what I believe about Agile, let me give a little background. In 2005, I was a staunch Waterfallian. Stuff happened (blogged elsewhere) and then I turned into an Agile advocate.

There are two important things that I believe about Agile. First, while I do believe that being Agile is more than just a set of practices, I also believe that there are a set of practices which are so good that for me they define what I currently think of as Agile and believe everybody can do them and would benefit from them.

I truly believe the benefits of Agile are significant enough to focus your resources to get to the point of saying this sentence.

This is based on the belief that the algorithm of Agile is just plain better than traditional development combined with direct observation of the significant benefits experienced by both external and internal teams.

To put it another way, if you are not yet investing in Agile, I believe it is the #1 investment you can make to increase your productivity, quality, revenues, customer satisfaction, profitability, and employee satisfaction. It is possible to invest in Agile but not get these benefits. If that is happening to you, I urge you to stick to your guns and look for help. Getting to Agile is worth the investment. It is worth redirecting resources, changing priorities, and doing what it takes to get there.

Wednesday, February 04, 2009

First of all, it is important to note that "Agile" is just a word and means different things to different people. There is a good chance that we have different definitions of what “Agile” means. If you want to know what I mean by Agile, please read “How Agile Works in a Nutshell”.

That’s often true, but it is not actually an impediment. While frequent releases are an important benefit, it takes time to get to that point, isn’t the right option for all situations, is just one of the benefits, and is not required to get the other benefits. Read more in a series of posts on this subject.

9. “The advocates are overzealous and arrogant.”

Yes, some of them are. But not all of them. Many people are overzealous and arrogant, that’s not unique to Agile. It is the concepts of Agile that make Agile worthwhile, not the advocates.

8. “It is all just a marketing ploy. You don’t really believe Agile is any better than traditional development and in fact it is just more of the same stuff in a shiny new package. You just want to hop on the buzzwagon.”

This one is hard to refute. The only way I can dispel that belief is if you get to know me better.

7. “I haven’t tried it, and I believe Agile Development is a good development method, but it is just another flavor. Whatever works for you.”

You may be of the opinion that traditional vs Agile is just a preference/philosophy/ideology thing, like chocolate vs strawberry, Aristotle vs Plato, Democrat vs Republican. But then in that case, why would anybody go to all of the effort of investing in Agile? Tech folks don't generally make massive switch-overs from one way of doing things to another just for preference or just to be 2% more productive, they generally only switch in order to get an order of magnitude improvement. So, if it is just a preference thing, there's not much to talk about (from my perspective).

6. “Yeah, I tried that Agile thing. What a disaster!”

There are any number of reasons for failure. I've seen plenty of cases of Agile failure. But in every case that I've seen "Agile failure" it was either because it wasn't really Agile that was being done, or there was a major impediment. An example of a major impediment would be that the attempt was initiated by executive decree followed by no investment in success and a goal of 100% Agile within an impossibly short amount of time. I realize that saying “it probably wasn’t really Agile” sounds pretty convenient. But, I have yet to hear anybody say "I feel like we were really doing it right, but it just didn't work." If that's something that you would say, I'd love to hear from you.

5. “Yeah, I know a group doing Agile and they are really successful. But they would succeed anyway because they’ve got all of the best people on that team.”

All I can say to that is that for me Agile is only worthwhile if it is something that has mainstream applicability. If it won’t work for the majority of teams, it isn’t interesting to me.

4. “I believe that you believe that it is better, but I can clearly see that it is not. I don’t know what your reasoning is, but it is clearly wrong.”

This is exactly what I was saying in 2005. Well, that works both ways and I’ve been on both sides of it. All I can say is that I believe it is worth your time to consider that if so many people that have devoted so much energy to the software development process believe that Agile is a good thing, then maybe there really is something worthwhile about Agile and it is worth your time to learn more about it.

3. “You don’t really understand how successful traditional development can be, and there are probably a bunch of techniques for success you are not aware of.”

My career for the past twenty years has been to contribute to the software process improvement efforts of countless companies. So it isn’t that. By the way, if you haven’t heard of the Niagra method (the best traditional development method), you should take a look.

2. “You have blind faith in Agile. You want it to be better and you will ignore any evidence to the contrary.”

Well, you'll have to take my word for it that I'm a very pragmatic person. If something isn't working, and it doesn't look like it is going to, I don't have a lot of patience to continue doing it just because I think it should work. I originally believed in Agile when I realized that it is algorithmically better than traditional development. But now I believe in Agile because I've experienced significant benefits from practicing it.

1. And the number one reason I may be wrong is the one I don't know about yet. If you've got a good one that I haven't covered, please let me know. I look forward to your thoughts and feedback.