Practical Analyst

Agile Teamwork – what BA’s need to know (Guest Post)

2009-11-04T18:04:04-08:00

I hope you’ll enjoy this guest post (our first ever, actually) by Rowan McCann of Bright Green Projects. - JB

Introduction

Back in the 90’s self-managed teams were all the rage but they had a high rate of failure mainly because team members lacked people skills. These ideas of self-managed teams were borrowed by the Agile movement when in 2001 they formulated a ‘new’ way of working, based on Agile principles. These principles value individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.

For these ideas to work in practice Agile team members must know something about teamwork and this means understanding a lot about human behavior and why people do the things they do!

Agile team members are usually composed of highly skilled knowledge workers with strong values of Independence. Some are worth more to an organization than the people who manage them! Many software developers are quite introverted, preferring to interact with their computers rather than people. My own IT degree course hardly spent any time on people skills and nothing on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team. I’ve had to learn this in the world of experience. I wonder how many readers find themselves in a similar position?

If you look at the Agile web space you’ll find that the emphasis is on ‘engineering best practice’ and tasks, rather than team processes. Many project managers, too, are used to old-school leadership where they are more comfortable with control and the power that goes with it. So for Agile IT teams to become high-performing it’s essential that, right from day 1, time is spent in helping the team to initiate the process of adaptive learning and this requires a focus on behavioral skills.

Rather than let Agile Teams try to reach high-performance by trial and error it seems to me that the first thing to do is for everyone to understand the behavioral characteristics of their team members. For a business analyst to be effective in an Agile environment they must understand a lot about people and how best to interact and influence them. A good starting point is to learn about the nature of teamwork and the preferences people have to engage with some tasks and not others.

The Nature of Work

A starting point for Agile Teams is to understand the nature of the work that all teams need to focus on. The Team Management Systems Types of Work Wheel identifies eight distinct ‘Types of Work’ that need to be undertaken by all teams, regardless of their industry. We have found this concept invaluable when working in the area of Agile Project Management.

The eight work functions are listed below, with the approval of Team Management Systems.

If you want to get valuable feedback about your current or future Agile Team we’ve put up a free questionnaire on our website. You’ll get a free 8-page assessment of what you think about your team’s performance, based on these eight Types of Work, or work functions.

Team Management Systems Types of Work Wheel

	The Advising function is associated with the gathering of information from all stakeholders and responding quickly to changing requirements. It involves keeping up-to-date with developments inside and outside the organization and passing advice on to others to help them in their work. It requires a transparent flow of knowledge of ‘what’ is going on and ‘where’, and a focus on ‘consulting skills’ so that information can be gathered quickly, accurately and effectively. A good Requirements Management System enhances this work function.
	The Innovating function involves generating new ideas and new ways of doing things. This requires the development of creative problem-solving skills so that the team remains one step ahead of its competitors. To do this well requires original thought, imagination and innovative thinking.
	The Promoting function is concerned with the identification of opportunities and the ’selling’ of these opportunities to others, both inside and outside the organization. It often involves the application of influencing skills and the making of presentations to others. It can also involve communicating the team or organizational ‘vision’. High visibility throughout the organization may also be required.
	The Developing function is associated with the turning of concepts into ‘reality’. Ideas are worked on to produce practical products and services. In many cases it may also involve developing workable and practical solutions when problems arise. Agile Teams need good analytical skills so that requirements can be quickly prioritized, enabling accurate estimates of iterations and burn down charts.
	The Organizing function involves organizing people and resources efficiently by setting clear goals and objectives and making team members accountable for their actions. It is also associated with the implementation of quick effective action when problems occur, so that the planned outputs are always capable of being achieved. In summary it’s the function that ensures that the work of the team is structured and focused towards common objectives.
	The Producing function focuses on outputs, ensuring that iterations are completed to high standards of effectiveness and efficiency. It’s the function associated with the regular delivery of releases and other services. It requires a systematic approach to work and an emphasis on the delivery of products on time.
	The Inspecting function requires an attention to detail and an emphasis on the monitoring of systems, contracts and outputs. It’s also associated with a focus on accuracy, ensuring that work outputs are always delivered to the right quality. This function is the classic control function where procedures are regularly monitored for their efficiency. It’s often a core feature of the iteration review process.
	The Maintaining function is a support function which ensures that proper standards of conduct and ethics are upheld and that quality is maintained. It’s also associated with supporting others in the team so that the team processes follow agreed ground rules. Personal conviction and loyalty are often important to this function as is an interest in helping others.

