30 April 2012

4 phrases v2

26 April 2012

The LAST conference you'll ever need

Ed Wong is one of the organisers in the local meetup community.  He's passionate about helping teams adopt agile practices, design user centric products and helping others learn.  After going to the Agile Tour event in Sydney last year he returned to Melbourne with the idea that we run something similar in Melbourne.

I argued that we extend the scope a little and we came up with Lean and Systems Thinking as two additional themes we should include and that led naturally to LAST as an acronym. When we discovered LASTConference.com was available as a domain we settled on it pretty quickly.

The biggest deal when arranging things like this is arranging a convenient venue.  Fortunately I am working at a University.  I went to the faculty of ICT and asked whether they would be interested and of course they were, so we scored a win by being able to host our event at Swinburne on July 27th.

Next we started asking Australian agile, lean and system thinkers people if they'd be interested in participating and several generously said yes instantly, and while we have not yet settled on the final line-up we can rest assured that we will have at least some interesting and engaging people facilitating sessions on the day.

Right now you can see some of the submissions on the LASTConference.com site, and you can also read more about the details of the day.

Our event is not designed to compete with Agile Australia. It will be more grass roots, led by practitioners and designed for practitioners.  There will be no big names from overseas and no CEO perspectives.  But it should be a fun day.  If you are going to be in town, come along.

