“If” syntactic sugar – slightly different from regular “If”

A short development post for a change…

Who doesn’t use syntactic sugars in C# these days? I think everyone does, even if they don’t know it. As the language evolves, more and more syntactic sugars are added to make our code shorter and look better (although some can argue on that).

Syntactic sugars are usually expected to act exactly the same as the original syntax, but with “if” statements it’s not always the case…

Lets say we have two classes that are derived from the same base class:

Now, lets write a method that returns an instance of one of the derived classes according to a given flag:

So far so good – no compilation errors.

Now, lets see what happens if we change the “if” statement to it’s syntactic sugar form using the conditional (?:) operator:

We get an error!
The compiler is trying to convert between the two types of the derived classes.

Why is that?
The reason is that a regular “if” is a statement, composed of statements, hence it does not return a value, whereas the sugared “if” is an expression, composed of expressions, hence it does return a value. In order to evaluate the sugared “if” expression, the compiler must have a way to know what the returned value’s type is. The way it does it is by implicitly converting between the two types that the inner expressions evaluate to – in our case:

A simple fix can make it work:

There is an implicit conversion between the "Base” type and the “DerivedB” type, so now the compiler is able to determine the sugared “if” return type to be “Base”.

This is just a sample demonstrating this issue. I’ve actually encountered this when using a similar sugared expression in a lambda expression, where I find this to be pretty useful in keeping my code clear.

Client Satisfaction

I’ve recently unintentionally encountered David Maister’s “First Law of Service” in relation to performance problems. Then I learned that it was originally addressed in his article: The Psychology of Waiting Lines. I found it to be an interesting approach and somehow it felt very natural to project it on software project management as well, specifically – the benefits of Agile development upon classic Waterfall development.

David Maister’s “First Law of Service”:

Satisfaction = Perception – Expectation

And I quote: “If you expect a certain level of service, and perceive the service reviewed to be higher, you are a satisfied client. If you perceive the same level as before, but expected higher, you are disappointed and, consequently, a dissatisfied client.”

Lets think about a classic Waterfall project. The requirements are predefined clearly in a contract between the client and the project manager (or other representative), together with a price and delivery date. This actually reflects the client’s expectations at that point (actually, there usually is a hidden expectation that he’ll be allowed to make requirements changes for free…). During the project development, the client gets nothing, so his expectations don’t change, nor we do nothing to increase his perception. In most cases, the project fails or is “challenged” (takes more time, more budget, or doesn’t meet all requirements), the client perceives less than expected, hence – dissatisfied. In other cases, the project succeeds in meeting the client’s original requirements on time and budget, so the client perceives what he expected (and not a bit more). Only if you achieve this success including the client’s requirements changes on the way, then he’ll really be satisfied and the chances for that to happen are pretty low.

Now lets think about an Agile project. The initial set of requirements are predefined clearly in a “pay as you go” method were the client still gets a rough estimation of price and delivery date. This time, the client gets to experience working software on exact predefined time intervals, what can easily increase his perception and overcome his expectations. Moreover, he’s welcome to make requirement changes and the project manager will embrace the changes and modify the plan accordingly. This may increase his expectations along the project as well. In the end of the project, even if not all original requirements were met and the estimations were shorter than reality, chances are that the client was already satisfied along the way and will still be satisfied at the end.

Back to the article I’ve mentioned, there are two propositions by David Maister concerning the psychology of waiting that I believe Agile principles address well:

1. Uncertain waits are longer than known, finite waits – The client in a Waterfall project waits a long uncertain wait till the final delivery date, which changes constantly due to overflows on the project buffer. By contrast, the client in an Agile project is handed a working software on-time on predefined time intervals. He knows exactly when to expect it, making it a finite wait for him.
   
2. The more valuable the service, the longer the customer will wait – Waterfall projects deliver no value to the client until the final stage of the project, so the client won’t accept waiting a day longer than the predefined delivery date. By contrast, Agile projects are focused on client (business) value and deliver value constantly along the project, making it more acceptable for the client to wait for the final release.

