Tuesday, August 30, 2016

Teacher and Principal step back to let student team self-organize after a rough day


A message from the Principal of Hope High School in Arizona regarding a student team that was having some personal challenges getting organized around a fairly large community event they decided to take on as a team....
Things worked out great! 
Moses really had a handle on the forming, storming, and norming speech and the biggest impact was Mr. Cook and myself leaving the room so they could hash things out. 
They have added items to their team agreement and even came up with their own incentive reward plan when the team meets certain goals. 
They also realized a key lever in their team stress was that their scrum board was not in a location that was functional with their meeting space. So, without asking us...they moved it...AS A TEAM!! 
They were so proud of their progress today and everyone left on cloud 9. I couldn't have asked for a better turn out. 
P.S. they are shifting to 1 week sprints. 

Notes about this message...


A student Scrum team had been organizing a very large community event. They were using two week Sprints to deliver their work and had selected a large number of activities to do in each Sprint to meet a perceived goal of 16 events (self-created).


There were some conflicts arising as students who recently started this school year worked to organize themselves to share work.  


The Principal called me for some guidance. We discussed ways to empower the students to solve this rather than teacher or principal involvement (something important to the Blueprint Education folks and their culture). We would share the Tuckmann team formation model of Forming, Storming, Norming, Performing to let the students know that what the were going through is normal and there is nothing wrong with them.



Moses (Scrum Master)
Hope High School
(c)Copyright Blueprint Education, 2016

Krissyn Sumare (the Principal) sat in the room for support while Moses (a Scrum Master on the student team) learned about the concepts, why it was important, while intently taking notes and asking questions. He was sure this would help the team feel better about things and was anxious to give it a try with his team-mates.

Moses went so far as to consider how to get involvement from other Scrum Masters in the resolution.


Moses' involvement in the ultimate solution to this problem is awesome to me. Let me explain.....

I met Moses last year at this event. He was a shy, reserved person, who looked down at the ground and often avoided eye contact. 

The Moses I was now talking to intently took notes, asked direct questions, stood tall and was proud and determined to help his team. Moses has become a person who's primary passion is helping the people on his team and ensuring they are all heard. In their environment, this can be challenging.


He seems to have taken on the persona of team "healer". I heard about Moses taking students out to other rooms to talk with them until they feel better. I heard about how he gathered everyone to make sure they would all be there as he was worried that everyone might not be there the next day to listen to what he had learned.  Before our conversation, people were pretty down.


All I can say to Moses (who I hope reads this).. WOW! I am so happy for you. Your outgoing, caring nature and ability to facilitate for people to solve problems will be a great benefit to all those you come across. I am glad you found something to really excel at and am more glad to have met you. 


Other topics to notice from this message....



  • teachers stepping out of the classroom
  • students coming up with their own process and goals
  • team self-organizing without permission to move their board
  • leadership not getting in the way of self-organization
  • a realization that shorter sprints may remove some stress

I hope you can agree that this team is well on their way to being a very successful student Scrum team with much to offer the world and a great future! They are all such awesome, brave people.

If you would like to learn more about what is going on at Blueprint Education and/or Hope High School, reach out to them at http://www.blueprinteducation.org/agility

I know they would be happy to start a conversation with you.


Monday, August 22, 2016

The Always Do It Differently Approach


Over the last few years, I have found myself working with organizations, coaches and consultants who use variations of a theme as follows;
  • Standard Team Startup Checklist
  • Team Kickoff Procedure
  • Standardized Reporting Template
  • Standardized KPI scheme
  • Proper Percentage of Developers to QA

These conversations often seem to revolve around the concept of "scaling agile" and "efficiency" for the coaching team.

I will submit that perhaps a different approach might be possible.

I see each team and each situation differently. I prefer to put my complete self and energy into doing the best for those that I work for based on their specific needs.