Work Preferences

For teams to be high-performing it’s essential that these eight Types of Work are done well. But Team Management Systems has discovered that rarely does anyone actually enjoy doing all of these functions. People show distinct ‘work preferences’ for maybe just two or three of these activities.

Work Preferences are dimensions of individual differences in tendencies to show consistent patterns of relationships, thoughts, feelings and actions in the work environment. Work Preferences determine the conditions we all set up to allow our mental and psychic processes to flow freely. Preferences are usually transparent and are often the first thing we notice in others – ‘He’s rather quiet, isn’t he?’ or ‘She never stops talking.’ Some people prefer to think things through on their own whereas others need to talk out loud to clarify their ideas. Preferences are readily visible to others and are usually the basis of first impressions.

When we are working to our preferences we set up conditions where our psychic energy can flow freely. If we are more extroverted we like work where there are lots of interactions with others, both inside and outside the organization. If we are more introverted, then we like conditions where we can work on our own with few interruptions and a minimal requirement for meetings. Under these conditions our energy can flow freely with minimal resistance. Just as electrical energy generates heat when it meets resistance so our psychic energy generates tension and stress when it has to flow through areas that are not our preference.

I have a preference to work in the Advising and Innovating areas on the Types of Work Wheel and I don’t really enjoy Promoting or Organizing activities, so wherever possible I’ll spend time thinking about new ideas or finding out as much as I can about the project.

It seems that the ‘Law of the Four P’s’ applies here. We all tend to practice what we prefer; for example you might prefer to play golf rather than squash. Therefore at any opportunity you are more likely to be on the golf course rather than on the squash court. The more you practice golf the more likely you are to perform better at it and maybe even become perfect. So it is at work. We all tend to Practice what we Prefer and over time we become more Proficient in the areas of our preference. This in turn gives us Pleasure from our work.

What happens in an Agile Team is that there’s likely to be an imbalance when you look at the work preferences of all the team members. If everyone is like me then there’ll be a tendency to give priority to making changes and incorporating the latest ideas. Teams like this may have the weakness of never tracking their burn-down charts!

Other weaknesses occur if everyone enjoys just Organizing and Producing. Your team may be well organized and on-target but is it really delivering what the stakeholders want or indeed need?

So, if your Agile Team is to be truly effective you must understand the work preferences of all team members and look at the preferences balance. It will give you an immediate picture of strengths and weaknesses, as far as teamwork is concerned. Information like this helps ensure that everyone’s work preferences are matched to the critical demand of the job they have to do. Where the match is high, our energy flows freely, we are more likely to enjoy our job, stress is lower and we feel happier at work. But all eight work functions must receive the priority they need and never be relegated to lower importance.

Is it possible to identify a person’s work preferences? Fortunately the answer is ‘yes’. Many years of research by Team Management Systems has led them to a reliable and valid way of doing this.

The Types of Work Wheel is a model about essential team tasks but there is a strong relationship with work preferences. For example people with preferences for extroverted relationships and creative information gathering map most often into the Promoting area of the Types of Work Wheel whereas those with introverted relationship preferences and practical information gathering most often prefer Inspecting work. Those who like analytical decision-making and prefer to work in a structured way show a bias for Organizing work whereas those with beliefs decision-making and a more flexible approach to the way they organize themselves and others enjoy Advising work.