So go satisfy your clients!

Managing a Small Project Effectively

A while ago I was appointed as the project manager of the final development phase of the XP2Win7 project done at Sela for MS Redmond and presented at the PDC 2009 expedition (Note: the latest build of the project has not yet been published). The application was almost complete at that time but there were still quite a few features to be developed and several bugs to be fixed.

The whole XP2Win7 application development was extensive and involved several developers for several months, but this final phase alone was a pretty small project itself. We had just one month to complete it (fixed schedule) with only two full-time dedicated developers working on it (Bnaya Eshet and I) and some help from other developers, mainly those who developed the application before on partial time. In addition, the features/bugs from our client were given priorities from 1 to 4, and then assembled to a fully prioritized list in collaboration with the team (mainly by the developers who developed the application before).

When managing such a project a few questions arise:

1. Is any development process or methodology cost-effective for the project?
2. How can I still manage and track the project progress effectively?
3. What Agile practices might be useful here?

Since it was a relatively short project on an already developed application, the tasks were clear and not likely to change drastically, so no predefined development iterations and incremental releases were required. The team was extremely small so task assignment and synchronization between team members could be done ad-hoc with no special meetings or tools. I had some QA resources but most of the testing was done by the developers immediately after each development task was done.

The only thing left was tracking. In order to do that effectively I’ve inserted all the prioritized project tasks into an Excel spreadsheet and created a burn-up velocity chart for the project that I updated daily. This allowed me, my managers and our client to have a complete overview of the project progress and get a prediction of the amount of tasks that will probably be done by the project’s deadline at any time. It was effective and required very little effort by me to keep it updated.

As you can see in the chart, our velocity was better than expected, so a week before the deadline we’ve decided in collaboration with our client to freeze development and concentrate our efforts on QA and finalization for the last few days.

In conclusion, it sometimes seems not worth implementing a whole development process or methodology upon small projects, but with little effort you can still implement some simple and effective practices for managing tasks and tracking progress.

PDC09 – The End

The last day of PDC is over. Unfortunately, I felt really bad today so I was unable to attend any sessions.

In conclusion, the PDC was not so innovative yet it was interesting, intensive and fun. I really liked the 2nd day keynote and the different sessions about concurrency and parallel programming. From the Agile aspect though, there wasn’t any insightful session, but it was fascinating to listen how different people in the community cope with the challenges of Agile implementation in their projects (detailed here). Today I missed a session regarding Scrum and VSTS 2010. It should be interesting to see how the new VSTS is more suited for Agile software development – I’m hoping to delve into this issue soon.

Regardless of the sessions, the “peripheral” stuff were great! First of all, I got a new laptop (well, a multi-touch tablet actually, but who cares, it’s free :-) ). The expo was nice and I got some more free stuff at it. In addition, the geek fest was fun – a huge playground of toys for boys – pool tables, air hockey, video games, paintball and more. And of course, all the free snacks and drinks between the sessions added a good flavor to the day.

As a great finale for the PDC days, just a few hours ago, a bunch of us from Sela got a VIP box at the LA Lakers vs. Chicago Bulls game tonight – it was really awesome!

For those of you in Israel that missed the PDC and want to hear more about the topics presented there, you’re welcome to attend Sela’s upcoming SDP.

Enjoy!

PDC09 – Day 2

Today’s keynote session was really exciting. It started with Windows 7 development process and cool new features, continued with the announcement of Silverlight 4, and concluding with Office 2010 and SharePoint 2010. Sasha (1, 2, 3) and Eran (1, 2, 3) elaborated on these pretty much in their blogs and you can hear more at the upcoming SDP conference. In addition, a Windows 7 PDC Laptop was given for free to every PDC attendee!!!

After the keynote I attended a panel discussion on the future of programming. The discussion covered a few issues including parallel programming, transactions, type safety, modeling and more. Personally I didn’t find anything so innovative in this discussion.

Future of Garbage Collection

