Certified Agile Leader

I am very proud to say that I have recently been granted the honor of becoming a certified agile leader!

I attended the course for this distinction in November, 2015 led by Brian Rabon of The Center for Agile Leadership and the Braintrust Consulting Group. It was a wonderful experience that really made an impression upon me and building upon my agile leadership skills and growing as a thought leader in general. This blog was actually started out of inspiration from this class to find my voice and get my thoughts out to others.

The first part of the journey was a “full” 2 days of classwork (and some homework assignments)  at which time upon completion, I became a “candidate” for the agile leader certification. The class then had a specified follow-up period in which you actually demonstrate how you are utilizing the agile leadership skills that the class teaches and  is receive really good feedback and perspective being “back in the mix”of daily work. This follow-up really helps reinforce the ideals as often it is too easy to go to a class, become motivated and lose any momentum when the reality of daily work returns. I feel like this tailored experience helped not only gauge if the principles I learned stuck with me but did I make it actionable in any way. If successful in demonstrating that you are applying the concepts of an agile leader you learned, you can be granted certification.

The class is kept intentionally small, I assume, to facilitate a high level of communication and participation but it also allowed it to be a very personal experience to the overall journey with a small group. I was very fortunate to be in the inaugural class for this experience with an amazing group of classmates. It was also good to get a mix of industries (including some of Brian’s own company members from Braintrust) so that we could see that often issues in leadership are the same and just in different domains. The members of the class, like myself, were all people seeking to do something different in their companies and become stronger leaders. I think that this commitment added a real personal investment by everyone who attended. I felt a part of a group who chose to be there and were not merely sent by their company to attend.

We were all very open and candid with one another  but defined our “group rules” before we started (therefore embodying the ideas of a team agreement which is a great principle for any collaborative group). It was a safe space to express yourself (the good, the bad and the ugly) for sure. People disagreed, people agreed and connected ideas similar between companies and shared some great personal conversations over lunch. Very little time was centered around my classmates on “the problems” and degenerated into a gripe session, we all accepted and knew we had obstacles in doing what we do, especially as we all sought to do it differently than those that may have come before us.

I described the class afterward to someone as “I felt inspired by all the ideas and conversation I was exposed to as it resonated with me and my beliefs.  But I also completed it somewhat emotionally drained through the focus of my self examination of my own current state of being a leader. It helped me focus on what a leader is and does”.

If you have not had the chance to hear Brian speak or take his classes, I would highly recommend it.  He is very transparent about his agile journey with himself and his company and definitely someone who applies agility throughout his personal and professional life. I found it very inspiring to gain his personal insights of agility and its application towards building agile organizations. I personally feel like a great deal of organizations could benefit from taking a moment to think about how they work, what it means to their message and how it impacts their people.

I think I can sum this up and reinforce my journey moving forward with an early quote by Mike Cohn; “Agility is not something you become. It is something you become more of …”

That being said, although like a product release plan itself, I have clarity of purpose in the immediate, I cannot wait to see how my own path to agility continues to unfold.



Why do I do this?

I typically start my blog with a quote that is meaningful to me or has inspired me to think about a topic. I wanted to incorporate one more directly as I think it fits better in context.

The current vision of Apple Inc. is

“We believe that we are on the face of the earth to make great products and that’s not changing. We are constantly focusing on innovating. We believe in the simple not the complex. We believe that we need to own and control the primary technologies behind the products that we make, and participate only in markets where we can make a significant contribution. We believe in saying no to thousands of projects, so that we can really focus on the few that are truly important and meaningful to us. We believe in deep collaboration and cross-pollination of our groups, which allow us to innovate in a way that others cannot. And frankly, we don’t settle for anything less than excellence in every group in the company, and we have the self- honesty to admit when we’re wrong and the courage to change. And I think regardless of who is in what job those values are so embedded in this company that Apple will do extremely well.”.

Re-read that for a moment. It tells you their beliefs, values and dreams.

Let’s go back a few years and look at the vision set forth by Steve Jobs for Apple. “To make a contribution to the world by making tools for the mind that advance humankind”.

Now, re-read that one. Again, it defines what they care about and why they do what they do. How do we set that context for ourselves and the organizations we lead?

