Tuesday, 29 April 2014

UK government is spending millions on agile development coaching and training

Verdict

- Agile is the way forward – digital projects require an approach that allows for change and constant testing, whilst still allowing innovation to be introduced. This just doesn’t work within the confines of a traditional waterfall environment.


- However, departments need to be aware that it isn’t just the development team that needs to be skilled up – it’s all of the governance surrounding the procurement that needs to change. You can’t be working in an agile way, but still reporting using waterfall structures.


- If the money needs to be spent, it needs to be spent. But I’d like to see agile advocates within government being pushed around departments to evangelise the benefits and help get teams on the right track.

Friday, 25 April 2014

You should be fired for being too good

I strongly believe the goal of a great Scrum Master/Agilist is to be fired. WHAT?! WTF?!?! Be fired??? Oh gee.. Ok bro chillax.  Let me explain myself: I heard something similar a very long time ago from my old work mate Bob. Bob is a sysadmin right, he is the typical stereotype it springs to mind when you think about a proper geek. A real genius geek. He is tall, massive size, rounded glasses, goat beard, pony tail, loves his beer – having clocked almost 1000 different ales in Untappd in the span of 6 months speaks for itself - and the best of all, he has capable of delivering the most dark and sarcastic tirades someone could possibly come up with. One day having a chat over a beer (he has having an ale) he said exactly that, “the goal of a good sysadmin is to be fired”. I was puzzled by that but then I finally got it.


Bob arrives for his new job and he finds it a proper zoo. There is no structure, cowboys work as they want on whatever they want, things get delayed, nobody knows what is going on, no documentation explaining what’s where, server hangs, site hangs, database crashes, e-mail bounces, you name it. Bob comes along and start his craft. He creates good scripts, monitoring tools, document the whole lot, provides structure to the chaos and after mega battles the system now seems stable. Sound the drums!

Users have the memory of a goldfish. They easily forget about pain. They take smoothness for granted. They seem to believe the system always performed right. They are happy users now. Emails do not get lost. The wi-fi works, everybody can be on Facebook without loosing their connection, CI works, no breaks, no corrupted db anymore, no servers hanging! Oh!! Gee!! As if from a magical spell it all works! After a while people start wondering what is it that Bob really does. It’s all running great, so why is he needed after all? Bob gets bored, Bob goes. A lonely geek warrior chasing his next digital battle.

Few weeks go by. Users are now spoiled. They do not update their crap, they cut corners. They are lazy. Soon it all starts to get back as it was. Slow. It drags. It’s unreliable. After a while the system goes bad again. Very easily its all back to square one and now people miss Bob. Sound familiar?

I guess this philosophy apply to great Agilists as well. Help people get on track, show them a better way of doing things, and move on. An eternal crusade towards spreading the mindset :-)

"There is something you should understand about the way I work. When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go. It's rather sad, really, but there it is" 
— Nanny McPhee

Monday, 21 April 2014

My personal crusade towards people engagement

How would this… look big?

During all my career as a developer I have consciously decided to work for small to medium size businesses. I did so because I wanted to see the whole package, how the business worked, what made it tick, how the different departments related to each other, cross the owners and everybody else by the coffee machine (although I do not drink coffee) and be able to have a quick chat,  I find it cool that it was easy to show my craft - and be called upon when I did not. Becoming a Scrum Master enable me to reach and experiment different types of problems and challenges in this environment, more related to the business and its people and that was indeed great fun.

When I first joined a huge enterprise size company I was keen to see how similar issues that I had experienced in the past would surface under a mega size company perspective. What sort of new problems would I be challenged with? New job, new challenges, right? There we go.



A giant game of small pieces

At my first day at work I was impressive by the size of things. Big building, many floors, loads of people, bubbly and dynamic, right? Not really. I was surprised to realise how much compartmented work and relationships were. You cannot just remove all the walls, put everybody in a single floor and expect them to gel like old friends. The modern silos are invisible. They are way more subtle, hard to be noticed and addressed than when you had odd Joe working alone on his cubicle. It is easy to feel alone in the middle of the crown and is also hard for others to realise you might be feeling like that since there is just too much going on.

