Veracity solutions is a different kind of company.  When we’re interviewing candidates to become Veracity team members, we are often asked, “What’s it really like to work for Veracity?”

That’s a great question, and one we enjoy answering, because Veracity is different from most “jobs.”  Several things differentiate us from the competition:

• Veracity is not a body shop
• Veracity is very picky about the people we hire
• Veracity is very picky about the clients we service

Veracity is Not a Body Shop

If you’ve worked in technology for very long, you’ve run into several body shops.  What we call a body shop are the companies that have a position to fill, and pretty much any warm body will do to fill that position.  I worked with one body shop where I was placed with the client, and after they had my government required documentation, I didn’t hear from them again, at least not until I decided to quit, and then they decided to try and make sure that I was happy.  Basically, the relationship was that they were the ones that sent me my paycheck, and the only commitment they had to me was that single contract.

Veracity is different.  We hold monthly all hands meetings to tell our consultants what’s going on.  We’re structured in such a way that you’ll hear from a fellow Veracity person usually many times a day, but at least once a week.  We want you to identify with being a Veracity consultant, not being an employee of our client.  You’re part of something bigger than a single client.  Once you’re on board, Veracity is making a commitment to keep you working through multiple contracts.  We take a long term view with our consultants.  Some of our consultants have been working with Veracity for more than 10 years!  Compare that to the typical body shop placement of six months to a year.

Our consultants are integrated into the client’s team, not just filling a slot.

Veracity is Picky About the People We Hire

Veracity’s vetting process is tough.  We want the best, not just average.  Our senior developers and architects often come from environments where they were leading their own teams and sometimes their own divisions.  In most companies, our consultants are more senior than most of our client’s employees.  This is a big deal, because at Veracity, we’re not just Contractors, we’re Consultants.  Not only can we write the code given to us to write, but we can help guide teams on how to write better software.  We consistently coach teams on Agile adoption, architectural guidelines and principles, and even on how to better structure their businesses for building successful products.  We’re involved in Mergers and Acquisitions and other high level activities that you wouldn’t expect from mere consultants.

That said, our consultants aren’t just about technical excellence.  In fact, if all you have is technical excellence, you probably won’t succeed at Veracity.  Our people are also strong communicators and know how to mentor our client’s employees to become even better and stronger.  In fact, our goal with each client is to help their teams become stronger and more self-sufficient so that when we leave, it’s merely a velocity decrease, not a knowledge decrease.  Mentoring team members is expected of all of our consultants.  We always strive to leave the teams better than they were when we started, and our consultants are the key to making that happen.

Not everyone has these skills.  Sadly, the “average” developer or QA specialist doesn’t have these skills.  Getting through our vetting process is hard, but its worth it.

Veracity is Picky about the Clients We Service

Not only are we picky about our consultants, we’re also picky about our clients.  Most of Veracity’s leadership worked at many different companies before Veracity.  We’ve all experienced the horrible environments that some companies subject their IT staff to.  We think that the welfare of our consultants is very important.  We strongly believe in 40 hour work weeks, agile environments, and environments where the quality of our people is truly appreciated.  Because of that, we will actively turn down potential clients and leads that don’t see software development as a fundamental part of what they do.  If they view development as a cost center or as something where one resource can easily be replaced with another, they’re probably not be a good fit for Veracity.  If they are a “sweat shop” environment and require people to work long hours to meet unrealistic expectations, they’re probably not a good fit for Veracity.

We’re big fans of Agile (usually Scrum) because we believe that it makes a better environment for all of the team members.  We think it produces a better product, responds better to customer needs, and is the right way to do software development.  Because of this, if a client is against Agile, we view that as a red flag, warning us to stay away.

We don’t look for perfect clients, we look for clients that share values that we have.  We want clients where making a mistake is tolerated, expected, and used as a way to learn and improve performance.  We seek clients where our consultants can truly consult and be part of a team building something great.

Conclusion

