Being Mark Cohen

Rowan Bunning pinged me and reminded me that the Australian Scrum Community has organised a free presentation by Joseph Pelrine on why Agile works in Sydney, on Monday. 

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.

I’m having a hard time applying Scrum within my team now. We have support or maintenance requests coming in daily, project scope creep that is difficult to manage, workload that exceeds some developers capacity, and low resourcing with regard to a lot of the processes outside of development.

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. Read more »

Our switch from Waterfall to Scrum has definitely been successful. The whole Agile approach has proven to work better within my team and (I think) my environment. some people still have issues with the provision of transparency with the removal of the power to interfere. I see their frustration a lot, luckily for me they accept that this is the way we are running the team now.

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.

We have finished out Sprint 1. It was tight, the guys had to really go the extra mile. We pulled some critical refactoring into the sprint, and pulled out enough work to make sure that the rafactoring would “fit in”. Problem was that the refactoring was under-estimated and so it took some serious effort to get it in.

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

Just an observation: The quickest benefit I have seen out of converting a waterfall project into a Scrum project is the immediate restoration of communication channels. With waterfall the tech team generally don’t speak to the business team often, and the business team harrass the tech team all the time. With Scrum, the business team ask the tech team to explain things a lot more (a good sign, they know they need to understand more) and the tech team are more focused on tangible deliverables – and communicate with the business about these goals a lot more.

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.

It’s official. I’m now a certified Scrum Master. What does that mean? It means I’ve been coached on the soft skills as well as the actual methodology of Scrum. What’s Scrum? I believe it’s the most life-changing thing a person can do to a project that’s dying at the hands of Waterfall management.

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

Just followed a link to the Manifesto for Agile Software development on the Scrum website. It’s a brilliant philosophy for the technical side of the software industry:

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