Our situation is unique, and we have no time for change. We have no time for Agile. Ever heard this? This is exactly the situation when you need to be Agile. Here is a case study about introducing Agile at an organisation which had 14,000 commercial and business banks as their customers, including 15 of the top 25 banks. How did they take on the challenges of difficult relationship with other departments, management expectations, managing team capacity while facing technical challenges and technical debt. Have a read.
From Steve Jobs with the Macintosh project to Winston Churchill in the Blitz and Mandela’s dismantling of apartheid, through to countless successful sporting teams: what bound their teams together was a collective purpose. How about our Agile teams – do we have a collective purpose, a vision that our teams believe in? Here are a couple of examples of the collective purpose crafted by Agile teams and how did that help them.
Most tools encourage us to track metrics. So we track velocity, burn-down/up, planned vs delivered work and the list goes on. How useful are these? When used to compare team performance, most of these are counter-productive. Want more points? Want more stories? Want to ‘improve’ estimates? No problem. These will get better. But what’s the effect? So what should we measure? Ron Jeffries presents a few ideas on some useful metrics.
The Nexus framework is presented by Scrum.org as a framework that drives to the heart of scaling: cross-team dependencies and integration issues. Adam Cogan discusses with Scrum.org team member Steve Porter about the Nexus Framework, an Agile framework designed for large scale software development. (video)
Often, a person who starts out with a negative attitude about change can turn into a very ardent supporter once the change is experienced. It’s normal to face resistance while going through change. What to do then? How to deal with resistance? If you’re working with senior leaders, how do you deal with resistance? How to deal with team resistance? Here are a few practical techniques to deal with resistance.
What if the team doesn’t want to get together in a retrospective and reflect on the sprint? What do you do? Maybe, they don’t think Agile suits them. Maybe, they like Agile, but don’t really like the retrospective meeting. Where do you start from? What sort of questions do you ask?
Don’t want to refactor? Likely result is technical debt. And then likely outcomes are painful and longer release cycles, brittle code, more bugs and high maintenance cost. But how does the business account for refactoring? How do we make good decisions about refactoring, i.e. when and how much to refactor? What are the business catalysts? Have a look.