Is Agile All That and a Bag of Potato Chips?

Pardon the title to this post, a reference to the Austin Powers movie series, but its a question that has been on my mind a lot recently. Unlike Craig, our resident agile master, my career has been fairly sequestered in waterfall land. Its not that I haven't liked what I've read about agile; its just that no company I've ever worked for has ever done a real agile project.

Sure, some of those companies have claimed to run an agile project or two, but when the daily scrum consists of only managers through VPs and last over an hour, I can't help but laugh at the absurdity of calling that agile. That's simply a waterfall meeting with a new name so it sounds like you're doing something new and important.

When I read an article on requirementsnetwork.com about the impacts on business analysis when moving to agile, it really struck a chord with me, especially given the project I started last week. Our VP came to a group of us: a director, a manager, a supervisor (me), an architect and a contract developer, asking us if we could set up an entire new platform and have it in use by the end of the year. It was a bit daunting at first, especially if you had seen the features list, but our response was agile, even if we didn't think about it at the time.

Putting a Plan Together

First up, we took the functionality list and broke it down by user groups. Then we determined which features would provide the most benefit to our user group. We decided to focus on two specific requirements, plus the underlying architecture, as these features would stop a decent number of calls from landing in our call center.

At this point, I, as the representative for the product owner, sat down with a few of my stakeholders to figure out exactly how these features should work. I put together a small simulation, using Serena Prototype Composer, on day two and then brought my stakeholders down on day three to review. One stakeholder really liked it and the second thought I only got it half right. Back to work on day four, making modifications to the simulation to meet everyone's needs. At the end of day four, the simulation went over to the architect and developer for creation.

Day five is where it really got interesting... they finished the UI. In one day. Now, there were no business rules behind the UI and no service had been created to do the data updates in the back end system, but all of the necessary user elements were in place. Usually after I finish a requirements document, its months if not more than a year before I ever see the first actual working application.

This left me in a weird place... the developers had finished the UI layout, yet I had no business rules or requirements finalized. I didn't even have much in the way of analysis done. The next couple of days saw me spending every moment of time not already allocated to other projects in search of rule, requirements and a UI theme.

Now, its all been turned over to the developers. If the progress thus far is any indication, we'll meet the end of the year deadline. No, we're not doing a formal daily scrum, but we are keeping in touch on a daily basis as questions arise. Its been fun. Hopefully soon I'll be able to update everyone on how the project went and if our stealth agile experience was a success or not.

Awesome failures

The other day we sat down to lunch with Roy Osherove and listened to his NDC talk on Code Leaders and Beautiful Teams.

The talk began with an anecdote where he is hired because he is awesome, but precisely because he is awesome he holds on to problems and fails to get help when needed.

I do that. Not to the extent that he does (listen to the talk) but sufficiently that my week or even weeks become difficulty for m and risk is introduced to the project.

Leaders are particularly vulnerable to holding onto a problem and not seeking help. Hell, we’re leaders right? We are expected to sort things out effortlessly and swiftly.

Of course we are people too. Where we are different is that we often operate solo and don’t have that voice of sanity telling us that we need to get help, that the challenge in front of us is too big for us alone, or that we are gradually being overwhelmed by a thousand incremental new tasks.

What to do? Recognise the potential for the problem. Find the partner on your team who will keep checking you, and have the conversation with them today.

What? There is no-one? Actually there’s a whole team of people willing to help you, just over the office divider

Business Analysis through Improvisation - part 3

Here is part 3 of Jonathan 'Kupe' Kupersmith's Business Analysis through Improvisation session during the September 2010 chapter meeting of the Louisville IIBA. Check out part 1 and part 2 before viewing the below clip!

The Requirements Doc for Gmail

Huge email inboxes, lots of fancy features, minimalist interface... these are things that we Gmail users seem to take for granted anymore. Considering that it was produced by what was at the time primarily a search and ad serving company, it seems strange that it was so good on the first try. For years, email clients, especially web-based email clients, had frustrated me with their limited, often broken, functionality and their incredibly small inbox sizes. 10MB? That's it? My hard drive at the time Gmail was released was 50GB! I know drive space isn't cheap when you're talking terabytes, but neither is bandwidth and these email providers don't seem to have any problem providing plenty of that.

