Wednesday, October 5, 2016

Cyber Agility – The Next Frontier

Could Virtual Reality (VR) and Augmented Reality (AR) be tools to enable distributed Agile teaming?
Co-location and pair programming are two of several elements in enabling high-performance agility. Soon, VR and AR could be enablers for a distributed Agile team while still maintaining the same level of high communication bandwidth that was previously only afforded by face to face communication. Before I go into my ideas on how this could work, I’d like to expand on why co-location and pair programming are so important to high-performance agility.

Face to Face Communication and High Performance

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
In 2001, the signatories of the Agile Manifesto got together to discuss “better ways of developing software”. I find it interesting that most of the manifesto is about people skills, and less about software. For example, “People and Interactions” is a core value and “face to face communication” a supporting principle.
The best way I know of to enabling face to face communication, is being co-located. The tighter the co-location, the more the interactions; hence having Agile teams sitting together in open office configurations.
My friend Mark Pearl pointed out on Twitter that the reason we strive for co-location, is that it is an enabler for collaboration. I'd agree with his assessment.
mark-pearl-twitter-colocation

Pair Programming and High Performance

If a software team were to take on only one Agile practice, then I would suggest pair programming. Seriously! It has the biggest bang for your buck as it helps with:
  • Moving from a group of individuals to a team (because of the bonding)
  • Increasing code quality (pairing is an extreme version of code reviews)
  • Increasing creativity and collaboration (a pair’s thinking power is more than the sum of two individuals)
  • Removing silos (because of knowledge transfer)
  • Improving code consistency (team coding standards)
  • Creating a sense of ownership by the team (collective code ownership and story ownership)
  • Continuous improvement (through coaching and mentoring, your B’s will become A’s over time)
  • Specialist Generalists (pairing on tasks other than ones matching your core competency)
  • Fun! (it’s incredible social)
I have found that pair programming can act as a foundational practice to other high high-performancee practices: merciless refactoring, continuous integration, test driven design/development, refactoring to patterns, DevOps, continuous delivery, coding standards, collective code ownership, clean code, etc.
Unfortunately, I’ve noticed pair programming is considered distastefully by some and is not practiced by many Agile teams. I put this down to either, people who have had a bad initial experience, or, to people having never tried it because it’s unintuitive and uninviting. I’m not going to try and sell you on it here, but will leave you with the advice that if you find yourself in one of these two categories, I hope you get a chance to experience pair programming one day the way it should be practiced.
Pair programming, and mob programming (an extension of pair programming), is easier when your team is co-located. And there is my second argument for co-location: in addition to better communication and collaboration, it makes pair programming a whole lot easier.

Virtual Reality and Extended Reality as Alternatives to Co-location (and office work in general)

While I am a big advocate for co-location and Pair Programming, I could be persuaded toward a distributed team model supported by the new emergent technologies of Virtual Reality (VR) and Augmented Reality (ER).
I think we could use VR/ER to enable distributed Agile teams in the very near future. Here’s what it might look like: your office will be in your home and consist of a keyboard, VR/ER headset and special gloves that you can see where your hands are in virtual space and in relation to your physical keyboard. You have arranged to meet your team for a daily huddle at a certain time and meet in virtual space; in a virtual team meeting room. In this room you can hear and see your team mates; well, digital renditions of them, and yourself. In this room you have access to a story map, an iteration story board, whiteboards, and computers. You proceed to sync up with your team and decide on your pairing partner for the next task. Or, you may even choose to mob program en masse or in a sub group on a task/story.
Once the team has self-organized into pairs or mob(s), they go to a chosen pairing/mobbing room in virtual space that can be customized to their heart’s content. For a pairing example; I may choose to sit in a desert and my pairing partner has chosen a field of poppies. In my reality, my pairing partner is with me in my desert landscape but in their cyberspace, I am in their poppy field. You can decide on whatever environment makes you feel most productive and happy.
Continuing with the pairing example: when I look to my left, I see my pairing partner. I pull up a virtual computer screen in the dimensions, font, colours, and theme that I am most comfortable with along with my preferred IDE (Integrated Development Environment) and keyboard shortcuts. My pairing partner might have something totally different but as long as our IDE’s are in sync, we can look at the same code. Off we go code crafting; free of interruptions to focus on the work at hand in our pair programming session.
Off to one side I have yet another screen that I can use to refer to anything else I may need in this pairing session without switching away from the code e.g. supporting documents, API documents. This would be much like having a laptop next to a pairing station in the real world.
To further this pairing scenario in virtual space: as we are crafting, a green interrupt notification comes up on our chat program. This indicates that one or other of our team mates or pairs has a non-urgent interruption. (There is also urgent and immediate interruptions that would alert us in other colours.) At the next convenient point in our pairing session, we open the chat session with the other pair and see what it is they want. “Hey Ron, which class was it where we…” At this junction we may choose to move to a mob programming room with the other pair, or a white board break out room, or just stay in chat mode. Can you see where this is going?
Working this way in virtual space, I would be on board with trying an experiment with distributed team members all working from home. I’m excited by this new technology and think that as well as Agile software development, most desk jobs will be conducted this way in the near future.
Until then however, I’m sticking with co-location as your best chance for success and high performance because of the higher bandwidth communication it offers and pre-requisite for pair programming. There are certainly some exciting times ahead and I eagerly await to see what experiments Agile teams take on in this space.