It transpires in simple stuff like not making eye contact or acknowledging people by the lift, to more concerning ones like not knowing who or what the guy on the next hub works with. How is it that at some point we – and I include myself - became too lazy and complacent to not bother to know who is that guy around the corner?

Most big business were at some point in their journey a small business. They are in essence a giant game of small pieces. A business is not if their employees and once they are now hundreds, thousands, having these guys to engage and collaborate becomes a BIG challenge.

And what is the point in having all these people talking? Old school mentality would say that this would just be another distraction. They chat therefore they produce less… Well, it is not like we work in an assembly line. I believe that what would happen is actually the opposite. Through engagement and communication is that creativity springs. Those Eureka moments by the shower need constant input of variated sources in order to happen.


So how do we start?

Ok. First stage is acceptance. You acknowledge that there is an issue. Second is how to go about that. How can you work towards change? Good news is that you do not need to be a Scrum Master to work towards what you believe. You do not need to be anyone’s boos. There’s always room for improvement and if you believe communication is key and people engaging is crucial, you can do your part to help in that process. Work around your colleagues  change yourself, change your team, your hub and at some point, by simply being an example, you will inspire others to change. The goal is to become a source of inspiration. If you only bother to do what is on your job spec, you are likely to drown ashore and ended up transforming yourself in a bitter employee, a moaning expert.

I currently work as a Software Engineer.  I have no power in saying how my team or department or anyone else should do their work and this is great! Having officially no power is key to have a real effect because if and when someone decides to give me some credit, they are genuinely doing so. Not because I am their freaking boss or someone in a posh suit. The house patron will seldom hear the cleaner’s gossips. I am fighting on the front line, within the trenches. My crusade is bottom up!

My idea was to start performing small experiments to see how they will help in improving communication and motivation around the team and I am happy to share my ideas and hear your suggestions and feedbacks.


1-2-1 by the Coffee Machine


Getting to know your team members and the others around you is crucial for building health and open relationships. Only when you can see from others perspective is that you can actively work towards changing and improving their lives (and yours). Trust only comes from such connections and if you want your team to be bold and try and experiment new things, they need to trust you and themselves. Take opportunity to chat with new faces, introduce yourself, see what they do, show them what you do. Discover their pain and their joy!!


Team Lunches


Yeah, we did have team lunches but it was one of these things that would happen once in a while. Now I have set up calendar reminders to make it happen every month or whenever I feel there is an opportunity for a nice catch up. I am trying to schedule regular lunches not only among our own Scrum Team but also among different teams and people. Break the invisible barrier by trying to involve other members of the business as well - POs, DevOps etc. All of a sudden the miracle of full collaboration might occur… You feel open to stop your colleague by the hall and have a catch up! You feel at easy to bother the big grumpy DevOp guy on the lower floor and dig further in an issue your team is experiencing..


Lunch & Learn


These is a very old school idea, the famous brow bag session. Every Wednesday we go into a room round lunch time and together we watch a cool video/course about some interesting topic (we already have had BDD, DDD and UML) or someone will come around and talk about something cool -  the guys from Security had recently done an awesome presentation and the room was full! Topics are suggested and voted through our Yammer Lunch & Learn page. I  believe this improves visibility on what other people do in the company and is also a chance to learn something new. Sometimes it will be only you in the room but persevere, find the right format, interesting topics and volunteers and you will get there. Note that this is more than just learning, it is a crucial opportunity for very different people – who would not normally see each other all day long – to engage.


Monday Thought


My goal with this is to slowly scope sensitive Scrum values and ceremonies and plant a small seed of  “doubt" among the teams. They need to become suspicious of what they do so that they start questioning What we do, Why do we do, and How we do it (WWH as I like to say)! I send and email every couple weeks, on Monday as the title suggests, where I briefly touch a critical subject such as the Scrum Values, DoD, Review, etc. There will always be someone disagreeing, questioning and debating my email and that’s when the fun starts :-) It is not about agreeing about something but to start a discussion and let the team reflect by themselves.


