28 March 2012

On the Community of Practice

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.

27 March 2012

On Guilds in Modern Times

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;

  1. 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? 
  2. 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

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


  • 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


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

Related topics

  • Cumulative Flow Diagrams
  • Release plans
  • Earned Value Management
  • Product road maps
  • Gantt charts

Further reading

22 March 2012

A User Story is just like a support ticket

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

20 March 2012

Four schools of Business Analysis: Mastery versus breadth

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


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

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

Mar 2012

Dec 2009

9 March 2012

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

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

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

6 March 2012

Case Study: Improve efficiency through a focus on feedback

Sydney George Street Looking South

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.

3 March 2012

Positive Deviance

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?

2 March 2012

My Precious...

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?

1 March 2012

Agile Documentation

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; 
      1. Work in progress docs, 
      2. Product docs and  
      3. 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.