I thought about this quite a bit, and here are my thoughts on it:

My view is that agile is not the only way, and that you should do what works for your company and situation, with the caveat that you create a culture that has these attributes:

• Continuous improvement, where every single person is on board with getting better as an individual, a team, and as a company. If people aren’t on board with that, then they are probably on the wrong bus.
• Look to eliminate waste. Waste is those things which add cost, but do not add appropriate value. This could be processes, unneeded documentation, hand-offs from one group to another when they should be working together, bugs that cause rework, waiting too long for feedback, company rules, or anything. Like at Toyota, it should be everyone’s job to find these things.
• Professionalism and trust. Teams should earn trust and be given it.

These are basic tenets of Lean thinking. Now, if you do these things, you will be agile, eventually, because it is impossible to have a culture of continuous improvement and do pure waterfall software development for long. In fact, I will go so far as to say that if you do waterfall development, you are probably robbing your company, because you are wasting your company’s money. I say probably because I do not know your situation, but I cannot see a case where pure waterfall development makes economic sense.

I’ve thought about this waaaay more than I should, but that’s just what I do, and I’ve come to the conclusion that the next time I am involved in helping a company move to agile development, I’m rarely going to use the word “agile”. It sets some people off, and also comes with preconceived notions, both good and bad. There are so many different flavors and ways of being agile that they come with assumptions. My plan is to incorporate lean concepts, and do those things that I listed above. Most people have heard of lean, and almost no one will fight it because it has won. Companies that are seriously doing continuous improvement, will get to agile, then go beyond that into lean. The problem with agile is that too many companies implement Scrum, and think they are agile, when they are really just doing the practices, but still aren’t making the real improvements that they could.

Abrams Falls

After a lot of wasted time trying, and then googling, then checking Stack Overflow and the JetBrains support site, I eventually gave up and contacted their support.

Five minutes later, I received the answer back from them. (In addition to spending too much time fighting Eclipse, that’s one more reason why I like them so much.)
Here’s the answer:

1. Look at the very bottom of the IDE, and see if their is a tab labeled “Changes”. If not, go to View > Tool Windows > Changes.
2. Look at the “Local” panel in the “Changes” window.
3. Under the “Unversioned files” node, there will be a list of all files and directories that are not under version control.
4. Right-click the “Unversioned Files” node, and select “Add to VCS” from the pop-up menu.
5. Right-click again, and select “Commit Changes”. You should be done.

I hope this helps someone, and remember- Version Control is your friend.
-Adrian Carr

Just for grins, here’s the email:

Good evening Mr. Carr,

Carey New York
Hiring Team
4901 27th Street
Long Island City, NY 11101
Tel:212-599-1122
www.Carey.com

So, I went into my wordpress control panel and added, activated, and setup the plugin in just a few minutes. Easy as pie.

I then went to a test page and added a Picasa photo album from a recent trip to Phoenix, Arizona.
I added this code:
[picasaview album='Arizona-August 2011']
This works great, and looks just like this:

Arizona-August 2011

(07/30/2011, 42 Photos)

Now, I’m going to come back to it, but notice that that there is a space in my album name. That’s perfectly fine to both Google and to PicasaView, up to a point.
What I really wanted was a bunch of thumbnails like I had seen on my friend’s blog. So, I added the “instantView” option to my PicasaView tag so it looked like this:

[picasaview album='Arizona-August 2011' instantView='yes']
This is when things went downhill fast.
In addition to messing up the entire CSS for my site, including messing up the header and background, it also generated this:

PicasaView Error

The issue here took me some time to find. The problem is that I used the title of the album as I entered it. This is the part that doesn’t work, because I have a space in the album name. The fix is to go to the url for the album that Picasa generated, and use that instead in the album name. In this image, you can see the album name and the url that works:

After I changed the PicasaViewer tag to look like this:
[picasaview album='ArizonaAugust2011' instantView='yes']
it generates thumbnails like this:

Arizona-August 2011

Previous

