Agile Academy Meetup: Agile & Lean Games

MeetupAgile AcademyLast week, the Agile Academy had a games night for its November 2011 meetup, to cap off the year, hosted by Adrian Smith from Ennova.

The three games we played were the XP Game, Lean Paper Plane Game and Kanban Soduko. We ended the night with the Marshmallow Challenge.

You can also view the pictures from the night.

YOW! Nights: Extracting Gold from Legacy Code

YOW! 2011Last month, Dave Thomas came to Brisbane for YOW! Nights to deliver his always insightful and entertaining presentation entitled “Mature Legacy Seeking Sexy New Technology for Fun and Profit: Extracting Gold from Legacy Code”. It’s been a pleasure to work with Dave on the last couple of Agile Australia conferences and I always try to make sure I catch his presentations when he is in town.

The following are my notes from the session:

  • a common complaint is that my boss does not let me do anything neat – legacy is a challenge
  • go where there is a big need rather than wherever everybody is – solve a problem that is important to them in a clever way
  • legacy code is code that has no tests
  • only if you have a product that matters you will have legacy – you can make bloatware even in new systems
  • legacy – the big ball of mud – OO is one of the biggest creators of technical debt
  • developers are the source of legacy debt – the developer solution is we can always rewrite it in my language – most rewrites fail
  • outsourcing often works short term – but you lose your business knowledge and you realise your requirements stink
  • vendor solution – start with a technology you don’t need
  • agile solution – just refactor it, there are no tools or practices that can fix millions of lines of code, it will take forever
  • need to figure out what the legacy is about – get the metaphor and a picture – write stories and put them on a wall, invest in getting the legacy programmers to sit down and talk about it
  • most companies are living on their legacy – new products are not paying the way
  • pair legacy and non-legacy developers to tackle the problem
  • use modern IDE, use modern SCM, new continuous build infrastructure is cheap, need fewer developers if your whole world is in memory
  • when everybody is using agile, how can it be the best practice – it is the only practice
  • prove your way through the old systems – there are very few greenfield projects
  • do TDD using live transaction roll back
  • automate from the data definition not screen scrape
  • people only do innovation when they are screwed – agile is predictability and quality not productivity
  • rewrite the contracts so that vendors can only install if they have automated acceptance tests – acceptance tests are the only way of putting two distinct processes together
  • big resource contracts should be split because the quality of resources are usually spilt in half – give it to local resources who have the talent
  • an agile coach is “an unemployed Smalltalk programmer”
  • think outside of the box – use spreadsheets to load data to the cloud
  • simple innovation in a difficult problem gets you a lot of respect – don’t ask your boss if you should write some Prolog to solve a problem
  • look where the customers are spending money – it is usually in legacy
  • lots of great opportunities to make a difference to hold your nose with the legacy smell – find where the biggest bang for buck is quickly – need to do it in months
  • KLOCs kill – more code to maintain
  • prove new ideas and do a little bit at a time

Agile Academy Meetup: The journey of becoming Agile or even more Agile

MeetupAgile AcademyA few weeks ago, the Agile Academy held its February 2011 meetup, with three speakers and a panel discussion on agile adoption in different organisations. There was a good turnout to hear the 3 speakers:

Here are my notes from the short sessions.

Adrian Smith (Ennova)

Ennova is a startup in the engineering space:

  • start with an idea or a better way of doing something as well as good people and customers
  • get an idea, develop it as quickly as possible, give it to your customers and learn
  • use low-fi tools: story wall, Pivotal Tracker, user personas and scenarios, build prototypes but enforce rules such as “can’t give this to the customer” or “no tests”, offshore remote pairing with Skype and iChat, version control using GitHub, continuous integration using Hudson, testing using Cucumber and RSpec, one-click deployment in Hudson and EC2 test grid, communications with Campfire and Yammer for chat and retrospectives using Listhings
  • started with the culture in mind, set principles and hire the right people
  • whole business needs to be agile, focus on technical quality important

