Speaking Culture

NOTICE: this may ruffle some feathers!

This is an attempt to put thoughts into words. To document how I think, we as a company, should be looking at the practice of public speaking. Whether a presentation at a large conference or lightning talks over lunch with your teammates.

Before I begin, a little background on how I arrived at this opinion. At the end of 2013, I started reflecting on my contributions to the technical community. I realized that I had a great passion for speaking and communicating my ideas to my peers. I also realized I hadn’t made much of an effort to contribute back to the community. So… an effort was made to up the ante. I concentrated on presenting as often as possible during 2014. At the end of 2014, I had presented at 13 conferences. 2015 is starting off well, with two conferences booked. Hope to see many of you during the 2015 year… I will be presenting at Agile and Beyond 2015 and self.conference 2015.


Enough with the background information… why am I writing this article?

So… I started thinking about how I currently approach public speaking. Questioning my approach and involvement within the technical community.

  • the technical community I rely on to remain pertinent.
  • the technical community I should be advancing.
  • the technical community relying on my participation in order to remain successful.

I took this a couple steps farther and started thinking about how the company I spend most of my time with and the peers I work with on a daily basis, are actually treating the practice of public speaking.

and my evaluation … it didn’t go well.

**NOTICE: ALERT

I am disappointed in my co-workers, my peers, and myself. We are not putting enough emphasis on the practice (art) of public speaking. We should be encouraging each other to present as often as possible, but we are not! Whether we speak at conferences or meetups or intra-company lightning talks held over lunch. We need to just get in front of people and speak.

A great place to start is the intra-company lightning talk. Where you can practice your chops in a comfortable and safe place, before moving on to a bigger venue.


I would like to encourage each of you to look at public speaking for the following reasons…

  • it is a great way to convey your ideas to a large group of people.
  • it is a great way to have a public version of your resume (speaker deck does a nice job of showing off your work).
  • it is a great recruiting tool… like-minded people interested in the same types of topics and ideas would probably make great co-workers.
  • heck… marketing is interested as well… our company is already taking great advantage of this.

The effort of public speaking needs to be a two-sided effort. Each employee should put thoughts to paper (slides) and the company should expect its employees to present on topics they are interested in.

Pillar has been supportive of public presentation. In my personal experience, each time I am given the opportunity to present (as a Pillar employee)… I have yet to be denied… – always given time-off from the client – payment of expenses have been covered (many conferences cover a large part of a presenters expenses… hotel, gas, flight, etc.) – promotion of the presentation… twitter, website, sponsorship at the conference

In our case… the employee is the part of the equation most lacking… and we will start there.

Consider you need to teach ‘something to someone’. Consider you really do not know what you are talking about until you start teaching someone. The process of working through how you will teach a person will force you to break down each step into it’s smallest and cleanest possible elements. Take a minute and think about how you would teach someone the practice of test-driven development. How many steps are required to teach this topic? Step back and teach that same person how to tie their shoe. Imagine they know nothing and they are not convinced they want to learn how to tie their shoes. Learning to tie your shoes will be dozens of small steps… TDD’ing will be tens of dozens. Simple is the key here.

Do not just get up in front of your peers and read the slides or lecture. Tell a freakin’ story. People want to be entertained. They want to know you are interested in standing up in front of them and teaching them something. It doesn’t need to be funny, it helps, but entertaining and interesting are a must. How many presentations have you seen where the presentation was boring and way to scripted. This doesn’t mean the presentation shouldn’t be practiced and polished, but it shouldn’t be a regurgitated repeat of the slide notes. It should be a conversation… the attendees want to be in the presence of someone that is passionate about the topic of which they are speaking.


So… how does this public speaking ‘thing’ actually make you a better person… a better employee? I believe that each time I am asked to stand up in front of my peers and asked to convey some idea to the masses… it changes me. It forces me to look at things differently. I am expected to think outside of my normal thoughts and consider the thoughts of everyone that will be attending the presentation.

Public speaking is public resume… a live public resume of what you are passionate about. But, more than a public resume, presenting on a regular basis is a great way to provide leadership to the technical community. I would caution from presenting yourself as a community leader just because you want to be known in the community. You should be presenting because it is the right thing to do. Do not present because your company wants you to present… because you want to share your thoughts and lessons with your peers.

It keeps your employees feeling fresh, and when they get back they’ll be ready to tackle the hard problems.NOTICE: this may ruffle some feathers!

This is an attempt to put thoughts to words. To document how I think, we as a company, should be looking at the practice of public speaking. Whether a presentation at a large conference or lightning talks over lunch with your teammates.

Before I begin, a little background on how I arrived at this opinion. At the end of 2013, I started reflecting on my contributions to the technical community. I realized that I had a great passion for speaking and communicating my ideas to my peers. I also realized I hadn’t made much of an effort to contribute back to the community. So… an effort was made to up the ante. I concentrated on presenting as often as possible during 2014. At the end of 2014, I had presented at 13 conferences. 2015 is starting off well, with two conferences booked. Hope to see many of you during the 2015 year… I will be presenting at Agile and Beyond 2015 and self.conference 2015.

Enough with the background information… why am I writing this article?

So… I started thinking about how I currently approach public speaking. Questioning my approach and involvement within the technical community.

  • the technical community I rely on to remain pertinent.
  • the technical community I should be advancing.
  • the technical community relying on my participation in order to remain successful.

I took this a couple steps farther and started thinking about how the company I spend most of my time with and the peers I work with on a daily basis, are actually treating the practice of public speaking.

and my evaluation … it didn’t go well.

**NOTICE: ALERT

I am disappointed in my co-workers, my peers, and myself. We are not putting enough emphasis on the practice (art) of public speaking. We should be encouraging each other to present as often as possible, but we are not! Whether we speak at conferences or meet-ups or intra-company lightning talks held over lunch. We need to just get in front of people and speak.

A great place to start is the intra-company lightning talk. Where you can practice your chops in a comfortable and safe place, before moving on to a bigger venue.


I would like to encourage each of you to look at public speaking for the following reasons…

  • it is great way to convey your ideas to a large group of people.
  • it is a great way to have a public version of your resume (speakerdeck does a nice job of showing off your work).
  • it is a great recruiting tool… like-minded people interested in the same types of topics and ideas would probably make great co-workers.
  • heck… marketing is interested as well… our company is already taking great advantage of this.

The effort of public speaking needs to be a two-sided effort. Each employee should put thoughts to paper (slides) and the company should expect it’s employees to present on topics they are interested in.

Pillar has been supportive of public presentation. In my personal experience, each time I am given the opportunity to present (as a Pillar employee)… I have yet to be denied… – always given time-off from the client – payment of expenses have been covered (many conferences cover a large part of a presenters expenses… hotel, gas, flight, etc.) – promotion of the presentation… twitter, website, sponsorship at the conference

In our case… the employee is the part of the equation most lacking… and we will start there.

Consider you need to teach ‘something to someone’. Consider you really do not know what you are talking about until you startteaching someone. The process of working through how you will teach a person will force you to break down each step to it’s smallest and cleanest possible elements. Take a minute and think about how you would teach someone the practice of test driven development. How many steps are required to teach this topic? Step back and teach that same person how to tie their shoe. Imagine they know nothing and they are not convinced they want to learn how to tie their shoes. Learning to tie your shoes will be dozens of small steps… TDD’ing will be tens of dozens. Simple is the key here.

Do not just get up in front of your peers and read the slides or lecture. Tell a freakin’ story. People want to be entertained. They want to know you are interested in standing up in front of them and teaching them something. It doesn’t need to be funny, it helps, but entertaining and interesting are a must. How many presentations have you seen where the presentation was boring and way to scripted. This doesn’t mean the presentation shouldn’t be practiced and polished, but it shouldn’t be a regurgitated repeat of the slide notes. It should be a conversation… the attendees want to be in the presence of someone that is passionate about the topic of which they are speaking.