Our corporate tagline is “Building Great Teams, Great Products, and Great Companies.” We do that by hiring excellent people, working on projects that matter, and working with clients that have similar goals. I love how that comes together to define who we are.  Many companies say that they do the same, but we’ve found that most don’t live up to their own hype. At Veracity, it’s not just hype, it’s what makes us different.  These principles are at the core of who we are.

Are we perfect?  No, but we’re trying to be the best we can.  We’ll make mistakes, but expect us to be open and honest (Veracity = Truthfulness) about them, admit them, and then do everything we can to make them right.

If you’re interested in working somewhere different and think you have what it takes, we encourage you to apply at jobs@veracitysolutions.com

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.

On Saturday December 3^rd, 2011, Veracity team members and their families gathered together at Harmons for our Veracity Service Day. Veracity had collected donations  from team members to purchase food for the Utah Food Bank with a pledge of matching all donations. This ultimate shopping experience began at 9am and each family was given a budget of $500. It was a family affair as we all grabbed carts and began filling them till they were overflowing with all kinds of non-perishable food and other items while Michael made arrangements with the manager for special deals on food from the back.

Galen and Noah… “Big donation coming through!”

Kao and his wife

Scott and his daughter

After we had each reached our budget, we parked the carts at the front of the store for checkout, with Harmons dedicating two checkout stands just for the Veracity carts. Even the little kids helped out as we helped to open paper bags for the food and became quite the skilled baggers! On more than one occasion, a cash register decided we had so much food that it reached the transaction limit, so we had to end that transaction and start a new one. It was such a rewarding experience to see all of the carts lined up outside waiting to be loaded into our vehicles. We knew right away that this was going to help a lot of families this holiday season.

Once the food was loaded into our cars and SUVs, we caravanned to the Utah Food Bank to drop off our donations and get a final weight so that we could pass the information along to Jiffy Lube to match. We parked our vehicles, formed a line, and started passing in the food, where it was loaded into giant boxes on pallets.

The pallets were then weighed and calculated to a total of 3,261 lbs. That means that with a matched donation from Jiffy Lube, Veracity donated 6,522 lbs. to the Utah Food Bank this year! With your help, we more than doubled our donation last year. We are so grateful for the generosity of everyone who donated and participated in this years’ Service Day. You have made this Veracity’s best year yet!

(posted by Scott on behalf of Simone Headden)

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:

1. The team gets together at a regularly schedule time
2. The team meets every day at the same time
3. Everyone on the team attends
4. The ScrumMaster starts the meeting on time and picks the first team member to start
5. The team coordinates around the questions:
   1. What did I do yesterday?
   2. What am I working on today?
   3. Is anything blocking me?
6. The stand-up ends when everyone has had a chance to answer the questions
7. 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.

1. Using stand-ups to report to management
2. Using stand-ups to solve design issues or other problems
3. Monopolization of stand-ups by either pigs or chickens
4. 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.

Summary

• Build was focused on consumer apps, not line of business apps
• The future of XAML is very bright
• Metro isn’t for all apps, but is focused on touch based apps
• Your XAML investments (Silverlight/WPF) are still good investments
• You don’t need to change your XAML direction; stay in Silverlight for now
• Where possible, evaluate how touch fits into your product lines
• Significant advancements are being made to .NET
• Silverlight is stable and mature and entering maintenance mode

Build Recap

What a week. Microsoft certainly did everything they could to excite people around Windows 8 and the new metro experience. If you aren’t familiar with what was announced, we encourage you to visit http://www.buildwindows.com and watch the keynote speeches. Microsoft is really emphasizing the “Fast and Fluid” concept, and the metro experience shows it. The keynotes also highlighted that Metro is a “Touch First” experience. This means that Metro apps will be designed first for using them by touch, and second for using them with a mouse and keyboard. A major announcement was WinRT (the Windows Runtime) and the status of XAML. XAML has become a first class citizen and is now part of the Windows infrastructure. We’ve been concerned about the longevity of XAML, but with its inclusion in WinRT, the future looks bright for XAML.

