28 July 2011

A BA's Rules to Software Developers

I respect most developers a lot, mostly because they have a job that I would absolutely hate to even consider doing. Several times in my life, mostly when I was incredibly frustrated at being unable to find an application that did exactly what I needed done, I have attempted to learn how to program. I even went so far as to spend a couple weeks learning VB5 to create an application to store data from an online game I played and it (mostly) worked.

But never could I do that job for a living. Nothing wrong with the job, its just not one that in any way suits me. I understand what developers do, and in some ways I do many of the same things (logically tear apart a problem, take the pieces and form them back into a solution, stare at a monitor all day, etc), but its the writing of the code itself that just bores me to no end.

One of the bloggers I follow, Ben Brooks, recently published a list of rules from users to developers. With that in mind, I humbly submit to my developer friends a list of things that drive me nuts when you do them. These are the rules by which you should live (yeah, the non-dev telling the dev what to do; I know, hubris). Be aware that these rules are for dealing with me, not Joe User, the guy who has trouble finding the power switch on his PC. When you deal with Joe, please feel free to disregard all of what I say below.
  1. Don't tell me it can't be done; I know it can. Yes, it could take a server the size of the moon, more money that Scrooge McDuck has in his vault and a project duration that couldn't be completed before the Sun runs out of hydrogen, but it could be done.
  2. Give me better options. I'm a pretty smart guy (Mensa says so), but if you're a developer, chances are, you're pretty smart, too. I come up with some pretty good ideas and I'm sure you can, too. If your idea is better than mine, I want to hear about it.
  3. If my idea sucks, yours better not. Don't tell me how awful my idea is if you can't come up with a better one. Please note that a 'better one' is not defined as you doing nothing.
  4. Don't lead me down a wrong path intentionally. I once worked with a dev who would explain to me a problem and present two solutions, one obviously bad and one that seemed to work. When I would select the one that seemed to work, he would tell me all the horrible things about the option I selected he intentionally left out the first time. Give me all the information I need to make an informed decision.
  5. Work with me. I value your opinion about technical details, so please value mine about business needs. My job is not to make your life miserable so please don't feel its your job to make my life miserable.
  6. Never tell me the odds (wait, no, that's Han Solo's rule; nevermind.)
  7. Don't become a lone gunman. We're not out to get you nor is everything worthy of a loony conspiracy theory. Yes, it is true, your knowledge will likely be incomplete during the project, but don't fear, so will everyone else's knowledge.
  8. Development is not an end unto itself. Never forget that even if you have perfect architecture, defect free code and standards compliant output, you can still completely fail to provide any business value. You don't have a job to churn out code, you have a job to churn out worthwhile code.
  9. Your opinion is worth just as much as everyone else's (which means not a whole lot). Don't refuse to do something just because you don't like the idea. Refuse to do something because the idea is objectively deficient, not because you just don't like it.
  10. You're not an android so don't think you are the final arbiter of what is logical. You're human and equally as able to suffer emotional pitfalls as the rest of us.
  11. Lastly, don't go rogue. Its one thing to daydream about sending the system down in flames, but its something else to actively pursue that as the goal. If your objections are so serious, get out before you try and sink it like it was the Titanic.

"I've been doing scrum since 1967..."

26 July 2011

How do I manage multiple teams release plans when using story points?

Here are a few thoughts for you.

Story points are abstract. They represent the volume of work in a backlog relative to the capacity of that team. This relativism means that a team’s velocity is constant in its context but not across multiple contexts.

Velocity via story points does not directly enable you to forecast how much work a team can deliver when;

  • They have a different product owner
  • They swap onto different technology
  • When the make-up of the team changes substantially (ie new project teams are formed)
  • For comparing multi team performance
There are some other assumptions that should be addressed when digging into this topic as well.

  • What is the minimum information is required to make project and portfolio decisions?
  • Why are we forecasting and how much accuracy is required?
  • What are the cross team dependencies and why do we need tools to compare productivity?

Once you have thought through these questions you may still need to find a way to normalise team story point velocities. Some ideas are presented below, and they may be useful. If they aren’t you can invent other methods, and of all else fails just go back to estimating in team days.

Workshop norms across teams
Bring people together in small groups to estimate common or similar stories. Have the teams talk about how the new estimates are the same as or different from their team estimates, and why. Talk to the teams about resetting their standards. You can also use this process to induct new agile teams into an estimating standard.

Use reference data
Similar to the above example, but standard stories from various size categories are posted up in everyone’s team area near or where they do their estimates to act as reference points for when the team do their own estimating.

“Let’s see, this sounds like example story C, so I’ll rate this as a 5 pointer.”