Nigel Waddington

Nigel relayed his experiences from setting up Agile at a large software organisation:

  • don’t believe case studies, every customer is different
  • it’s all about yoghurt! – cultural change is hard – need leadership involved plus bottom up engagement
  • leaders care about money – “show me the proof that waterfall works!”, they want predictability and reporting and to make money
  • ran pilots to show success – choose good duration, start small and grow and make sure it has executive buy-in, don’t choose pieces of work that are too easy
  • pilots are good to engage people – train, educate, seed teams – get them to push and make it happen
  • balance between fast and evaluation
  • eat your own dog food, “iterating towards agility” (Mike Cohn), use a virtual scrum team for transition
  • don’t mess with the Scrum basics in the beginning
  • remember you go to work to deliver software, not to do Scrum

Elio Patane (WorkCover Queensland)

WorkCover Queensland is a workers compensation insurance company:

  • weren’t delivering quickly enough resulted in reduced confidence from the business
  • wanted to be agile, but not capital “A” Agile – did not want to lose sight of goals
  • started with customers breaking down projects to deliver value
  • solution delivery framework – Idea -> Discussion -> Plan -> Build -> Implement
  • needed to improve communication around intent of project – created a “project picture” to give context
  • found out that they did not know enough about stories – started too early – more in planning phase
  • standups – walk the wall, back to front rather than the 3 questions as they missed the picture of progress
  • ATDD using Cucumber and Watir – testers break the build, just like developers
  • one floor, open plan environment
  • big release walls – give management a view
  • can now to deliver to Production every 3 weeks and high quality

Panel Discussions

The panel discussions covered some awesome questions from the audience. As I was lucky enough to be asked to moderate the panel, I did not get the opportunity to record any notes from this session.

Sydney Go Inaugural Meetup January 2011

Google GoI got along to the “Googleplex” when I was in Sydney the other week, and with Steve Dalton checked out the inaugural Go Meetup. I have spent very little time looking at Go, so was interested to get some background into what it is all about.

Andrew Gerrand gave (part) of a talk on Practical Go Programming (I say part because it turned out to be a discussion with the slides rather than the talk). The slides are available here, but the talk is available as a recording from OSDC 2010.

Steve Dalton also interviewed Andrew Gerrand on the Coding By Numbers podcast earlier in the day, which is well worth a listen.

Agile Academy Meetup: A is for Agile, the start of something good!

MeetupAgile AcademyIt’s that time of year where you start to clear the decks for the next year, and, in amongst a bunch of files on my hard disk, I found my notes from the Agile Academy Meetup from April 2010 in Brisbane, which I thought had been long lost to binary heaven.

At this meetup, Phil Abernathy presented an introductory agile session entitled “A is for Agile, the start of something good!” He had some good some refreshing points, and some of my notes from the session are here:

  • why change – better, faster, cheaper – key driver, but customers have always wanted this even before the Global Financial Crisis
  • RAD – “the good old days”
  • agile is evolutionary – developed over time from RAD, XP, Scrum, etc…
  • pendulum swing from waterfall to agile is a bad approach
  • agile is made up of values and principles plus technology, social and management practices
  • values and principles are not enough, so the only way to implement these are practices – social, technology and management
  • being accountable is a key value, but gets harder as agile teams work closely together, so you also need courage, respect & honesty as well
  • wisdom of the crowd is always better than the best person in the group
  • simplicity is the most difficult principle to implement – humans always want more detail
  • self organization does not mean no leadership – it means even more leadership
  • if you get kickoff of your project wrong, it will always go wrong (regardless of waterfall or agile)
  • agile successful in non-software development projects – biggest demand in Suncorp is from the business
  • benefits linked to outcomes which are linked to features which are then linked to stories
  • agile is different to RAD because we don’t prototype, we build… iteratively
  • in agile we don’t write documentation until we have shared understanding, but there is a discipline to the amount and the need to refactor
  • issues with agile adoption are usually on the IT side of the fence, once the business have seen it they will be the biggest supporters

