Agile

Better, faster, cheaper…

Here’s a presentation I gave a while ago to a bunch of senior execs, introducing the concepts of lean and agile to software development.  Many of the slides are taken from a presentation given by Richard Durnall which can be found on the ThoughtWorks website [pdf].  If nothing else, the slides about the problems with conventional development methodologies – that they take time, are not responsive to change and rarely end up satisfying all stakeholders, struck a chord with the audience I presented this to.

[slideshare id=657541&doc=it-forum-presentation1-1223980207243199-8&w=425]

Can retrospectives be made leaner?

The <enter time period> ends and a retrospective is held.  The team writes on Post-It notes things that are important to them and they get stuck up on the wall.  And maybe they get grouped into similar topics or themes.  And then the team vote on them; the topic that has the most votes is the one the group talks about first…. and they talk about that topic at length.  (If you were to analyse the signal to noise ratio of the first topic discussed compared with the last topic discussed, you’d find significantly more noise when you start).  Actions to resolve the issues are finally addressed and identified.  The team then move on to the next topic and so on until all the topics that had votes against them are done.  And it’s been a marathon session and we are done.

But what about the topics that no-one voted on?  What about the post-it that sits alone?  It was important enough for someone to have written it.  No votes, no priority,  no discussion, no action.  Yet mining it might have  delivered a diamond action.

I don’t care much for voting in retrospectives.  It’s not a particularly efficient way of doing things.  For one because the actual process of voting takes up valuable time.  Then by the time the issue with the fewest votes comes up, the energy in the room is drained and the discussion is rushed.  So why not do away with the voting, and introduce strict time management to the retrospective discussion.  Allow five minutes to each topic.  Use a stop watch to enforce this.  This will allow all the issues that were of importance to someone to be aired.  When the five minutes is up, if there is still heat in the discussion, park it and return to it later in the retrospective.  Such an approach is more incremental, and dare I say it, Lean.

What if an RFP was an Open Day?

We recently completed writing a response to an RFP. It weighed in at just under 100 pages with almost 34,000 words. OK, so there was a lot of copying and pasting going on, but that is not an insignificant amount of effort. Multiply that by the number of suppliers who were invited to respond; add the time taken for the client to produce the RFP itself, then review responses and answer questions and it is clear that RFPs consumes a lot of everybody’s time. With the winner taking all, that is a lot of wasted effort. But hold! That is only the first stage! The list of suppliers is whittled down and a beauty parade follows. Yet more effort is spent by two or three vendors turning their word document into a bunch of PowerPoint slides. A favoured supplier is identified and a process of negotiation follows, based upon estimates and what little information the supplier knows. Finally the supplier is selected, inevitably their are surprises on both sides when the engagement starts.

So the RFP process is a standard (but inefficient) way of doing business. What if it was done a different way?

One of the more significant decisions you make in your life (if you have children) is where you will send them to school. It is not a decision you make lightly as it will have a major influence on how your child grows up in the world. In the UK the government provides data (league tables) but this can only tell you so much; there is more to education that the statistics tell (which are historical and do not necessarily reflect the current reality your child is going to face). You will probably ask around – seek the wisdom of the crowd. Undoubtedly the community can identify good schools and bad schools. But the best judge of a school is to go there, to look around, to meet the teachers, to see the children. Do you trust the leadership of the head? Would you be happy for this person to teach your child, would you like your child to play in this playground, (and more importantly) grow up with these children?

So why not apply this thinking when looking for a supplier to build you an application? At the end of the day, projects succeed on personalities and relationships. Will the vendor get on with the buyer? The RFP tells you little about that. What if the RFP process was like seeking a school for your child? What if you had a project open day where you welcomed suppliers in, got to meet them, and maybe even got them to compete against each other.

What if you had three intense days when the business, IT and prospective invited suppliers come together to define the project and complete against each other in teams to come up with the “best” solution.

What if you provide the suppliers with details of what you are looking to achieve and request a basic qualifier – company details, profitability etc (the stuff that goes on every RFP) and a list of clients they have built similar products for (not exceeding one page of A4 per client). And for costings you ask them to provide you with their proposed rate card.