Viewing images 1-42 of 42

Next

Previous

Viewing images 1-42 of 42

Next

That’s all there is to it. I hope this helps someone else.
-Adrian

We still went ahead because we knew we could design something that would simply be better and we could innovate light years faster. Now, we are rarely compared to this giant, and when we are, it’s because someone is saying we’re doing a better job. Our execution is so different that it, in and of itself, is reason enough for people to turn to us.
http://www.fastcompany.com/9-nagging-questions-to-tune-out-when-launching-a-startup

Image just for fun….

I had a variable at the data access level, and it didn’t seem like it was doing what I wanted. I added a simple
Console.WriteLine("ISERROR=" + Convert.ToString(variableNameHere));
but this didn’t display anything in the Visual Studio output window like I expected.

I then used this instead, and it worked great. There was my variable, with an unexpected value.
System.Diagnostics.Debug.WriteLine("ISERROR=" + Convert.ToString(variableNameHere));

That’s it. I hope this helps someone else out there.

-Adrian

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Some of you recognize this as the last item principle in the list of principles behind the Agile Manifesto. There are whole books written on the subject.

If you want to really, really know all there is to know about retrospectives, you can go and buy the book. My intent here is to provide a simple overview. I hope you find it useful. (If you do, you can let me know.)

Just to make sure we’re all on the same page here, this post is about Scrum retrospectives. In the classic book, Agile Project Management with Scrum, Ken Schwaber states very simply “The purpose of the sprint retrospective is to inspect how the Scrum process worked during the last sprint and adjust it to improve the next sprint.” Wow, that’s pretty simple. Not a lot of guidance here. It’s not surprising to me that people get so confused about it. I see questions about retrospectives pop up on the Yahoo! ScrumDevelopment board quite often, and there are whole sessions about retrospectives at the large agile conferences, so don’t feel too bad if you’re here trying to figure this out.

Retrospectives aren’t something that we normally do in traditional software development. Sure, we might have a “post mortem” at the very end of a project, where we talk about all the things that went wrong, and vow to never do them again, and a project manager will take notes and maybe even send them out to everyone, but in reality, they get filed
away and forgotten, and we repeat the same mistakes over again on the next project.

Retrospectives don’t have to be difficult, but it is important to keep some things in mind. Scrum is simply a framework for developing software in an agile manner, and it provides some fairly easy rules and guidelines that are based on the principles behind the agile movement. Anytime we do something because Scrum says we should, it would help us to keep the corresponding Agile Manifesto principle in mind. The corresponding principle to the Scrum retrospective is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

So, given that statement, let’s take a closer look at the individual parts of the principle and then go ahead and get the easy one out of the way: The first part is “At regular intervals…”. Since Scrum sprints are normally from one to four weeks, our “regular interval” should be at the end of every sprint, after the sprint review. The retrospective should take place after the sprint review because you will normally have stakeholders, managers, and end users who show up to see what the team has accomplished. These stakeholders will say something about what you are showing them, and you should be paying attention. The feedback you receive should be discussed in your retrospective, whether it is good or bad. If you aren’t responding to feedback early and often, you’re missing one of the key benefits of agile. Retrospectives are a great place to capture real feedback from the people you are working for.

Since we’ve discussed when to have the retrospective, the next question is who should hold the retrospective? Well, according to the principle, the team should be the ones doing the reflecting. Sure, managers, stakeholders, etc can reflect on how the team can be more effective, but the team is required to do this. If someone outside the team has input on how to be more effective, I would encourage the team to listen. Many times, managers see the bigger picture, interact with several other teams, and have great ideas or advice. Since we know it is the team’s responsibility to reflect, a question that sometimes comes up is “Who is the team?”.
Unfortunately, the answer varies from team to team. Ideally, your team consists of the regular team members (developers, testers, designers, etc), but also includes the Scrum Master and Product Owner. Yes, the product owner, but only if they really are a member of the team. By “member of the team”, I mean if they sit with the team, help the team, eat lunch with the team sometimes. Do they have skin in the game and help the team to accomplish the goals, or do they blame the team when things don’t go exactly according to plan? Another way of putting this
is: “Are they a pig or a chicken”? I’ve seen it both ways, but I can promise that I’ve seen it work far better when the Product Owner is a part of the team.