Phil then answered some questions from the audience:

  • PRINCE2 now has a large agile component to it – is no different because agile sits on top of it – agile has rigour and will work with any project management method
  • governance – heartbeat of the steering commitee must be the same heartbeat as that of the project
  • selling agile – you need troaching – training and coaching together, it’s a change management journey
  • don’t expect a successful agile project to sell agile in the organisation, you will get resistance – need to manage transition from pilot to scaling, need buy-in to the pilot to avoid this
  • where do you put agile artefacts when you don’t have walls – mobile whiteboards, walls, a company in San Francisco just got seed funding for agile walls
  • do not recommend using a tool over tangible materials

Agile Academy Meetup: A Business Value Focused Model for Story Identification

MeetupAgile AcademyShane Hastie presented at the September 2010 Agile Academy Meetup in Brisbane on the topic of user stories. Here are my notes:

Agile Academy Meetup Shane Hastie

  • use models to break complex problems down to manageable chunks
  • Standish Group – number of canceled projects has increased with agile and number of wasted money projects have decreased – trend seems to be that agile is driving the cancellation of bad projects
  • business value is not delivered until it is in production and being used by the users
  • nobody ever does a business realisation review – 9 months after the project ask did we deliver what we said we would deliver
  • turn the story card around to emphasise value – so that… I want…
  • users is a bad term – implies they are addicted to something – they are customers of our service, victims of our software
  • think about who is your customer, what are their real needs – pin a picture up of them up on the wall to remind you to ask what they would think
  • events happen – business events (random but we need to be able to respond them when they arise), temporal events (happen due to the passage of time such as end of month, annual backup, daily backup, quarterly review) and conditional events (happen because something else happened)
  • suggest adding when to epics to track events as a… when… I want… when… so that
  • elementary business process – done by one person (or small team) in one place at one time – this is the level we should usually look for our epics
  • look for CRUD – a business process that is supposed to happen
  • latch onto nouns in customer conversations – a trigger that something is done
  • look at the management levels – we are good at the immediate needs of the workforce, but what about the needs of supervisory management, middle management and top management
  • think about the impact of data from external sources – what if the GST percentage changed tomorrow (it is in New Zealand!)
  • the model for epics – As a.. When… I Want… Using… So That
  • add the CRUD to the using statements to confirm the process
  • next level down look into Jeff Patton’s story mapping process
  • the smell of stories – PERFUM (Performance, Efficiency, Functionality, Usability, Maintainability) – in some cases if you don’t look after these, a refactor will mean rewrite the system
  • value is in the delivery of a complete epic
  • epic model helps you figure out how big the project is without going to a low level of detail
  • epic model is based on early work by Ed Yourdon and works on any project, including waterfall

ANZTB SIGIST Brisbane: Agile Testing & How We Need To Change

ANZTBA couple of weeks ago I had the opportunity to present at the ANZTB SIGIST Brisbane September meeting with my colleague Rene Maslen. Our talk was “Agile Testing and How We Need To Change” and the slides are available on Slideshare.

Some of my other colleagues also presented on the night including Ben Sullivan and Brent Acworth who spoke on BDD and some work they are doing on an open source framework for JBehave and Craig Aspinall who spoke on Automated Black Blob Testing.

Alister Scott had some nice words to say on my presentation on his blog and was also nice enough to take some pictures, which I have embedded below:







Alec Sharp: Avoiding the Pitfalls – 7 Common Mistakes in Working With Business Processes

Earlier this year, on a long flight from Brisbane to San Francisco, I had the good fortune to sit next to Charles Follett, a process analyst with the Stratam Group . I had noticed the book he was reading on management thinking, and that led to a lengthy discussion on coaching and the similarities between the agile methodology and business process re-engineering. After that discussion I had a made a note to learn more about this, especially given some of the tasks I undertake as an agile coach involve process change (either directly with the team or the project they are undertaking).

From Miscellaneous

Last week I had the good fortune to get invited to see Alec Sharp present in Brisbane on business processes, thanks to my friends at Software Education. They had mentioned that he has been the highest rated speaker at previous Software Education conferences, and after seeing his presentation style I can see why. The following are my notes from this course, however if you have any interest in business processes, I highly recommend getting along to one of his classes.

1. Clarity on what a business process really is

  • can be anything from product lifecycle management to writing business processes
  • an end to end business process, more than the activities, flow, documentation and efficiencies
  • sometimes important activities are seen as separate processes, sometimes the sequence, metrics and rewards work against the original intent
  • don’t focus on the work but the result
  • name processes in verb noun form, flip to understand intent, the process must have an output that can be counted eg.  issue permit vs handle application (flipped you are issuing a permit whereas handling an application says nothing)
  • avoid mushy verbs like manage, monitor and administer
  • name a process from the customer perspective
  • management kiss of death is “improve efficiency”, usually efficiency goes down and yields little or no benefit
  • telco example – didn’t identify the true overall process, confused organisation with process, ignored the customer, didn’t measure what the customer cared about (time to provision a service)
  • usually a trigger has two or more results (at least one for the customer and one for the organization)
  • “local optimization yields global suboptimisation” (Eliyahu M. Goldratt in The Goal)
  • when making change you need to demonstrate not convince
  • three types of triggers – external event, time, condition
  • look for boundaries – usually a token change or one to many event
  • keep focussed on the happy path
  • sometimes useful to start at the end result and work the process backwards
  • three types of processes – governance, core enterprise and enabling processes
  • doesn’t always look like a “linear noodle”

2. Recognise negative reactions to process

  • people get nervous when we look at process
  • it’s not about downsizing, its about eliminating friction, etc…
  • backlash against labels – “sick sigma” and “six stigma”
  • use the right tool for the problem, the wrong tool might sour the organization

3. Address cross functional issues, make it blame free

  • Freakonomics – best seller, about the underlying reason as to why things happen – the law of unintended consequences
  • different functional goals – sales bonus, maximize machine utilization, lower shipping costs, etc – collectively harms the entire process because nobody is really looking at the entire process
  • Boeing – planes always move when being built, everything is about the plane
  • functions are good – align expertise – just need to coexist with the process
  • criticism is hard to take – make the process clear, visible and blame free
  • figure out what the processes are, align performance goals, processes need an owner to set direction

4. Clarify business process to information system linkages

  • success is usually process first and IT secondary
  • process success – consistency and repetition
  • configure software in a process aware fashion

5. Avoid the deep dive into complex, detailed models

  • make the process visible
  • process decomposition – visual overview of process, good for high level, clarify scope, no more than three levels
  • swimlane diagram – a workflow diagram should should show the flow of work, tell the story, simple
  • BPMN – Business Process Modelling Notation – made for manufacturing so 95% of notation is useless in business, but recognised standard and tools
  • common errors – misunderstanding the process, hiding parts of the process through sanitisation, too much detail – need a balance of sanitisation versus detail
  • simple diagrams! – who, what and when – show time (arrows only out from right and in from the left), simple symbols (boxes and lines only), many cases for a process may need multiple diagrams (simpler)
  • progressive detail – scope –> content –> detail
  • successful techniques will always be used outside their area of domain
  • workflow modelling good for requirements – stop workflow modeling when the work stops flowing – drill down to use cases and service specifications and then data modelling
From Miscellaneous

6. Take a holistic view to understand all requirements

  • workflow and systems are important but are only two enablers – also motivation and measurement, human resources and policies and rules and facilities (consider these for every step)
  • 55% of knowledge workers spend their day on administration when support staff are laid off (Slack by Tom DeMarco)

