Navigating the Seas of Information: SCRUM Australia conference

It has been a few weeks since the Scrum Australia conference and as I promised I would post my notes. Gathering all the information into a single post would be challenging, as there was so much information and shared experiences exchanged between everyone attending. So I have produced a summary, with a mind map detailing my notes.

My reason for attending was to get back in touch with people and what was happening in other companies with Scrum and agile processes in general. What I got out of the conference was allot of new friends, new tools and new insights into where Scrum as going and being treated. I was very glad to listen to talks that focused on how the business can use Scrum ver how a development team can use it and some heated discussions over different agile methods.

I was in some sense surprised to find that there was a growing trend of defining a very hard line of what is and isn't the correct process. One person mentioned that they had encountered a trainer who taught that a story must begin with "A user ...." and that if you used "A customer ..." you were not doing agile. I guess you get some miss interpretations and "hard liners" in any community. I doubt I will ever know the exact context that drove to that style of training.

The conference was over 2 days, April 10-11, there was a good range of talks, and an "Open space". This was my first open space which I really enjoyed talking about topics raised on the first day. I wish more conferences did open spaces.

I attended

Day 1

Opening Keynote: Economically Sensible Scrum
Scrum in highly regulated backend environments
Scrum from concept to app store
Global attitudes towards Scrum
Take it offshore! Ramping up a distributed team.
Inspire Management

Day 2

Open Space discussions (Scrum Trends session)

Benefits and Realisations, Business Value metric, Emerging architecture
Kanban
UX - How much is too much?
Product Management

Ebay. An agile journey for the worlds largest Data Warehouse
Portfolio Management with Scrum
Closing Keynote: Systemic Scrum - The lifeline of organisations

I have gathered my full notes into the mind map, it is quite large and I have provided a high resolution version so you can download and inspect the branches, and I will refer to some of the branches in my discussion.

Scrum process seems to be well adopted, and now the same questions that face every process are being addressed, such as cost of technical debt, product support mechanisms, resource and knowledge management, and measures of success. When you look at the Product branch you will see the main notes regarding these problems. What this suggests to me is that the process be it Scrum or Waterfall we are still dealing with project processes and wrestling with the operational process impacts. It may be worth looking at operational best practices and see how they influence Scrum methodologies. (Thus the buzz on DevOps)

Speakers such as Justin Urbanski and Jason Harwood highlighted how the introduction of SCRUM exposed the values of processes like continual integration, using spikes for rapid prototyping early on in projects and having custom testing tools were critical especially where high quality is required. I think the Halfbrick friday concept Jason described, where everyone across multiple teams get together and pitch ideas is of huge potential especially if you can implement those ideas.

Quite a bit of discussion was had over how to manage time, interruptions and work. I have been a fan of Pomodoro ever since Julines Liong introduced it to me years ago when I was working at USyd. It breaks time into Pomodoro units of 25min work and 5min clarity, establishes rules on managing interruptions, self improvement and is amazingly helpful if you are feeling overloaded and stressed. It is being applied to teams as Henry Wiputra pointed out, though that was the first time I had seen it applied at a team level. The figure that a person should be on no more then 2 projects was very interesting showing that more then this will cause increasingly inefficient work.

It is good to see that people are trying to determine the returns on products done through Scrum methodologies such as Kenneth Rubin in his Essential Scrum, however in discussions allot of people were reporting frustration at not being able to determine real benefit realisation or value from projects. This is something that definitely needs further investigation for myself as I am very interested in the correlation between BV figures and prioritisations. The question to ask is: "How can you prioritize with a measurement for estimated business value that can't then be measured for actual business value?"

The day before the event I had a Kanban game training session at work, which I really enjoyed, so the discussion on Kanban vs SCRUM was a great one, even though I did spend most of the time as an observer. The key items I felt came out of it was that people view it as a managers agile process and a way of taking decision making away from the team and back into the managers hand. I assume this comes from ways it has been implemented where that has been the case. I find the Kanban process interesting and from a pipeline perspective an effective way of managing blocks of work. Who makes the decisions can be a team or a manager.

I tended to agree with the outcome of the Product Management discussion branch which noted that the Business Analyst makes the best Product Owner. Its a gap bridging role as are the architect roles. Though having said that I must mention as Rowan Bunning pointed out to me, the PO role is about making the

"hard-nosed commercial decision making. It's about vision, $'s, trade-offs, value-based thinking, outcomes, being an intrapreneur and often saying "no" to the sort of peripheral requirements that many analysts tend to dig up"

Perhaps this one needs some more discussion and input at the next conference open space.

"T-Shape" skill set is something I absolutely agree with. Find a focus that your personality and skills really are best for, but ensure that you have the breadth of knowledge and skills to be able to move between positions and support others in your organisation. In agile this is essential. To simply pick up a task, execute it and then do a different task with different skill set is the key to efficient agile teams.

Slack Slack Slack. Use it, don't abuse it.

Daniel Gu's guidelines for good agile teams were very good. What eBay have done is very impressive as they have achieved very good agile teams and they do reflect many of the experiences that people related at the conference. If I was to put a team together for a project from anywhere I know who I would pick. Most of them are Scrum masters, they all have diverse specialties they are all skilled at adapting quickly to new technologies, they are all professional in their work and the sum creates a fantastic working team.

Well my pomodoro's for this blog have run out so I would also like to thank the organizers for doing such a fantastic job, and all the people who did attend for sharing all their experiences and insights.

Some good references gathered from discussions:

Navigating the Seas of Information

Thursday, April 25, 2013

SCRUM Australia conference

1 comment: