BPMN and User Stories

After a couple of years of project starts and stops that reflected a lack of common direction at my current employer (that was and is an otherwise great place to work), the last several months has seen a changing of the guard up and down the organisation such that an new direction is now agreed on.

For me, that means actual projects that are seen to produce results. One of the new direction's impacts is to use agile development on as many projects as possible, as preached by our new PMO manager. My question on agile has always been: where does the backlog come from? If creating a new product of some sort, then it is the vision of the product owner that gets you started and evolves over time.

But what about 'run the business' projects? Changes to existing process? How do you know what to work on?

The answer  is what I call 'agile in context'. The context is the business processes of the organisation, and I mean all of them as defined in a process architecture. Before agile development,  a project is scoped by identifying what processes are impacted (given business objectives drawn from overall strategy). The main steps are to
(1) identify process experts in the business
(2) assign a business analyst  to work with the experts to first document the as-is process at a task level (we use BPMN 2.0 for consistent modelling approach), then
(3) define the changes needed to create a to-be process
(4) examine all the changed and new tasks to determine if they need automation
(5) define the functions being automated for each task
(6) write the functions as user stories

Voila, a set of user stories to put in the backlog. Given access top those experts (and that is crucial), the above steps take 2 to 4 weeks for a typical project.

There are other aspects of the project that are needed, like the overall systems architecture to support the functions/stories, maybe some data modelling for new/changed data, technical stories for whatever the system architect says is needed...

But all those things support the project in delivering the value of the function-based user stories. Given a backlog, use the methodology of your choice (ours is Scrum) to define the number of sprints, allocating stories to sprints, running sprints to build a solution(s), add/adjust stories based on results, etc. etc. The known value then is that agile delivers results much faster than other approaches

Over the years most of what I have read about agile was (1) focused on what happens once the backlog exists, but that (2) you didn't do requirements, like in the form of BRD, always presented as too big, too costly, and wrong once you start development. Fine, but what did you do to get the backlog, the things that a solution is 'required' to do? How can be your sure you don't build the wrong solution?

Placing agile in context of an organisation's processes answers that question. The above approach to create a backlog is straight-forward and repeatable. I have now finished one of these projects, with six 2 week sprints; previously it would have been expected such a project would take three times longer. Now I am starting process modelling on two more projects and advising on three others. Prognosis for those projects is also good.

So after years (decades) of being against or on the fence, I am now all-in for agile development, in context.

Thoughts, anyone? comments welcome.

What is new in Business Analysis and Requirements Methods?

For many, many years I have used all available sources to keep up to date on what I do as a profession. Back in the day, I would read good old paper magazines being circulated in offices I worked in, venerable publications like ComputerWorld, Datamation, and Information Week. As the internet grew, the sources became websites and email newsletters, then blog postings by noted writers, followed by distribution through twitter and its accumulator services like paper.li.

But lately I find my sources are repeating the same topics over and over again; Agile, BPMN, Use Cases versus User Stories, etc.. Have we climbed on to a plateau of methods and methodologies? When was the last thing to come out that made a difference in the way Business Analysts provide better results?

My focus for a long time has been Requirements, their discovery, documentation, and use in delivering solutions. At least a decade ago I wrote posts on what combination of requirements techniques have worked best for me; I have seen nothing since then to change or add to that set of techniques.

I am trying to decide if this is a good or bad thing. I do miss the days of exploring new approaches, all the way from Structured Analysis & Design, through to Business Rules Management. I like to think my attention span is not that short, but I ask "What's next?".

Now, I will not say that having a stable set of techniques is a panacea for Business Analysts working today; getting opportunities to use them effectively is still as much a challenge as it has ever been. When I do get that opportunity, the work is still as fulfilling as ever.

But still: What's next?

The practical realities of software estimation

A great post from Scott Ambler about estimation. I ask a question, of course...

http://www.disciplinedagiledelivery.com/software-guesstimation/#comment-21334