7. Why would they choose your process – differentiator

  • strive to be great at one and good at two – operational excellence, product leadership and customer intimacy (Discipline of Market Leaders)
  • no clear differentiator usually means not good at anything
  • silos with differentiator differences is the classic Dilbert sales versus marketing
  • different processes can have different differeneiatots

Agile Academy Meetup: Agile For Startups

Agile AcademyAdrian Smith presented at the July 2010 Agile Academy Meetup in Brisbane on the topic of Agile for Startups. Here are my notes:

Agile Academy Meetup July 2010

  • startups should not last forever – transitional to success or failure
  • need an idea or an idea where you can do better (copycat business)
  • 90% of startups fail due to lack of customers
  • good people are critical to success – technology is a lever to productivity, no more than in software development
  • “The best programmers are up to 25 times better than the worst programmers” (Robert L. Glass)
  • startup lifecycle – building customers vs building product
  • aim for high quality code to reduce technical debt – will allow you to react faster
  • an office is sometimes seen as an expression of rank, whereas the office in an agile team / startup should enable innovation
  • use cloud based infrastructure to scale up and down and not be tied to any one location, also good for remote workers
  • startups cannot support the same number of roles as a typical agile team, need to dual-role and work out priority
  • startups can choose the technology, and that choice can govern the types of people that you can attract

Some of the tools that support agile startups:

  • Skype – fantastic for collaboration, desktop sharing
  • Yammer – effective to create internal collaboration within company, to share ideas, etc.
  • Teleport – great for screen sharing, especially dual screens
  • iChat for screen sharing
  • Harvest for time tracking (low cost)
  • Saasu (Australian), is like a better hosted MYOB, free for 20 transactions or less a month, payroll and BAS at the press of a button
  • Pivotal Tracker for project management and Scrum, other tools around like Scrum Pad
  • Unfuddle for ticketing, version control with GitHub
  • Balsamiq for mockups, iPlotz has better functionality (low cost)
  • CodeYak is in beta for code metrics and tracking over time
  • Hudson for continuous integration, Pivotal Labs has a free dashboard (Pivotal Pulse)
  • Heroku for deployment with a pure Git workflow, Linode for hosting
  • GetSatisfaction for customer feedback, rating features, etc…
  • Google Analytics for tracking web site traffic, Trendly for more meaningful interpretation
  • Startup Search is a good place to see if somebody has else has done something you’re interested in
  • Resources – The Four Steps To Epiphany by Steven G. Blank (free) and Getting Real from 37 Signals (free online)

Question and answer session:

  • showcase in a startup – get deployed to deployment environment and get customers using it, using new features as they come along
  • virtual office that make you seem big – a cost that you don’t need to spend, especially if using your own money
  • key agile – setting consistent expectations in relation to code quality amongst all developers, need a minimum viable product to showcase
  • collaborate closely with customers, have people on-site with customers who are using it, Skype calls to customers using the product
  • starting with agile – determine your priority and make those tasks transparent, make sure you are working on priorities and to an agreed quality
  • regret some features that were initially put in that were thought to be useful (make features work hard to get into the product initially)
  • biggest obstacle is getting to a minimum viable product, risk that product is not usable or is superseded by another product

Agile Alliance Brisbane: Changing Role of a Tester

The inaugural Agile Alliance Meetup in Brisbane kicked off on May 13 at the Hilton, Brisbane with a talk by Kristan Vingrys (Global Test Lead for ThoughtWorks) talking about the changing role of a tester. I have had the good fortune to work with Kristan a couple of times this year, so was looking forward to catching up again as well as seeing this talk.

Among other announcements, Robin Mack is the Brisbane liason for Agile Alliance Australia and they are currently looking for volunteers, sponsors and speakers.

The following are my notes from the session, the slides are also available online:

Agile Alliance Brisbane Kristan Vingrys

  • testing – find out what system is and what it does
  • testing is not about putting a quality assurance stamp on software before it goes out the door, its about understanding the quality of the application
  • traditional testing – V model – independent, based on a feature complete system, exit criteria from each phase
  • collaboration – more related to agile – single velocity for entire team (not just developers), co-located and interspersed team, loose boundary of roles, work closely with developers (not throwing information over the wall)
  • should not be iterative testing (testing 2-3 iterations behind), independent or separate velocity
  • stop finger pointing, no longer a gatekeeper
  • tester should be able to check out code, try it out whenever they want to
  • tester should have direct contact with business to break down direct animosity with the developer
  • measured by value added to the team not by defects found or number of tests written
  • test early – make sure the story is testable, do all testing earlier (including non-functional testing such as UAT)
  • Acceptance Test Driven Development – building quality in, not testing it in, this is not just about automation
  • handover – developer should call tester over to ensure that the requirement has been met, give the tester the keyboard for 2 minutes to see if they can break it before check-in
  • exploratory testing – difference between exploratory and ad-hoc, it should have a plan, allows to execute test cases while learning the system, a good approach to test the tests, looking for different ways to learn about and break the system
  • automation – a good way to continually do regression testing, it is not a test strategy, is not just tests (can also be used for automated assisted testing, trawling through log files, etc), automation is code so treat it like code (not using good behaviours will end up as brittle code)
  • unit testing – benefits the tester, know what comes from the developers has been tested to a certain level
  • continuous integration – push the regression suite so that it becomes the responsibility of the team
  • pairing – way to transfer knowledge, to and from the tester, focus on higher value testing
  • co-location – can talk directly to the team about issues or further understanding
  • standups – understanding what the team is doing, what they are working on, know areas of system to spend time on or stay away from
  • automated functional testing – not running the same test again and again and again
  • ratio of testers to developers – hard to gauge, depends on the skills, not everybody on the testing team needs to be a tester
  • test analysis – what are we going to test, understand requirements, architecture, test execution (by a human or a machine), environment management (testing the right thing, a stable environment)
  • “you can’t find a defect if it doesn’t exist”
  • troubleshooting – being able to track down a problem, find the artefacts and hand it off to the correct team to fix
  • every role on the team should contribute to testing in some way
  • metrics that you collect change when you move from waterfall to agile testing
  • generating a test report should not take very long – should be an indication as to whether someone needs to have a conversation with me, answers questions about the state of the test team
  • people make assumptions on vanilla metrics

Metrics:

  • points in test over time – number of stories that are in the testing column on the storywall, indicate if the team is keeping up with testing activities
  • outstanding defects over time  – how defects are tracking over time
  • number of bounces per story point – bounces back and forward between the development and the testing columns
  • not all defects need to be logged – only needs to be captured if it is not going to be fixed straight away, better to spend time on automated test to check defect will not come back rather than logging it
  • be aware of fake defect debt – when a story gets pushed through and defect/s get raised to be fixed later
  • add value by getting team focused on quality

Then there were some questions from the crowd:

  • environments – want enough environments to avoid test scheduling (where possible), happy to do UAT in an earlier environment if it means you are getting early feedback that is useful
  • tester velocity – should be focused on the velocity of the team and the definition of done, investigating using Kanban techniques to set a limit on a column (perhaps for testing to enable team flow)
  • automated tests – depends on where business logic, for AJAX you need to do more UI tests, main issue is getting tests running as quickly as possible and getting fast feedback, prefer not to test via the UI because it is very fragile
  • skillsets – pulling a team together will look at troubleshooting and may need to hire somebody just for this task, a team with developers that strong minded makes it hard for a tester to get their opinions across
  • test plans – does not necessarily need to be a document, the important thing is that there is a shared understanding, should never be signed off because it should be constantly revisited
  • skilled team of testers and developers – who should write the automated tests – look at skills, should not be written by those whp do not understand programming or test analyst – answer what I want to test and how do I go about developing it
  • regression test definition of done – business need to articulate the level of risk they are willing to accept, understand where the business value is in the system, finding a defect may encourage you to spend more time