Microsoft is advancing into the tablet market to compete effectively with Apple and Google. Though Windows Tablets are initially focused on the consumer market, they have mid-range implications for corporate and enterprise customers. Product management teams should earnestly consider how tablet and touch technologies and Metro user experiences complement existing product lines and/or create new product opportunities. Future users of applications will likely expect touch first experiences, so you need to be ready for this shift in user behavior.

The sessions were also very enlightening. Much advancement is being made with asynchronous development, the cloud, and with the languages of .NET. In particular, the Rosyln research project is very interesting for its ability to provide runtime access to compiler services without requiring many of the difficult steps that were required previously.

We think that an important aspect of the show was that it was primarily focused on consumer software and devices, which is great for companies making consumer software, but not so great for companies building line of business applications. Microsoft didn’t spend much time talking about the corporate strategy. In talking with Microsoft employees, the general feel is that Microsoft hasn’t defined its future corporate strategy. We expect future meetings and conferences to discuss what Metro and WinRT mean for line of business applications. As Veracity continues its partnership with Microsoft and its technical leaders, our relationships with leaders of the four XAML teams (WinRT, WPF, Silverlight and Windows Phone) will continue to provide valuable insights for our customers.

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?

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.

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!

He who fails to plan, plans to fail. – unknown

In many ways, one of the most dreaded tasks of every iteration is the Sprint Planning Meeting.  This meeting is a very important meeting, but many, many things can go wrong and make this meeting a very long and very painful experience.  However, this meeting is critical to the success of the team.  If the team doesn’t know what they’re doing at the beginning of the iteration, how can they commit to getting the work done?

To hopefully help ease the pain of the Sprint Planning Meeting, here are a few suggestions.

Identify Stories and Priorities Before The Meeting

This step is critical and often missed, especially on teams with dysfunctional product owners.  Before the start of sprint planning, product owners and designers should have a good idea of what the story is, the rules around the story, and at least some basic paper prototypes for the story.  Testers should probably have fleshed out some acceptance criteria for the stories. Without this information, the team will be unable to plan the implementation of the story with any effectiveness.  Note that this implies that the team members responsible for this information have been working on the story before the start of the iteration.  We find that when designers, product owners, and testers are a single iteration ahead of the development team, the actual implementation is much smoother.  These team members should have a few more stories prepared than actually can be completed, just in case the team needs to throw a story out during discovery.

Ideally, the product owner will have an entire release backlog of prioritized stories.  The stories should be prioritized based on the ROI for the company, which requires serious preparation and thought.  Only the upcoming sprint’s stories should be fleshed out.  Future stories should be left until the future.

The Product Owner should have everything they need ready for the meeting so that when questions are asked, they can quickly give answers and not resort to designing during the planning meeting.

No Toys

This rule annoys many people when I first put it out.  Most people are used to zoning out and not focusing on the meeting by using toys during the meeting.  Toys are generally electronic distractions such as cell phones, laptops, ipads, ipods, and any other device that would prevent a team member from focusing during the meeting.

Some team members may need toys to plan effectively, for example, the team may need to know testing details from an electronic source or the product owner may want to refer to electronic documents.  If they start to use those toys to zone out, then they should be reminded that they need to focus on the meeting, not on their toys.  If everyone focuses, planning goes better and team members are better able to perform in the iteration.

Get Team Availability at the Start

Once your environment is set up, the very next step is to get the availability of the team. I’ve seen teams plan all of the stories that have been assigned to an iteration, irrespective of the amount of time actually available and then seen them move out more than half of those stories.  That’s a waste of time!  If you get the teams availability first, you can plan until the time is completely used up and then you know you are done and won’t waste time planning stories that have no chance of being completed. 

You may have a product owner that resists this method of planning because they want all of the stories they assigned to the iteration completed that iteration.  That’s too bad for him.  The team cannot work more hours than are available, and part of Scrum is recognizing that the team has a velocity and that the company needs to deal with the reality of that velocity.

Don’t Assign Tasks During Planning

