Day 3 at Agile 2011, here are my notes:

Scaling Software Agility: Advanced Practices for Large Enterprise

Dean Leffingwell is the author of Scaling Software Agility (which was written in 2006 and, in his own words, the world has changed since then) as well as Agile Software Requirements (which is really about portfolio management). Dean presented this session, a copy of his presentation is available here.

From Agile 2011

• scrum is designed for small teams and makes no claims for scale
• scale might not work, you can make it work
• economics and technology have changed to make agile work

Not everything is a user story:

• user stories came from XP, builds the user right into the requirement
• lots of teams have their own stories in their own sprints
• if something is in the backlog we might do it, if it is not in the backlog we won’t do it, anything that needs to be done goes in the backlog
• best code comes from XP shops – it’s a form of hygiene, like brushing your teeth
• the user story model lacks context – the things around it
• at enterprise scale you have a large, large amount of stories but how do you reason about that and get the context
• we need an additional level of planning – features which get decomposed into stories
• features need to fit into potentially shippable increments as well, because they need to ship
• stories need to get tested, as do features and non-functional requirements
• use epics to describe features that are too fine grained at the enterprise level – may be implemented over long periods, even years
• investment themes represent the budget allocations that drive the authority – at a program level figure out your epics that make up 17% of the budget, for instance

Think agile programs, not just agile teams – manifesto does not mention teams at all

• there are lots of teams in the enterprise
• need to train everybody, but that is slow and expensive
• regular release train, build it this way even if if the customer / factory is not ready for fit
• change value system from plan driven to value/vision driven – move from Clarity driven estimates which we then fix to fixing a date which we strive to meet
• in software industry we always miss dates, build credibility by meeting dates
• most teams are overly optimistic
• quality needs to be built in, but features need to be variable
• everyone needs to be on the train – waterscrumming does not work
• hindsight brings us perspective
• cadence alone is not enough – worst nightmare is not the facts but the false sense of security that you are going to deliver
• slowest component drags the train – if you have a VP of system integration you are already screwed
• make sprints the same length – two weeks is a good cadence, three weeks is too long, you can’t figure out when you should start testing
• have regular system wide integration – use PSI (potentially shippable increment) to ensure you have a product, use hardening sprints for the things you can’t do in a normal sprint and let the team catch up
• release train process – when you have an asset that adds customer value, ship it or ensure you have a asset that you could ship – it could save you with large maintenance renewals
• pacemaker is release planning – need a full day or two for release planning – if you can’t spare that then plan badly – also gives us full alignment, a good point to get the architects involved because at this point you can make a change – plan using stories because that is the teams currency
• scrum gave us a framework for sprints – plan and commit on day 1, execute for 8 days, demo and retro on day 10
• at enterprise level raise this to the PSI level – plan and commit at the program level and demo and retro together at the end, sprints at team level in between (a program is usually 5-10 teams)
• do a one week all in training for the team and then fire straight into release planning – then coaching is in context – don’t have good experiences with teams that go ahead without coaching support
• take into account that your first sprint will be a little rough

Enterprise systems require intentional architecture – it matters!

• refactoring is part of agile, list on the wall and get the product owner to stand by them, but it doesn’t scale very well
• architecture can emerge, you can’t always plan for it
• principles of system architecture are important
• the architect needs to be part of the team to succeed
• the team owns the design of the system, gives them accountability – design spike is our currency for architecture and it needs to be demoed
• sometimes we need architectural epics – architectural epic kanban system

Portfolio management must be agile too – the mothership of all impediments!

• PMO is governing us to a model we have abandoned, yet we created it in the first place
• need to move from a portfolio of projects to a backlog of content management
• need to move from cost estimation to velocity estimation and planning – so estimate your releases and epics in points too, not in dollars or hours
• the team manages a project, not a traditional PMBOK manager
• move from Gantt charts to a release train
• move from milestones to fact based governance – we don’t cheat and lie on agile, the facts are friendly
• use the term PSI rather than milestones
• the worse your program is, the less you see it (that is, if you miss a design milestone there is nothing to see)
• get the agile PMO to re-purpose and drive release planning, reviews and retrospectives – they need to drive the behaviours to be successful

Your enterprise can be no leaner than your executives thinking – need to turn them into leaders

• executives are actually pigs – pigs are cool, chickens are uncool
• I need management to resolve impediments, string vision, managing performance, etc…
• managers must lead! – need to train them first
• need to have respect for people
• management needs to be trained in lean thinking, when they get lean they get agile (The Principles of Product Development Flow)

Overall, there was nothing really new in this session for me, although it was great to hear from Dean directly, especially on the topic of PMO’s and leadership. His latest book is still on my list to read.

Removing Impediments with Drawings

Carlton Nettleton led this interactive session, the instructions and agenda of the session is available here.

From Agile 2011

This session was based around Dan Roam’s Back Of The Napkin framework. There are six types of business problems:

1. Who and what? – people, things and roles
2. How much? – counting and measuring
3. When? – scheduling and timing
4. Where? – direction and how things fit together
5. How? – how things influence each other
6. Why? – what is the big picture

These help you focus on the types of problem you are trying to solve.

The steps to visual thinking are:

1. Look – look around the room, get oriented
2. See – start to recognize familiar patterns
3. Imagine – see with our minds eye, manipulate the patterns and make the invisible visible
4. Show – show the idea to people

From Agile 2011

A drawing is more memorable, particularly when related to a story, helps your audience visualize your message, pictures drawn by a human are better than those drawn by a computer because they look too perfect

SQVID is a metaphor of how to draw pictures. Are you drawing:

• simple or elaborate pictures
• quality vs quantity
• vision vs execution
• individual vs compare
• change vs status quo

Imagine:

• discuss why you are imagining
• draw simple
• don’t overwhelm by drawing too much
• iteration and refinement
• think outside the box

Show:

• focus on the audience
• feedback
• evolution – start, middle, end
• outside perspective
• drawing is only for support

This was a very hands on session, and the charts that we used in the exercises were very good templates that I will recall and use in future. The takeaway for me was to draw pictures in real time more to illustrate and get engagement for my message. I will also take another closer look at  Dan Roam’s book.

Agile 2.0 – Rebooting A Raccoon In An Imperfect World

I presented this session with Greg Smith to a good size audience. The slides are available in a separate post.

Tightening the Feedback Loop

Patrick Kua presented this session, the slides are available here.

From Agile 2011

• effective feedback should strengthen confidence or improve effectiveness
• The retrospective prime directive (at retrospectives.com) also applies to feedback
• in lean 99% of behaviors are driven by the system – people were driven by the situation at hand
• focus on behaviors not values or judgements

Formula:

• be specific on timeframes eg yesterday
• your observed behavior
• perceived impact
• recommendation or suggested solution
• make it a conversation – set aside time such as feedback frenzy Friday
• give feedback earlier, not just at annual review time
• create safety – “is now a good time”, not a public theme but in private
• seek clarifications – apply the five why’s to feedback
• say thanks for feedback at the end – appreciate being helped to grow
• take action on the feedback

Overall I have always found Patrick’s writing on retrospectives helpful, however there was little new in the presentation for me.

After Dark

Wednesday night was the Sponsor Reception, where the prime aim was to get to every booth and get a sponsor stamp (the real rule was to get one stamp per page, but it was far more fun ensuring I visited every booth!) One of the amusing things in Salt Lake City was that they do not take themselves too seriously, as evidenced by this beer.

From Agile 2011

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 3 of the conference.