Better Projects

What's the ultimate agile BA technique? Paper Prototypes

2012-05-17T10:00:00.000+10:00

According to the meetup group we played with the other day it is paper prototypes.

(You can see the whole list of techniques we discussed here, and the game we used to create the list here.)

Ideas for DarkPatterns.org homepage

What we the criteria that got it up as the champion technique on the night?

You can test business ideas with them
Paper prototypes can be built quickly and edited just as quickly
They can be disposed of equally quickly and with less fanfare than the deletion of an exquisitely crafted Balsamiq wireframe
Pictures tell a thousand words
Screen sketches capture key business data
Screen and flow sketches capture important process and interaction flows
The combination of the above help you discover edge cases
A paper sketch doesn't get you caught up on details of design or UX

Here are some handy resources on Paper Prototyping

Wikipedia page
A case study on designing a University web application
An online book - Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces
A handy Youtube clip showing someone do it particularly well (embedded below)

Analyzing without a License

2012-05-16T10:50:00.000+10:00

I've posted about him before, but if you're not reading Jeff Atwood's Coding Horror blog, you're really missing out. Today's post is perfect. There are several lines that really stuck with me, here is one of my favorites:

Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks.

Over a year ago, in response to one of my posts here on the site, someone told me that if I didn't like how developers did their jobs, I should go out and write the code myself. The idiocy of the statement just astounded me. Now, here is one of the premier programmers in the world, backing me up.

You see, learning to code is very similar to business analysis or project management. It may sound like something that anyone, given a weekend and a 'Teach yourself XXXXXX in 24 hours" book can do, but learning a programming language does not make you a developer, nor does learning the concepts behind business analysis or project management make you either one of those professions.

My biggest concern is that most everyone should not learn these skills. To quote the movie Tommy Boy:

Tommy: I can get a good look at a T-bone by sticking my head up a bull's ass, but I'd rather take a butcher's word for it.

Most business people shouldn't need to know more than the basics about technology and they definitely shouldn't know enough to try doing project work, at least not beyond being a SME. Its not that these people are dumb, far from it, but their expertise is in running the business. Those of who work on projects, developers, analyst and PMs, have our areas of expertise as well. Some of the skills overlap, but lots more do not.

With my background as an analyst, I do tend to see everything through that lens. When I'm in a meeting to discuss a recently discovered problem or opportunity and the first thing I hear is someone say, "What we need to do is..." I find myself trying to breathe deeply and not lose my temper. Starting at the solution without really getting a firm understanding of the problem is one of the worst mistakes you can make when doing analysis. It is a very easy failure to make, one I see analysts make regularly, but one that you have to train yourself out of in order to be the best at what you do.

Be an expert at the things you're really good at and leave everything else to the experts in other fields. When we work together as a team of experts in our own field, we do better than a bunch of amateurs who don't know enough to know they don't know what they're doing.

Project estimating: What could possibly go wrong?

2012-05-15T23:24:00.003+10:00

"Are we born to be optimistic, rather than realistic? Tali Sharot shares new research that suggests our brains are wired to look on the bright side -- and how that can be both dangerous and beneficial."

Learning, Video Games and Photoshop

2012-05-10T10:26:00.000+10:00

I regularly read Rands in Repose, and today's article was nothing short of awesome. If you're not a Rands reader, I highly recommend you become one, if for no other reasons, for bits like this:

Photoshop’s goal isn’t entertaining unless you think the national pastime of bitching about Photoshop is a sport. Photoshop has no points or leaderboards because Photoshop is a tool and the perception of tools is that you must be willing to supply blood, sweat, and tears in order to acquire the skills to become any good at using them.
Bullshit.
Make a list. Tell me the number of applications you use on a daily basis where there is a decent chance that you’ll end up in a foaming at the mouth homicidal rage because of crap workflow, bad UI, and bugginess. Is Photoshop on that list? Yeah, me too.

Photoshop isn't one of my regular tools, but the Mac image editing app Pixelmator absolutely is. Why? Two reasons... first, its slightly cheaper and second, it doesn't make me want to gouge my eyes out every time I open it. No, I'm not a professional image editor, so I don't need Photoshop, but the few times I've tried to use it, I run screaming back to Pixelmator every single time.

