Lessons learned this Agile project (Week11) Final Blog

I've got a assignment of building a small project with Agile at Agile Development Project Subjects that I taken this semester (4 developers – 10 weeks planned).
This project was built on Java. And It gain a lot of things by doing this project especially in Agile Knowledge

XP-style Planning - Small iteration helps to track project progress and create better estimates.

Customer Feedback - Manage a project without client representative is a hell on the earth. You are working like in a vacuum. No response, no feedback and no attention.


Test-Driven Development - We wrote unit tests for all business objects before code, and it worked great. However, we did not have tests for controllers. Controllers are very close to GUI and they changed often (during first month). Maybe we should write unit tests for controllers as well, maybe not. This is unclear. But we should consider such a possibility in future. Anyway, TDD is good and we will use it as a mandatory practice.

Acceptance Tests - About 50 tests were created. We modified tests quite often and spent near 0.5 hour per day to keep them working.

Refactoring - It helps reduce code duplication and keeps system architecture clear. We had doing refactoring constantly, and sometimes we spent on major refactoring whole day.

Walking Skeleton - This is a first, fast and small release, which contains single system feature ‘in depth’. For example, show projects list, add project into the database, check user permissions on project. Walking Skeleton for the system took near 2 weeks. We manage to investigate many architectural decisions and choose the best. Small and fast release is a great thing.

Pair Programming - We create most important system modules in pair. The code quality and overall system architecture appears significantly better when pair programming used. Constant code review, communication and experience sharing are really great things. It is not easy to program 7 or more hours in a row, and you feel exhausted in the end of the day. But work satisfaction is great. We will use pair programming for teaching, experience sharing and critical modules implementation in future.

Code Metrics - LOCs dynamic, Unit Tests # dynamic, Acceptance Tests dynamic. Code metrics help to track project progress and predict team velocity and project size.


System Prototypes - Helps to resolve many issues on the early stage. In general, the prototype should be created if project budget allows to. But I do not recommend create comprehensive prototype, since it just waste time. Prototype should contain major system modules and maybe some secondary.

Honesty - Just be honest with your teammates. They will trust you, and trust is one of the major factors for jelled teams.

Documentation in Source Code - Almost all system architecture related documentation was in source code. The week point is that source code less browsable (it is slightly harder to find a method while scrolling, for example).

Pair Programming - Dual Core 2 is faster (Week10)

I have found some benefits in doing Pair Programming this week.



1. Dual Core Processor is faster and better
This benefit is more for the project than the individuals. If there is a particularly complex or difficult problem that needs solving, it’s often good to have two people working together to solve it. Rather than just discussing the problem, where ambiguities can creep in, having two people write the actual code means any misunderstandings can be cleared up as they write. The code is the final. Opinions, prejudices and communication problems just don’t exist within code; it’s the final contract for what the program will do. Pair programming is also continuous and instantaneous, where sudden ideas that flash to mind can be discussed and implemented on the spot.

Some people may argue that it’s a waste of programming resources having two people do one person’s job, however I believe the benefit gained when working on complex or difficult problems far out ways the cost. You really can’t put a dollar figure on having a better solution to a problem and while the time taken to write code won’t be half as much, the quality will often be high enough to warrant this higher expense. The cost does mean that I wouldn’t recommend pair programming all day long as simple problems can often be solved by one person more easily.


2. I'm not alone anymore
At last I find someone who feels the same as I do about working alone.

I've always found I'm most productive when not forced to work with others, but rather being able to do my own thing.

In a corporate environment you can get some of that by shutting yourself off putting on headphones and some music.

At first people indeed look weird at this person who doesn't socialize, but I've found that usually it's accepted after a while.

Pair programming for me would be constant hell. I've nothing against sitting down with someone to solve a problem together if you or the other person is stuck but to do it all the time, no I could never do that. Managers who cannot work around such things, instead trying to force everyone into the same role model don't I think deserve the title.

The main job of a manager is to leverage his people to get them as productive as possible. If that means letting some people work alone in a shop that otherwise practices pair programming than that's what it takes.

Maybe start R&D groups for those people, where they can let their minds wander a bit trying new technologies that can benefit the company in the future without breaking the corporate "standard" of using pair programming to increase the quality of production code.

Or maybe recognize that pair programming is not the Holy Grail and see that those "loners" can produce as good a volume of code as a pair of herd animals working together.

And other Benefit that I have found in Pair Programming

• Everyone understands the code and the cost of programmers leaving the team will not be too high.