This is probably best introduced via an exercise where the goals are explained and some facilitated estimations are done

Simplify your measures
Move away from story points to simpler measures such as S-M-L. It’s easier to compare across teams and it’s proven successful enough in many teams already.

Use regression analysis
Look back and take objective measures of requirements using a standard (e.g. function points, or your own simplified version) and just work out what each team delivers per local story point. Then you have a translator that can help you work out the averages per team.

Forget the abstract and use the release schedule
Most of the time what matters most is integration and dependency between teams. You need to work out when to start team A on an activity to it can be ready for team B to work on a downstream component.
Simply take a look at the release plan and see when things are due to be rolled out. Factor in uncertainty, change your backlog priorities as needed and problem solved.

Have you got any other ideas?  Do you use any of these techniques? Git any suggestions?

25 July 2011

Subconscious Information Processing OR How I Think About Problems

When I was in 8th grade, I participated in an program called Future Problem Solving. Teams from many different schools would gather in a room, the proctors would pass out a short description of a problem and each team would have a couple hours to come up with a set of solutions, weigh pros and cons of each, then recommend a solution for implementation. We would write all of that up into a two page summary, turn it in and wait a couple hours for the grading to come back to see which team won the round.

Given that I'm a Business Analyst by trade, it probably isn't surprising to any of you that I really enjoyed Future Problem Solving.

What had never occurred to me until I started this post is how much the habits I learned doing Future Problem Solving really fit into how I work today. See, what I haven't told you yet is that in the months prior to the sessions, the team was given high-level categories from which our question for the round would be selected. During those intervening weeks, the team spent its time researching and studying anything we could get our hands on about those subjects. I even remember our coach going so far as to figure out ways to get copy protected material that couldn't be sent through a copying machine to work on one anyway, just so we could all share the material.

But after we studied our heads off, we did something interesting... we did nothing. That's right, once we read and memorized all the information we could, we took a break. For the days just prior to the event, we really didn't do that much work. We just let the information percolate in our minds, ideas quietly bouncing off one another, marinating just long enough to produce something of quality.

So when I read about the idea of subconscious information processing, I realized that while the term might be relatively new to me, the concepts went back to some of my oldest memories. I do this all the time, for just about every project. Its routine to hear me say, "That's interesting. I'm not sure what to do with it or how to tackle it, but let me think about it a while and get back to you."

See, I'm all about up front research. Let me give you an example that happened just today. About 7 months ago, when I was given charge of our company's QA functions, I started doing a lot of research about testing processes and automated testing tools. During that research, I ran across the concept of writing software that gathers a large, some might say obscene, amount of metrics data from your application. The idea is to capture and measure everything, then to graph it so people can interpret it easily. When you start, you measure everything you can think of. Then you go back and add the things you never thought of measuring. Once you hit your stride, even modest sized applications can be measuring thousands of data points, everything from user interactions to system performance to usage duration.

I spoke of the idea of using this type of metrics data for an upcoming project, but only dropped the idea to my boss, our VP and one other manager, but I kept the idea in my back pocket all this time, just waiting for the right time to drop it. Today was that day.

Because I had 7 months to plan out how to bring up this idea, I had determined the best way to convince everyone of how useful this would be. Sure enough, as I laid out my vision for usage, everyone in the room was convinced within minutes it was the right approach to take. It was something no one in the room had considered. Most were like me of 7 months ago, they didn't even know that tools existed to do this type of analysis. The team immediately saw its value and started asking what other projects this might be used on!

What made this work, besides it being an idea whose time had come, was that I had done my research and the idea had time to grow in my mind. If someone had come to me 7 months ago and asked how we could better understand what is going on with our application, I would not have had a clue. Even 3-4 months ago, I would not have the full vision of what is now in my head. A year from now, after I've had time to tinker and play around with the ideas, it will be even better.

Its all about subconscious information processing. The idea of a robust analytics suite, not just for business metrics but for system and user metrics as well, was not created by me but it was one whose time has come for our organization. As I've been saying for months to anyone who will listen, "if we keep doing things the way we do them now, we'll continue to fail in the same ways." Its not that we fail a lot or fail badly, but everyone fails at some point. Keeping to the same processes only ensures that you'll continue to fail in the same way.

So what ideas have been rolling around in your head? Drop them in the comments for us all to spend a little time performing a little subconscious information processing on them!