Definition of Done


We have recently formalised our Team Definition of Done. Among all the benefits of it I highlight the subtle one that the DoD is crucial in establishing our quality standards as a Team so that we do not get satisfied with less. If you cannot find quality and meaning in what you do you are likely to leave work demotivated. Don’t accept crap code, re-write bad users stories that lack sense of proper acceptance criteria, chase the PO to have your work validated! As a team, fight for what you believe is right. One or all and All for One! Excellence is a matter of choice.


Social Media

We have recently adopted Yammer and I am a great enthusiast of it. I have created a Climber’s group, Runners Group and our Lunch & Learn group. It feels like Facebook but more business faced and has being a nice way to share thoughts, events and get to know people from other floors with similar interests, specially the shy ones. It is also a great way to share your team results within their Agile journey so that other teams can be inspired to try something new. Don’t waste such precious opportunities to engage and group people around their commonalities being that their love for Agile or a passion for bread baking.


Gun yourself up with good friends!


Old cowboys had good pistols, good Agilists have good friends. Find who are the other Agile enthusiasts of your business, within the trenches and from the top chain of command. Connect with them. While you try to push bottom up, you are sure to have support and energy from top down. More “senior” and experienced people are good allies when the going get’s tough and can help in disseminating the idea at other levels of the business. You cannot win alone.


Visual Radiators


This has being a very positive one. Here we do not use a physical Scrum board but a Jira board so that the other geographically dislocated teams can have visibility of the work. Amazingly the virtual board works great for us but I still missed a colourful wall with nice posters and motivational notes. I slowly started to mess our wall and now we have great posters reminding the team of SOLID Principles, our Definition of Done and what are we working in improving in the current sprint. We are now creating each other's avatar and start attaching them to who is responsible for helping an specific item of our Retro to be driven forward.

The past sprint was the one we improved the most in terms of targeting the items we have found to be problematic in our Retro and I believe the wall played a good part in reminding and driving the team towards such goals.


What about you? How do you radiate your values of Agility? How do you work towards springing innovation at your work place? How do you help people being happier at work?

Monday, 7 April 2014

Monday Thought: Is it Done?!

From: Murilo Lessa <murilo.lessa@>
Date: Monday, 24 March 2014 17:37
To: Dev All
Subject: Monday Thought: Is it Done?!

In our previous Retro we discussed our Definition of Done (DoD) and we are now in the process of formalising it. The DoD should be a agreed & shared among all teams so I invite you all to take part in this discussion and come up with the bare minimum that we understand as DONE.

Why?
Scrum requires Teams to build an increment of product functionality every Sprint that is potentially shippable. To do so, the increment must be a complete slice of the product, additive to all prior increments and thoroughly tested, ensuring that all increments work together.

n Teams, 1 Agreement! 
Asserting that functionality is done might lead someone to assume that it is at least cleanly coded, refactored, unit tested, built,and acceptance tested. Someone else might assume only that the code has been built. If everyone doesn’t know what the DoD is, the other two legs of empirical process control don’t work. When someone describes something as “done”, everyone must understand what “done” means.

Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the DoD does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all PB items in the increment.


That may be too much! No worries! When Teams aren’t yet able to include everything required for implementation in their DoD, this must be clear to the PO. The remaining work will have to be done before the product can be implemented and used.

But we already have a big Code Best Practices document!
The DoD is not a set of best coding practices. You are expected to  be using the Team Best Practices when doing your code but the DoD sits on top of it, at a more business level and is shared among the teams and Product Owners who know what does it mean for a certain story to be Done.

Where to start? Simple as we can. A story is Done when:
  • It has being tested (unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration)
  • It has being documented (code comments, type hints, confluence – if required, etc)
  • It has being pair reviewed
  • It has being validated by QA
  • It has being checked by Product
