Dahlia Bock

16Apr/092

Delivering business value

What do we mean when we say that we are delivering business value for our client? What do our clients get at the end of the day after forking out a huge amount of money? A piece of software? A piece of software that works? A piece of software that works and does what the client wants it to do? A piece of software that works and does what the client wants it to do and brings their business to the next level?

How far are we pushing the lines that define these two words, Business Value?

I've had many discussions with my colleagues about this particular topic and it's always an interesting conversation.

When on a project and there is really nothing to do, do we sit there and create work for ourselves so that we keep billing the client for that time even though we're not really delivering any value? Or do we alert the client that work is running low and that we should possibly think about restructuring the team or taking a closer look at the project?

At the pub yesterday, I was fortunate enough to meet the great Dan North, author of BDD and all around an old-school ThoughtWorker and he puts it like this (or at least the bits that I remember).

Suppose your client wants to build a triangle.

triangle

And the following things are what's need for the triangle to be completed.

triangleandstuf

And each of those have sub-requirements and so on and so forth. Developers are usually focused on the minor detail, the day-to-day implementations, the nitty-gritty and sometimes forget the big picture and why the team was working on this particular functionality in the first place. Then someone decides to take a bird's eye view of what the team is currently doing and voila, we find that Part C of the system is actually redundant and we could deliver the product in less time and money than what was planned.

So now comes the question. What do we do? Do we approach the client with what we just found out and possibly end the project earlier, or take some people out earlier? Or do we just keep billing like nothing happened and maybe finish a day or two earlier just to look good?

What do you think are actions that define business value and what aren't?

Filed under: consulting 2 Comments
4Apr/094

Making teamwork work

I've had the privilege of being a part of many software development teams in the past 2.5 years. Part of the perks of being a consultant is that one gets the experience of being in different companies, environments, cultures, initiatives and goals. Not that I'm claiming to be an expert on how things should work, but it does help to be able to gain different perspectives in a short period of time. Here's what I think is important for teams to pay attention to, but by all means, I don't mean for these to be silver bullets, just observations.

Collective Ownership

Of everything. Of defects, of the broken build, of code refactoring, of talking to the stakeholders. Some think it's a good idea to have specialized teams that drive innovation or improvements, but I think it's the team that feels the pain of a certain problem, be it a terribly long build, or incredibly flaky tests, should be the ones that drive those improvements. They know what the problems are and will have a better idea of how to make things better. Getting an external opinion is a good thing but the responsibility of the "fixing" should belong to the team.

When something goes wrong (i.e. build breaks), we should adopt the "we should fix it" not the "it's somebody else' test, they'll fix it" attitude. Even if it wasn't my checkin that broke the build, if I can be of help, or if I know how to fix it, there's no point in waiting around and leaving the light red.

One backlog, one team. Split backlogs, split teams.

I've learned that it's really hard for a backlog to be shared across split teams that don't have visibility of the big picture and don't communicate across those imaginary-team-walls. Consider this scenario, Company Z has 3 software development teams working on their online website. The teams are seated separately, don't have much communication between them except through email, and a lot of email.

Iteration 1: Team A is given work for Feature Foo. Team B is given work for Feature Bar. And Team C is given work for Feature Baz.

Iteration 2: Team A is given some work for Feature Bar, and some for Feature Baz. Team B is given some work for Feature Foo and some for Feature Baz. Team C is working on another completely different feature. But in the previous iteration, they have identified a few issues for Feature Foo that they would like to fix but since they can't work on Feature Foo anymore, the work goes to Team B who has little to no context of what the problems were.

I think if we want to have a shared backlog and have everyone on the team familiar with the different facets of the work, we need to be ONE team and not multiple teams.

Colocation

Following the previous observation, a team has to feel like they are a team and one way to encourage that feeling is to sit the team together. It might seem like a trivial act, but it does help if it's easy for me to walk up and approach another developer instead of having to walk across the entire floor and feel like intruding another team's space. It's all about false perceptions, and it'll do us good to get rid of as many of them as possible.

Filed under: consulting, teamwork 4 Comments
10Dec/080

Bodyshopping. Is it a dirty word?

My answer?

It depends entirely on whether you originally set out to do consulting or bodyshopping. Of course, you say, doh!

But what differentiates bodyshopping organizations from consulting firms? And should there be a line that separates the two? And if so, how honest are we with the gigs that we take on? What kind of criteria do we use to evaluate them before we actually accept them? Of course we also should look at the current projects that we have and weed out the ones that we shouldn't have anything to do with.

If we claim to be a consultancy, what sets us apart from bodyshoppers? This article outlines a few areas where we can clearly draw the line. Here are some of the questions it poses, in case you don't want to read another blog entry:

Does the firm have genuine practice areas based on shared intellectual property? A consultancy should have mechanisms for capturing, sharing, and reusing intellectual property in areas of specialized expertise. These mechanisms can be embodied in people (practice leaders), processes (defined practices for knowledge-sharing), and tools (collaborative software, reusable collateral, etc.).

Check. I do love all the mailing lists/communities that we have, be it about software development, analysis, testing, travel and even gaming. Post a question/comment to it and you can almost be certain that you'll receive a reply in less than 24 hours.

Does the firm limit its consultants’ billable time for strategic purposes? A body shop bills as much of its consultants’ time as possible, all the time. In contrast, a consultancy continually invests time in improving its collective knowledge and performance.

This question is a bit harder to answer straight up. I think we try to do the best we can, but we do make decisions that might just turn around and bite us in the rear end. Consulting isn't really all about sitting in that chair and billing as many hours as possible. A lot of factors are involved in determining whether or not a consultant should be sitting there or not. Are we adding business value? (Yes, the dreaded BV). Is the client getting something out of us doing the work that we're doing? If there's really nothing to do, should we send the team back home and not waste our client's money?

Does the firm measure success in terms of profitability per engagement? This question is closely related to the last two. If a firm’s goal is simply to bill as much as possible, and its preference is to bill for time and materials, it will have no interest in the profitability of individual engagements, and will simply “run the clock” as long as it can. Conversely, if a firm uses its knowledge to deliver high-value fixed-price engagements, it will try to perform engagements as quickly and efficiently as possible, in order to maximize their profitability.

Quickly and efficiently are the key words.

Does the firm leverage new skills to build higher-level relationships? Over time, a firm builds skills engagement by engagement. It comes in to offer skill A, and picks up skill B in the process. If the firm simply adds these new skills to its list of “things we do,” it is behaving like a body shop. If the firm analyzes, consolidates and leverages these skills into higher-level client relationships, it is behaving like a consultancy.

'Nuff said.

Filed under: consulting, ThoughtWorks No Comments
   

Contact Me

Archives

Categories