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.