• The code will have higher quality so the cost of maintaining the code is lesser during the life cycle of program.
• Sharing specific knowledge
• In with good habits, out with bad habits

Adoption XP Programming (Week 9) - After Holiday

I read a book about eXtreme Programming as my advance study in Agile Development Project Subject that I am taking right now.

Extreme was just what I looked for. Soon, after I got Kent Beck's - Extreme Programming Explained, the first edition. I read it very fast and that was a decisive moment in my programming life. I thought everything in there was good but not applicable. I said you can never have 100% unit tested code. In time I saw I was wrong. I said PP costs double. I was wrong. Every practice was for me a new impossible and as the time got by, I found it less and less impossible but as the book said very beneficial.

I see lately more and more people hearing about XP and then trying to resist to it after seeing that it is really extreme. My advices, a few years later, in a much better context as there are much more people that can help, much more tools, more proven cases and more openness.

I want to adopt XP. What is the plan?

When I first started with agile methodologies, as a developer, I had to think about
what to do to be able to make the team, the company, the business, become agile.

Sell XP to yourself

In order to do that I had to sell XP to myself in the first step. I thought that if I'm both the vendor and the client, I must think what I, as a developer, would like to achieve by moving to another way of working.

Sell XP to your management
in convincing managers you have to remember that they are managers and they are
running a business.

Selling to the customer

The customer must be informed from the beginning about what you're planning to do and the iterative circle of life (see Ron Jeffries's XP Installed). Convince them about the benefits, using the same methods as for managers. Less time, less money, better quality, running, tested features after just a couple of months, at maximum.

Conclusion - I'm XP infected now and don't regret a thing

I tried to share a little about my experiences in becoming agile. We
are very small (as a company), and that's a huge advantage, but I have seen good results even in monster companies. Just determination is needed. And XP will win, as it did with me

XP Adoption (Week 7)

I'm always happy to talk about how to make things better and I'm mostly of the opinion that XP is the best way to make development of software more satisfying for all those involved. With this belief, my focus has become,
"Where is the value it what is being done?
"What value is there is BDUF? What value is there in TDD? What value is there in what I am proposing to add/remove from our processes? Everything has boiled down to the simple question of what value does X provide. I don't think this is an XP specific, or even an agile specific, practice, but I find myself constantly asking this question internally and very often now those around me are probably getting used to hearing this query which leads me to how I are currently adopting XP.
Initially, I was want to identify what I thought should be the development teams focus to be more agile.
The first step was to mandate that all development would be TDD. After that, I started pair programmer, but I started "soft" (but spontaneously went "hard" just last week). The interesting bit is where I just started grabbing at practices without much thought.
What practices would deliver the most value for the team to adopt next. With this in mind, it was obvious to us that planning game was not the answer (though it might have looked like it previously).
So, my overall generalizing conclusion from this small experience is that the best way to approach introducing XP to a team of developers depends a bit on history. If there is a legacy code base, like what I currently have, then sneak up on it by constantly examining what could be done and prioritize these by what value you believe they will give to the process. I started with TDD. Next added pair programming. Failed miserably with planning game (but only because I forgot to look for value) and now are focusing on acceptance tests first before working on a story. Implied in this is that I are taking the time to reflect, which I have decided to explicitly do (even without a planning game, ironic, eh? 8)). BTW, to me, reflection is where you look at your values, i.e. communication, simplicity, etc.
The corollary to this generalization is that if you are on a greenfield project, grab as many practices as you can find and go for your life!

Agile QA Bugs (Week 6)

Some thought that my contention that many believe that all bugs should be fixed was simply a "straw man" argument. In other words, I couldn't possibly believe that anyone really thinks that. I guess that's the problem with generalizations, so I'll be more specific.

For Example, one QA manager routinely prevented software from shipping because the CTO had declared a "Zero-defect policy". This meant that in theory, I couldn't ship the new version until the defect tracking system had no open items.

As you might expect, each team spent the next few days to transfer bugs logged against their areas to other potentially responsible parties.( Without telling them)

This also kicked off lots of heated arguments with the QA team as to what exactly constituted a defect. I can't prove it, but I think the entire QA team got free lunches for a week. This seemed to correlate with a new level of flexibility re: "bug” versus "enhancement."

Moral of that story: zero-defect policies usually just force bugs underground. Instead of having no known bugs, you wind up with no DOCUMENTED bugs that everyone knows about.

By contrast, another company I worked for was obsessed with features. There was no time to fix bugs. I had to get out the latest features NOW! The development team was very talented, and my some miracle I was able to keep delivering. The system quality did start to show signs of fraying, and the stability was somewhat less than rock-solid.

