Day 4 at Agile 2010 and another full day of sessions followed by the conference dinner at Epcot. Here are my notes:
How to Own a Really Big Complex Product
Mike Cottmeyer presented this session which is also available on Slideshare.
- product owner is responsible for stewarding the team, creates and prioritizes the backlog, elaborate requirements, communicate vision, represent customer, QA the product
- product owner is a single wringable neck, one person responsible for what we want to build, with multiple product owners who decides what to build?
- embodiment of traditional roles – product manager, project manager, business analyst, quality assurance, management, user experience and a team member – overloaded!
- complex product – intersection of multiple products we need to deliver against
- need to think about our organisation differently – challenge is always to get a cross functional team that has all the parts of software, hardware, etc (there is a scale where this does not work)
- many to many teams working on products – teams may have good velocity but the organization or product does not – sequence backlog across team to ensure goals are being met
- performance indicator is not velocity of the team – performance of one one team can starve performance (if one team is not pulling their weight)
- typically we have features that spread across multiple teams, not always working on the same thing because they are blocked or not synced
- intermeshing features leads to time blowouts and context switching – end up running late, dropping features and all hands on deck
- look for teams that are the constraint – remove their non essential work so that they are getting value out
- need to take systems thinking approach and look for team constraints
- look for patterns as to who is fulfilling the product owner role – often tends to be the development manager
- need to express the product owner capabilities at team and organisation level
- scrum of scrums have turned out to be dependency management meetings for scrum masters, need to do the same for product owners – make sure that product backlogs are not starved, include architecture or a senior technical resource in this “product owner team”
- manage and respect the dependencies between teams
- recommend taking a look at Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results by David J. Anderson
- kanban – can help the organization constraint problem, express the enterprise flow of value
- architect – creates strategic technical constraints for teams
- it’s about team, team, team, conversation, conversation, conversation – need to trust the organisation has ethics to achieve decisions – most executives make hairbrain decisions because they don’t have the right data
Refactor Your Retrospectives
Rachel Davies delivered this tutorial, a copy of the presentation is here.
- Project Retrospectives: A Handbook for Team Reviews by Norman Kerth was the original text on retrospectives in 2001
- not originally part of scrum – a small part in the Agile Project Management with Scrum book
- for a good overview of retrospectives take a look at the Agile Retrospectives book as well as Agile Coaching
- heartbeat retrospectives- challenge that 2 weeks not long enough to do things, what to do differently is sometimes not enough to ask
- more people doing continuous retrospectives, especially with kanban
- helps if you limit the number of actions – short amount of time and not enough time to do it
- prepare for your retrospective – bring in data, book rooms, bring equipment, etc…
- after the retrospective – publish the outcomes, make them visible
- have the participants prepare
- too much time living in the past – not creating actions
- judging – spending more time on what happens rather than the cause, and just making analysis rather than actually making changes
- cloudy thinking – spend more time thinking about practical steps to fix the problem
- fixing symptoms – talk about the real problem
- blaming – criticizing others, especially those not in the room, need to steer the conversation back to what the team can effect, can we build bridges or invite them to the retrospective, get multiple teams together to tackle issue
- unconnected ideas – have people who are keen and not keen, need buy in from team that it makes sense
- thinking too big – ambitious action lists, can we fix in the next iteration, decrease velocity, pick the top few, decompose large actions
- no owner – team recognizes problem, need somebody excited to change it, should not always be the scrum master because the team are not taking responsibility and action
- invisible actions – make the actions visible to the product owner, hard if the product owner is from management
- activities that trivialize the team – vary retrospectives but respect the team, sometimes have fun activities and sometimes need for discussion, be aware of things happening in the environment
- picking on people – maintain safety, ensure meeting is about process and work not individuals
- important retrospectives affect some kind of change
- respect people are bringing time to the meeting
- do it differently – respect visual versus post it’s versus standing versus sitting
- a bridge between sprints – should be half looking back and half looking forward
- are sometimes about improving our working agreements
- turn the topic to “why can’t we do retrospective actions”
- don’t rush – allow time, get the story out and listen to the team, need about an hour
- gather the data in a timeline – written as well as verbal, everybody participating
- get people to draw what it felt like working on the last sprint
- dot voting – need to build consensus, but can also lead to disagreements
- encourage many solutions to an idea
- make things visible, write them down, bring them to the next one
- use agile techniques to run and build into plan
- read books on facilitation and try different techniques
Kanban Explained: Seeing, Not Hearing Constraints
Jon Stahl delivered this presentation to a packed room, the slides are available on Slideshare:
- kanban is another practice – you don’t eat the whole buffet, you just pick what you need
- at Toyota doors are requirements but also are physical inventory
- 3 rules – strict queue limits, pull value through, make it visible
- set limits for active states, not wait states, relative to your team size, no more than 2-3 in wait state or per person
- use value stream and FIFO (First In First Out)
- everytime a developer stops work to help QA, put a tick mark, we now have a discussion point
- waiting point queues are for slack in between, just for buffer
- show and tell column for feedback, when we reach the limit schedule while it is still fresh, also may be a signal to deploy in kanban
- use bingo doppers to mark features – it is just fun
- can change the priority for items in the wait queue to help
- push through a feature
- make your queue signals visible (rules) eg. if architecture = new, trigger architecture review meetings
- what goes on card – date card created, work in progress (WIP) start and done dates to measure lead time and cycle time, then create a metric from a realtime average
- when you get a flow issue from your metric, do a root cause analysis, throw it in the pile for next retrospective
- you don’t want things to flow backward, need to call a plumber! – write on the back the date it went backwards
- Disney are good at wait time – track your average wait time to done (customer delight) in your analysis queue and your backlog (should be the same number of WIP as your kanban board)
- a card is a token, a symbol of work, gives you courage to have a conversation, there is only so much WIP
- takes about 6 weeks to figure out your WIP when starting up
- there is no “always the case”, this is it
- estimates – extra small (XS) < 1 day (1), small (S) 1-3 days (2), medium (M) 4-6 days (4), large 7-10 days (8)
- every implementation – the business is the bottleneck
- team signals – put the team rules up on your board, put meetings up on wall so you check it is adding value
- retrospective kanban board – when you hit a limit, have a retrospective, keep a retrospective kanban board for actionss
- flow is continuous, no open or close (show and tell and retrospective triggered)
- scrum versus kanban, who cares – worry about pace and consistency
- standups – how are things flowing, talk about blocks, take turns talking to the board, walk the board and talk when you need to – stops the ceremony
- Jeff Patton talks about an express lane – have signals and make it hard
- look at Kanban by David Anderson new book, Limited WIP Society, the Yahoo! kanbandev group
- distributed teams – have a board in each location, get them to measure and give data back
- cross team communication is 25% waste
Bloody Stupid Johnson Teaches Agile
Rave reviews of this session by James Shore and Arlo Belshee led to an encore performance, which more than lived up to the hype. There is a great review of the original session written up by Dave Nicolette on his blog.
The play was very entertaining (and way too true in some regards) and the audience participation was spot on. I heard a rumor the original session was recorded (I certainly hope it was as it is well worth a viewing).
Project Management Stage
Once again, I dropped in on the sessions that were happening on the Project Management stage throughout the day, there were some real standouts that in hindsight I wish I had attended. We had a number of talks in multiple rooms.
- Institutionalizing Scrum (Brian Bozzuto and Michele Sliger) – this was a well received talk and it was great to meet Brian in person as we had collaborated on the reviews for the stage.
- Save 76% – Joys and Pitfalls of using Virtual Worlds for Remote Teams (Bill Krebs) – this was a talk I was keen to have on the stage, and it was awesome to see Bill demonstrate in real time a virtual standup in Second Life and Telepresence with State Farm.
- Project Vital Signs (Stelios Pantazopoulos) – it was great to meet Stelios and I got to spend some time with him at various stage throughout the conference. This is an excellent presentation with different ways to demonstrate the health of an agile project.
- How an Agile Project can Fail and what to do about it (Ahmed Sidky and Sara Medhat) – Ahmed was the co-author on Becoming Agile and it was good to see him again this year at the conference, and to see him speak from real like experiences.
- Estimation Games – Play to create and destroy good estimates (Pascal Van Cauwenberghe) – Pascal came highly recommended for this talk on the stage.
- Agile Projects – Beginning with the End in Mind (Bob Galen) – this was another good session, and it was good to finally meet Bob this year (he was also at the AAFTT workshop I attended earlier in the week).
In typical Disney style, this was a well orchestrated affair of dinner, a show followed by Fireworks at Epcot. Unlike usual conference dinners, it was a little unfortunate that there was not time to mingle and chat afterwards. However, the entertainment was awesome, particularly the celtic rock band Off Kilter, and the night concluded with the 10pm fireworks at Epcot followed by 2 hours to experience the attractions at the park (Test Track baby!)
One thought on “Agile 2010 Day 4 Review”
Pingback: Twitter Summary September 2010 « CDS 43