I don't actually feel comfortable with "following the standard checklist". That made sense for flying an aircraft (and necessary). I find that when coaching, it hinders my ability to be the my best for the team, organization or group I am working for.  Yes, it is more work for me. However, I find the client gets better results if I meet their needs rather than the needs of standardization (or effeciency).

Some will claim checklists for startup are about "quality"... OK.  I concede, in some cases that might make sense in a Training context. 

We are not trying to create "standard work" or "same piece size" when we start a team. We are working with a living system of people who have invited us into their lives. They deserve our respect. 

I find that by embedding myself completely into a situation and having an approach of "Always Do It Differently" keeps me fresh, engaged, doesn't let me slack off, and helps me to love my career.

I understand that Innovation does not come from following scripts and the same procedures every time. I know as a professional that I too must be Innovative and always learning. 

What is strange to me about following predetermined team startup processes is that we are so often asking our clients to question procedures and standard approaches. We want them to value change, get used to it, embrace it! 
  
Killbot Assembly Line - Courtesy of Pascal

I enjoy the challenge of having the best session I can come up with for the people I am working for. It keeps me alive, keeps my professionalism up, and gives my clients the best possible help for their situation.

It stands to reason that every coach will have some common tools they know work for different situations and that they are comfortable with. We don't need to re-invent the wheel. That would not make sense. However, by stretching ourselves to always come up with a different approach or idea for the next engagement or team keeps us learning and exploring!

I personally enjoy the reaction from teams when they received a session that I invented when I woke up that morning, perfectly matching their situation, or knowing that I have the skill to take an existing technique or tool and modify it for improvement while I am flying to their city.

Agile coaches should be embracing, innovating, changing, and experimenting along with their clients. I need to be clear here. There is a difference between training and coaching. This message is more about coaching. That being said, I know some amazing Teachers who pride themselves in always changing and improving and would be very unhappy to hear about a standardized, designated way to start a new class for the school year. 

For the next few months, consider trying ....

"The Always Do It Differently Approach"

  • Start every team differently based on their needs
  • Talk to the team and then consider where it makes sense to start
  • Take existing coaching tools and techniques and see if you can improve them for the current situation
  • Try and push yourself to learn something different from another coach or leader
  • Build some methods to share new ideas between coaches
  • Feel the joy of pushing yourself to a new level to serve others
  • See if you end up being a better coach for this

If after several months, you want to go back to procedures and processes, you always have that choice..  Agility is after all about what's right for people, and you as a coach are also a person. 

If you would to talk about me providing my services for yourself personally, for your team or your organization, feel free to reach out to me. I enjoy new challenges :->

More importantly...


For the next few months.....

 consider.......

 "The Always Do It Differently Approach"






Monday, August 15, 2016

Changing your approach.. Let them know.


I recently found myself hunting around for a post about a topic that has been come up a few times lately.

After some digging, I discovered a post I was looking for at a previous employer's web site. I'm happy to send you over there.. They are good people.

I believe the message to be important enough to not ignore.

One line from the article.....
Consider letting people know you are changing your approach.  It might not work for everyone, but some might appreciate knowing that you intend on doing so.

Here is the link...   http://www.agile42.com/en/blog/2015/01/17/let-them-know/

Enjoy.

Friday, August 12, 2016

AnsibleFest 2016 Presentation on Test Driven Development for Infrastructure

I recently had the pleasure of meeting some amazing people at AnsibleFest 2016 in San Francisco.

I was presenting a session for beginners on a pattern to introduce Test Driven Development to Infrastructure.


The Test/Maintain Loop for Infrastructure



Actually, it wasn't just beginners... which makes me really happy. :->


To truly do Incremental Infrastructure delivery, we must have an automated way to know that we haven’t broken something else in the system when we make changes.
The key is finding a method to allow constant evolution of our code base (infrastructure).
We do not need to reinvent an approach. Test Driven Development concepts have proven effective in incremental software delivery and can be re-used effectively for infrastructure as code.
Mike Caspar, 2016 