The Team Management Wheel

The integration of the Types of Work Wheel with the work preference concepts led to the development of the Team Management Wheel.

The TMS Team Management Wheel

A person’s work preferences can be mapped onto this Wheel as a major role preference and two related role preferences. Thus someone might show a preference as a Creator-Innovator with related roles of Thruster-Organizer and Concluder-Producer, or as a Controller-Inspector with related roles of Concluder-Producer and Upholder-Maintainer.

Here are some general characteristics of each sector:

Reporter-Adviser:	Prefers gathering information and likes to fully understand situations before acting
Creator-Innovator:	Enjoys thinking up new ideas and new ways of doing things rather than focusing on delivering outputs on a regular basis.
Explorer-Promoter:	Like to take ideas and promote them to others, not worrying too much about any details involved.
Assessor-Developer:	Enjoy analyzing and developing different possibilities before decisions are made
Thruster-Organizer:	Like to make things happen and get results rather than ‘waste’ too much time debating issues
Concluder-Producer:	Practical people who like to carry through things to the end by working to a plan
Controller-Inspector:	Quieter, reflective people who enjoy the detailed side of work and like dealing with facts and figures.
Upholder-Maintainer:	Enjoy working in support of others ensuring that tasks are delivered to high standards

Using the Team Management Wheel to Improve Teamwork

There are many ways to use the Team Management Wheel to improve Agile Team performance. Some of these are highlighted below.

Self-understanding

Receiving detailed feedback on which team roles a person is likely to prefer helps them realize why they emphasize some team activities but ignore others.

Team balance

If all members of a team map unevenly around the Wheel it helps explain why some team activities are ignored. After all, we tend to give priority to those tasks we like doing. If there is a team imbalance then everyone knows that an extra effort needs to be made to make sure that less-liked team activities are done well.

Work allocation

Knowing what team roles someone prefers can help with the allocation of tasks. For example, giving an Explorer-Promoter tasks with a high need for detail is probably an unwise move. Asking Reporter-Advisers to work in a job that requires a ‘thrusting’ approach to organize projects and deliver results on time may cause them unnecessary stress.

Colored meetings

Many teams use the concept of the Team Management Wheel in planning meetings. Green meetings focus on information and ideas. Yellow meetings explore options and discuss relevant ‘promotions’. Red meetings are all about planning for action and results. Blue meetings are review meetings to go over the detail. In this way adequate time can be assigned for four distinct but important features of teamwork.

Understanding others

Different roles on the Team Management Wheel see the world in different ways. As a result, team members tend to make negative attributions about those on the other side of the Wheel. Explorer-Promoters may see Controller-Inspectors as dull, boring, pedantic and detail oriented. Controller-Inspectors in return may see Explorer-Promoters as loud-mouthed, waffling and with little substance. It’s a natural human tendency to look negatively on those who are ‘different’. However all roles are necessary to get the best from a team because, often, it is out of diversity that the best solutions arise. Learning how to appreciate individual strengths can be achieved by use of the Team Management Wheel.

Linking

I haven’t mentioned Linking yet but it’s probably the most important idea on the Team Management Wheel and the subject of an article on its own. It’s an activity responsible for integrating and co-coordinating the work of the team. It’s not a preference but a set of important skills that applies individually to team members and collectively to the whole team. Ideal Agile Teams have a low level of leadership control and a high level of autonomy. In these situations team effectiveness largely depends on six key skills of People Linking. These are the skills of Active Listening, Communication, Problem-solving and Counseling, Team Relationships, Participative Decision-Making and Interface Management.

For People Linking to be effective it’s important for all Agile Teams to establish a set of ground rules. These are an agreed set of acceptable individual behaviors that define how team members will interact. Usually they comprise 10-20 statements that are posted in the team meeting room or on the Agile Project Management Platform, agreed at the start of the project and reviewed after each iteration. If a team member is unhappy with a particular team process then it’s easy to open up a discussion just by referring to the relevant ground rule which everyone has already agreed to. Conflict is often avoided by this simple process.

