Skip to main content

Posts

The Death Knoll for the Agile Trainer

The winds of change blow fiercely, propelled by AI-driven virtual trainers, and I can't imagine for a minute that certification organisations have not already recognised the potential for a revolution in training. They may even already be preparing to embrace technology to reshape the Agile learning experience. Traditional face-to-face training and training organisations are on the verge of becoming obsolete as virtual tutors take the lead in guiding aspiring Agile practitioners through immersive digital experiences. The future of training and coaching lies in AI-driven virtual trainers and coaches. Trainers, powered by artificial intelligence engines such as ChatGPT, are set to revolutionise the learning experience. With AI-powered virtual trainers, learners can engage in immersive virtual environments, actively participate in simulations, collaborate with virtual team members, and tackle real-world scenarios. These trainers automatically analyse progress, provide instant feedback

The Business Value of Telemetry

Dynamic technologies and infrastructure allow server failures and network issues to be quickly addressed, easily mitigated and, in many cases, reliably predicted. As a result, there’s a new venue opening for IT: end-user telemetry, which enables IT to determine how its internal users are consuming business resources, what type of application issues they are experiencing and how it impacts business performance. Gartner suggests that infrastructure and operations (I&O) leaders must change their approach and prioritize top-down business-oriented metrics. The research firm predicts that “60% of IT monitoring investments will include a focus on business-relevant metrics” by 2021, up from just 20% this year. Changing The Game Of course, it’s one thing to recognize the value of business-driven metrics and another to implement effective monitoring processes company-wide to overcome key barriers to effective digital transformation. The first step is understanding the fundamental shift requi

eyes wide shut

As a youngster one of my favourite authors was the American humorist, James Thurber. Of all the pieces of his I read, the one that I remember most concerned his English teacher′s obsession with the use of "the container for the thing contained" as a figure of speech. For example, we might say, "Today London elected a new mayor." Of course, London would do no such thing, it is an inanimate city of roads, parks and buildings and roads parks and buildings have not yet been given the vote. It is the people of London that elect mayors but the use of the container for the thing contained is a common trait with humans and everyone understands it. Another similar manifestation of this type of behavioural trait concerns certification. We imagine that the owner of a certificate possesses not just the knowledge originally required to gain the certificate but also the talent and skill to use that knowledge effectively. The fact that a standard exists also implies that the stand

lazy agile developers

..said my colleague. "How so?" I enquired. "Well!" he said, "when we do planning, I notice that one or two of the guys are always happy to suggest we only ever attempt to match our previous velocity, they never try to improve. If anyone suggests we aim for more points than we achieved before, they are quick to shoot them down. If that's not laziness, I don't know what is?" "OK" I replied, "if we set aside the issues of point inflation and the like for the moment, I still don't see how Agile has made anyone lazy? If it's true that these individuals are, indeed, lazy, then what Agile has done is simply made this visible. I would guess that they were always lazy, it's just that nobody really knew before because work and the effort required to complete it were hidden. It's only now that we've introduced transparent methods that these issues have become apparent." That is if, and only if, they really are lazy. My

the death of tdd

Several years ago, Colin had the pleasure of working with Mike and his team as they embarked on their Agile journey. As with many teams, they went through stages of what might be termed maturity. First, they learned how to plan and work iteratively, later they learned incremental working. Finally, they reached a point where they wanted to improve their engineering practices and so Colin had introduced them to Test-Driven Development. Now he was sitting listening to Mike, the technical team lead for the team, explain to him why TDD wasn’t working for them. "You see, TDD forces you to decouple everything” he said, “You taught us the SOLID principles, JSP and the Composed Method pattern?” He looked down into his cappuccino, “you introduced us to clean code, too. We’ve followed the rules in the book to the letter and now we’ve found it’s just too difficult to write code.” I was curious about his statement, “What do you mean it’s too difficult?” I asked. Mike was hesitant at first but

cross-functional

“RJ,” said Willy, the CEO, putting his arm around RJ’s shoulders, “we made you CTO because you said you could deliver. Foofle have launched a cloud product and it looks like we’ll lose our market share to them. We can’t wait a year, what’s the earliest we can launch Project Synergy? Change the team if they can’t deliver!” Richard Jones (known as RJ to everyone except his mum) went back to his office to think about the situation. Willy was right; he was promoted because he promised to deliver Project Synergy within a year. Unfortunately, things weren’t going well. He had skilled engineers and he’d planned everything thoroughly but things weren’t working out. His DBA, Donald, had broken his leg snowboarding and couldn’t produce Synergy’s schemas, tables and queries. The middle-tier team were working on defects while waiting for Donald to recover. The UI team were finished with Synergy and had moved on but their team lead was worried about rework. He wouldn’t stay CTO for long at this rat

planetary system

Until 1781, humans had believed there to be only six planets (including Earth) in the solar system. Although many eminent astronomers had previously spotted the planet Uranus, they had always presumed it to be just another star and listed it as such. In March 1781, William Herschel made a series of parallax observations through his telescope and believed he had discovered a comet. On 26th April that year, he reported his find. Only after feedback on his report from the Astronomer Royal and independent confirmation from European astronomers, did he finally concede he had discovered a new planet. After some discussion, Berlin astronomer, Johann Elert Bode, named the planet Uranus. Herschel brought the number of planets in the solar system to seven. Later, Alex Bouvard noticed some unexpected perturbations in Uranus’s orbit and predicted the existence of yet another planet. Johann Galle visually confirmed Neptune’s presence in September 1846 and brought the number of planets to eight. No,