So… how does this public speaking ‘thing’ actually make you a better person… a better employee ? I believe that each time I am asked to stand up in front of my peers and asked to convey some idea to the masses… it changes me. It forces me to look at things differently. I am expected to think outside of my normal thoughts and consider the thoughts of everyone that will be attending the presentation.

Public speaking is public resume… a live public resume of what you are passionate about. But, more than a public resume, presenting on a regular basis is a great way to provide leadership to the technical community. I would caution from presenting yourself as a community leader just because you want to be known in the community. You should be presenting because it is the right thing to do. Do not present because your company wants you to present… because you want to share your thoughts and lessons with your peers.

It keeps your employees feeling fresh, and when they get back they’ll be ready to tackle the hard problems.

The Chartus Praxis

This post will serve as an introduction. Not of a person, but of a technique. A technique to gain an appreciation of practices. This technique could be applied to an individual but is intended for a team.

Practices are often misunderstood and more often… just ignored! I believe these practices are the key to high performing teams, capable of delivering incredible amounts of business value.

I want to introduce my approach… an approach to help a team gain their own appreciation… not an approach of someone telling them what to do, but an approach of allowing them to talk/think through which practices make the most sense to the team. Individual practices will vary between teams.

definition of practice : repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it.

Purpose

Chartus Praxis provides a visual and interactive method, allowing teams to gather awareness to the practices, that will allow teams to become highly effective and allow for the delivery of high quality working software.

Supplies

To help a team with the Chartus Praxis, you need the following:

  • Three sheets of flip chart paper (or the ‘universe’ printed on plotter approximately the size of three sheets of flip chart paper)
  • Markers (thick, suitable for writing on paper) Black, Blue, Green
  • Wall space or White Board large enough to fit the ‘universe’
  • Printed Praxis cards
    • Printed by hand on 3×5 cards or 3×3 Post-it Notes
    • Avery cards 5388
  • Blue Painters tape or a Post-it glue stick

The Universe

Preparation

Prepare your diagram by lining up your three sheets of flipchart paper and draw two intersecting circles. This needs to be large enough to fit all of the cards with the practices that fit in the Team, Engineering, and Both (intersection) sections.

Add the cards to each section. Place them in any order/placement within the section they fall into. Spread them so the team can see how full the universe is of practices they can use to improve their team and engineering processes.

  • Round 1 – Review the Practices Review and clarify each practice so the team has an understanding of what the card represents.
  • Round 2 – What does the Team Think? Remove all of the cards from the universe and trisect the circles horizontally. The top line in Blue, the bottom line in Green. Add the Legend and arrows as shown. Explain the three sections to the team. This is where the team interaction comes to the fore. Using a round-robin approach, have each team member take a card and place it in its corresponding section and in the place where they think the team is on the Legend: Not on Radar, Trying, not yet Embrace, and Embedded in Team DNA. Have them state why they think the team is where they’re putting it. Continue through until all the cards are placed.
  • Round 3 – What Are Our Priorities? In one final round, ask each team member where they think the focus for continuous improvement should be. Mark the card with dots (or stars, or whatever). Then of those few cards, have the team select #1 (they could have a card selected as #1 in each section depending on their state) to focus on.

Conclusion

Remind the team this is a snapshot of the team’s state. Set a timeframe to revisit the Chartus Praxis and have it evolve over time as the team matures.

Eulogy

 

This is the eulogy I presented to the congregation on the day of my father’s funeral. I do not have a good reason for allowing the world to see this, but I also do not have a bad reason either. So here goes…

As I am sure most of you know me… I am DJ… Dudley’s oldest son. Please forgive me as I read this, I do not want to forget any of these words.

First off… thank you very much for coming today… thank you to my mother and brother for having the faith in me to delivery Dad’s eulogy. And the support of my wife to listen to my insecurities as I put words to paper.

I didn’t learn of this story until recently (and many of you who know David and I will relate), but when Dad was asked to compare David and I… He would respond… If David and DJ were both asked to jump off of a mountain… David would sit and think, draw up the plans, rethink the plan, build his wings and then cautiously slide off the mountain… Dad would then say (probably with a shake of his head) DJ would immediately run and jump off the mountain and figure out how to build his wings on the way down. I am sure this caused my father many sleepless nights in 42 years. The ironic part of this story… I have had a signature on the bottom of my personal email for many years, a quote from Ray Bradbury… saying,

