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

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

Monday, 24 March 2014

Monday Thought: "Why do we do What we do"

From: Murilo Lessa <murilo.lessa@>
Date: Monday, 24 March 2014 17:37
To: Dev All
Subject: Monday Thought: "Why do we do What we do"

The road to empiricism and continuous improvement is about a diligent questioning and analysis of everything we do.

The “Scrum Bible” is only 16 pages and easily digested, but as we experience, making it work right is a whole different game :-)  The are no Scrum flavours, there are no "Scrum but”s.. You either do it or don’t. Simple as that.

For those who care about people over process, here goes a PDF for bit of evening relaxation.
It worth to see what is prescribed in there and how we apply to our reality.

Have you all a great week!
.M


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