Recently as part of an amazing leadership experience I was a part of, I was tasked to read Simon Sinek’s book “Start with Why”. (Amazon). Actually, and no offense to Simon, I couldn’t read it. It just didn’t pace well with me but I got the Audible version read by the author and it connected much deeper. Maybe a lot of it was meant to be conveyed in a more verbal manner or perhaps now that I have listened to the book, I could return and visually reinforce things. Either way, it worked for me. The key tenet of the idea is that as leaders and companies, we better inspire and create loyalty when we start with “why”. Most companies, as he points out start with “what” the do or “how” they are different than the competition. Apple is a prime example of a company that started with “why”. And the result is sometimes seen as almost a cultish following that believes in the products they build. Not that they are not good products (as I type on my MBP), but people will pay more and forgive Apple as they believe in the underlying “why” they do what they do. As Sinek repeats throughout his book, people buy not “what” you do but “why”. Your message can create an intense loyalty to your products far beyond rationality and cost.

This got me to thinking a lot about my own personal “why”. I am not a corporation, I am a person who seeks opportunities to grow, learn, build and help organizations create something special. But what is the “why” behind doing this? What is that motivator that makes me driven to lead from where I am, push boundaries, perpetually think and seek to grow myself and those around me? This became a driving question that I wanted to think about as not sure I ever really had done so before now.

I have spent 15-20 years in software in some capacity. I have been a tester, wrote automated frameworks, wrote code, performed operational duties, fixed hardware, lead units and teams, a scrum master, started a scrum revolution for an agency and state and now am an agile organizational leader for a product development group. I have worked across so many areas that I find it easy to relate to what people do. I no longer consider myself the most technical person in the room, nor seek to be. I understand enough to hold conversations and I hire well and trust those whom I hire. I focus more on building teams, cultures and organizations these days than anything else. I think about this sort of stuff constantly.

But that still doesn’t feel like the “why” behind what I do. It’s more background information about me.

This is what I come to as “why” for me.

Why I do what I do is this …

“I build teams and organizations. It’s not a job. It’s my passion.

I believe that creating the right  culture around what you are doing leads to better sustainability in organizations. It helps people create a place in which they want to work, helps them unleash their power of creativity, when provided the thoughtful opportunities to do so, and can permeate every aspect of what you do.

It guides how you build and hire and retain talented people. It gives people a common language and belief system that they can embrace and generally makes work a more happy, exciting and productive place to show up to each day. It connects each other in a real way to people so that you feel like you are a part of something larger than yourself. And with that connection and nurturing of the people, the adherence to real values that you nourish, this environment and culture can produce amazing things and support amazing people.”

Maybe not as great as Apple and I am still figuring it out for myself. But this is my “why”. Have you taken a moment to ask why you do what you do?

“Pleasure in the job puts perfection in the work” – Aristotle


hackIT Code Week


“If you cannot fly, then run.  If you cannot run, then walk.  If you cannot walk, then crawl.  But whatever you do, keep moving forward”  -Martin Luther King

Well, the day is finally here! hackIT code week is happening!

The plan: Create a timebox for development team members to generate ideas based on things they seek to explore, form teams around them and build their ideas.

The Outcome: Demo day of built product ideas at the end of the week to peers and other organizational staff. Votes are cast and the first hackIT winner is declared.

The general rules:

  1. Place any ideas that you want to solicit team members for on the Shipit board.
  2. You have until to 2/25/2016 to declare your hackIT project idea and your team
  3. You can be a single person team but not a part of multiple teams
  4. Your code must be FUNCTIONAL for a demo during lightning talk.
  5. Keep it small and manageable to build in a week!
  6. Ideas related to the business are encouraged, but not specifically required.

We seeded the idea about 30 days prior and asked folks to begin thinking about ideas and soliciting for team members to join them, combine ideas and generally find out what creative “itch” they felt they needed to scratch. In retrospect, this was perhaps a bit too long but I did so as not to distract them from their current product commitments as much. Plus, coming up with an idea sounds easy, but can really be very hard when the end goal is to commit to that original idea. So I think it worked out well.

We had several ideas emerge including several hardware/software products, mobile apps, a scheduler system for operational support and a driving game that allows control of a website from a mobile device as a steering wheel.

So, why did I do this?