Garbage collection consists of mechanisms that apply certain policies, but there should be different policies for different conditions, such as workstation applications versus server applications. .NET GC has evolved from CLR V1 to CLR V3, introducing Workstation and Server GC. In CLR V4, a new Background GC is implemented for workstation applications, which allows ephemeral GCs for Gen 0 and Gen 1 while engaging concurrent GCs for Gen 2. This looks very good so far and may be brought to Server GC as well.

While the speed of the GC allocator is good and the percentage of time in GC is low, the main problem with GC today is the max GC pause time for large heaps. In addition, the GC working set is too large – large object heap and background GC aren’t compacting. As a solution, Microsoft’s considering LOH compaction and partial compaction for Background GC (for instance, compacting small badly fragmented areas during Gen 0 or Gen 1 GCs). Some interesting different approaches for GC process improvement are being explored – hardware assistance, OS assistance, loosely maintaining reference counts on Gen 2 objects and more.

For more extensive information from this session, I recommend you read Sasha’s post on it.

Spice Up Your Applications with Windows Workflow Foundation 4

WF was a really neat technology from day one, yet there were a lot of problems with it’s implementation in it’s first versions. I had the chance of managing an innovative project built upon the early version of WF (same development team described in my first posts), one of the first projects in Israel that were using this technology. During our work on this project, we had the privilege of discussing with Matt Winkler on WF issues we were trying to resolve, some of what he said might be resolved in WF 4.

In this session, Matt presented the new version of Windows Workflow Foundation which seams to be much more matured than the previous versions. For example, a new Async Code Activity is presented, allowing true parallelizing inside the workflow. This subject will be addressed thoroughly at the upcoming SDP conference.

PDC09 – Agile Talks

In the afternoon of the first day of PDC, I attended two interesting sessions regarding Agile. I was glad to see that in both sessions the halls were full. There were even several people standing around the chairs. This just stressed the fact that Agile concepts are penetrating into more & more teams and organizations worldwide.

Agile – Tales of Triumph, Tribulation, Tools, and Teams

This session was actually an open discussion about Agile, mainly motivated by stories and queries presented by the audience. It was a great opportunity to learn from the experience of dozens of other agilists in their Agile projects.

Here are some highlights from this discussion I found worth mentioning (but not necessarily agreed upon):

• Organizational boundaries must be crossed.
• Agile can be implemented top-down (where highest management is instructing the development teams to work Agile) or bottom-up (where Agile implementation begins in specific teams where the developers drive the process), but it can cause negative outcomes such as developers having no real commitment to the process and saying “we’re doing it because we’re told to”. The formula to success is in the combination of the two, where the developers are motivated & committed to the process and drive it forward with the backup and support of the management at all levels, or in short: Top support – Buttom will.
• Practicing Scrum of Scrums in large projects, breaking stuff down, assisted Scrum to scale and led to success.
• Scrum fails when concentrating only on the developers and not on the context as well.
• A quote by Ken Schwaber noted by the session speaker – “Teach developers how to create software you can determine if you want it or not in 30 days instead of 2 years”.
• A tip for “selling” Agile to the clients – delivering them an “alpha” version (which is actually the software increment of one of the first iterations) in a release quality (achieved by implementing XP concepts of course).
• Can’t succeed with Agile without committing to organizational changes (one of the toughest challenges to accept).
• A problem was raised – exploding backlog. Release planning solves this issue. The product owner must control the backlog. One way of doing it is limiting the sprint reviews to the team and the product owner alone. Other people such as sales department guys don’t need to attend every review.
• Clients still have budget, so you must give them an estimation for the project even though you know they don’t really know what they want yet – another tough one since even though you’re clients are willing or even want you to work Agile, they’re not in an Agile state of mind themselves.

Finally, the speakers repeated a few times the importance of “going by the book” when it comes to Agile (at least for the first 90 days). I tend to disagree to this perception (as you can understand from my previous posts), yet I do understand the cause for this perception, coming from Agile assimilation failures due to Agile methodologies poorly tailored to the projects.

Tooling on Agile Teams

