I came across a post by Meade Rubenstein this evening that I liked because it made me think a bit about methodology and how it evolves (or devolves) as it matures. We all want to get software out the door better, cheaper, and faster, right? And all the buzz lately seems to be around adopting agile methodologies.  Rubenstein’s opinion is that that agile methods, as is typical for “revolutions” in how things are done, will become more bureaucratic as they become the norm:

[L]ike all other revolutions (this one being one of process from traditional SDLC to Agile/XP) - the new becomes the norm and the norm become bureaucratic - making further drastic changes required. I’ve always seen Agile and XP initiatives as an attempt to deliver greater value by removing the imposed management overhead and miss-steps (such as thinking mediocre can replace exceptional with the right process in place) - and, unfortunately now that many Agile/XP practices/processes have become the norm, they are now the anchor.

I can appreciate the notion that with agile, even though there is less “imposed management overhead,” what overhead there is can certainly become rigid and regimented. That said, the balance of this post won’t be quite as much a structured reaction to Rubenstein’s post as it is just a couple of the thoughts that the article spurred and that I’d like to share.

Will “Agile” Remain Agile?

While agile methodologies have been, and will continue to be a quick and obvious win for some shops, I wonder how “pure” agile methodologies will remain over the long haul for more mature, heavy-footed companies trying to transition. It’s easy to imagine some agile-adopters - even among the most well-intentioned - gradually shifting back to old ways by adding “just a few” new activities here and there that add marginal value, but that make the process of delivering good software more cumbersome. It will be hard in some shops to overcome the notion  that the best way to avert risk is to produce more documents. Sure, that’s going to happen. And they’ll still call it agile.

Will Agile Become the Norm?

We’ll also probably find that in some environments, XP (or whatever other flavor of agile methodology) just isn’t the best fit. I won’t deny that we’re in the midst of an what seems to be an agile revolution, but what I’m less sure of is that methodologies like XP/Scrum will ever be the “norm” to the degree that traditional waterfall/spiral methods were for so long. I thinkXP, Scrum, and other agile methodologies are providing us with alternatives that we can all learn from, and that work great in some places, while heavier methodologies are still better suited to others.

The Agile “Discussion” Benefits Us All

What I’ve enjoyed most about this whole “agile movement” is that it is causing all of us - even those of us that use more traditional methodologies - to discuss agile principles and look at ways to make our processes leaner and more efficient.

I think Alistair Cockburn summed it up well in his book, Agile Software Development:

The question for using agile methodologies is not to ask, “Can an agile methodology be used in this situation” but “How can we remain agile in this situation?” A 40-person team won’t be as agile as a six person collocated team. However, each can maximize its use of the agile methodology principles, and run as light and fast as they can creatively make their circumstances allow.

I’ve been very interested in the whole agile/traditional methodology discussion that’s been going on from the blogosphere to the break room (especially as it pertains to the role of the business analyst). What do you think?

Bureaucracy - Magritte photo by Oddstock.

Copyright JonathanBabcock.com. View the original post or comment on

Agility vs. Bureacracy (and other thoughts)

While skimming the book, Lean Software Development: An Agile Toolkit, I came across a passage that has been on my mind for a few days that I’d like to share.

Many software development processes require paperwork for customer sign-off, or to provide traceability, or to get approval for a change. Does your customer really find this makes the product more valuable to them? Just because paperwork is a required deliverable does not mean that it adds value.

A good test of the value of paperwork is to see if there is someone waiting for what is being produced. If an analyst fills out templates, makes tables, or writes use cases that others are eager to use—for coding, testing, and writing training manuals—then these probably add value. Even so, there should be a constant search for the most efficient, effective means to transmit the information.

Lean Software Development: An Agile Toolkit, Mary Poppendieck & Tom Poppendieck, Addison Wesley, 2003

While the book was written in advocacy of agile methods of software development (one of the tenets of the Agile Manifesto is the emphasis on “working software over comprehensive documentation”), I think these ideas also ring true - and perhaps especially so - for “heavier” methodologies.

Now, I’m not knocking documentation in general. There is great value in a spec that represents meaningful, collaborative dialog through which key decisions are made and that expresses stakeholder need in a way that is intuitive to designers, developers and testers. Depending on the company or the industry, there may also be compelling reasons (level of criticality, government regulation, etc.) to produce detailed documentation that, in order to not get too far off-topic, I may address in a later post.

