Let us talk about what A ScrumMaster is really about

I once attended an advanced ScrumMaster training. The trainer brought out the following pictures and asked us to discuss what the role of a ScrumMaster was. 

The answer? All of them! A ScrumMaster is so many things, he/she is a sports coach, a loving parent, a sheep dog, a servant, a bulldozer, an orchestrator, a meeting facilitator…

I wonder why the trainer didn’t include this picture:

The software industry (at least in China) is young male dominated, there are software companies who hire young pretty girls whose job is to talk to young mail engineers, motivate them and make them happy. If a ScrumMaster is also a cheerleader, wouldn’t be fantastic? :-)

But enough! Software engineering is hard enough, having this mushy, fluffy talk doesn’t help! A good ScrumMaster might need to be all those things (but a loving parent, really? How condescending!), but if you can produce a “certified” ScrumMaster after a two day’s training (plus some hefty training fee and an exam), that is a miracle!

Instead, let us get down to the earth and discuss what skills a ScrumMaster should have. In my opinion, for a ScrumMaster to be effective in facilitating the team, he/she needs to have a certain level of knowledge in every function of software development, including: 

•  Technical skills: software engineers are notoriously snobbish, they will respect you if you possess the skills that can participate and help them, they will not respect you because of your position (they might obey you for some time until they find another job, but it won’t inspire them). To build rapport with the team, a ScrumMaster needs to at least have a degree of technical knowledge to earn the team’s respect and is able to facilitate and participate the team’s decision-making.

• Business knowledge: in an Agile environment, defining/refining requirements is an integral part of development process, product owner acts as a proxy of users, and works out the details with team. A ScrumMaster needs to have a degree of business knowledge to be able to facilitate the team.

•  People management and leadership skills: in a traditional team, team members report to functional managers, and a project manager resorts to functional managers to impose control over the team members. An agile team is cross-functional, and it is expected to be self-organizing, but before it can reach that point, it requires much stronger leadership skills to build up the team, especially if a team is newly assembled from different component based teams in a traditional environment.

• Process improving capabilities: An Agile team is expected to improve practices as it conducts its business. Copying practices from textbook is doomed to fail. A ScrumMaster is not just a “retrospective” meeting host, he needs to have the capability to lead the team to do deep root cause analysis and come up with ideas to improve the process. 

(update on 2016/06/30):
I had an interesting discussion with my colleague on this. His opinion is, "no, the most important skills a ScrumMaster should have are communication skills and facilitate skills". I do not deny that a ScrumMaster's job is to facilitate the team to make it function better (despite what those mushy pictures describe), but my opinion is: to facilitate a team effectively, a ScrumMaster needs to have the above skills.

I reflect on a lot of discussions I had with my team, a lot of goes like this:
Me: "wait a minute, that is a 4th idea, let us park that idea, and first discuss through these ideas..."

Me: "we have discussed this idea, it is essentially the same as ..."

Me (interrupt someone): "please let him finish his thoughts, there is something interesting there, afterwards, you can bring up your opinion."


 Software technology is very intense, I am not sure if I hadn't possessed a certain degree of technology skills, I would be able to identify the 4th idea, and direct the team to have an effective discussion. What I have observed is that the team members usually think very quickly, jumping from idea A to idea B to idea C, and often times go back to idea A (in a different form), the facilitator needs to setup a structure to make sure team members discuss through ideas thoroughly, and everyone has an equal opportunity to voice their ideas.

A meeting happened yesterday run like this:
team: adding a checkbox in UI is very difficult 
Me: why?
team: because this UI uses a technology ... (I have very little idea what that is)
Me: who is using this UI?
team: administrators 
Me: does an administrator have to use this UI? 
...
Long story short, this is a discussion that uses business knowledge to select/define technology approach. 

Incremental vs iterative developing

I am starting to learn drawing, I do not aspire to be an artist, to me, drawing is like a way of communication, so many times I wish I could draw the pictures in my mind. While I am learning drawing, one lesion I learned early on is that you have to get the structure ready and right early on, you put on finer details later on, and some finer details will pop you drawing out, making it vivid. But if you get the structure correct, at least you won’t get a terrible picture, so terrible that no amount of finer details can make it look good. 

For software development, we need to take a similar approach. My drawing is not so good at the moment, so I took the pictures and ideas from “User Story Mapping: Discover the Whole Story, Build the Right Product”.

Incremental

The problem with this approach is:

1. You are optimizing prematurely

     You work on something to perfection, only to find out later that this kind of perfection is not necessary. We know this from performance tuning, without taking the full picture and identifying the bottleneck, we can fine tune a part to death and won’t make a significant difference. 

     2. You may lose sight of critical risks at a later stage, when you realize that the pieces that you’ve work out to perfection can’t be integrated together. 

     3.  It is easy to lose sight of the whole picture when working on piece by piece

        