There are several things about Gmail that instantly drew me to the service (as soon as I could get an invite that is). First, the 1GB of storage was amazing. No longer did I need fear hard drive failure and losing all my important email. Second, conversational email, where all messages in a single thread were combined, was amazing. No longer did I have to search through a large inbox to find related messages. Lastly, and probably most important, was searching. Filing email into folders always seemed absurd to me, but searching my mail history ended up being a perfect solution for me.

When Gmail was release, not all was roses; there were several criticisms leveled at the service, the most loudly voiced one was that the ad content displayed inside Gmail were selected based on the contents of your email. This criticism always struck me as a bit silly because email is transmitted across unsecured network connections and passes through multiple servers on the way to and from my inbox. Email has always been readable by anyone who wants to do so.

Nice history lesson you say, but what about that requirements document I mentioned in the title of this post? Like most things Google, it was likely very simple. I expect it grew out of a frustration with existing email clients and their limitations. This frustration likely led to two of the key features, email search and threaded conversations. But what about the huge storage space? How did this feature, which had been frustrating with existing providers, end up into the mix? It doesn't seem really obvious at first, until you remember Google wasn't providing Gmail out of the kindness of their heart... they had to make back a return on their investment.

Lets look at email usage around the time Gmail was introduced. At this time, it was popular to forward a large number of 'junk' emails of funny cats, videos and other large files as a means of sharing with your friends. Usually these emails were often half a MB or larger, so 20 of them would overflow an email box quickly. As useless as I felt these emails to be, they did reveal a lot about the person who sent them and often something about the recipient as well.

That history of sent and received email, especially when viewed over a long period of time, can be an excellent predictor of not only what a person currently likes, but of what they could be interested in when compared against users with similar conversations. This is a treasure trove for marketers because it contains data not just on a user's stated opinions but also on their actual behavior.

Without the large storage capacity, 20 garbage forwards could wipe out all of that customer information contained within that long email history. For Gmail to be successful as a platform for serving ads, for advertisers to truly know they're correctly targeting their ad buys, there had to be a great deal of data on each customer.

That brings us to the requirements document once again... it looks to have contained three items, two that greatly benefited users and one that benefited users and marketers. Over the last six and a half years since Gmail's introduction, it has proved itself to be one of Google's most successful products. If only we could all have the opportunity to elicit requirements that are so straightforward and so valuable.

Getting there

What's the difference between you and the other guys?

It's the fact that you are continually looking for new ways to do your job better and to help the people around you do better. There is always someone around with more experience nad better knowledge, but ther are also plenty of people you cna share, coach and help.

Unless you are standing still, in which case the rest of the world will pass you by.

Learning is exciting for some of us, and for others it's a chore. How do we help others pick up the desire to stretch themselves, even just a little bit?

Try starting with a conversation. Every little bit counts.

Business Analysis through Improvisation - part 2

Here is part 2 of Jonathan 'Kupe' Kupersmith's Business Analysis through Improvisation session during the September 2010 chapter meeting of the Louisville IIBA. Check out part 1 before viewing the below clip!

Does certification change the way you operate?

Yes, Another #pmp #cbap certification post!

To get a PMP or CBAP you have to have a couple of years practical experience managing projects. By then many practices and techniques are entrenched as habits almost. ANd to get to the point where you are eligible for the certification you have probably learned that project management works for you as a career choice.

So here is my question: Does studying for and passing the PMP certification change the way you do business? Does it improve your performance?

Anyone got any stories of substantial changes?

A note to my team

Here is a  note I published to my team about a year ago.  Maybe it's of interest.

For the most part the paperwork we use on our team is focused around quality management.


We have PBI QA checklists, SBI checklists, soon we'll have a sprint plan QA checklist, and maybe a QA checklist for accepting PBIs into sprint planning.


We also have some paperwork around the eCAB process to give confidence to IT that we are not cowboys deploying any old thing.