I bring all this up because I feel that programs like Photoshop just need to die. Die a horrible death. In a fire. Then get its ashes buried in the deepest part of the ocean. Never do we want to involve ourselves with something that makes our users want to hate our product. This is a sign of a product, and the project that creates it, gone wrong.

Oh, and before I forget, there are a few other apps that fit on my 'list' as well. Naming them all would take too long, so I'll list categories instead, but I bet your list looks a lot like mine:

Microsoft Office
Project Management apps
Requirements Management apps
Defect Tracking apps
Testing Automation apps

Pretty much, if its a tool used by project people, I'm probably going to hate it. That's sad, because in the 10.5 years I've been doing this, it hasn't gotten any better.

(Yes, there are some fine tools out there; I just don't get to use them, and even those I have played around with that were not terrible still made me want to gouge out my eyes at least once a day because of some insane thing it did.)

What's on your list?

Join us and blog at Better Projects

2012-05-10T09:17:00.000+10:00

It's time for us to refresh the tone and content here and so we would like to hear from people who would be interested in joining Ted, me and the occasional other to blog here.

The rules are pretty simple; share what you are learning as you grow in your role. Get in touch if you are interested and we can talk more.

Being agile; not so important after all

2012-05-03T09:00:00.000+10:00

Being agile is not always important.

The interwebs have a thing going on in recent months about the difference between doing agile and being agile.

There are a bunch of agile things that correlate with positive business outcomes, but they aren’t universal are they?

I work at a university. What we do in the IT Department is important but it is barely core business. Core business for universities comes in three forms; Innovation borne out of research, student experience, and subordinate but critical to that; teach experience.

A side note on that topic: Research and student speak for themselves. That’s where the money comes from, either directly or through government grants. Teacher experience is worth noting because most teachers in universities are working at below their market value. For example, all of the teaching staff related to ITC that I have met at Swinburne are smart, pragmatic and well informed in our industry. They could all be earning much more as consultants and industry practitioners. But they sacrifice earning more money in order to be able to participate in the shaping of the industry both through research and through teaching students. There is clearly consideration in that.

Back to being agile. What can the IT Department do to affect these three aspects of the business? Yes there is a place to play in making commodity systems (mostly procured, not built) work. And yes, if they don’t work it can be a big deal. So you need to be capable at managing commodity services.

Where does being agile play into that? Where is the need for responsiveness to market conditions? How does an effective IT department affect enrolments or staff engagement?

It doesn’t really does it?

Yes, it will. When traditional education starts to feel the effects of the current and next waves of industry disruption technology will matter. But it probably won’t come from the OT Department. Instead the fancy innovations will be business led, often with IT partners outside the organization.

IT will still be important, but it will become a hygiene factor rather than something that gets discussed at the University Council.

And so, while being competent matters, being agile doesn’t.

So why pursue agile practices?

Perhaps because they might become table stakes for being competent. Perhaps because IT will partner with the business in innovation and industry disruption (They are probably as good if not better than many IT partners universities work with.) Perhaps because, as a developer led movement the agile values and ways of working are imbued with respect for the workers.

Perhaps because, once you understand it, you realise that working in more traditional command and control modes is fundamentally stupid. Enabling people to do their best is a much more savvy way t do business than managing to the lowest common denominator, or trying to manage away all risks through mandated methods.

The ULTIMATE business analysis technique

2012-05-02T11:38:00.001+10:00

Agile Business Analysts

A Melbourne community meet-up group

invite you to

Fight! The ultimate BA technique

Tuesday, May 8, 2012, 6:00 PM

Microsoft office, LVL5, 4 freshwater place, Melbourne

At this month's Agile BA meet-up we share our favourite techniques and search for the ultimate technique - that's right; the one method to rule them all!

Approach
We will do this via a game. Teams will form and share their favourite techniques and methods, with examples of where they have been successful.

Teams will then pair off against other teams and present their favourite methods and challenge the other team with counter examples or questions. The rest of the room vote on the winner. We repeat this in a series of four to five rounds until a winner is found.

Along the way we hear lots of examples of where analysts have deployed successful techniques and hear what situations they may not work in as well.

Learning Objectives
This is a fun interactive way to review a broad range of methods and techniques, to talk about them, and hear stories of when they have been successful in the field.

You bring
Your variety of experiences, an inquisitive mind and a pen and paper. Post it notes would also be good 

Audience level
All levels of experience are welcome. Diversity of the whole room is what is most important. The call to action

4 phrases v2

2012-04-30T09:00:00.000+10:00

The LAST conference you'll ever need

2012-04-26T15:30:00.000+10:00

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.)