Is this enough? Is it too much? Keen to hear your thoughts!

Best regards,
Murilo

This is part of my email experiment - sent every 2 weeks - with the dev team I am part of, aiming to inspire them to acknowledge and question What do we do, Why do we do it, and How do we it

Friday, 4 April 2014

Apollo 11 code goes ‘open source’

source: Apcmag.com

It’s been famously remarked that the on-board systems in Apollo 11 had less computing power than a modern pocket calculator. Now we can see that the code which ran those systems was probably less complicated than the code behind the Windows Calculator.

As part of its celebration of the 40th anniversary of Apollo 11 and man’s first steps on the moon the space heads at Google have published the original code from the Apollo Guidance Computer or AGC.



The code was transcribed from scanned images of printouts for the AGC in both the Command Module (codenamed Comanche054) which reached moon orbit and was the return vehicle; and the Lunar Module (Luminary099) which took astronauts Neil Armstrong and Buzz Aldrin to the moon.

While the code itself is primarily of interest to programmers there are some amusing snippets which show that the geek sense of humour never changes.

Line 666 in the Lunar Module’s code has a comment identifying it as “NUMERO MYSTERIOSO” or the number of mystery while Lines 179 and 180 have both been commented by the programmer as “TEMPORARY I HOPE HOPE HOPE”.

If you want to load up the code and try it for yourself Google also provides links to an open-source AGC emulator.

Only impressive 1474 lines of code, including comments.. it’s amazing to say the least. At my work we have classes bigger then that - don’t start.. I am not proud of it…

Source can be found here.

Wednesday, 2 April 2014

Tips for Scrum Alliance's CSP Exam

The CSP Certification was on my radar for a long time but it was just one of these things I kept delaying, until I read about the changes to the certification process after January/2014

What has changed?

From 31st January/2014 onwards in order to apply for the CSP Exam you will need to have years of experience PLUS a set of SEU, continuous education units that you accumulate through attendance to Scrum-related conferences, presentations you give, blogs you write etc. The conferences and trainings will need to be endorsed by the Scrum Alliance for you to be able to claim units. Basically it means it is going to involve a lot more work.


The Exam

As I recall there were quite a few questions related to Ceremonies (specifically Retrospective, it’s phases, scope, goals, etc), Scrum Roles, Refactoring, TDD, Spikes, purposes of CI, ideal team structure, Acceptance Tests and how they are used in Agile, team Estimation, team structure, PDCA (plan-do-check-act), intentional and emergent design, "what would yo do if your team is failing to commit or under-delivering" (would you increase the sprint? make it short? and so on), about the variables involved in calculating ROI, ...
I found the exam tiring. It was not only about waking up 5am, driving for almost 4h from London to Whiterby and having to go through a 3h exam with 150 questions.. the questions are tricky. You are always left not knowing if you have chosen the right option although you are sure you did :-) Many of the questions are along the lines of "find what is THE BEST option among the ones bellow" and this is the catch. The options are all technically right but to find the BEST one...

I guess most books tend to repeat a lot of the same stuff, from all the reading material recommended by Scrum Alliance (25 books!) these are the ones you should read if you have the time:

1) Essential Scrum – Kenneth S. Rubin
2) Succeeding With Agile - Mike Cohn
3) Agile Estimating and Planning - Mike Cohn
4) User Stories Applied for Agile Software Development by Mike Cohn
5) Agile Software Development - Alistair Cockburn
6) Agile Software Development with Scrum - Ken Schwaber and Mike Beedle
7) Agile Product Management with Scrum - Roman Pichler
8) Extreme Programming - Kent Beck
9) Agile Retrospectives, Making Good Teams Great
10) DoBetterScrum-v2
11) Scrum Papers
12) Scrum Primer
13) CSP Preparation PDF


Strategy

I read only 2 books and the rest was be based on PDF's and Exam Simulations. I also complemented that with a lot of simulation tests.

I was a bit concerned about my strategy but at the end it worked so I guess I can share my notes and what I read. I believe previous professional experience really helps with the questions.