Developers will often resist this suggestion.  After all, Joe is good at design and Jim is good at the back end work, so why not assign the tasks to them at the start?  The practical reason is that if all of the tasks are assigned, Jim may be over allocated and become a blocking factor in the iteration.  Additionally, team members may be working on stories that are a lower value to the company, simply because they didn’t have any tasks assigned to them on earlier iterations.  The team is responsible for the entire iteration.  Note that I didn’t say that a single team member is responsible.  Therefore, my suggestion is that unless there are very specific tasks that only one member CAN do, the tasks should not be assigned.  While Joe may not be as good as Jim and may take twice as long, the net effect of parallel execution may still cause the task to be completed before Jim had a chance to get to the task.

Instead of assigning tasks, the team should start at the top story and work their way down.  Each story should be completed in turn.  On healthy teams, a variety of team members will have tasks in a given story.  On unhealthy teams, individuals will be responsible for entire stories.

Another practical reason for this suggestion is that as team members touch all parts of the application, the tribal knowledge of the team members becomes greater so the loss of any individual team member lessens the impact on the organization and on the team.

Include Uncertainty

Many teams struggle to estimate accurately.  Some teams even have great pressure from product owners to estimate low, rather than accurately.  On one team I was working on, if anyone gave an estimate that was higher than what the product owner though was reasonable, the product owner would make loud noises and comments like “Oh, come on!  That can’t take that long!”  The team member would then revise down the estimate and the team would miss the iteration.  This happened for more than 6 months before finally, I devised a mechanism for dealing with the situation.  I call it the Uncertainty task.  Basically, for each task, an estimate is given.  If the team is unsure about how long it will take, or if a complication could modify the time it will take, the team adds some uncertainty time into the Uncertainty task.  For example, say I’m implementing my own high powered socket server.  I’m pretty sure that the TCP/IP communication will take about 3 hours to implement.  However, if I can’t find a third party component to handle that communication, it may take 6 hours to complete.  The 3 hour difference would be uncertainty and would be put into the Uncertainty task.

This gives the team a lot of flexibility. They can account for uncertainty and not commit to unrealistic estimates that may come back to bite them at the end of the iteration.

Avoid Design During Planning

This suggestion is difficult.  Some design will usually be needed during planning, especially as the developers try to come up with tasks and discover areas that the product owner and designers may have missed.  The key to success is identifying when you’re designing the story and when you’re trying to do discovery on the story.  In general, if you’ve spent 15 minutes talking about a story and have added few, if any, tasks, you’re probably designing.  If you’re talking about how you will implement the story (i.e. I’ll use Entity Framework, and the database design will need to look like X), rather than talking about the tasks needed to accomplish the story, you’re designing.  You don’t need to know how you’re going to complete the tasks, only that the tasks need to be completed.

If you find that you can’t plan the story without significant discovery/design during planning, throw the story out and move on and give the product owner additional time to flesh out the story.

Give an Estimate and Discuss as Needed

Often, teams will fall into the trap of trying to get perfect understanding about a problem before giving an estimate.  I’ve seen teams spend more than an hour talking about a problem and then deducing that the actual task would only take 30 minutes!  That’s a waste of everyone’s time.  Because of that, I recommend that after a task has been identified, someone on the team throws out a guess as to how long they think it’ll take.  If anyone on the team disagrees, THEN have some discussion about why they disagree.  If the disagreement is small (a hour or so), instead of trying to get very precise numbers, add the difference to uncertainty and move on.  Teams that operate this way can complete their planning and have reasonable estimates in a few hours.  Teams that need to get everything exact often will take a full day or more.

Split Up Planning

A long planning meeting is very difficult.  By the end of the meeting, quality goes down, people don’t pay as much attention, and you end up with more poorly planned stories that took longer to plan.  An easy way to solve this problem is to break planning up.  Instead of a monster planning meeting, schedule an additional meeting during the sprint before the iteration that you’re going to commit to for planning.  For example, if you normally start your sprints on a Monday, and your sprints are two weeks in length, the Monday before the start of the iteration would be a planning, and then the Monday of the start of the iteration would be a planning.  You wouldn’t commit until after the second planning.  You shouldn’t start the iteration without committing and since you can’t commit without planning, you should not plan for the current iteration after the start of the iteration.

Have a Retrospective about Planning