An update on Google Docs as a Requirements Tool

2012-04-24T09:00:00.000+10:00

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!

My new Prince2 hypothesis

2012-04-18T22:23:00.001+10:00

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 :)

The role of the analyst on an agile team

2012-04-12T04:05:00.000+10:00

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.

Do yourself a favour (Subscribe to OneFTE)

2012-04-01T09:02:00.000+10:00

Insight,

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

OneFTE.com

On the Community of Practice

2012-03-28T22:10:00.000+11:00

The Community of Practice is a concept that is used in professional and corporate circles to describe a community of people with common areas of interest, mostly in relation to the performance of role oriented tasks, but sometimes more generally. Ideas that underpin the Community of Practice include the concept of self-directed learning and knowledge sharing through storytelling, and collaborative problem solving.

The community of practice is manifested in work environments I attend through activities such as brown bag lunches, CoP monthly meetings, shared online spaces (such as a BA practice Wiki), Social media groups, on-line forums and so on. Communities of practice share many aspects of the master-Apprentice model without the formal hierarchical and power based roles inherent in the guild system. Communities of practice tend to be free and opt-in entities. People are typically free to join and leave when they want.

The community of practice is an idea full of contradictions; for example if it is voluntary and potentially quite ad hoc, how is knowledge on standards and quality developed and maintained? In this idea we find the challenges of creating and sustaining an effective community. People need to find purpose in participation, must find a way to both learn and contribute and must feel a sense of ownership in its success.

A Community of Practice is a difficult thing to make work over the long haul. A worthwhile consideration is; To what degree does this need to be a sustainable community? Is it still valuable if it comes, fulfils a need, and then once the need diminishes, the community disbands? This idea of a temporal organisation stands in contrast to the guild system, which like corporations creates an entity who’s main motivation is to sustain and grow its own power.

Given the CoP’s potentially temporal nature it’s worth considering the contrast with projects; CoPs don’t have a specific goal, and they don’t have a specific end date. While projects are typically led by a client’s vision, communities are led by an emergent vision from the group.

Given this concept fits so well with the idea of managing work in complex domains it’s surprising we don’t hear people talking more about leveraging Communities of Practice as vehicles for getting things done.

On Guilds in Modern Times

2012-03-27T11:59:00.000+11:00

The History Lesson
A guild is an association of craftsmen in a particular trade (Wikipedia.)

Guilds were usually organisations that had an early form of accreditation and membership, often in the form of something called “letters patents” issues by the local lord. The result of this is an exclusive right to deal in a particular area. The guild would charge members a fee to join, and in return members would receive a right to practice their craft within certain jurisdictions.

As ‘professional’ organisations members would swear an oath of allegiance to the guild, much like members of modern organisations like PMI sign on to an ethics standard that implies certain behaviours and allegiances to the profession above and beyond the guild members’ other obligations to the customers.

Guilds ensured their dominance over labour markets by ensuring certain quality and performance standards were met through professional standards and through the apprentice, journeyman, master model. This model had a variety of consequences including the control of labour which ensured premium wages for guild members, and eventually a proliferation of specialisations within the guild.

This fragmentation eventually led to the end of guild dominance of the professions, as subgroups competed for dominance in their market.

There is a general view that the guild was essentially a racket which stifled innovation and creativity within industries. It was a classic example of the status-quo maintaining it’s power rather than seeking advancement in skills and techniques that would benefit the industry and the community it served. Guilds primarily served their members to the disadvantage of both later generations and the community or customers they serviced.

The Guilds of Today
Today many guilds still exist, especially in the creative industries. Some guilds wield large amounts of power, such as the groups that manage and protect the interests (including intellectual property) of writers and artists.