These internal artefacts - the QA checklists and related pieces are there to support you in getting as close to the right solution first time around.


One day we may abandon some or all of these paper practices, but not until we can all demonstrate reliable on-time delivery of consistently high quality outputs.


In the meantime, look at the QA sheets as tools to help you do a better job. If you can, improve them as we go.

Things changed, but that was a message that was important at one time for this team.

Doctor me?

I am planning to commence a doctoral degree and am thinking about how to structure it to be as easy and useful as possible.

The topic area I which to explore is project management, as a subset of management. The Project Management literature is, like management, full of differing opinions on what’s right and suspect truisms. While it may change, my current intention is to analyse the quality of current theory underpinning ‘best practice’ as proscribed by organizations such as the Project Management Institute (PMI) and the Office of Government and Commerce (OGC) and the US Department of Defence (US DoD).

My early analysis model (as in what I have been mulling over the last few weeks) could be simply represented as a table and potentially published as a wiki or similar online resource for practitioners. Maybe it could be something I could product-ize and sell?

I have the idea of something like a table where columns represent the packets of theory as related to practice areas and rows represent the spectrum of theory from the current dominant paradigm (say the top row) to a an opposite or divergent one and at this stage I am guessing that there is some sort of consistent scale I could use like maybe the age or size of the host organization, or the control mechanisms used within an organization, or even market dynamism. But at this stage, I really don’t know and this neat presentation idea may go out the window.

What do you think? Any suggestions? Anything you’d like to see researched?

Continuous improvement

“The most powerful force in the universe is compound interest”

Apply that to personal and team improvements. Do it regularly and do it often.

What are you improving this week?

A few weeks ago we tried the approach of “what can we take away” from our day to day processes. It made the team focus on bureaucratic and low value work and challenge whether it was necessary.

Improvements aren’t always gained by adding things.

How Will You Measure Your Life?

"Knowing what tools to wield to elicit the needed cooperation is a critical managerial skill." 

In an HBR article entitled How Will You Measure Your Life? Clayton M. Christensen describes models he uses to manage his life. His three main goals; to find happiness in his work life, to ensure family relationships prosper and to stay out of jail.

Along the way he raises this model for managing organisational conflict; Agree on what is important, and agree on how to get there. It struck me that there may be something in there for managing project teams and stakeholders.

What do you do if people disagree on what the project’s goal is?

There are probably many answers and I’d love to hear your suggestions, but the first thing that came to mind was the ‘selling the vision’ work we often speak about.

And what do you do if people disagree on the path?  Again, my mind leapt to a fairly simple answer; coach people. Is there a better way?

'Kupe' on Business Analysis through Improvisation - part 1

Jonathan 'Kupe' Kupersmith of B2T Training presented his discussion of Business Analysis through Improvisation at the Louisville IIBA's September Chapter meeting. When I'm not at my day job or writing here for BetterProjects, I moonlight as the VP of Marketing and Communication for the Louisville IIBA chapter. It was a great opportunity for our small but growing chapter to have a speaker of Kupe's caliber present and we were so glad to have him come to town and share with us.

One of the things Kupe and I worked out prior to the meeting was that he was willing to let me record the whole thing and post it out on YouTube. I brought along my Flip HD and iPhone 4 to capture video for the evening and spent some time with iMovie editing it all together. Over the next few weeks, I'll be posting segments from Kupe's session for you all to view. This is part 1 of 4 and I hope you all enjoy it as much as we did. Thanks go out to Kupe for bringing his 'A' game!

The video below is of lower quality, but if you click through to YouTube, you can view it in HD.

The A3 Report

TPS reports, courtesy of the movie Office Space, have become nearly a cultural in-joke about useless paperwork for those of us who work in office environments. I recently saw an article that described the A3 technique, which is far from useless. The technique comes from the book Managing to Learn: Using the A3 Management Process by John Shook.


What I really like about this technique is that it seeks to concentrate all the necessary information down into a single piece of paper, albeit a large piece of paper. While the details of issues we face on a daily basis are often extremely complex, the level of detail needed to make an informed decision rarely needs that same complexity. Space is limited, especially if the information is going to be legible, so brevity is a must. Nothing beyond what is necessary is contained within the document.