My point is that sometimes we (and I’m talking about myself first and foremost)  get so caught up in doing things just because they’re part of “the process” that we neglect to seriously question whether our time might not be better spent on activities that are more likely to hasten the delivery of good software.

The bottom line is that regardless of the process for getting software done, there is no value in paperwork that no one needs and no one cares to read.

Here’s a challenge: Take a look your current delivery model. Does it include documents or regularly performed activities upon which no one is really dependent? Would eliminating them free up resources for value-add activities that might potentially shorten the delivery cycle? If so, how do you go about amending your model?

As always, I’ll be interested to hear your thoughts.

Copyright JonathanBabcock.com. View the original post or comment on

Does Your Paperwork Add Value?

According to Chin, the determination is made by evaluating project environments and organizational stakeholders.

Project Types

For “Operational Project” environments, or “projects that are run with a regular frequency, are very similar to each other, and are critical to the day-to-day running of the business,” he tends to favor classic management methods.

For projects focusing on the development of new technology he favors agile methods. To clarify what he means by this type of project, he states:

I am not talking about a new product or application, but rather the development of breakthrough technology, upon which future products will be built… Technology development projects are very unique in nature. There is no template project teams can work from and, in fact, a project management template, or any template for that matter, may greatly restrict the team creativity required to create such a new technology platform.

For product or process development projects, which require more business and less technical expertise, he doesn’t see as clear break toward either, but potentially a blend of the two.

Organizational/Stakeholder Environment

Per Chin, the number and type of organizations and stakeholders involved in the project also influence the classic/agile balance. He indicates that classic project management is better suited for handling the complexities of intergroup coordination and accountability necessary in projects with several external stakeholders, stating “[w]hile it is not impossible to create a successful agile environment across multiple organizations, it will be significantly more challenging.”

He favors agile management most in projects under a single organizational or corporate umbrella, and states that this is the environment “where most technology projects that can benefit from agile PM reside, and thus, it is an area with a strong potential return.”

This array of project types and organizational environments combine to provide a matrix resembling the one below that can aid in deciding on the appropriate method of project management.

(Table adapted from figure 2-7 of Agile Project Management—How to Succeed in the Face of Changing Project Requirements by Gary Chin)

Conclusions

Obviously, there are holes to be poked in any simplified method of making complex decisions, and Chin acknowledges that, “[d]eciding to employ agile PM is not a simple, black-and-white question.”

For all its simplicity, I did find the agile/classic matrix to make quite a bit of sense. At the very least, the approach Chin used provides some useful insights that can help in deciding which management method best suits your situation.

If you get the chance, pick up the book. Chin provides much more detail on the topic in his book than I have in this simple summary. He includes several other factors that may influence the classic/agile question, and tackles numerous other agile project management topics.

So, what are your thoughts? Would you agree on the factors used? How would your decision matrix differ from Chin’s? As always, I’ll look forward to your input.

Copyright JonathanBabcock.com. View the original post or comment on

Choosing Between Agile and Classic Management Methods

Here are some of my recent findings of interest that I wanted to share in case others of you may be in the same boat.

Martin Fowler specifically addresses the question, “What is the difference between UseCases and XP’s stories?“:

Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories… break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP’s release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.

Mike Cohn, whom I’ve cited before on the topic of user stories, provides insight on a format for articulating user stories that he has found to work well.

I advocate writing user stories in the form of “As a <type of user>, I want <some goal> so that <some reason>.”

For example, “As a corporate finance user, I want to know yearly how much in taxes are due to the state treasury so that the company can comply with state tax regulations (and avoid penalties for non-compliance).”

I think this format could be just as beneficial in a non-XP environment as a mechanism for requirements elicitation. In fact, I’m going to use the spreadsheet form of which he provides a sample for use in one of my new projects. I plan to ask my stakeholders to put themselves in the place of the user (in at least one case, the stakeholder will actually be one of the users) and let them state, from a first-person perspective, what they need to be able to do, and the value of being able to do it.

Too often as I’ve written traditional SRS documents I’ve either been asked or wondered to myself what was the value of a given requirement or set of requirements. With this format, we’d include a statement of business value with each user requirement. Good stuff.

For your reference, and contrasts them with traditional requirements.

