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)
Continuer la lecture de « An Agnostic Agile case in Infrastructure and Service Management »
By Karin Schijf
My goal as an Agile coach is to really help the client. To make sure we move along in an Agile way with the ever-faster and ever-changing circumstances. For example, to stay ahead of your competitors, to improve quality, and to adjust and modernise certain ways of working. With improved business results as the outcome of the process.
I have noticed that certain organisations have turned Agile into somewhat of a goal, rather than a tool. Organisations that boast about their high Agile maturity are not necessarily the frontrunners in their industry or field. Common sense remains important in order to obtain results. Is the way we work today still logical, considering everything we know now that we didn’t know yesterday?
Continuer la lecture de « Is Agile not simply the use of common sense? »
By Michael Küsters
This article was first published on Fail Fast Move On on November 17, 2016
Pretty much every large company states, “We need an agile scaling framework”.
I do agree that when 50+ developers need to collaborate, then a scaling framework provides massive benefits. There is one question left unanswered. One unspoken, unchallenged assumption looms like a specter over every scaling approach. Before asking this question, I will list out the reasons why it needs to be answered.
Are you asking the right question?
Creating Complex Products
A complex system has, by definition, a fairly high complexity. A common assumption is that Divide+Conquer (D+C) is a good way to approach complex problems: Split one big problem into many smaller problems, distribute these and bring the solution back together. Sounds promising.
A Scaling framework can then be used to maximize the effectiveness of the D+C approach.
Continuer la lecture de « The Biggest Question when Scaling Agile »
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.
Continuer la lecture de « 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. Continuer la lecture de « An agnostic agile journey of a team new to agile »