Finally, evaluate your planning process on a regular basis.  Talk about what is working in planning and what is not and then make changes to make your planning more effective.  Over time, the team will become better at planning and things that were useful early on may not be necessary later on.  Only your team knows what works well.  I recommend being stricter in the beginning for a short period of time (at least one release) and then adapting after you have some experience under your belt.

Conclusion

By following these few suggestions, sprint planning can be easier and more fun, and you can completed it more rapidly.  Effective planning will help your team be more successful and the artifacts created can help your team become more predictable as well.

Leadership

Veracity consultants are an interesting group of people. We have some of the best and brightest people working to help our customers deliver great products to their customers.

While there are a lot of consulting shops in the industry, most are not like Veracity Solutions. Many shops simply want to put a body into a chair. They offer cheap hourly full time employee replacements (contractors) instead of people that can actually help their business be successful.

Veracity, on the other hand, really tries to fill the consultant role. Yes, we can pound out code like nobody else, but we can do more than just that, we can help them write the right code for their business. We can help them understand how their teams should function. Ultimately, our goal is that when we leave the team, we leave them in a better place than they were.

Knowing how to help their teams requires a skill that we try to make sure that we all have, and that is the skill of leadership. Almost any Veracity consultant could lead the teams on which they are placed. You really are that good!

Servant Leadership

Since we often have a leadership role with our clients, knowing the best way to lead is important. Many different styles of leadership exist. Some work better than others. The type of leadership that we recommend is called Servant Leadership.

Agile teaches that the team should be self-forming and should have the authority and responsibility to make whatever decisions are necessary to successfully complete the iteration. Note that this philosophy doesn’t have a “leader” that is directing the work of the team. This includes the ScrumMaster. The ScrumMaster’s role is not to direct the team and tell them how to function. The ScrumMaster’s role is to get obstacles out of the way and help the team function. This is different from traditional management.

Perhaps some examples will help to explain.

The Early Years

I have a degree in Business Management. That means, that I’m supposed to manage people, and every management course I took focused on strategies for “managing” people. Few focused on strategies for leading people and exactly none focused on strategies for serving people.

In many ways, my management degree left me unprepared to lead teams of developers. As a result, I learned the hard way. Some of my early blunders are embarrassing, and quite funny.

The first that I’ll relate was managing a team of about 75 customer service representatives. I was young and just out of school. We experienced a significant amount of growth and needed a time tracking tool to track the time of these hourly employees. Being a geek, I ran out and researched this nifty device that would track time AND included a fingerprint reader! They absolutely had to be present to punch their time card, since they’d have to swipe their finger to do it. Biometric security at its finest. Who cares if it takes them 15 minutes to get signed in, spreads diseases, and tells them that we think they’re criminals! Ouch. Those poor people. I’m sure morale was terrible.

Now that I’m older and more mature, I look back on that experience and see that I was being a manager, not a leader and especially not a servant leader. A servant leader would have instead sought ways to track their time and meet the goal while placing as little burden as possible upon the employees. I could have found a system that was tied to their login or tied to their phone, or any number of other options. I should have been helping them accurately input their time so they didn’t have to worry about it.

The second experience was from my early days of Scrum. We were working with a client and were at least using stories, but I didn’t understand the concept of team ownership of those stories. Because of that, planning was mostly me throwing out tasks and then assigning those tasks to team members. Our team was only as good as I was, which limited its success.

I’ve learned quite a bit since those days. I now know that a servant leader understands that their goal is to help the team plan, but leave the planning up to the team. Instead of me coming up with all of the tasks, I should have helped, encouraged, and prodded the team, where necessary, to come up with the tasks and then helped them determine how they were going to accomplish those tasks.

A servant leader rarely will assign tasks to team members. A servant leader will often be the first person to volunteer for the least desirable tasks. Servant leaders lead by example.

Conclusion

I hope that you will examine your leadership style. If you find yourself telling people what to do, your management style is probably dated and needs to change. If you have a list of things that need to be done, don’t tell people to do them. Instead, let team members volunteer for the individual tasks. If you trust them, they will trust you and will not want to let you down.