(A last note, Rowan Bunning contacted Ed a few days ago and let us know that Simon Bennett is a Lean/Agile/ST coach and consultant in the UK trading under the name LASTing-Benefits. We don't know Simon, and are not directly associated with him, although I have discovered him in my Twitter feed. It's a small world isn't it.)

24 April 2012

An update on Google Docs as a Requirements Tool

Almost 1 year ago, I wrote a post about using Google Docs as a requirements documentation and management tool. Since then, we've finalized requirements for our first project phase, have made it maybe half-way through development and have even done a little bit of testing.

I thought this might be a good time to update everyone on my 'little' experiment (I'm piloting this on the largest project my company has ever done, thus the quotes around the word little) as I now have a better understanding of what worked well, what didn't, what sank like the Titanic and what I think we'll do different next time.

The Good

Believe it or not, there really were a LOT of good things to come out of this test of mine. Here's a little list for handy reference:
  • Speed of revision. Like any project, especially one where we started the requirements a long time before the development, we have had to make adjustments along the way as what we thought would work well sometimes ran into the wall of technical limitations. Because we didn't have an architect or developer reading along as we wrote the requirements, we sometimes failed to get down to the necessary level of detail for the developers to get things right.
  • Collaboration. Everyone has access to the documents. Everyone knows where they are (or at least they have been told!) Everyone can go look at them and ask questions. They are not buried on some shared drive that is only accessible when at the office or when connected over a VPN. If you need them, they are there.
  • Prototyping. Using Google Drawings to create wireframes makes getting ideas in front of our customers insanely easy. We have built a set of stencils over the last year or so that make drawing  and sharing a new screen idea trivial. This alone has saved me an insane amount of time.

The Bad

I wish it had all been good; I really do. Here's a sampling of feedback we've received on what doesn't work so well.
  • Too many docs, too many places. This one I actually take issue with, but it has been a consistent piece of feedback from the developers. They don't know where to look, despite having divided all the documents up by subject matter separate collections. There have also been complaints that we spent too much time categorizing information into different document types and not enough time tying all the document types together.
  • Google Docs sucks at formatting. Well, this one I completely agree with; it really is terrible. Thankfully, we are doing a minimum amount of formatting, so the pain isn't horrible.
  • Google Docs sucks for large documents. One document that the development team demanded we create, against my better judgement, clocked in at over 300 pages (long story; shoot me before I ever agree to this again). You can't use the revision history functions; it locks up. Loading the document up in the browser maxes out your CPUs for a very long time. Keep your documents simple; you will not regret this.
  • Speed of revision. This could probably be said as a bottleneck in our review process, namely finding time for me to actually look at and approve the changes. My BAs are awesome, so awesome that with all my other duties, finding time to review their changes, even small ones, is a big challenge. Thankfully we keep a fairly detailed change log so I know what documents need reviewing.
  • Collaboration. Some people just didn't get the concept of a document as a living thing. A few times, we had developers show us printed copies of docs that were 2 months out of date and try to claim things they coded in the last week didn't match the document. True, it didn't match the printed copy they had, but it perfectly fit the current one that had been updated prior to the start of their coding. It took several rounds of this happening before the dev team finally believed us that working from the online docs was the best thing.
  • Mobile. I live on my iPad. It never leaves my side. Google's support for it is horrendously bad. Drawings appear as an ill-formatted and shrunken image. Text documents only have the most rudimentary editing support. Spreadsheets... just don't bother.

The Future

We are about to start putting together some ideas for the second phase of the project. We want to build upon the good start we have with this tool and figure out ways to make this process work better. This project (really a program) is going to last for a few years as we replace and revamp our processes and systems from the ground up, so this is something we'll need to make work well. Here are some of the changes we're considering:
  • Omnibus Documents. Instead of 4-5 different types of docs, we are probably going to merge all docs for a particular subject area into different pages of a spreadsheet. While this makes the issue of document size all that much worse, it will (hopefully) make understanding what to read easier on the development team.
  • Better collaboration. This isn't so much better about where the documents are housed as it is about having the development and testing teams involved earlier in the requirements process. This lack of involvement in the first phase has been one of the largest hindrances during the project as it has caused a significant amount of rework. The BAs are not developers nor are they testers and expecting them to capture everything the other teams need without input from those teams is just not going to work.
  • Expanding the use of the tool. Google recently announced that teams can use Google+ Hangouts with Google Docs. For our offshore team, this would be a great way to review documentation prior to any code being written.
So what new types of requirements solutions have you been working with in the last year? Drop us a note in the comments!

18 April 2012

My new Prince2 hypothesis

If you have been watching my tweets you'll notice I have been searching for any reliable evidence that Prince2 as a method has delivered any sort of possible results to users.  While there are anecdotes of project managers describing success with Prince2, there is no evidence that it is anything more than a coincidence.

Apart from asking practitioners on PM forums and social media, I have also searched industry and academic papers on the topic. Nothing.

So, I am now confident to say that there is zero evidence that Prince2 can help you achieve any sort of success.

You would expect what people have invested in it, there would have been some work invested into proving the model. Given it isn't there, even in a tenuous, challenge-able state, I have modified my hypothesis.

My new hypothesis
"Prince2 actually contributes to cost over-runs, budget crises and disillusioned clients."
I don't know that this is a truth, but I suspect it is possible.  For example, we find Prince2 concentrated in UK and Australian Government circles. Coincidentally these domains have a reputation for poor delivery, bad project choices and tremendous amounts of waste within their projects.

(And yes, there are plenty of exceptions, but there is a clear trend, you have to agree.)

So, the call to action:  Can you help me prove or disprove this hypothesis? Do you have any studies or reports that cold help?

Things that could be useful;

  • Reports on industry project performance correlated to industry Prince2 concentration
  • Surveys of project outcomes compared to project delivery methods
  • etc
Looking forward to your help :)

12 April 2012

The role of the analyst on an agile team

Left to right: Me, Annie, Trent, Paul, Kaye, Erik,
With Kevin standing, possibly about to throw something at us.

On Tuesday night the local business analyst community met up to hear a debate facilitated by Kevin Broughton.  The topic was "Business Analyst: Role or Competency?"

We had 5 great panellists, and me as a ring-in.

On the pro-role side there was Paul Velonis and Erik Van Eekelen from Elabor8, Kaye Knight, contracting analyst gun for hire, and Trent Barnes, a recruitment consultant who specialises in BA, PM and QA roles from CicuitIT.  On the pro-competency side we had Annie McGlade, a BA Competency Lead at a large bank and myself, a natural contrarian.

Given the audience was a bunch of business analyst (peppered with a few analyst programmers) the debate pretty squarely landed on the side of "There is a clear need for business analysts, s don't be quitting your day job just yet."

Let me see if I can summarise the arguments in the order they were presented.  I'll make a few mistakes because (as a ring-in) I was trying to work out what I was going to say while they were taking.  I'll editorialise as well. Maybe the guys will drop in some comments below.

Paul started with the disclaimer than analysts are probably not required on small development initiatives where there are 2-3 people on the team and a single customer.  Things are straightforward and the communication lines are simple. Assuming your developers are competent and your customers knows their business and has some sense of the market they are working in you should be okay.  But, as soon as you start to scale - either in team size or project complexity a business analyst becomes a highly valuable asset for the team.  Systems thinking, asking 'why' a lot, and helping people deal with complexity were just a few of the issues he said business analysts were useful for.

An interesting note Paul made when speaking was that Elabor8 analysts were all trained and coached in consulting skills, and the 'business analyst as consultant' very much flavours the way he sees an agile BA working.  [Craig editorial: Me too, by the way.  Facilitation rather than system analysis and modelling skills are clearly the more important skill for an agile BA.)

Erik followed up (or was it Kaye next?) with examples of how analysts add value.  Essentially he amplified what Paul was saying, and expressed a caveat on Paul's idea of small teams not needing analysts, saying that while they may not need one, an analyst can usually help a lot even in these situation.  A key part of Erik's argument was that he believes that the members of a multi-disciplinary team should help each other out to get their stories done, but that that every discipline (BA, test, dev) demand its own, very specific, skills to do the job properly. That's why he said that any Agile team - no matter how small- should have a BA, a Tester and a Developer: it takes skill to play each specific role.

Kaye introduced the Swing picture below and talked about the need to continually ask 'why' and to seek out answers to questions and to challenge assumptions. She also highlighted the analysts ability to think about the situation independent of technology, and thus help with customer centric thinking on the team.

Next up was the other side of the argument; The analyst role is not needed on agile teams, and all that is required is the competencies.

Annie went first and talked about how any person with sufficient motivation can be trained and coached to perform the role well. And conversely that many people in the industry operating with the BA job title were not actually adding a lot of value to the teams they were on.  She also made the point  that job titles come and go, but it is the tasks, activities and thinking tools that are required for teams. Who has them doesn't matter so much.

Lastly I went and my argument was that hand-offs degrade flow and that applies just as much to project teams as it does to organisational silos.  As a bunch of analysts, I sad, we are all familiar with the boundaries on swim lanes being obvious pain points. (Erik and Kaye countered me with the surgical team metaphor. A bunch of specialists working as a team are still specialists.)

I tapped into the emotions with two stories:  Firstly, when doing some BA competency assessments I didn't see strong correlations between effectiveness and competency. What was much more important for team effectiveness was playing as a team.   And secondly I saw an example of a team where a BA became a single point dependency, and when they were away the team crashed. But that crash and absence was a catalyst for further improvements from team outputs. (Of course I was playing a devil's advocate and Erik once again called me on the anecdotes != statistics rule.)

The debate was interesting and fun. We explored a few ideas, and had a good Q&A session afterwards.

A few closing notes because I wanted to say this but forgot on the night;

  • The only Agile model that is dogmatic about roles is Scrum. Everything else pretty much accepts whatever your current staffing model is, with the caveat that the team should work together as collaboratively as possible.
  • It strikes me that the emergence of the BA role was in response to a need for a generalist to act as a boundary spanner across the organisation. With the IIBA doing a very good job of defining the role, with it's boundaries (i.e. a BA is not a change manager or trainer) they are going to create a vacuum for  that generalist role and something else is possibly going to have to take it's place.
So, I'll leave it at that.  If you were there I'd be keen to hear your thoughts on the night.

1 April 2012

Do yourself a favour (Subscribe to OneFTE)

 delivered to your mailbox/RSS feed/Twitter account/Facebook feed/Google+ account three times a week, every week.