(BTW, I am considering writing up an eBook on my experiences with what I'm tentatively calling "Metrics-driven Analysis" so everyone can understand the vision I outlined to the team, along with details on how to determine what metrics to track. Anyone interested in this?)

New job

Today I started the second of two new jobs. (Do I have a focus problem?)

The job I started last week is as an 'Agile trainer' at Telstra.

I signed up because I want to see what this ambitious change program looks like from the inside, and because it will be an amazing win for the community of web and phone users in Australia if it comes off.  My part in the process is small, but it's a great initiative and exciting to be a part of it.

The job I started today is as the 'head of project management and assurance' at Swinburne University.

I signed on there because I wanted to test my mettle against portfolio and line management.  I also wanted to work in an industry that is contributing to the community is a positive way.  Education fits that criteria pretty well for me.  Again, an exciting opportunity.

This is on the back of a very very busy 9 months as a consultant where I did everything from practice consulting, product visioning and enterprise architecture.  I'm glad I did the consulting work, but I'll also be glad to leave the hectic pace behind me for a while. (Not that the new job will be a walk in the park.)

As I start this new role I am trying to discipline myself to shut up and pay attention to what's going on rather than jump in screaming "let's get lean! Let's get agile!" from the rafters.  There is nothing worse in the new guy than a problem looking for a solution, right?

What you might do for me is point me to any good posts on being the new guy on the team and how to identify and implement the right approach to changes.

19 July 2011

Innovating Requirements in the Office

My last couple posts have talked about what innovation is and is not, from a fairly high level. Before you asked, yes, I do know this is a blog about projects. :) While both of these posts were somewhat relieving an annoying itch that had been bothering me for some time, it also was setting the stage for this post and the one after it that will discuss innovation in the work of a business analyst and in business analysis.

Today we are going to discuss the work of a business analyst. Having been doing this for a decade now, I have to say, in most ways, the job really hasn't changed. People have problems or have recognized opportunities, they bring these to me and expect miracles to be done, all before lunchtime. Sure, the last decade has seen my accuracy in requirements elicitation and analysis increase dramatically (I still shudder at some of those early requirements) along with my ability to document those requirements and relate them back to my stakeholders.

But that, frankly, isn't innovation. That's process improvement. This isn't a bad thing in and of itself, but it has its limits. If it takes me 2 weeks to elicit requirements for a medium sized project, with enough business and technical knowledge, I could maybe shave a few days off that timeframe, but its not likely I could decrease it to mere hours. There are just too many things outside my own control to make that happen.

Similarly, given enough knowledge and forethought, I could probably increase my accuracy in requirements analysis several percentage points. This suffers from the law of diminishing returns; the more accurate I want to get, the longer its likely to take me to get there. At some point, its probably better to go with what we know now and adjust later than it is to hold up resources who are waiting on work.

So how do I innovate in my job as a business analyst?

First, you have to realize that you do need to innovate. Staying the same really isn't an option. I'm not suggesting you go out and create a whole new methodology, but maybe its time to add into the mix segments from other methodologies into your own personal work. For example, even though you may work in an organization that is purely waterfall, maybe your run your tasks in an agile manner. Maybe you pick a backlog of tasks for the next 2 weeks, create a stack of those and then have your own, personal stand-up at your desk every morning. Work through the items, see what you've accomplished, decide on what you'll do today and figure out if you need to escalate anything.

On the surface, that probably sounds like looking at your to-do list as soon as you sit down in the morning. Truth be told, you're probably right in that assessment. The difference is that you're doing it deliberately now instead of just because you have to. You are adding an element of planning and forethought to a process that was formerly ad-hoc. Doing this may help you flush out ways in which you were previously unproductive, just because you took a little time to organize what you did naturally.

Next, add something totally new to the mix. Have you been focused on large requirements documents with lengthy implementation details included in them? Grab Visio and create a process flow instead. How about creating some wireframes and using them to help your stakeholders visualize requirements before they attempt to put them into words.

Now get rid of something; the more painful the better. The best thing to get rid of is email. I'm not an email hater, but its so convenient that sometimes we lose ourselves in it. Declare an email bankruptcy, wipe the inbox clean and start again. Let your stakeholders know that you're doing this and that if they need you to respond to something they sent within the last week, they need to do so again. Stop replying to every email just so they all know you're out here working for them.

Lastly, produce something. Do it early and often. Don't wait till its perfect to put it out there. Create a rough draft, something that has all the right ideas (and maybe a few wrong ones) and push it out for review in hopes that it creates at least one new spark of information in your reviewers. That one great idea may come out of being utterly disgusted with all the bad ones that rough draft contained.

There is a lot of risk in what I'm outlining here. I don't deny that; in fact, I'm glad of it. Many of us (myself included) work for organizations that have well established processes in place for good reasons, but we often (myself included) forget why the processes are there. They were put in place to fix a problem in the past, not in order to create a better future. Sometimes the world changes, and that rule that worked so well 10 years ago is hampering our ability to grow.

