Friday, January 13, 2012
We’ve used dbdeploy.net on a number of projects and have found it to be a useful tool, especially around CI environments. We recently started a Windows Azure project that uses SQL Server and discovered that DbDeploy.Net didn’t work.
There have been a few nagging issues with DbDeploy.Net as well, like the lack of support for recursive script directories, and when we looked into the code base, we discovered that it’s not really written to modern software development standards, and that getting it there would take quite a bit of work, almost as much as just rewriting it, and not much effort has gone into the original version lately.
Not wanting to shirk from a challenge, we rewrote it. 
We didn’t use any code from the original. Some of the concepts are similar, but for the most part, it’s a complete rewrite.
You can download the new version at http://dbdeploynet2.codeplex.com. There’s still plenty of work to do, but its fully functional (and unit tested) for Sql Server and Sql Azure environments, provided that your scripts are Sql Azure friendly (the scripts that Sql Server Management Studio generates are not, but easy to fix).
We look forward to your feedback.
In the New Testament in Luke 4:23 Jesus speaks of a proverb, “Physician, Heal Thyself.” What, you may ask, does this have to do with being a good developer or a good ScrumMaster? In my experience, it has quite a bit to do with it, actually, and recently, it’s had far more meaning to me than it used to have in the past. In large part, my own increased awareness has stemmed from reading Lyssa Adkins fantastic book, “Coaching Agile Teams.”
My Command and Control Roots
My dad owns several independent telephone companies in the west. Growing up was a lesson in business. I saw him grow the business from a small company of only about 500 customers to now thousands of customers in Oregon, Kansas, Utah, and Idaho. In many ways, he’s been quite successful. I’ve participated in lobbying congress, seen him work on advisory boards for independent telephone companies and watched him interact with his employees.
From there, I went to Idaho State University and received my Bachelors of Business Administration majoring in computer information systems. I even started my MBA. All of this was fantastic for me to learn and taught me quite a bit. However, it all also taught me how to be an expert at Motivation 2.0. Many also know this as Command and Control. They taught me how to be a manager. If I could hold everything in my head, and tell people exactly what to do, I was being a good manager. I was taught that employee’s weren’t to be trusted, because they’d cheat and look for ways skip on doing work. I was taught that timesheet’s in 15 minute increments so that you knew what people were doing at any given point in the day was a good thing.
I was so bad, that I even once installed a time system that used the employee’s fingerprints to clock in and out.
Ghastly, I know, and I’m deeply ashamed of that period in my life.
My Transformation
About 10 years ago, I started to realize the error of my ways. I didn’t understand it at first. My dad’s company had a consulting firm come in and do an evaluation of why they were struggling with morale, and almost refused to work with us as a company because of the results of a survey that they took of the employees. It was/is that bad. That was the catalyst for me to start learning. It’s what I needed to hear to try and become better.
I left my dad’s company and moved to a government agency, which didn’t help my understanding of command and control. I could see the problems it was causing in the teams, but still didn’t understand why. Finally, I ended up as CTO of a local firm and started running my own team. I got the chance to practice not being command and control. I read about the agile thing it was hard, but I was doing better. Not good, but better. I still didn’t get it. I thought I was Agile, was using a RUP derivative (sort of), had heard of Scrum and thought I was doing what was needed, except that the entire thing blew up in my face and I didn’t know why.
Finally, I started a new job as a project manager for Veracity Solutions. Almost immediately, things started to go downhill, similar to my last company. My response was, “O.k., I just need to control things tighter and everything will be o.k.” It wasn’t. I was scared. I didn’t want another failure.
I became very introspective and I realized that the problem wasn’t the team, wasn’t the process, wasn’t the other people. The problem was me.
I WAS THE PROBLEM!!!
I put that big and bold so that every time I see it, I can ask myself the question,
AM I STILL THE PROBLEM?
Each day, I’m striving to continue the transformation.
Heal Thyself
Recently, I read much of Lyssa’s book and realized that I still have a long way to go. I had become a master of the mechanics of Scrum, but I hadn’t yet mastered the people side of scrum. I am still using violent language, I’m still not as aware of my emotions as I’d like to be. I’ve discovered that I have a growing edge (the rough boundary between things I’ve mastered and things that I stink at) that is much closer than I want it to be.
Coaching is all about helping PEOPLE become better than they currently are. It’s not about the mechanics of some process. It’s not about process at all. It’s about becoming a better person. When I wasn’t introspective, I was trying to make people become just like me, controlling, terrible people. I had to heal myself first. I had to recognize that people around me have the same wants, needs, and desires that I have and that I can only be successful when they are also successful.
I’m still not perfect, but I am growing closer to that vision of myself that I’ve always had. I’ve gone from having the bubonic plague to having the bird flu, and I’m getting better, hopefully every day. At least I’ve never been turned into a newt. That would have been a much harder starting place.
If you want to coach others, please take the time to understand yourself and make sure you don’t have any lingering patterns that will cause you to be ineffective as a coach. For the software development world, Lyssa’s book can help. For the religious world, Christ’s example can help.
Whatever your source of inspiration, seek to make those around you better and together, we can move into a better world.
Thursday, December 29, 2011
I’ve been playing Age of Empires online now for a few months and I really like the game. I’ve always been a fan of the series, and they did an excellent job on this one as well.
They’ve made it free to play, but, of course, if you want all of the features, you’ll need to purchase a pro civilization, which I’ve done. I figure that I’d pay $50 for the game if they had released it in the traditional way, so the price was actually quite reasonable.
If you like RTS games, this is a great one to add to your collection.
Wednesday, December 28, 2011
Unity is a great IoC container. One thing that is lacking, however, is the ability to automatically resolve requests without some kind of mapping. In the past, I’ve applied attributes to classes to do that mapping or used a config file. Recently, though, I looked into extending Unity itself and discovered that it’s actually quite doable to do so.
I’ve created an “AutoResolver Strategy” that will allow Unity to take any interface request and automagically translate that into a resolution.
It assumes that you’re using the following naming pattern for your interfaces: “I” + Concrete Class Name. For example, the interface for the ConfigurationService would be IConfigurationService. A request that looked like UnityContainer.Resolve<IConfigurationService> would automatically resolve and create an instance of ConfigurationService.
To support testing, when I write code, every concrete instance has an interface, and I use dependency injection, usually constructor injection, to inject those types into the classes where they are needed. In most cases, there’s a one to one mapping in the production code between the interface and the concrete type. When writing unit tests, however, I’ll often need to mock the dependencies. I prefer Moq for this. I’ll make my mock, and then put that mock into the container that will be used to run the test with a container controlled lifetime and voila, my type has been replaced.
Basically, this gives me the best of both worlds. I can still create a mapping or use a config file, or I can autoresolve and not mess with mappings.
Here’s the class. Details on attaching it to the container are below.
// -----------------------------------------------------------------------
// <copyright file="AutoResolverStrategy.cs" company="Veracity Solutions, Inc.">
// Copyright (c) Veracity Solutions, Inc. 2011. This code is licensed under the Microsoft Public License (MS-PL). http://www.opensource.org/licenses/MS-PL.
// </copyright>
// <summary>
// Created By: Robert J. May
// </summary>
// -----------------------------------------------------------------------
namespace Veracity.Utilities.IoC
{
#region Usings
using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using Microsoft.Practices.ObjectBuilder2;
#endregion
/// <summary>
/// Represents a strategy for performing mappings when the given type isn't already mapped.
/// </summary>
public class AutoResolverStrategy : BuilderStrategy
{
#region Constants and Fields
/// <summary>
/// An object to use for locking.
/// </summary>
private static readonly object lockObject = new object();
/// <summary>
/// A cache of type mappings that we've looked up already.
/// </summary>
private static readonly Dictionary<string, Type> typeCache = new Dictionary<string, Type>();
#endregion
#region Public Methods
/// <summary>
/// Looks for an existing mapping. if not found, attempts a mapping based on the name of the resolve request.
/// </summary>
/// <param name="context"> The current context for the buildup. </param>
public override void PreBuildUp(IBuilderContext context)
{
// Note that this is the same functionality as the default BuildKeyMappingPolicy. The difference is that if we have no policy, we infer one.
var policy = context.Policies.Get<IBuildKeyMappingPolicy>(context.BuildKey);
if (policy != null)
{
context.BuildKey = policy.Map(context.BuildKey, context);
}
else
{
if (context.BuildKey.Type.IsInterface)
{
string interFaceName = context.BuildKey.Type.Name;
string interfaceNamespace = context.BuildKey.Type.Namespace;
// By convention, all of our interfaces start with I, and by convention, the concrete type that they implement is the same name without the I.
if (interFaceName.StartsWith("I"))
{
string newName = interFaceName.Substring(1, interFaceName.Length - 1);
string fullName = interfaceNamespace + "." + newName;
Type concreteType = null;
if (typeCache.ContainsKey(fullName))
{
concreteType = typeCache[fullName];
}
else
{
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
concreteType = assembly.GetType(fullName);
if (concreteType != null)
{
lock (lockObject)
{
if (!typeCache.ContainsKey(fullName))
{
typeCache.Add(fullName, concreteType);
}
}
break;
}
}
}
if (concreteType != null)
{
NamedTypeBuildKey oldKey = context.BuildKey;
NamedTypeBuildKey newBuildKey = new NamedTypeBuildKey(concreteType, null);
context.BuildKey = newBuildKey;
// look for persistant policies for this interface name
ILifetimePolicy lifetime = context.PersistentPolicies.Get<ILifetimePolicy>(oldKey);
if (lifetime != null)
{
context.PersistentPolicies.Set(lifetime, newBuildKey);
}
}
}
}
}
}
#endregion
}
}
Once you’ve got this class into place, you’ll need to create an extension that tells Unity when to use the strategy. I use this extension:
// -----------------------------------------------------------------------
// <copyright file="AutoResolverUnityExtension.cs" company="Veracity Solutions, Inc.">
// Copyright (c) Veracity Solutions, Inc. 2011. This code is licensed under the Microsoft Public License (MS-PL). http://www.opensource.org/licenses/MS-PL.
// </copyright>
// <summary>
// Created By: Robert J. May
// </summary>
// -----------------------------------------------------------------------
namespace Veracity.Utilities.IoC
{
#region Usings
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.ObjectBuilder;
#endregion
/// <summary>
/// Extends unity to automatically resolve most items based on naming convention.
/// </summary>
public class AutoResolverUnityExtension : UnityContainerExtension
{
#region Methods
/// <summary>
/// Initializes this extension.
/// </summary>
protected override void Initialize()
{
this.Context.Strategies.AddNew<AutoResolverStrategy>(UnityBuildStage.TypeMapping);
}
#endregion
}
}
Then, you’ll need to attach the extension to the container, like this:
var container = new UnityContainer();
container.AddNewExtension<AutoResolverUnityExtension>();
That’s it. Enjoy!
Monday, October 17, 2011
When teams are first introduced to Stand-Ups, many teams will dread them. Their thought is, “Oh great! Yet another meeting to consume a bunch of my time!”
I certainly understand this sentiment, and if run incorrectly, stand-ups are certainly painful and can be a waste of time. Stand-ups are fundamentally about coordination between team members and nobody else. To restate that, stand-ups are for the pigs, not the chickens!
This post is to help you understand what a good stand-up is and how best to keep people from dreading your stand-ups.
What is the Stand-Up?
Before I jump into how to make a stand-up effective, I’d like to talk more about what a stand-up is. The basic structure of the stand-up is this:
- The team gets together at a regularly schedule time
- The team meets every day at the same time
- Everyone on the team attends
- The ScrumMaster starts the meeting on time and picks the first team member to start
- The team coordinates around the questions:
- What did I do yesterday?
- What am I working on today?
- Is anything blocking me?
- The stand-up ends when everyone has had a chance to answer the questions
- After the stand-up, the ScrumMaster helps resolve any blockages identified during the stand-up
That’s it, but many teams try to make it much more complex than that. Because of that, next I’ll try to give some examples of how people fail with stand-ups.
Stand-Up Dysfunctions
I’ve seen several types of dysfunctions in my years as a ScrumMaster. They tend to be quite common, and all can be addressed. Interestingly, “long” stand-ups are usually a side effect, not a problem! With the exception of teams that are too big, I’ve never seen stand-ups go long on a regular basis for teams that are functioning well. Here are the most common issues I’ve seen in Stand-Ups.
- Using stand-ups to report to management
- Using stand-ups to solve design issues or other problems
- Monopolization of stand-ups by either pigs or chickens
- Lack of participation from certain team members
Using Stand-Ups to Report to Management
This is, by far, the most common problem with Stand-ups. Note that Management can include the ScrumMaster. A key sign of this happening is that team members are required to bring in story numbers, defect numbers, etc. to the stand-up and tell exactly what they did for each story. Team members will typically make eye contact with the manager or ScrumMaster to whom they’re reporting. When reporting like this happens, Management will often give feedback or direction during the Stand-Up. This is a great example of a Chicken talking when they shouldn’t be.
Of course, this can be tricky, since Management often controls your paycheck, but as a ScrumMaster, and as a team, you need to make sure that the team has the time to coordinate that they need. One way to solve this problem is to ask the manager in question to not come to the stand-up for a week and promise that you’ll give him detailed information about what was said. If they’re a good manager, they’ll probably go for this. This will let you reshape the stand-up to be about coordination. You’ll be able to introduce new interaction styles between the team members.
Another strategy is to ask the manager to not talk during the stand-up. In fact, if they’re willing, have them focus on their phone, like they’re dealing with important e-mail messages. Breaking eye contact has an interesting effect on people’s behavior. We expect that the people we’re talking to will look us in the eyes. By breaking eye contact and not talking, the team won’t feel like they’re talking to the manager and they’ll be more likely to make eye contact with other team members.
A third strategy is to actively look for points of coordination and call them out; give them special attention. That will start people thinking in terms of coordination and over time, they’ll start to coordinate normally.
A final strategy is to ask, after every report, “How can we help you with that?” or “Is there anything that you need to coordinate around those items with the team?”
Using Stand-Ups to Solve Design Issues
This problem also really happens frequently. Basically, a team member will bring up a problem, and the rest of the team begins to try and solve the problem. This collaboration is great, and you want to foster it in general, but not during the stand-up. My strategy here is to try and make a determination as to how long the discussion is likely to take. If you’re working with a small team, a little more talk can be tolerated. If the conversation appears to be likely to take a lot of time, simply say, “Can we take this offline?” If the team doesn’t respond well to that, interrupt and say, “This is a great discussion. We need to move on with the stand-up, so I’ll schedule a meeting where we can continue this discussion. Who’s next?”
Most teams will respond to the first well, some will require you to be more forceful, but curbing design discussions can greatly enhance your stand-ups.
Monopolizing Stand-ups
Some team members just like to hear their own voices! Sometimes, it’s because they’re really happy with what they’ve created. Other times, they just don’t know how to filter the content that they’re giving. Sometimes, they do it to try and manipulate the stand-up. Often, team members are giving details on how they did something, rather than what they did, or are treating the situation as a reporting situation, rather than a coordinating situation.
Monopolization is most typically solved by individual coaching of team members. Don’t do it in stand-up, unless you give the feedback generically at the beginning of your stand-up. Instead, talk with the team member and then do role playing. Most people are very receptive to this type of coaching and will gladly change, if that will make stand-ups shorter.
Some people are more recalcitrant and will require more work. Be patient, and if you can get the rest of the team to function well, they’ll see that they’re standing out and be pressured to change.
Another strategy is to tell everyone that they’ve got 2 (or whatever) minutes to give their stand-up. Then, bring an egg timer into the meeting and use it for each team member. When it goes off, they’ll know they’re going over. The noisy bell tends to be very effective at getting people to focus their thoughts.
Lack of Participation
This is a tough one. This usually happens when people are resisting the change to agile. I’ve actually heard, “Yesterday, I did stuff. Today, I’ll do some more stuff, and I’m not blocked.” I’ve heard that when people were joking, but I’ve also heard that from people that were serious. Without major attitude change, team members that behave this way are going to cause major disruptions on the team.
First, try approaching them and giving them coaching about how their behavior is impacting the team. If they still resist, become more blunt. If they still resist, you’ll need to get HR involved, and they may not be the right person for the team. Remember that technical ability does NOT trump the ability to work on a team except in rare cases. If they don’t change, move them out.
Conclusion
I hope that this has been useful in helping you understand how to make your stand-up more effective.
Technorati Tags:
Agile,
Scrum,
Stand-Ups
Wednesday, October 05, 2011
Recently, a co-worker was talking about how wonderful Spotify was, and I decided to give it a go. I signed up for the ultimate version, because, hey, if you’re going to try something, you should give it a fair shake. 
I’m also a Pandora One subscriber.
The end result is that I’m canceling my Spotify subscription and returning to Pandora. I’ll still use it when I really want to hear a specific song, but probably won’t spend much time in it.
You should know that 85% of the time, I’m a “Give me X genre of music” type of guy, not a “I want this song now” type of guy. I don’t like to spend time building playlists. I have better things to do.
So, here’s what I liked:
- The ability to listen to music offline.
- The ability to listen to pretty much any song I wanted.
- The price. $9.99 felt cheap.
Here’s what I didn’t like:
- Their “radio” feature is terrible!!! The Home Alone soundtrack is NOT classical.
- No ability to play music like the current version I’m playing.
- Finding similar artists works sometimes, but isn’t obvious.
- the ITunes interface. Have I mentioned how much I HATE the itunes interface?
- Manually administering my playlists. I just don’t want to spend the time, and I don’t want to listen to the same play list over and over.
So, because I usually find myself wanting to use the features in the dislikes group, I think Pandora is a better fit, even though I can’t always play a song that I want to hear when I want to hear it and even though it does repeat sometimes.
Where do you find yourself?
Wednesday, September 21, 2011
I just got back from Build 2011, and rather than spout my own theories (I’ll get to them later), I want to point you at a post by Kieth Elder.
Basically, he says that there are two modes of using data, creation and consumption. Metro is for consumption, desktop mode is for creation. I think he’s spot on!
Technorati Tags:
Windows 8,
Metro
Thursday, September 01, 2011
Is technical talent more important than Team Dynamic? I don’t think so. Read on and tell me if you agree.
The Art of the Interview
For my job, I conduct quite a few technical interviews. Rarely will I have a week go by where I’m not digging into someone’s brain trying to find out what they know and how they think. However, understanding their technical knowledge is only part of the challenge. We also must understand whether or not they code quickly, and whether or not they they will be a good fit for our teams. Technical talent is only part of the equation.
If you’re planning on an interview with Veracity, expect us to push you a bit, just to see how you react. If you react poorly, even though technically you’re outstanding, you probably will not get an offer to join us.
We’re that serious about team dynamics.
Nothing will kill a team faster than someone who is technically strong, but refuses to work with the rest of the team. The risk of failure on teams with members that refuse to comply with the team culture is very high. Ironically, often, the team members that are the hardest to work with may not be that good. We often find that people who are very difficult to work with, even though they may be considered very good by their peers, are often hiding behind that arrogance. On several different occasions, once their actual performance was evaluated, they were more mediocre than was expected.
How to be a Good Team Member
So how do you avoid being the team member that hides in the darkness and doesn’t want anyone to know what is really going on? For some, this can be tough because they feel like they’re being micromanaged. Recognizing that visibility to your team isn’t micromanagement. Having a manager tell you exactly what to do is micromanagement. Recognizing that you work with people, not machines is also important. In general, being charitable with those around you is key to wanting to work with them in a team. They’re not a distraction, they’re why you do what you do, and without them, what you do would be meaningless.
That feels ephemeral, but that’s reality. As soon as an individual recognizes that working together is the only way to produce great products for people, their behavior changes.
Compare the development team to a relay race. If one individual tries to run the entire race for the team, they’ll be left in the dust by teams that understand that with four people, they can be much faster, even if individually they’re slower than the single guy.
Change or be Left Behind
Finally, if your company has decided to adopt Scrum you have two choices: You can either change, or you can be left behind, which may mean you won’t have a job in the future. Everyone else on the team will likely see the value, and if you’re a non-contributor, even if you write really good code, they’ll likely view you as being less valuable and ask you to move on.
Change may be hard, but it beats looking for a new job, doesn’t it?
Technorati Tags:
Agile,
Team
Friday, August 19, 2011
Recently, I gave a presentation on Flow at Agile Executives. It was a fun meeting and a fun topic and lead to several realizations on my part. First, when Alistair Cockburn is in the audience, I get a bit nervous. Second, Lean and Agile aren’t incompatible, they’re complimentary. Let me explain.
The Sterility of Lean
Lean tends to think of people as nothing more than metrics. Cogs in the grand scheme of things. Little focus is placed on the human aspect of software development when talking about lean. My opinion is that lean is structured that way because lean is typically looking at widgets flowing through a system of machines to build a machine that a human uses. Cars are a great example.
Software development, instead, focuses on functionality for humans moving through humans to be displayed by machines. In other words, software development is more human than what lean typically deals with.
Agile: A Human Face on Lean
When you put Agile into the mix with lean, suddenly you have a much more human experience with software development. Instead of cold, hard, metrics, you have philosophies like Individuals and Interactions over Processes and tools. While still being concerned about the widgets (stories) flowing though, you’re also concerned about the people working those widgets. Rather than expecting robots, you’re dealing with people.
Final Thoughts
This concept is still percolating, and hopefully, I’ll have deeper thoughts around it, but for now, let me know if this resonates.
Technorati Tags:
Agile,
Lean,
Scrum
Tuesday, June 14, 2011
You’ve all seen this team, maybe you’ve even been on this team. I certainly know that I have! What kind of team, you might ask? It’s the team that is simply dysfunctional. Many reasons can exist for a team that isn’t working, and team dysfunction is a complex thing that can’t necessarily be isolated into a simple formula that will always work to make people function well on a team.
Cynefin
Recently, I attended RallyOn in Boulder with Rally Software Development. This was one of the best user conferences I have attended. We love the Rally tools for managing agile projects. One of the tracks that they had at that conference covered the Cynefin framework. Basically, Cynefin breaks problems down into four different groups: Simple, Complicated, Complex and Chaos.
Simple
Simple problems can be broken down into simple rules. If you drop a rock, it will fall. If you check in code that breaks a unit test, the build will fail. If your code style doesn’t match StyleCop, you’ll receive rules violations. These examples are all simple and easy to explain. Non-technical computer people often think of software development or music as being simply a collection of simple rules that if followed will always give the same result. As professional software developers, we know this isn’t the case. The people who think this are the ones buying the cookie cutter websites for ONLY $400, which they soon find out don’t meet any of their needs.
Complicated
The complicated domain is similar to the simple domain. Ultimately, problems can be broken down into “rules” that if followed, will yield the same results. Much scientific work falls into this category. To an expert, the operation of a jet engine is understandable and the rules associated with that operation can be written and if followed, you’ll get a working jet engine. Similarly, the rules for setting up a continuous integration environment are complicated, but can be written down and if followed or implemented by an expert, will yield an operating CI environment. More educated people will often put software development into the complicated domain. If they just document all of the rules about software development, they’ll have a successful project and it can be outsourced and everything will be great. Again, senior developers know that this is not true. Instead, software development really falls into the complex domain.
Complex
The complex domain is a domain where cause and effect can only be seen in retrospect. Much of software development and people management falls into this domain. If people could anticipate what was going to happen, they would behave differently, but since they can’t, knowing before hand what will happen is not possible. Great examples of this domain are: Life, software development, the stock market, politics, corporate fraud, and other people related examples. Software development teams fall into this category. Some resources will work very well on one project, and then fail on the next and the reason for that failure often cannot be known in advance. The rules for building a successful software team are complex.
Chaos
Chaos is a domain where there is no relationship between cause and effect. Essentially, trying to predict what will happen with any certainty is not possible. Serendipitous inventions are a great example of this and much innovative work occurs in the chaos domain. Some examples: The sun, avalanches, fires, mob behavior.
Movement in Groups
An important aspect of Cynefin is that problems can move from domain to domain. Scientists are always trying to move items that appear to be complex or chaotic into the complicated domain. If they can reduce things down to a set of rules, they have succeeded. Often, they cannot, and they fail. Things can move from Simple and Complicated as well. For example, the music industry had the sale and success of music refined to simple rules. Get a great artist, record music, put it into a store, get rich. However, peer to peer sharing moved that from the simple domain to the chaotic domain, something which the music industry has been doing everything they can to change and move it back into the simple domain. They probably will not succeed. The genie is out of the lamp, so to speak.
Cynefin and Teams
So what does this have to do with software development? Quite simply, as stated above, teams and team performance fit into the Complex domain. Sure, parts are in complicated domain and have good practices, but much of it lies firmly in the Complex domain. For example, how team members will get along or collaborate is not something that can be predicted with great accuracy in advance, and there are no rules you can use that will guarantee that the team members will get along.
Everyone on the team, and stakeholders for the project, need to recognize that team dynamics are complex and that no simple set of rules will make a team function. Agile preaches that the team needs to be self-healing and have the ability to do whatever needs to happen to make the team successful. This really is the best place to deal with complex team problems.
Too often, external managers will attempt to “fix” the problems on the team. Often, teams will feel like these managers are actually making things worse on the team. The managers are viewing the problem as complicated, and in worst case scenarios, simple and probably ARE making the problem worse.
A better solution is to put the problem in front of the team and let them figure out what is going on. Obviously, since team dynamics are a complex problem, even the strategy of putting the problem in front of the team will not always work. For example, suppose you have a team where everyone on the team thinks that things are improving and getting better and that the team is adapting. Everyone, that is, except for a single member of the team, and that single member of the team doesn’t want to bring his issues to the team. That’s a complex problem, and will need to be handled in the context of the team. Some teams, once they know that the team member feels the way that he does, will adapt and solve the problem. Some teams will require management to intervene and come up with a solution.
The most important thing to remember is that these really are complex problems that often fall into the domain of the ScrumMaster. The ScrumMaster is the person responsible for seeing that such issues are dealt with by the team or the team’s manager. Avoid jumping to early conclusions. Fixing complex problems often takes more than one attempt. Be patient and work together. What you try first may not succeed. Don’t give up! Keep trying! Eventually, the team will figure out how to make things better.
Conclusion
There’s quite a bit more to the Cynefin framework. I encourage you to take the time to understand what it can offer. Happy coding!
Technorati Tags:
Agile,
Team,
Cynefin