This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Tuesday, March 28, 2006

Agile shifts the economics of software development

I often hear this argument about "re-engineering" also known as "refactoring" in Agile circles:

[...] it is difficult to justify work that doesn't bring any added value or whose results cannot be measured to evaluate the _immediate_ outcome.
As a software development manager, I've been also on the side of "there's no justification for re-engineering, just implement the feature!", why I've been there (and are not anymore) is that at that time I understood the problem wrongly!

One of the problems with justifying improving code quality ("re-engineering" in this quote) may be one of scale.
Normally (in legacy code and waterfall projects) improving code quality means spending a lot of time going over code that already works and trying to make it more flexible so that some code that does not work (typically a new feature) starts working.

This is hard to justify because of the size of the investment (too much code to "re-write" or at least "improve") and the fact that the outcome is very unclear (we don't know if the code that does not work today will actually work once we have "re-engineered" the legacy/older code).

Agile shifts the economics by putting the emphasis on "re-engineering" the code (actually: refactoring) at every step of the way, not in one massive go!
In Agile projects refactoring is just part of coding, you must refactor every day to improve the code quality and to facilitate the development of new features.

In Agile projects (because of this economic shift) you don't need to justify the refactoring, you do it as part of your daily work, pretty much the same argument can also be used to explain why Test Driven Development is done: it does not cost more, it is just part of coding. By doing it at every step of the way you don't add costs, you actually contribute to higher productivity by doing small improvements that will avoid larger problems in the medium/short term!

If you or one of your managers are stuck on the "there's no justification for re-engineering" camp it maybe because you/them have not yet understood the economics shift that Agile software development brings to software development.

Agile software development (re-factoring and TDD as one example) just simply change the context (do it every day, not when you bump into a wall) and with that they make quality code part of our daily life!

As an example I can quote one of the developers working in my previous team: "I was working in a consulting company and there the pressure was always to deliver more features we had no time to do the things right! Now in this way of working (Scrum with XP practices) I finally can be proud of what I do because I have the possibility to do the things right!"
NOTE: the productivity of that person was higher not lower than in his previous job! ;)

at 11:48 | 2 comments links to this post
RSS link

Bookmark and Share

Monday, March 27, 2006

How others see Agile/Scrum

In our company we have been going through the agile development transition for 1,5 years. The most interesting part of this transition is to see people's reaction to the change.

Certainly there are negative reactions (a lot) mostly due to lack of understanding or not being able to adapt to a new way of working (
somebody moved the cheese...).

But it is heart-warming to see some of the positive feedback, and for all of you involved in similar processes here's an example:
Personally I think they are the single best thing also. For the last
four months for the first time I have felt like I'm actually in control
of my work. I mean really, really in daily work and in the project time
line I can see where I am, and more importantly I can even affect where
I'm going. And also the feeling of the whole project is better for every
related person.
Good stuff!

This really tells you what Scrum/Agile is all about, being in control of your work and your time at work, and that just feels great! ;)

at 16:23 | 0 comments links to this post
RSS link

Bookmark and Share

Builds should never fail! (for long...)

After arriving to work and checking my e-mails I decided to check in on my previous team's results on the continuous integration system. Guess what? The build had been broken for 10 days!

Continuing to develop on top of a broken build is dangerous as typically an error in the build process hides several other problems. Only the problem that causes the build to fail is visible, but that may only be the tip of the iceberg. Do you know if the current error is the tip of the iceberg?

Also, nothing justifies having a broken build. Don't get me wrong, there are many excuses to have a build broken:
1- I'm sick, not at the office! (someone else needs to take the ball, that's why the build results are available to the WHOLE TEAM!!)
2- I'm just too damn lazy! (humm, should this person be in the team?)
3- I don'’t know how to fix the build! (someone else needs to help!)
4- It's ok to have that unit test fail because we are working on something that makes it fail for now! (If the build has been broken for more than a few hours this normally is a sign that you don't know what you are doing because you can no longer assess the consequences of your changes!)
5- That unit test is obsolete, it should be removed. (what are you waiting for?!?)
6- Continuous integration sucks and I don't care if the build is broken (there are bigger problems then the broken build in this team!)
7- I don't believe that having continuously working software helps the development process in any way (boy, are you in for a religious fight or what!)

Even though I could come up with these excuses in just under 5 minutes, it does not mean that any of them justify having a broken build!

The continuous integration system is our hourly/daily feedback loop on the quality of the code that is delivered. If that stops working we are back to waterfall, even if an "iteration-length" waterfall instead of a "project-length" waterfall.

What happens at the end of the iteration if the build is broken until then? A lot of testing! Testing only at the end is bad because it destroys the visibility to your progress, and the continuous integration system helps you maintain that visibility by providing some "validation" on the code that you are developing.

If you are asking yourself "how could I avoid broken builds?", take a look at
this post.

at 10:07 | 0 comments links to this post
RSS link

Bookmark and Share

Friday, March 24, 2006

More Microsoft on Agility

This is one of the 3 (only 3!) points that Kevin Johnson, head of the "Platforms & Services Division" at Microsoft sent in an internal memo.

You can read the whole article
here.

"3. Agility: Lay the foundation for accelerating our pace of innovation, including focusing on ways to improve clarity of decision making, drive greater accountability, and reduce layers in the organization so we can move faster. It also means utilizing existing expertise within the division to embrace services -- and rapid release cycles that services can enable -- to all aspects of our business. Our software + service approach and the expertise we have built in MSN can support innovation agility as we enable the Live era."

I especially like:
"embrace services -- and rapid release cycles that services can enable" -- sounds familiar.