Simple; I strongly believe in a few principles as a part of how I am wired to work and think:

  1. I believe in the power of putting togethe r creative people to do amazing things and I have complete faith that this happens when you follow this principle
  2. I believe software development is a creative art and as so those who do it are creative people and need space to be creative.
  3. I love my teams. I love the fact that they are composed of diverse individuals who can come together and share a common set of values yet still hold onto the diversity that makes them individually amazing people.
  4. I believe that if you truly want to be innovative, you have to make space to do so. Trying to force innovation in the midst of the daily “getting sh*t done” is like just digging and believing that eventually you will strike gold. Building the right culture of trust and responsibility, leveraging the creative minds you hire and creating opportunities to let them explore, connect and cross-pollinate. This is where innovation truly happens. Expecting that people will merely be innovative without the time to do so,  a culture of experimentation and a lack of fear in failure is not reasonable. Creating these opportunities is where you find the best potential for innovation.

So, what came out of hackIT?

I expect you want to tell you about all the amazing innovative products we designed as a part of our BETA test for an innovation  event. Well, guess what? I can’t.  We had some amazing product ideas and technical approaches come out of it, but in my eyes that was not the largest value of our first attempt. What happened is we continued to commit to our cultural values and I observed that we were being true to what we said we believe. We had fun, we learned and we continued to connect in doing the thing we do.

How so? Let me give you some of my observations …

Team members just formed functioned as long standing teams.

Because we have been serious and deliberate about defining the way we work and have created a culture that supports the core values for our group and the way we work, we share a common language of working. Teams formed their own ideas and then formed around the idea based on the desire to make it happen. That intrinsic motivation on each team member’s part to see the thing they chose to build coupled with team approach to development led me to observe team members working together and supporting one another that may have never worked together before.

We helped share some of the ideas of how we work with other areas of the organization.

At least one team was composed of team members that were composed of members from an area of the organization that does not have the cultural definition nor work like we do in product development. Feedback from this group was that it forced them to think in different ways. They admitted that they are usually a group that plans a lot before taking action and were unable to do so in this case. They said they learned a lot from the value of small horizon experimentation and build approaches. Plus we continued to build relationships with others and expose them to things we believe.

We had unintended effects.

Groups outside of product development began to become excited about hackIT. Our human resources group showed up to see the event as well as people from other areas of the business. They all wanted to see what we were trying to do. The idea that I was so personally passionate about started to organically grow and ask people what they could do to sponsor innovative space for their own groups.

Following our demo day, I returned to my office a little spent from all of the event (and collecting my thoughts before going for a beer with the teams to celebrate) when several people came to visit me. A few came by inspired by the creativity shown from the event and wanted to express their admiration for a particular product idea but one stuck with me as an unexpected side effect…

I had a person from one of our shared service areas come and relay this to me …

“I just wanted to come by and tell you; product development is not typically ‘my thing’ but I really enjoyed today. It made me proud to be a part of a company that has that kind of people working here”. I told him that this was one of the best compliments we had received and I would pass this along to all of the teams.

The hackIT Retrospective

The next week, I held my bi-weekly staff meeting. Typically this meeting is owned by the product development teams with me as the director just providing some housekeeping items to kick it off and wrap it up. It’s a space for them to reflect on what they are doing and learn from one another. They had the space to design it that way and it works well.

However, some of the development leaders said we should reflect on the hackIT event for continuous improvement and growth. I agreed with them (and was very proud that we think that way). Plus it allowed me to dust off some of the dust from my skills as an agile coach and facilitate.

We reflected on the event. It was a success overall to the group and they saw the value and hoped we make it a regularly reflection of our culture. I committed to them to ensure that I championed this event to my partners in leadership (who were impressed by the event as well). Here were the things we centered on for improvement:

Start Doing

  1. Preparing technical needs (server VM provisions/configurations) earlier. We had some unique needs that caused difficult for operational team members to be a part of the team for dealing with configuration needs.
  2. Being more widely inclusive. I took the blame for this as I have spent a significant amount of time and energy on cultural building and team building and because I knew we had really moved forward here, I was uncertain if the organization as a whole was ready to be able to participate in this type of event. In retrospect, it was probably fear and uncertainty that drove this as I wanted to show the value and so I tried to keep it like a small experiment. But as I found out, once the genie is out of the bottle and coupled with not managing the message to the outside, it can cause more problems than necessary due to lack of understanding.
  3. Re-thinking team size guidelines. We also had allowed teams to be of any size (including a single person). This resulted in at least one team forming into the event as they had not joined another team and needed help when everyone was focused. Having a team of one sounds good in theory but in practice it goes against our more communal cultural core values so we may have to change this approach.
  4. Changing the voting process. We had kept voting simple for this attempt by creating paper votes with team names and a box to mark ‘X’ by the selected team product. The problem that happened was that two teams decided to build a product that was pretty coupled in how it was thought of (resulting in a tie for the teams as people voted for both consistently). A suggestion was to use “chip voting” to allow people to vote for multiple products.
  5. Earlier clarity of ideas prior to kickoff. What we noticed as a lot of teams kept ideas “close to the vest” as opposed of getting them to an idea board (maybe to be strategic). Getting those ideas out there earlier would allow people to create more diverse teams and allow people to know if they wanted to try and create their own team or join another.
  6. Display our countdown clock in a central location. We had a countdown clock on the home page for the event of the server hosting the products. It was never looked at as folks were too busy. Was it even needed since we defined the timeframe? Food for thought.
  7. More planning. This actually arose from an admin we pulled in late to coordinate a lot of the activities (mostly based on an unknown budget). We actually started the work about 6 months before the event but the swag and food was all very last minute. Fair assessment. We can do better.

Stop Doing

  1. Eliminate the need for use of VPN. Based on the enterprise network configuration, utilization of wireless requires the use of a VPN client. This caused some issues in demos as they tend to timeout, etc. Not sure we can eliminate it but perhaps we can be better prepared to deal with those issues.
  2. The Drama! This stemmed around my approach to “keep it small” and lack of wider communication until the event was at hand. I’ll handle this much better next time.
  3. Less Snacks (I ate too much)! We provided breakfast for the organization day one, lunch for teams day 2 and then lunch on demo day for the organization. In the afternoon, I pushed a cart of snacks and treats around the floor across the entire organization to make connections, allow people to take a break and share a conversation and give them a nice treat. Apparently some folks felt the temptation by my cart of treats was more than they could stand. Overall it was a good thing but leads me to consider how to make it more balanced and healthy. I’ll think this through to create a more balanced mix over the week.
  4. Plan the schedule and work the plan. We were in the midst of wrapping up some hiring paperwork and so on the day of the event, my kickoff instructions may have not been as clear as I wanted so I had to do a follow-up. I had the scheduled outlined in the initial presentation I did with the teams. Next time, I will rely on visual aids if I have them.
  5. Stop spending so much money (this was directed towards me). For the most part, I funded this event from my own pocket (and I will not share the amount). I never actively solicited for reimbursement from anyone as I felt it was a personal passion and I wanted to do it (thank you to those that contributed though as every bit helped). I made sure everyone in the organization had a t-shirt for the event, bought snacks for the week, provided organization wide breakfast and lunch and team lunch and some other items. I told my teams that I saw this as an experiment and wanted to demonstrate how to support it and as it was a passion for me, I funded and did not regret spending a single penny and would do so again if necessary as I believed in it even more after it was done. But I did agree to be better to solicit for funding next time.
  6. Taking about every detail or trying to make things perfect. Some of the more junior members of the teams struggled with the idea of not going into deeper discussion or trying to perfect the products. This was impractical given the timeframe and created stress for them. Fortunately our more senior developers were there to guide them as to making decisions as to what could and could not be done within the timeframe. This is a skill that gets learned as we do this more. What can I actually build in this timeframe? Product ideas developed are potentials for future products but should be seen as R&D, not as production ready releases.


This experiment with hackIT turned out to be a great success and something I think I can see us further developing into our culture supporting core value beliefs we have in continuous learning and growth and the power in experimentation without the fear of failure. As for me, it was a personal joy to see what an amazing group I have to lead everyday have the way we believe and the talents they have be shared to the wider organization.

I leave with this …

“When it comes to innovation, an ounce of execution is worth more than a ton of theory”                -Phil McKinney, former CTO of HP Personal Systems Group