OK, enough about the product owner. Back to “the team”. Who is NOT a part of the team? Managers, stakeholders that happen to be “chickens”, and anyone else that isn’t working together with the team on the project day to day. Retrospectives are a place where transparency is vital. If people are afraid to speak out or speak up, your retrospective won’t be as effective as it could be. This is the place where the team reflects not only on what went right, but what went wrong. Team dynamics, individual weaknesses, team members not doing their best; these are all fair game during a retrospective, and the team should feel free to discuss these without fear of management reprisal. If you don’t think that Ted is pulling his weight, you need to be able to say it (in a thoughtful, kind way) without worrying that a manager will take note. You also want to be able to discuss things that didn’t go well, or could have been done better, and you may not want stakeholders present that wouldn’t understand the day to day details that take place.

Great, we’ve got the when and the who. Now what does the team reflect on? The team should reflect on how to be more effective. Huh? More effective at what? The primary thing to reflect on is “How to satisfy the customer through early and continuous delivery of valuable software”. Come on, that’s your job. Do it well, and look for ways to do it better. Instead of just complaining about outsourcing, find ways to be so
efficient and valuable that you don’t worry about offshoring that much. Sure, you still won’t be completely immune to decisions to outsource you, but the better value you provide, the better chance you have of people up the corporate chain thinking that they don’t need to replace you, especially as more and more companies get bitten by sending their
business know-how out of the country, and find that quality typically suffers.

In addition to looking at how to be more efficient at delivering software, this is a great time for the team to take note of accomplishments, jobs well done, problems solved, and any other good things that happened during the last sprint. If a team member really shows improvement, let them know. If there are things that could make your job better or make the work more fun, bring it up. Sometimes, simple improvements can make a big difference in people’s attitudes or enjoyment of their work, and this is good for everyone. Happy programmers have happier end users, because they are willing to go the extra mile and pay attention to the little things that make big differences.

There are many different ways to reflect on how to be more effective. Different teams use different techniques. What works for one team may not work for another. For the team that I’m on, we’ve settled on this set of questions/statements that we discuss and take notes on during each retrospective:

1. What did we like about this sprint or do well? It’s a good idea to get the meeting started in a positive fashion. This is a nice time to pat ourselves on the back and take note accomplishments and work completed.
2. Room for improvement/lessons learned:
3. What caused us pains this sprint?
4. What would we do differently if we started this sprint all over again?
5. What are some things that we want to try or do next sprint?
6. Concerns (long term, short term, etc)
7. Concrete Action Items

The last one is very important. As Bob Schatz once said: “Retrospectives that don’t result in change are sterile and frustrating.” This is where the rubber meets the road, and a good way to implement the part of the principle that says “….then tunes and adjusts its behavior accordingly”. Take a look through the list of things that caused pain, or things that you would like to do differently if you could. Also look closely at the “Things we want to try or do next sprint”. This may be as simple as “show our tester how to do make css changes”, or try pair programming”. If the team really means it, this is their chance. Don’t put eleven different things on your concrete action items list. Pick the top two or three, maybe four if they aren’t real big. Chances are, some of the smaller easier ones will happen over time without you really thinking about them.

Be sure to post these action items, or somehow make sure they really do happen. ( Scrum Masters, pay attention here.) Whatever you do, make sure the team tunes and adjusts their behavior accordingly.

Here’s another retrospective idea that I came across one day. I’d like to give credit for it where it is due, but I can’t remember where I saw it. It’s very simple. Basically, just draw a big chart on a whiteboard that looks like this:

The important thing is that the team always tries to be more efficient and better. Don’t become complacent, or settle for “good enough”. As you may have heard before: “Good enough is the enemy of great”.