Managing Different Styles of Development Team (Part 2 of 2)
This is the second part that looks at different styles of SharePoint development teams. The premise is that not all teams have the same attributes. Well, no surprise there.
You can find part 1 here: Managing Different Styles of Development Team (Part 1)
The two attributes of the team that we’ve looked at are:
- how skilled the team is
- their approach to the project
That is, some teams are very experienced with SharePoint, and some not so. Also, some are happy that SharePoint is being used for the project, and some not so.
Using these two attributes as axes on a graph, we’ve identified four types of development teams, as show in the following diagram.
The broad characteristics of these types of teams are:
- Type 1: A capable and proficient team who have good experience of developing successful SharePoint solutions. They are happy to be working on the project and are convinced that the use of SharePoint is appropriate.
- Type 2: A development team who are probably new to SharePoint. They may, or may not, be proficient developers. Even so, they see the use of SharePoint as a good thing.
- Type 3: This team has had little exposure to SharePoint development. They are not convinced that SharePoint is a good fit and would probably prefer to be using some other technology.
- Type 4: This team are skilled and versed in SharePoint development. However, they are not convinced the SharePoint is relevant for the project.
The previous posting discussed the two upper quadrants: when folks are happy that SharePoint is being used for the project. In this posting, we address the two lower quadrants: when people are not happy (or not convinced) that SharePoint is a suitable platform for the project.
Type 3: Novice and Sceptical
This type of team are new to SharePoint development and, for various reasons, they are not convinced that SharePoint is appropriate or relevant for the project.
I’ve come across project teams like this in two main scenarios:
- The development team prefer to write everything themselves
- The customer is starting to use SharePoint instead of some other technology
In the first case, I’ve seen customers make the following (wrong) argument:
- SharePoint is built on.NET
- I have.NET Developers
- I have SharePoint Developers
With a development team that prefers to build everything themselves, nothing beats the purity of their own codebase written from scratch. Now, don’t get me wrong: this approach is sometimes needed. But SharePoint provides a whole set of building blocks and in-built capabilities. As such, this is a team that is used to doing things in a particular way and they have to come to terms with an alternate approach. For example, there are recommended ways of doing things and this can feel like a whole set of restrictions on the team – they can feel as if they have all their freedoms taken away from them. Naturally, this results in a degree of frustration and it is no wonder that they are not feeling too great about having to use SharePoint.
In the second case (when they’re moving away from some other technology), the team is in a similar position. They know how to get the job done with the previous mechanisms of the alternate software package. Why do we have to go and spoil everything with the introduction of SharePoint? This can be the situation when upper management has not taken the time to explain why there is the move to SharePoint. After all, the IT Strategy has to be tied to, and serve, the Business Strategy. Consequently, there has probably been some decisions made elsewhere that has driven the move to SharePoint. Sometimes, these drivers don’t get fully, or properly, relayed to the developers and this leaves the wondering, “Why are we doing it this way?” Sometimes, a quick chat is all that is needed.
The trick is to try and move them from being a Type 3 team to a Type 2 team. That is, move them from being “novice and negative” to “novice but positive”. From there, we already know how to get them to Type 1 “export and positive”.
Within any development team, I always have a “holy trinity” of three key roles:
- User Experience Lead
- Lead Developer
- Test Lead
These three people are the ones that I look to, in the first instance. The UX Lead is critical to building the user stories, scenarios and wireframes that define the solution that we are creating. The Lead Developer will be responsible decomposing the solution into its constituent elements and organising the other developers to implement the code and create the necessary configurations. The Test Lead is the one who keeps everyone honest by checking to make sure that the code executes as it should and that the various quality attributes are met.
If I sense that I am in the realms of a Type 3 team, I have always found it most important to take my “holy trinity” aside and deal with them independently. If I convince these folks that SharePoint is both useful and appropriate, I can be pretty sure that they will take the message to their respective teams. Instead of trying to persuade the complete team, I have reduced my problem to a much smaller one: convince the leaders and then let them lead their teams.
And I have been most successful in this task when I’ve concentrated on the things that they don’t have to do rather than trying to explain how good SharePoint is. Sometimes a solution is being used to support a brand new business concept that has never existed before and every single line of code needs to be written from scratch. Most of the time, the solution is well understood and the pattern has been established for a long time.
Applications of SharePoint tend to lie mostly in the second camp: the solution patterns are well known and understood. We typically have forms being used to update custom lists and this may make use of event handlers or workflows to implement some business logic. Sometimes, we have a job to perform some form of automated task on a scheduled basis.
Well, so far, so good. The development team could well argue that ASP.NET can also be used to implement such a solution. And they’d be right. However, it is all the “value-adds” that SharePoint brings that I first discuss with my Leads.
For the UX Lead, their efforts can focus on the screens for the actual solution instead of needing to address administrative elements. For example, user administration and security permissions are provided by SharePoint and so these are screens they do not need to think about and design. In addition, the overall approach to screen layout is also provided by SharePoint: master pages, page layouts, themes, headers, left-hand navigation, etc.
For the Lead Developer, we can address scalability and data integrity because SharePoint is based on ASP.NET, runs on IIS, and uses a database to hold its data. It can have multiple front-end web servers that handle load balancing. The use of SQL Server provides the integrity, scalability, robustness, and security of the underlying lists, data and documents used by the solution. We have the security model that can be applied to lock down elements such as Management Libraries, etc. The site engine can be used to serve different types of web site. We have a mechanism to deploy and retract custom code via Features and Solutions. We have the performance counters in order to provide for monitoring the application once it has been deployed. And the list goes on.
For the Test Lead, again, the argument is that they do not need to spend time testing the administrative paraphernalia of the solution. All they have to focus on is testing the new components in the context of the business solution. Also, as SharePoint provides a rich scripting interface, they can automate their tests to populate test data and users, etc. Furthermore, the use of the solution deployment and site administration means that they can have a controlled test environment that they can tear down and rebuild with relative ease.
So, instead of trying to take on a whole development team, I decompose my problem into smaller elements: convince the Leads and trust them to convince (and lead) their teams.
Type 4: Experienced and Sceptical
Now, you might be forgiven for thinking that there’s no option but to resign your position when faced with a Type 4 team. They’re knowledgeable and skilled SharePoint developers. They probably are leading lights in their respective communities. And they’re convinced that SharePoint is not a good idea for this project.
Oh dear.
The trick, here, is to really understand what their problem is. Because it may well be that, once you start digging into things, that they have concerns in only one or two areas. If we can address these concerns, we will have moved the team from a Type 4 (expert but negative) into a Type 1 (expert and positive). And that’s our goal, isn’t it?
Let’s start with the easiest scenario: the team has well founded concerns about some areas. This can arise for a number of reasons. For example, the team might have past experience in a particular area and they are aware of the problems that can arise. These don’t have to be just technical problems. Problems can arise for organisational reasons, as well.
So, it may well be that you have designed a system with an incorrect assumption. Perhaps, for a given customer, certain features are not enabled due to a variety of concerns. Or it may be that you are relying on an external system that the team knows is not as reliable as you might have been led to believe. There’s a whole host of reasons why you might need to modify your design. Just because you’re the architect, it doesn’t mean that you are always right.
Part of the skill of an architect is to be able to negotiate and compromise. And when there is skilled expertise advising you that a particular course of action is ill-advised (and when you have convinced yourself that they are right), it is time to flex the architecture and record your modifications in a refresh of the Solution Architecture document and an update of the Decisions Log.
However, there are times when the skilled team are not correct about something. I’ve most often noticed this when dealing a desire to use new or updated features and I’ve been championing something less sophisticated. It most often comes about when the team doing the development are not connected to the team that will run the system during its day-to-day usage. Teams can have this “disconnected” make-up when, for example, they have been subcontracted for the purposes of the development and they are expected to hand-over to the customer’s operations team.
In this situation, I am keen for something I call, “Operations Oriented Architecture.” What I mean by this is that one of the foremost considerations is the team that will run, or operate, the final system. Now, as we discussed previously, I always try to run the design past the Operations Team to make sure that they are expecting to on-board the system and that they can get any necessary training in place and organised. Sometimes, these conversations drive changes to the architecture. “No, we can’t use this capability as the Operations Team have not been trained to support it. They would rather we use this alternate method.”
So, it can be that the Operations Team will impose restrictions on the solution. As a simple example, they might define a format for error/log messages and assign your application a unique reference number or code. This is so that their systems monitoring application can identify your application. The Development Team can sometimes balk at these “restrictions” or “impositions” but it’s your job as an architect to persuade them otherwise.
So, I’ve experienced a Type 4 team when there is a disparity between what the Project Team want to do and what the Operations Team will support. And, it’s most often that the Project Team want to make use of some fancy, new feature. After all, they’re skilled, expert and capable. For them, it is the smallest stretch to understand and make use of the new feature. But for the Operations Team, it can be a huge hill to climb: they have to send their people on training, they have to provision and deploy new hardware, and they have to update the configuration of the data centres, and so on.
Once again, a key architect skill of, “negotiate and compromise” comes to the fore. Except, this time, you use your negotiation skills to ensure that it is the Development Team that make the compromise.
Conclusion
I hope you’ve found these two articles useful.
It’s worth noting that, whilst I have addressed this at the level of the Development Team as whole, you would be quite right if you thought that these approaches can also be used for individuals. After all, whilst a team can have an identity and a character of its own, this doesn’t mean to say that all the members of the team are the same.
As a Solutions Architect, it took me some time to fully appreciate that projects do not always have the same shape and form. Each has their own unique challenges. What was easy on one will be hard on another. The enjoyment is that it is all about getting people to perform at their best. As an architect, you need to really engage with the team and genuinely understand them and their concerns in order to have them working with you instead of against you.