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...

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...

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,...

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...

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...

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...

The March meeting of Agile Executives was great!  We've recorded it and you can listen to it here.  We hope to have you join us for the next meeting in April.

We recently returned from the HIMMS conference in Orlando.  While there, we spent a significant amount of time networking with CIO's, CTO's VP's of Dev and other healthcare IT leaders.

A recurring theme that we heard was, "We're implementing/starting/using Agile and we need help!"  Most of the companies we talked to are in some state of Agile adoption.

To me, this is very gratifying.  Companies are starting to realize that Agile can help their organizations be more efficient and effective at developing software.

I also think that Agile Executives is starting at the right time.  As a community, we can help the individuals leading development teams in these organizations become better at Scrum.

Over the years, I have experienced many different styles of software development. In the early days, most of the development was Waterfall development. In the last few years, I’ve become an advocate of Scrum.

As I talked about last month, many people have misconceptions about what Scrum really is. The reason why we do Scrum at Veracity is because of the difference it makes in the life of the team doing Scrum. Software is for people, and happy motivated people will build better software.

However, not all executives understand Scrum and how to get the information from development teams that use Scrum. I think that these executives need a support system for managing Agile teams.

Historical Software Management When Henry Ford pioneered the assembly line, I doubt he realized the impact he’d have on Management through the ages. Historically, management was about managing the process of building things. The people were just cogs in that process. Like all cogs, they were replaceable.

Unfortunately,...

A very common task in Agile Environments is prioritization.  Teams that are functioning well will prioritize new features, old features, the backlog, and any other source of stories for the team, and they’ll do it regularly.

Not all teams are good at prioritizing according to the real return on investment that building stories will yield to the company.  This is unfortunate.  Too often, teams end up building features that are less valuable, and everyone seems to know it except perhaps the product owner!  Most features built into software are never even used.  Clearly, not much return for features that go unused.

So how does a company avoid building features that add little value to the company?  This is a tough question to answer, but usually, this prioritization starts at the top with the executives of the company.  After all, they’re responsible for the overall vision of the company.

Here’s...