I have read the following books:
If you could bother I would also add another one to this list:
I have also gone through the following PDFs:
For questions and test simulation I used the free version of the following sites:

Some of these sites randomly select the questions so you can do these as many times you want, until you are satisfied with the results. I would definitely recommend Scale Study and since is quite affordable would advise you to seriously consider paying for it. Their questions resemble a lot what I saw in the exam.

When your time comes, don't spend hours in a single question, there are 150. Answer them as you go and flag the ones you are unsure. In my case I did all the test in 2h and spend the last hour checking the ones I flagged. Funnyly enough I had flagged 40% of them :-)


Personal Notes

I created a few documents containing study notes from the books and PDFs I have read and also the best questions I have seem while taking the mock exams. I am also making available my Ebooks and Agile files.


A digest of the few PDFs I have read. I am yet to write a big one that merges all this information.

Study notes from books and other readings a a full list of questions about the Agile world.

All books mentioned in this post and much more.


Additional Reference

Right from the start I've joined the Scrum Alliance CSP Exam Prep Study Group in Linkedin and went checking the notes of people who have done the test and were sharing their tips, notes and reading links. Among the ones worth having a look I would mention:



Saravana Bharathi's site, Agile Karma, contains a useful Reading List and also some more tips and useful links.

I would also recommend checking other Linkedin Agile/Scrum Groups since they always have a lot of useful information as well as already stablished blogs and websites such as

Scrum Alliance’s Agile Atlas contains many articles from top contributors
Scrum Training Series, with loads of videos
Source Making, Great info on Design Patterns, Refactoring, …

Team Dynamics

Pair Programming

Kanban


Scrum Alliance Recommended Bibliography

Title: Succeeding with Agile: Software Development Using Scrum
Author(s): Mike Cohn

Title: Agile Estimating and Planning Author(s): Mike Cohn
Publisher: Prentice Hall

Title: Agile Product Management with Scrum Author(s): Roman Pichler
Publisher: Addison Wesley

Title: Agile Retrospectives
Author(s): Esther Derby and Diana Larsen Publisher: Pragmatic Programmers Publication Date: 2006

Title: Agile Software Development with Scrum
Author(s): Ken Schwaber, Mike Beedle Publisher: Prentice Hall

Title: Agile Testing: A Practical Guide for Testers and Agile Teams
Author(s): Lisa Crispin and Janet Gregory Publisher: Addison-Wesley

Title: Clean Code
Author(s): Martin Publisher

Title: Continuous Integration
Author(s): Paul Duvall

Title: Extreme Programming Explained
Author(s): Kent Beck

Title: Extreme Programming Installed
Author(s): Jeffries, Anderson, and Hendrickson

Title: How Do We Know When We Are Done?
Author(s): Mitch Lacey

Title: Implementing Lean Software Development
Author(s): Mary Poppendieck, Tom Poppendieck

Title: Planning Extreme Programming
Author(s): Kent Beck, Martin Fowler

Title: Pragmatic Project Automation
Author(s): Clark

Title: Project Retrospectives: A Handbook for Team Reviews
Author(s): Norman L. Kerth

Title: Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience
Author(s): Arlo Belshee

Title: Refactoring: Improving the Design of Existing Code
Author(s): Fowler

Title: Retrospectives – The Missing Practice
Author(s): Tim Mackinnon

Title: Scrum Primer
Author(s): Pete Deemer, Gabrielle Benefield, Craig Larman and Bas Vodde

Title: Test Driven Development By Example
Author(s): Kent Beck

Title: The Art of Agile Development
Author(s): James Shore

Title: User Stories Applied
Author(s): Mike Cohn

Title: What is Definition of Done (DoD)?
Author(s): Dhaval Panchal

Title: Which End of the Horse
Author(s): Jeffries

Title: Selling Agile – How to Respond to Concerns from Management, the Business, and the Team
Author(s): Michelle Sliger and Stacia Broderick