Monday, September 28, 2015

An Agile Balance

I wrote a couple of posts back about my ScrumMaster training that I would wrote more about how I would apply this to my job. This is the second such post.

This one is about the need to balance the discipline of what you are doing correctly with the ability to adapt, learn and change. If one is not careful, you might "discipline" as a static thing. In reality, while you are developing and practicing your discipline(s), you are at same time (or you should also be) learning and adapting. When viewed this way, discipline is a much more active endeavor. In his slideshare titled "The Tao of Agile", Fabio Armani states that "Both (Lean and Agile) offer a thinking tool set that allow us create new models and different approaches".

Reflecting on one of my recent projects, I had the thought, "Finally, the Product Owner is starting to 'get it'. It's a good thing I was so disciplined about this!" When I went back to review with them what they had "finally learned", I could also see that my own approach had adapted and evolved. I was also "getting it" and learning things about the project that were not initially clear to me. This is what the an Agile MindSet is all about -- being open to this "thinking tool set".  Can you  recognize when new models & new approaches either need to happen or in fact have already happened -- either for you customer or yourself?

Friday, September 11, 2015

Some Thoughts on MinneDemo21

Last night I attended MinneDemo21.     It was the 1st time I attended after several attempts.   I will be attending again, shame on me for not getting there earlier.  Several general reactions:
  1. There *is* cool stuff happening in my local community
  2. There are lots of energized, passionate individuals working on that cool stuff
  3. There are few (need to be more) "deep pockets" trying to encourage, nurture, and fund this so more cool stuff will be created locally.
  4. Shame on me for not being a little fish in this pond or doing more to connect deep pockets with the community.
In the spirit of doing my "little fish" thing to nurture and encourage, here are links to the companies that presented along with my twitter stream that captured my reaction in realtime.

The Presenters:

Want more?  Here are videos of each presentation posted to TECHdotMN










Sunday, July 5, 2015

Don’t be a Killjoy

If I am dating myself with the title of this post, it was one of the more valuable take homes from my recent CSM Training Class. I had always considered myself to be very flexible and adaptable. However, during one group exercise, I was most definitely a Killjoy. This came during one of our opportunities to learn and adapt — an extremely important agile ability. I justified this (rationalized this) by “suggesting” to the group that we were not yet ready for a change one team-mate was trying to introduce since he had introduced it very late in our short planning period. We went through one more iteration and eventually did adopt this suggested change (it was indeed a breakthrough in the team’s output) with my full support.

However, there were three important things the instructor pointed out this particular exchange:
  1. Don’t be afraid to “Fail Fast” — This was indeed my greatest fear. Given how late in the planning cycle my team-mate had suggested this change, I feared that our output would be even lower that previous iterations. No doubt we would have quickly realized that we did not all know what to do. This this fast failure leads to the second point. 
  2. Don’t be afraid to dynamically adapt — Even during your iterations. I saw numerous times during this and other exercises that team members were constantly giving each other feedback and were adapting their techniques and methods mid-iteration. 
  3. Lastly, how you deliver the message *is*important. When I said that I “suggested” we were not ready, it came across *much* more forcefully than a suggestion. While I know the person that suggested the idea knew I liked it, others on the team might have heard in my language that it “was a terrible idea”.  As I mentioned previously it was a good idea that we eventually adopted.
Don’t mistake “binary clarity” with being a Killjoy on rapid learning.
  

Monday, June 29, 2015

Certified ScrumMaster Training

Despite the fact that I have been a Agile Practitioner for many years and while I sent (read paid for) many employees to attend classes and certification tests over the years, I had never done so myself. A few weeks back I rectified that and attended CSM training/certification from the Scrum Alliance. I went into the class thinking that much of this would be repetitious (parts of it were), that there would be beginners (there were) and that the exercises would be useless (they *weren't*). Each of those points is worth a quick paragraph.

Material
It's never a bad idea to review the assumptions and principles on any material. In this case I found the most valuable was review of the roles of a Scrum team. I was able to apply this to my current projects and realized that in at least one case, I really do not have a Product Owner. One attendee asked, "Without a Product Owner, do you really have a project?" This is an appropriately challenging question. It was somewhat encouraging to hear that I was not alone in this challenge.

Other Attendees
There were several attendees that had recently been laid off and as part of their severance packages included some training dollars. Several of them were classic PMP's from the PMI. They were struggling with the basics of SCRUM since the material was very different from their backgrounds. However, their questions were valuable as they allowed the instructor to underscore key points and assumptions. The experienced Agilists were also add some stories from the front lines that added to the discussion. As with all training that allows you to "get away", the real value is in hearing those real world stories -- what have other people tried and not tried, what has work or not worked, etc.

Exercises
I take my hats off to the Scrum Alliance on the exercises they include in their training. These no doubt have been refined over the years. But given the relatively short time frame of a two day class (you take the certification test on your own after the class) the exercises most definitely gave us a chance to quickly plan, execute, adapt and repeat. It was both fascinating to watch and be a part of. In nearly all of the cases it taught me somethings(s) about myself.


Over the next couple of blog entries, I will share more about what I learned about myself and how I will apply it to my work.

Thursday, July 31, 2014

The Importance of Common Language

I had previously written about “binary clarity” and how gratifying it was to hear others using that language after I left a position where I had used it frequently. The reason this was so gratifying was I realized the others had internalized what it meant. In short, the group had developed common language Further, they had internalized the importance of the concept.

Today, while attending a daily standup (I am now an observer, not an active participant) I heard the use of more common language. When I heard term used, I could tell everyone knew what it meant and what actions would follow.

I have an older brother that is now retired. He frequently comments on how he enjoys having his kids quote him. He likes to add, “Others will carry on after me”.  Common language is critical. It’s even more gratifying when you are the originator of the language.  It confirms that you have had an impact on the group and that others will “carry on”. 

Tuesday, July 15, 2014

Agility, Demos, and Credibility with your Customer

Once I had the opportunity to present at my company's annual User Conference. The Product Manager for the session set a goal that in hindsight was a pretty aggressive demonstration. When he walked through the outline, I thought, "Yep, that can be done" and the synopsis went out to the conference attendees. As frequently happens, work and life got in the way of the preparation time. I was fortunate enough to get some fantastic assistance from my colleagues on the requisite slides and that helped to further focus "the story" that the demonstration. I entered the conference feeling reasonably prepared.

For some reason the day before the presentation, "the buzz" around what I was going to demonstrate began to build. There was a Field Services employee that read the session synopsis and said, "You are going to do *that* during a live demonstration-are you crazy?" Shortly before the presentation, I ran into a customer that had intended to come, but then had another commitment. He apologized by saying that he was going to have to miss my "high wire act".  I was suddenly nervous.

Wednesday, April 30, 2014

Agile Performance Testing

Two recent events had me thinking about the subject line. One was a Webinar given by CloudBees titled, “ Adding Performance Testing into the Continuous Integration Process “ (the link is the Webex recording), the other was reading a blogpost shared by a colleague, "Combining Agile with Load and Performance Testing: What am I in for?” In essence both of these presentations ask the same basic question -- with all the focus on Continuous Integration and rapid feedback, "Why hasn’t development embraced Performance Testing as part of their development cycles?" The short answer from both — “It’s Hard”