White meetings are Linking meetings, often referred to as the daily 5-minute stand-up meeting when teams are co-located. If you’re interested, I’ll talk about Linking in a future article. In the meantime try out the free Agile Team Performance Questionnaire.

Bright Green Projects is a cloud-based Agile Project Management Solution, developed by a team of Management Consultants with 10 years experience working internationally. Take a look at http://brightgreenprojects.com/overview to watch a quick video.

Quoteworthy: Karl Popper

2009-10-22T15:14:00-07:00

It is impossible to speak in such a way that you cannot be misunderstood.

- Karl Popper

No related posts.

Quoteworthy: Kulak & Guinney

2009-10-12T17:57:34-07:00

An appropriate and complete requirements specification does nothing to ensure a successful implementation; however, it makes it possible.

- Kulak & Guinney

Quoteworthy: Joseph Joubert

2009-10-05T18:30:10-07:00

Words, like eyeglasses, blur everything that they do not make more clear.

- Joseph Joubert

No related posts.

“Cascade”: Q&A with David Wright

2009-10-01T17:35:11-07:00

David Wright is no stranger to many who participate in the various online business analysis-related forums and online communities. He’s been in the business for over 25 years and, during that time, has accumulated quite a bit of practical knowledge and insight.

Not long ago, he decided to put pen to paper and share some of that accumulated knowledge in Cascade; a guidebook using a framework of 13 principles to describe “better practices for effective delivery of information systems in a multi-project environment“.

I’ve read and enjoyed the book myself, and thought it’d be interesting to get a little background on Cascade and the thought process behind it.

With that in mind, I sent David a list of questions that you’ll find below along with his responses and a few of my own comments on the book.

Cascade is a pretty unique title. How did you come up with that?

It’s a play on Waterfall methodologies. I always thought Waterfall was a misnomer, because of the standard criticism of it being slow; I have been to Niagara Falls a few times, and it has never looked slow. A “cascade” is usually visualized as a small but very quick moving thing, and it just clicked with me when I was looking for a high-concept name for what I was writing about.

What motivated you to write Cascade? What are your goals and aspirations for it?

It was something I had to get out of my head and down on paper (or Word doc). I have been working in information systems long enough that I had a set of “rules of thumb” that helped me be successful while avoiding failures I have seen before. I was having a conversation one day with a friend about methodologies and manifestos and what they really accomplished, and it dawned on me that my own experiences and “rules” addressed the same topic. It took me about a half-hour to write out the first cut at what would become the practices in Cascade. After that, it was a matter of fleshing it out with examples and war stories. I guess it comes to that old adage of writing about what you know.

My goal now is to share Cascade with any and all who might find it of interest, and who might be helped by it. To be honest, I did not think about this much while I was writing it, I just needed to get it written. It is a vast marketplace of ideas out there, so achieving that goal is the challenge now; writing it was the easy part!

The book specifically addresses multi-project environments. What caused you to focus there?

It is the reality that most any IT shop faces, but when you want to find some methods to help deal with that reality, what you will find most in the market is methodologies that describe how to best deliver a single project. Most of the time in my career I would be working on several projects at the same time, reflecting the fact that the IT departments I worked in were always executing many projects at the same time. There was never the luxury of doing one project at a time, get it done, and then start another one. There are always too many demands on IT from all parts of the rest of the business to allow that. So constantly working in that environment lead to the experiences that drove out my rules and practices.

There are lots of good practices when it comes to IT delivery. Just curious, how did you whittle the number you addressed to the 13?

It was actually built up to thirteen. I started with my initial draft list, and added a few more to address certain experiences, and it settled down at 13. Anything else I wrote after that fit into one of the thirteen. At this point, I like the number itself, at least for now. I am still working on projects every day, so I may have some more practices to add down the road.

