Thursday, July 23, 2015
Book review that I left on Amazon.com for "The People's Scrum" by Tobias Mayer
As an agile coach with years of experience and much reading, I am refreshed to finally find something so unique and insightful on the topic of Scrum. Tobias has captured what Scrum is really like, from the trenches so to speak. In publishing this book, I feel Tobias was courageous enough to call out what others have been unable to see or just afraid to say in the wider scrum community. I am grateful not only for the insights, but for the public display of courage.
You’ve read the Cohn series of scrum books. You’ve applied all the cookie cutter methods – story points, planning poker, modified Fibonacci sequence, Scrum of Scrums, burn down charts, team agreements, definition of ready, meta- scrum etc. etc. and something still doesn’t fit. If this is you, then you are likely to be ready for this book and possibly also ready to call yourself an agile anarchist.
This is now my number one favourite book on Scrum.
Tuesday, July 7, 2015
Sunday, July 5, 2015
The Roots of the Idea - Four InspirationsThe seed of my renegade stance was planted by Bob Martin when I watched a video that was recorded at the Norwegian Developers conference in 2011 entitled "The Land That Scrum Forgot". The video actually reinforced a lot of unease that I had been feeling about agile and Scrum in particular. I was feeling that agile has been moving away from what was intended by the manifesto.
I was excited to see that I was not alone in my feelings again when I read Tim Ottinger's blog on I Want Agile Back.
Martin Fowler was blogging about Flaccid Scrum - a common pattern of how Scrum was being misapplied most of the time. I was beginning to be bold enough to publicly identify Scrum as more of a problem than a solution and combined with Martin's material, Scrum certification to be a root cause of Scrum's wide acceptance.
Then my mind was made up to finally take a stance when I read Tobias Mayer's book "The People's Scrum". In the introduction he talks of his split from the Scrum Alliance as a CST due to disillusionment with Scrum certification - "I always struggled with the idea of certification. It seemed to hark back to exactly what we wanted to escape from: a hierarchical, check-box model of management".
The Fall From Agile Grace
- Scrum lends itself to be easily misapplied and become Flaccid Scrum. (There will be another blog coming just on this subject.)
- Scrum Certification was a large contributor of why Scrum became so widely accepted. Project Managers wanted a piece of the agile pie and they were used to having certification to prove their worth in the market. People want something on their resume/CV to show that they are "agile" in today's market and sitting a 2-5 day class is a low hanging fruit as it comes with little to no work for the return of putting letters after your name on LinkedIn.
- The widespread acceptance of Flaccid Scrum was the beginning of the end (and is what most people know agile as today).
Scrum is the best and worst thing that happened to Agile
We now live in the era of Flaccid Agile. #TakeBackAgile and #SayNoToAgileCertifications are positions that I am standing behind in the fight to stop the agile rot.
Most Agile Certifications are Mickey MousePutting letters after your name used to be an indicator that you were a recognized professional by means of an examining body and rigorous testing. To pass those examinations meant study and learning - for more than 2-5 days!
Now understand - I have no problem with handing someone a certificate to say that they sat your course. That is good! But to certify someone as an expert just because they sat your class is very different to certifying that they sat your class. Anyone can sit a class, but not everyone can be an expert. And therein lies the key differentiation and why I dislike (most of) the agile certifications.
I have no problem with the content of any of the agile classes I have seen. But calling yourself a Certified
The one Agile Certification that is OK - the Trainer
The one certification that I feel is of value however is certifying instructors. This has value by way of ensuring that a message does not become diluted and granting a certification status to individuals only after they have proven that they are capable of delivering training and not diluting or changing the message.
A Possible Solution
Decorated Agile Certifications Take Away the Sweetness in your Name
Monday, June 1, 2015
Jenkins, You Can Take the Evening Off
Recently I was asked to participate on a panel organized by Electric Cloud to discuss Continuous Integration (CI). So I spent a day doing some reading and researching to polish up on my knowledge around the topic. Most teams I have worked with feel that because they have a CI server (e.g. Jenkins), then they are "doing CI". But I feel that this is not necessarily true and is only part of what CI is. In fact Automated Continuous Integration software did not exist when the CI practice first came to light so it can't be what CI is. Which raises the question, what is it?
An understanding of the history of CI will be important to understand why I am going to recommend that new teams learn CI without a CI server initially.
Note to users of Git – when you read commit or check in anywhere in this article, think Push.
History of Continuous Integration
Extreme Programming (XP) adopted the practice of Continuous Integration as one of the twelve core practices and brought it to the mainstream agile community. While CI is not part of Scrum, many Scrum teams have chosen to adopt CI as a best practice.
Kent Beck describes the word extreme in Extreme Programming to mean that he took common sense principles and development practices to extreme levels. In this way, when talking about integration testing - “If integration testing is important, then we’ll integrate and test several times a day (continuous integration)” – Kent Beck.
The What of Continuous Integration?
Continuous integration is the process of merging all developer working copies with a shared mainline several times a day.
The “several times a day” point is important as this was the evolutionary step away from a nightly build (which was the most common practice at the time).
"Mainline" is another important word to note. I'll talk more about that below in the section "Trunk not Branch".
The Why of Continuous Integration
The goals of CI are :-
- early feedback (XP value)
- avoiding merge hell
- supporting practice to collective code ownership (XP practice)
- encouraging simple design (XP practice)
- enabling merciless refactoring among a team (XP practice)
- ensure working software (the only measure of progress - Agile Principle)
All of the XP practices are there to enable refactoring. Refactoring is the core practice needed to architect a system with changing requirements.
Note that there is still no mention of CI servers or Automated Continuous Integration software yet. The technology did not exist when XP was born. This is an important point that has been lost to the masses who feel that CI is about having a CI server. I’ll talk more about where the CI server fits in later.
Before CI it was common to run a nightly build. You would come in the morning to see if the build passed. That meant that your feedback loop might be as long as 24 hours! That is a big hit in a one or two week iteration (or Sprint for the scrum people). So it was important to integrate more often. We want to find out within a couple of hours if integration is going to work rather than a day. We want to find out within hours if there are architectural or design issues among the team, rather than a day or days. Days is not uncommon on teams that use Git and choose to work on separate feature or story branches and only merge them once the entire story is complete. This pattern can also cause "merge hell". Read on.
Avoiding Merge Hell
The more and longer you leave your code un-merged from the main branch, the harder and more time it can take to merge and resolve collisions. This becomes particularly apparent once a team adopts the XP practice of Merciless Refactoring. Within the scope a single task, the changes made to the codebase are not limited to the minimum amount to complete the task (a pattern seen in Scrum teams that do not adopt merciless refactoring), so can be numerous and might cover a broad swathe of application and test code.
Once the merges are numerous and there are many collisions, you are in “Merge Hell”. To avoid this, the pattern is to integrate your code every couple of hours. “No code sits un-integrated for more than a couple of hours. At the end of every development episode, the code is integrated with the latest release…” – Kent Beck Extreme Programming Explained: Embrace Change Chapter 16: Development Strategy
The mantra that I was taught when learning XP was to “Commit early, commit often”. This, I feel, is the first aspect of CI that a team needs to learn!
Collective Code Ownership and Simple Design
These benefits will become apparent in the Learning Continuous Integration section below under the headings with these same titles.
Once a team begins to refactor mercilessly, you will find yourself in merge hell more often than not unless you integrate with each others code frequently. If you have an agile code base (to support an agile project i.e. one where the requirements are changing) - you should be refactoring mercilessly. If you don't, you will be incurring technical debt and end up with a legacy system. I have written a blog on the topic of Iterating Toward Legacy which describes this in more depth.
The How of Continuous Integration
I recommend a team learn CI without a CI Server. (Which is what the title of this article is hinting at.) Once you have the core practices down, then, you are ready for a CI server. I like James Shore's description of How to Practice Continuous Integration. Probably the best I have read apart from the original white book by Kent Beck. Below are the core CI practices a team will need to learn :-
Note - We will assume that you have source control already set up and the team are proficient in it's use.
Create scripts to build your code and have them committed to source control. This will often involve learning to use a build tool such as maven, gradle, grunt etc. Technically, you can still do CI without a scripted build but this is rare and so I will not cover it. The build scripts need to include running a test suite and failing the build should any tests fail. For more information on build automation see James Shore’s website on automated build or his book The Art of Agile. You can see an example script here.
The Ten Minute Build
This practice is a refinement on the automated build. Because we must run a complete build before we commit (or Push if you are using Git), then we need to keep the build to under Ten Minutes. This can be challenging for some teams who already have longer build times. You are able to do CI with longer builds – but the pattern is to try to reduce your build time in order to shorten feedback time, reduce collisions within a team and avoid build races.
Maintaining a fast build is an ongoing discipline of an agile team that requires a team to track the build time. It will require a team to change and refactor the build scripts and test code with the same attention that we give to our production code. In a team that is practicing Collective Code Ownership, everyone in the team is responsible and capable of editing these scripts, the source and test code.
Commit Early, Commit Often
In the early computer science days we were taught the mantra of “Save early, Save often”. With the advent of source control this became “Commit Early, Commit Often”. If you have gone a day without a single commit, it’s an indication that you may have gone down the rabbit hole of over complexity and need to roll back your changes and start all over again.
It’s not a bad thing when this happens - and it does happen. When this happens, you've learned what didn’t work and in doing so probably worked out how to break the problem down into smaller chunks and which order to tackle them in when you come back to it.
Trunk Not Branch
This one is always contentious with the git folk. If you are using git, it is not that you shouldn't create branches, it is that you need to merge your code with trunk with the same cadence that we spoke about above. Martin Fowler has an excellent article on the challenge of CI with Git. His closing line is a quote from Paul Hammant :-
"I wonder though, if a team should not be adept with trunk-based development before they move to distributed"
The reason that we stay on trunk is to avoid merge hell. If you must use branches, then try to ensure they are as short lived as possible.
Side note - In a highly distributed team this may not possible. But then being highly distributed is already an agile anti-pattern.
Side note - If you are considering Git for your source control then consider the Centralized Workflow implementation.
The idea of the build token is that when you are about to kick off a build on your computer (or for a beginner team a dedicated integration computer), you take the build token. This is a physical item that all the team recognize. In most instances I have seen, it is a rubber chicken or other similar frivolous yet fun toy that typically can make a sound when squeezed.
Whilst others are able to build without the token, they are unable to commit their code (by team agreement).
This practice is to stop a build race. As the holder of the token, if your build passes, then you are able to commit your changes to trunk. At that point you initiate the token’s noise and return it to the ready location. The noise is an indication to the room that they need to merge changes into the code they are working on ASAP. This is where the continuous part comes in. Because now you are continuously merging in changes and keeping in sync with the whole team and continuously integrating changes to head/trunk. (Actually, continually would be a more correct word if one was going to be pedantic.)
When a team begins to really practice Merciless Refactoring, then in the scope of any task, you could find yourself in parts of the code that you did not imagine before you began coding. This is not to be discouraged. The knock on effect of this though, is that you are far more likely to be colliding on classes and methods with other team members. When these collisions happen, you want to find out sooner rather than later so the two pairs (assuming that you are practicing the XP practice of Pair Programming) can get together and have an architectural discussion to resolve. This is part of fast feedback and how emergent design works!
Emergent Design and Rapid Feedback
Consider that we were able to discover an architectural issue within hours (rather than a day) and can quickly resolve it thereby minimizing the disruption to the flow of coding and likelihood of having to roll back changes. Consider also how easy it is for a co-located team to resolve an architectural issue via a quick face to face huddle in front of a white board. This is one reason why XP recommends development team members being collocated. It increases communication and can eliminates time lost because of distance issues.
Were you only integrating daily instead of multiple times a day, how does it feel to come in in the morning ready to start a new task after a good days work yesterday, only to find that you need to go back and change the code from yesterday? Integrating 2-4 times a day enables a much finer grained level of Rapid Feedback. I believe the effort/cost of fixing issues increases exponentially over time. The sooner you find and fix it, the cheaper.
Another way to avoid collisions, and a pattern to refactor the code when you do have collisions, is to make classes and methods smaller. This is one of the rules of Kent Beck’s "Four Rules of Simple Design" and it's a good OO practice in general.
Simple Design is one of the XP core practices. I hope you are starting to see how all the XP practices work together and why you should take them all on as they are supportive of each other.
Side Note - If you are doing the XP practice of Test Driven Development (TDD), you will find it naturally encourages smaller classes and methods. See what I mean about the XP practices all working together?
Collective Code Ownership
Collective Code Ownership is another XP core practice. The heart of an agile project is a self-organized, self-managed team. (In XP that team is co-located and sit together in an open office environment. Scrum does not enforce this practice.) The idea of Collective Code Ownership is that anyone can edit any code. We are trying to break down silos of knowledge within a team. (Pair Programming is the quickest way to reach the point of Collective Code Ownership within a team.)
CI has been described as a prerequisite to Collective Code Ownership. By integrating often in the day, you will be keeping up to date with all the code changes that are happening by all of the team. You are staying in sync with all the team by continuously reading each others code changes every few hours when you integrate.
Step 2 - Automated Continuous Integration
OK Jenkins - You can come back now
Once the team has all this down pat, then it is ready for an Automated CI Build Server - such as Jenkins.
Again, this requires some learning and should be owned by the entire team now that we have established Collective Code Ownership. You do not need to throw away any of the above practices. Instead you now add to it. I highly recommend that a monitor and speakers be in the development environment so that notice of any build or integration failures found by the CI server are immediately obvious to the team.
The rule/practice for the team is this:-
The teams highest priority is to maintain a green (passing) build.
Should the build break, the team should stop everything, have a huddle to determine the cause of the break, identify who will fix and and make that the highest priority for the team. Swarming and/or mob programming is a good practice here.
While the build is red (broken), no one is permitted to commit any code (by team agreement).
Here is another brief description of an Automated CI process.
Continuous Deployment, Continuous Delivery(CD) and DevOps
These are whole topics in and of them self and also the latest buzzwords in agile. Core to these practices is the CI server. Some clever folks worked out these automated build machines can do more than just build and test. They can also become gateways, package, deploy, monitors, run broader environment and package testing. And so, Continuous Deployment, Continuous Delivery and DevOps were born. Enough said.
Closing and summary
I'm not going to go into any further detail on the uses or setup of a CI server such as build triggers, chained builds, breaking out test suites, stress testing, bench marking, testing environments, continuous deployment etc. They are each topics in themselves and take me away from the main topic of this article.
I'm hoping that you noticed the interrelationship between CI and all the other XP practices that have been mentioned in this article. The practices/disciplines are designed to work together in this way and work best when ALL of them are practiced. That is why I prefer to keep XP intact rather than breaking it into a smaller subset of the practices and calling them agile development practices or technical practices. Don't mess with Grandma's recipe. If you want CI, then do XP.
The main points I want to reiterate for my closing summary :-
The first rule of CI is - Check in Early, Check in Often
You should be be committing (and therefore building) your code 3-4 times a day. That is why they call it "Continuous"
CI is so much more than a CI server. Learn all the other practices before installing a CI server
Get adept with trunk-based development before moving to distributed
Do ALL of the XP (Extreme Programming) disciplines and not just part
Martin Fowler's blog article on Continuous Integration
Tuesday, May 26, 2015
A list of devices and apps that help make travelling for your job a little easier to bear.
Kindle Fire Tablet (with Amazon Prime subscription)
I actually prefer the 7 inch to the larger. Reason is that it fits into any bag that I choose to take as carry on and with the magnetic cover folded back it slots perfectly into the seat back of Alaska airline planes so that you can watch your film at eye height and not loose any precious space on your tray. Well - that's in coach in any case.
|The model I have - Kindle Fire HDX 7"|
As well as this unique feature to Amazon tablets, it's also great for Amazon music and as a Kindle reader of course. Skype and Netflix work great on it and the sound and picture quality is fantastic. If you have a fire stick you can also do some other neat stuff with it in your hotel room which I will talk about next.
Fire TV Stick (from Amazon)
This trick doesn't always work. It relies on the hotel TV allowing you to put devices into the HDMI port of the hotel TV.
|Fire TV Stick|
The cool thing about this? It comes with a remote (or you can use an app on your phone). And - you can fling from your Fire HDX to the TV. So if you were half way through a movie, you can pick up right where you left off from on the tablet and watch it on the TV.
(When you do this, the Kindle allows you to pause the movie and also displays "X-ray" information about the film.)
Miniature Portable Humidifier
This was a lifesaver when I was in Detroit during the Polar Vortex. The air was so dry! I found it helped me to sleep better and not feel like a lizard.
The model I bought was from the Think Geek website - Vap0rb USB Ultrasonic Humidifier
I fill the room's ice bucket with water and float this device in it.
White Noise App
Hotel rooms can be noisy. By running an app (on your kindle fire hdx for instance) that plays white noise (e.g. a beach, or rainstorm) it mutes the background noise so your brain doesn't focus on it and allows you to go to sleep. I read somewhere that you actually go into a deeper sleep too.
The one I use is called White Noise
Bluetooth Waterproof Speaker
This one is not for everyone. I like listening to audio books - even in the shower. So with Audible loaded onto my kindle fire HDX or cell phone, I can listen to the book while showering. (I take long showers.)
The model I have is VicTsing® Wireless Bluetooth 3.0 Waterproof Outdoor / Shower Speaker, with 5W Speaker/Suction Cup/Mic/Hands-Free Speakerphone
|Wireless Portable Router|
This device is only for hotel rooms that offer a wired internet connection - which is becoming less and less available I'm finding. But when it is there - you plug this baby in and have your own hotspot that you can connect as many devices that you want into without having to type in credentials into each e.g. hotel room number and last name. You only have to enter it once on any one device and then you are set for all your devices. It is also a firewall so you are less at risk of getting hacked by someone else in the hotel on the same network.
If you travel and don't use tripit - you need to. 'Nuff said.
Gogo monthly pass
Only works if you are with Verizon (which I switched to because I travel and was tired of dead spots with my previous carrier). This app runs on your laptop (and kindle fire hdx) to receive and send SMS messages that you would usually do on your phone. Particularly useful while flying to be able to receive and respond to your text messages. (See gogo internet.)
Hertz Status - Presidents Circle (comes with Delta Platinum Status)
Thursday, January 8, 2015
There is an anti-pattern that I have noticed as a consultant working with Scrum implementations. While management is happy with their agile process and seeing new functionality being added every sprint, typically they are not budgeting for any maintenance.
In the early days, this is easy to get away with, particularly on a new codebase or greenfield project. However, unless you are cleaning up after yourself continuously (particularly if you are cutting corners in the sprint) and fighting to keep the code clean, you will be incurring technical debt. It is subtle in the early days, and you will not notice it, but it starts to add up.
The reason that we call it debt is that you need to pay it back at some point. The longer you wait to pay it, the more interest it has accrued and compounded. Not only are you not paying the compounding interest back, but you are also continuing to add to the debt by adding complexity to complexity and sloppy code onto sloppy code increasing the already compounded debt. The longer you leave the debt unpaid, the more effort and time it takes to fix the mess. This is what agile looks like without any discipline around cleaning up the code during each sprint and being vigilant to improve the architecture as it evolves. This is agile done wrong - which I see all too often in Scrum implementations, and has been called "Flaccid Scrum" 2. To dig yourself out of technical debt, it is going to cost you - a lot.
In short, the scrum Achilles heel (or blind spot) is this:
On a long term project / large product, scrum (done poorly) creates technical debt. Too much technical debt left unpaid results in a Legacy System.
Legacy Systems and Cost of Ownership
I was working with an agile client that had implemented scrum as their software delivery process. They were on the second version of their product. That is to say; they had re-written the first system and were very proud of their new second system which was now using more modern languages, technologies, and frameworks. They retell the stories of the horror of working in their legacy system. Stories like:
- it took weeks to deploy
- the code was hard to understand, and only a handful of developers knew how to work on it
- it was extremely fragile, and they were always breaking the system when trying to add a new feature or even fix a bug
- adding any new functionality took a long time
- the system was bug ridden
- bugs took a long time to find and remove
These are some questions that I asked to provoke thought and insight into how they managed to get into that mess in the first place:
- Did you have senior architects and senior developers when you created the original system?
- Did they intentionally architect a legacy system? (I'm being facetious on purpose.)
- Now you have a new system, what are you doing differently to ensure this doesn't happen again?
Then I point out that every day that I sync my laptop to their codebase, I am pulling in hundreds of new files. That is just not sustainable! They are on track to hit the same technical debt wall that they had in their original product and create a Version 2 Legacy system.
If you carry on sprint after sprint delivering business value while disregarding code quality and architecture, you will end up with a legacy system.In a legacy system, the rate of adding new features decreases and the cost of adding features increases. You will not necessarily notice a drop in velocity however as the size of the stories starts to increase (to account for the complexity of working in a legacy system). Velocity will stay the same but the rate of adding new features decreases. (Which is one reason you should not use velocity as an indication of a team's performance.) You will also notice the bug count going up and much more time spent on fixing bugs. At this point, a business knows that things are going slow, but it can't work out why and starts to lean harder on the engineering department to produce more, which only results in them cutting more corners, writing more bad code and compounding the mess.
Once a company realizes that they have dug themselves into a technical debt pit, they scramble to get out. A typical (anti) pattern I see is creating technical debt stories (or even sprints!), refactoring stories and technical stories. If you find yourself doing this you need to change your development process as stories, by definition, are supposed to come with business value. More information below on how to improve your development process.
You pay for quality one way or another. You either pay for it as you go (by building quality into your process) and create a system with a low maintenance cost that you can continue to build on, or you pay the price toward the end of the project (where it now costs more) and have high maintenance costs. The option that makes most economic sense is to pay your debt as you go.
The solution to technical debt - Refactoring (Mercilessly)
The only one tool to stop the natural code entropy toward technical debt is - Merciless Refactoring.
Code Refactoring Definition : Code refactoring is the process of restructuring existing computer code - changing the factoring - without changing its external behavior.Each sprint you have to build SLACK into the sprint, so that you can MERCILESSLY REFACTOR the code, evolving the architecture (EMERGENT ARCHITECTURE) and keeping the code clean (CODE CRAFTSMANSHIP) to enable the business to be able to change direction on a moment's notice and keep the cost of change low.
Refactoring is a scary word, particularly to conventional QA specialists and to management who struggle to see what value refactoring can bring. Which is why it is often not only avoided but actively discouraged. In fact, I agree that you should be scared of refactoring. Without other supporting disciplines/practices, refactoring is very dangerous!
What are these other disciplines that support refactoring? Well, there are eleven of them, and when you package them up with refactoring, you have - eXtreme Programming (XP). The practices all work together to support each other. If you are going to implement XP, don't mess with Grandma's Recipe (well at least until you are proficient) by trying to do just part of it. (This is why I dislike it when I hear "Engineering Practices" or "Technical Practices" used in place of "XP." It only encourages the misuse of Grandma's recipe.)
Extreme Programming is a suite of twelve disciplines, designed to work together to ensure code quality and enable refactoring, which in turn allows emergent design/architecture, which enables having a delivery model of changing requirements (agile).
The goals of refactoring are:
- remove dead code
- reduce complexity (often reduces lines of code)
- remove duplication (including tests)
- make code easier to read and understand (to support collective code ownership and ease of future changes)
- change an underlying architecture to a better one as the system emerges (emergent design/architecture)
- change an underlying architecture to match a change in requirements
The main value of refactoring is that you are not accruing technical debt and can therefore continue to add features and alter your system ad infinitum (with few to almost no bugs to boot).
This goes part way to addresses the agile principle behind the manifesto of sustainable pace.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely - Principle behind the agile manifesto.
Scrum has no answer as to how to achieve the principle of sustainable development where XP does. Consider these graphs below of two long term projects. One delivered with Scrum and the other XP:
This is a graphic illustration of the sustainable nature that XP will give to your development process over scrum. The state toward the end of the graph is Scrum as a legacy system. In fact, XP helps fill in many more agile principle gaps that scrum leaves unanswered. Read on.
Scrum is not enough
Scrum is a framework, and its implementation is left up to you. Much of the implementation of today's corporate scrum has come from XP. This includes Stories, Story Points, Velocity, Continuous Integration, and Release Planning.
When you take all the Principles Behind the Agile Manifesto and map them to Scrum and XP practices, it becomes pretty clear as to why you should be supplementing scrum with XP; supporting my claim of - Scrum is not enough.
|Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.||Sprint Review - Demo||Small Releases |
|Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.||Sprint Review |
Feedback (XP Value)
|Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.||Iterative Development||Iterative Development |
|Business people and developers must work together daily throughout the project.||On-site customer |
Feedback (XP Value)
|Build projects around motivated individuals. |
Give them the environment and support they need, and trust them to get the job done.
|Co-located team |
Play to win
Collective Code Ownership
|The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.||Scrum (daily standup)||On-site customer |
Feedback (XP Value)
|Working software is the primary measure of progress.||Sprint review - Demo |
Definition of Done
|Continuous Integration |
On-site customer (signoff)
Agile Testing (including TDD)
Clean Code / Craftsmanship
|Agile processes promote sustainable development. |
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
40 hour week (no overtime)
Clean Code / Craftsmanship
Collective Code Ownership
|Continuous attention to technical excellence and good design enhances agility.||Simple Design |
Clean Code / Craftsmanship
|Simplicity--the art of maximizing the amount of work not done--is essential.||Small Releases |
YAGNI (Similar to MVP)
|The best architectures, requirements, and designs emerge from self-organizing teams.||Emergent Architecture |
Play to win
|At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.||Sprint Review - Retrospective||Retrospective |
|Other Aspects of Development |
(not included in the agile principles)
|Code Quality||Agile Testing |
Clean Code / Craftsmanship
|Iterative development||Sprint Planning |
|Planning Game |
Last week's weather
|Agile Requirements||Product Backlog Increments |
Scrum + XP = A More Complete Agile Process
It is recommended that Scrum be complimented with XP 3, and it has been recognized that there are significant speed (5-10x) and quality advantages 4 in doing this.
So if it is recommended, why are there so few Scrum implementations that do this? According to the State of Agile 2013 survey, out of the total of scrum agile implementations reported, only 15% are doing Scrum + XP! (Of the entire population sample, only 1% are doing just XP.)
Scrum on its own fails to address
- removing technical debt
- maintaining a sustainable pace
- code quality
- emergent architecture
- small releases
XP fills in these gaps, and more. To be successful in iterative development (e.g. Scrum), your developers need new skills and understanding.
Software developers moving from waterfall to an agile delivery environment need training in agile development practices and ways of thinking in order to deliver software incrementally and architect a system while requirements are changing.Most Scrum transformations/adoptions I have seen have focused only on changing business processes without spending any resources on training the developers and setting them up for success (or leave it late in transformation by which time bad development habits have already set in). Developers need new skills and understanding to deliver in an agile environment. XP training and coaching can provide these skills. This includes:
- Incremental delivery
- Incremental and emergent architecture
- Emergent design
- Merciless Refactoring
- Agile Testing (The Agile Testing Pyramid)
- Continuous Integration
- YAGNI and Simplicity
- Simple Design
- Choosing technologies that support testing and refactoring
If you carry on sprint after sprint delivering business value while disregarding code quality and architecture, you will end up with a legacy system (i.e., crippled with technical debt) with a high cost of ownership and many bugs.
Code suffers naturally from entropy. A software system tends toward technical debt and legacy (if left unchecked). The ONLY way to fight this entropy is code refactoring.
To refactor code requires supporting practices e.g., agile testing. There are at least eleven other of these practices/disciplines, and the sum of all these practices are packaged together as eXtreme Programming (XP).
XP gives developers skills in delivering and architecting a system for changing requirements - which Scrum does not.
In a long-term software project, you need to supplement scrum with XP.
Side Note - I came to this conclusion independently, but in writing this blog and researching references, I discovered that some of the content isn't particularly new. The thoughts of Bob Martin, Martin Fowler, Michael Feathers, and other thought leaders, in many cases, match my own observations. I find that encouraging.
Agile Terms and Lingo
XP - eXtreme Programming
MVP - Minimal Viable Product
YAGNI - "You Ain't Gonna Need It". The similar thought process in XP to Minimal Viable Product (MVP) in Lean Startup
TDD - Test Driven Development
Agile Testing - The suite of testing practices exercised by XP developers that follow the Agile Testing Pyramid paradigm
Refactoring - Code refactoring is the process of restructuring existing computer code - changing the factoring - without changing its external behavior
Technical Debt - A backlog of improvements to the code and/or architecture that will help make it more maintainable, easier to read, and robust
Legacy System - A computer system that has a large amount of technical debt
Incremental Delivery - The process evolving a software product by delivering working sub-portions (increments) of a system (typically on a cadence). Each increment typically builds further functionality on the previous, growing the complexity of the system incrementally.
1 - Agile Principles and Values, by Jeff Sutherland
"the Scrum framework for software development was designed to get a team started in two or three days, whereas engineering practices often take many months to implement. Therefore, it left the question of when (and whether) to implement specific practices up to each team. Scrum cocreators Jeff Sutherland and Ken Schwaber recommend that Scrum teams get started immediately and create a list of impediments and a process improvement plan. As engineering practices are identified as impediments, teams should look to XP practices as a way to improve. The best teams run Scrum supplemented with XP practices. Scrum helps XP to scale, and XP helps Scrum to work well."
2 - Flaccid Scrum, by Martin Fowler
"What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake, you'll soon find your productivity dragged down because it's much harder to add new features. You've taken on a crippling Technical Debt, and your scrum has gone weak at the knees."
3 - Scrum and XP: Better Together, by Mike Cohn
Availble via wayback machine internet archive to article now removed from Scrum Alliance Site
4 - The Origins of Scrum, by Jeff Sutherland
"Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices"
More from other Authors
The Art of Agile - James Shore
My favourite book and blog on XP right now.
The Land that Scrum Forgot - Bob Martin
Ask me Anything session - Jeff Sutherland
"Ken Schwaber convinced me that Scrum would be easier to adopt and work anywhere if we didn't mandate specific software practices."
XP is the Mac of Agile - Jonathan Rasmusson
Working Effectively with Legacy Code - Michael Feathers
A great example of why developers need to refactor - Manuel Bernhardt
"It is one thing to get to a reasonable functionality in a short time, and another one entirely to build a piece of software that can be maintained or worked within a team over an extended period of time. It is all too tempting to leave working code as-is, without refining it or improving it in a timely fashion. And before you know it, someone else has picked it up, or you have picked it up again, copy-pasted it (god forbid!) or increased its complexity where there would have been a simpler solution would you have given it some more thought."
Code Refactoring - Wikipedia