Supporting Articles

Pair Programming by James Shore
Sit Together by James Shore

Thursday, July 23, 2015

The People's Scrum - A Book Review

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.

The Poeple's Scrum by Tobias Mayer

Tuesday, July 7, 2015

Turn the Ship Around

This is not a blog as much as a link to a blog that I have published over on the FAST Agile website which I maintain.

I felt it had more to do with FAST specifically than agile in general so posted it over there.

The short summary is - the book "Turn the Ship Around! A True Story of Turning Followers into Leaders" by L. David Marquet is the best book I have read on the essence of agility.



Sunday, July 5, 2015

Say No To Agile Certification and The Fall From Agile Grace

I have recently been tweeting with the hashtag #SayNoToAgileCertification. So why would I, or anyone take such a view?

The Roots of the Idea - Four Inspirations

The 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

Whilst Scrum brought Agile to the masses (the best thing), I feel it is a flawed framework because it is so easily misapplied and has left the masses with a poor understanding of what Agile should be like (and hence, the worst thing).


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 Mouse

Putting 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 because you sat a class is a mockery to any industry. Why has it become so pervasive in Agile? It just adds to the Fall From Agile Grace in my opinion.


The one Agile Certification that is OK - the Trainer

Even though some of the agile certifications do require more than just falling off a log, I still question their value and benefit to your career e.g. CSP and CSC.

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

Stop it! To make a change, first you have to change yourself. And that is what I am doing publicly. I am letting go of my certifications that I feel are either valueless or pointless and encourage others to do the same rather than continue to prop up a systems that seems to be more about making money than changing the world. #SayNoToAgileCertification


FAST Agile

My association with a new Agile Methodology called FAST Agile has nothing to do with my stance on Saying No To Agile Certification.

But as a founder of FAST, it has however impacted my resolve on FAST and certification. There will never be any Certified Fast (other than maybe trainer) nor will there ever be a FAST Alliance. We have the Agile Alliance and that is enough. FAST is behind the Agile Alliance 100% and sees no need for creating alliances around specific frameworks and splintering the industry.

There may one day be certified instructors and perhaps even certified FAST organizations but I'm (not) sorry to say Project Managers - you ain't gonna get no certification from FAST. You become a FAST professional by doing it. Period.

(Read more about FAST Agile at http://fast-agile.com)

I created FAST because I wanted to fix agile and not just moan about how broken it has become. That includes the certifications and Alliances nonsense. I have a dream. Join me. Become an agile activist and take a stance. Let's stop the rot and #TakeBackAgile.







Jurgen Appello's take - Certificates are evil

Decorated Agile Certifications Take Away the Sweetness in your Name

Monday, June 1, 2015

Jenkins, You Can Take the Evening Off

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.

Early Feedback

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.

Merciless Refactoring

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.

Automated/Scripted Build

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.

Build Token

This works best with a co-located team working in an open office space.

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.)

Refactor Mercilessly

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.

Simple Design

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

Further Reading

Martin Fowler's blog article on Continuous Integration

Tuesday, May 26, 2015

Toys and Tools for the Road Warrior


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"
But the key distinguishing factor that Amazon tablets have to other tablets are the services that are made available to Amazon Prime subscribers. Specifically, it is capable of storing and watching free rented movies from Amazon Prime in off line mode. This allows you to watch films while waiting to take off as well as during the flight and landing. No having to miss the end of a film you started in flight. No having to pay to watch films on the plane.

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
But if you can - then it turns your hotel room TV into a Fire TV - complete with Prime Movies and TV - including the things you can only stream. There is a Netflix app that you can install and watch that as well.

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




Travel Router

 

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.




Tripit

 



If you travel and don't use tripit - you need to. 'Nuff said.



 

 

Gogo monthly pass