“If we listened to our intellect, we’d never have a love affair. We’d never have a friendship. We’d never go into business, because we’d be cynical. Well, that’s nonsense. Go to the edge of the cliff and jump off. Build your wings on the way down.”

So… following this theory… of jumping before thinking…

I volunteered to deliver Dad’s eulogy today — I am not sure exactly what I was thinking, but here I am.

Just over one month ago… I talked to my parents on Christmas Eve… and I learned my father was diagnosed with a mass on his kidney. I immediately had this feeling… my father wasn’t going to be with us much longer. I am not sure why, it was just a feeling. For the next month, from time to time… (quite often actually)… I would think of things about my father… and they all seemed like things that should be mentioned during a eulogy… so this is why I volunteered.

Six days ago… on January 31 at 5:30 PM, my father passed.

After his passing… I sat in my office attempting to write this eulogy. Starting multiple times and stopping just as many. I would start again, trying to find the words to describe how it feels to be here without him. I am still trying to figure this out. I had a father for 42 years and have only not had a father for six days, so anything I say today must be understood as the words of someone only six days old.

He left behind… a wife… two sons… two daughter-in-laws (that he loved to tease)… and five grandchildren (that he loved to tease even more)

  • I did not expect that my father would not live to see any of his 5 grandchildren graduate from high school.
  • I did not expect that my father would not live to see them get married.
  • And I certainly did not expect that he would not live to see the age of 70.

Up until this past Thursday when he passed, I did not expect anything less than many more good years to share with him.

But the thing I expected least of all was the deep peace of mind and spirit that I have knowing he is now safe and free from pain and suffering.

My father’s love for my mother was a full, romantic and sentimental love, rich with devotion that is rare and a love I feel honored to have witnessed in my lifetime.

In those 46 years of marriage, they shared their love for one another, their love for their children and grandchildren, and their love of their friends.

With David and I, he was loving, gentle and always filled with pride and joy with each accomplishment and milestone and made sure he was involved in our activities and interests. As kids, we could always count on seeing his face at every event.

During our failures and struggles, of which there were many, he was SLOW with words of advice, but FAST with encouragement and support. Dad was all about you figuring ‘things’ out. I remember talking to my father many times… asking for advice… (I never received the advice… at least not from his lips)… he would let me talk… and talk… and at the end, he would say, “Well… I think you know what you need to do… now go and do it!”. It was hard to swallow his tactic, but it always seemed to work.

Dad always encouraged and taught us to pick our battles. When someone was trying to pull ‘one over on him’… he would say, “if you can live with it… I can live without it”

He had a couple other less frequently used sayings…

— it’s going to get better… it might get worse… or it might just stay the same

— and when he was really mad… and things weren’t going so well… he would really let it fly… and say, ‘Ahh Man!’

but his favorite of all time… (please repeat it with me) — “it’s too far from your heart to kill you”

So… as I put words to paper for today… I started to take a moment and capture a few stories about Dad… and then as I tried to capture them… the phone would ring. I would answer… of course is was someone wanting to talk to me about dad… the tears would roll for both of us… and then the tears would turn to laughter and the stories I was trying to capture would start to be told (everyone had a least one). I quickly realized there were too many stories for the short time I have. So I decided to try and sum up all of the stories into just one idea.

If there was one word to describe my Father during his lifetime, it would be the word: Friend. I can see many people he considered friends in front of me right now. He never met a stranger… he never treated anyone as if he hadn’t known them forever and he would have given the shirt off his back to anyone in need (and never expect it back). Everyone he met was a friend.