Embrace innovation in your job. Do it today.

13 July 2011

Balanced Anarchy

How many perspectives can you handle at once?

11 July 2011

What 'Innovation' Does Mean

Last week, I did a post that catalogued a list of things innovation is not. I put this list together for two reasons: first, you hear all the time about what innovation is, but rarely about what its not. Second, having recently been asked by someone to 'get creative' when, if you know any thing about my work at all, I generally have to reign in my creativity for most people to keep up. Its not that I'm some genius (ok, I am, but lets leave my Mensa paperwork out of this), but I do get a lot of ideas. Most of them (ok, nearly all of them) suck, but on occasion, just like the picture to the right, one of them works. It may be the wonky one that fell over, but it does work.

With that in mind, I sat down and thought about what I really believe innovation is and does. As you'll see from my list and short descriptions for each item, being and doing are inseparable when it comes to innovation. So without further adieu, here is the list. Read it, then go out and do it. I'll do the same.


...must be nurtured. If you're not feeding it constantly, like one of those tamagotchi that were so popular in the 1990s, it will die. You can't ignore it. It is like that unruly child that needs more time than you think you have to give it.

...thrives on new experiences. You can't sequester it in a dark room (or a carpeted cubicle) and expect it to produce miracles. No, surfing the web is not a (good) substitute for experiences. It needs to be around others who can provide it with new stimuli. Consider it your inner toddler.

...is equal parts creation and destruction. Remember that project you did that rewrote your company's mission critical application from a mainframe dinosaur into a web-based cyborg? Remember that row of old gray-beards that soon found themselves out of a job once the power switch was flipped into the off position on those old green-screens? They were yesterday's innovators. You are today's innovator and some day soon, you'll have that gray beard when the next technology revolution occurs. Your innovation today was creative for you, but destructive to someone else's world. That isn't a warning that you shouldn't innovate, only to be aware of the consequences of your innovation.

