No one is saying Silverlight is the Flash killer, but an Adobe Flex killer it might be. As a Microsoft developer I may have a skewed perspective. To give myself a little "expert" credit I can say I have used Adobe and Macromedia products for many years and love them too... I worked on many small Flash projects over the years and even a few non-professional projects in Flex.
Back to my point, look at the history of Flash, it started as a technology to do fancy/flashy animations. Granted it has done a good job, and continues to grow up nicely in that Adobe suite. Flex took a great move to the Eclipse platform, which generates a nice following from the non-Microsoft geeks. But ultimately the way Flex and Flash work together, can I say "sucks?" OK I said it. Adobe does not have the experience Microsoft does in providing developer tools, nor does it have any where near the number of great coders in it's platform. Allowing developers and designers to work extremely well together should really change things.
I would guess some day Flex will add the nice visual design features of Flash but it might be too late. Not to mention these action script files hanging off the side. Currently it's really more designed as one technology or the other, although Flex can play a Flash movie (animations) and good flex guys can do some hacks to get them working pretty-well together.
OK technically yes Flex outputs Flash based code, but in Flex there are no real animation UI's. For the true geeks this is not a problem, they will write code for every animation no problem, but there is no easy way for great UI designers to easily work well with die hard developers. Microsoft has definitely done this right by having a single technology and a the great Expression Blend, that works very well with the Visual Studio. This is an environment that just Rocks!!! Sure Blend 2 and Silverlight 2 have their funkiness but you really can see where this is going and how good it will get. Expression Blend 3/Silverlight 3 look very promising right now.
An example of the platform maturing is that Blend 3 will now work with source control, Team Foundation Server at the minimum, a crucial step towards a perfect working relationship of developer and designer. You also now have the new Blend 3 SketchFlow (now the Product owners can do mock-ups, check-in, the designer can make it look good, check-in, and the developer can code it. The whole Visual Studio platform, provides complete lifecycle support. For QA, for Build Master. You name it.
The other new feature of binding UI's to data-sources means that developers can create empty data-objects that can be bound to a UI page in 1 line of XAML, and the UI guy can add his own test data without any code other than markup. It would even be really easy for the UI guy to even create his own data object without requiring him to be a true geek, only a little training. There are some amazing video's here to see the new Silverlight 3 features.
http://videos.visitmix.com/
Microsoft is really addressing all the shortcomings of Flash and hitting them head on. A "simple" one such as working back and forward buttons in the browser. They have what looks like clean solution in SL3. I could compile a long list of stuff I have tested personally not to mention a lot that I have not.
So ultimately is Silverlight a Flash killer probably not, but it might be an HTML killer, did I say that, OK joking but seriously. HTML, javascript, css with a mix of server technologies is a one big "hack" whether it is asp.net, php,... I have to say it is similar to Flex and Flash's relationship, HTML was not originally designed to be dynamic. Ask windows developer they will tell you web technologies feel like a hack, a piecemeal of mixed semi-unrelated technologies. Even though lately I have been doing a WPF project, I am not a windows developer. As a career I prefer web technologies and I even really like asp.net, almost love it from a business value perspective.
Ultimately as Silverlight grows up, I along many other developers will no longer want to deal with HTML, and my crystal ball says most of the top talent UI developers will feel the same. How many more years do you want to deal with browser compatibility issues? Me zero. How long can the business hold back IT, my guess is not too long assuming developers can be as efficient as they are now, especially if they can deliver RIA, instead of just IA.
Tuesday, July 7, 2009
Geographically Distributed Scrum Teams
They say Scrum is difficult and it quickly points out your weaknesses. After 2 years of inspecting and adapting with geographically distributed Scrum teams, and even though our processes are far from perfect, I can honestly say it usually feels pretty and my teams agree. We have high team satisfaction, client satisfaction and on the road to high profitability. Distributed Scrum seems to be working...
I am discussing a development team in Poland - SaaS (asp.net/silverlight/sql/soa) with product owners in Seattle, ... 9 time zones are a bit painful, but the whole team averages 40 hour work weeks, during basically normal work hours.
So what about Scrum? No 3x5 cards, that's too bad. Microsoft's Team Foundation Server (TFS) holds our electronic artifacts. We are using the eScrum Template for TFS. Every project always has a working burndown chart. Prior to the Daily Stand up we get an email with the burndown chart. In a Skype based meeting everyone answers the 3 questions fairly religiously. Because the answer to the question "What did you work on today?" is in TFS, we have some overlap. Hearing it on the phone frequently sparks some ideas for further followup discussions.
We run a hybrid scrum process, and I am more of a manager or director, but I do my best to maintain the role of "inspiration enforcement," not the "ruler." I also assist with removing blocking issues due to the lack of product owners on our time zone. I have to say our teams function very well without me, which allows me to easily work remotely most of the year. I just need to be extra available at the beginning of the sprint. The key here is allowing the team to do it's thinking, and I guess a little delegation helps also.
We also have other hybrid roles. Scrum Master / Dev Manager. As Scrum master they run all the meetings, help remove blocking issues, and make sure the burndown is heading downhill (positive direction). Not to mention as a manager ultimately responsible to making sure the product quality stays high, definitely not true Scrum, but I do believe if you ask the teams they feel like they run their own show, the manager is more of a support role, due to shortage of resources they happen to play the Scrum master also. This also allows the teams to says focused directly on their projects for the most part. One good thing is different geo, and different time zone makes it so the Scrum master does not need to do much blocking.
Using TFS. This is a long subject in itself but to keep it short and mention the highlights of what we use it for product backlog items, sprint tasks, bugs, backlog priority, sprint task priority, iterations, areas to name a few. We move unassigned backlogs into sprint backlog. We create developer and QA tasks linked to sprint backlog items. Sprints in TFS are basically just an iteration. BL items, tasks, and bugs are all just different workitems with different sets of clothing. You can also see articles on build automation and code reviews. (Soon).
Velocity. I have seen many posts on improving velocity. Because each team and company is so unique, and I think most of the time people have very large products they are delivering over many sprints, with semi-consistent teams. I don't feel most of what I have read is overly accurate to our situation or level of change, although scrum still excels for our projects. We do backlog (story point) estimation very quickly and early and I would not say it is particularly accurate, as we frequently change the scope before or within the planning meeting(s). We can have a pretty good idea of when things will be completed and that is good enough for us. We stick to assuming we will get 80% of the most important features completed each sprint. Trying to increase velocity might have some positive side affects, but currently assume we get more efficient as we go anyway.
The schedule - 4 week sprints
Day one Sprint Planning - Europe evening understand the backlog, includes PO
Day two Sprint Planning - Design meeting followed by task estimation and creation
About 10-12 days of developement (holidays...)
A stabilization day (just in case)
4 days UAT
Release every sprint
The meetings. Every 4 weeks we release a new sprint. Because we release each sprint we also need time for the customer to review, some teams are good at keeping the client reviewing all the time but frequently it is once a month. This means we need a time for user acceptance tests, although this is at the end of the sprint and they really don't have a choice at this time, our custom software teams give the client more choices. The only time we have for the sprint planning meeting is end of day Europe, beginning of day Seattle. We break the planning meeting into 2. Day one, go through the backlog and make sure we clarify any questions (3-4 hour meeting). The next day when they are fresh during, the morning the development team discusses in detail including tasks, and comes up with list of remaining quesitons, which can usually be handled by email. Developers and QA then go and create their tasks with personal hours estimates and the scrum master creates the burndown in TFS.
Sprint Review meeting, also a little non-traditional. Our product owners also play multiple roles which they end up being busy, so frequently they have not even reviewed all the changes before a Sprint Review. Our QA runs the sprint review. Goes through the Backlog shows what has been accomplished.
So there is an overview. Is it Scrum? Some might say no, I definitely say yes. Inspect and adapt gives leeway in the definition of Scrun. We do try to adhere to the Agile principals. I also agree there would be huge benefit in being collocated, at least some of the time, in many cases this would likely offset the cost of having developers in lower cost center locations. Don't get me wrong, I love this team, and they are extremely gifted, but as I said there is something very valuable in colocation. Good luck with your projects. ~alex
I am discussing a development team in Poland - SaaS (asp.net/silverlight/sql/soa) with product owners in Seattle, ... 9 time zones are a bit painful, but the whole team averages 40 hour work weeks, during basically normal work hours.
So what about Scrum? No 3x5 cards, that's too bad. Microsoft's Team Foundation Server (TFS) holds our electronic artifacts. We are using the eScrum Template for TFS. Every project always has a working burndown chart. Prior to the Daily Stand up we get an email with the burndown chart. In a Skype based meeting everyone answers the 3 questions fairly religiously. Because the answer to the question "What did you work on today?" is in TFS, we have some overlap. Hearing it on the phone frequently sparks some ideas for further followup discussions.
We run a hybrid scrum process, and I am more of a manager or director, but I do my best to maintain the role of "inspiration enforcement," not the "ruler." I also assist with removing blocking issues due to the lack of product owners on our time zone. I have to say our teams function very well without me, which allows me to easily work remotely most of the year. I just need to be extra available at the beginning of the sprint. The key here is allowing the team to do it's thinking, and I guess a little delegation helps also.
We also have other hybrid roles. Scrum Master / Dev Manager. As Scrum master they run all the meetings, help remove blocking issues, and make sure the burndown is heading downhill (positive direction). Not to mention as a manager ultimately responsible to making sure the product quality stays high, definitely not true Scrum, but I do believe if you ask the teams they feel like they run their own show, the manager is more of a support role, due to shortage of resources they happen to play the Scrum master also. This also allows the teams to says focused directly on their projects for the most part. One good thing is different geo, and different time zone makes it so the Scrum master does not need to do much blocking.
Using TFS. This is a long subject in itself but to keep it short and mention the highlights of what we use it for product backlog items, sprint tasks, bugs, backlog priority, sprint task priority, iterations, areas to name a few. We move unassigned backlogs into sprint backlog. We create developer and QA tasks linked to sprint backlog items. Sprints in TFS are basically just an iteration. BL items, tasks, and bugs are all just different workitems with different sets of clothing. You can also see articles on build automation and code reviews. (Soon).
Velocity. I have seen many posts on improving velocity. Because each team and company is so unique, and I think most of the time people have very large products they are delivering over many sprints, with semi-consistent teams. I don't feel most of what I have read is overly accurate to our situation or level of change, although scrum still excels for our projects. We do backlog (story point) estimation very quickly and early and I would not say it is particularly accurate, as we frequently change the scope before or within the planning meeting(s). We can have a pretty good idea of when things will be completed and that is good enough for us. We stick to assuming we will get 80% of the most important features completed each sprint. Trying to increase velocity might have some positive side affects, but currently assume we get more efficient as we go anyway.
The schedule - 4 week sprints
Day one Sprint Planning - Europe evening understand the backlog, includes PO
Day two Sprint Planning - Design meeting followed by task estimation and creation
About 10-12 days of developement (holidays...)
A stabilization day (just in case)
4 days UAT
Release every sprint
The meetings. Every 4 weeks we release a new sprint. Because we release each sprint we also need time for the customer to review, some teams are good at keeping the client reviewing all the time but frequently it is once a month. This means we need a time for user acceptance tests, although this is at the end of the sprint and they really don't have a choice at this time, our custom software teams give the client more choices. The only time we have for the sprint planning meeting is end of day Europe, beginning of day Seattle. We break the planning meeting into 2. Day one, go through the backlog and make sure we clarify any questions (3-4 hour meeting). The next day when they are fresh during, the morning the development team discusses in detail including tasks, and comes up with list of remaining quesitons, which can usually be handled by email. Developers and QA then go and create their tasks with personal hours estimates and the scrum master creates the burndown in TFS.
Sprint Review meeting, also a little non-traditional. Our product owners also play multiple roles which they end up being busy, so frequently they have not even reviewed all the changes before a Sprint Review. Our QA runs the sprint review. Goes through the Backlog shows what has been accomplished.
So there is an overview. Is it Scrum? Some might say no, I definitely say yes. Inspect and adapt gives leeway in the definition of Scrun. We do try to adhere to the Agile principals. I also agree there would be huge benefit in being collocated, at least some of the time, in many cases this would likely offset the cost of having developers in lower cost center locations. Don't get me wrong, I love this team, and they are extremely gifted, but as I said there is something very valuable in colocation. Good luck with your projects. ~alex
Life before and after Ndepend
There are a lot of reviews of ndepend out there, and I don't think I have read a negative one, granted 1/2 of them got a free copy but I can say I paid for mine. Our team uses ndepend as the "big brother code reviewer," always ready to give his opinion on check-in. We do not use it as a replacement for manual code reviews it only allows our manual code review process to be more focused and productive.
Our team: Our company has about 80 IS strong (developers, scrum masters and QA). My work focuses on what we call the "Product Team," as contrasted to our company's core line of work, which is custom development for the fortune 500.
We have been using Microsoft technologies for 12+ years and currently (ASP.NET 3.5, C#, Silverlight, SQL). Hybrid Scrum has proliferated our organization, using Team Foundation Server (TFS) for most of our electronic process based needs. Item tracking (bugs, backlog, tasks), source control, and build process. I have also been trying to inspire my teams to do TDD but it doesn't seem to stick.
Before ndepend our code reviews were hap hazard and lacked focus, as an example "This is the code I have been working on... Oh that's nice or no that's not so great will you refactor it when you get time?" Then out pops a TFS task, assign to a future sprint/iteration, only possibly to be postponed forever. In the "fridge" as my team had coined, just waiting for you like left overs.
Each team has a different review process, and each team has different criteria of what they see as important. Amazing we can get such consistent results, all of projects over 2 years old turn into something you would not even introduce to your mother. Sure quality is relative but I consider frequent 100 line methods with high cyclomatic complexity and 20%+ code duplication pretty low. How does this happen? Everyone knows small simple methods are best, don't they? And reuse... cut and paste is much faster. Conflicting priories and procrastinating refactors are only a couple of ways to achieve such consistency.
There are many reasons for code reviews. My research would say the industry defines the primary purpose of code reviews to find defects. For the purpose of this article you might define my code reviews as design reviews, although I am only looking at code.
What am I looking for? Hard to read / unmaintainable code, it smells bad, and more importantly is to provide developers better options to achieve the goal of clean code. Consistently finding bad code is is easy, consistently keeping smelling fresh is not. In manual reviews we also look at team standards, security, naming conventions... you get the picture.
Life after ndepend: We have implemented ndepend in a way that I have not seen any other teams openly discuss on the web. Realize my ultimate goal is to get developers to keep their code clean and I can justifiably argue, the easiest time to fix it is when you create it. If the code is fresh in your mind you feel much more comfortable refactoring. I can honestly say our current processes have accomplished our goal of keeping our code clean. We can and will take this progressively further but I can easily say over time our code has stayed so much better, not only would our developers show their old code to their mother, they might even show it off to a peer.
Many companies use ndepend with continuous integration (ccnet). We also are using ccnet for all of my teams projects. We use it in a fairly simple manner, immediate feedback when developers break the build and run our ndepend automation process, that's it for now. What we are doing differently is that when a developer checks in some failing code, ccnet creates a refactor task for the developer and he gets an email from TFS, new task created, so he can go in immediately and clean his code he was just working on. Developers can usually clean 80% or more right after this check-in failure. I know... before check-in is even better.
To inspire the developer further we have a daily email that goes out to all developers and the managers with red, yellow, green project status to show if you have closed all your ndepend failure tasks. Yes every developer wants his project green, we provide everything possible to promote this, including the ability to postpone a task. Back in the "fridge," only this time it is like beer, you can't wait to take it out. While in the fridge the task does not affect the green status. Today 6 out of 7 of our projects are green and 4 out of 7 have no outstanding tasks that need refactoring. Much better than continual postponement and a couple that are trailing are legacy that are being brought up to par, talk about difficult.
So a long article only to say. Immediate code verification feedback and daily email color status, so simple, so valuable.
In a separate blog I will talk about what is the definition of red, yellow and green and what we see as valuable for the rules of ndepend. The great thing about ndepend is each project or team can have their own rules. I will also create an blog about manual code reviews.
Ultimately I believe that keeping developer inspiration high may be the most important goal in software development (customer satisfaction is near the top too). Developers spend so much time maintaining applications, keeping the quality high is part of retaining that inspiration, even maintainance tasks are more fun when you know you must adhere to standards and refactor to keep your code clean.. Good luck...
Our team: Our company has about 80 IS strong (developers, scrum masters and QA). My work focuses on what we call the "Product Team," as contrasted to our company's core line of work, which is custom development for the fortune 500.
We have been using Microsoft technologies for 12+ years and currently (ASP.NET 3.5, C#, Silverlight, SQL). Hybrid Scrum has proliferated our organization, using Team Foundation Server (TFS) for most of our electronic process based needs. Item tracking (bugs, backlog, tasks), source control, and build process. I have also been trying to inspire my teams to do TDD but it doesn't seem to stick.
Before ndepend our code reviews were hap hazard and lacked focus, as an example "This is the code I have been working on... Oh that's nice or no that's not so great will you refactor it when you get time?" Then out pops a TFS task, assign to a future sprint/iteration, only possibly to be postponed forever. In the "fridge" as my team had coined, just waiting for you like left overs.
Each team has a different review process, and each team has different criteria of what they see as important. Amazing we can get such consistent results, all of projects over 2 years old turn into something you would not even introduce to your mother. Sure quality is relative but I consider frequent 100 line methods with high cyclomatic complexity and 20%+ code duplication pretty low. How does this happen? Everyone knows small simple methods are best, don't they? And reuse... cut and paste is much faster. Conflicting priories and procrastinating refactors are only a couple of ways to achieve such consistency.
There are many reasons for code reviews. My research would say the industry defines the primary purpose of code reviews to find defects. For the purpose of this article you might define my code reviews as design reviews, although I am only looking at code.
What am I looking for? Hard to read / unmaintainable code, it smells bad, and more importantly is to provide developers better options to achieve the goal of clean code. Consistently finding bad code is is easy, consistently keeping smelling fresh is not. In manual reviews we also look at team standards, security, naming conventions... you get the picture.
Life after ndepend: We have implemented ndepend in a way that I have not seen any other teams openly discuss on the web. Realize my ultimate goal is to get developers to keep their code clean and I can justifiably argue, the easiest time to fix it is when you create it. If the code is fresh in your mind you feel much more comfortable refactoring. I can honestly say our current processes have accomplished our goal of keeping our code clean. We can and will take this progressively further but I can easily say over time our code has stayed so much better, not only would our developers show their old code to their mother, they might even show it off to a peer.
Many companies use ndepend with continuous integration (ccnet). We also are using ccnet for all of my teams projects. We use it in a fairly simple manner, immediate feedback when developers break the build and run our ndepend automation process, that's it for now. What we are doing differently is that when a developer checks in some failing code, ccnet creates a refactor task for the developer and he gets an email from TFS, new task created, so he can go in immediately and clean his code he was just working on. Developers can usually clean 80% or more right after this check-in failure. I know... before check-in is even better.
To inspire the developer further we have a daily email that goes out to all developers and the managers with red, yellow, green project status to show if you have closed all your ndepend failure tasks. Yes every developer wants his project green, we provide everything possible to promote this, including the ability to postpone a task. Back in the "fridge," only this time it is like beer, you can't wait to take it out. While in the fridge the task does not affect the green status. Today 6 out of 7 of our projects are green and 4 out of 7 have no outstanding tasks that need refactoring. Much better than continual postponement and a couple that are trailing are legacy that are being brought up to par, talk about difficult.
So a long article only to say. Immediate code verification feedback and daily email color status, so simple, so valuable.
In a separate blog I will talk about what is the definition of red, yellow and green and what we see as valuable for the rules of ndepend. The great thing about ndepend is each project or team can have their own rules. I will also create an blog about manual code reviews.
Ultimately I believe that keeping developer inspiration high may be the most important goal in software development (customer satisfaction is near the top too). Developers spend so much time maintaining applications, keeping the quality high is part of retaining that inspiration, even maintainance tasks are more fun when you know you must adhere to standards and refactor to keep your code clean.. Good luck...
Subscribe to:
Comments (Atom)