Archives for category: Processes

Agile Architecture

January 27, 2013 //

I got asked recently about the role of architecture in agile development. Basically, the question boils down to some variation of “Is there a place for architecture in agile development?” This is a common and mostly misunderstood question. It seems like it gets asked on every project. It’s based on a faulty assumption: that architecture is something that is stand alone, that can be bolted on to a project.

To talk about agile architecture, you first need to understand what architecture is. Once you know what architecture is, and what it isn’t, the question changes to “How can you do good architecture in agile development?”

Read the rest of this entry »

Categories Agile, Architecture, Processes

Lateness in Agile Projects

January 21, 2013 //

I’m late! I’m late! My whole project is late!

Can an agile project be late? What does it mean for an agile project to be late? There are really two different kinds of lateness for agile projects. First, there’s the kind that everyone thinks of “this project will take 8 sprints instead of 6 so release it”. Then there’s the more insidious kind, “these stories got started but not completed in the sprint”.

Read the rest of this entry »

Categories Agile, Processes

TDD Drag

December 7, 2012 //

One of the arguments that I see a lot in favor of Test Driven Development is that it helps deliver higher quality software more quickly. The more I projects I take part in or observe, I realize that this is only half true, and less than half true for Agile projects. I’m not saying that TDD has no place in Agile projects, just that it has a very specific place and time.

Read the rest of this entry »

Categories Agile, Software Development, Testing

Atomic Stories

November 21, 2012 //

One of the causes of death march project is poor story definition. Whether you call them stories, features, tasks, items or whatever, defining good stories is essential for success.

The ACID principle from database design applies to stories as well as databases. Atomicity, Consistency, Isolation and Durability. These principles apply to story design as much as they do to anything else.

Read the rest of this entry »

Categories Agile, Processes, Software Development

Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Alpha Edition

It’s an interesting primer on Ruby on Rails, test driven development and agile development. It’s geared at undergrad computer science students and does a good job for that.

However, as an experienced professional, I was looking for many of the chapters that aren’t written yet. For example, the chapters on creating testable javascript and writing maintainable client side code were missing. In a nutshell, wait for the beta edition if you already know rails.

I thought that it was an interesting experiment in lean writing. The idea was to write just the chapters that you need now and see what the interest is in the other chapters. It will be fun to see what happens in future versions of the book.

Categories Agile, Personal Development, Software Development

Fixed Time, Fixed Price Agile Development (Part 3 of 3)

June 12, 2012 //

Fixed time, fixed price development is really about managing the project across sprints to make sure that you hit the finish line at the right time. Except in the most trivial projects that can be done in a single sprint, this will involve coordinating and planning across multiple sprints until the release date.

That pretty much makes the strategic planning aspect of managing the project the most important part. It seems like most of the time the planning runs into issues it comes down to a choice between two excuses:

It’s taking us longer than we thought. (bad velocity tracking)
We need to add this other thing before we can move on. (scope management)

Read the rest of this entry »

Categories Agile, Processes

Fixed Time, Fixed Price Agile Development (Part 2 of 3)

June 4, 2012 //

The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.

Scope management is the second most important part of doing successful fixed time fixed price development, or any development for that matter. Scope is essentially the “definition of done” for the business process.

The definition of done for a task is defined by the team as incorporating certain things: unit tests, integration tests, documentation or whatever. When all the criteria for “Done” are met, the task is done. Scope is the same sort of thing, just for the entire project. When all the things that are in scope are done, the project is done.

Read the rest of this entry »

Categories Agile, Processes

Fixed Time, Fixed Price Agile Development (Part 1 of 3)

May 28, 2012 //

I always wonder when I see another article about how it’s impossible to do Agile software development on a fixed time/fixed price basis. Especially because I’ve spent 75% of my career doing exactly that. The thing that really gets me is when people write that the only way to do accurate estimation is to have complete and detailed requirements up front. As if having 400 pages of cut and paste business speak to adhere to is going to magically solve the problem.

I realized after starting this that this is a big topic and should get split into multiple parts. So here’s the most important, or at least first part.

Read the rest of this entry »

Categories Agile, Processes

The Guru Sea Change

May 7, 2012 //

As a project grows the role of the guru has to change with it. At the start the guru is the technical wizard writing a lot of code because he is the entire technical team. When the project is large, he isn’t so much a coder but a coordinator and manager of the technical vision. Those are two very different sets of skills that don’t really have that much overlap.

Read the rest of this entry »

Categories Personal Development, Processes

Goldilocks’ Processes

April 30, 2012 //

Some processes are too big, some are too small so how do you find what’s just right? A lot of people would argue that highly detailed processes with buy in from a lot of different stakeholders slows the pace of software development. The fundamental reason for “agile” methods is to cut the overhead out of the processes to focus back on delivering value to the customer. Read the rest of this entry »

Categories Processes