Are You Being Agile or Just Doing Agile
•Télécharger en tant que PPTX, PDF•
0 j'aime•140 vues
"Are you Doing Agile or are you Being Agile?" by Chris Lowe. Agile Tour Vilnius 2018
Recommandé
Recommandé
Contenu connexe
Similaire à Are You Being Agile or Just Doing Agile
Similaire à Are You Being Agile or Just Doing Agile (20)
Plus de Agile Lietuva
Plus de Agile Lietuva (20)
Dernier
Dernier (20)
Are You Being Agile or Just Doing Agile
- 1. Are you Doing agile or are you Being agile? Chris Lowe @agilearchitect_
- 3. A list of business problems • The product is late • Blame Technology • The product has quality issues • Blame Technology • The printer is on fire • Blame Technology
- 4. ShuHaRi “In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation.” Aikido master Endō Seishirō Shu - Obey Ha - Digress Ri - Separate
- 5. So are we Agile?
- 9. What’s the target? “The ability of an organisation to rapidly adapt to market and environmental changes”
- 10. Make a cross functional team that can design, develop and take a product to market
- 11. Change is a carrier of failure and disruption • Change introduces downtime unless we mitigate with a strategy like blue- green • Change introduces bugs unless we mitigate with an automated Quality strategy • Change introduces opportunity for manual error unless we mitigate it with an automated deployment strategy
- 13. ShuHaRi “Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. ” Aikido master Endō Seishirō Shu - Obey Ha - Digress Ri - Separate
- 15. Code Craftsmanship • Readable • Well tested • Maintainable • Flexible
- 16. ShuHaRi “Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires. ” Aikido master Endō Seishirō Shu - Obey Ha - Digress Ri - Separate
Notes de l'éditeur
- It’s great to be here. I’ve been a developer and architect for about 22 years, and for about the last 10 years I’ve been learning about agile And helping organisations to implement agile frameworks Today I want to talk about a problem that affects a lot of companies people like you and I might end up working for It’s a problem that we don’t talk about often enough. That’s when companies do all the agile things, but in the end don’t get the agility they were looking for But before we get started, a quick show of hands to make sure we’re all alert. How many people work with teams that use short iterations? Keep your hand up if your team includes: not just devs and a QA but also someone from product, maybe a designer, some one on UX? Keep your hand up if you’ve ever met one of your customers (Click)
- I like this cartoon. It’s funny because it’s true. I work for a company where this happens. Not the first or the second time I’ve seen it, and I’m sure it won’t be the last. Like all businesses this company has their problems And like many businesses, they love to blame Technology for as many of those problems as possible. (click)
- Lets have a look at some problems businesses might face (click) You’re getting the hang of how that works An Agile consultant might say that the solution for at least 2 of these problems is to start using an agile Framework like scrum Scrum delivers value early so the product wont be late to market Scrum says that quality is not negotiable, so no more quality issues. (click)
- So like many other Technology teams, we adopted an agile framework and depending on how the work arrives, that maybe Kanban, but for the teams I work with it was scrum Just like normal, we made the change without too much trouble, So we deliver value in iterations, we do retros, we do refinement we do all the ceremonies We do scrum (click)
- (click) Nope How do I know this? Because as an Architect I am on the boundary between two worlds and I can see into both of them The business needs to sign of on a project before work can start: Product needs to approve the solution, UX needs to approve the design. Security, finance, everyone has to approve the project So every year, I have to work with the Delivery manager to submit a Business Case For those of you that haven’t come across a business case before (consider yourselves lucky) it’s a document that sets out all of these parts of the project
- But hold on a moment, Did we just say tat in the business case Scope is fixed Cost is fixed Design is fixed Which means the only thing left that’s negotiable is quality? I know what you’re thinking…
- But I can’t tell the teams that. Telling the teams that would break the illusion that we’re agile. (click)
- Over here, on one side, I have the teams that I work with We develop a product where requirements are emergent, Design is flexible, scope is negotiable and Quality is fixed Over here, on the other side we have the smouldering remains of the business case where Design is fixed, scope is fixed and quality is negotiable And here’s me, stuck between the two With Technology using one framework, and the rest of the organisation using whatever came before: waterfall, chaos, whatever, we are trying to deliver something to the customer using 2 different Product delivery methodologies, and I don’t know what you think, but I think that’s always going to be worse that picking one and going with that.
- We said at the start that this problem is about companies who do all the agile things, but never get the agility they’re looking for. The aim (click) is to tame the unicorn that is business agility While everyone knows that a unicorn is famously un-tamable, companies do get close. What this really looks like in practice is a company who is so close to their customer that they understand the problems, have an idea how to solve them and can recognise when the Customers requirements have changed because they have a strong enough relationship that the customer tells them. To summarise that, I like the phrase customer alignment. If we Know our customers and can communicate with them, we can deliver products that don’t just solve their problems today but can evolve and grow to meet customers needs in the future.
- If we’re going to deliver a product that does all that, we’re going to need to make teams that can design, develop, deliver, market and sell we need truly cross functional teams Instead of building teams based on similar skills, horizontal slices through our organisation (click), we need Teams built from vertical slices through the organisation. Teams that, led by their relationship with the customer, can do anything. So that’s it? Build cross functional teams that have a strong relationship with the customer and we’re done? The company has done it’s part, but now the light shines back on Technology because now we have to do something different from what we’ve done before. Now our code has to evolve as the customers requirements change, and if we’re in touch with our customers, if we’re asking them what problems they have, what features they need, change might come faster than it did before and we need to be ready
- There have been two times in my career as a developer when I felt like I was super-productive. The first time it was because I was part of a team of awesome software engineers and the second time it was because I was say right across the desk from my customer. When you’re that close, requirements are truly emergent and they come thick and fast. This leads to lots of change at the product level and change has a major consequence. The thing to note about change is that it is probably our industry’s biggest trigger for unplanned outages. We want our customer’s experience to be great – at least, better than the competition One of my favourite lean writers, Mary Poppendieck says that we should aim to surprise and delight our customers, bur we know, don’t we that every time we introduce new features that’s also a potential source of bugs and downtime. (Click)
- About 5 years ago I went to Berlin to visit a company that had just been acquired. I was there to help them with their dev-ops. They had a successful microlending business, but when I got there and asked them about their deployment, the answer came back “Oh, that’s manual” The guy I was there to see took me through their 15 stage deployment. Step 1 check the new code out of git Step 2 Connect to the target server Step 3 copy the code over to the target. Step 4 put up the maintenance page And so on. He knew the steps inside and out, and he could do the deployment in his sleep But when I asked if it ever went wrong He said “Oh yeah, the most common thing we do wrong is forget to check the new code out of git” “So you log in at 2 am, and spend 30 minutes deploying the current version over the top of itself?” “Yeah”
- If we don’t mitigate for the risks that come along with making changes, we risk failure when we’re releasing changes very often. Those of you with a Dev–ops background will recognise what I’ve just described: Automated Quality strategy, automated deployment, near zero down-time should all sounds very familiar. Because we have created a situation where change happens often and we realise that change can be a source of disruption and bugs, Dev Ops is key to taming the unicorn. (click)
- The other thing that Technology has to deliver is a codebase that can be extended, maintained and improved with confidence through the lifetime of a product. How old is the oldest software product? It’s hard to tell. Applications like Word and Excel were some of the first widely used business software, along with Lotus Notes. IBM Notes is still sold today 29 years after it’s first release. Microsoft word was first released in 1983. It’s 35 years old! When you think of writing software that has to absorb all the changes in a 35 year lifespan, you wonder how much of that original code is still there? But Complete Rewrites are expensive, and involve a lot of chance that we’ll suffer from our friends instability and disruption. On top of that, if your application stores data, does a rewrite include a data migration? Complicated and nasty. The more we can do to write our code so that it can last the length of the product and avoid the rewrite the better.
- The code craftsmanship movement, described so well by Robert C Martin explains all the behaviours that we can use to develop code that is (click) All the things we need to do to put off the rewrite for as long as possible, if not, for ever By building a combination of Dev Ops and code craftsmanship into our culture we can deliver Technology to support an ever-evolving long-lived product that can keep up with changing condition and our customers requirements
- Reorganising the way that we work in teams. Building a new culture of Dev-ops and code craftsmanship. It sounds like a lot of work, and depending on where you’re starting from, it might be but the good news is that we don’t have to wait for the Organisation to realign around our customers, we can start the cultural change right now. If we do maybe the business will stop blaming Technology for everything that goes wrong and make them look at themselves for improvement. Maybe if we di this and get ourselves and our code perform as well as we possibly can, it will be the catalyst that brings about stronger customer alignment? Maybe then we can stop doing agile and finally start being agile.