Please excuse typo’s, grammatical errors, poor style/structure and general rough-ness. I’m continuously deploying my updates to live whilst attending sessions at Agile on the Beach…
I’ve tried to record the sessions accurately, without personal embellishment.
Be warned: This post is very long. You should use the links below to click ahead to my notes on the sessions that sound interesting to you.
Day one
JB Rrainsberger (@jbrains): Software Craftsmanship Keynote
Simon Brown (@simonbrown): Agility and the essence of software achitecture
Steve Freeman (@sf105): TDD, That’s not what we meant!
Jon Tilt (@jontilt): An Agile Journey – Making the Elephant Dance
Marcin Florean (@mfloryan): #noLearning
Chris Oldwood (@ChrisOldwood): Test Driven SQL
Lynda Girvan (@LynGirvan): Putting the BA into BAcklog: Agile in the business context
Day two
Bjarte Bogsnes(@bbogsnes): Day 2 Keynote – Beyond Budgeting
Seb Rose (@sebrose): BDD by example (Double session)
Nick McKenna (@nickmckenna): There Is No Agile
Steve Smith (@AgileSteveSmith): Release Testing Is Risk Management Theatre
Panel
Software Craftsmanship Keynote – JB Rrainsberger (@jbrains)
Why aren’t we rich yet?
We think of Agile as a mindset. We cast it as some zen like thing, rather than thinking about it as a bunch of discrete practices (like Kanban, reterospectives and stand-ups/daily scrum), we use awesome phrases that we understand but others don’t. “You have to BE agile”. Bill Caputo famously said “Extreme programming isn’t out there it’s in here”. This advice isn’t useful.
“Stop it!”
Now we look like utopian nuts – or irrelevant.
I read the book Switch by Chip Heath. Chapter 3 was about scripting out the critical moves. If you can get good at these dozen or so practices you’ll probably learn to generally do the right thing.
I think we’ve scripted the critical moves, but we’ve failed to convey the vision. Agile is a brand. It is seen as an ethereal thing. We have not conveyed the practical significance of what we are trying to do. In some ways it feels like in 15 years us technical guys are still having the same conversations with the business guys or other technical departments. We haven’t budged an inch.
We need to communicate (or sell our ideas) to those around us. The new strategic selling. Miller Heiman. This book gave me a model to debug sales gone wrong.
Grandma’s Ham: http://www.dailypaul.com/295661/why-we-cut-the-ends-off-the-ham
So let’s look at the practices:
Stand-up: This is actually a high risk strategy that requires aa lot of trust. We are asking people to stand up in front of their colleagues and discuss what they did wrong. Face-time anti-pattern. 80% done anti-pattern. Travelogue anti-pattern. Now it is your chance to complain, get it off your chest.
What’s missing: Risk. The primary point of this meeting is to uncover risks/blockers/people who are stuck/slow and need help. Go and read Waltzing with Bears.
Kan-ban: You end up with too much in ToDo. You also get too much stuff slipping through the net as high priority tasks pop up. Add an inbox section for any random new things that pop up. From the inbox it can be moved to backlog or in doing.
Involving the customer: We still see teams who talk to the customer once and 6 months later and deliver them some code.
Talk in examples: When talking to business guys use example of the functionality that you are expecting to ensure you understand each other properly. “At this point I expect to see a green A in the bottom right corner”, etc. This bridges the gap between thee high level concepts and the specifics.
Story prioritization: = fighting between stakeholders. If you need 8 stories and we only have space for 5 you have a bigger problem. We need to split these out into smaller tasks and work out the most important parts of each one. This is exactly the point.
Pairing: It’s not just about writing code together. It’s about sharing information and understanding. Information osmosis. The bottleneck is the pace at which we learn. Pairing with the same person misses the point. You need to be promiscuous. You need to have confident humility.
Reterospectives: People either don’t speak, speak too much about everything that is wrong, or paint a rosy picture. Read the 5 dysfunctions of a team.
TDD: If you aren’t focusing on cleaning as you go you are missing the point.
CI: One of the most misunderstood practices. It is not about tools, its an attitude. Make sure the first thing is fixed before doing the next one.
ScrumMaster: Mild form of Stamford prison experiment. If there is a master, there are slaves. This is not what we had in mind, but it is inevitable.
Simon Brown (@simonbrown): Agility and the essence of software achitecture
Architecture need to be more accessible. Doing lots up front is a bad idea. Doing none up front is worse.
Agile teams don’t necessarily deliver agile architectures. Are ‘big-ball of mud’ monolithic agile architectures?
Are service based microservices agile? More moving parts. More complex.
Is there somewhere in the middle?
How do you visualize your architecture? Most people don’t use UML… So what do they do?
We need to agree on a common set of abstractions. (This is more important that common notation). In my view, a software system is made up of containers, which contain components which contain classes. And your done.
Visualing system context, containers and components is a good place to start. You need to be able to zoom in and out – and pictures are the simplest form of documentation.
How do we adapt/refactor an existing architecture?
It doesn’t need to be hard if you have a good map. A good idea of where you are and where you want to go. But what if the code-base does not reflect your architecture? This is why people start to distrust pictures. Can you see the abstractions in your diagrams in your code?
Example about how I refactored my layered architecture to reflect my component architecture.
Sketches get out of date. Why not auto generate the diagrams? Unfortunately the tools see the packages and databases etc but not your components that you define.
Just enough up front design
This phrase isn’t very useful for beginners. You need to do just enough to understand the structure. Every developer should learn how to sketch.
You need to do up front design to understand the risks.
Try risk storming. Drawing architecture on wall get lots of people with post-its to illustrate where the risks are. This will give developers a shared vision of what the design should look like. 
This is not big design up front – this is just enough to change their behavior.
A lot of people think architecture is too fluffy and conceptual. It needs to be grounded to the code. People need to understand it.
There is a bonkers misconception that agile is about not doing documentation or design.
Try architecture katas. https://archkatas.herokuapp.com/. 2 x 90 minute sessions. First will provide jibberish results. Second will see marked improvement.
Good architecture gives us agility.
Steve Freeman (@sf105): TDD, That’s not what we meant!
#istdddead?
Things have changed. Testing used to be a lower class profession, back when we drove without seatbelts and smoked indoors. Now we take testing seriously. We even refactor…
Occasionally.
Let’s review:
– Write test (accepting a task)
– Write code (doing the work)
– Refactor (design)
The problem. Without proper thought tests become:
– Difficult to understand
– Overspecified
– Obscure
– Brittle
– Meaningless failures
What we are beginning to see is: “Security Theatre” “Test-driven Theatre”
What should we look for in TDD?
– Steady, incremental progress (When you are doing it, it doesn’t feel like you are going very fast… but you just keep moving. The alternative?: I once spent 3 weeks trying to find a bug. Boom and bust programming.)
– Constant positive reinforcement
– I think before I code (sometimes I’m about to write tests and I realise I don’t know what I’m writing tests for – and I go find a domain expert. This is the sort of thing we are looking for.)
– Things break when they’re supposed to (if you are being blocked by the test framework, sometime this means the test framework is doing its job)
– Surprising designs emerge (better than what I would have designed up front)
Lessons we’ve learned:
– Write readable tests. (If I can’t write a sentence to define my test, I probably haven’t defined my work properly yet.)
– Interfaces not internals. (If I can’t access the data I need it is time to refactor).
– Protocols, not interfaces.
– From simple to general. (start with the simplest thing you can do and take incremental steps)
– It’s about explaining domain, not about proving correctness of code.
– When you are lost, slow down. Running around in a hurry doesn’t help.
– Test at the right level. Unit tests are important, but they are not the only type of tests.
– Nowadays there is careful monitoring too. Throw the code out and monitor like crazy. But this doesn’t give us design feedback so by itself it isn’t enough.
Why does TDD work?
– It’s focused. Without TDD it is easy to get lost. TDD keeps me focused.
– It’s concrete. We aren’t good at abstraction. Brilliant Plato metaphor: In software we are often abstracting concepts into their form.
– It’s empirical. Does this work? Lots of feedback about the actual code.
– It makes devs question requirements from product managers to help them define features. Which makes product managers raise their game.
The critical slide. We need to add a new line to the traditional diagram… If writing the test is hard, it is also time to refactor.
Jon Tilt (@jontilt): An Agile Journey – Making the Elephant Dance
Jon works for IBM and talks about doing agile at scale.
Agile for 5 people is easy. Doing it at scale has problems. This is what we found at IBM and how we dealt with it. 26,000 software engineers on every content (except Antarctica) in 80 locations, on different timezones, who speak different languages and have different cultures. In total 400,000 employees. Many companies have been acquired and they have their own cultures/processes. We can’t get people on the same timezone or continent for a traditional stand-up. We agreed to use English as a standard language which helps.
In the old days IBM was a slow elephant that owned the market and called all the shots. It was easy. Now we need to be agile to compete with our competitors. This became apparent in the early 90s when we got to a point that we were 2 weeks away from going under.
Agile, fundamentally is about business. That’s why we needed to do it. We suffer at IBM because we do not have a survival of the fittest mentality like you get in start-ups. We struggle to kill products because we are a wealthy company and we don’t need to. We have software that has been running for 40 years, despite the fact not many people are using it.
Look at the agile manifesto. It is impossible for us to live totally to the left. For many of our people tools and processes are fundamentally important.
We went from a 2 year iteration to a 4 month iteration and asked each team to be release-able at the end of each iteration. We are getting down to one week for some of our best teams but we have a lot further to go. We are working in stepping stones.
We had to start training people. We gave hundreds or thousands of developers training on agile and lean. We set up evangelists. Passionate people who were circulated between the teams. We’ve turned around our inductions because often grad students know more about it that senior managers. We want to learn from them.
The reality is that all our work needs to be underpinned by tools. People and interactions are all very good in a small team but at enterprise we end up with all sorts of mixed tools/processes stuck together with sticky tape. We rolled out Rational (of course we would, we own it). That said, at first we were skeptical because we didn’t think we could use it. Over time we were able to evolve until we had rolled it all out. It came from the bottom up.
This standardized toolset has helped us no end when it comes to auditing. “Show me that you wrote, and tested, and reviewed that line of code.” A 2-3 day job now takes 5 minutes.
The dashboard functionality is wonderful because working across different teams and different continents, live dashboards are the only way that we can see a general overview of the work being done. (Rather than each team providing slides that are out of date by the time we have a review meeting).
We were doing ‘constrained agile’. We were promised the golden agile pot of gold but we can’t release that value yet for governance reasons. It’s taking us 6 months to get our code into production. We are looking at DevOps as a way of allowing us to get our relatively quick dev iterations into production more quickly.
We are now hiring in young designers. (Not software engineers). They are coming in and shaking us up with radical ideas, which is brilliant.
Design thinking:
– Understand
– Explore
– Protoytype
– (???)
Fail fast, learn quickly, iterate.
(ps. We’re hiring)
We are trying to move our thinking away from looking at a small number of metrics to measure the health of our products. We don’t just look at bug IDs. We look at all sorts of metrics and we create dashboards. Could I ship this to production?: 
We talk about ‘time to’ metrics. “I want to know how safe my product is to ship in the time it takes to make a cup of tea”. (Reminds me of coffee break builds!) In reality some of our tools take 2 weeks, but we are making progress.
We don’t have all the answers, and we aren’t perfect yet. But we are doing this at massive scale and we are moving in the right direction.
Marcin Florean (@mfloryan): #noLearning
“I’m really sorry you came to the conference. You will not learn anything today.” Marcin Floyan – Lead software engineer at CompareTheMarket.
How many of you are paid exclusively to learn? No-one? How often do you know in advance how your end solution will look? Almost every day we are going from the unknown to the known.
The classics put it very well:
“I cannot teach anybody anything. I can only teach them to think”
Is our learning primed, deliberate and validated?
Primed
Example of scientific research into scurvy in the 1700s and 1800s and how people didn’t believe in solutions for many years, despite compelling data. People believed in sea ghosts etc.
Example of Victorian hospitals where one hospital had a far higher mortality rate. Mortality rate dropped dramatically when people started washing their hands. People believed surgeons were educated and already had clean hands.
In both cases the original people who made discoveries were rejected. Society cannot except solutions, even when backed up with data, if they are contrary to our belief systems.
“It is impossible for anyone to begin to learn that which he thinks he already knows.”
Deliberate
My daughter went to her ice-skating class. She didn’t practice the thing she was told to. She practiced a different exercise because she knew she was good at.
Java developer with 10 year’s experience? There are other languages that are better at solving some problems! Didn’t you learn anything? Otherwise you might have tried to do something new/different?
We need to be deliberate to practice the things we know we need to improve, rather than working within our comfort zone.
This: 
(Flow, balancing existing and new skills)
“Mastery of knowledge alone isn’t sufficient”
Kolb Learning Cycle (Google it)
“Whatever you would make habitual, practice it…”
“You want to do it – do it. You want to stop doing it – stop doing it”
With deliberate learning we need to understand that generally our productivity will go up, but there will be pits of despair and frustration. We will probably get worse before we get better. We need to be ready to invest in that.
Validated
I read the same book to my children every night for 6 months – but I cannot recite it. I can recite a Polish poem I learned 20 years ago. Why? I knew I had to recite the poem in from of my team. I was assessed on it.
#activelearning
Confirmation Bias: We will look for evidence that confirms what we already think/believe. Surely we must be good at agile now because we did the training?
Dunning-Kruger effect: Really experienced people over-rate their peers.
Save on read: We reinforce our own conceptions when we remember scenarios.
Do we ask questions? When we are given requirements, do we challenge them? When we write code, do we challenge it?
#tdd
What have you changed?
If you are learning, you will be changing the way you work.
The law of learning entropy
Without positive energy, everything turns to chaos. If you don’t put in the determined effort, you won’t be able to learn.
My validation that I have learned enough about learning is this talk. I wanted to learn about learning. If I can do a talk on the topic of learning I probably know about it.
Primed, deliberate, validated
“If you’ve done something with something you’ve learned, then perhaps you have learned it.”
(maybe?)
Chris Oldwood (@ChrisOldwood): Test Driven SQL
My regular readers might not be surprised that this is a session that I have been really excited about.
SQL Unit testing
Functional Testing: Tests should verify the publicly observeable behavior not thee choice of implementation.
Development Sandbox: Isolation, Fast feedback, Deterministic, Tooling.
Organisations tend to be hostile to the idea that developers should have their own databases on their local machines. Instead people start using integration environments for dev – but the shared environment causes chaos as devs get in each others way.
Tooling has advanced. For example SQL Express is now free and because we don’t have any data it doesn’t matter if we have a cranky old machine.
SQLUnit: https://github.com/chrisoldwood/SS-Unit / http://www.chrisoldwood.com/sql.htm
SQL Unit is a unit testing framework that Chris has developed for SQL Server.
Most of the talk is a live demo. Here is an online version:
Chris Oldwood, Test Driven SQL 2014 from The Lens Box on Vimeo.
The upshot is that Chris, in the early 2000s, created a framework for developing the database as code. He was practicing ‘declarative database development’ long before Microsoft coined the phrase. He found a way for developers to create their own sandboxes of the code and easily commit it to source control before the modern incarnation of Visual Studio database projects or Red Gate SQL Source Control. Inspired by JUnit he created a unit testing framework called SQLUnit that did not require implausible database permissions. He also found a way to automate the tests and achieve continuous integration.
TDD for the database is not impossible. Testing our functions and stored procedures should be a requirement.
Lynda Girvan (@LynGirvan): Putting the BA into BAcklog: Agile in the business context
BA is about analyzing the business needs. You don’t all need BAs, but you all need to have someone doing BA.
Who works out that IT is the solution to the business problem? We need to think holistically about whether X is a good thing for the business. When you have a business case, who does the business analysis? Product managers? Some are great, but do they all have the skills and training in BA?
Let’s look at scrum – It all starts with a backlog… Where do those post-its come from? Someone somewhere is doing business analysis.
I’m trying to fit a 60 minute talk into 45 minutes so I’m going to do the agile thing and prioritise my backlog and deliver the most important slides! ;-P
Consider the whole:
– Processes, policies, legal, people, organizational structure
When thinking about delivering a business system we need to consider all of these things. Scrum doesn’t go into this detail, but someone needs to. Agile focusses on software development. Why agile? Economy, demanding customers, lead time, reliance on it. This is true of whole business not just IT.
Agile manifesto: Let’s replace ‘Working software’ to ‘Deliver value to customer’ and suddenly we see that agile has nothing specifically to do with IT – its about working in teams in a business generally.
In IT we are applying it but we should be applying it to the whole of the business and we should consider the whole org, not just IT, in our agile processes.
Let’s think about the primary and secondary processes in and org. If we are honest, in most companies IT is a secondary/support activity. Let’s try to apply agile to whatever our primary activities are. What if we got HR or procurement doing agile?
Agile modelling. (I’ll admit, I don’t know enough about BA and I didn’t keep up with this but I’ll Google it later.)
Do it JIT (just in time).
Systems thinking: Understanding that a system has a bunch on interrelated parts. This is true not just of your code but also of the businesses. BAs are trained on this.
(We chose the next topic to discuss from a list with a vote… Prioritising backlog.)
Software processes don’t kill systems, people do.
All the processes work. Waterfall can work! The challenge is whether the people can accept it. Let’s think about when agile has gone wrong:
Heathrow Terminal 5: Opening terminal 5 went wrong. Cancellations, delays etc. In actual fact, the building, the software and the machines were working, but the people, didn’t know where to park, couldn’t get through security, didn’t know where to go and didn’t know how to use the software. A traditional project manager might not see this but a BA would.
(Another vote.)
Decompose goals, NOT functions
Goal: book a course
Lets break it down further:
Goal: Book one course for one person.
Later: Book a course for two people. Book a course for multiple people. Book multiple courses.
Think about minimal viable goal. Start delivering value sooner. Deliver early value.
Breaking down to minimal viable goals is something that in my experience BAs find natural.
Functional decompostition of teams
.NET teams say ‘we are agile but the DB guys hold us back’. A BA says ‘well where are the DB team?’ ‘Why are they holding you back?’ ‘Why aren’t they in your team?’
Sometimes developers need to think about who is paying for the features. Is it actually your end user? Make sure you have someone in your team who has the right skills to analyse your backlog and think about your end user. (Does your end user actually pay the bill?)
(Getting really rapid-fire now!)
The devil is in the detail
Process sequence Business rules Data requirements. How can you model the data using class diagrams. This is time consuming and something the BA can do within the agile team.
Tacit knowledge. We assume a level of understanding and knowledge and this causes problems. BAs are trained to spot this stuff.
BAs help to put the BA into BAcklog because…
They have the time to refine and apply these techniques
We are good at working with people
BA isn’t just for Christmas
It doesn’t matter if you don’t have a BA, as long as you have someone with BA skills
Bjarte Bogsnes(@bbogsnes): Day 2 Keynote: Beyond Budgeting
Works for Statoil – energy company. Invests in off-shore wind.
You can be as agile as you like, but sooner or later you will hit the business machine. As companies grow they become bureaucratic, inflexible, slow, sad places to work. Just like as humans grow old – companies have the same pain. For large companies, we need to work out how to stop being inflexible. For start-ups we need to work out how to avoid going that way.
The case for change – What is the problem
Budget problems:
– Weak link to strategy
– Time consuming
– Decisions made too early and too high up
– Assumptions quickly outdated
– Prevents value adding activities
– “Accordian” forecasting horizon
– Bad yardstick for performance
Most people agree with this but continue anyway. But really, they are symptoms of a bigger problem: Performance
To explain, let’s look at traffic. We all want good performance/flow of traffic. This is managed by traffic lights (old fashioned/no sensors for this example). Who is programming these? The programmers who built the light many years ago. What is the alternative? Roundabouts! Who is control? Drivers. Users.
What is normally more efficient? Roundabouts. Many studies have proven this. The point is you do not have to wait for the pre-programmed red light.
What is more difficult? The roundabout. But we don’t get to just not do it because it is hard.
In which are values important? Roundabout. We are enforcing a culture of values and positive common purpose. We are asking people to be more conscientious. I would argue that this is highly relevant to business management.
Beyond budgeting priciples
(This is so much more than budgets. It is about the budgeting mindset you see in management.)
McGreggor: theory x and theory y.
Theory X: My employees are selfish and spend all their money on beer.
Theory Y: My employees are well educated, conscientious and they want the best for the company.
At Statoil, we believe that most of our employees are Y.
12 principles: 
It is not until principle 11 that we talk about cost. Cost is still important which is why we need to think about it carefully.
How can we predict, the autumn before, how it will be wise to spend our money next year?
It doesn’t help that everything on the left is about people and on the right it is about rewards?
Solving serious issues with budgeting. We use budgeting for three very important things:
– Targets
– Forecasts
– Resource allocation
These are all very important and we need to deal with them all separately, rather than fudging them all together into a single process. If I want to get a good budget for next year I will submit a higher forecast than I actually believe. All sorts of bad practices emerge that are poisonous.
– Target: what we want
– Forecast: What we think
– Resource Allocation: How we make it happen
The best targets are those that people set themselves. How can we separate these? Do them dynamically, let people set them themselves and be agile with these?
Financial performance: We rate ourselves against our competition. All our KPIs are relative to our competitors. The purpose of this is to drive learning (and in a gentle way, stimulate performance).
How do managers manage costs without budgets? We want to hear less of ‘do we have money for this?’ and more of ‘Is this really necessary?’ Working to a fixed budget is nonesense. You need to spend exactly what you budgeted last year. Not more not less. You have very strange motivations for making spending decisions. This is terrible. Yes we should be cost conscious, but we should be like this all the time, not just at budget time. Banks are open 12 months a year.
Absolute KPIs
Rather than looking at annual fixed budgets, we look at ambition level/burn rate. This provides more flexibility but still absolute.
Relative KPIs Unit cost/cost vs peers/bottom line focus only.
No KPI at all Strategic objections or actions only. Cost is still important and we talk about it lots. We still need to give good answers to our managers but there is no written budget.
In many ways it was easier when our manager would just give us a pot of money. Now we think harder about every cost. Pick the best approach for your system
People who abuse the system: Don’t put everyone in jail. Take them off and have the stern conversation. But don’t put everyone in jail.
The Statoil model – Ambition and action
(We aren’t perfect, we made mistakes, but we are making some progress)
Ambition to action scorecards. 
The bad news is that if we are competing with our competitors in balanced scorecards now they all use balanced scorecards too. So what do we do differently?
Hunt for the perfect KPI? I tried for many years to find it. I gave up. It doesn’t exist.
Albert Einstein: “Not everything that counts can be counted. Not everything that can be counted counts.”
Now we start with looking at people and organization – and trust me, there is always enough time to talk about the money! 
More than 1400 Ambitions to actions across the company. The way we create alignment is through cascading.
All ambition to actions are publicly available.
They can change whenever is appropriate (not annual, more frequent). Only control measure for big changes is to go one level up and to tell effected people for either big or small changes.
Finally, yes we measure KPIs, but then we discuss the results, whether they are green or red, and whether it was really successful. Targets are just the starting point of the discussion. We take a more holistic approach. Peoples’ bonuses are not solely tied to whether they hit their KPIs. That would be very dangerous.
Helge Lund CEO: “We have a management structure that is very well suited to volatile conditions.” (Roughly)
Seb Rose (@sebrose): BDD by example (Double session)
Apologies in advance, writing comprehensible notes during a workshop style session is harder than during a lecture style session. It is entirely possible that notes for this session are in particular need of refactoring and polishing up but I do not have time to do it right now. Please take with pinch of salt.
TDD, BDD, fooDD, BarDD… What is the difference?
http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/
They are called different things!
Cost of changing mind increases over time. In BDD we want the customer in the room as we are writing the acceptance criteria, using concrete examples. (Ask lots of questions about specific edge case scenarios – no assumptions)
Generalisation alert: Two types of people: Stakeholders and programmers.
BDD specifically is about the problem.
Dichotomy: Problem domain and Solution domain (classic venn diagram)
Ubiquitous language – we need a common way of communication. When translating between languages meaning gets lost. One customer I had had 4 meanings for the word ‘version’. Ambiguity is there in all our business and we need to find a ubiquitous language.
This comes down to deliberate discovery. We know we don’t know stuff. We are looking for the unknown unknowns.
Exercise – Defining Twitter: Got into groups, discussed twitter – we all learned something new by sharing knowledge and examples.
When planning a user story there will be a three amigos meeting between a dev, a tester and a product owner. All three will contribute ideas. These ideas will help you add new user stories and break stories down into smaller stories (always try to make smaller user stories). A story should take 2-3 days from being accepted and delivered (fully tested). It’s hard but it should be our goal – and it is possible.
Concrete examples help us to break down user stories and they also help our estimations.
Funny how greenfield projects tend to go quite fast and well. As they get older, they slow down. One reason why startups fail. They code very fast early on, get VC, slow down, VC leaves, they re-write, they never come back.
We want to turn an exponential age of project vs speed to develop graph into a general flatter graph.
[Aside: I wonder how this can align with Lean Startup philosophies?]
We want start-ups and experienced teams to look like a well-organized restaurant kitchen – not my own kitchen. We need to keep our kitchens clean. It is hideous to retrospectively write unit tests. You cannot stay agile if you do not write tests and clean code. You cannot write clean code if you do not refactor. If you can’t run good automated tests, you can’t confidently refactor – so you don’t!
Product owners will always want more functionality than the developers have time to deliver. Product owners need to demand that code quality is high, and they need to be prepared to expect less functionality in the short term.
Exercise – Rules vs Examples: Strong password rule guessing challenge. (teams created three password rules and then challenged each other to guess example passwords and then guess rules).
Examples and rules work well together. We need rules, but examples help us illustrate them. By using examples (e.g. 16 spaces) it allows us to write acceptance criteria (rules). Three amigos meeting. (dev, test and product owner). This is a minimum, more may be welcome. For example, with passwords you might want someone from security or legal.
Exercise – Creating user stories, requirements and examples: 
- Break down stories (yellow) into smaller stories – and still smaller (this frees up other teams to build on this)
- 3 amigos discuss requirements (blue) and examples (green). Discussing the two in combination spurs conversations between people from different perspectives.
- Focus on the most risky and most important things first.
- Our challenge is to create stories, requirements and examples to build a ‘create user account’ functionality for our new Twitter network called ‘Squeeker’.
Story gradually got smalller (for brevity I’m ignoring ‘As a __ I want __ therefore __’ pattern):
– User can create username and password
– User can add their own username
– User can use their email (only) as a username
Requirements:
– Username is a valid email address
– Invalid email addresses are declined
– Duplicates are declined
– When addresses are declined a useful error message is returned to user
Examples (what ifs):
(So many, wont list them all)
– Specific examples of legal email addresses following unusual patterns
– Specific examples of illegal email addresses
– Specific examples of adding already existing email addresses
– Examples of error messages in certain scenarios
Examples outnumbered requirements which outnumbered stories. Of course this is all great for working together and getting input from different perspectives. It is also great for sharing domain knowledge.
It also means we are delivering the most important functionality quickly (rather than bundling it up into large user stories). By breaking down the tasks into their smallest, most important and risky parts and thinking about tiny parts in isolation and how we test those parts we not only get the most important stuff done, quickly and iteratively, but we are also able to maintain code quality and release quickly. It highlights the importance of having a ubiquitous language – that we all understand each other. For example, what does the word ‘DONE’ mean?
You can do a three day course on this: http://kickstarteracademy.io
Nick McKenna (@nickmckenna): There Is No Agile
Why don’t you write documentation? “Well that’s agile isn’t it?” Agile is not an excuse for poor programing.
@nickmckenna: “what is agile?” Audience: silence. Day 2 of #agileatb. #agileotb #notWaterfall — Alex Yates (@_AlexYates_) September 5, 2014
Agile is not a single process. Different environments (enterprise, start-up, government, finance, consulting) you will need to work in different ways.
5 problems this year
Problem 1: Dogmatic adherence to a method
Agile is supposed to be a tool that sets us free – but the mechanics have become a prison. Why do you do it that way? “Well that’s how agile works”
People doing practices because that is what the book says, rather than understanding the problems we are trying to solve.
Problem 2: Single pace for all
– releasing once per sprint
– meetings for meetings sake at start/end of sprint, rather than ‘just in time’
– the meeting that people do choose to skip is the retrospective, but this is the most important bit. But why wait until end of sprint for retro. Why not do a 5 minute on every day.
– measuring velocity… Why?
– by doing the standard practices more frequently and more often you get to a point where you are doing all the stuff by habit and you no longer need the regular meetings to prompt you. These practices might have been revolutionary 20 years ago, but we no longer need the regular meetings as a crutch to keep us doing stuff that is now second nature.
– scrum was designed for small. It wasn’t designed for big.
Problem 3: Unhappy teams
– Agile won’t magically make people happy. You might need to do something more?
Problem 4: Burndowns
– One person I worked with created a graph with two bars. One is % of budget spent. The other is tasks completed. That was quite nice
Problem 5: Declining velocity
Steve Smith (@AgileSteveSmith): Release Testing Is Risk Management Theatre
Steve Smith: Agile consultant and Continuous Delivery specialist
www.alwaysagileconsulting.com/blog
My continuous delivery is more about the people side of things than the people side of things. (Automation is easy – people are hard).
Fundamentally I really, truly believe that release testing is a massive anti-pattern and burden on the business.
What is testing?
A choice/balance we must make:
If we do too much testing we get to market late. If we do too little testing we deliver crappy code.
Conventional, silo’d, QA teams fly in the face of making rational decisions about this choice.
This also delays releasing and costs $$$
Luckily no-one in their right minds now acts like this… (Or do they?)
Agile manifesto applies to testing. We need to have cross-functional teams (not separate teams) who work together.
When I think of smoke tests, unit tests, acceptance tests I think of a solid automated regression testing framework which allows testers to do valuable exploratory testing activities.
Working in a cross-functional team has been a wonderful experience. I’ve learned so much from testers about testing. We’ve produced great quality, testable, reliable code. But why is this so uncommon?
What I see today is lots of manual regression/release testing teams who are expensive, unreliable and delaying your processes to get code into prod (successfully)
By having separate teams responsible for stability/responsibility and authority/development bad things happen. Work in progress (WIP) sits on the self. Delays happen in hand-overs. Feedback cycles are slow.
Also, release tests can’t do unit testing. All they can do is manual or automated end to end testing. The scope of tests are large, they are slow, results are not as detailed, test coverage is compromised.
What really cripples test coverage: Release testers are given a black box, endeavor and time pressure. Release testers get blamed for not finding defects (madness).
If you have an agile team in front of your QA team problems get worse. The dev team is doing TDD, BDD which means there is more work coming through and not as many bugs to find.
So how do people fix this? Management says “now you have 2 weeks instead of 11 for release testing”. This is the worst thing you can do. You make the problem worse. Testers have even less chance to improve the way they work and they do less of the stuff they actually can do.
What we need to do is accept that release testing is risk management theatre:
Risk management theatre: Airplane examples. I can’t take a 200ml bottle on the plane but I can take 4 x 100ml bottles. Really?
Release testing is the most obvious form of risk management theatre in software development.
Testing is a continuous activity. Everyone is responsible for quality from the cleaners to the CEO.
We need to get rid of release testing. That doesn’t mean that we fire release testers. (I’ve seen it!) Continuous Delivery s about freeing people up not firing them. We should turn release testers to exploratory testing and make them work with dev teams.
The result?
More releases = lower probability of defects.
*Some maths*
Also, more frequent releases means we can find defects more quickly and give us better code.
So, release management is all cost and no gain. I know it’s counter intuitive – but we need to accept it.
Interesting phenomenon: What is your time to get a line of code into production?
How often do you hear that features in months and bugs in days? Why?! Why?! Stop it! You have worked this out for bugs but not for features.
Panel
I’m not going to make any effort to attribute comments to people and I missed a few answers – but this is what I managed to get down:
What’s the most interesting thing you learned?
Lots of talks on agile outside of software. Seems to be something that is really picking up speed.
If you have one thing to which you would like to say “Stop it!”…
Companies that try to use BDD to introduce ttesting without talking to customer. Communication/collaboration FIRST. Automation SECOND.
I want to hear ‘Agile is X’ less.
Believing your client knows what they want.
We need to stop arguing about the cost-effectiveness of programmer testing their code. I don’t care how you do it. It always has been cost effective. Stop debating it.
If you could change one thing about #agileotb…
More comfortable beds for accommodation
Better air conditioning
Soap in the hotel rooms
2 ½ day conference with fewer tracks
Do something different on last day to get interest from students and other locals. Something more accessible on first day.
Designated area for lunch/networking. More opportunities to meet people beyond beach party
What was the best thing about #agileotb
People
+1
+1
Great track set-up. Varied speakers. Varied attendees from different sectors (including gov).
Speaker line-up is ridiculously good. Keeping quality of speakers this high is critical.
Have any topics been under represented. How can we improve?
Ops, DBAs, Server admins (not DevOps – I mean the people who aren’t doing DevOps)
Teamwork and communication
What is and isn’t ideal for automation
Good to see some UX here but want to see more.
Not just optimizing process, but also building stuff people actually want.
What’s the most controversial thing you heard?
I need to clear the air: User stories didn’t start off evil…
I didn’t hear anything controversial? Last year someone said developers shouldn’t talk to customers
Jam or cream first on your scone?
*** NOISE ***
What hashtag would you like to see for a constructive debate?
#mehEstimates: but no-one cares
#noAbsolutes: irony!
#itsallabitcomplicated
#stopit
What topic should we have next year?
Practical advice on marketing to customers
Science
The language we use to talk about agile
Business models for agile business
Failed projects – and why they failed
I want to have customers here
Where do we go to eat?
Go to events square
Use twitter
Audience… Did you enjoy yourself
Very tired but also very positive murmurs!
Who will come back next year?
Sea of raised hands 🙂
That’s all folks
Good evening everyone… Now I’m heading off to Events Square for a pint.
Then the sleeper train back to England 😛 and home.