Episode 172: Business Agility & DevOps Health Radars with Sally Elatta

The Agile Revolution Podcast

Craig catches up with Sally Elatta, president of Agile Transformation and the founder of Agility Health Radar and they chat about:

  • Companies struggle to get the metrics to know if their agile transformations are making a difference, hence the creation of Agility Health Radar
  • Business Agility pillars – customer seat at the table, lean portfolio management, organisation structure and design, agile framework, leadership and culture, make it stick, technology agility and agility metrics
  • DevOps pillars – faster value delivery, higher quality, culture of improvement and building the right product

TheAgileRevolution-172 (27 minutes)

View original post

Scrum Shortcuts Without Cutting Corners (Book Review & Summary)

ScrumShortcutsI was priviliged to be an early reviewer for Ilan Goldstein’s book “Scrum Shortcuts Without Cutting Corners” and to also count him as a colleague and a friend. The Agile community in Australia is relatively small, so it is always exciting to see a book come out the community, particularly one that is part of one of the leading Agile Series by Mike Cohn. I was also honoured to be asked to provide a quote for the book. The following is my brief review and notes from the book.

Review

The following is my quote from the front of the book:

“If Scrum and Agile were easy, everybody would be doing it! Now that so many are, this book is the virtual Agile coach I wish I had when I was on the early steps of my Scrum journey. Ilan is a world-class coach, and he has packed this book full of ideas and approaches to all of the common questions and issues that are bound to come up as you transform your world of work to Scrum.”

–Craig Smith, Agile coach and editor at InfoQ

The book is broken into 10 chapters, each with 3 shortcuts each. It is written in a very easy to read and laid back style and feels like you are having a conversation with Ilan. It’s organisation means you can read the book from cover to cover of ad-hoc as a reference. It is clearly written with the Scrum Master / Iteration Manager as the primary audience, although it is suitable for anyone on the Agile team.

The key concept I really liked in the book was the notion of a Chief Scrum Master. As organisations begin to scale, it is a necessary role that is not always taken seriously. The book also covers the notion of One Scrum Master = One Team and deals with the ramifications and alternatives to this setup in a reasonable amount of pragmatic detail.

There were a couple of areas I disagreed with, mainly from an hybrid Agile approach as opposed to Scrum

  • protected sprint – Scrum talks about the idea of a protected sprint so that the team can focus. I can see some merit for new teams, but in this day and age of constant change I much prefer working on the next highest priority and the kanban approach to focussing on one-piece flow
  • sprint lengths – Ilan mentions that “1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks”. I have had a lot of success with 1 week sprints, particularly in business teams. Also, with teams adopting kanban, I have found 1 week sprints a good starting point. I have had some mainframe teams argue that they need 3 week sprints, but I personally find them too long.
  • creating and estimating tasks – Ilan writes “break the PBIs into more granular technical tasks and to estimate each task to the nearest hour”. I find this a complete overkill and much prefer to have nicely sized cards of no more than 3 days. That said. Ilan has some good strategies for splitting stories in the book that I completely agree with.
  • tracking time – further in the book, it is written “before going home each day, everyone on the development team should adjust the remaining time for any tasks they had been working on that day to ensure that up-to-date data is being fed into the sprint burndown chart.” As per the above point, I find this to be in most cases a useless metric, particularly if you cannot get the estimates from everyone in the team. In this age of #noestimates, I personally see this as an administrative overkill.

Overall, this is a book that belongs on any Agile pratitioners bookshelf as a trusted advisor or useful reference. As you become more experienced, this is the book you will definitely hand-on and recommend to your more novice colleagues as they take on the Scrum Master role.

My full book review and interview with Ilan and Colin is available on InfoQ.

Summary

Here are my key notes from the book:

Shortcut 1: Scrum On The Pitch

  • protected sprint allows the developers to completely fix their focus on what they committed to during the sprint planning session
  • the idea of personal achievement is overshadowed by team achievement
  • ScrumMaster protects the team from disruptive outside influences and removes issues that may be impeding development progress.
  • Scrum promotes transparency as a core tenet