I also love that this is meant to be ad-hoc. No time is wasted trying to format and 'pretty up' a document that is meant to be used. For those of us who are spelling-challenged and depend upon our word processor's spell-check functions, creating our A3 by hand is especially challenging, but it also forces us to not be so reliant upon technology.

The last thing I really enjoy about this is how visual it is. I've noticed that certain groups of stakeholders, especially those that are not in finance, generally respond better to graphical representations of processes than they do to a large list of textual requirements. This presents the information stakeholders need in a format that works well for most of them.

What about you? Could you use A3 in your projects?

Utility and Strategy (and the stuff in between)

Martin Fowler blogged a while back on a project dichotomy of strategic or utility. Not bad for a code monkey, although I prefer the model which splits projects into three categories;

• Run the business
• Grow the business
• Change the business

The idea is that strategic projects are more risk tolerant and higher stake than utility projects and should thus be run differently. This idea makes a huge amount of sense.

And this is why the project management office has been introduced into many organizations and why so many important application development projects are run outside of the IT department.

This is the standard operating mode for most of the ‘strategic’ projects I have worked on. The IT department is good for many things. IT is a competitive advantage for many organizations, but not for all.

Project leaders are used to working to the agendas of multiple stakeholders, but at the end of the day they’ll follow their incentives. If you want your strategic project to be run to the IT dept’s agenda, run it from there. If you want a broader perspective bring it into a PMO or report into a C level with the right spread of authority.

Traits Great Business Analysts Share

Quora recently asked What innate traits do great Internet product leaders share? As I read the list, I realized that these are the same traits shared by great business analysts. I highly recommend reading the response by Chris Wetherel, the first in the list, as its a great post. There are a few that I would add though.

• Planning = Its one thing to have the skills to produce a great requirements document and something completely different to be able to plan for putting together the document, assigning out which resources will pull together which portions, to identify stakeholders, plan review sessions and achieve sign-off. Great analysts think not only about doing the task, but about what it takes to get the task done and how to best approach the tasks that are not yet on anyone else's horizons.
• Flexibility = Despite our best plans, projects never actually go according to the plan we created at the beginning of the cycle. We must be able to adapt and to do so faster than anyone else around us. We cannot afford to be the one the rest of the project is waiting on to get our act together.
• Value-adding = People see the value in developers; if they were not there no software would be produced. People see the value in business users; if they didn't exist, none of the actual work of the business would get done. Business analysts are what I refer to as 'friction reducers' as we enable the speed of projects to increase and to provide processes and tools that in turn allow the business itself to speed up.

I'm sure there is a similar list for PMs as well as BAs. What do you all think? What are the great traits you see for project professionals?

Taming Change with Portfolio Management

It’s taken me three months to read Taming Change partly because it’s so dammed good. I started it at the same time as three other (fiction) books and after chapter one decided that what this book had was so important for me it needed proper attention and I should read it once I got the other books out of the way.

The readership of this blog mostly comprises of four different career tracks.  I am going to give you a brief summary of the contents of the book and then give each of you a reason why you should buy Taming Change with Portfolio Management and read it now.

Taming Change is about portfolio management. It’s focus is at a level higher than project and program portfolio. The portfolios here are at the highest level of the organization, but the principles apply to any level of the organization you care to attack. You have portfolios of products, people, processes, programs, business units and more.

The authors understand that what you can or can’t do depends on your current capability and that your planning needs to fit those constraints.  It’s well informed by a deep body of work with many US firms and academic research, although it doesn’t read like an academic text. In fact it does read very much as a text book, but in a topic that isn’t really taught anywhere at the moment except in real business contexts. And by calling it a textbook I am complementing its comprehensiveness.

If you read and apply the knowledge in this you have a playbook for strategic management of any enterprise. (Of course experience with people also matters.)

One of the great things about it is that it isn’t all ‘theoretical’ what you should do stuff. It’s full of practical activities that you can execute at both the strategic and tactical levels. This is great because it’s clearly a problem for many organizations that strategic vision and implementation aren’t integrated and working together.

