The Agile Response to a P1 Incident
How should a team respond to change?
The simple answer is “they should respond by being agile”.
If there’s one concept about agility that sceptical managers have caught onto it’s this one. When change happens, they expect that a truly agile team will be able to turn on a dime. You can hardly blame them, it sounds like a great idea. It suggests that perhaps managers don’t need to stabilise the working environment. They just need to pass change on. The teams will be able to deal with the impact…if they’re any good.
After all, aren’t they meant to be agile?
Of course, team members will have a rather different interpretation of this. They’ll tell you that agility isn’t about being reactive – it’s about responding to change in a controlled manner. With seemingly limitless demands on the team, and clearly finite resources, prioritisation becomes essential. Agile teams will work from an ordered backlog, and they’ll plan to deliver value by drawing work requests out of that queue. In other words they plan to follow an agile process…and that means things like “Sprint Planning” can still happen.
So let’s ask the question again – how should a team respond to change?
Agile Is Not The Goal
Agile has become the new fashion in the Software Development World. Organizations ranging from startups to large scale development, varying across technologies and domains, from Product Companies to Service Organizations have either started, or planning to start or already have years of experience invested in the Agile Software Development.
The challenge starts when the teams or organizations just want to do Agile, without understanding the need for it. They just want to brand themselves as Agile, as this is the new thing and everyone is doing it. They don’t want to be left behind in this race.
They just focus too much on the practices, and forget to think about why they are doing those practices. They blindly follow the popular Agile methodologies or frameworks without understanding the context of their problems, environment, real need of the hour, believing Agile is the ultimate solution to any problem.
Agile Politics – The Games People Play
‘Office politics’ – a fact of ‘working life’ we all have to deal with at some point or other.
Plato once said “One of the penalties for refusing to participate in politics is that you end up being governed by your inferiors.”
Assuming there’s some truth in this statement, then regardless of whether you practice, hate, avoid, or love it, it’s important to understand and know how to safely navigate the political minefield – especially if you want to advance in your career.
In this short video, Professor of Software Engineering at University of British Columbia,Vancouver and Director of Process Development (RUP) at Rational Software, Philippe Kruchten shares some useful information including:
Why Stretched Teams do “Scrumban”
A few years ago Corey Ladas wrote an article about an Agile approach he called “Scrumban”. As the name suggests, this is a variant of Scrum with certain Lean-Kanban characteristics. What he proposed was a graduation of Scrum teams to leaner and more pull-based ways of working than Scrum itself allows.
Whereas Scrum will “batch” work up into Sprint Backlogs and potentially releasable increments, a leaner Scrumban approach will seek to minimize the batching of work as far as possible. Each work item will be processed in response to a clear signal for demand, and not because it has been planned into a Sprint backlog. In strictly Lean terms, holding on to such inventory is a form of waste.
What Corey proposed was the gradual facilitation of leaner practices in Scrum. He sought “…to incrementally enhance Scrum with more and more pull-like features until all that remains of the original process is vestigial scaffolding”. For example, he argued that “if your iteration backlog contains 20 work items, then that’s still about 19 more than it needs to be in a pull system”.
The result was an agile approach which makes a Leaner way of working an end in itself. Since then though, Scrum-Kanban hybrids have taken off in ways that were perhaps not entirely foreseeable at the time when Scrumban was floated.
An Introduction to Continuous Integration
One of the great Agile ‘promises’ is the ability to “satisfy the customer through early and continuous delivery of valuable software.”
But what does it really take to achieve this end goal?
In this video, ‘The Continuous Deliverist’ and AtTask Inc Director of Development Jesse Dowdle shares some continuous integration insights, including…