In summary, here is what I’ve gathered so far based from my readings on user stories (much of this is derived from ExtremeProgramming.org’s useful description of user stories) :

1. User stories are primarily used to estimate development time, as opposed to use cases which focus on how users (actors) interact with a system.
2. User stories focus on user needs and are technology/implementation detail agnostic.
3. User stories become acceptance test scenarios.
4. User stories are typically written on cards and not diagrammed using the UML as are use cases.
5. User stories are an alternative to the traditional SRS document full of “shalls”. When it comes to detailed functional, system and quality requirements, those are worked out between developers and the customer.
6. User stories are most often identified with the XP (extreme programming) approach to release planning and development, which is a form of agile development.

I am a student as much as a practitioner of requirements analysis, and am always open to new information in tips. If you have any additional information or personal feedback on user stories or extreme programming or other agile methods, then please share. I’m always interested in learning more.

Copyright JonathanBabcock.com. View the original post or comment on

More on User Stories

Among others, Lockhart draws attention to topics such as budget, relationship management, onsite travel, CMM considerations, the risks of miscommunication, and economic and political risks that need to be carefully weighed out before deciding to go offshore.

The way I see it, offshore outsourcing of IT work - chiefly development and QA - is not going away. Those of us stateside will have to learn to adapt and thrive in this new type of environment in order to remain marketable. For many of us, retooling may be necessary.

From a business analyst’s perspective, I’m not so naive as to think that my role couldn’t possibly be performed overseas, but I don’t think that the role of the onshore BA is going away anytime soon. I’ve alluded elsewhere on this blog to the notion that the business analyst role can be at least as much a business role as an IT role. Until companies start farming out their marketing, finance and operations to offshore MBA’s - and I don’t see that happening anytime soon - then there should remain plenty of work for the BA in helping define business problems and objectives and refining business processes.

Anyway, if you’re interested at all in the dynamics and trade-offs involved in offshore vs. onshore development arrangements, I think you’ll find this read well worth your while.

Copyright JonathanBabcock.com. View the original post or comment on

Onshore vs. Offshore

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
4. Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
5. Repeat three times steps 3 and 4.
6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
7. Users find 137 new bugs.
8. Original programmer, having cashed his royalty check, is nowhere to be found.
9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
13. Programmer produces code he believes is bug-free…

Let me know whether this made you laugh or want to cry.. I think I’ve seen it from both sides!

This and other project management related jokes and truisms are available from Visitor Tracking.

Copyright JonathanBabcock.com. View the original post or comment on

The REAL Development Lifecycle?

Now, you can err on the side of going with a no-planning, “fly by the seat of your pants” approach to product development and just kind throw something out there and see what happens.

You can also hurt your concept by taking it to the other extreme of “analysis paralysis“; you spend so much time planning and researching that you never end up releasing a product.

So, obviously, there is a happy medium. And I won’t be defining that happy medium for you in this post. What I will provide, though, are 4 things to consider in product development that will put you well on your way to success.

This “party of four” key considerations comes from Adam Bullied at writethatdown.com. Basic? Absolutely. Product management 101 type stuff? Yes, sir. But if you’re not including these 4 key and simple concepts in your product planning you probably ought to.

Problem?

Straight-up. What is the problem the product is trying to solve? If this can’t be defined, maybe the product idea needs to be revisited before proceeding.

Vision

What is the grander scheme of the product? A vision is 100% critical because it gives you perspective moving forward. Competitive decisions, feature choices, even priorities. All these choices can be a direct reflection of the vision. Is there something that can’t be decided? Go back to the vision. Does it fit the vision?

If not, chuck it. It it does, get it in there.

Market Segments

So what”s the other really important thing before writing a stitch of code? Deciding who … the code is being written for. If that’s not known, then how can features and priorities be decided upon?

I’ve found that there is a key difference here when building consumer products to business products. The segments for a business product can be a lot more broad as opposed to consumer, which tend to need to be more specific. Why is this? I think it’s because with consumer markets you’re dealing a TON more users that need to be pleased, in most cases.

I don’t believe this is hard & fast, but just lessons learned thus far.

User Goals

So once the market segments are decided upon, the goals the segments are worked toward when using the product need to be identified, so they can actually be reached.

Copyright JonathanBabcock.com. View the original post or comment on

“Party of Four” Key Considerations in Product Development