In working through Dad’s eulogy for today, and speaking with lots of you, it is easy to see that Dad was well-liked and well-regarded in his life.

  • I am proud of my Dad.
  • I am proud of the way he loved my mother.
  • I am proud of the house that he built.
  • I am proud of the way he loved and cared for David and I… and our wives.
  • I am proud of the way he loved his grandchildren.
  • I am proud of the number of people I see in front of me… that called him friend and brother.
  • I am proud of the man that he was… it will be a hard standard to achieve.
  • I am proud of the way, by daily example, he taught me the lesson of unconditional love and the importance of family.

This is his legacy. He is, and will be, greatly missed by all.

I have one last example of ‘what’ my father was… He was a very proud and honorable man… and for him to make this comment was a great honor to me.

A couple years ago… I called my father on father’s day… I of course wished him a ‘Happy Father’s Day’… His only response without hesitation… in his normal calm tone… was ‘It is my honor’… I am not sure what I had done to deserve the honor… but it was an honor to be told such a thing.

He felt it was an honor to be our Dad, an honor to be a husband, and an honor to be a friend. Please know he loved all of you greatly.

Thank you very much for coming today. I will leave you with one final thought… directly from dad…

Dad told Mom for years… when I go… I will never be too far. He would say, “Go outside, look into the sky at the clouds… I will be the one making loops around them.”

Rest in peace, Dad — I love you.

Spikes

HELL YEAH… we SPIKE

the spike… why is the spike such a complex concept for a team to understand.. grasp.. embrace? Why would anyone want to work on something for a short amount of time, gather some information, answer a question and then throw your work away… just to do it again for real. spikes allow you to make better decisions and possibly determine if something is feasible at all… all without wasting a huge amount of time and/or money.

so… when do you actually perform a spike? when is it the right time to not deliver real value to the business? well, when you think of it that way… the answer should be never. although, ‘never’ is not really a viable option… when the known is not known… the spike is the way for the team… to do a little digging into the unknown and then, create a viable solution with more information in your pocket. spikes are not just confined to technical decisions… spikes should be used any time the team is unsure of what is the next step… hopefully allowing the team to answer the question with definitive assurance. Please spike… it will make the business very uncomfortable at first, but with honesty and practice, the business will see the real value of why spikes should exist.

as you might expect… spikes are a lot of things, but they are NOT:

  • NOT a way to slip untested code into the production stream
  • NOT a way to allow the team to make uneducated guesses at estimating stories and then cleaning up the guess with a spike
  • NOT a way for improperly defined (missing definition of ready criteria) user stories to enter the groomed backlog

ok… here is where I lose most people.

spikes should be treated the same as all user stories on the card wall. spikes should be evaluated for the possible business value each will help define. They should also be estimated… estimated because each spike will reduce the capacity of the team. Many teams do not count spikes towards their velocity… I personally do not agree with this. This appears to me to be a lie to the business. (We can also compare this with defects, but that is another topic). The process of determining velocity is not an effort to collect points or apples or whatever, but a process of allowing the business to have a means to determine how much of something they can get within a certain amount of time. The concept of ‘getting credit’ should be considered something the team should not engage. velocity is not about gamification of the agile process. Report the actual velocity based on the actual work of the team… who cares whether you call them… user stories, defects, technical debt or spikes. work is work… and thus reduces the amount of capacity a team has promised the business.

In order to make spikes a little easier to digest… spikes should not be allowed to consume huge portions of the sprint. time-box them using a small estimate. you know your system… pick a reasonable estimate… it is probably not your smallest card on the wall, but definitely not the biggest either. If a spike is estimated and the team working the spike feels they have reached the end of the estimation period… then the spike is done! period… end of story. If the spike is still unable to answer the question, it is possible another spike will need to follow. this is a business decision… it is up to the business to determine if yet another spike should be played. it is not a bad thing to play more than a single spike to answer a question, but each cycle should be carefully evaluated and the business should inevitably by the deciding factor. If the spike is of a technical nature, it is the responsibility of the technical staff to sell the business value to the business, but the business will make the final decision.