We can see that guilds can still be overly focused on the short term goals of protecting the status-quo over being responsive to future members and the communities they purport to serve.

Newer guilds (like in the software craftsmanship movement) don’t tend to have the tremendous amount of power and influence that large and established guilds demonstrate and wield, but they clearly have that tendency.

So when we talk about guilds in the software craftsmanship or IT domain what do we mean?

The term was pressed into duty because we wanted to draw on the strengths of the master-apprentice model. We want to acknowledge that the most effective way to transmit complex knowledge or knowledge of complex information is through mentorship, and oral tradition.

I have two questions out of all this;

Are we stealing the word and re purposing it? Or are we in the business of building up a power base with a view to protecting member interests over the world around us?
Is the Master Apprentice model the best one for where we want to go, and are the assumptions that underlie it valid? Can you help?

Burn Up Charts

2012-03-27T11:48:00.003+11:00

Burn-up charts are different to burn down charts. They present different information and address different needs. This post takes a look at the Burn-up chart and how it is useful for managing client and stakeholder expectations.

While burn-down charts are a team tool to help the team gather data in order to inspect and adapt within a sprint, burn up charts are about presenting data to stakeholders outside the team.

What is a Burn-up chart?

A burn-up chart is a chart that shows the rate at which features are completed over time, indicating when a particular parcel of work will be done. Burn-up charts measure the work completed per iteration and provide empirical data to assist with forward planning. The are similar but different to both Earned Value and Cumulative Flow charts.

Things a Burn up chart helps us understand include;

What is the size of the total work under plan?
What is the team’s velocity (i.e. capacity)
When will key releasable feature sets be reached?
What trends are apparent?
What problems or opportunities can a burn-up chart address?

Burn-up charts are a tool to communicate when the team think they will be done to project stakeholders
They assist in the planning of downstream activities such as advertising, release management activities, and other release to user type activities

What Burn up charts are not

Burn-up charts are not measuring work in progress or work completed within an iteration (see Burn Down Charts.)
Burn-up charts do not measure activities completed. They only measure the completion of valuable increments of working product.
Burn up charts are not Earned Value Charts. For example, they do not measure expenditure.

Who is responsible for the burn-up chart?

The answer tot his question depends on the team structure and roles you have on your team. The burn-up chart shows when releases or projects will be completed so ask yourself who is best positioned to manage this message.

Typically the ‘product owner’ will be the focus point of this sort of messaging, although it may also fall to a project manager. Also, it is not unusual for scrum masters of business analysts to accumulate the data.

Consider that there are three aspects to managing this sort of reporting;

Create the report system via negotiating the data to be accumulated, setting up templates in excel or Powerpoint, or within backlog management tools and so on,
Gathering the data on a regular basis to support the report
Actually delivering the message and having the discussions that go with the report.

Strengths and Weaknesses of the tool

Strengths

It is simple to implement
The image trends towards an idea of 100% complete
It is a leading indicator – showing what the future is likely to bring
It presents data over time so systemic trends become apparent
Early stages of a team often present overly pessimistic velocity, which can cause anxiety in stakeholders
The binary nature of work – done/not-done encourages teams to manage their work to complete quickly

Weaknesses

Cumulative flow diagrams provide a more fine grained view of work in progress and bottlenecks
Burn-up charts require calculating velocity and story points which may or may not be valuable activities, depending on the team context
Teams that do not manage their work to a ‘100% completed’ state are hiding work which will surprise stakeholders later in the project.

A User Story is just like a support ticket

2012-03-22T07:00:00.000+11:00

When I talk to the local business analyst community about the User Story I always break into a little routine about how a user story is different and distinct from business analysis and requirements modelling. My metaphor is the support ticket.

When a product support team receive a defect report they raise a ticket in their management system and do whatever needs to be done to resolve it. The ticket travels through whatever workflow is appropriate to it and eventually someone resolves the issue, verifies with the customer that all is well and then closes the ticket.

Generally requirements analysis isn't really done. Certainly discovery work as performed in the BA community isn't done. The support team tent to either know through their experience what business requirements apply to the problem area, or they look at the manual. Sometimes they may ask for clarification, but this is rare. The team are expected to know how the system works and how it supports user operations.