What is a requirement? Well, what kind?

From discussion on linkedin

"What are requirements"

https://www.linkedin.com/grp/post/128312-6019368539587121153

My comment:

A lot of comments already, have not read all of them, but i think the question is too wide. We need some adjectives in front of "requirement". I don't necessarily like all of them myself, but I offer up the ones I hear most: business, process, functional, non-functional , solution, system, even testing. 
I think what most comments here are speaking to is the functional requirement. While precise wording can vary, I hold that the definition must emphasize the concept of "what, not how". I like Jose Santos version, but would shorten it to "A software requirement describes what a software should do but not how to do it, and it satisfies a need." I also like where commentators use the term "future". Certainly a requirement stated now implies a future state where it is met, but it is good to state/think it instead of assuming the implication.

David Wright

prototyping tools are not new, and may already be hanging on your wall.

linkedin conversation on prototyping

https://www.linkedin.com/grp/post/60878-6021176829337944068

So, key man theory and agile.

Later than I thought, but have always wondered about the Product Manager in the agile approaches that feature the role. They are the go-to person for the rest of the team with questions about what is being delivered, yes? What if that person, for any reason, has to leave the project before it completes? What impact does that have? Or am
I asking a rhetorical question?

Key Man Theory, heard of it?

Sometime in the past decades I read about a management idea called the "Key Man Theory". Of course, I can't recall where and when, but it stuck in my brain ever since. In essence, it states that if the success of your business operation or project is heavily dependent on one person, with unique knowledge or skills, you have a huge risk to mitigate. In less sensitive times someone might ask "what happens to us if Dick (or Jane) walk out of the office and get hit by a bus? are we screwed?". The nicer way of saying it now is "what happens if Dick/Jane win the lottery?". Either way, the risk is the same; things could go bad quickly.

This in the same idea as the financial product called key person insurance, but that may not be what you want to fall back on. It is good to avoid poverty if your business fails, but what if you love your business and want to actually save it? In this case the mitigation techniques are to reduce your dependence on the key man (OK, person) by looking to hire similar people, or start some knowledge transfer from Dick and Jane to other people in the organization. Dick/Jane may not be thrilled with this --- being the key person certainly gives leverage when asking for more money or other things --- but you have to do something about this situation; being empathetic and supportive of the key person will help. In the end, when they do leave/retire, they will have felt valued and may have enjoyed passing on their knowledge to the younger folk..


 So, I was drafting some thoughts on another post to come, which refers to the theory.  I thought I would make use of web searches to find some source info or references to use and, to my surprise, my searches found nothing... nada.  So question for everyone: do you remember 'Key Man Theory'? And if so, do you know what happened to it?

What to do when you see bad methods...

... and can't convince people of it.

I have had this experience a few times, and I have thought long and hard about writing about it.I still don't want to get into details, the old "if you can't say something good..." situation. But the possibility of it happening starts with joining a project already underway and the methods have already been chosen. When I first see something troublesome, I might nicely say something like "this is a bit different, how did come to be used?" The worst answer is "that's how we have always done it", and I really have to shut my mouth before reflexively responding "and how's that been working for ya?" ala Dr Phil.

I won't jump ship because of this (new ships not always passing by), so I make the effort. The real problem comes when you see that using the bad method(s) will make you produce bad or late deliverables. The worst response in this case is "Work harder, Work overtime, etc" because that is what always has happened, so it is seen as the norm for doing projects. Even if what you do eventually produce results in buggy systems and missing functionality, so that the change log balloons, that is also seen as the norm.

My personal problem is that I know it does not have to be this way, so it is tough to continue working to the 'norm'. If you are lucky, some project goes so awry enough that 'lessons learned' are considered; that's when you might have chance to suggest improvements.If not, I start considering my options for moving to a (hopefully) better situation. This could be within the organization if it is big enough, but leaving the org might be what is needed in order to join a better environment.

Anyone want to offer their similar experiences as comments?