What if you then invite all suppliers to a large venue with a space for everyone to gather, and break out areas for the individual suppliers to work in. You start with background and presentations from the business and from IT. You tell the story of what you want, the vision, a description of the current technology, constraints, assumptions, known risks, integration points, etc. You provide some initial direction as a large group, but then breakout into supplier teams, interspersing each team with your people – from IT and the business. You provide technology (access to your systems, whatever is needed) and domain expertise. What happens next is up to the suppliers. They then have two days to impress.

What if at the end of each day each supplier presents their output to the whole group. The following morning you outline what you like of the outputs and ask the teams to take that as input to work on. Then at the end of the last day each vendor puts in an anonymous sealed envelope with their estimate (resources required to build the application). Can this triangulation technique be any less accurate than the estimate given on the back of several pages specification in an RPP?

If we accept that IT projects are about people, implemented by people, then the benefit of this approach is that you get to work with the supplier and experience the relationship first hand, rather than through documents and practiced PowerPoint presentations. And for the supplier it reduces the time taken to respond and will be more enjoyable for those involved. After all, don’t people prefer to do rather than write about what they do?

The scourge of Document Driven Design

Documents, or rather words are the scourge of product design. Because words can never convey the true meaning or emotion of what is really required. All to often, software development projects are driven by the documentation – agile projects can be equally guilty of this- driven by words on paper (or card) that convey what the requirement is. Issue #1. Developers don’t read!

Except for a few exceptions, software is all about a user interacting with a system in order to accomplish a goal. Trying to describe that premise in terms of features and functionality is fundamentally flawed as it will be nested in the language of technical implementation, not in the user interaction. “Find” becomes “search”, “buy” becomes “shopping cart”, “check” becomes “validation” and so on. Issue #2. The desired outcomes become lost in a smog of technical jargon.

Solution: Picture Driven Design. Up front. Yeah! I’m all for up front design! A picture tells a thousand words. It has the power to remove ambiguities, clarify the vision, showing what the journey to realise outcomes look like. Start with a day in the life of… scribble out the flow, the user journey. Nothing complicated, boxes and arrows. Then scribble out what the user interface might look like. Done. That’s your up front design. That’s your documentation. That’s your scope. What you do next is up to you, write loads of documents that describe it and produce the software in a waterfall way if you want. I’d prefer you were more lean and adopted agile practices, but whatever you do, start with the picture. I’m convinced it will save much pain later on.

What the customer wants

I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.

Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.

I want an intranet portal“.

No, you don’t. You want a place where your employees can share files and documents.

I want a google search appliance“.

No you don’t. You want to be able to find documents quickly and efficiently.

Worse is when vendors try and force products onto the customer…

You want an integrated BI toolset“.

No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.

OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.

I’ll write more about this in the future…

Bag of risk

I’ve only thought of blogging about Lois Vuitton once before and that was on how they positively encourage queueing outside their stores during busy periods. It’s a pretty strong brand that can tell its customer to hang about before being allowed to come in and shop.

This time I’m not blogging about them in a positive light, and nor are many others. Jeremiah Owyang describes the situation they are in well. Their brand has been hijacked by Nadia Plesner, an artist trying to raise awareness about Darfur and how the media considers Paris Hilton with her “designer bags and ugly dogs” to be more worthy of attention than genocide in Darfur. She uses an image of a LV bag in her T-shirts. LV take offence and sue, she refuses to budge and suddenly the image, the issue and LV all hit the spot-light. And in this David and Goliath contest, who is going to come out worst? There can only be one looser.

So why didn’t LV just ignore it, or even as Jeremiah suggests, harness the issue, turn it into a conversation that would paint them in a good light? I’ll argue that it is because they don’t understand risk.

There was always a risk to the brand be de-valued by being associated by asociation with Dafur. And this is what the marketing and legal team jumped on with such zeal. Did no-one think about the risk to the brand of turning this into the issue it has become on the web? Laying out the options and doing a risk analysis would have been a worthy exercise.

Option 1. Assess the global impact of nadia plesner, assume it is minimal and do nothing. Risk to brand: minimal.