This is not to say requirements don't exist. It's just that they are independent of the support ticket.

User Stories are like that. They are the ticket that travels through a workflow.

(Of course I my model here is flawed. The "As a, I want, so that" strays into analysis and modelling territory addressing partitioning of work, user modelling, motivation modelling and even interaction modelling. But it doesn't do the whole job. Analysis and modelling remain distinct activities and artefacts.)

Four schools of Business Analysis: Mastery versus breadth

2012-03-20T22:52:00.001+11:00

By my estimate there are four main schools of analysis;

Data Modelling
Business Rules Management
Business Process Modelling, and
Interaction Modelling (i.e. Use Cases)

We as a community of analysts tend to get early exposure to one and then work to master it. And that works to a point because some disciplined analytical thinking goes a long way no matter how it is applied.

We then augment these basics with more advanced skills and techniques and complement them with social and interpersonal skills and gradually become highly competent analyst/consultants (and sometimes even an Analyst-Therapist.)

But.

Imagine if instead of investing all that energy into mastery of one modelling school we were to instead become generally competent at two, three or even all four? By applying multiple thinking models to the problem at hand we will get a better and more broad understanding that we will from improving our artistry in techniques such as BPMN or Use Case Narratives.

What we blog about | Wordle 2012 v 2009

2012-03-20T22:24:00.001+11:00

Two Wordles comparing early 2012 BetterProjects.net blogging to late 2009.

Mar 2012

Dec 2009

Building Business Solutions by Ronn Ross and Gladys Lam | book review

2012-03-09T15:15:00.000+11:00

Ron Ross and Gladys Lam have written an important book for the business analyst community.

It aims to get business analysts out of the technology ghetto that many of us get stuck in. Regardless of the type of analyst you are, I think it would be worth your time to get your hands on and read this book.

I wrote a book review which you can read at Modern Analyst.

Respect for individuals makes life easier

2012-03-09T07:26:00.001+11:00

Scrum and XP expressly call for respect for people in their value statements, and the Agile Manifesto reminds us that individuals and interactions are of primary importance. How does this affect us on a day to day level?

Yesterday I went to a mandatory EEO briefing session at work. What struck me was how rooted in a Marxist, adversarial world-view our employment law seems to be. Upon further listening and reflection, it seems it is less the law and more management's defensive response to risks and issues highlighted in legislation and case law.

While I am not an expert in the field I have a few ideas I'd like to share.

By respecting people (even annoying people like me) you are able to have open conversations and address issues that otherwise might be deemed risky, and this deferred, hidden and allowed to escalate until they become larger and more difficult to deal with
By putting the manager 'in charge' of dealing with worker issues like discrimination and harassment, the workforce are dis-empowered, leading to a likelihood of issues coming up
By focusing on failure modes (ie what could go wrong), HR policy seems to lead to managers operating out of a fear and compliance mindset rather than one focusing on positive outcomes, which for the most part can be achieved by...
Building a workplace that encourages mutual respect for each other

Respect not only helps us have a workplace free from harassment and discrimination, it also enables us to work more effectively as a team. Rather than some notion of fairness, where everyone must contribute equally, we are more likely to work from a perspective of everyone does their best for the team's interests, and it doesn't matter whether the contribution is equal. (After all, it can't be.) This then saves us time worrying about unequal contributions, the best desks, who gets to work earliest, etc.

I am curious to see what you guys think. What affects do you observe from teams that focus on respect for individuals versus ones where respect is less prominent.

(edit: 2 minutes after hitting 'post' I came across this blog post at Customer Bliss. Worth taking a look.)

Case Study: Improve efficiency through a focus on feedback

2012-03-06T15:07:00.000+11:00

Angela joined a team as a PM where one of the first comments I received from a developer was “The way we work around here is code any old thing and then let the testers tell us how to improve it.” (Little did she know he was a closet TDD advocate!) Quality was notoriously low. The track record for IT projects at this project was so abysmal some executives had wondered aloud whether they should even be doing any, and whether the IT development function should be outsourced entirely.

On a two year software adventure Angela and her team adopted XP coding practices within a scrum framework. It took 6 months from inception to the first roll-out and several moderate bugs were found, and only a handful of bugs of real significance. They were resolved within a week. From that week on the team were able to successfully roll out 36 more releases with only an occasional major defect making it beyond a sprint review. The handful of defects that did emerge were found in UAT within a few hours of exploratory testing.

Angela’s role in this great quality outcome was in enabling the team to pursue the quality standards they wanted to work with and nudging them onward to ever higher standards every now and again. She did this by making the team accountable for their decisions and for the work output and making sure that the many feedback loops built into XP and scrum were effective.

Leaders emerged from within the team that championed quality. They build test suites and brought in automated UI testing tools. Everyone on the team tested rigorously and everyone took ownership of the product and accountability for what they delivered to clients. Angela assisted by coaching the customer on acceptance standards, and ensuring the team got sufficient feedback when a feature was not sufficiently done.

Over time Angela spent less and less time working with the team and more time coaching and mentoring the enterprise clients to the project. While not formally adopting a method like scrum the user community also adopted the principles of short feedback cycles and increased focus to get things done within their operations space. Everyone experienced improved efficiency as a result of a focus on quality via feedback loops. The efficiency win in this case was in the reduced amount of rework, and increased alignment on mutual goals.

Positive Deviance

2012-03-03T15:37:00.001+11:00

Over the years I have seen some tweets and posts with the phrase positive deviance and generally assumed this to mean the variation from normal on the winners side of the bell curve. Yesterday I started reading Rabovich and DeRosa's (Nov 2011) paper "Patterns of Success in Systems Engineering" which prefaces its findings with an explanation of the idea of positive deviance.

While I was on the right track, it turns out that positive deviance has a lot more to it. Positive deviance has a Wikipedia article where you can read about the concept and where it came from. I want to talk about how it is relevant to me and my job. A couple of quick ideas for now. I'll be reading more soon.

Positive deviance and best practices
I rant against best practices every opportunity I can. Apart from the popular notion that best practices are a red herring because there are usually many equally good pathways to a result, it also assumes a best. This leads to the limiting idea that you can't beat the competition, you can only match them.

What if, instead we looked at what the best performers did and tried to emulate the parts that will work in our circumstances. A combination of positive patterns, customised for our situation might give us some sort of real advantage. And what if there were no "best" and instead we always just looked to "better" as our aspirational state.

Positive deviance and lessons learned
Lessons learned so often focus on what went wrong. Our response is usually to try to plug the gaps in our performance. In other contexts we think about improving outcomes by exploiting strengths. Why don't we look to the success patterns and adjust the way we operate to be more like them?

Positive deviance and risk management
Risk management, like our lessons learned example above, tends to focus on avoiding problems. Risk management is a continuing activity with multiple risks constantly adding and subtracting to the net (negative) risk of the project. What if instead of an almost exclusive focus on managing negative risk, we were able to invest in maximising positive risk as well?

My Precious...

2012-03-02T09:00:00.000+11:00

I'm a massive Lord of the Rings fan. Every year, I spend part of my holiday vacation rewatching the 12 hours of the blu-ray extended edition. Yes, I am just that big of a geek.

As much as Gollum has his precious ring, I, too have a precious. Its something that is very dear to me, mostly because of how little of it I have. Most of it each week is taken up with my job (50+), my commute (~10), sleeping (~56) and the rest to my family (basically the weekends). It is time.

The little free time I have usually is spent helping me unwind from all the other things going on in my life. I brew beer, but usually every other month or so. I work on my classic 1965 Ford Mustang (barely drivable since 2003) maybe 3 times per year (which is equal to how many times I take it out for a drive). I blog (you can see what my posting frequency has been like in the last month to see how poorly that has gone). Other than that, and a little web surfing, that's about it.

What you'll notice in there is that there is precious little time in my life for the things that really get me going... ideas. My work provides me the opportunity to do that more than what most people are allowed, but its still not very often. The times I find myself most frustrated with my job is when I realize my outlets for creativity are being stifled in the name of a project deadline or the endless stream of meetings.

My last 3 weeks have been just absolutely insane. No one real big thing has been driving it, but what I thought would be a slowing down, once I got most of my team in place, has really been nothing more than a massive speeding up as I get to do my real job instead of all the additional tasks I've been doing just to keep the wheels from falling off the proverbial car.

Its because of this that the latest entry of Rands in Repose hit so close to home. Let me give you some quotes that really hit home exactly why I feel as I do:

When an engineer becomes a lead or a manager, they create a professional satisfaction gap. They’ve observed this gap long before they became a lead with the question: “What does my boss do all day? I see him running around like something is on fire, but… what does he actually do?” The question gets personal when the now freshly minted manager begins to understand that life as a lead is an endless list of little things that collectively keep you busy, but, in aggregate, don’t feel much like progress. <emphasis mine>

Thing is, it isn't just an engineer who feels this. When I was 'just' a business analyst, putting the last finishing touches on a requirements document prior to sign-off was such an amazing rush. Sitting down for a few hours to really knock the last rough edges off something, coming out with a well-formed, highly-usable set of requirements gave such an amazing sense of accomplishment.

Now, I have an endless parade of meetings, some of which I must be honest and tell you, I don't even know what they are about before I walk into the room. This happened to me twice. Today.

You would not believe how many times your boss has walked into a meeting with absolutely no clue what is supposed to happen during that meeting. Managers have developed aggressive context acquisition skills. They walk into the room and immediately assess whose meeting it is, listen intensely for the first five minutes to figure out why they’re there all, while sporting a well-rehearsed facial expression that conveys to the entire room, “Yes, yes, I certainly know what is going on here”.

The fact that this had happened to me twice on the day I read this article was not lost on me. While its nice to realize that my boss probably suffers from this same affliction, its hard to go from someone who spent his day accomplishing so many things to being the person who helps other people accomplish things all day.

It is Rand's solution that impresses me most... block out time to be creative; to focus on this every single day.

Starting at the beginning of February, I made a change. Each day I blocked off a precious hour to build something.
Every day. One hour. No matter what.
Every day? Yup. Including weekends.
A hour? Yup, 60 full minutes. More if I can afford it.

I cannot tell you what I would give to have an hour a day with zero interruptions to just create. I cannot imagine the number of ideas that have been rolling around in my head for months that would get done. I cannot imagine what amazing development plans I could create for my employees. I cannot imagine what new recommendations for the company would blossom just given that space to soak in fertile soil.

I wish it did not feel like an impossible dream. In the end, the author inspires me, but to what, I cannot say. One of his final thoughts speaks volumes to me, and I hope it does to you as well.

What would you create if you had eight uninterrupted hours - every month?

Agile Documentation

2012-03-01T08:00:00.000+11:00

Last Thursday I pointed you at Scott Ambler's Agile Modelling website.

One of the pages there referred to Agile Documentation. Coincidentally, earlier that day I bumped into an old essay by James Shore on The Art of Agile Documentation. Also coincidentally I was burdened with reading a terrible quality project document the Friday before and am teetering on the brink of creating one myself. (Peer pressure is a terrible thing.)

So this Agile Thursday I thought I would share some links to posts on the topic, starting with James and Scott.

The Art of Agile Documentation by James Shore

James describes the three types of documentation;

Work in progress docs,
Product docs and
Hand-off docs

The Documentation Myth, again by James

This time James flips the typical defensive stance of "Documents are good but conversations are better" and "Good agile teams produce great documentation" by focusing instead on why documents are produced (to provide accessible answers to questions.)

Agile/Lean Documentation by Scott Ambler

Scott writes quite a comprehensive essay discussing the purpose and meaning of documents, motivations and techniques for keeping them lightweight, who should be creating them, the use f templates and the introduction of cruft into documents. It's well worth the read.

The Requirements as Inventory Metaphor by Business Analyst blogger Jon Babcock

JB briefly and concisely discusses the concept of requirements as inventory. I can't write too much to describe it or my description will be longer than his. The topic is an important one to understand and underlies several of the motivations to improve requirements documentation and modelling practices.

Agile Documentation by Scott Selhorst

Scott discusses the idea of iterating documents just like you might iterate your code. Addressed in Scott Ambler's essay, this is an essay exclusively on the topic.

These four sources are a pretty good starter pack that you should be able to digest in an evening. As usual I would really like to hear your feedback or to hear of any other good sources on this topic. Please add your comments.