spikes will not always result in additional user stories being created. many times, a spike will be initiated by the process of estimating an existing user story. the user story doesn’t have enough detail or the technical questions will not allow the user story to be estimated with certainty… a spike will be required to answer these questions. At the end of the spike, additional cards may or may not be required… simply filling in the knowledge gaps will allow the existing user story to be estimated. On the other hand, a spike may actually result in additional user stories being created.

so… just how does a spike fail… well… I actually think it is very difficult for a spike to fail. spikes are designed to answer a question, fill in the gaps, allow for more informed decision to occur. any information you gather during the spiking process will result in a better position to answer these questions… so, therefore, you are more informed and better off. the only way to truly fail would be a spike that answers nothing, gathers no information and wastes a portion of the teams capacity.

the results

what do you do with the information you have gathered during the spiking process? As far as the code you have written… learn from it and then throw it away. This is just spike code, without tests, this code should never be considered good enough to be production code. Do NOT allow yourself or anyone else to be swayed to use the code. it will come back to bite you… just do not do it. DELETE the code ! this also does not include putting the code in a special branch within your code repository for later retrieval… DELETE the code !!! As far as the result of the spike, document your findings, positive or negative… this will help with the decisions based on the result of the spike. A lot of times, at the end of the spike, the team will make a decision and then forget to share the findings with the team… the team playing the spike may not be the same team that plays the subsequent cards associated with the spike.

spikes are not magical. they are special in their purpose, but they do not bring magical results to the project other than they are a great way to reduce a risk and allow future cards to proceed across the wall more consistently. spikes are a great way to engage the business and allow for quicker more thorough feedback and a better understanding of upcoming complexity. complexity that will surely derail the sprint/iteration if left uncontrolled.

when to use

when should you utilize a spike… at least a couple ideas to get things started:

  • the team is in a position where they do not understand something… could be the business context of the problem or a new technology unfamiliar to the team.
  • a story is just too big to get a grasp on… and without breaking the problem down… you will not be able to effectively estimate.
  • a new technology has been introduced and the risk of the new technology is adding significant risk to the successful estimation and probable delivery of the story.

good luck with the process of spiking.

Coding in the Clink VI

What were you doing on Saturday, March 2012?

You should of been in Marion, Ohio… participating in Coding in the Clink VI. Dan Wiebe (twitter – @dnwiebe) has been asking me for months to participate and I have always had something else that was more important. Big mistake on my part. The short version, just in case you do not want to keep reading… it was AWESOME !!! and I will do it again. Every person should attempt to attend. As good as any code-retreat I have ever attended.

so… I am going to recap my entire day as an attempt to hopefully bring light what kind of experience, Coding in the Clink VI, really was… at least for me.

I live about 1 hour and 20-25 minutes south of Marion. I started the day, actually the night before, thinking about what the next day would bring. Of course, your mind is quite capable of making things worse than they really are… especially when you are thinking about going to prison. At 7AM, I left the house, headed for Marion Correctional Institute for a day of coding… or at least that is what I was hoping for. I arrived a few minutes early, met by Dan (Wiebe). I must of had a look of nervousness on my face. Dan quickly asked me how I was doing. I, of course, answered… ‘fine’… actually I was quite nervous and not really sure how I should be feeling.

Everyone else arrived, we removed everything from our pockets and were greeted by the metal detector. I PASSED. This is when the nerves peaked. It is not normal to want to enter a prison for the day. People are not supposed to actually want to go ‘behind bars’ for an enjoyable Saturday. We, as a group, were escorted down the main hall of the prison… greeted by two, not one, but two very large steel doors. We had to pass through the first, lock the first, and then the second was unlocked and we passed into the prison. The ‘long walk’ led us to the ‘computer lab’. We were welcomed into the lab by several prisoners, all very excited by our arrival. It was a very nice experience. Still nervous at this point, but much more at ease, Dan greeted everyone and tried to start the introductions. He was stopped by Lee, with an announcement of donuts, coffee and lemonade. After a few minutes of breakfast item gathering, the introductions and code-retreat formalities were started. We had to learn each persons name… and that was it. We were all just developers, nothing more… nothing less. Dan introduced us to the challenge of the day, the game of Mancala. Seemed pretty simple at first pass… we learned otherwise throughout the rest of the day.

