I am back...

My apologies for letting this blog lie dormant for over 3 months. I was up to my elbows in work and university at night. My subject was "Strategic Leadership for Innovation". Very interesting! But lots of work. The good news is that it gave me lots of new material. I'll try and post a bit more often over the coming months.

Why Human Multitasking is Problematic

The Siren Song of Multitasking

Using Business Analysts with Scrum

There has been increasing attention paid to the role of Business Analysts in the Scrum development methodology. Feedback from some early adopters of agile methodologies seemed to suggest that the role of BAs had been made redundant via the use of short feedback cycles. Certainly I can find no mention of BAs in some of the seminal agile books like "Extreme Programming" and "Agile Project Management with Scrum".

The death of Business Analysts has been greatly exaggerated. A quick google will show you that BAs with agile experience are in great demand.

Let me tell you how we use BAs with Scrum. Usually the Scrum Master meets with the Product Owner before the sprint planning meeting to "groom" the product backlog. We push that meeting back to a week or more prior to the planning meeting (we are on month long sprints) and send the BA to meet the PO.

In addition to grooming the backlog, the BA digs into each of the user stories in more detail. He then goes away and prepares a specification based on the priorities identified. This spec is usually complete by the time the sprint planning meeting occurs, and is used for estimating and after that as a development spec. Toward the end of the sprint, the BA then tests the system against the requirements.

You've probably got some questions -

• How big are these sprint specs? We have four developers in one of my teams, our sprints are a month long, and the sprint spec is usually about 20 pages long.
• What's in the specs? We make use of Gherkin, and also screen prototypes done in Balsamiq. We also do acceptance criteria for each user story.
• What do programmers think of the specs? They LOVE having specs. Rather than having to ring up the PO all the time, they can just get on with the coding. When a BA is on holidays and there are no specs available, they are not happy.
• Have the specs improved the quality of what you are building? I think having specs, acceptance criteria and tests against those criteria have certainly reduced the number of bugs in the code, and stopped us going down dead ends.

Ok, you say, so it's been effective. But you might have some other objections -

• Doesn't writing specs violate a cardinal agile principle? The Agile Manifesto says that we should value working code over documentation. I agree! However, it doesn't say we should have *no* documentation, just that we shouldn't create these huge specs and spend all our time trying to keep them up to date. We don't do that. We create a spec per sprint, and it's really a disposable document, forgotten once the code has been written.
• Aren't you just describing the role of the Scrum Master? The Scrum Master certainly does requirements analysis in classic Scrum. However, I don't believe it is usually to the detail and quality that a professional BA will give you. I've also found that Scrum Masters are usually far too busy to spend time doing the requirements in detail.
• Don't you lose agility? I don't see why you would. The specs simply reflect the priorities the PO has set - they don't change them. And the specs are a guide, not a shackle - if something doesn't work out when it comes time to code, there is no problem with trying something different.

I hope I've shown you how useful Business Analysts can be on a Scrum project. I couldn't live without them now.

The Care and Feeding of Software Engineers

I've only just skimmed this article, but from what I read, it has a lot of useful insights. (click here)

Punctuality and Respect

The following Dilbert cartoon rings true - click here.

Sadly, I've seen this attitude in many companies, especially a couple of large mutli-nationals I used to work for. Managers were perpetually late to team meetings. As the Dilbert cartoon suggests, this really shows a lack of respect for your subordinates, the message being that their time is not valuable.

As a manager, you should be competent at organising your time. Make the effort to be punctual with your staff - they will appreciate the respect.

Autonomy and Motivation

Daniel Pink has identified autonomy as one of the key intrinsic motivators. That is, if we have a complex, creative task to perform (like software development), we enjoy it more if we are given the freedom to make real decisions. From long experience, I have observed that programmers value autonomy almost above anything else. Programming is fundamentally problem-solving - if you put too many restrictions into the process, you rob it of much of it's joy.

So how do we establish autonomy in the workplace? Kenneth Thomas identifies the following building blocks -

1. Delegated authority - the right to make decisions
2. Trust - confidence in an individual's self-management
3. Security - no fear of punishment for experimentation and honest mistakes
4. A clear purpose - an understanding of what one is trying to accomplish
5. Information - access to relevant facts and sources

These are pretty clear, I think. The opposite approach is known as "micro-management", and it is loathed by programmers. I've known managers who insist on personally inspecting every line of code written by their subordinates. This sort of thing simply destroys motivation.

Does this mean we are left with a free-for-all? Not at all - everyone understands there needs to be boundaries, and these are often captured in standards and practices documents. Ideally these should be negotiated up front, and the relevants parties should "buy in" to whatever boundaries have been established. Then, so long as the boundaries are respected, the programmer ought to have autonomy.

One of the reasons I like Scrum is because it establishes and protects programmer autonomy. In a proper Scrum, the development team must agree to the amount of work to be done in a sprint. Furthermore, once the sprint has started, it is up to the team to implement the functionality as they see fit - neither the Scrum Master nor the Product Owner are permitted to interfere. And teams are highly motivated to complete a piece of work that they voluntarily agreed to - much more so than a schedule that is imposed by fiat.

Granting autonomy is not hard for "Big Picture" people - it is much more difficult, I think, for detail people, who want to know and control every little thing. If you are guilty of micro-management, I'd encourage you to change your course - the impact on motivation will be spectacular.

Seven Roles of a Leader

These are quoted from Kimball Fisher's excellent book, Leading Self-Directed Work Teams -

1. The leader unleashes energy and enthusiasm by creating a vision that others find inspiring and motivating.

2. The results catalyst helps the team improve performance, gets good results without resorting to authoritarian methods, manages people by principle rather than by policy, and uses boundaries rather than directives.

3. The facilitator brings together the necessary tools, information and resources for the team to get the job done, and facilitates group efforts.

4. The barrier buster opens doors and runs interference for the team, challenges the status quo, and breaks down artificial barriers to the teams performance.

5. The business analyst understands the big picture, is able to translate changes in the business environment into opportunities for the organisation, and acts as an advocate for the customer.

6. The coach teachers others and helps them develop their potential, maintains an appropriate authority balance, and ensures accountability in others.

7. The living example serves as a role model for others by "walking the talk" and demonstrating the desired behaviours of team members and leaders.