It's not always worth it to listen to MS, but sometimes it is :)

Judging by the news below, they really need to be more "agile" to borrow's Kevin's own word:

60% of Windows Vista code to re-written

Forbes say Vista not "people ready"

Office delayed too

at 22:33 | 0 comments links to this post
RSS link

Bookmark and Share

Sunday, March 19, 2006

Agile Seminar: Team building in Agile projects, Part I

Last week there was the Agile Seminar here in Helsinki. During my talk I promised that I would make the content available so here we go.

During the talk and through a story that I told at the start I tried to illustrate the first Agile value. I slightly changed the it's phrasing from "Individuals and interactions over processes and tools" to "People over processes and tools".
But there was a reason for this change. I was trying, with that story, to demonstrate that "people" are at the heart of that value, and ultimately of all Agile values. The "people" value is present in all values in the Agile Manifesto:
  • Individuals and interactions over processes and tools: In this value the "people" component is quite obvious. This value tries to convey the message that ultimately if people don't adapt to the processes or tools we must seek some process or some tool that adapts to people. This was what I tried to illustrate with the story that I told in the beginning of the presentation.
  • Working software over comprehensive documentation: In this value the "people" aspect is not so obvious, but it is there. When a team starts forming, the best catalyst to have the team "Perform" (remember: Form->Norm->Storm->Perform)
    is to present to them a concrete challenge, and having the team deliver working software very early on helps the team focus on solving the challenges that "delivering working software" presents. One example I used in the talk is that our team (which had only 2 people at the start of the project) was able to define many details of the software development process very early on, because they had precisely one month to deliver working software (20 working days was the length of our Sprints) they were "forced" -- even if the "force" was implicit -- to make decisions. Also, because they eventually were able to deliver working software they also gained the self-confidence that allowed them to take even bolder steps in the following sprints.

    I'm sure someone will write something at some point on how "delivering working software" helps teams steam past the "norm" and "storm" phases, one strong reason for this is that the "shared goal", so important for teams, is there from the beginning.

  • Customer collaboration over contract negotiation: In this value the "people" aspect is again more obvious. First, Customers are people too ;) and collaboration (not antagonistic negotiation) is the best way to establish a productive and hopefully lasting relationship. If you and your company/team follow this value there's also the added advantage that you reduce the pressure on the development team by having customer buy in through collaboration. NOTE: this does not mean that you are allowed to slack, indeed, collaboration often leads to the exact opposite effect: people commit and therefore give more of themselves to the work than they would otherwise.
  • Responding to change over following a plan: I'm sure you are asking yourself "let's how he manages to put the "people" aspect on this value!". Well, here's my take on it, you judge if it makes sense in your context. In my company (as well as in many other companies) the changes to requirements come at the worse possible time: at the end when we finally know more about the product and can change the scope based on that knowledge. In Waterfall-type methodologies this is a moment of crisis for the team, the questions are often "why does the customer only see that requirement now?", "don't they get it that if they change the requirements we will be so much more late than we are already?". If you are lucky enough to work in an old style consulting company (I won't mention which ones I'm thinking about but I'm sure you know...) you even have a way to get out of this situation: "Dear customer, here's the requirements document you signed-off, to add that requirement it will cost you 1 000 000 more. We did our project plan based on the assumption that the requirements would not change and the resources would be fixed and there would be no surprises during the development process". Obviously this is not good for anyone. Specially not for the morale of the team that gave it's best to produce what they thought the customer wanted only to be faced with the cruel fact that requirements change.

    Now imagine the same situation in an Agile team: The customer comes in and says "Well, after all I need this new feature in the software and I cannot ship the product without it". The team replies: "OK, do you still want to ship the product on the same date? If you do we will have to remove some work from the backlog, if you don't we can happily add that feature and, if it is that important we can start working on that feature in 2 weeks' time (on average, taking into account the iteration length of 4 weeks).

    See the difference? Now imagine how both the customer and the team feel about the project in the first situation: probably stressed, frustrated, de-motivated, etc. Would that be a situation that you would like to be in?

The talk also mentioned other aspects that I'll leave for another post, but the main point that I tried to get across is that "people" is the most important aspect in a software project, and we must be prepared and active when dealing with that important aspect of any software project.

at 21:18 | 0 comments links to this post
RSS link

Bookmark and Share

Saturday, March 18, 2006

Agile Seminar in Helsinki

Last evening (March 17th) we had the third Agile Seminar arranged by
Lasse Koskela (correction: I should also mention that many other people were involved in the organization of the seminar, indeed they were, and a big thanks to them also for this great event!)

Three talks, one of them by yours truly (The role of team building in Agile projects), one by Sebastian Nykopp (Test Automation in Agile Development Today) and one by Joseph Pelrin (How Agile Works: Complexity and Agility).

I'd like to think that all three talks were good, but I will not comment on mine out of pure modesty ;).

Sebastian's talk about how they use JUnit, Wicket, Selenium and FitNess was a definitely good technical talk, and it left me with a burning want to use those tools and see how we could automate even more the development of our web-application.

Joseph's talk was a relaxed introduction to a field that he is bringing into the Agile community: Social Complexity. This talk opened a lot of avenues for improvements in my own approach of managing an Agile team or a team that wants to go Agile. Good stuff, and a lot of stuff to think about!

If you attended the seminar leave your comments in the Agile Finland wiki.

Looking forward for the next one!

PS: during the days that follow I'll try to put here a collection of articles that describe some of the key points of my presentation.

at 15:31 | 2 comments links to this post
RSS link

Bookmark and Share

 
(c) All rights reserved