I have just returned from a five day conference in Orlando, Agile 2010, hosted by the Agile Alliance. I’ve been doing SCRUM for about 4 years, depending on whether the client engagements I’ve been on have allowed it. When they haven’t, it’s generally been their loss. I’ve come to this conclusion after observing how things can go wrong on projects and with client relationships even before I discovered Agile in 2006. When I first read the Agile Manifesto, which stresses Individuals and interactions, working software, customer collaboration and responding to change, I found a lot to agree with, based on having had about 6 years of experience on projects where testing was late or neglected, massive documents were written and never read properly, end users were barely involved in the process and many projects felt like “Death Marches“.
The sad thing was that although I agreed with it, I didn’t see how it could possibly work in the real world, where I felt that people were naturally prone to not collaborating, to hiding behind titles or signoffs and to politicking with projects, rather than just getting the job done. I’m pleased to say that, since 2006, I have only had one client where absolutely nobody seemed willing to work towards getting a job done. Quite rightly, their share price has barely moved in 4 years.
So although I haven’t been all the way around the block, I’ve definitely gone around the corner. I was looking forward to the conference as a way of gaining new insights and confirming old ones. I was not disappointed. Although the conference was a bit of a curate’s egg, I was lucky to fly away with inspiration and some new ways of looking at delivery, courtesy of some of the best names in the business:
- Agile is a mindset and Don’t Force Terminologies – Something I’ve been really guilty of is hanging on to the SCRUM terminologies when dealing with new teams. “We already do agile: we have meetings every morning” has been like a red rag and I’m guilty of having dashed in and deployed buzzwords in an attempt to improve things. Agile is a mindset: it doesn’t need people to play Planning Poker, when they could instead do an estimating game. It doesn’t need people to do a retrospective, when instead we can meet in the pub and look back over the iteration over a few scoops. As long as the behaviours are followed, the benefits of Agile can be realised. Conversely: performing the ceremonies of Agile won’t on its own make your team Agile. They have to think and behave that way.
- Waterfall is Dead – I don’t agree with this at all. I think it will still be necessary where technical constraints make this unavoidable or where organisations are not mature enough to deliver differently. This was an example of some of the hyperbole at the conference. Another was “Functional Managers are dinosaurs”.
- Employees as Volunteers – Treat your employees as though they are working for free. I think I knew this already, having started off my Project Management life with the early realisation that I have a lot of responsibility but not really any authority. Let your employees see what it is they’re working for. Get them motivated to be creative. Treat them as though they could just quit or go slow at any moment and they’ll reward you for it by being loyal, motivated and productive.
- Fit designs to constraints – Why try and build something beautiful with difficulty when all you need is something that’s ugly but easy to build? Look first at the constraints of the project, then design your solution with these in mind.
- Decouple dependencies – Many projects have cascading dependencies. If the top of the chain is delayed, a delay will ripple through the project. For this reason, I’ve focused a lot of time on managing dependencies in my projects. In future, I’ll look to break them instead wherever possible.
- On Time, On budget isn’t the be all and end all – What if your project was on time and on budget but didn’t do anything new? What if the customer didn’t adopt it? What if you had overspent, but the end business value delivered made the difference between success and failure? Coming from a consulting background, “On time, on budget” has been essential to me. This is because margin is dependent on these things. Now that I’m no longer in consulting, I need to look beyond just getting the project delivered, but instead concentrate on the value being delivered; especially in an organisation where the incremental costs are so much smaller than a consulting day rate would allow. This isn’t to say that the discipline of schedule and cost tracking should be cast aside: instead these data should be used to come to an informed decision with the Product Owner. This was a bit of an epiphany for me, especially since any project can be on time and on budget when it is rebaselined near the end.
- We should eliminate Project Managers – One I’m not happy about – probably more hyperbole. The theory goes that in a perfect world, with self-organising, cross-functional teams, Project Managers won’t be necessary. Instead, the teams can work with the Product Owners to get stuff done. Thankfully, we’re not there right now, so there’s time for me to retrain!
- Go Cross-Functional – This is an obvious one. Guess what: So very few people actually implement this and it’s really crucial to efficiently getting projects done efficiently. This is often because of technical debt or organisational issues. This point was hammered home again and again at the conference. Cross functional teams should become part of the business unit they’re delivering with. It may be cost effective to offshore and or centralise development, but if it’s more effective for delivering value in the longer term, isn’t this the better strategy? The answer is: maybe. If you’re desperate to satisfy your shareholders over your customers in the short term, then maybe it isn’t.
- Good engineering is crucial – This was made over and over. One speaker even went as far as saying, “If you only do one thing, implement Continuous Integration (CI)”. Without CI, Automated Testing and other lean engineering practices, technical debt mounts up, iterative development becomes too expensive and it becomes impossible to implement Agile without massive deferred cost.
- Management Debt – My business is software development to support the business of others. As such, I’m conscious about Technical Debt (the deferred consequences of hasty or slapdash software development). Management Debt refers to the implications of not making committed decisions, not collaborating with across the company for the greater good, changing priorities frequently, and generally looking very busy with little positive effect. I have seen these symptoms many times and seen the damage they have done to motivation, retention, productivity and efficiency.
- Get into Kanban – I really liked the consequences of Kanban: determining throughput and working to that, not overloading the team and allowing the team to pull work through as it is ready. Kanban is organised on a board system and has its roots in lean manufacturing principles, which stress “just enough” inventory. When someone challenged the speaker by asking how they were supposed to fit the hundreds of projects on their wall board, the speaker responded that they “had too many projects approved”. Through presentations and interactive sessions, the point was made that running lots of projects in parallel is inefficient and also delays the realisation of business value excessively: do one project at a time, more quickly and every time one of the projects gets released, it starts making money.
- Focus on the Customer – Everyone should. The customer is the end customer that your organisation is there to serve. For a developer in a retail organisation, this means the person going to buy your stuff at your stores. It does not mean the executive who commissioned the project. That’s your product owner. If everyone focuses on the customer, developers will be motivated and care about what is being built, product owners will demand just enough features in an iteration so that the customers can benefit from the product as soon as possible and the organisation will spend less time fighting itself, more on working to deliver great products and experiences to the customer. And isn’t that a motivating idea to end on?