I'm typing this on a plane. Putting internet onto planes is a godsend for the road warrior. Allows me to get work done and stay in touch with family and colleagues while in the air. It's expensive. But if you fly a lot I think it's worth the cost.


Verizon Message+

 


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)

 

I love Hertz Status. You don't need to go the desk. You just walk straight to the car they have reserved for you (which they notify you on the phone where it is) or you can go to the presidents circle and pick any of those if they look better than the one you were assigned. And there are some nice cars in that circle!


Airline Status

 

There is very little good about travel so finding small luxuries helps make it a little more bearable. The worst is travelling coach. Yuck. It's called cattle class for a reason. The difference in comfort and service in first class is marked. Pick one airline and work it. My favourite is Delta. Once you are high enough status you get upgraded to first often.




Thursday, January 8, 2015

Iterating Toward Legacy - Scrum's Achilles Heel

Of the various software delivery processes under the agile umbrella, scrum became the most popular and is the most common implementation of agile in Corporate America. I like scrum. I like its simplicity. I think that scrum's popularity is due to the fact that you can get quick business gains because it is quick to adopt 1. It is exciting to be able to watch a software system grow and change direction at will. This is in fact why agile exists and why it is called - agile. Managers like this concept and sign up for Scrum heartily for this benefit.


Technical Debt


There is an anti-pattern that I have noticed as a consultant working with Scrum implementations however. While management are 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 green field 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, you are continuing to add to the debt by adding complexity onto 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 this 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 a 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
The bullet points above describe a legacy system. Any of it sound familiar? Alas, it is not an uncommon situation.

These are some questions that I asked in order 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?

Ouch!

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 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 common (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 change 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 build 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 often why it is 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.)

XP Twelve Practices

Extreme Programming is a suite of twelve disciplines, designed to work together to ensure code quality and enable refactoring, which in turn enables 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
Because refactoring returns no new functionality, management often struggle to see value in the practice.
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.


Sustainable Development


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:

Cost of Change

New Features added over time

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 in scrum is 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.


Agile PrincipleScrumXP
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Sprint Review - Demo Small Releases

On-site customer

Simple Design

Continuous Integration
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Sprint Review

Sprint Planning
Refactoring

Emergent Architecture

On-site customer

Planning Game

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

Continuous Integration

Small Releases

Simple Design
Business people and developers must work together daily throughout the project. On-site customer

Stories

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

Co-located team

Pair Programming

Feedback (XP Value)
Working software is the primary measure of progress. Sprint review - Demo

Definition of Done
Continuous Integration

On-site customer (signoff)

Small releases

Agile Testing (including TDD)

Clean Code / Craftsmanship

Simple design

No Bugs
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Refactoring

40 hour week (no overtime)

Clean Code / Craftsmanship

Collective Code Ownership

Simple Design

Emergent Architecture

No Bugs

Slack

Agile Testing
Continuous attention to technical excellence and good design enhances agility. Simple Design

Emergent Architecture

Clean Code / Craftsmanship

Refactoring
Simplicity--the art of maximizing the amount of work not done--is essential. Small Releases

Simple Design

YAGNI (Similar to MVP)
The best architectures, requirements, and designs emerge from self-organizing teams. Emergent Architecture

Co-located team

Pair programming

On-site customer

Simple design

Refactoring

Play to win

YAGNI
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Sprint Review - Retrospective Retrospective

Continuous Improvement
Other Aspects of Development
(not included in the agile principles)
Code Quality Agile Testing

Coding Standards

Pair Programming

Simple Design

Clean Code / Craftsmanship

No Bugs

Continuous Integration
Iterative development Sprint Planning

Sprint Backlog

Sprint Review
Planning Game

Last week's weather

Velocity

Emergent Architecture
Agile Requirements Product Backlog Increments

Product Owner
Stories

YAGNI

Simple Design

Small Releases

On-site customer



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.)

State of Agile 2013 Survey



Scrum's Weaknesses


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


Summary


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 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 these 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". 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.


References


1 - Agile Principles and Values, by Jeff Sutherland
http://msdn.microsoft.com/en-us/library/dd997578.aspx
"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 co-creators 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
http://martinfowler.com/bliki/FlaccidScrum.html
"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 than you'd like. 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
https://www.scrumalliance.org/community/spotlight/mike-cohn/april-2014/scrum-xp-better-together

4 - The Origins of Scrum, by Jeff Sutherland
http://jeffsutherland.com/2007/07/origins-of-scrum.html
"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 with in 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 yourself 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



An Exercise to Illustrate to Teams and Managers how Scrum without XP creates Technical Debt

The Scrum Gauntlet of Debt