Shortcut 2: Fragile Agile

  • Scrum is a framework not a method – Scrum is a framework of practices tied together by a small set of clearly defined rules
  • a requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done
  • sprint zero – artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint. The issue is inappropriate work is bundled into it that delays the starting of real sprints
  • poor ScrumMaster selection – unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant

Shortcut 3: Creative Comfort

  • important to ensure that everyone is feeling energized and excited about coming to work
  • teams are made up of individuals, and individuals still maintain a sense of self-worth and appreciate having their hard work recognized.
  • when our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value
  • basics for the environment: plentiful whiteboard and wall space, plenty of light, open desk space for each team, ample chair space, small round discussion table, readily available large meeting rooms, do-not-disturb zones, private areas, buffering from the noisier elements of the organisation
  • developers who are offered their choice of the latest and greatest equipment see it as the most wonderful benefit – keeping developers happy but also improving overall productivity!
  • jelled teams are usually marked by a strong sense of identity . . . team members feel they’re part of something unique. They feel they’re better than the run of the mill.
  • the more passionate people are about their projects, the more likely they are to fully engage in them each day
  • include the developers in some of the early user story workshops so that they not only feel involved in the conception of the product but also get an early idea of what they will be expected to develop and why.
  • a warm greeting in the morning, a sincere pat on the back for a task well done, and the feeling that you are part of a unique team can often be all that is required to maintain smiling faces.

Shortcut 4: Masterful ScrumMaster

  • begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead
  • 7 abilities: leading without authority, bring about change without fear, be diplomatic without being political, behave selflessly without downplaying the role, protect without being overprotective, maintain technical knowledge without being an expert, be comfortable never finishing, next generation leadership
  • ScrumMasters form part of a new generation of enlightened professionals. The role of the ScrumMaster is deep and complex and should never be seen simply as a laundry list of operational functions
  • although not everyone can be a ScrumMaster, a ScrumMaster can be anyone

Shortcut 5: Rock Stars or Studio Musicians

  • we prefer attitude over aptitude
  • teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield
  • constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion
  • the effort you’re willing to contribute goes down the more times you hear “You’re wrong!”

Shortcut 6: Picking Your Team Line-Up

  • consider many factors when running your own Scrum “draft pick,” including attitude, compatibility, skill sets, team size, ratio of functional specialties, shared resources, and workplace logistics
  • everyone is a developer – Scrum views all development team members as equals and labels them accordingly with the collective title “developer.” – it is like being a medical specialist; irrespective of specialty, all specialists are still doctors
  • Scrum team size – 5-7
  • development team ratios – 3 programmers : 1 tester : 0.5 “deep specialist(s)”
  • preferable to limit the work in progress and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs
  • in your next sprint planning meeting, agree that one specialist on the team will not work in that specialty for the duration of the sprint. The specialist can advise others who do the specialty work but cannot do the work personally
  • have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team – treat the as consultants and trainers for the rest of the team
  • one team = one ScrumMaster

Shortcut 7: Setting the Scrum Stage

  • keep the team together for the duration of the project
  • a reasonable assessment of startup cost (for a new team member) is therefore approximately three lost work-months per new hire
  • work conducted in ad hoc space has got more energy and a higher success rate. People suffer less from noise and interruption and frustration
  • sitting together is the most effective way I know to build empathy
  • overtime should be the exception, not the rule – symptom of a serious problem on the project,” not simply business as usual
  • big believer in initially running a pilot project. I recommend this approach even if the business is champing at the bit to roll Scrum out en masse
  • as an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations

Shortcut 8: Plan the Sprint, Sprint the Plan

  • by collectively resetting the goals for the upcoming sprint every few weeks, the team can start afresh rather than remain stuck on a seemingly endless treadmill of ongoing work
  • ensure that the product owner (with relevant assistance) not only has determined the next priority requirements for the upcoming sprint but also has fleshed them out in just enough detail to allow the developers to get started
  • 1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks
  • don’t fall into the trap of believing that those who are dedicated full time to the sprint will be able to spend their entire working day on sprint-related tasks
  • 7 Ps – proper planning and preparation prevents piss-poor performance