This session was also partially an open discussion about Agile, yet focused on the different tools people use to assist their Agile process.

Some of the tools presented were:

• Index Cards
• X-Planner
• Rally/Taskboard
• Skype
• Microsoft Communicator
• Jing
• VSTS
• Word
• Excel
• Wiki

As you can see, even general communication tools were stated as Agile tools since communication is one of Agile’s baselines. Moreover, during the session Agile teams were defined to be based on high bandwidth communication and tight feedback.

An interesting that was presented by someone from the audience was that project success (in general) increased by 10% from 1992 to 2002, particularly thanks increased Agile implementation.

Some more highlights from this session:

• Agile can reduce failure “size” – A project would be canceled much earlier when using Agile than when using Waterfall.
• Drop the builds to a Live Mesh folder for an instant feedback from tester, clients, etc.
• Involving the project manager and even a representative of the client in Planning Poker – balancing the estimation.
• Backlog should be not more than 6-8 months when practicing re-estimation at the end of each sprint. Separate the backlog from the story sandbox.

In conclusion, Agile is becoming much more common and well practiced worldwide from small local projects to large distributed projects, and in spite of the implementation difficulties, I feel there’s almost a consensus that it’s the right way to manage software development projects.

PDC09 – Day 1

This is my first time at a conference as big as the PDC. It’s like Israel’s Tech-Ed scaled up and out!

Opening the conference was keynote speaker Ray Ozzie, Microsoft’s chief software architect, introducing a wide range of new Microsoft technologies in cooperation with colleagues from Microsoft and it’s partners. He especially emphasized cloud computing realized by Windows Azure, presenting the “infrastructure/platform as a service” concept.

After the keynote I attended the Future Directions for C# and Visual Basic session. Luca Bolognese first described the evolution of these languages from the 3 important directives – declarative, concurrent & dynamic – and demonstrated it elegantly using LINQ. Then he discussed the thoughts about future directions for these languages, including the use of the compiler’s structure & functionality and “asynchronizing” synchronous code easily and intuitively, which I found very impressive and useful for server-side high-performance data-processing applications in particular (if I only had it a few years ago…).

The next session I attended was Concurrency Fuzzing & Data Races, where two very powerful tools were presented:

1. Cuzz – for finding concurrency bugs in multi-threaded applications. By injecting Cuzz dll into your application’s executable you can dramatically increase the probability of your bug reoccurring without any performance penalties, gaining much shorter stress tests to find concurrency bugs in same probability as before (a great advantage when using continuous integration for example).
2. FeatherLite – a data-race detection tool, detecting more than 70% of data races by sampling less than 2% of data accesses.

There’s still much more to learn about the above issues, and much more to come on the next couple of PDC days…

PDC 2009 – Here I Come!

I’m in LA for the upcoming Microsoft PDC 2009 with quite a few guys from Sela Group, hoping to get a good glance at the new Microsoft technologies and tools. As a warm-up, a bunch of us went to the thrilling Six Flags Magic Mountain theme park for an extreme day of infinite adrenalin! And if you’re an adrenaline freak like me, you already know that the PDC is just an excuse for coming to LA and visiting the Magic Mountain park :-). It was better than I expected, especially thanks to the short lines in this off-season period and the cool new rides from the past few years.

I’m planning to attend a couple of sessions (at least) regarding Agile development and probably some sessions on .Net 4.0 and Windows 7, especially server-side development. I suppose tomorrow I’ll know better which sessions I’ll be attending. Anyhow, I’ll be updating my blog with interesting stuff I’ll learn from the PDC sessions during the conference, so stay tuned…

Agile Framework Development – Part III

It was new to all of us – for me as a Scrum Master and the team as Agile developers. But pretty quickly the whole team was starting to feel a real progress in the project. By the 4^th sprint everything was going smoothly, releases were delivered exactly on time and our users were much more pleased. So when I met again with my managers they were surprised with the success of this new process and let me go on with it.