Slideshare of the presentation

http://www.slideshare.net/MikeCaspar/testing-for-infrastructure-as-code-for-ansiblefest-2016-64540514

Source code of files for the presentaiton

https://github.com/MikeCaspar/ansibleFest2016SFO

Audio of the session provided by Ansible.

https://www.ansible.com/beginners-guide-to-testing-infrastructure-as-code


Github source repository for project in the works....

https://github.com/MikeCaspar/playbook_test_framework



Enjoy.

Tuesday, August 9, 2016

Decrease the time to learning


Consider that the goal is to Learn fast.. not fail fast. 

We do want tests to fail fast... 

...  to decrease time to learning.

Friday, August 5, 2016

Choice of wording in coaching conversations




A fascinating coaching discussion today....

The difference in perceived threat to a leader when sharing an insight and using the phrase "most organizations" or "many organizations".

Realize that the recipient might perceive or compare themselves to the comments. The choice of words can create two totally different feelings during the conversation.





Monday, July 11, 2016

Using SonarQube in a Shared Docker Image to simplify Java code quality testing for teams - Part 1

As teams work to increase their speed to production, a discussion about code quality will inevitably come up. 

In many cases, development team members (even with production level tools in place) have difficulty checking code quality before checking code into a shared repository and have to wait to see results. 

This article seeks to provide a method to allow code quality checks using SonarQube to happen on the development station before having to check to the code into a code repository while also providing a consistent base Plugin­ set for team members. 

Although the procedure below gives a base set to start with for Java developers, it is provided as a guide to allow you to use a similar approach and build something that is perfect for your unique environment.

This is the first of several posts.

Part 1 - A Quick-Start to using SonarQube and docker on a developer workstation with no long-term data retention 

Part 2 - An extension of this procedure to a cloud based server (such as Digital Ocean) 

Part 3 - Some notes about storing data long-term into a database.

Important Notes:​


The Quick-Start procedure in this document launches a container on a workstation that is disposable and will not retain any data if re­-created.  
  
An understanding of docker installation and execution is implied.

Please consider firewall implications as source code may become available at port 9000 at your workstation.


Technology used:




Article Sections 

  • Quick­-Start (development station) 
  • Sample launchable Dockerfile and image


Quick-­Start 


Using the shared Droplet instance from your workstation


docker run -d --name sonarqube -p 9000:9000 mikecaspar/docker_sonarqube

You should see the latest image download .... 




You will be able to confirm the server is running with the command: 

docker ps


It should show you something like this ... 



Notice that the SonarQube server starts at tcp port 9000.  You may need to make firewall adjustments. 

To get the local server to see it’s current information, use the Url: 

http://localhost:9000


The default SonarQube instance will look like this:  






* Notice the red warning that data stored in this instance will not stay in the server after it has been restarted. 


To add your Java project to the local instance for current code quality information, go to your Java project directory (where you POM file is) and type: 


mvn sonar:sonar


By  default , the Sonar plugin looks for a local Sonar Server to store data. 

The sonar plugin will download from your configured sources, analyse your code with the currently configured rules and then store the results in the current temporary instance. 



Now, you can see your progress without the need to check your code into a repository first!


Go back to your web instance at http://localhost:9000 and you will see how your code quality is. 

This sample has a few hours of technical debt shown for presentation purposes ... 





 A more detailed view.. 





Sample launchable Dockerfile and image 


A sample Dockerfile is available at this git repository:  

https://github.com/MikeCaspar/docker-sonarqube

This repository could be used as is to launch containers without the need to create your own if you are happy with the settings in the repository. 

If you to make your own changes, feel free to fork or clone the repo.


The Dockerfile is available at  

https://raw.githubusercontent.com/MikeCaspar/docker-sonarqube/master/Dockerfile 

The default admin userid is ​admin​

The default admin password is ​admin​