If yoda were a developer…

With this being my third TechEd and first in the United States, it was by far the best Technical Conference I have been to so far. And from all of the presentations, technical discussions and sessions, there is one definite difference to all other Microsoft events that I have been to in previous years – the enthusiasm and willingness to engage the technical users on how they are using Microsoft Products. Several years ago I would never have imagined that Microsoft Staff (Program Managers and Technical staff alike) would have been so willing to engage the users and be open to frank discussions and feedback on their work (i.e. the development tools that are VS 2010, TFS 2010 and Lab Management).

Some of the highlights for me were a number of sessions that I attended:

ASI203 | Understanding the Microsoft Application Server: AppFabric, WF, WCF, and More

(David Chapell) – as ever David was insightful with his delivery, this time on the Service AppFabric from Microsoft, to the point that he highlighted the difference and somewhat confusing reference to Service AppFabric and Azure AppFabric.  With some of the demonstrations provided by Ron Jacobs, the session was invaluable for those that are on the fringe of Azure and the concept of Cloud Computing as well as those that are seasoned SOA implementers. The presentation took us from an explanation on AppFabric (Services) showing us the magic of AppFabric Caching; through using WF in conjunction with WCF to provide an alternative to traditional WCF Services; to using Hosting and Caching together to provide a seamless experience for the end user.

DPR206 | Visual Studio ALM: Lessons Learned through Dogfooding

(Brian Harry) – Brian took us through a journey of discovery as he pulled back the covers on the pains and successes that the Developer Division went through during their progress from VS 2005, 2008 and 2010. He highlighted the influence that the division had on shaping the tools that came to be as well as the influence that the process adoption had on the tools as well – specifically SCRUM. From the presentation of statistics on various metrics gathered in all three release and the comparison between them; to the explanation on how the teams breakdown the features into pillars then groups and then deliverables. This presentation is high on my list of favorite sessions.

DPR207 Why Software Estimation is so Painful and How It Doesn’t Have To Be

(Gregg Boer) – Gregg’s presentation took us through familiar territory (in fact all too familiar territory) and certainly provided us with the assurance that we (developers / software engineers) are not mad as hatters. His portrayal of circumstances and roles were spot-on to the point that it was uncanny to see – (has he been in the same meetings as I had?). This illustrative presentation re-assured me that the circumstances one finds one’s self is not unique and certainly is repeated across the majority of Software Development Companies throughout the world.

DEV08-INT Using Microsoft Visual Studio 2010 to Understand Your Applications

(Mark Groves and Suhail Dutta) – Mark and Suhail’s demos into how to utilize the features of the Architecture tools were very helpful even to someone who has spent sometime playing around with them in the months leading up to Beta and RC. The demonstrations of Layer Diagrams and UML Diagrams were useful to highlight the very important addition of Architectural tools that have been longed for by many in the development community – I for one am seriously ecstatic for such possibilities that can be incorporated into the build. Just the fact of being able to validate the integrity of the architecture in each build is in itself a major improvement and cannot be understated.

DPR03-INT | Increasing Your Productivity Using Code Katas

(David Starr and Ben Day) – apart from a very interesting topic, the chemistry between the two presenters made for good entertainment (especially their different viewpoints on Bowling – Ten Pin or Candlestick). David and Ben took us on a live ride from the start of a unit test through the cycles of code, test, refactor and showed us a very useful way for developers to stay on top of their game. In fact I was so buzzed I started to use the technique there and then, following David as he walked us through the problem solving exercise. I would highly recommend any serious developer interested in TDD to utilize the technique.

DPR204 | Top 10 Mistakes in Unit Testing

(Ben Day) – Ben covered a topic that was very close to my heart and did not disappoint in the least. In fact not only did he have the 10 mistakes listed, but even provided a further 4 more. Ben’s approach to the topic was very much along the lines of TDD and covered the many pitfalls that people face when embarking on unit testing. Although his ordering was not exactly the same way as I would have perceived it (he did say that they were not in a particular order); he definitely covered the aspects of mistakes made in taking on Unit Testing and showed us some prime examples along with tips on how to avoid the pitfalls.

