Right. Google I/O’s done and dusted. Unfortunately, while regular people are sleeping (or playing DOTA), we’re wide awake at the Cinnamon Lakeside. The reason: Colombo Agile Conference 2014 is kicking off.
Agile, in the techie definition of the term, is a software development methodology. Now why there’s and entire conference on a software development methodology is because this particular method (introduced in 2001) is literally revolutionizing the old way of doing things. It relies on a series of tight iterations throughout the dev process and a constant back-and-forth between everyone involved, so there is a fine art of balancing between speed, productivity and methodology. We’ve got Internet courtesy of Hutch Sri Lanka, a live twitter feed @readmelive and @readmelk, and the event is about to start.
Up first, we have Pete Deemer, a legendary figure in Agile circles.
“This is the really interesting thing about software,” he says, recounting a classic smaller firm vs larger firm example. “In software, skill beats scale.
“Start with the right why.
Let me share with you an email I received. ‘I found your name by Googling Agile best trainers. We’re running a waterfall model and the client wants Agile – the project starts in two weeks, send proposal immediately!’
That isn’t how Agile works. Agile isn’t a methodology: it’s an entirely new way of thinking. You need to know exactly why you’re going into this and what you’re getting out of it.
Agile isn’t a way of doing things well: it’s a way of doing things better.
As you start adopting Agile practices, you see everything you’re bad at. Agile becomes a tool for relentless self-improvement. You see what you’re good at, what you’re bad at, what you need to improve on.
Focus on your practices. The first thing: building cross-functional teams. The next: Test-driven development. Here’s an example: you write an automated test and you run it. The test will fail. And then we write just enough code to make the test pass. Then we look at the code and say “Can we make it simple? Can we refactor?”
Then we write another test. We run both together. The first test will pass. The second will fail. Then we write just enough code…
This process allows us to build tons of increments in small amounts of time while making sure our newest additions don’t break the earlier code. Most of the teams I’ve worked with, once they discovered test-driven development, have never wanted to go back.”
The third point: continuous integration.
Software defects are like a lion. Have you seen a lion cub on TV? It’s cute. You want to cuddle it. Give that cub six months and you try pet it and it’ll take your arm off. Sometimes a boy lion meets a girl lion and voila, new lion cubs. Software defects are the same. Some defects spawn children that are even cleverer than the parents.
“At the end of the day, working software is what keeps us honest. We tell ourself sweet lies “it’ll probably work”; “it’ll probably do the right thing.” At the very center of Agile is this methodology that lets you know what works, how it works, and why.”
Start with the desperate people. At Yahoo, we identified four teams that were already in failure mode and we rolled out Scrum to them. The thing is, when you’re failing, you have nothing to lose. And we just waited. After a while, the other teams started coming to us and saying “We want Scrum too”. They’d seen the performance. It worked.”
“Choose the right tools,” advises Deemer, recounting a lengthy tale describing how deeply a tool affects how a team works – and how the psychology of individual competition can break a project and lead to fingerpointing, as compared to a group In fact, the tool in question brought in individual burn-down charts and that became so deeply embedded in the company culture that a good team had gone bad. “It wasn’t a team anymore: it was a group of people at warfare with each other. What I wanted to say was ‘Take your tool, open the window, throw it out.’
That tool cost, in usual terms, a thousand dollars a year: but in actual terms, it cost that company $200,000 dollars in productivity – plus a thousand dollars – plus Pete’s consultancy fee. Losses all around.
“Resist the urge to tinker. I see this over and over again. The teams get the best practices and they just do them. They don’t customize those practices: they just do. And as they start to gain expertise, they get to a point where they can customize the process. Start from the bottom.”
Pete pulls up a hieroglyph-like graphics showing the difference between a boss and a leader:: the boss is sitting on a block being pulled by slaves, the leader is at the very front, pulling harder than all the slaves. The lesson? Change needs a leader.
“And the last thing on my list: see the big picture. You know, there’s a statue. This is a 7th century statue, found just outside Trinco. One of the most beautiful things our species has ever created, The life is clearly in this object.
This was created 1300 years ago. Now if you think about this – 1300 years if uninterrupted craftsmanship, architecture, painting, literature, music – there is no place that has had longer, richer culture.
I want you to look around this room.
We’re not sculpting out of stone and metal. We’re sculpting out of bits and bytes. The things we’re creating touch more lives in a single afternoon than this single statue does in years. This … is the big picture.”
And with that, Pete Deemer steps down: Gabrielle Benefield, one of the original creators of Scrum – is in. Her presentation is titled “Metrics that matter: outcomes over outputs.: it’s about how features aren’t necessarily gold – there’s has to be a balance, between features and how the target market uses them. It comes down to what your customers need. One example she uses is how improving the page load time for an ecommerce site improved the traffic and conversion.
“Understanding the outcomes of what you’re building is critical to understanding what your customers need. I’ve met lots of teams who’ve done what the contract specifies, but the client isn’t happy. The reason? They’ve got everything that the client wants, but not what the client needs. They haven’t understood the outcomes.”
“The big problem with a lot of contracts is that you’re ignorant of most of you requirements at the beginning. The contract lops in that ignorance. Also, most of your clients aren’t technical. So you’re basically asking people who don’t know the technical fundamentals to describe a system you’re going to build.
Agile gives a way around this. You build prototypes, gain feedback, incorporate that, so you cut out that ignorance over a number of iterations. That way you end product works.”
After the coffee break, we’ve got Henrik Kniberg on stage. Kniberg, in his own words, is in the business of optimizing IT companies. His speech is about risks – and the successes and failures that happen within the development environment, dishing out facts left, right and center – for example, the fact that big projects usually fail, regardless of methodology.
His advice? Evaluate the risk. “You can’t look at the gain of a solution until you look at the pain of a solution,” he says, pointing out that the easiest way to see if your product is wrong is to list all the hypotheses and build MVPs around them. Even when you think a product is done, it may not be done yet: you have to see how the users react to it.
“This is called software for a reason. It’s soft. We make changes fast. We build an iteration. We show it. We build another. We show it to the customer. Maybe he likes it. We incorporate his feedback, build another. And now maybe he’s satisfied: maybe he’s not. Either way, we’re constantly in line with that vision.
Maybe we’re building an internet bank. My first thing would be: the customer can see the amount they have in the bank. And we’ll get feedback: ‘I don’t want to see this on the web, I want it in an app.’ Whoosh. It’s a small thing and we’ll do it. And maybe the next change would be to let them view the next three transactions. And so on and so forth until we’ll have a really nice e-bank that is just right for their user’s needs.”
Kniberg draws from his experience at Spotify to see how this iteration also applies to a product you’re doing. Spotify came up with incremental changes that over time added up to an experience that constantly had something new for the users. They did this by coming up with tons of prototypes for each change and just seeing what fit.
“Remember: customer collaboration is good, but user collaboration is better. The customer might be paying for the product, but you need to understand how people are going to actually use it.”
Ilan Goldstein is up next.
“A large portion of companies are running what I call ‘lip-service’ Agile,” he says. “There are quite a few myth and corrupt adoptions brought out by poor education on Agile. So I’m going to bust some myths today. Let’s start right at the top:
1. A lot of people think Scrum is an acronym! It’s not. It comes from the game of rugby, where it’s a group of burlish rugby players joined together like a jigsaw trying to drive their opposition back.
2. Scrum teams are faster than traditional teams.Scrum teams work in sprints, that’s really fast!
No. A sprint is misused. Agile processes promote a steady speed that the team can maintain indefinitely. A sprint is a short jump to clear a hurdle right in front of you. It’s not that your teams are going to move faster. They may or may not be faster than a traditional team. But I’ll tell you what they will be faster at: delivering the most-value product the fastest.
3. Scrum is an approach just for software: it might be born from the software industry, but if you read any of the Scrum guides, you will not see the word ‘software’ or the word ‘engineering’. That’s because Scrum is abstracted above that level. Warplanes are being developed using Scrum. Houses, religious institutes, research papers are being built with Scrum. More and more non-software people are turning at our Scrum training camps every day!
4. Scrum hates documentation! Boo! We especially hate detailed documentation! But is this true? You’ve seen something called user stories. That’s documentation. A product needs to include a whole range of documentation. We don’t shy away and say we don’t document: rather, we say to ourselves “what do we really need” and incrementally build that as we’re building our product.
After debunking the myth that certain tools need to be used for Scrum – and the myth of pre-work – he moves to Myth 8: “You must ship or can ship only at the end of each sprint.”
“The problem here is the term ‘Potentially’ shippable material. I don’t like that term. We’re not trying to ship to production all the time. We’re trying to create a working iteration that can be demonstrated. Most teams I work with ship after multiple sprints. Then, on the other side of the spectrum, you have teams that need to constantly ship – that’s where you hear “Scrum ins’t agile enough!” Look, all Scrum says is to ship when you want to.
9. Sprint is failure when the team does not complete a sprint backlog. This is an overly simplistic way of looking a it. It’s a failure depending on how the team works. For example, if the team took on all the tasks and completed nothing, that’s a failure. But if they were smart enough to take on most of the log and complete it – I count that as a success.
“Sprint planning all day with people who have no idea what they’re doing – Dante’s seventh circle of hell is software development,” says Goldstein, moving onto the 12th myth: that Scrum expects all members of a team to be cross-functional. That’s a myth. Scrum doesn’t want your people to be able to do everything – it wants your teams to be cross-functional. Specialists are good. You need specialists. That is totally okay.
And the final myth: after attending a coupla days’ training and reading a few books, these people should be able to all of this Agile stuff. Myth.
Rome wasn’t built in a day. Things take time. Stop being hypocritical. Teams are hellbent on improving their product, but think about the process as well.”
Now that the session is over, Mano Sekaram, CEO of 99x, has given his message, the speakers have been awarded gifts of appreciation for taking the trouble to come down here, and we’re done with lunch, I’m sitting in the (suddenly) reconverted space where previously we had one huge main event. Henrik is exploring the development process for a game development company, using it as a case study in his speech “What is an Agile Tester?”
In this same room, one of the three parallel sessions happening right now, we’ve got “Quality with Agility as an Attitude” by Harsha Kapilarathna, “Build products that win with lean quality” by Yngvar Ungland, “Overcoming regression testing debt with Selenium” by Kishan Navaratne.
In the other room, we have Stakeholder engagement shortcuts by Ilan Golstein, Shortcuts in Automation by Janith Gunasekra, Sprint activity shortcuts by Colin Tan, the Journey towards success in product maintenance – in that order. Of course, as mentioned, the event has broken up into three and there are three very technical , very focused sessions happening in parallel, so this is the one area that our liveblog cannot properly cover.
There’s also Making distributed scrum great by Pete Deemer, Lean/Agile metrics for scaled Agile systems by Janani Liyanage, Beyond Velocity Charts by Rukshan Jayaratne and How to build the right products and deliver rapidly by Gabrielle Benefield.
Well, that’s just about it for the day. The three sessions are continuing, in the way sessions do, and it looks like the QA has kicked off. We’re going to sign out for the day and move onto our next big event: TEDx Colombo. See you in 30, folks.