I've seen these patterns over and over again, both in companies I've worked in, and those that my friends and colleagues have. It's a form of corporate unconsciousness, where things get done, but no one really is sure how or why.

This isn't just a management problem though; I've seen unconscious behavior at the developer level also. Unplanned "tweaks" and "cleanups" of perfectly functioning code that caused major problems in production. An extra feature added in that no one asked for, which destabilizes the system or confuses users.

Anyway, that's enough on that for awhile, but I wanted to get you thinking about ways I can develop software more consciously. It's not just about fixing bugs or not fixing bugs.

It's about approaching development with the same care I approach a by-the-pound salad bar. Load up on the high-value, tasty items and leave the heavy, bad-tasting things where they lie.

Agile Defect (Week 5)

I've been thinking about Agile issues with software development, which is how Agile actually manages defects discovered after release.

I was thinking some scenario related with this topic.

-- **** The Story Begin ****--

Lukman is a customer in one company. He sends an email with an issue he's been having with the software. At this point, it doesn't matter whether it's a software bug, a documentation problem, or a user error, I just want to understand what Lukman is trying to do, and why he is frustrated.

Lukman may say "I want to reschedule all appointments to next month, but the software makes me do one at a time." This is clearly an enhancement to the product in software terms, but to Lukman, it may as well be a defect, since he can't do what he wants, and it hurts.

In another scenario, Lukman might say "I tried to reschedule an appointment to next year, but I get a message that says External Error -584754." OK, I seem to have a software defect now. If the software can't handle rescheduling items more than 456 days away, maybe it's just a bad error message, or if the spec says it should be able to anything, maybe it's a true failure. Either way, Lukman is in pain.

--**** The End of Story *****--

My approach of this problem is to treat all of these situations similarly, regardless of the label you might apply, "bug", "enhancement", "spec problem", "cosmetic issue", "feature request".

In a typical agile process, there is a "backlog" of features, enhancements, and defects. As part of the planning process, the Customer/Product Owner/Decider will prioritize the items on the backlog for the next release.

There is one challenging aspect to this approach. As a developer, project manager, and a leader, I am driven to produce the highest quality software possible. It bothers me to see unfixed bugs in any system I am involved with. But there is a fine line between conscientious quality management, and obsessive, wasteful fixing of every defect that arrives.

In this case, it was still worth the effort to understand where the problem was rooted; even though ultimately the code was not within our control (I did ultimately find a tolerable workaround). So even though I'm advocating prioritization of defects, some due diligence of the root cause is important so that you can communicate the impact to your customer, as well as gain a better understanding of what the fix would require.

How do you manage your defects?

Test by your own (week 4)

James Bach http://www.satisfice.com/blog/archives/54 write about whether programmers should test their work extensively before delivering it to testers.

His conclusion is:
Many testers would advise the programmer to test the product himself, first. I have a different answer. My answer is: send me the product the moment it exists. I want avoid creating barriers between testing and programming. I worry that anything that may cause the programmers to avoid working with me is toxic to rapid, excellent testing.

He goes on to indicate that he has no problem with programmer testing, and in fact considers it to be a good thing. But that if it contributes to a wall between developer and tester, then he'd rather just have the code now, please.

A common theme has emerged recently in the Agile world, where I've seen a lot of questionable enthusiasm for doing away with dedicated testers, and having the developers write all of the tests.

I believe in unit tests, especially the automated kind, but acceptance testing is a trickier proposition. Having worked for over 15 years with both developers and testers, I can say unequivocally that a good tester can test circles around a good developer.

So why would I want to throw away the talents and viewpoint of a great tester under the guise of automation or agility?

Well, in an Agile process, fast feedback is important, and the more hoops that need to be jumped through to release software, the harder it is to get that feedback. A dedicated testing team is just another obstacle to overcome on the way to a release, right?

Or is it?

What if dedicated testers weren't a hoop to jump through, but rather a valuable feedback source? What if you could not only find and eliminate more defects, but also find under-specified areas of the software, and be able to anticipate customer needs sooner?

A good QA/testing team can help you do these things.

Does this mean that developers should stop creating unit tests? Of course not. The better the input, the cleaner the output will be. Unit testing (along with Test-driven Development) is an internal quality practice that makes code easier to maintain.

But as for the final acceptance testing and other areas that are difficult to automate, I for one welcome the opportunity to work with talented testers who can help make my software better.