This talk provides a short introduction to social complexity theory, especially the Cynefin multi-ontological sense-making framework, and illustrates its application to agile software development.

I did my Certified Scrum Master training with Joseph Pelrine.  He’s a very interesting and experienced practitioner.  He comes out of a smalltalk background (we can forgive that   ) and so understands developers and development very well.  He offers a wealth of experience and is worth listening to, I recommend getting to this talk if you possibly can.

We’ll have most of the big holes plugged soon enough with our new staff that have come on board or will be soon. The issue I’m facing is, I think, that the demand for immediate reaction is huge in our environment. this means that a lot of people carry a lot of stress.

To manage this we’re trying several approaches simultaneously.

1. We’re asking the business not to escalate anything to the senior developers without first going through myself or one of the development managers.
2. We’re currently running one daily Scrum with every developer attending, and project managers attending two to three times a week.
3. All work allocation has to come through one of the development managers before it reaches the team, ensuring it is prioritised and allocated effectively
4. All work is now assigned through Mantis, the issue tracking software we use
5. Mantis reports are generated twice a week and emailed to all team members listing out all their tasks, and the Mantis emails have been turned off to reduce the disruptive effect
6. We have recently been tracking our Sprints against Mantis more than the Excel-based backlog. This makes keeping things in sync easier but visualising them much more difficult

The Scrum Methodology has this to say about the daily Scrum:

Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum. During the meeting, the team explains what it has accomplished since the last meeting, what it is going to do before the next meeting, and what obstacles are in its way 

In our team meeting we go twice round the team. Once going through progress of assigned tasks by project, once reviewing each team member’s immediate activity. It’s still basically the same three questions, just approached in a slightly different way. This seems to work be keeping the focus on the projects and their priority.

Once our workload stabilises I intend breaking the team down into two or three teams each holding its own daily scrum. We’ll then have a Scrum of Scrums, involving each teams Development Manager / Scrum master and the Account / Project Managers. This feels like along way away.

When I was working at Fairfax Digital we had management and team buy-in and we managed to go from barely managed Waterfall project management to Scrum in one hit. And the nett effect was we delivered a massive project spectacularly well. I think the reason why I am having more of a hard time implementing Scrum this time is because of the sheer volume of projects and number of work items that need to be executed.

I’d be very intersted to hear other people’s experiences.

Our deliverables for this sprint are absolute project milestones – we will be delivering the core components of the project – and so far on time too.

Once we come out the other end of this sprint we’ll be doing a sprint focused on a portion of client-side development, reporting, testing and documentation. Sprint 5 will have to be focused on mopping up.

Because of the sterling job the team has done, the quality of the code base is awesome. Refactoring is done as a matter of course, as necessary rather than delayed until there is no option. I had to do some scratching around in the SQL code to test why some data took a long time to cache (over a minute). After looking around the database, I was pleased to discover that the normal pre-launch performance tuning I’ve gotten used to will be unneccessary – even the SQL quality is right up there.

The direction we have managed to acheive by switching to Scrum combined with the fantastic skill level in my team is looking like the winning ticket!

I had the first resignation of a person I had recruited since I started managing people, with the exception of a team member who got emotionally involved with a colleague. It’s been interesting – she’s going travelling overseas. She timed it well, and will see out the current sprint before leaving. We wish her all the best.

The team did a sterling job and handed the work over with a full-on briefing. The dependent teams have integrated our work already and are screaming for the next sprint’s deliverables already. That means we did a good job

What we did well this sprint:
Communicated well with dependent teams on related projects
Estimated most work well
Managed expectations well
Maintained a high standard in deliverables

What we did badly:
We still didn’t get the level of documentation we need to achieve
Still had too many meetings that ended without outcomes
We took on refactoring work without fully understanding the scope

What we can do better next time
Spend time upfront establishing requirements and documenting clearly
Spend time on clarifying issues upfront
Explicitly allocate more time to refactoring
Allocate more time within sprint to unit and integration testing
Clearly document what will and will not form part of Sprint deliverables, to use as accpetance criteria.

As we are building components for use by external teams it is important to clearly identify the deliverables and make sure they will meet the expectations of our “customers”. We hope to document the acceptance criteria (“Done checklist”) to a fairly granular level, time permitting. This will avoid disappointment on both sides at the end of this sprint

Sushi delivery is what Scrum calls the delivery of complete slices of the system, like the slices of a California Roll. Sushi Delivery means more frequent, smaller, but functional deliveries are made until the system is complete. Sushi Delivery together with the very clearly articulated and specific Scrum objectives are what keep us tech people focused and speaking the right language.

According to a gentleman in the course, they used to work according to the principles of Scrum when he was a mainframe programmer about thirty years ago. then along came all the business analysts, kpmg – and accenture – style, and they said “don’t do that, you need to have a formal methodology”.

Now thirty years later people are saying “drop all that paper chasing, cut the development cycle down to a series of short iterations and establish a feedback loop”. He reckons it’s a full circle. Maybe so but we’re wiser now.

A novice bonsai grower knows that he must make his Chokkan (formal upright) bonsai have a straight trunk, that the taper must approximate the natural proportions seen in big trees, that the trunk should never thicken, that branches should never cross the trunk. A bonsai master knows that his Chokkan (formal upright) bonsai should look like a big old pine tree thats grown on a high hill or else it’ll be a Moyogi (Informal Upright)

Once one has the insight afforded by experience the reasons why things are as they are become internalised and become one’s nature. the questions become more complicated and the answers become simpler

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

The intentions of the manifesto as well as the ethics of those who have signed onto it can be immediately understood by anyone who’s spend more than a year or two in the industry (and I’d wager by most who have spent less).