[This post continues from Reflections from Agile Cambridge 2013: Day 1]

Change or be changed (Janet Gregory)

Today’s keynote dug down deeper into the concept of how we often can’t avoid change. The presentation was split into three parts: types of change, influences for success and how to introduce change.

The types of change section discussed how we can change a ‘want’ into a need to face change, which often involves seeing opportunity. The change we are driving may have its success determined by other factors, however, including how it was introduced, resistance and whether people feel there is an implicit blame in a culture change. It is therefore necessary to consider any personal agendas people might have. Introducing change involves sharing a vision and involving others, and giving people space to voice any concerns and fears. If the change involves measuring something, it’s also important to explain what we are measuring and why, so they don’t react, thinking they will be punished. [This is something I know that I’m particularly guilty of.]

Scrum & Kanban (Jon Terry)

Unfortunately, this talk had a published title which was different from the one that was presented, entitled ScrumAgiLean, which I had seen previously. The talk is a useful reminder that Scrum and Kanban are complementary, and how they relate to Lean Management. One of the main things I learnt is that we can defer commitment to a particular path by building multiple options at the same time. I wonder how practical it would be to suggest to management that the team should develop something twice in different ways, although I can understand that it can save time in the longer run.

Requirements: whose job are they anyway (Allan Kelly)

This was a disappointing talk in my opinion, as it came across as predominantly being a rant. Perhaps it’s because I’m lucky that at Red Gate we have dedicated Product Managers who talk to customers, but the only really useful thing I took away was a distinction between Product Owner (as an umbrella term), Business Analyst (someone looking at internal users, who are measured by costs) and Product Managers (someone looking at external customers, who are measured by revenue).

Scaling out solutions development with feature teams (Luke Morgan)

This talk was much more useful. Luke started by introducing the ‘Capability Complexity Curve’ to describe how ‘solutions’ different from ‘products’. The majority of his talk, however, focused on the structure of his feature teams, which exist as a subsidiary of a single solution team. For example, he has usability and architecture specialists at the solution (not feature-team) level, to help avoid the issues of Conway’s Law. Another interesting factor was the need to have a DevOps engineer in the feature teams, helping to resolve any infrastructure impediments. The solution team, meanwhile, contains the Release Manager (which is similar to the Project Manager), whilst the ScrumMaster exists at the feature team level.

Open session: DevOps

In an impromptu open session at the end of the day, we discussed the role of DevOps, and in particular whether they should be embedded in the team or separate. The general consensus was that embedded DevOps improves speed and flexibility, whereas separate DevOps teams help get more time for working on infrastructure. Generally, DevOps were seen as being crucial for scalability. Slightly more worryingly, however, the best definition we could come up with was that DevOps are ‘A group to shout at, even though they have no cost centre’.

[This post continues at Reflections from Agile Cambridge 2013: Day 3]