As a team, we decided on 45 minute iterations and 15 minute retrospectives. The first iteration was slow and rough, but we made it through. The iterations started adding up… and the code started flying. The rules were… each prisoner had to pair with an ‘outsider’… ‘outsiders’ were not allowed to pair with each other. Each iteration required a person to pick a new pair and not to pair at the same station as the previous iteration. Also… the code was not deleted between iterations, as normal, which really changed the dynamic of the retreat. If I remember correctly… lunch was served after 3 iterations… this brought some really nice conversations. The most enlightening event for me, was when I realized I had forgotten that I was in prison and thought I was just in any other agile team room at any other client.

The final iterations occurred, the final retrospective happened… the day ended with me completely enjoying the code, the new friends I made and imagine… in prison ! A venue I would have never have imagined I could have said, ”I had a good time”.

Thanks to Dan for organizing and inviting me to ‘number six’… hope to be invited back! Thanks to the ‘guys’ for a wonderful, enlightening, and productive code retreat… hope to see you soon!

Thanks!

DJ

End Of Project Retrospective

My first attempt was to try and document all of the events since joining the project… and as interesting as it might be, I have decided to take a slightly different approach to capturing my retrospective thoughts.

Many of you have probably read or heard this before…

It’s not where you start, but where you finish. April Heinrichs – Coach of the U.S. women’s national soccer team I couldn’t agree with this more… when considering the Client X project.

The initial steps were rough, many paths were started and many ended quickly (fail fast… right?)

Internal Client X’s direction was

  • ‘foggy’ at best
  • a large portion of the technical stack was undefined and misunderstood
  • Pillar delivered a ‘velocity’ team… Client X expected to use Pillar resources as ‘staff aug’… we worked through this !!!

So… here were my thoughts, 3 weeks into the project. These thoughts were captured in a document during the early stages of the project. (Remember these were my notes… and not a well thought out document).


** the following notes were taken after three weeks on the Client X project (mid-September 2011) **

Over the last couple of weeks, I have been gathering my thoughts and ideas, concerning our client… Client X. I have grouped my thoughts in order to bring light to the current issues associated with this project.

I have spent considerable time, pondering the idea of injecting a self-sufficient Pillar team into a ‘transforming’ environment, with the sole purpose of delivering valuable features. We have been presented with many challenges, but because of these challenges, we will have many opportunities as well.

The first and probably the most challenging issue I feel the team is currently experiencing is a question we will need to address with Client X.

“Should our team be autonomous?”.

We have been asked to deliver a ‘velocity’ team, but we are currently being used as ‘staff aug’. The question of autonomy really comes down to determining which criteria will be used to determine success for the team. If the team is to focus 100% on ‘feature delivery’, then the number of valuable features delivered to Client X will be our mark of success. If the team is to focus 100% on ‘coaching’, then we should be judged on our ability to transform, the associated Client X team, into a performing, agile team. Although, it is rare for a team to focus completely on feature delivery or completely on coaching. I believe it is very important, ultimately critical, to determine the percentage. This will determine if the team is successful. If the team is to be a ‘feature delivery’ team, 100% of the time… autonomy is a necessity. Without autonomy, work distribution will become cumbersome and will result in the ultimate roadblock to team success.

The next challenge we currently face is the fact we are required to share a backlog and even worse… a card wall. This sharing is creating artificial dependencies… slowing the delivery of each feature. Our ultimate goal of small, concise, non-dependent cards may not always be feasible but should be the direction our team heads.

All of the Client X, ‘agile’ teams share a single code repository and single continuous integration server. Many of the Client X team members believe a shared code base creates unmanageable dependencies between teams. I have worked on many, very large enterprise and open-source projects, with hundreds of developers sharing a single code base… and they were, and still remain, very successful.

