I am part of the amazing Red Hat Developers Program and lead the Agile Transformation as the Principal Agile Coach. Our goal is to provide tools that make it easier for developers to succeed in their everyday endeavours, right from planning to production. Be sure to checkout developers.redhat.com to explore our products and our latest service OpenShift.io that allows all developers to plan, develop, test, build and deploy to production just from the web browser.
We are a group of around 250 developers, living in 16 plus countries and spread across 6 plus timezones. We are practising and learning Scaled Agile as we work and collaborate in this highly distributed fashion. We have successfully been able to achieve 'Continuous Delivery' wherein we have teams merging code to the production almost every day. As all of our projects are Opensource you can view our work on Github. For example github.com/openshiftio/openshift.io and github.com/eclipse/che
Authored Comments
Thank your for your interest, I’ll elaborate on how it helped and then get into the second part of the question. By adopting this philosophy, we have demonstrated inherent trust in the team’s ability to assimilate and undertake the Agile transformation onto their shoulders. This created a better environment to have open conversations, which was previously tough when based solely or velocity of the team. This is because the nature of the projects that we undertake is quite complex and working with an open source environment adds to it. As we depend in other projects and communities to progress in our efforts which we have little or no control over.
Coming to the second question, I personally believe that once a teams have embraced the Agile mindset they are become much more capable of producing high quality work products. So for us, we realised measuring just productivity is of little value, if output is not properly aligned with business goals or expectations of the stakeholders. We rather want to focus on building the team’s capability to be able to perform in a fast changing environment where priorities could rapidly change in a relatively short period to time.
For example one of the Agile principle that revolved around stakeholders satisfaction triggered an energetic and enthusiastic discussion to identify the stakeholders. Needless to say the team quickly went beyond the product manger, business units, organisation and thought about community and end users. As you can imagine, when each developer in the team becomes capable of stretching their thoughts to understand how their piece fits into the big picture the quality of software they produce is much higher and also tightly aligned with the overall vision.
The artefact that is generated at the end of these discussions, helps us to visualise what the teams have identified and how they progressed over few months or weeks, before we revisit the Agile principle. It is like a footprint on our journey towards becoming truly Agile. For measuring performance, we observe and inspect is the quality of the deliverables at the end of each iteration and the impact it creates in the market and community.
For example when we release a new version of the product, we see the reaction and emotion it generates, either through comments or questions on blog posts, reporting of issues or number of downloads. As these are self-evident and tie back directly to the business drivers, it gives us a much more wholistic picture of how are teams are doing.