Who would you say would benefit most from reading it?

I would like to think that almost anyone involved in multiple projects at a time could find some benefit, from project sponsors through to testers. I suppose the main audience is IT Managers who are responsible for a group of projects, or manage the people who work on many projects. Most of my actual work over the years has been in Business Analysis with some Project Management when needed, so that’s in there too. The idea of the separate practices is that you only need to read those that affect your work the most, then hopefully readers will take in the rest after that.

What about Cascade are you most proud of or has given you the most satisfaction?

As a Business Analyst, I have done a lot of writing over the years, but always for a project purpose: Project Charters, Business Cases, Requirements Documents, and so on. Cascade is something I wrote for myself, no methodology or templates or standards to drive what I wrote. So, seeing it done was a moment of pure pleasure of accomplishment. I had never pictured myself as an “author”, so to be one now is a good feeling, I highly recommend it to anyone who thinks they might have it in them.

My Thoughts?

First of all, I appreciate David taking the time to respond to my questions, and enjoyed reading the responses. I hope you did, too.

As I said above, I read Cascade and really enjoyed it. It was a quick, 100 page read with a light, familiar tone and a nice pace.

I wouldn’t say David has invented any new principles or coined any new buzzwords with Cascade, but he does provide some specific and sound advice on how familiar principles can be put to good use in a multi-project environment.

I think it’s a good resource and I do recommend it to business analysts particularly for the useful way it ties principles of business analysis in with architecture, project management and resource management principles.

Availability

Cascade is available at Amazon and other various online booksellers. If you’d like to get more acquainted with David, look him up on Twitter or check out his blog (which contains quite a few Cascade teasers if you look back through the archives).

Have you read Cascade? If so, what were your thoughts? What other recently-released books would you recommend as a good read for BA’s?

No related posts.

The Business Analyst Balancing Act

2009-09-28T17:19:26-07:00

See the thin, black line down the middle of the table below? That’s the Business Analyst Tightrope. For wider appeal we could as easily call it the “Good Enough” tightrope.

If you’re an analyst, it represents the line you tread when trying to balance the risk of missing requirements against that of paralyzing the project until “everything” is known.

Not very wide, is it?

The trick to staying on the “good enough” tightrope is to learn and apply some important principles:

“Good enough” requirements are not perfect, but they are sufficient to allow design to proceed with an acceptable level of risk. (Thanks Mr. Wiegers!)
“Good enough” requires time, planning, good communication and cooperation from stakeholders, both in the business and in the factory. Hopefully it goes without saying that it also requires an analyst that does a good job of eliciting and analyzing those requirements!
You will miss important requirements if you don’t have the above.
You won’t produce a “perfect” requirements model/spec upfront even if you do have the above – no matter how long you decide you are going to spend on it.

To quote another of my favorite reads:

Knowing that perfect communications are impossible relieves you of trying to reach that perfection. Instead, you learn to manage the incompleteness of communication. Rather than try to make the requirements document or the design model comprehensible to everyone, you stop when the document is sufficient to the purpose of the intended audience.

- Alistair Cockburn from Agile Software Development

Now, I know the table above isn’t complete, and there is a lot more I could say on this topic. But you see, I have probably 20 or so blog posts that have been sitting in draft mode for up to a year. Why have I not gone ahead and published them? Because they weren’t perfect!

Obviously, I need a dose of my own prescription (as is usually the case with my more “prescriptive” posts), so I’ll start today. I didn’t want to let the imperfection of this post keep me from sharing what I think is a useful idea for BA’s, so here it is in its “good enough” state.

I’d love to add more to the table, though. If you have any more ideas on items that fall on either side of the missed requirements/analysis paralysis tightrope, please comment or contact me with them. I’ll continue to update the table with your contributions and mine as I think of them.

