8 Questions for Your CEO
24-09-2008November Scrum Breakfast: SwissICT and the Journey to Agile
30-09-2008I almost didn’t go to the Agile Business Conference in London, but I am glad I did.
My introduction to Agile was Scrum, through which I discovered XP and Lean. Artem reported from Toronto that Agile seemed to be focusing around Scrum and XP, and that the two factions were putting their internal rivalries behind them and calling the results ‘Agile’.
Scrum and XP were not very visible at this conference. Present yes, for instance in the Keynote from Borland, but both ceded the limelight in deference to DSDM, the host of the event.
I discovered agile is a much wider than ‘just’ Scrum and XP, so wide that it risks turning into a bandwagen and losing all meaning. Many methodologies and frameworks were present, including DSDM, RUP (an excellent presentation from BJSS discussed developing a real time trading system using what was clearly RUP, even though they didn’t call it by name), and OpenUP.
OpenUP is an attempt to turn RUP, a humungous methodology which usually needs extensive tailoring, into a slim framework which can be complemented with useful practices. However if they really want to end the “Process Wars,” OpenUP’s proponents should send fewer barbs and FUD in the direction of Scrum. At this point, I should probably refrain from saying that you can tell this comes from IBM. Oops.
I even heard one company say, ‘we eliminated most documentation, so now we are agile.’ Dilbert lives.
There were several really excellent talks, including three keynotes, and the discussions in the halls was just amazing. I learned a lot and met many interesting people! I even learned that RUP can be agile, and it is possible to develop successful projects with it.
What are my key learnings?
- Agile is first and foremost about values. Honesty, openness, trust, courage and a responsible attitude towards money. Values are an excellent place to start the agile discussion with top management, particularly since the symptoms are magnified at that level.
- Adopting agile values is the place to start. It is a strategic decision by top management. It is in their interest, even though they will need some convincing
- The dangers of just ‘doing agile’ are substantial. So use a name brand framework and follow it to the letter for your first agile projects. As you do it, that framework will evolve to meet the needs and character of your organization. But if you start off by improvising, you will end up with a mess.
- As a manager, start doing Scrum as the first concrete step in this direction. Scrum is a simple management practice to effectively organize teams. It’s OK to start with small steps to build confidence. As confidence increases, Scrum can be applied in a broader context.
- XP is the next step. (If you’re a developer, start here, but try to get some sponsorship from higher up). The teams are encouraged to introduce solid engineering practices. XP’s vision of a tightly integrated customer is what a Scrum Product-Owner should evolve into.
- Lean principles provide additional important context for making good decisions to improve effectiveness, but don’t get preoccupied with getting too lean too quickly.
Where will this take us? Agile offers a vision of dramatically improved communication, because the impediments to communication (e.g. mistrust) are removed. Dramatically improved effectiveness and productivity will follow.
What would it be like, when IT’s ability to deliver value were not the limiting factor in your company’s ability to deliver new value to your customers? It could happen and agile is making it happen.
7 Comments
Would you mind elaborating on the “dangers” of following a customised methodology over a “named brand framework”? My company is taking steps to adopt Agile practices for the management of projects, but have found the information about Scrum to be somewhat insufficient in our web development agency, multi-project, multi-team environment, so we are thinking a customised process tailored to our organisation would be better.
If you are a master level practitioner, there is no problem improvising. Scrum and XP evolve to meet the needs of your situation.
The problem comes from either a) having no methodology or b) improvising as a beginner, i.e. without the experience to make good judgements about what practices to adopt and what to keep.
The danger is you suppress important practices (usually to protect dysfunctions in the company) and end up with no (useful) methodology.
So think Shuhari: start with Scrum or XP, follow the book for 6 months, get some training and coaching along the way, and then start to adapt the process if you fee a need to.
Great post, and I totally agree with Peter’s comment back to Neil.
I want to elaborate a little further on the denominations of agile.
If you are adopting Agile bottom-up from a tech team perspective… start with XP. If you are adopting agile top-down from a business perspective, start with Scrum.
And yes, at Agile 2008 in Toronto, during the keynote banquet Uncle Bob Martin basically declared that XP and Scrum need to unite and that they complement each other. I attribute this to the fact that XP focuses on engineering practices and Scrum focuses on PM approaches. Someone at ObjectMentor once told me that XP is the content and Scrum is the box it ships in.
This whole thread will provide some good food for my own blog content.
Hi Kevin,
While we are scratching each other’s back, I will say that I totally agree with your statement, if your doing agile bottom up, start with XP. My advice was intended for managers and I have updated the post to reflect that.
More generally stated, start within your own jurisdiction.
BTW – Developers were the early adopters of Agile. We’re now getting to the Early Majority phase, so managers are getting involved (we won’t say, taking over, because they’re not!)
Thanks for your response Peter. On reflection I think I should be asking a different question; our current exposure to Scrum is limited – we understand the principles and intend to follow it to the letter, however, our exposure to date has not covered the subject of how to do it in a multi-client, multi-project, multi-disciplinary team, agency environment where we tend to schedule jobs months in advance. This is where we are thinking we need a customised methodology – but maybe customised is wrong, maybe the more appropriate word is extended.
So, have I just not found the right information within Scrum on how to cope with this yet? If not, do you know of ay good resources online that discuss solutions to problems like this?
Your advice is most welcome – we are currently deciding on whether to spend several thousand GBP on scrum master courses or 3 times as much on an on-site training course on a methodology customised to our organisation.
Hi Neil,
Gee, I’d like to have you as a client! 😉
I used to work for a web agency. Very dynamic with a very large number of relatively small projects (and maybe a few big ones).
The scrumdevelopement group is a good source for information exchange on Scrum. I’ll be kicking off a sort of “ask the expert blog” but it’s not quite ready for the announcement. Real Soon Now.
I believe in your environment a strong team concept (i.e. Scrum) is very important for working productively. The basic idea is bring work to teams rather than people to projects. This will massively reduce the churn on scheduling people and also reduce the contention for critical resources (otherwise known as people).
So I don’t think (at least based on my previous experience) that you’ll change Scrum very much, but you will change your company quite a bit! And you’ll be much stronger because of it. And coaching is very important in the process. It keeps you from going off cliffs.
BTW – I just updated my courses; you might want to take a look at Agile Project Management for Scrum Teams. It’s more a getting started course for the whole team than the targeted Scrum Master training that is the CSM.
Cheers,
Peter
Thanks again for your response, I’ll check out the scrumdevelopment group. Just looked at your course, sounds good except for 2 things – you’re in Zurich and the course language is German and we’re in England and my German is limited to “Wie komme ich am besten zum bahnhof bitte?” 😉