Alan Gawthorpe & I a talk last month on doing architecture with agile teams:
We did the session agile-style: We had cards for our topics, and the ‘customers’ in the audience prioritised. I think it worked okay, it would probably go smoother doing it a second time. Some of the significant books & articles that went into the slides were:
Agile Methodologies for the Enterprise
* Scott Ambler & Mark Lines – Disciplined Agile Delivery
* Scott’s whitepaper on Agile@Scale
What does a technical architecture for agile look like?
* Coplien & Bjørnvig, Lean Architecture for Agile Software Development
* Poppendieck & Poppendieck, Lean Software Development: An Agile Toolkit
The further reading list
* George Fairbanks, Just Enough Software Architecture
* The UK government’s national audit office report on Agile Governance
If a team or organisation wants to adopt agile, should they do it all in one, or gradually? How do you overcome problems in agile adoption?
Agile Principles when Adopting Agile
Agile is not about process and methodology; it’s about people, relationships and learning and so turns out to be very much democratic and consensus based. Effective adoption presupposes that you’ve got the team(s) on board; if you have to impose agile, you’re probably doing it wrong. You can’t adopt faster than your teams and individuals are motivated to adopt.
If you apply the agile manifesto to the project of ‘adopt agile’ then you’d adopt agile incrementally, of course. I suggest an obvious principle: You can’t adopt faster than you can learn.
Agile’s take on organisation & adjustment is that teams self-organise with regular reflection, which enables you to see what’s not going well and consider ways to correct. There is no learning without feedback. Adopt incrementally with regular reflection and adjustment.
Agile teams puts work items in priority order, in to deliver the greatest business value first. Look at your current pain points – what’s not working well – and find out which practices are found to address them. Prioritise changes which add most value.
Risk management is arguably a missing subject in agile, so let’s add that here: soberly consider what, at this stage, you are capable of adopting successfully. First adopting practises you’re capable of to maximise your chance of early success. The choice to deliver value or to attack risk first is a judgement call. When you’re doing something new the risk of failure is high, so that judgement is largely about knowing how new to your team(s) the changes you’re making really are.
Finally, agile starts with the vision of a wider community learning. Any fool can learn from their mistakes but the wise learn from others’ mistakes too. In the past 10 years, others have already tried out all the mistakes for you. Call in someone in who’s done it before.
A fine time was had by all …
It’s been decades since software people started to think about how to cope with requirements changing during the course of an engagement, though other areas of endeavour have surely been doing it since the stone age. Literally.
The state of the art for software, and increasingly for other areas of IT, is Agile. Yet the recognition of agile in contractual relationships has lagged behind, which is odd given that a large part of IT is done by contracting someone.
When all is sunshine and daises this doesn’t matter. The time you really really want your written agreements to be right is when things go awry. If you’re doing business even with friends & family, it can help to have something in writing.
But how to write a contract for something when you know it’s going to change?
This problem came up in a linked-in architects’ discussion and I immediately reached for google to find my notes from Susan Atkinson’s presentation on Agile Contracts (I saw her present at a Rational User Group conference a couple of years ago). I reduced it to bullet points in /p1201/susan-atkinson-features-of-an-agile-contract, and she was good enough to drop by to correct & update it. She’s been developing an Evolve Contract Model with Gabrielle Benefield and the website should be up soon. Meanwhile there is a recent presentation on slide-share at Contract Metrics For Agile.
For those not yet convinced that there’s anything wrong with a waterfall-style contract and project, you can read the IEEE 2013 conference paper at http://www.slideshare.net/SusanAtkinson2/ieee-2013-the-flaws-in-the-traditional-contract-for-software-development. nb Open it full-page mode for easy reading.
Reading I Fear Our Mobile Group Being Forced To Follow Scrum crystallised in my mind what can go wrong when you treat Agile as a methodology. It describes a team successfully using kanban which is to potentially be required to use scrum — because that’s becoming the company standard.
Making a team follow an agile methodology is exactly *not* Agile.
Agile is “Individuals and interactions” being valued more highly than processes. Imposing Scrum looks like valuing the process more than the team.
Agile is “self-organising teams” and letting “the team [reflect] on how to become more effective, then tune and adjust accordingly.” Imposing conformity on a team that has already adjusted is a backwards step; you’re asking a team that has optimised somewhat for the individuals in the team to de-optimise again.
This doesn’t mean that you can’t teach an agile team anything. The manifest starts with “We are uncovering better ways of developing software by doing it and helping others do it.” A team that can’t be corrected, or won’t learn better ways, isn’t agile. For that matter, a team that won’t learn in any walk of life has started the downhill path to decline.
For what it’s worth, I’m sure that a competent lean team that tries Scrum for a while will learn from it, even if they end up optimising back to something more fluid.