Quotable: Whitney Young

2009-09-26T13:17:05-07:00

It’s better to be prepared for an opportunity and not have one than to have an opportunity and not be prepared.

- Whitney Young

Quotable: Herbert Kaufman

Time Travel for Context-free Use Cases

2009-09-23T20:39:25-07:00

We business analysts are surrounded by “solution” folks; those whose jobs are to determine how to solve problems. On one side, our business stakeholders are typically tasked with problems in the business domain that they want to solve with the help of technology. On the other side, our designers, architects and developers are tasked with solving the puzzle of enabling the available technology to solve the business problems. They, pretty much reflexively, process the information they’re given in terms of what the solution needs to be and what it needs to look like. And they should. It’s their job, after all.

BA’s are (supposed to be) a different animal. We’re the ones that help our solution-oriented counterparts take a step back to focus first on the problems and their root causes. Then we work to create a shared vision between business stakeholders and the delivery organization as to the essential needs and/or functions required to solve the problem (AKA “specifying the requirements) while being careful not to pigeonhole the design with unnecessary implementation detail.

The challenge is that a lot of us BA’s were solutions people in “prior lives” so describing those essential needs and functions in a way that is free of implied technical and implementation context isn’t necessarily something that comes naturally.

Yes, sometimes we BA’s need to think of unconventional ways to help us withhold the technology and implementation detail from our requirements. Below, I’ll share a couple of those “tricks” for the those of you who might benefit from them.

The example

Let’s take as an example a rough cut at a use case description for withdrawing cash from a bank.

The customer swipes a card at the ATM.
The system reads the card and verifies that it is valid, then prompts the customer to enter a PIN.
The customer enters and submits a PIN.
The system validates the PIN, grants the customer access to their account, and provides the customer with a menu of options.
The customer selects the option to withdraw cash.
The system displays the withdraw cash screen to the customer.
The customer selects an amount of cash for withdrawal.
The system verifies that the account has the available funds, that the ATM has the funds available cover the requested amount, and dispenses cash to the customer and provides a receipt.

It’s not a bad use case description. The steps seem reasonable, and they end with the customer getting his cash, so that’s good, right? But do I provide unneeded implementation detail in that use case description?

To check myself, I might use one of these exercises.

Take a walk back in time

Assume we’re operating in the past – before computer systems and software as we know them today. In many cases, systems and software just help humans do things they would have done manually in the past. Imagining that we are operating maybe 40 or 50 years ago, what were the actions – at their simplest - that had to be taken to achieve the goal manually? Often, those will be the same actions today, only they are performed by computer systems and software.

With the past in mind, let’s reconsider the use case for withdrawing cash from a bank. Instead of imagining pin numbers, card swipes, and ATM screens, we might be more inclined to think of how an old-time, customer/teller transaction might take place.

The customer informs the teller that he/she would like to make a withdrawal from their checking account, and presents the teller with a check written out to “cash”.
The teller looks up the account number on the check and requests additional proof of identification.
The customer shows a driver’s license or other valid proof of identification.
The teller verifies the customer’s identity and notes information from the additional ID.
The teller looks up the customer’s account balance and verifies that the balance is sufficient to cover the amount on the check.
The teller deducts the amount of the check from the customer’s account, counts the cash out to the customer and gives them a receipt summarizing the transaction.

Where in the original description we refer to card swipes, PINs, and screens, in the scenario from the past we refer to checks and driver’s licenses. All of those are details of a specific implementation of the use case to withdraw cash.

Simply summarized, thinking through how the process would be done manually helps me recognize my implementation biases in my use cases. I normally wouldn’t completely write out the whole description from the “past” perspective. I’ve done so here just to illustrate the thought process.

Back to the future

By the same token, we could assume we’re operating in the distant future – where your wish is your command. Gone are the crude days of pressing buttons, clicking on links, selecting items from a drop-down list. Assume that you have access to some advanced technical entity – maybe a robot or something – that can enable you to attain your user goals if you just tell it what you need to do.