Shortcut 9: Incriminating Impediments

  • anything impeding your team’s progress becomes the number-one priority for the ScrumMaster to tackle
  • impediments – meetings of large magnitude, illness, broken builds, issues with the tools of the trade, unreliable supplier, unrefined product backlog, absent or unempowered Product Owner, incentive schemes focussed on the individual
  • impediment ConTROL – Confirm, Triage, Remove, Outline, Learn
  • an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment)
  • you want clear visibility of all blocked tasks, irrespective of how temporary the block may be – spin the corresponding sticky-note 45 degrees

Shortcut 10: Structuring Stories

  • an epic story is a user story that will take more than one or two sprints to develop and test
  • not necessary to have detailed user stories for every requirement only the top-priority items that are going to be worked on in the next one or two sprints
  • key is that stories should be written so that the customer can value them
  • if you can split a story into smaller ones and it is possible to independently prioritize them, it makes sense to treat them as actual stories rather than tasks
  • technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.

Shortcut 11: Developing the Definition of Done

  • DoD becomes the governing agreement that guides all developmental activities, clearly stating what is required for a piece of work to be categorically classified as “done”
  • we should be regularly inspecting and adapting the DoD
  • acceptance criteria or DoD – comes down to whether the requirement is applicable to every user story or to a smaller subset of stories
  • be realistic and get the ball rolling with a minimally acceptable DoD that everyone can live with

Shortcut 12: Progressive Revelations

  • inspect and adapt the user stories under development on a day-to-day basis throughout the sprint
  • typically a hands-on demonstration of the work requiring verification/validation, it usually occurs at the desk of the applicable developer

Shortcut 13: Relating to Estimating

  • estimate to make trade-off decisions and help set goals
  • relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing
  • determine the effort required to complete a PBI using three factors: complexity, repetition, and risk

Shortcut 14: Planning Poker at Pace

  • the issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours, for example
  • some teams adopt more abstract classifiers, such as T-shirt sizes – requires the extra step of mapping to a numeric value to enable forecasting during release planning
  • ScrumMaster acts as the facilitator throughout and is not involved in the actual estimation
  • Reestimation should be required only when a whole class of PBIs suddenly becomes smaller or larger
  • important to circulate a small number of reference PBIs that correspond to the point levels in the card deck
  • typically advocate removing the big cards (20, 40, 100, infinity) as well as the ½ card from the Planning Poker deck – fewer options equals less analysis paralysis
  • group of PBIs will inevitably rely on some of the same important research or technical plumbing – underlying work should be incorporated into the estimation of only one of the PBIs, not into all of them

Shortcut 15: Transitioning Relatively

  • identify the smallest user story in the product backlog and designate it to be the initial ½-point story – this approach can certainly work, and it seems straightforward on the surface, but the reality is that it can end up taking considerably more time than you might expect
  • map historical work to the new point scale system – identify, sort and stack, sizing up, subclassify, final filter

Shortcut 16: Bah! Scrum Bug!

  • an issue is a problem that occurs during the sprint and is tightly coupled to a user story – not a product backlog item
  • bug is a bug only if it is identified after a user story has been completed and accepted by the product owner – type of product backlog item
  • unless a user story meets the definition of done, it might as well not exist as far as the customer is concerned

Shortcut 17: We Still Love The Testers!

  • loss of identity fear – lose QA identity, lack of skills, won’t get support they need
  • testers think in alternative problem-solving patterns that are, generally speaking, mutually exclusive to the way programmers think
  • pair testing (when a tester pairs up with a programmer) is potentially even more powerful because there is additional scope to encourage functional skills transfer
  • there will always be the need for manual exploratory testing that no level of automation is able to replicate