DEV403 | Building Extensions for the Microsoft Visual Studio Architecture Tools

(Peter Provost) – Peter peeled back the covers on the extensibility of VS 2010 and showed us a glimpse of what is possible with the extensions in the Architecture Tools. Some of the methods by which we can extended the tools varied from the sublime (copying files to a specific folder) to the more subtle and elegant such as writing custom code and deploying them. My only frustration was not to have my MSDN information to hand to be able to download the Feature Pack; however as soon as I am back at the office I shall be trying it out. Combining this session with Mark and Suhails (DEV08-INT) gives a complete picture in to just what we can do with the Architecture tools of VS 2010.

I could go on and on about the sessions that I attended, but the biggest take away from this TechEd is the advancement that Microsoft has made in their Developer tools and how much they have listened to and involved the development community. From the obvious presence of Agile practices in many of the presentations to the technologies and tools available, I was not disappointed by the content and in fact I would go as far as to say – a very grateful thank you from this individual for moving us (in my mind) in the right direction for software development.

Many times a custom tool that is created to overcome a particular “issue” ends up morphing into something that is greater than the initial idea. Case in point, I had come across many instances where the sheer bulk of Sprint Backlog Items that had to be entered in to TFS almost made me break out in to a cold sweat – it is an arduous task to do it via the Team Explorer Window when you are doing the entries one by one:

So, typically for large volumes of Sprint Backlog Items I would prefer to use the Export to Excel capability of a TFS WorkItem Query:

I could then enter the bulk of Sprint Backlog Items entering the required data in each row (representing each SBI) and then use the Publish feature of the TFS Excel Team Add-In:

The only issue with this approach is that I’d have to go back and link each SBI in Team Explorer with the correct PBI!