Why this book is something you should buy and read.

Consultants
If you already have a framework for strategic planning and performance management this provides an excellent alternative model for you to expand your current offering. No matter how formed your existing framework is, this one will have something new that you can draw on.

Project and Program Managers
Project and program managers operate within certain contexts. Often a badly famed project idea or a project that isn’t aligned to the big picture is more trouble than it’s worth. By understanding the larger picture and how your project fits in you get to know how to kill a bad project early, or change it so that it is better able to contribute to the larger game.

You don’t need to read the whole book to figure this out, but let’s face it, you are on a career track that will eventually lead to strategic planning and management at least a program level, so this is still very useful information for a program or project of any size of complexity.

You’ll also get insight into the behaviours of stakeholders and sponsors and why they so often appear to be acting counter to the interests of the project and the organizations they work for, and perhaps you’ll be better equipped to avert crises early.

Business Analysts
Business analysts through their design of business models and the technical architecture of enterprises are key people in the strategic development of an organization. It’s absolutely critical that a serious business analysts understands strategy, how it works and what’s going on in the minds of people at the pointy end of the business. Others may be setting the agenda for enterprise development, but business analysts are the key people to execute the strategic intent into practical
outcomes.

Software developers
Like business analysts, software developers are the people who are building the enterprise for tomorrow. Unlike business analysts Software Developers are often left out of the big picture conversations. The best developers are the one shat understand the business and business models. Context is everything and the higher up the organisational planning pyramid you look the better your work will be. So, coders, invest a few hours into understanding the other side of the business/IT coin and see how you can best contribute to your company’s future.

Disclaimer: I was approached to review this book but have not received any payment for it. Hyperlinks under the book title book in this review are Amazon affiliate links. The opinions are mine, and I wholeheartedly recommend this book.

Partitioning project work

If there is an integration cost associated with partitioning work (Staats, Milkman, Fox 2010) then it’s worth paying attention to the way we breakdown a project’s work.

There are two dominant paradigms that I know of and work with for breaking down work; the WBS and the Product Backlog (prioritised list) but there are also probably others.

Can you help me out by nominating alternate methods for breaking a project’s work down into estimable chunks?

Business analysis tools

In 2007 I came across this resource from the University of Aukland - Situation, Industry and Environmental Analyses, a graduate student resource library.

"This guide is designed to assist you in finding online resources for completing a marketing situation analysis."

I bookmarked it with the intention of going back and reading more.  Frankly, I have never had the time, although it looks promising.

It's oriented to a marketing paradigm which aligns perfectly with the project context, so here it is for you.  I hope someone finds it useful.  If you like what you see there please leave a comment and share with teh rest of us.

Lessons Learned in Projects

While Kevin Kelly's opinions and mine tend to differ on the merits of homeschooling, I have to give the man kudos for the lessons he taught his 8th grade son during a year of homeschooling. The list of lessons learned at the bottom of the article make for fascinating reading, not only for 8th graders, but for those of us who work in projects as well. I would even suggest that a year of homeschooling is a project!

• Every new technology will bite back. The more powerful its gifts, the more powerfully it can be abused. Look for its costs.
• Technologies improve so fast you should postpone getting anything you need until the last second. Get comfortable with the fact that anything you buy is already obsolete.
• Before you can master a device, program or invention, it will be superseded; you will always be a beginner. Get good at it.
• The proper response to a stupid technology is to make a better one, just as the proper response to a stupid idea is not to outlaw it but to replace it with a better idea.
• Every technology is biased by its embedded defaults: what does it assume?
• Find the minimum amount of technology that will maximize your options.

These are lessons I try to instill in my analysts and ones I hope you follow as well. Here are some others that I use as well:

• Documentation is necessary, but you don't have to use it as a club.
• Know who holds power and who holds authority. They are not the same thing.
• In every software release, try to include at least one thing that your users will love you for changing.
• Those new pieces of technology you are continually mastering? Use them as teaching platforms for your users. Cultivate the image of a technology master and people will believe you are a master of other thing as well.