This would initiate a dialog during which “the system” would “do some magic” in the background and respond with what you need to do next. You would respond in kind until the goal is achieved. Sometimes it is helpful to just think of the “how” as “the magic behind the scenes” as another way to prevent listing unessential requirements or design detail.

Now for the present

After removing implementation context and listing the common elements of both our original and past (manual) descriptions, we might end up with a use case description like this:

The customer identifies self and provides proof of identification.
The bank evaluates the identification information, and recognizes the customer as valid and authorized.
The bank grants the customer account access.
The customer requests to withdraw cash and provides an amount.
The bank determines that the customer has a sufficient account balance, that the bank has available funds, and provides cash to the customer. The bank reduces the customer’s account balance by the requested amount and provides a receipt.

Those steps are pretty much the same whether you did a drive through or walk-in transaction 30 years ago, or today. By taking away the technical context, it’s easy to envision the steps working for a drive-thru, walk-in, ATM, online, or any other withdrawal transaction.

Theoretically, the actions – with their accompanying business rules – should still be applicable if the bank decides to move to a different technology , or even when they come up with some revolutionary new way of fulfilling cash withdrawals.

Wrapping it up

Now remember, I’m not saying that it’s a good practice to always check your use cases by reviewing them as is from the past or future. It’s just a trick you can use to condition yourself to recognize unnecessary detail in your use case descriptions if that’s something your challenged with.

With practice, you’ll get better at instinctively leaving out implementation context without the help of extra tips and tricks. You’ll easily be able to write use cases that are portable across technology and, apparently, across time!

I’d be curious to know, have others of you ever tried these techniques? What other tips and tricks do you use to keep your requirements at the proper level of detail?

Bookmarks & New Favorites (09-38)

2009-09-20T18:40:14-07:00

Here are a few of the articles I found “bookmark-worthy” over the past week.

Improv Comedian Turns Business Analyst by Jonathan Kupersmith – Kupe draws out some of the parallels between comedy improv and the soft skills – or characteristics – that can really help an analyst “perform”.

Bridging Documents by Karl Wiegers – “It’s not unusual for a well-meaning requirements analyst to carefully prepare a software requirements specification and deliver it to the development team and testers, only to have the recipients gripe about it.”

Creating wireframes and mockups – Includes some wireframing fundamentals, and then reviews of some of the more common wireframing tools.

Using User Stories by George Dinwiddie – List a few advantages of user stories, and includes a link to a helpful handout on “writing and splitting” user stories.

Where’s the juice in your requirements? from Hobbs on Tech

Requirements are difficult. I should say good requirements are hard to put together. One thing to look for in requirements, instead of a shopping list, is the juice in requirements. Sure you may need a bag of oranges, but what you’re really after is orange juice. Of course, you also need a knife, juicer, pitcher, glasses, and to know how to make orange juice. But really, orange juice on it’s own really isn’t that interesting a requirement since pretty much anyone can make orange juice. So ideally you want to dig deeper and define more clearly what kind of juice you are attempting (perhaps mint orange juice made at your table?).

Thoughts on Lean Thinking by Dean Leffingwell

An entire ERP system in a single diagram from Kishore Kumar – It’s just as it says. An image of a UML package view of an entire ERP package. I’m just sharing it because I liked it and thought it could be useful. There’s something to be said for having that high-level, overall view of “what this thing does.”

Quoteworthy: Jim Brosseau

2009-09-13T21:05:53-07:00

There will never be “the right approach” for all projects. Software projects come in too many shapes and sizes. There are too many cultures, and just too many reasons for developing software, even within individual organizations. There is no Holy Grail, but many approaches can be “a reasonable approach,” depending on the situation.

- Jim Brosseau from Software Teamwork: Taking Ownership for Success

Quoteworthy: Margot Fonteyn