Technodrone

So you want to introduce agile methods to your team...

The following are some "lessons learned" when from someone who advocated agile/scrum to a group that was not ready for it.

"Change agents, in my experience, face negative consequences. Sometimes, most of the time at the beginning, it's painful.

This is the question you might have to ask yourself. Do you want to be a developer in scrum project or do you want be a scrum master managing the process?
I think with proper mentoring/training, you can become good scrum master. But is that what you want? if yes, you can go ahead, take the training.
if you want to be a developer, you may not need to be certified  as scrum master. You can just pick up from a book such as Mike Cohn's new book I am reading it now. It's good. ,

In my experience, I did waste my resources by trying to change the culture. It cost me lot. Instead, I should have focused on technical practices that are core to agile.
Then look for teams that are good at agile. I would have saved lot of energy, and time.

Try baby steps first yourself in the company, and next with the team, starting with technical practices like writing unit tests, SOLID principles, patterns, refactoring, continuous integration, pairing, and peer code reviews. These have inherent pull that can bring collaboration from a team.  Once you see team adaption in core practices, then you can introduce scrum concepts like user stories/task board etc.  This idea of Leading by example seems to be working for most of the agile folks. You can pitch core practices to the manager, and the team, and start showing them how you are doing.  You can put a road map for agile adaption and you can pitch to your manager. I would include need for scrum master training as part of the road map. "

I thought about his advice for a couple of weeks and read about the pitfalls of technical debt and the team not having prior awareness of agile methods. The more I read and think about it the more I think he was right.  What do you think?

 

 

Over all I think the best indication that someone will be a good agile
team member is:

• Demonstrates  a long-term desire to move from journeyman to craftsman. (study groups, software related blogging, seeks out training)
• Demonstrates that they will share knowledge insights with others.(mentoring,being mentored not just for newbies all team members)
• Open to debate and new ideas. (question whenever a quick solution does not follow solid principles, or adds unnecessary technical debt)
• Willingness to work closely with non-developers (users, business owners, managers)
• Patience with the process (complex problems are not easily solved it takes time and investigation).
• Can make the argument for refactoring code.

I am learning all I can about the solid principles. Currently I am
reading about the Single Responsibility Principle (A class should have
only one reason to change).  If a class has more than one
responsibility, the responsibilities become coupled. This kind of
coupling leads to fragile designs that beak in unexpected ways when
changed according to Bob Martin. An example I have seen lately is the
case of the widget.com public site and the widget.com customer site
having the exact same code base except for the part code that deals
specifically with customer service. The team debated whether the
customer service code should be pulled out of the customer service
site and placed into the public site so that two almost exact code
repositories needing to be maintained. There was disagreement among
the team. Some felt this would be efficient others felt that this was
breaking SRP. Others thought combining the code together violates the
DRY principle. What do you think?

Someone that I respect in software development recommended this book to me. Pragramatic Thinking & Learning by Andy Hunt. I got it in the mail last evening and have already read half of it. He talks about the Dreyfus Model Stages. These stages apply to any profession and were first implemented in the early 1980s with nurses.  He says skills in a profession are distributed in 5 levels from lowest to highest: Novice, Advanced Beginner, Competent, Proficient, and Expert. Most people don't get past Advanced Beginner. After reading this chapter I now see why implementation of agile will likely fail if any of the team members are at the Novice or Advanced Beginner stage.  I would recommend to any developer interested in maximizing their skills and mental sharpness read this book.  It is an enjoyable book to read as well.

I am currently working with a company that has a 40 million dollar contract that will be lost if the code is buggy and incomplete. We have just started writing unit tests. TDD is foreign to most of the team members. Most of the code is contained in the code behind of aspx pages. I am using selenium to write the unit test. Team members are getting frustrated because of the tight deadline; they feel they don't have the time to unit test. While this is going on the company has decided the team should use the agile methodology yet they have no training/mentoring so it is causing them more frustration and anxiety. We have a consultant telling them they must learn TDD and agile while at the same time they have an extremely tight deadline. The deadline will not budge. I want the team to be able to produce quality code within the timeline. At the point it is too late to eliminate the spaghetti code and lack of domain objects. I still want as much test coverage as possible. I am the go between the developers, an agile consultant and the management. Any ideas?

I enjoyed this article this morning. I observe and play the chicken game constantly. I always called it the "Is it done yet game".  As the recession worsens we are afraid to say "that enhancement to the web site will say 2 weeks to code and a two weeks to test/fix".  Instead we are told do it all in 40 hours knowing there is no stinkin way that is gonna happen.  If you tell the project manager is going to take longer because of testing and integration you are told. "That is not part of the time estimate.'   If your team uses agile sometimes this game is played on a daily basis at the morning stand up meeting.  One of the most popular strategies is to say we are 95% done.  I will admit I have sometimes fibbed and said I was making progress when instead I was behind schedule.  It buys a little time but only works a time or two. In these cases everyone is playing chicken with everyone else just because the team is unwilling or afraid to be honest about time estimates. I think this kind of behavior worsens as we try to do more with less.  In the long run the project still takes as long as it takes. If people are truly striving to do a good job. The  developer may have originally estimated 40 hours the project manager said no do it in 12 hours. In the long run it still takes 40 hours or possibly more due to lack of communication. Why can't we just communicate more honestly . That is just not in vogue in today's climate of fear of retribution.  We just keep playing this time wasting non-productive game.  Here is a link to the article on Stickyminds.com.

Managing the Chicken Game

Disclaimer: References to the Chicken Game do not reflect upon current or past employers. It is just a half thought out editorial based on lack of sleep. No animals were harmed and I only consumed 2 carbon credits creating this post. I put my redbull can in the recycle bin by the way.

 

I came into the office on January 2, 2009 and found out one of my applications was not finding files that have names based on the day of year and month of year.  Here is the problem, my code was looking for a file called  'thepreciousfile200911.txt" instead of "thepreciousfile200901001.  This worked 12/28/2008 but when the day of year changed to a single digit on the new year I could no longer check for file existence because the string I was using for the file name was now wrong. When I retrieved the day of year from the current month I blanked out and did not think it would return as 1 and if it did that was the correct file name anyway. Well it was wrong.  Here is what I did to fix it and it was extremely easy.

 

In this example the 3 is the number of characters I want the resulting string to have and the '0' is the character you want to use for padding if the day of year does not equal 3 characters. 

string dayofyear = Convert.ToString(DateTime.Now.DayOfYear).PadLeft(3, 0);

I have been hacking at this for two days. I could use a little help here. I am rewriting a console application that uses a com object named transaut.tlb.  This object exposes cognos transformer functionality. I used tlbimp.exe and imported it.  When I make reference to this dll and use it in my code, the code compiles but I get the runtime error "CLSID{blah ,blah...} failed due to the following error: 80040154".  I tried making a reference to the orginal com object transaut.tlb I tried registering the imported dll but got the error  "cognostransformer.dll was loaded but the DLL Register Server entry point was not found. This object worked with .net version 1. Any help would be appreciated.   Thanks