Shortcut 18: Automation Nation

  • if your programmers are using TDD as a mechanism to write their tests, then they are not only creating a great regression suite, but they are using them to design high-quality, robust code
  • functional testing is also often called acceptance testing. Perhaps one day we will call it user story testing, as the idea is to be able to test and automate the full end-to-end functionality of a particular user story
  • integration testing is all about ensuring that new functionality is able to play nicely with the broader ecosystem and not just in isolation
  • performance testing is to measure the operation of the product when under pressure, typically brought about by increasing the number of users and/or increasing the amount of data processing required
  • recommend running a secondary build in the development environment (traditionally known as the nightly build) that is triggered manually and less frequently. The difference between the CI build and the secondary build is that the latter should be given the luxury of time, and therefore, it can include the full set of tests (including all of the heavier functional and UI tests that take significantly longer to run
  • should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention
  • while continuous delivery makes every build releasable to users, continuous deployment actually releases every change to users (sometimes multiple times a day)
  • Scrum does not say that you must release at the end of every sprint, but it does say that you should do everything possible to have something releasable at the end of a sprint
  • just start somewhere –  recommend that if you are new to automation, you allocate a percentage of your sprint capacity to chipping away at it

Shortcut 19: Metrics That Matter

  • use them only for good, not for evil
  • good metric – used as a signal to help the team identify roughly where things are at and, more importantly, as a guide to help the team inspect and adapt its processes to improve over time
  • evil metric – used as an inflexible indicator for micromanaging an individual’s performance over time and, more importantly, for beating people up and killing morale
  • meaningful metrics – sprint burndown, enhanced release burndown, sprint intereference, remedial focus

Shortcut 20: Outstanding Stand-Ups

  • GIFTS – good start, improvement, focus, team, status
  • stand-up ambassadors – act as observers in the other groups to pick up on any potential contention and/or lessons
  • if you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling
  • daily scrum is a simple concept, but without care it can quickly turn into a daily mess

Shortcut 21: Taming the Task Board

  • colorful, sticky-note-adorned board has almost become the symbol of Scrum
  • visceral “ceremony” of this movement really appeals to our natural sense of achievement because of the visual recognition of work completed

Shortcut 22: To-Dos for your Sprint Reviews

  • sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate
  • nothing is more embarrassing than so-called technology experts unable to get the projector to work before the session even begins
  • demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team
  • team should demonstrate only stories that meet the definition of done
  • acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down on the whiteboard or index cards

Shortcut 23: Retrospective Irrespective

  • irony is that this session is most valuable when the pressure is on and/or when things aren’t running as expected
  • without an atmosphere of openness, you will never get to the heart of issues; without courage, the team won’t be willing to confront problems head on; without respect, the team won’t present criticism in a constructive fashion; and without focus and commitment, the team won’t care enough to resolve the issues
  • recommend a relaxed setting such as a coffee shop, a break room (if you have one), or even the kitchen area
  • focus areas – communication, processes, scope, quality, environment, skills
  • ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues
  • circles technique employs an affinity mapping variation, bubbles technique requires each person to document on paper the three most urgent issues that he or she feels should be focused on pair and keep bubbling up the top 3 issues

Shortcut 24: Risk Takers and Mistake Makers

  • to successfully implement Scrum, we must overcome a range of fears
  • spend your time and effort helping those who are already enthusiastic
  • the few bad eggs are often the ones who are most afraid of exposure
  • Scrum turns software development into an open book where mistakes are clearly visible
  • when openly discussing mistakes and vulnerabilities is the forging of closer bonds between team members

Shoprtcut 25: Perception is Reality

  • you have a role as the ScrumMaster to keep the sponsor from blowing a gasket
  • reinforce the positive changes that are occurring while also gauging the sponsor’s current perception of how the project is going
  • sponsors become less upset when confronted with problems if they are involved in the resolution
  • take the sponsor on a “Tour of the Task Boards” now and again
  • never say no is a lesson that I have learned over time

Shortcut 26: Our Lords and Masters

  • Chief ScrumMaster – facilitator of the ScrumMaster Community of Practice – training and coaching, challenge existing behaviours, provide and maintain tools, define and refine metrics, help establish communities of practice, ensure consistency, coordinate teams, ongoing Scrum promotion, developing the approach, company-level education, aligning the teams DoD, continual process improvement via Collective Retrospectives, impediment escalation, HR for the ScrumMasters, creating a physical environment conducive to Scrum
  • ScrumMaster – process improvement, impediment management, diplomacy, coaching, managing change, maintaining the DoD, maintainin effective communication, updating artifacts, faciliating workshops, faciliating Scrum activities

Shortcut 27: Morphing Managers in the Matrix

  • requires visionary leadership that is genuinely interested in encouraging continuous improvement as opposed to playing politics
  • intra-organizational coordination, logistical planning, scheduling, and tracking are massive roles and ones that are nicely suited to the traditional project manager
  • the manager in Scrum is less of a ‘nanny’ to the Team and more of a mentor or ‘guru,’ helping them learn, grow and perform

Shortcut 28: Scrum Rollout Reckoning

  • you are either doing Scrum or not – it is binary
  • Scrum is not a mechanical process… it is so reliant on people and culture that even with fantastic quantitative results, the introduction of Scrum may have caused such upheaval that too many people are unhappy and that is not good for Scrum’s long-term survival
  • Benefield and Deemer used a simple survey based on the following six criteria: How much the team got done in 30 days; Clarity of goals—what the team was supposed to deliver; Collaboration and cooperation within the team; Business value of what the team produced in 30 days; Amount of time wasted, work thrown out, cycles misused; Overall quality and “rightness” of what the team produced
  • Comparative Agility – teamwork, requirements, planning, technical practices, quality, culture, knowledge creation
  • 3 questions – are your clients happier, are your team members happier, are your stakeholders happier

Shortcut 29: Eyes on the Prize

  • development team has no top-down command-and-control authority that tells the team how to do its work. Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done
  • self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control
  • ScrumMaster should assist management in the selection of team members to ensure that the team has the natural predisposition to self-organize and work together as one
  • ScrumMasters should not become obsolete – impediments are never predictable, perfection is impossible

Shortcut 30: Shortcut to the Final Level

  • if you remain disciplined, follow the Scrum rules, and adhere to the key practices, then, at the very worst, Scrum will act like a mirror, helping you to uncover the dysfunctions that caused the project to fizzle
  • three words to remember from the book: transparency, inspection, adaption
  • A Scrum adoption should be seen as a big collection of small experiments, wrapped up in a big experiment
  • convince every single person in your organization that “agility needs to be seen as a business strategy and not just something the IT guys do

Agile Australia 2011 Day 1 Review

Agile Australia 2011Agile Australia 2011 was held for its third year last week at the Hilton in Sydney. Once again I was honoured to be offered an opportunity to present, be an MC for speaker sessions on both days, moderate a panel discussion and run the end of conference retrospective. The conference attracted 675 attendees and the buzz over the two days indicated to me that the conference was a huge success.

For the second year, it was a great pleasure to be one of the conference advisors. As the conference was brought forward to June, there was only six months to prepare between conferences and lots of suggestions and improvements to implement from previous years. A lot of review, debate and discussion went into putting the program together and ensuing there was a good mix of speakers, variety of topics and sessions for different levels of expertise. More effort was also put into shepherding speakers. A huge thank you needs to go to Rachel Slattery and Zhien-U Teoh from Slattery IT for their commitment to the conference as well as my fellow conference advisors Phil Abernathy, Adam Boas, Keith Dodds, Martin Kearns, Dave Thomas and Nigel Dalton.

The following are my notes from the sessions I attended on the first day.

Keynote: On Beyond Agile – The New Face of Software Engineering

Alistair Cockburn delivered this keynote, the slides are available here.

From Agile Australia 2011
  • agile software development is for wimps
  • cooperative game – invention, communication and decision making
  • projects are in a position, look for strategies to move our position, no fixed formula for winning the game (competitors and the economy are some of the enemies), only three moves to invent, communicate and decide
  • communication – whiteboard discussion provides stickiness over time (can just point back to conversation) as well as proximity
  • need about 3 minutes of video to enhance the distributed conversation, becomes archived documentation to remember user point of view or architect design decisions
  • craft – a lot has changed, software development changes every 5-10 years and you need to keep up
  • people learn skills in 3 stages – shu, ha and ri
  • work in progress is decisions that have been made but have not been shipped and delivered
  • like lean we we want multiple deliveries per day – continuous integration has evolved to continuous delivery
  • in decision making, look for the bottlenecks, the person with the full inbox is the person limiting the work in progress of the whole organisation
  • knowledge acquisition – real moment of learning often happens at the end when the surprise factor occurs when we deliver work, suggest that at the beginning of a project deliver a knowledge curve ahead of the cost curve (a number of small experiments)
  • agile says deliver highest level of business value first but projects tend to always deal with the risks first – learn about your business risk (should we build it), social risk (do we have the right people), technical risk (API’s, performance, architecture), cost/schedule risk (gain knowledge about the solidity of the estimates) – you need to decide whether to deliver business values or knock off some of these risks
  • need to identify the tail to determine whether we deliver business value early or add more features later (Apple are good at this, for example shipping an iPad without 3G initially)
  • self awareness – the team is self aware when the team can talk about the team and where they are

Keynote – Is Business Ready for Agile

Rob Thomsett delivered this keynote, his slides are available here. He advised that he was going to run his talk in two sprints and check the heart beat halfway

From Agile Australia 2011
  • agile is a church of all people – the newbies through to the true believers and a few drooling old people
  • agile is not new – been going for 40 years
  • is business ready for agile? – yes and no – every company in the world is ready for agile, they just don’t know it – how do we develop agile into a broader organisational paradigm
  • we work on a set of models that were developed when the world was relatively stable
  • the average window of stability for an organisation is about 3 months, change is normal and everything changes
  • old business techniques have reached their use by date (Gary Hamel – Management 2.0)
  • 100% of C-level executives believe that project management is too bureaucratic, projects take too long, business cases are poorly developed, transparency is adequate, they expect to be ambushed, steering committees are a waste of time, reports are not accurate
  • in 1968/69 NATO held a conference to address a perceived crisis in software engineering – sound familiar?
  • software is not engineering, wrong paradigm, it is a craft
  • the closest to what we do is not making buildings but making movies
  • summary: we took the wrong model, flogged it to death so let’s throw it out
  • agile is a cultural and disruptive journey – first question to ask is are you up for the cultural challenge, for every company that says no there is one that says yes
  • business approach needs to pass the simple and transparent test – most powerful test to clean up broken processes
  • go back to work and annoy people by asking people if we can make it simpler
  • cultural values are openness, honesty, courage, trust and money
  • the people at the top are the easiest folks to get on board with agile
  • most people link budgeting to estimating – agile demands we move money around more quickly
  • sponsors must get dirty – they must be part of the process because they own it
  • PMO should exist for resourcing, not reporting

Panel – The Changing Role of the CIO

Beverley Head moderated this panel with Jeff Smith from Suncorp, Steve Coles from Allianz, Daniel Oertli from REA Group and John Sullivan from Jetstar.

From Agile Australia 2011
  • key is to turn decision making over to employees and leaders need to become coaches and create a great environment
  • The Corner Office by Adam Bryant gives advice for success – passionate curiosity, battle hardened confidence, team smarts, simplicity, fearlessness
  • role is to understand where the company is going and deliver things for them to succeed
  • relax the old techniques like governance that gave a veneer of confidence
  • need to understand and remove the barriers by becoming an active listener
  • fundamentals like attract and retain the best have not changed
  • learn the business in which you operate and realise the definition of leadership has changed (don’t be afraid to higher smarter people than you)
  • need clarity of purpose, avoid constraint of thought and don’t filter based on your experience
  • resistance at the frozen layer – middle managers are typically the blockers so need to change the communication structure (for example, using Yammer for communication to give everyone an equal voice)
  • distributed teams always need a local decision point like an iteration manager
  • leaders need to eliminate information handlers
  • offshoring value proposition – you need to decide if your assets are a strategic advantage, do not offshore things that are volatile or if the project is too big to handle yourself (which essentially means you can’t explain it to someone else), offshoring is good because it keeps us on our toes to be competitive and continuously improve
  • need to look at outsourcing from a productivity point of view and not just a cost point of view (we are not buying pencils)
  • life long learning for developers – people have to follow their own course, inject talent and different thinking, look back each year and think about what you added to your bag of tricks
  • most people are capable of learning new skills, that’s the beauty of human beings
  • what does quality mean – quality is something that is fit for purpose and testable and maintainable, quality is everything
  • pushing agile into the business – need to agree on one way of working, once you are successful people want to jump on the bandwagon

Agile Architecture & Design

I had the privilege to introduce Neal Ford for this presentation, and his slides are available here. As I had seen many parts of this presentation previously, I did not take many notes as they can be found across other posts on this blog.

From Agile Australia 2011
  • in the software world we deal with known unknowns
  • spikes are your friends, purely informational gathering
  • ckjm – tool for reporting complexity and coupling
  • don’t pay for technical debt that you may never justify

Key Metrics for an Agile Organisation

It was my pleasure to introduce Craig Langenfeld from Rally Software to deliver this presentation (originally scheduled to be presented by Mark Ortega). The slides are available here.

From Agile Australia 2011
  • cumulative flow – look at the top of the line to see what is the scope and how has it changed (total features), then ask if the team limits their work in progress by looking at the time between the boundary of in progress swim lanes, finally look at the lead times and how long it will take to deliver a feature
  • work in progress limits allow the team to move through work more effectively
  • lead and cycle time report – allows you to see where your bottlenecks are
  • stop focussing on the workers and focus on the work product – so rather than lines of code look at the the value delivered
  • productivity – understand your teams velocity, throughout mapping stories that were completed and carried over
  • earned value – useful to measure how much value we are delivering (the difference in agile is we are actually delivering the value)
  • predictability – answering the question of when we will be done – throughput chart can show you if a team is getting more predictable over time, burn up is used to show predictability of meeting scope, release burndown to show meeting a date and demonstrate additional scope being added
  • use cumulative flow to track the cone of uncertainty
  • quality – defect trends and counts, most code altered, number of changes, etc…
  • net promoter score for tracking customer satisfaction and if it is increasing
  • get customers to vote on what aspects of the product they like and don’t like
  • for cloud computing track the features that are actually used

Leading by Serving

Simon Bristow delivered this presentation, his slides are available here.

From Agile Australia 2011
  • a perfect team is one that can do anything, in control, do anything thrown at them
  • lots of teams act in an agile manner, the leader makes the difference
  • Robert Greenleaf – The Servant As Leader – others highest priority needs are being served first
  • bridge the gap – gaps when making a decision which is the unknowns, bridges the gap to the future by seeing the unseeable
  • one action at a time
  • forcing a decision on someone will engender resistance, some you must persuade – need to listen to connect at the grass roots level
  • withdraw and acceptance – step back from the team to allow them to look after themselves and accept that the team know best as they are the subject matter experts and will get the job done
  • facilitate community – need to build
  • lead using art not science – if you turn to science in agile you will turn to process

Soldering Irons, Consumer Devices and Hardware Manufacturing in the world of Agile Software

Dean Netherton and Neil Brydon for DiUS delivered this talk which was one of the highlights of the conference for me. The slides are available here.

From Agile Australia 2011
  • DiUS working on a fire danger smart meter and technology for charging electric cars
  • how do you demonstrate value when haven’t built the device?
  • had to work around the vendor for the smart meter because they had a traditional process for building the device – aligned project plans around hardware drops and had to simulate the hardware in many cases
  • used wireframes to drive design but had to spend longer on design to ensure it was right – for example, can’t add a bigger battery later
  • first drop was an off the shelf component board to kick start the software
  • second drop was a bare board that was the basic board without the LCD
  • third drop was the plastics without the screen as the component had not arrived so replaced with paper
  • challenge on how to articulate stories – had to break stories own technically
  • used Cucumber to test as there was an embedded USB port on the board – helped embedded engineers assist the Ruby engineers understand how the device worked
  • did continuous integration by plugging a device into the build server, had an issue about flashing the device when the code changes
  • hardware engineers slightly change the design with each revision which had affects on software design as well as having hardware for continuous integration
  • built own hardware prototypes and used local suppliers to cut down lead times (China cheaper but added 6-7 weeks to the lead time)
  • used mocking to show users the idea ahead of hardware being available
  • planned for multiple hardware revisions to allow for late decisions
  • these days you can send a 3D model to a design house and they can pop out a prototype, design exercise ensures that screws line up, etc
  • no excuses for automated testing, in the past it was not embraced in hardware, can test the integration layer without the need for hardware
  • no benefit in running tests for the hardware design as you only get a handful of drops
  • use automated test to ensure buttons and light work, good when you get new hardware and good for checking faults on the production line
  • had to learn about the hardware stack early on which challenged whether value was being added
  • firmware development not integrated onto the story wall
  • technical tasks are OK but really understand what done is
  • luckily the stakeholders were quite technical

Putting It All Together – Agile Transformation and Development Tooling

Philip Chan from IBM delivered this presentation, his slides are available here. I failed to see a lot of agile in this talk personally.

  • established teams – communication difficult across timezones but tools make it easy, different tools used in different teams,
  • IBM agile process – 2 week iterations, 2 day inter sprint break every 4 weeks, develop for first 6 days followed by 2.5 days for bug fixing, do acceptance testing for first 6 days and 2.5 days of exploratory testing, showcase on day 9
  • test management very waterfall for audit purposes
  • using automated tests and continuous integration to assist global team optimise processes

Panel – Continuous Delivery

Evan Bottcher, Neal Ford and Martin Fowler from ThoughtWorks were on this panel.

From Agile Australia 2011
  • continuous integration – everyone in the team integrates with the mainline at least once a day
  • continuous delivery is taking the same approach as continuous integration and apply it to the last mile – decision to deploy should be business only with no technical barriers
  • continuous deployment is continually delivering on a regular basis – continuous delivery enables this if you want it
  • rare to find a company that is pulling in the same direction, so you need to automate in pockets and add manual checkpoints and then you can look for ways to automate them
  • risks – need to bring pain forward, which was the tenet of XP, not doing it is much more risky, there is pain and effort to setup, you need to look for a leverage point in your production systems to justify
  • if you do something rarely you don’t get practice, by doing it more often you improve which actually results in a process that is more auditable and gives you more confidence
  • is a good approach to shorten feedback loops, also allows you to give confidence to the business on delivery timelines
  • packaged software makes continuous delivery hard, important to look at the automation of the configuration as well as automated tests, looking for fast feedback to give confidence in delivery
  • need to push software vendors to make things more deliverable (this was a rant by Martin Fowler, that I tend to agree with)
  • make database changes with the same fundamentals – break them down into small changes and combine schema changes with the data migration and string them together into a package, tools have got more specific like dbdeploy and Liquibase support this and Ruby on Rails just supports this out of the box
  • DBA’s are the final frontier because they like to fiddle with scripts, need to bring them in or deal with smaller changes
  • testers tied to manual processing – need to separate the low and high value testing work, fear that they will be replaced by a small shell script, will make their job vastly easier, need to get buy in by demonstration
  • difficulty is always the human element – testers are moved from the backend to the front end of the process, specification by example at the front now, need to look at incentives and make them common between developers and testers
  • key is a business decision of when to delay so you can deal with business change, training, etc…
  • people are now used to the fact that websites or apps on their phones are continuously changing
  • gives the option to deploy to different types of users when they need it
  • Go was built with continuous delivery in mind, version control systems are critical because everything needs to be in there, automated testing tools are also critical, continuous integration servers can help if they have an extra build pipelines
  • Puppet and Chef both allow you to script your environments
  • need to place people in teams who believe things are possible

Other Stuff

At the end of a very long day, it was good to network with attendees at the ThoughtWorks open office.

Also, I have to send congratulations to my colleague Adrian Smith from Ennova on his talk Agile for Startups which I hear was very well received (I have attended previous incarnations of this talk).