I must point out that our whole methodology at all aspects has changed by then and later on from what was previously defined. I'll explain why and how by indicating the most valuable Agile practices we've implemented in our project (of course there were more practices we've implemented that were very useful, but I want to emphasize these):

1. The daily stand-up meeting – This daily 15-minute meeting had much more effect than we've expected. Suddenly everyone knew exactly where the whole project was standing and what the responsibilities of the whole team are, not just their own. This encouraged communication between the team members very much. In addition, I found myself, as the team leader, knowing exactly what my team members were doing every day without nagging, telling them what to do, or even having weekly meetings with them like I used to. It was really amazing, especially in an organization with an "overflow" of meetings, that the only meetings I had with my team were the Scrum ceremonies and maybe some design reviews once in a while.
   
2. Automated Unit Tests – As we increased our code coverage more and more, the quality of the framework increased as well. We got much less bug complaints from our users. We were also less and less afraid of making changes in the core of the framework since we got more confidence in our unit tests protecting its integrity. We could see clearly that the features our users were complaining about the most were the ones that were most poorly covered with unit tests.
   
3. The Sprint Retrospective – I would say this is the most important element of the methodology, and the thing that influenced the most our success in the project. This is actually what generated all the changes in the methodology. During these meetings everything was put on the table, and I mean EVERYTHING – from the sprint division and length to the every-day work in pairs, from the way our users prioritize our backlog and get support to the way we estimate tasks and update them in the TFS. By questioning everything and discussing every suggestion for improvement of the development process, in a few sprints we've reached an optimal and long-lasting methodology that worked well for everyone.
   Here are some examples of the things that were changed in our methodology along the way thanks to these meetings:
   • Users' involvement in backlog prioritization – At first I was hoping that at least most of our users' team leaders would participate in the Sprint Planning and Sprint Review meetings. After two sprints that we got less than 10% participation, we had to change this method. By the way, this is a direct consequence of the lack of a real Product Owner in the project (which I expected to affect us one way or the other).
     So we've added a "User Priority" field to our tasks in the TFS and I developed a small prioritization application for my users' team leaders, which they could run any time they liked and prioritize the backlog queried from the TFS. Each team leader got 100 points for distribution between the backlog items. If there were new requirements, they would post it to a special folder in the Exchange server and I would insert them to the TFS if relevant. Just before the Sprint Planning meeting, I would execute another small application that calculated the cumulative points for each backlog item and placed it in the "User Priority" field. Then, in the meeting itself (with just the team), we could decide what to do in the next sprint with consideration of our users' wills.
     At the end of the sprint, we released detailed release notes to all our users so they'll know exactly what's new in the fresh release without participating in a Sprint Review meeting.
   • Sprint division and length – Since some team members were working part time in the team, a 2-week development phase was too short to accomplish anything significant, so we've extended the sprints to 5 calendar weeks with a 3-week development phase. In addition, we've realized that the design phase wasn't always necessary and was defined as optional and with variable length.
   • Pair programming – We were always wondering if it was more useful than wasting. In some cases, it proved itself by resulting in better designs and better code quality. But in other cases, some team members felt it was a time waster. So we've decided to make it optional and task-specific. It was to be decided in every daily meeting who would pair up and who would work alone. Mostly, team members would pair up during the design phase.

This methodology proved itself for over a dozen successful sprints and releases of the framework. A few months before I left my position at this team, we've started a new framework project from scratch where we've worked in an Agile fashion from the beginning. It was much easier working on an Agile project from start than implementing an Agile process on an existing non-Agile project, but this is a different story…

In conclusion, I encourage you to tailor the methodology to the project and not just use a methodology as is from the shelf, as a tailored suit will always fit you better than any expensive brand name suit. Said that, once making changes to known methodologies rules, you must first understand why they exist and what the consequences of changing them might be. With an open mind to different methodologies and a continuous improvement process you can achieve a successful development process in your project while there's still a lot to do.

Agile Framework Development – Part II

As I concluded before, we tailored the methodology to our project. By "project" I mean all its aspects – the developed framework characteristics, the team characteristics and our users' needs (quality needs, TTM needs, etc.). In a sentence, we've decided to develop the framework in 4-week sprints, were a new version is released at the end of each sprint. So how can you deliver a high quality, fully packaged product every 4 weeks while obtaining significant progress and high productivity? The answer to this question relies on the methodologies guidelines.

These are the major guidelines of the methodology:

• Development would be done in 4-week sprints, divided to phases as follows:
  • 3-4 days of design and POCs for high risk and complex tasks of the sprint + QA test planning.
  • 0-3 days of fixes of critical bugs in the previous release candidate.
  • About two weeks of development, including unit testing and QA testing.
  • A day for packaging the whole product version (release notes, configuration tool, migration tool, FxCop rules, help, samples, installer and project templates).
  • A week of finalization (mainly boosting testing and bug fixing – NO DEVELOPMENT!).
• At the end of each sprint a new release candidate of the framework would be released to our users, following a CTP released after the development phase and followed by the final release of that version (a few days later).
• There would be nightly builds running all tests and continuous integration on every check-in.
• The team members would embrace XP guidelines, practicing pair programming, writing and running unit tests as part of the feature development.
• All Scrum sprint ceremonies would be performed – sprint planning, daily meetings, sprint review and sprint retrospective (no need for release planning since every sprint is a release sprint and requirements changed rapidly). In addition, there would be a sprint execution meeting after the design & POCs phase where the bugs aroused from the previous release candidate are inspected and a final sprint backlog is formed.
• All users' team leaders are invited to the sprint planning and sprint review, taking part in the decisions and prioritizations regarding the next sprint.
• No more support via direct e-mail messages to the team. All support will be done through a dedicated Exchange public folder so all users can learn from the knowledge accumulated by all support issues. Face-to-face support would be offered if support through the public folder has failed.

The first challenge was to convince the management that this is the right way for us to work on this project. This was a tough one since the management was very Waterfall/TOC oriented and knew nothing about Agile. I presented them the problems I'm trying to solve, the methodology as the solution, its guidelines, how does it intend to solve the problems and most importantly - the risks in the suggested methodology. These risks were as follows:

• Team members' availability – as I mentioned before, some team members were working on the project only part-time.
• Users support – as a major interruption factor for the team.
• Short periods between CTP, RC & release versions – not enough time for our users to examine the intermediate versions.
• Short development period – might not be enough to gain a significant progress between releases.
• Many versions – might increase maintenance.
• Pair programming as a practice that the team wasn't experienced with – might decrease productivity instead of increasing it.

After long discussions with them I got the green light to go, mostly because they believed in me and agreed for a pilot period of 3-4 sprints. They still weren't really convinced about the Agile approach.

The next challenge was to recruit our users to the process. This was a very important stage since there was no defined product owner (it was actually me playing this role) so even if the project was managed perfectly, it would fail if there would be no collaboration with our users. So I gathered all the users' team leaders to a meeting and presented them the new methodology, emphasizing the expectations they should have from it and the effect it will have on their interaction with my team. They were very suspicious about it since it was very strange for them, but finally it was accepted.

Now it was time to make all preparations needed. We've installed the Scrum for TFS template on our TFS and created a Product Backlog from all known future features (and some more that came up from some team brainstorming). We've defined the nightly build and continuous integration and entered all automated unit tests and QA tests we had to the nightly build. Off we went to our first sprint!

To be continued…

Agile Framework Development – Part I

8 years ago I've joined an elite technology unit in IDF. After working as a software developer for a few years, about 3 years ago I was given the position of the Infrastructure Team Leader (about 6 developers + 1 QA) in my branch. This team was responsible for the development, distribution and assimilation of all software infrastructures used by the different developer teams in the branch (100+ developers, dozens of small to mid-size projects). The main project developed by the team was a framework based on .Net 2.0 (and .Net 3.5 later on) which most of the branch's applications were based on. This project was in cooperation with Microsoft's consulting services, so the team consisted of MCS architects and developers, such as Alon Fliess, Sasha Goldstein and Dima Zurbalev. I started the new position a few months after the first release of the framework and during the development of release 1.1 of it. As the team leader, I was also responsible for the project management and product management of the framework developed by the team.

So how and why I've entered the Agile world at this point?

First, let me put out a few points regarding the state of the project and the environment at this point:

• There were at least 30 projects in different phases of their lifecycle that were built on the framework by more than a dozen teams.
• The first release of the framework had many bugs, some of which were fixed ad-hoc after the first release and released as hot-fixes to specific users.
• The development of version 1.1 of the framework took longer than expected, mainly because it took over a month to stabilize it (from CTP to Release), which caused delays in some projects depending on it.
• There was no sort of automated build (nightly or CI), just a few unit tests and a lack of QA on major parts of the framework.
• Some team members were working only part time in the team.
• The team wasn't productive enough since it was spending a lot of time supporting users for the version 1.0 of the framework and there was no knowledge preservation of the support issues.
• Our users required higher quality of the framework, better time-to-market and shorter support response time from the team to their complaints (which was done by e-mail at that time).
• Our users' needs were changing rapidly and it was difficult to look even a few months ahead to how the framework should look.
• There was no organized requirements management process for gathering requirements from our users (most of the developed features were decided by the team).
• There was no way of tracking the progress of the developed features so it was unclear for our users when their requested features were expected to be released.
• There was no requirements prioritization process in collaboration with our users.

All of these issues brought me to the conclusion that the framework project needs to be managed differently it all aspects. At that time, all my knowledge and experience in project management was with Waterfall concepts and TOC, using Gantt and Fever charts and working with buffers. Moreover, this was the approach selected by the branch's management (and even higher up) and was implemented in most of the projects. But it just didn't seem suitable for our project.

One of the MCS consultants in the team was Roy Osherove, an Agile expert which was about to leave our team. So I took the opportunity and learned from him the basics of Agile methodologies, particularly Scrum and XP. As I kept studying these methodologies, it seemed to me more and more that these concepts are exactly what we needed for making our project much more successful. So I started to define and form a suitable methodology for our project based on the Agile approach. After consolidating a draft of the methodology by myself, I've consulted my senior team members and fine-tuned it together with them.

Now, if you're an Agile person, you're probably thinking to yourself "this smells like a ScrumBut…". Well, it might be true, but I don’t think it's a bad thing in this case. Basically, I believe the methodology should be tailored for the project and not the other way around. Yet, it is an act that should be done with much caution and should be constantly reviewed.

In my next post I'll present the consolidated methodology and the major challenges I had at the beginning of the new era of the project.

Introduction

Hi, my name is Ram Dayan and I'm currently a senior software consultant and Agile expert in Sela Group. I've been a developer most of my life since I was a child, using different technologies that evolved over the years - from Basic on a Commodore 64/128 when I was five years old, through many other languages and technologies, mainly C++ using Win32 API & MFC, to .Net 3.5 on Windows 7.

Development was always my passion in my professional life (and still is), but a few years ago I entered the project managing world as well, leading a core technology team in IDF consisting of some of the top MCS architects, being responsible for the development, testing, distribution and assimilation of the software infrastructures used in dozens of applications developed by over 100 developers of the department. At that time, the whole organization was pushing towards TOC/Waterfall based development processes. This is where I first introduced the Agile concepts, SCRUM & XP methodologies into the organization, managing two successful major infrastructure projects based on the latest .Net technologies (.Net 3.5, WF, WCF). In over two years of Agile practice, I improved project management and adaptation to users' needs and increased products' quality significantly by implementing automated unit and QA tests, nightly builds, continuous integration and additional tools.

I hope to share with you as much as I can from my experience in Agile practice, presenting the motivations of the specific Agile implementation for every project, and the cons & pros of each Agile practice in each project. I will try to emphasize the Agile affects from the developer’s perspective (where the real work gets done) and to be as practical as possible. You're welcome to ask me any question regarding the projects I'll present or Agile issues in general.