Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Internal Customer Service and What I’m Doing to Be Agile

I’ve been spending a lot of time in the last six months retreading myself in Agile as we are rolling out Agile to several organizations. During this process, we’ve talked with our internal developers a lot about the Agile Manifesto and the Principles Behind the Manifesto. As we share these principle with our team, I’m finding it very healthy for myself to go back to these basics which are so easily forgotten or inadvertently pushed aside.

As a refresher The Agile Manifesto reads:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

And, what I believe to be the most important principle from the 12 principles behind the manifesto:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

In looking back in my nearly ~10 years of “being Agile” I’m ashamed to admit that I’ve never really sought out the customer to find out how I, or my team, was doing. I’ve likely asked casually how things are going in an ad hoc fashion, but I’ve never taken deliberate and disciplined steps to checking in with my customers.

In our current Agile adoption we changed that, and my encouragement is that you to consider doing the same if you’ve lost sight of your customer. We built a simple survey (takes only 90 seconds to fill it out) to inquire how we’re doing. We initially circulated the questionnaire on a monthly basis and then backed off to quarterly which gives us a regular cadence on getting empirical feedback.

Here are the questions we ask to ~20 key stakeholders of our development process and software:

Q1. How eager were the representatives of our department to help?
Q2. When discussing project requirements, how satisfied are you with the interaction with the team?
Q3. How satisfied are you with the communication of project status during the entire process?
Q4. Would you say that our team solved your problem or answered your question quickly, slowly, or neither?
Q5. How well did the output from the team meet your business objectives/needs?
Q6. How knowledgeable did our team representative(s) seem to you?
Q7. How clear was the information that our representative provided to you?
Q8. Overall, are you satisfied with the service you received, dissatisfied with our service, or neither satisfied nor dissatisfied?

Open Ended Questions

Q9 (Optional): What’s the most recent example of how we have exceeded your expectations on this project?
Q10 (Optional): Is there a recent example where we have not met your expectations?
Q11 (Optional): What is one thing none of devs do but wish we would?
Q12 (Optional): Additional comments?

When I push these surveys out I anxiously await the results to see how we’re doing.I review each one personally. I’ll be frank, it has been a mixed bag of emotions. Sometimes (read:often) what I read isn’t easy to read; while we have drastically improved internal customer service, our stakeholders ask for more (and rightly so).

In the past, I may have been too quick to use the Agile manifesto and underlying principles selfishly for my own gain when it suits me and when it plays to my advantage in furthering my cause. As of late, I’m challenging myself and the team to continue to refer to the manifesto and it’s underlying state-of-mind/ethos, especially as it relates to the human side of development (customer satisfaction, changing requirements, working together, and communication).

As you head into the week, consider your own situation, might you be able to adhere to the Agile principles just a bit better? The survey is what is working for us and it may or may not work for you. If you desire, please feel free to copy and use the questions we’ve used (we picked them very carefully).

I’m curious…what do you think? How could/should we be more “Agile”. Please post your thoughts, suggestions, and results of your own survey’s in the comments below.

Posted in Agile | Leave a comment

Quick Hit: What Do Your Customers Really Want?

The famous Harvard Business School Professor Theodore Levitt famously reminded:

“People don’t want to buy a quarter-inch drill. They want to buy a quarter-inch hole!”

He’s right. Similarly, your customers, whether other developers, other departments, or external customers don’t want to buy Agile, scrum, lean, test-driven development, domain driven development, continuous integration, C#, VB, Node, JavaScript, Roslyn, or any technology/language/tool/method. They want to buy what it enables, the solution, the hole.

 

Posted in Quick Hits | 2 Comments

Agile Software Teams, a Basketball Analogy

basketball-teamWhat makes a great basketball team? Having a great scorer? Having a great defensive presence? Both? Neither?

What makes a great software team?

The other day I was explaining team interactions and dynamics in an agile culture. Being that this was right after the NBA Finals I used the analogy of a basketball team.

In basketball, there is more to building a great team than simply hiring offensive scorers, it’s about creating balance on both ends of the floor and how well the players play together. In many respects, software is very similar.

In basketball it’s not uncommon to label players; Carmelo Anthony is an offensively-minded player. Joakim Noah is a defensive player. Software is similar in that we often have areas of expertise that often lead to labels,  “he’s a database guy”, “she’s a UI/UX person”, or “she’s a javascript guru”. However while players have specialties all players must be “good enough” at the other areas to not create a deficiency in the team.

It would be ludicrous to think that whenever the ball passes mid-court you give it to “the scorer” and expect him to score. Just as ludicrous is the idea that a single person guards the ball on the defensive end, even if that person is the best defensive player.

In 2013-2014 NBA season, the league’s best scorer was Oklahoma City’s Kevin Durant (29.6 points per game) however Oklahoma City averaged over 100 points per game. On average, the best scorer in the league, didn’t score 1/3 of his team’s points!

Why then, do we as software teams often find ourselves defining our work not as what’s effective for the team (shipping software) and instead labeling by functional area? We say, “that’s a designer task” or “that’s for the DBA to do”.

Great basketball teams:

  • Optimize to win games.
  • Win at all costs.
  • Adjust to the team they face.
  • Have players who play well with their teammates.
  • Put team successes ahead of personal accomplishment.
  • Have players who are great at their position.

The point is that having the best offensive or defensive player doesn’t necessarily win championships. What ultimately wins is great team play and adjustment to the team you’re playing. If the key scorer is getting double-teamed, someone else has to step up. If you’re DBA is tackling some gnarly “DBA stuff” and some other “DBA work” needs to get done, perhaps you need to step up and help out. Sure, you aren’t as good of a DBA as your DBA, but last I checked it doesn’t matter who scores the points at the end of the game – two points from Hasheem Thabeet counts the same as two points from Kevin Durant.

Software is the same way, great software teams optimize to deliver software, regardless of who did what tasks. Yes, specialization is important, however it’s the use of the specialization in concert with others on the team that leads to winning.

Whether you’re the scorer on the team, the backup person, or the defensive specialist, I would encourage you to not only learn your position well, but be well rounded enough to help your team win in any situation.

Posted in Agile | Tagged , | 4 Comments