With (badly implemented)Scrum, it is easy to make this kind of mistakes. You pick up stories from the backlog and work on them without knowing how these stories will come up and make up a whole picture.

   

     4. Even if the whole picture turns out to be perfect, when it is released, it may not be what the end user wants. You lose the opportunity to be told by users earlier.

Agile’s value is to tell you earlier (way before step 5) whether you are doing the thing that users want.

Iterative

This is how one draws a picture, and how software should be built. 

Last year, I was involved in a POC which was to prove the feasibility of a project. The team tasked with the POC took an “incremental” approach: they made several POCs to test several parts of the project, and concluded the project feasible. While no one single POC tested the project from end to end. The project was claimed feasible, and all teams were thrilled to jump onto it, until they stumbled on a critical block. Had they performed an end to end POC, they would’ve found out the block. 

Here is the bad news. In reality, users might ignore you completely until you’ve reached step 4 or 5:

You need good product managers or product owners who know how to engage users, and how know how to extract information from them. 

Why Agile didn't work

Why Agile didn't work

An ELK Docker cloud

My job involves analyzing massive log files from different customers. To improve my team’s efficiency, I created an ELK Docker cloud. Here is its architecture:

(We like to fantasize that we are superman that can solve any kind of customer issues, in reality, we are more like this: always in the water, and use our flesh to stem the tide :-) )

Back to the topic:

• Moose: It is a Nodejs application that users can upload log files. Fun fact, elk and moose are different, and you should know their differences if you are a hunter: http://k99.com/moose-or-elk-how-to-tell-the-difference/.

·                       Moose stores users’ actions in a MongoDb.

• DockerRunner is a python application, which uses Ansile to start Logstash containers to process users’ uploaded logs. Users can have different log analyzing algorithms for different log files, so for every user’s upload action, a new Logstash container will be started.

          Users can view Logstash containers’ status in Moose and also can stop and remove Logstash containers.

• Elasticsearch forms a cluster.

•  Users view logs through Kibana. Kibana has a customized plugin to enable automatically setting up discovery, visualize and dashboard (see my pervious blogs).

          Here is an example of what you can see with Kibana:

• All web applications are proxied through Nginx. (there is actually only one Nginx instance proxing all web applications)

• Service registry, discovering and monitoring is done through Consul and Docker Registrator.

• All operations are done through Ansible. Operations such as provisioning a new node, install/start/stop/upgrade applications.

Here is how these applications physically located:

• VMs are managed through Vagrant

           VM node information is defined in a boxes.yml file, so it is easy to start/stop nodes:

boxes:

  os:

    ubuntu: wily64

    ubuntu_version: wily   

    has_systemd: true

    proxy: http://web-proxy.houston.hp.com:8080

 

  ctrl:

    name: ctrl

    ip: '192.168.33.10'

    memory: '2048'   

  elknodes:

    size: 3

    name: elk

    ip: '192.168.55.1'

    memory: '4096'

   

  kibananodes:

    size: 1

    name: kibana

    ip: '192.168.66.1'

    memory: '4096'   

  ports:

    ctrl:

      - { guest: 8500, host: 8500 }

      - { guest: 80, host: 7500 }

      - { guest: 27017, host: 27017 }    

      - { guest: 3000, host: 6500 }

The nodes’ name will take the form of name#number, for example, elknodes will be named elk1, elk2 and elk3. 

• Ansible does all the heavy lifting of provisioning nodes, installing/starting/upgrading applications.

          A Vagrant provision python script will update an Ansible variable file so Ansible knows what nodes it is looking after.

         The Ansible variable file also defines what each node is for:

master_node: 'ctrl'

registry_node: 'ctrl'

proxy_node: 'ctrl'

mongo_node: 'ctrl'

kibana_nodes: [kibana1,]

moose_nodes: [kibana1,]

elk_nodes: [elk1,elk2,elk3,]

logstash_nodes: [elk1,elk2,elk3,]

             

• Docker_Runner runs Logstash containers. It distributes Logstash containers evenly onto VMs. This distribution can be done by Docker_Swarm, but in my experiment, I found out Docker_Swarm is not that stable, so I implemented the distribution logic in Docker_Runner.

• One Elasticsearch is running on each node. ElasticSearch instances form a cluster. Clustering is done through a runtime parameter discovery.zen.ping.unicast.hosts. When Ansible starts an ElasticSearch container, it first check Consul the existing ElasticSearch containers and supply that information in the discovery.zen.ping.unicast.hosts paramete.

Because of the way Vagrant and Ansible are designed, starting a new VM and provision it is very simple: 

• Change the size of the nodes in boxes.yml, for example, change the size of elknodes to 4.  

•  Start up the node       

    vagrant up elk4

•        Provision the node (install necessary software and start an ElasticSearch)

    ansible-playbook apps.yml --tags=common,es --limit=elk4