The Client X team members are constantly challenged with writing effective, appropriately sized story cards. They are unable to understand the purpose of properly sizing story cards. They tend to create, ‘epic’ or ‘implementation’ sized stories. Although, this is not uncommon for teams new to ‘agile’. We are constantly challenged by the lack of ‘value stories’ within the teams. Value stories simply do not exist in their vocabulary, which causes a great deal of pain and noise. Without the existence of ‘value’ stories, it is near impossible to determine if “little work yields great value” and conversely… if “big work yields little value”. The lack of understanding of each interdependence and more importantly… how to remove or minimize these dependencies will inevitably create many negative issues. If we can be successful in introducing smaller stories, we might be able to eliminate/remove many of these stumbling blocks. Another challenge we are faced with is facilitating the understanding to determine when cards are too big and when to split. (e.g. – splitting cards into value-driven, demonstrable stories small enough to avoid ‘card collision’… user interface, functionality, and linkage between the two).

We are challenged daily with an environment, where the Client X team members do not value pairing. They are not interested in pairing, do not see the value in pairing, and generally refuse to pair. We, Pillar ‘team one’ continue to pair on a daily basis, but we are still required to submit all of our ‘checked in’ code to a code review process, which generally takes 1 to 2 days minimum to get the code… ‘approved’. They try to do TDD, but, in general, do not understand why ‘it’ is required and the benefit of TDD’ing. The same for ATDD. We consistently see a non-collaborative environment… more appropriately defined as non-cooperative. There have been several occurrences of ‘code guarding’ and, as a result… lots and lots of scope creep. The proper use of source code control is very new to JD and the lack of understanding is causing large amounts of confusion.

Here are some general team stumbling blocks we continue to deal with…

learning the process knowledge / business context (bigger than JD expected) undefined / unstable tech environment lack of forethought before making the ‘leap’ from windows to Linux… windows based simulators will only run on windows… limiting factor from moving over to native Linux exclusively too many moving targets (very difficult to focus on a single point of attack) business still in the process of defining the what technology stack changing before solidifying new people (new to Pillar and new to tech stack) mixed roles (both JD and Pillar) unknown roles (both JD and Pillar) —————

so… five months later… here are my thoughts…

Pillar continues to hire incredibly smart/creative people… collectively capable of achieving feats not possible alone. Client X was not ready for a ‘Pillar style’ team ! And what I mean by this is… solid work ethic, solid technical competency, creativity to solve problems, ability for a group of people, with little time together, to work as a team, realization that ‘a team is a team’… and it is more than the sum of it’s parts the never stop trying attitude every Pillar team, I have ever been involved with… has ! We, Pillar, didn’t have a concept of how dysfunctional Client X was until we arrived. The noise created by this dysfunction provided lots of opportunities for Pillar… especially after delivering value to the customer. Client X was not prepared to ‘incubate’ new teams… either internal or external. My proudest moment on the Client X project… when we were finally released from the ‘incubation’ process… the very next sprint, we met and exceeded our commitment. Client X has grown in many areas… their people are ‘more agile’, their agile processes have come a long way… much work still remains, their ability to more quickly adapt / change has improved, their ability to accept change as the norm and focus on the value a feature can provide to the company, not how ‘cool’ something seems… has improved. Client X has areas where they are still growing… many of the teams think their way… is still the best way. they are constantly challenged with ‘always deliverable’… they would be completely lost with the concept of ‘continuous delivery’ their continuous integration environment is very ‘light’ and unstable their understanding of source code control is still minimal at best effective card writing is still a challenge code guarding is still present… the concept of ‘collective code’ is very scary for them development environment is still minimally understood… Linux is still very new team buy-in is still at a minimum… they are still not convinced ‘agile’ is the way to go More importantly, (at least to me)… Pillar has been able to grow…

we have added many new ‘Pillarites’… all very capable and fun to work with we understand how to deal with challenging, ‘opportunity rich’ environments and succeed. and yes… we learned things from Client X as well !!! so… one final comment…

We changed and will continue to change, the way Client X “works”… !!!

The members of the Client X teams should find great success in the changes already in place and the changes they will continue to employ on a daily basis. All of us, as Pillar employees, can be proud to be part of a team capable of delivering value to very challenging customers and succeed.