...is disruptive. It breaks up the status quo. It turns the world upside down. It knocks people down. It uses lots of overused cliches (not really; just making sure you're paying attention). When innovation happens, people either change with it or they don't. Processes, technology and products fare no better than people.

...is more than just about product; it is also about process, form and service. Sure, we all hear innovation and think about the new, shiny product from Apple, but sometimes that product isn't something that's tangible. Innovation in process changes the way people work and play. Innovation in form changes the way we interact with the world around us. Innovation in service changes our relationship with people and organizations.

...produces. Ideas are not innovative. Innovation contains ideas, but is not just an idea. If you're innovative, you produce and do so in abundance. You can have the best idea in the world, but until someone actually can use or follow it, it isn't innovative. A person with a good idea for a movie is not an award-winning director or producer; they're just a person with an idea.

...leads to growth, but growth does not always lead to innovation. This one is tricky. When you innovate, you are specifically, intentionally, doing something that is better and different than anyone else. You will, sometimes organically and other times with a little marketing help, draw people to you simply because of what you're doing. This leads to growth, and as more people become aware of what you're doing, to more growth. But just because you're growing, does not mean you are in any way innovating. Your one, original great implementation may be stagnant for years while people slowly become aware of how great it is, but it doesn't mean any of the dozens of ideas you've had since then are in any way innovative.

...builds upon prior innovation. Innovation isn't a lightning strike (at least not usually); its more of a slow boil (usually). Innovation takes innovations of the past, tweaks them, recombines them with different innovations and creates something novel and useful. Don't worry that your innovation is nothing more than a compilation of stuff other people thought of; that's exactly what those other people's innovations were as well.

...embraces failures, both of commission and omission. There are two ways to fail: doing something and it failing or not doing anything and failing. If you build something novel, but not useful, its probably going to fail (commission). If you had the idea but implemented nothing while someone else had the same idea, implemented it and succeeded, you also failed (omission). Both processes teach you something. The first teaches you not everything is really innovative. The second teaches you to seize when it comes to you; not to wait for someone else to create it first.

...is hard. Not everyone (in fact most people) can be innovative. There are lots of reasons for this. Some people don't give themselves time or space to be innovative. Some don't believe its possible for them. Others blame someone else's stifling influence on their own failure to innovate. There are as many reasons as there are people on this planet (and probably quite a few more) to not be innovative. In the end, innovation is about choice. If you set out to be innovative, I can't guarantee it will happen. I can guarantee you won't be innovative if you choose to not be innovative.

What about you? What is on your list of ways to be innovative?

9 July 2011

Cultural impact of Kanban

Ian Carroll a UK based Kanban and Agile coach has walked around and collected video feedback from team mates and stakeholders on the impact of a Kanban implementation.  It's an interesting 2 minute meander through various people's experiences.

Cultural Impact of Kanban from Ian Carroll on Vimeo.

6 July 2011

The Speedboat Game (from Innovation Games)

A safe way to discover what customers are dissatisfied with.

What 'Innovation' Doesn't Mean

  • It doesn't mean 'Not Invented Here'
  • It doesn't mean 'New is always better'
  • It doesn't mean 'Build for the sake of building'
  • It doesn't mean 'Winners finish first'
  • It isn't a way to filter good ideas from bad ideas
  • It isn't a way to 'think creatively'
  • It isn't a way to 'think out of the box'
  • It isn't a means to an end
  • It isn't sold by any individual company
  • It isn't the domain of any type of consultant
  • It won't ensure you make money
  • It won't ensure your company or project survives
  • It isn't the birthright of a single country or culture
  • It can't be contained within a pithy slogan or on a t-shirt
  • It isn't housed in the private conference center across town
  • It isn't something that is for sale on an eCommerce site
  • It isn't something you can find on amazon.com
  • It can't be mandated by management
  • It can't be put on a schedule
  • It can't be bought
  • It isn't measured by patent filings
It really irks me, if you didn't realize it by now, when someone tells me to 'get creative' or 'be innovative'. It isn't a light switch. I wasn't being not-innovative yesterday and suddenly decided, because you told me to, to be innovative today. I'll be doing another one of these lists, hopefully soon, about what innovation really is. Stay tuned.

5 July 2011

Minimally Viable... Project?

As I'm checking through my news feed, I ran across this great post from 37signals about what happens to user experience in a minimally viable product. This started me thinking... what would constitute a minimally viable project? Before we dig into that idea, what is a minimally viable product?
MVP, if you aren’t familiar, is an idea from the Lean Startup scene. In a nutshell, it means to do as little as possible so you can learn if you did the right thing or not. 
The first thing that comes to my mind about running a minimally viable project (I'll refer to it as MVP from here on out, so don't confuse it with MVP from the quote) is scarcity. This isn't with a 'do more with less' management BS, but just an acknowledgement that the resources and ideas you do have are precious and should in no way be taken for granted. Lean Startups usually have very little money, and thus very little time, to create their product and get just enough customers to survive until the next round of funding comes in or until you get enough paying customers to sustain your company.

Sometimes projects start out with a surplus of resources, all of which are the wrong kind. When you're trying to figure out what needs to be done, projects often suffer from a too many hands in the cookie jar syndrome. The opening in the jar, our project funnel, can only support so many people reaching into it at one time before fighting begins. In this situation, cookies may be in plentiful supply, if the jar is large enough, but cookie access is scarce. The more hands trying to access, the more scarce will be cookies outside the jar due to hands getting in each other's way.

Starting an MVP requires having the minimum number of right resources to get the project off the ground. Any more or less of the wrong kind of resource and you are failing either the 'minimum' or the 'viable' part.

Another part of the Lean Startup process is a focus on using the tools you have available. Because of funding restraints, these usually end up being free, open-source software that the startup can acquire with little to no cost and can modify in any way they please. You don't necessarily have the tool that is perfect for just what you're trying to build, but you have tools that are good enough to get the job done now.

How many times have we waiting around to start a project because some piece of infrastructure or specific resources were unavailable? How frustrated did that make you? Yes, as I pointed out in the prior section, resource scarcity is a reality, but when you're in an MVP situation, you do not let yourself be hindered by the lack of that exactly perfect resource. You do without, knowing that at some point you will likely have to scrap much of what you've done anyway. Why would you end up tossing what you've done away? That's where we come to point #3 in the Lean startup.

Lean startups are all about iteration. The idea is to release quickly and often, get your customer's feedback on what you've done and then make it better at such a rapid pace that before they can get bored with what you're doing and move on. You constantly engage them with just enough progress that they stick around.

One of the things that often frustrates me is walking into a requirements review session knowing that its going to be two weeks until I see the revised document from the analyst. Yes, watching someone who is not computer savvy (or using a bad requirements management tool) attempt to update a document in real time during a meeting can be the definition of painful. When you're with an analyst who can fly through the changes, its amazing how seeing the final revision take shape in front of your eyes changes your entire outlook on the project.

Does your organization practice MVP? Do you think its something that sounds nice but is best left to the realm of the lean startup? Let us know in the comments.

1 July 2011

Trojan Consultants

Found in this week's issue of The New Yorker. It made me laugh and I just had to share.