Option 2. Follow standard route of brand defamation and sue. Ignore association with ‘good cause’, ignore blogosphere. Risk to brand: potentially significant.

Sadly, it seems that LV ignored the whole concept of risk and went with the default option – sue. They are not alone in failing to assess the risks properly before pursuing a course of action. In IT this approach is endemic. Where is the greater risk? Placing all your eggs in one basket, investing heavily in a desired outcome that will be many months before it sees the light of day. Or take a more gradual approach, investing ‘just enough’ to get ‘just enough’, ‘just in time’. The latter approach is lean and agile. A good agile project is a lesson in risk management, building resillience into the process and testing options as you go. It is organic and evolutionary, (rather like nature), as opposed to the plan and control approach of waterfall which is brittle and will struggle to react to or accommodate risk appropriately. I should write more but there is a day’s work ahead.

Agile Hong Kong

Exciting times for us in Hong Kong. The inaugral meeting of Agile Hong Kong is next Tuesday, 5th February. Martin Fowler will be attending, hosting an informal Q & A session. It’s sponsored by ThoughtWorks who will be providing the drinks. Check out agilehongkong.com for more details.

Cutting waste: dump PowerPoint and invest in a camera

So you’ve run a workshop and generated ideas. There’s a list of points on the flipchart and diagrams on the whiteboard. What now? Write it all up in Word or commit the drawings to PowerPoint?

Stop! Ask yourself why you are doing this? Is it just to record the ideas, to socialise back to the group involved in the workshop? Creating PowerPoint slides is not always an inconsiderable effort. It takes time. That effort is waste.

Think of the purpose of what you are doing. Then take photographs of the flipcharts and whiteboard diagrams, paste them into PowerPoint, and think of how much time and effort you have just saved.

The best CIOs don’t care about IT

One of the (many) things about ThoughtWorks developers is that, whilst they are passionate about technology, (and will happily argue for hours amongst themselves about the relative merits of REST over SOAP or ruby on rails over django), more often than not when they start a conversation with a client, technology will be at the back of their mind. I think it is safe to say that generally the primary driver in the ThoughtWorks mind is business value:

  • Why are we building this application?
  • What are the business objectives?
  • What will deliver the greatest value in the shortest timeframe?

Once the requirements of the business are understood, and framed in terms of their business value, then (and only then) should we turn to the technology. This can often be a challenging message; IT professionals like to think in terms of architecture and platforms, yet often these constrain the ability to truly deliver what the busines really needs.

The development team may be a Java shop and only does Java, yet the end users live in a world of Microsoft. So what happens – IT develop user interfaces that expose data in a web browser only for the business users to copy and paste it into the tools of their trade – Microsoft Office. And because IT only do Java that’s the way it has to be.

Value is lost in this thinking. It is easy to argue on the cost to expand the team requiring new skills by introducing .net into the architecture. But what is the cost to the business of time spent through inefficient work practices? All to often IT is an end unto itself, rather than the means. IT needs to remember it only exists to enable organisations. The most refreshing CIOs are those that recognise this. Those who focus upon delivering business value and question every big decision – what value is this giving to the whole organisation rather than thinking in terms of their IT silo. In fact, the sort of way that ThoughtWorkers think.

Paired introductions

Starting a meeting or workshop with new people will almost certainly commence with introductions.  Usually I will ask participants to say not only who they are and what department they are from, but also why they think they are at the meeting.  If someone is not sure, or says “because my boss told me to attend” there might be an issue.

Last week I attended a workshop run by a couple of our developers from China.  Because paired programming is a fundamental practice to what we do, they asked the participants to do paired introductions.  Participants paired, were offered a minute to talk to each other and then introduce their colleague.  Because the team already knew each other, they didn’t need the minute to prepare.  As each participant introduced his colleague, he emphasised the persons strengths and good points.  At the end of the introductions there was a tremendously positive vibe in the room which set the meeting up for success.  It might have taken a little longer than just doing the straight introductions, but the value was clear; get people to introduce their colleagues – it breaks the ice, promotes the positive (and as a facilitator gives you another hook by which to remember people).

4 of 10
12345678