The lack of understanding of each interdependence and more importantly… how to remove or minimize these dependencies will inevitably create many negative issues. 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”. Value stories simply do not exist in their vocabulary, which causes a great deal of pain and noise. We are constantly challenged by the lack of ‘value stories’ within the teams. Although, this is not uncommon for teams new to ‘agile’. They tend to create, ‘epic’ or ‘implementation’ sized stories. They are unable to understand the purpose of properly sizing story cards. The Client X team members are constantly challenged with writing effective, appropriately sized story cards.
#PROJECT RETROSPECTIVE CODE#
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. Many of the Client X team members believe a shared code base creates unmanageable dependencies between teams. Our ultimate goal of small, concise, non-dependent cards may not always be feasible but should be the direction our team heads.Īll of the Client X, ‘agile’ teams share a single code repository and single continuous integration server. This sharing is creating artificial dependencies… slowing the delivery of each feature. The next challenge we currently face is the fact we are required to share a backlog and even worse… a card wall. Without autonomy, work distribution will become cumbersome and will result in the ultimate roadblock to team success. If the team is to be a ‘feature delivery’ team, 100% of the time… autonomy is a necessity. This will determine if the team is successful. I believe it is very important, ultimately critical, to determine the percentage. Although, it is rare for a team to focus completely on feature delivery or completely on coaching. 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. 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. The question of autonomy really comes down to determining which criteria will be used to determine success for the team. We have been asked to deliver a ‘velocity’ team, but we are currently being used as ‘staff aug’. 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. We have been presented with many challenges, but because of these challenges, we will have many opportunities as well. 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. I have grouped my thoughts in order to bring light to the current issues associated with this project. Over the last couple of weeks, I have been gathering my thoughts and ideas, concerning our client… Client X. ** the following notes were taken after three weeks on the Client X project (mid-September 2011) **
(Remember these were my notes… and not a well thought out document). These thoughts were captured in a document during the early stages of the project. So… here were my thoughts, 3 weeks into the project. Pillar delivered a ‘velocity’ team… Client X expected to use Pillar resources as ‘staff aug’… we worked through this !!!.a large portion of the technical stack was undefined and misunderstood.The initial steps were rough, many paths were started and many ended quickly (fail fast… right?) women’s national soccer team I couldn’t agree with this more… when considering the Client X project. It’s not where you start, but where you finish. Many of you have probably read or heard this before… 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.