Agileista

Having had some time to myself recently, I've been reflecting on all the weird and wonderful implementations of Agile/Scrum that I've either; heard about, observed or been directly involved with. In doing this I've been reminded that it's all to easy to overcomplicate your agile process. In some cases even ignoring what could be considered the basics all together, without first trying them. One that I was reminded of recently is testing.

Why test?
Well it seems obvious doesn't it - we test stuff to see if it works. More than that we have tests and criteria so that we can see just how well it works and how healthy the work is. We test so that we can deliver value through quality software. So that we know what level of quality we are achieving; testing is one slice of the quality cake, a leading indicator of code and functional quality and sometimes lagging indicator of quality issues.

Creating acceptance tests also allows the Product Owner and the Team to explore the requirements and behavior together - its part of the conversation that they have when fleshing out the requirement before an iteration.

I was chatting with Eben about the current state of affairs at work. We got around to talking about the personnel and projects that my place has on the go.

The development staff consist of seven developers (one of which is the MD, one of which is me, with the obvious coding time impact for both of us) and roughly three testers.

The projects on the go, split roughly by a combination of technology and client number seven major and two minor.

If I count the two minor projects as one, and the MD's and my available development time as one developer, that's 1.125 projects, per developer!

This level of task diversity for our developers had never occurred to me before, in my defence this was largely the status quo before I even joined (bar one project or so). I wasn't exactly going to join and be able to convince the upper management to give up revenue streams.

All this is a far cry from Eben's situation of one team, aimed at one collective software goal (or at least, that's my current take on their situation).

It's obvious we need more staff, and there is an ongoing recruitment process. In the meantime the demographics lead to some interesting thoughts around the right way to structure the teams.

I may as well get around to admitting one of the Agile sins: We have a great deal of "infrastructure code". While I understand this can often be a bad thing, in this case it does serve to unify a lot of the work done in one language - indeed three of the biggest projects share exactly the same shared code base, with client-specific code on top.

Therefore I could potentially unify teams by language. This would help unify developer interaction. It would spread domain knowledge. It would create more of a team environment as the biggest team would now comprise of five 1/2 developers, plus two testers (say). I think this could be a marked improvement for the team dynamic; giving them the chance to really interact.

However, it presents a difficult question from the other side of the Agile coin: Specifically with reference to the Product Owner. How could a unified team like this serve the needs of the respective Product Owner for each client? I think the joint most important part of Agile is that it ends up (if done correctly) creating software the client wants. How then can the Scrum Master (say) use such a unified team such that each Product Owner's priorities can be folded into one Product Backlog?

It's this challenge that has prevented me from unifying the team, so I'm paying the price in terms of the greater complexity my current set-up creates.

Recently I've been looking at how to implement a balanced score card (BSC) approach to performance management, on top of our existing Scrum practices. We have decided that BSC is the best overall approach for the whole business and that we would need to find a way to integrate it with our Agile processes and metrics as these have been very successful. My first thought was that as long as we don't measure performance at an individual level we'd be ok. Wikipedia defines the BSC approach in it's introduction as:

"The key new element is focusing not only on financial outcomes but also on the human issues that drive those outcomes, so that organizations focus on the future and act in their long-term best interest. The strategic management system forces managers to focus on the important performance metrics that drive success. It balances a financial perspective with customer, process, and employee perspectives"

I posted to the Yahoo! scrumdevelopment group asking for advice and examples of how to do it. I'm happy to report that I got some great advice from people who've been there and done it. Mike Cohn advised:

"I'd then bring the company goals back to the engineering department and we put together our own version of a BSC. For the engineering group we came up with four categories that were different from Kaplan and Norton's. We then came up with strategic objectives, core outcomes,performance drivers, and critical success factors for each along the lines of traditional BSC advice"

It's encouraging to know that the great and the good of the Agile world have been there and done it. I'm now working up our own score card categories and strategic objectives in line with Mike's advice.Tom Popendiek advised me to take a look at Creating a Lean Culture by David Mann from Productivity Press, and further advised not to measure at the individual level.

Software development is a team activity, there's no getting away from it. When developing software is done in teams it stands to reason that measuring performance at the individual level can disrupt and damage the team and its output.

Technorati Tags: BSC balancedscorecard agile scrum metrics management

KPI's can destroy a teams morale and productivity if they are not carefully considered. Every organisation likes to measure the performance of their employees, some more formally than others. It's pretty easy to see what your metric is in a sales environment when deciding who is and who is not doing their best. Measure the value of their sales activity and you get a pretty good idea how well they are performing right?