By Adrian Lander
The context was outsourcing, this time. While I was a “software product guy” by origin (in SW development since the age of 10, mid 70s – not the hobby computer stuff but real HP computers), my turnaround record led to me being suggested for challenging misery from time to time. Not always in a position to duck… In the end, it turned out to be an interesting application of lean agile in unusual territory.
CASE – A GLOBAL RESOURCES COMPANY
80+ critical business application servers. Moved from client data center to outsourcer’s data center as part of a very large global outsourcing deal. None of the servers had been accepted by the data center as they were not meeting data center standards. In production – full use by the client who ran their business critical processes with it. The outsourcing program was an IT transition and transformation, and the fact that none of the servers had been accepted was blocking new projects, within a large program. So, blocking business improvement and money coming in for both parties. Of course there was more going on than getting 80+ services already in productive use for years, accepted by a center.
Sounds simple to fix. Reality was totally different due to constraints. SLAs the client was paying for – but not end to end executed, as should be obvious. Due to the global 24×7 use of the systems, maintenance windows were short and rare and hard to obtain. Then for the specific data center, that also housed defense systems, security clearance was needed and any visitor needed to be announced in advance. All servers needed 5 types of upgrade, requiring 5 different specialist engineers.
The previous project manager had not made progress, as when one of the engineers turned out not to be available, more than one window was needed. (He was getting replaced or relieved from the misery)
Continue reading “An Agnostic Agile case in Infrastructure and Service Management”
Agnostic Agile from the Trenches – 3. Managers and Team Retrospectives
By Shaaron A Alvares & Adrian Lander
Preamble: We believe that everybody can be a leader. Leadership is not a title, nor the prerogative of executives or management only, instead everybody across an organization is a leader, individual team members included. For the purpose of this article, that focuses on roles interaction in agile, we named various roles, team member, manager, leader, but we understand that they all can be leaders.
As I introduced agile or improved agile delivery in various groups in Seattle, I had the opportunity to work with some of the best agile leaders and champions: David Smith and Ashish Suryavanshi at Microsoft, Fernando Cuadra at Expedia, Sally Bauer at BECU, and Thomas McGee at T-Mobile to name a few. They understood agile and its benefits well and lived by the agile values and mindset, which is particularly difficult to do when, as line managers of a large group, they are responsible for their teams’ success and setbacks. They took any opportunity they had to foster the agile mindset, sometimes at the detriment of their relationship capital or at the cost of their career aspiration and stability. These agile leaders shared common traits and common beliefs. As an example, they were very adamant about not inviting managers to attend team retrospectives and if managers crashed retrospectives uninvited, they instructed their scrum masters with the following: “Text my cell phone 911 and the room number where you are and I will come right away”, “Ask them to leave, you have my support”, “let me know if that happens and I will address it”. In some organizations, T-Mobile was one of them, we created a log, confidential to the agile coaching crew only, where we captured manager incidents in order to address these with the appropriate level of support and coaching.
Continue reading “Agnostic Agile from the Trenches”
A bigger, but packed with learning read on a real case of an agnostic agile journey, from scratch.
The team was new to agile, and to each other and the organisation. They were asked to develop a new mobile solution that would be used on board of airlines. So, regulatory / safety aspects. There was an external hard deadline, and the organisation had lost a year creating a hefty traditional business requirements document through another, traditional (expensive) team without delivering any product, not even for evaluation, and now there were only a few months left. In a business workshop it turned out that a lot of the requirements had become outdated or even obsolete. The need for the product and the external deadline had not changed, though. Neither the business division that was client nor IT management were very warm towards agile – they were convinced that “agile does not work here”. They were also not very open to change their old (micro) management habits……They knew however that traditionally they had never delivered in such a short time, nor three times that. And maybe if it did not work, they could get rid of agile. A win-win? An interesting, challenging journey was ahead. Continue reading “An agnostic agile journey of a team new to agile”