So I created an Add-In to overcome this. At first the Add-In would only pull back the PBI Id and Title and allow the user to type in a new PBI Id and publish the link information, but then I realized it would be great (for planning purposes) to be able to pull back whatever field from a PBI that I wanted. So I created a mapping between the PBI Field name and a Column name that the user would type in to Excel (the red shows the mapping from the Excel Column text; the purple shows the mapping from the TFS Template definition for a Product Backlog Item:

I can then pull back whatever I like and be able to see how it relates to the list of Sprint Backlog Items I have. I also created an informative video to illustrate how to use the add-in.

You can get the latest version from:

http://www.petrellyn.com/jaspware/ExcelTfsAddIn

Recently I had been working on creating Sprint Backlog Items in Excel and then using the Team Explorer add-in for Excel to publish the changes back to the TFS server. It was great to be able to view tasks in Excel and update similar tasks through a spreadsheet manner rather than swapping back and fourth in Team Explorer of Visual Studio. The only issue was the linking to Product Backlog Items; there wasn’t any way to link the published SBI with appropriate Product Backlog Items – it meant I would have to go back to Team Explorer and do it through there. I had already worked on an Excel add-in to calculate work remaining for each team member:

The functionality behind this feature is based on certain fields being defined in the SCRUM template (Estimated Effort (Scrum), Work Remaining (Scrum)). The Excel Add-In exposes Formulas that can be utilized within a cell:

GetTotalHoursRemaining() provides the calculation of Total hours remaining in a given Sprint for one or more team members:

Returning to the problem at hand, I realized that it would be simple enough to add functionality into the existing Add-In to be able to “pull” the PBI links down to the sheet and even “push” new links back up to the server; after all each PBI has an ID that can be represented as text, and the process of adding a link to any TFS WorkItem is accomplished through the following call:

workItem.Links.Add(new RelatedLink(linkId));

With a constructor signature for a RelatedLink instance accepts an int:

RelatedLink(int relatedWorkItemId)

This meant that I could scour the ID column of the Sprint Backlog Item in Excel and can pull off the IDs as integers, then scouring the column that had the Product Backlog Item IDs I could update the Sprint Backlog Item internal Links:

By adding a further column (in the Spreadsheet) that can be identified by the Add-In I could pull or push the links to the Product Backlog Items:

I created a simplistic installer (it makes assumptions that you are running Office 2007 and that you are using a suitable template such as the Conchango SCRUM for TeamSystem):

http://www.petrellyn.com/jaspware/ExcelTfsAddIn/index.php?lang=eng

Wow – June 24th was the last entry! First of all I need to apologize for my bad blogging; I have no other excuse except for the volume of work AT work. Sure I could have re-prioritized and it may have made a difference, but I don’t think my employer would have been very pleased.

So, New England Code Camp, Microsoft Offices, Waltham, MA – full information can be found at http://www.thedevcommunity.org/Events/PresentationList.aspx?id=13. Today I am giving two presentations:

Using Entity Framework’s New POCO Features: Part 2 (Unit Testing)

Level: Intermediate

Starts: Oct 17 2009 2:50 PM

Ends: Sep 17 2009 4:05 PM

Room: MPR A

Speaker: James Phillips

In many cases Unit Testing is considered a chore rather than another development task and often ends up being the last task in a development cycle. More often than not, the sheer work involved in preparing unit tests for existing code can lead to the production of Integration Tests rather than true Unit Tests. Where a unit of code that is under test relies on an external resource, such as a Database or Configuration file, the dependency can lead to testing of the underlying mechanism as well as the unit being tested. This was especially true with Entity Framework 1.0 shipped with .NET Framework 3.5 Service Pack 1. With the advent of .NET Framework 4.0, the Entity Framework has advanced in favor of better Unit Testing with the use of POCO and the ability to create interfaces based on IObjectSet. This presentation will cover the examples that can lead to true Unit Testing as opposed to Integration Testing and provide valuable feedback metrics such as code coverage and automated build time reporting of results.

SCRUM and TFS

Level: Introductory

Starts: Oct 17 2009 4:10 PM

Ends: Sep 17 2009 5:25 PM

Room: Rhode Island

Speaker: James Phillips

SCRUM has grown in popularity and acceptance by many companies over the world with numbers of registered SCRUM Masters reaching 51,955 (11 March 2009 – Jeff Sutherland). Although SCRUM does not stipulate what tools to use to produce the necessary artifacts, Microsoft Team Foundation System provides a number of features via TFS Explorer that facilitate capturing the artifacts of SCRUM and is a useful tool for any SCRUM Master, Team and Product Owner. This presentation will highlight the SCRUM framework and show you practical use of TFS and other tools that facilitate the ceremonies and artifacts of SCRUM.

The slides and code are available for download here:

SCRUM_And_TFS.zip

EF_POCO_And_UnitTesting_slides.zip”

EF_POCO_And_UnitTesting_code.zip

EF_POCO_And_UnitTesting.zip

Now the title might be a bit mis-leading, but rather than discuss one issue or observation at a time, I wanted to touch on all topics in the same post.

Recently I have been delving deeper and deeper into the issues that I have seen first hand and heard / read about with regards to Scrum and I raise them here as a point of discussion and as a reminder to myself in the future when I wonder just what the heck was I thinking about?

Multi-tasking

First and foremost, something close to home that is the subject of simian (human) multi-tasking. Often when I broach this subject with my peers there is a lot of references to “Jamie hours” and being the inhuman way of doing things – i.e. my long hours of work and investigation. In other words – get a life, turn off the laptop and go to bed! There is a really good article in Time magazine that discusses the human capacity of multi-tasking.

I say this in jest but the topic is quite serious; should a Scrum Master take on tasks in a Scrum team in as much as being in the trenches with the team whilst at the same time as being the facilitator? I asked this question recently on LinkedIn and the few replies that I got are more or less what I had expected; “of course they can” and in some cases, should. And for the most part I do agree. It would appear to make common sense that someone who is on a Scrum Team as Scrum Master would need to take on a few non-critical tasks to at least lessen the burden on the team as well as “feel the pain” that the team goes through. This is made easier when the Scrum Master is a technical lead, a senior developer or SQ lead, someone who is accustomed to the typical tasks of the team.

However, when the role is filled by someone that is traditionally Project Management based, would they be able to jump in and out of the role? I would say that it depends on the Scrum experience of the individual – someone that is new to Scrum who is re-tooling as a Scrum Master from a Project Management position, would need time to settle in to the role and go through several sprints before even entertaining the idea of rolling up their sleeves and getting stuck in with the team. On the other hand it could depend entirely on the environment that the development is taking place. If it is a highly regulatory environment (Petro-chemical industry, aviation, military, healthcare) then the Scrum Master will probably be inundated with the various QA documents that are required.

Multi-project

Leading on from the discussion of a Multi-tasking Scrum Master, the context was set for a one to one correlation of Scrum Master to team. Something completely different is a one to many mapping of Scrum Master to two or more teams. In this scenario I would imagine that the traditional Project Manager role would be better suited to swapping between teams in a given time frame – although I could also foresee there being a decrease in efficiency on the part of the Scrum Master; what would happen if the Sprint Planning for one team collided with another important ceremony of the other team, such as a Sprint Retrospective. I would say that this would probably be more problematic than the first scenario and could lead to the failure of two or more teams, not just one. There again, it does depend on the individual and the teams that they are working with.

If I can do it; so can you.

Dangerous phrase that; many have lost their shirt or worse on such a challenge. However it does raise a valid point and should serve as a glimmer of hope to those that are embarking on the path to agility.

True, it is documented that many projects that have attempted to adopt agile methodologies have fallen by the wayside because of a plethora of reasons; but it only takes one team to pull it off in a company to be able to “inspire” other teams to follow suit. The main issue I can envisage is the fact that all too often people have the belief that if team X did it and it worked for them, then let’s take that model and apply it to team Y. They often overlook some of the dynamics that permitted team X to adopt and fly with agility. A small, close-knit, co-located team, bonding from the beginning across the disciplines; cannot be compared to teams that are dysfunctional from the outset (Ken Schwaber recently gave a great presentation on “Flaccid Scrum” and Martin Fowler blogged on this very issue). Also there are teams that feel it cannot be done because they have not been through the motions of Scrum to realize that it is capable of helping them to improve their process. The important point for those individuals to realize is that Scrum is not the silver bullet – it is the de-fogger of the windscreen, blowing away all the mist and shrouded activity that goes on in other styles of software development. With the tight feedback loop, it will highlight the issues of the development process faster and with more clarity than before – providing a much needed view of the issues well before it is too late.

Many un-initiated see a well oiled fully functional Scrum team as a bunch of hippy-tree-huggers because of their bonding and team work; however, few realize that this is a result of being immersed in a routine that requires each one of them to have faith in their colleagues and to be able to self-organize. In my experience it was not a pre-requisite to joining the team, it was a by-product of agility.

So then we come back to the title statement “If I can do it; so can you”. Although this is not entirely true, there is some smidgen of truth in it. After all, what is a Product Backlog? Isn’t it a list of requirements (stories) or defects (remember – bugs are now first class citizens). What is a Sprint backlog? It’s a set of tasks to complete within a given time. The main difference are the roles of the Product Owner and the Scrum Master and the fact that the team is central to the development process and take part in the estimation and sizing of the stories. For those of us doing Scrum it makes so much sense and can often be a sticking point when talking to our non-Scrum colleagues.

An important fact to bear in mind, covered in books and presentations, is that no two projects are alike; what works for one team might not work for another. For certain types of development a one or two week sprint is more manageable because of the nature of the work being done; or a more traditional three or four week sprint is necessary because of the type of stories being dealt with. With Scrum the Sprint Retrospective is fundamental for providing the necessary feedback to be able to make adjustments and fine tune the process – without it there is no feedback loop and the system is running un-controlled.

People often wonder where I get the time and energy to work the way that I do; the truth is it that it is all down to the passion I have for my work as a software engineer and the type of work that I am involved in. I am also very passionate about pushing the boundaries and I find it very difficult to accept that something can’t or won’t be done on the basis of “But, we’ve always done it that way” – it doesn’t necessarily mean that it is the right way, nor does it mean that it is appropriate for today’s world. It might have kept companies ahead of the game 10 or 15 years ago, but the world has moved on since then and now we have to be faster, more efficient, better. For me Agile Software Development lends itself to this change and is all about change.

I will be honest and say that this is the first “work related” book that actually captured my attention to the point that I would sit and read whilst my loved ones were enjoying their sweet slumber (and obviously blog about it).

This book is highly informative; being neither condescending, nor pushy and over-bearing on the way that agile adoption should be approached. Without intending to be a partisan; I would even go as far as saying that it is more than recommended reading, it should be required reading for anyone thinking of migrating to agile; recent adoptees of agile or anyone in between.

From the first chapters that guide us through the principles (I loved the annotated 12 principles of the Manifesto for Agile Software Development – section 1.1.2) and the descriptive text on the “paradigm shift from a plan-driven mentality”; to the readiness assessments and the importance of obtaining executive support; through to the population of the product backlog and on to the first iterations of an example company adopting Agility in their software development process.

There is no substitute for actually reading the book, which is a must; however various chapters and sections drew my attention more than others.

Section 1.1.2 – The agile principles:

Although the manifesto has been analyzed and described on various blogs and books; the descriptive text for each principle was really handy when evangelizing on agile and is a good primer for anyone new to the subject (and possibly even for those of us who have been practicing agile).

Section 1.2 – A paradigm shift from a plan-driven mentality:

This is a must read for those of us who have come from years of waterfall and attempts at changes to “traditional” methodologies or processes. The section highlights the change in mentality that is needed to move from more traditional ways of software development to a leaner, more agile way.

Section 2.4 – What does it look like when a team “becomes agile”:

With comparative plan related diagrams of how the change is made from waterfall to agile and the breakdown of how that transition was made; is comforting for those that have made the change as well as those that are thinking about/planning the change.

Section 3.2 – The different flavors of agile:

This section has a really good breakdown of strengths and weaknesses of the two foremost agile methods; Scrum and XP.

Section 3.3 – Create your own flavor to become agile within your constraints:

When I first started in agile there seemed to be a common mantra that permeated throughout the meetings and blogs that effectively stated if you weren’t doing it exactly by the book, you weren’t being agile. It is completely preposterous.
How can the same agile development methods used by a web advertising company be cookie-cut for a software company writing client server applications in a strong regulatory environment? The answer is – it can’t. There will need to be some adaptation. After all isn’t that one of the principle concepts of agile; what is the point of having Sprint Retrospectives to adjust and tweak a process in a constant attempt to improve? This section is a must read for those that are constantly being belittled or set-upon by “those in the know”.

Chapter 4 – The fitness test: all about readiness assessments:

Although I have not had the opportunity of actually performing this exercise; having read through the chapter it is very informative and goes in to great detail on how a company can be measured for it’s fitness to adopt agile development.

Section 6.3.1 – Tough questions:

I liked this section because of the example of typical questions asked by the team that will be adopting agile development and the possible answers to give about the migration process.

Section 7.1.1 – Attributes of a good coach:

This section contains a very good breakdown of the attributes that should be sought when selecting an agile coach. The following sections go into further detail about training and coaching; as well as details on the interaction with managers and stakeholders.

Section 7.3 – Creating a team with an agile mindset:

This section explains what ingredients are needed to create a sound agile team; from “Culture and roles” through to “Characteristics that influence individual performance”.

Chapter 8 – Injecting agility into your current process:

Just the title alone gives the idea of the maturity of mind that the authors have when confronting a company wanting to adopt agile development methods. From documenting the existing process (not everyone has it written in stone and perhaps not all aspects of the company are actually doing what it says in the process hand-book); to deciding what to keep and what to change.

Chapters 9, 10 and 11

Discuss the selection of a pilot project and the team that will be on the pilot project. This is very informative for those companies that have made up their mind to move to agile and are looking around for the best project to guinea pig.

Section 12.3 – Feature cards compared to…:

As a Scrum practitioner it was interesting to read the comparisons between feature cards, user stories, use cases and functional specifications.

Section 12.5 – Hard-copy vs. electronic cards:

I found this section particularly useful as it highlighted the benefits of both, using SharePoint as an example of the electronic format. Although the idea is to keep it as simple as possible I am an advocate of using technology where possible – more than anything to cut down on the waste generated by so much paper; but also for the fact that you can view the information at any time (this is effective when trying to explain PBI or SBI to persons not located in the same area).

Chapter 13 – Prioritizing the backlog:

This is a subject that I find is the least covered in discussions with peers (both at work and outside) and it is really helpful to see the suggestions posed throughout the chapter. Peppered with examples of a product backlog and how to handle various items; this chapter is a good starting point for broadening the discussion.

Chapter 14 – Estimating at the right level with the right people:

I still remember being asked to estimate for a particular requirement when I still felt that I did not have enough information to do a sound enough job of it. How different it is when you are doing it as a team and everyone can voice their thoughts on the matter. This chapter is particularly useful for those still in “traditional” methods or recent adopters of agile methods. Of particular interest is section 14.1 – Contrasting traditional and agile estimation techniques and section 14.2 – The importance of whole-team estimation; both of which ease the reader into the subject that is quite explanatory with regards to the estimation process in agile.

Section 16.3 – Identifying and estimating tasks:

This section has a nice “call-out” titled “Task assignments aren’t permanent” that describes how the early stages, specialist people will be suited to certain tasks and how with the passage of time and acquired experience in an agile environment team members will become more capable of taking on varied tasks that perhaps were out of their realm in the beginning.

The latter chapters of the book, starting with chapter 20, describe the process of adapting to change and learning as we go. Section 20.1 – Common reasons for adapting (i.e. make those tweaks mentioned earlier); describes common issues that crop up and some ways that teams adapt to the situation described.
Chapter 22 is particularly interesting with a detailed explanation on how to prepare and manage the retrospective.
Chapter 23 is a must read for companies that have successfully started a pilot project and are now looking at how to push across the divide and bring about change at an enterprise level.

As I stated at the beginning of this article, I would seriously make this book required reading for those that are at all interested in adopting agile or have just started – it is clear, concise and has plenty of example scenarios that many individuals and corporations would identify with.

I would like to state categorically (more so than my disclaimer on this blog site) that this blog entry is not a plug for any particular service or association to a particular institution, it is intended purely as an observation on my experiences and interactions with individuals both in the SCRUM community and the world in general.

We have all heard the mantra from the “founding fathers” of SCRUM – “Unless there is complete management backing; then SCRUM will not work” – this is very true, to a point. It depends entirely on the project.

How can that be you may ask? Well, consider a new project in an existing company where new ground is being broken both as far as methodology and technology goes – if it goes bust, well hey, at least “we tried”; if it flies, well hey, “I told you it would”. From a management perspective it can be a win – win scenario (except for the manager that has put their reputation on the line in pushing for the change in methodology and/or technology).

Taking this type of project and putting on my Britannic influenced monocle and looking at the evidence in the cold light of day, one could form the hypothesis that the SCRUM based project worked because it was isolated enough that it wouldn’t disrupt existing products / projects. If it failed, well, a few reputations would be soiled, time would have been wasted and something new would have been learned – don’t do it that way… If it succeeds however, we now have the seed for which we can germinate the other projects / teams.

Or do we? If we take existing projects and teams run through the traditional waterfall methodology and try to germinate them with the success of the “golden team” we all too often hit the “they just don’t get it” factor. This is especially true when the proverbial hits the fan; it is far too easy for everyone to scramble back to the former way of doing things and hit panic mode – for any number of reasons. One of the failures at this stage can be attributed to the fact that those that were outside of the Golden Team during the whole process of development have little or no idea of what the implications of being SCRUM really are.

What is the first aspect of SCRUM that is so appealing to those that are doing it?
Complete and utter transparency – there is nothing that hones your concentration so much as to “air your dirty laundry in public”. The sprint burn down chart that is viewed on a daily (or hourly basis) can be very telling to those outside of the team, especially when you know what you are looking at.

What is the main aspect of SCRUM that traditional managers are petrified of?
The perceived loss of power: “What? You mean to say that the team is in charge of organizing their tasks, doing the estimates, etc. How will that work without a manager telling them what they should do?” It is all about trust. In order for SCRUM to truly work you need to trust the team. You can monitor them easily enough and as SCRUM dictates (via the Product Owner or the team itself); pull the plug when the whole scene goes south.

For many, the idea of “handing over” control of a project is too much to bear and is best left to projects that will not impact the company too much. I am not saying we should all go and play the typical team-building exercises where an individual allows themselves to topple over and be caught by their colleagues, but the idea is not far off. If there is no trust in the team then there is little chance of SCRUM working and the traditional dictatorial methodology is best suited to that type of manager.

There is a definite necessity of culture change required, both at the team level and at the management level. For those of us that have become experienced at SCRUM through whatever avenue we have followed, it becomes second nature to us and anything remotely related to waterfall seems like the dark ages of Software Development.

At a team level there is the necessity of maturity on part of the team members to know how to play within the rules, to be honest and open about their estimations, task progress and their limitations – they’ll be very quickly found out within two or three sprints.

At the management level, there will be a necessity of helping your teenage team to pack their bags and prepare to venture out in to the “big bad world” of software development – you will need to place your trust in them, be open with them about your concerns and most of all show them your unbending support.

There is no magic formula for ensuring that a SCRUM project will work, there are numbers out there that state that up to 90% of SCRUM teams fail – the main reason being attributed to the emotional factors (from Michael de la Maza). As someone that has moved countries 4 times, it wasn’t until I came to the US that a cultural consultant pointed out to me the emotional roller coaster that many go through under such circumstances. Google the phrase “cultural adjustment curves” and you will come across articles such as the one provided by the University of Minnesota Duluth where they discuss the culture shock experienced by many individuals that move abroad. When you look at the graph on offer in the article; there are various stages that a person will pass through:

This can be mapped on to many circumstances where a person has to experience a radical change in their lives. We often overlook the fact that we often spend more time at our places of work than we do in our personal lives and therefore the emotional experiences we have in the work place play a lot in to the feelings we carry home. From what I have seen of SCRUM blogs, lectures, books, etc. few people seem to highlight the fact that there is an aspect to change that needs to be accounted for when adopting such a radical change in methodology (Michael de la Maza is one of the few people that I have had the pleasure to meet and share ideas of SCRUM that actually understands it).

Therefore when making the statement that you are prepared to plough headlong in to SCRUM, bear in mind what you and your teams are going to get in to. As a manager you will need to be able to place your full trust in the team to handle the crisis that they go through and the judgments that they make that perhaps were traditionally in the domain of a manager. As a member of the team, you will need to be honest and open about your work, you will need to be frank with your team-mates (obviously not to the point of being obnoxious) as well as accept their comments about your work. You will also need to have no shame in admitting failure, but at the same time be safe in the knowledge that you and the team can pull together to sort it out.

One of my fondest memories of development was during the height of the initial phase of a new SCRUM project, when the team appeared, for all intents and purposes, as though it was a (very) small colony of ants – as soon as an issue bubbled up we pulled together to resolve it as a team. We were (and still are) very close – with the comfort of knowledge that we can count on each other at all phases of the project.

I cannot effectively express in words the feeling of elation that comes when working within a team immersed in SCRUM – co-located, cross functional and open makes other methodologies seem dull, obscure, in-efficient and out of date.