I was talking to my husband about this blog tonight over dinner. He’s a software consultant specializing in enterprise web applications. I wasn’t sure what topic to explore, and he suggested that I think about challenging situations that arise at work. One of these situations is development itself–sometimes, we’re just not sure what we want from a computer program (eg, our publication’s web site). Our conversation then turned to software development; specifically, the waterfall. In development terminology, the waterfall is “determine a need,” “get the requirements,” “develop,” “test,” ”deploy,” and then “we can’t use this” (ie, change it). Waterfall development is a predecessor to what you may be seeing with your publication today; that is, agile development. The waterfall is a linear model–what you get at the end may not necessarily be what you really wanted or needed. Agile development is an iterative process. That is, you start with a basic set of requirements or needs. In the initial stage, a prototype of the product is put out for review and testing. Any changes to the initial set of requirements are captured. Then, it’s quickly back to the drawing board to implement these changes. And repeat as needed. The important part of this is to establish a baseline of what the minimum set of requirements are to produce a fully usable application.

In our roles as editors, development occurs behind the scenes, and we may take this work for granted. It’s worthwhile learning a bit about the nuts and bolts. Not too bad for a Monday night meal over Thai food!

Every week I read thousands of blog posts. Here, for your weekend enjoyment, are some highlights from my recent reading, for you.

	On Starting Up… http://www.markpeterdavis.com/getventure/2009/11/bootstrapping-vs-venture-funding.html On choosing the right financing strategy.
	On Design & Product Experience… http://googlemobile.blogspot.com/2009/11/iterative-web-app-new-look-for-gmail.html The iterative and incremental design process at Google mobile and Gmail.
	On Modular Innovation… http://www.readwriteweb.com/archives/linkedin_platform_pros_and_cons.php A look at LinkedIn’s Modular Innovation progress.

Have a great weekend!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

1. Identify your users’ stories

As I studied users’ thoughts, I found patterns in what my project was really designed to do, above and beyond what the project brief said. I listened to what my mind was drawn to listen to. These were the users’ stories — what was most important in their working lives.

There are no right or wrong answers in listening. Be honest with your users that you’re there to add value to the way they work and their stories – needs, expectations, attitudes and capabilities – will become clear.

2. Embrace your users’ needs

Once I am aware of users’ needs, it is far easier to design according to them. When faced with a decision, I can compare it to their values by documentation as personas, and see it will bring me closer to a solution that is fit for them, rather than what is easiest for the project team to produce.

3. Accept expanding feature sets

A ZenAgile mind does not struggle. It accepts users’ needs as they truly are. A rock is a rock. It will remain that way no matter how much you worry, wish, or pressure it into changing. Worrying about requirements and ever expanding user wants are the same way. I accept requirements for what they are, do not waste time or energy fretting over it, and group them into feature sets for delivery in such a way that, as a whole, they add value to users’ work.

4. Energise for change

A ZenAgile mind can give you extra energy for change as you are not wasting energy fighting against the inevitable. As above, there is a large rock in your way. You have three options:

• run into the rock repeatedly
• agonize about the rock being in the way, or
• find a way around the rock.

Before ZenAgile, I chose the first two options. With ZenAgile, I now accept the rock for what it is: an obstacle. I accept that you cannot go through it. I do not panic, and waste time and energy worrying about the obstacle. Instead I make my own path around the obstacle, either over the rock, around the rock, or under the rock.

This is Seijaku (静寂) — the energised calm.

5. Enhance knowledge of yourself

As I practice ZenAgile, I spend a fair amount of time in conversation with others and thereby understanding myself and how I come to terms with change: change in the project context, changes in requirements, and changes that need to occur to the solution.

In time, I’ve learned to quiet my mind. I’ve listened to the same fears for projects repeating themselves which inspired me to change what was causing those fears. I’ve realised, for example, that lack of a user-centred approach was a large source of anxiety, and so it was time for a change. Without time to think and meditate on the conversations in a project, we tend to ignore what our mind is telling us, and remain locked into our old patterns of doing things.

6. Gain confidence in the agile way

As you reflect on your inner self, you become conscious of who you really are, your role, and the skills you bring to aspects of the agile project. You learn what makes you happy, what is beneficial to your project, and where you fit into the multidisciplinary team. You bypass the fears and anxieties of your mind, what role you play — Business Analyst, Project Manager, Information Architecture, User Experience Designer, Change Manager — and focus on doing what needs to be done. Boldly and passionately complete the iteration. The opinions of traditional organisations like PMI, IIBA, ABAA, etc, do not matter, because you know you are doing what is right.

7. Appreciate the iterative project lifecycle

I accept the project as it truly is – evolutionary in nature, rather than revolutionary. You will always uncover new aspects of users’ needs. You will always uncover the unknown as you proceed boldly through the project. Some will be surprises like a starry evening, a stroll by the river, or a night of solitude. Each will have their own unique characteristics to be appreciated. Mundane user needs also hold their own charm. Observing the quiet details of the project lends value to the less appealing aspects, and brings peace and joy in commonplace tasks.

8. Increase consideration for others

Each person on the project is interconnected. We are all searching for the solution, requirements, and a meaningful project to work on. It is much harder to be angry at the user who argues with you about scope when you realise they are on the same path, just at a different point in their journey.

9. Simplify your project and your documentation

Conversation not documentation helps you differentiate between needs and wants. To document things completely today is to suggest that it will fix users and their workplace in time until the project has been completed. By focussing, instead, on a minimalist, simple project solution delivered in a short period of time, with just enough documentation to describe the decisions made, you are able to deliver value to people now and then build upon that solution to meet their future needs.

This is Kanso (簡素) — simplicity and elimination of clutter from the project

10. Cultivate a giving spirit by mentoring others in the team

When you are doing your role in the best way you can, your heart fills with joy. You are doing what you were put on this earth to do, and doing it to the best of your ability. Your life is simple, you are living your values, and you have a clear mind. You can then give to others, mentoring and teaching with a loving spirit, to help them along their path.

This is the True Way of ZenAgile

M

I have my problems with iterative design. Personally, iterative design is the way to go for me. Professionally it’s my biggest enemy.

When designing games, I find it impossible to think of every (and I mean EVERY) little aspect of the game. I just can’t. Even harder is that I cannot always guarantee that my design is fun or that it “feels right” when played. Making a game feel right  is the hardest process, because it involves a lot of fiddeling around with animation, response times, feedback and so on. To really get those things nailed, iteration is the way to go – although time and budget restrains often keep me from iterating until I feel the game is good to go.

Now, those budget restrains are not what makes iteration my biggest enemy. It’s my co-workers. Don’t get me wrong here, they are great guys but every time I ask for iteration, it weakens my position as a Game Designer. It almost feels like I’m saying: “I’m a bad designer. I have no clue about what I’m doing. I can’t design on paper.” I had people come up to me and ask me, why I did not know this or that button had to be there 6 months ago. All I could answer was “I simply didn’t know back then!”. Well, that must mean I am a bad designer  - at least to the person asking it does.

Iteration feels like admitting that you don’t have a clue. If you’d have a clue, you could’ve designed everything in pre-production. At least that’s what a lot of people expect of me.

But I am content with this. Iteration IS the way to go. At least for me.

The stick containing the credits wasn’t heavier or extra shiny, but I knew it was more special in five million little ways than any other credcard I’d had in a long while. I presented it to Kurt in the waiting room of the Ganymede Internment Center.
“You know what this credcard represents, Kurt?”
“Five million credits. I think you are implying some metaphoric relationship that is not readily apparent, though.” Deadpan, as usual.
“Well, sure I am. This means an actual animal slaughtered steak dinner. Perhaps a bottle of actual red wine; not because it tastes better than assembly drinks, but just because we can. How do you want to celebrate and be happy?”
He rose from the bench and followed me out into the walking path.
“We have had this discussion before, Ishmael. Just because I am sentient does not require me to feel certain emotions.”
People kept taking double takes at Kurt’s dull metal faceplate as they entered or exited the walkways. One salary man missed his exit from the runway and fell down. His briefcase spilled styluses and data pads.
“Okay,” I said. “Think a bit. What’s the emotion you experience the most?”
“When I am running low on joint lubricant, or am being treated unfairly despite my legal freedom, I experience an awareness of my condition that treats the constant internal reminders to be something like frustration, I believe, compared to what you and many authors have described.”
We side-stepped to the runway and were heading towards the space port.
“So all the time.”
“The majority of time.”
“When don’t you feel,” I made air quotes with my fingers, “frustrated?”
“When properly lubricated and on our ship. I am not sure you remember when we discovered that antique probe circling Phobos.”
We made the transition to another walkway and headed towards a ship resupply store.
“I remember. It cost our last fifty thousand to get the landing gear bay door fixed.”
“Yes. That one. I was curious that entries in the standard historical and navigation archives did not mention it, and had to do some extensive searching on the Interplanetary University Databases to find out it was a satellite from the twenty-first century.”
“So you like doing research?”
“I wanted to fix the blanks in the archives and my personal knowledge.”
“You wanted to, like code, or wanted to on your own?”
Kurt tapped the upper right side of his chest, which is like a human tapping their temple. “Just because my sentience is the result of a complex, emergent software grafted into a hardware frame does not mean my programming makes me do anything more or less than the systematic pulses your neurons provide from inside your chemically fueled brain. I wanted to, as in I had a desire.”
I rolled my eyes. It was something Kurt couldn’t do, which I liked. “Right, whatever. So here’s what you can do. I’ll transfer twenty thousand credits to our second credcard.” I handed him a credcard which he took in his digits like he was studying a disgusting new bug. “Then you can go find a pre-spacer science book, or get yourself a subscription to a new library or database.”
We exited the walkway and stood in front of the port’s refueling and provisioning office. As I took a step to walk in, Kurt put a hand on my shoulder. The move startled me inside, but I made an effort to hide the surprise.
“Ishmael, to what end? This celebration money could be spent on our search to find a place where the inhabitants do not have this awful prejudice towards Second Men.” He gestured to two people trying too hard to look idle while leaning against the wall of the neighboring store. “Those two have been following us since the Internment Center.”
I took another look at them and decided they were toughs visiting friends in the GIC, cops in plain clothes, or both. Even I could tell their hands were holding on to something inside their coats.
“Twenty thousand will buy enough rations and fuel to take us somewhere else, Ishmael.”
“Fine, Kurt.” I poked him in his steel breastplate with a finger, words colored more by disgust than defeat. “But I’m buying you a complete nano scrub to go with a case or three of the top synthetic joint lube. Then go sit in the ship while I find some whiskey old enough to order another whiskey, and actual Terra-Asian style takeout while we wait for the fuel to get pumped.” I headed inside and started keying the ship’s details into the automated fueler machine. Kurt came in and stood behind me, watching the door.
“The nano scrub is unnecessary. I am well within the tolerable limits for foreign matter.”
“That’s the point of celebration, Kurt. It’s supposed to be unnecessary. Enjoy the sensation of being clean and not having any humans around. Maybe it will cut down on those internal reminders.”
“I predict that the state of being afterwards would best be described as peaceful. Right now, I am most likely grateful.”

“Be grateful for the joint lube.  I think it might be a while before we find the place.”

Kurt missed.
The bullet shattered through the window and pieces of slug and glass ricocheted off Ventura’s flight helmet. His head snapped sideways before we heard the rifle’s report and I cursed faster than he could hit the ground. I dove to the ground. His pistol, obviously an automatic, fired rounds over my head.
At the galleries, Kurt never missed. When the interplanetary fair was in town, they wouldn’t let a Second Man with precisely controlled synthetic muscles ever have a second chance at any of the carnie games. “Only real people have luck,” they’d say. “Lady Luck don’t go on dates with Metal Men.”
Why is this relevant? Ventura had been pointing that automatic at me and standing still when Kurt pulled the trigger.
I didn’t have a conscience like Kurt did, just instinct, and dashed the last twenty feet. I pulled my .38 revolver from its holster and pressed it against Ventura’s cheek.
“I hope you can hear me over the bells ringing inside your head. My partner missed, but I’m a pretty good shot at this range. I don’t particularly trust those fancy automatics, so unless you’d like a very in-depth lesson on the reliability of revolvers, I suggest you throw your weapon away.” I didn’t pull my eyes from the unfocused look on Ventura’s face, but heard the gunmetal skitter along the laminate floor.
I rolled him over, cuffed his hands and legs together, and then left him on his side. I was gingerly unloading the machined pistol when Kurt came inside the small house a moment later.
“This humidity and brackish water of my wet observation post is interfering with my inputs and leg joints, Ishmael.”
That’s me. Ishmael. Insert white whale reference here.
“Also, pardon the miscalculation, but I did not notice the plating in the walls or that the windows are military grade glass until I was within two hundred meters of the house just now.”
“It’s fine, Kurt. He’s alive and worth more because of it. You make it seem like I can’t handle myself.”
“The human mind does almost incalculable amounts of math every day to keep your bodies running. Yet, it was not hard for me to see that Ventura held the advantage when he leaped out of the freezer unit and pointed his weapon at you.”
“Is that so? Amazing. I felt like I had the situation under control the whole time.” I started scribbling requests for a convict pick up in to Sheriff’s Net.
“That was clever of him to hide from my thermal optics by using the ice-covered interior of the freezer. For all that mathematical potential, humans are entertainingly random occasionally.” Kurt unloaded the ammo from his iron sights rifle and looked around the old warehouse. “I deduct that the metal lining and thick glass make this place an excellent slaughterhouse.”
“Thankfully for us, it wasn’t today.”
“Yes. Ventura will be worth two million more credits alive than dead.”
“I meant we’re thankful that I didn’t die, Kurt.”
“Yes, I imagine you are.”
I rammed my hands into the pockets of my parka.
“Sometimes, you’re a heartless bastard, Kurt. Did you know that?”
“You know as well as I do, I do not have a father or a heart.”

I shook my head and stepped back outside to await the pickup vessel.

“No, I suppose you don’t.”

“This is not smart. You have not thought about this at all,” Kurt stated.
“Why do you ask these questions when you know the answers?” I replied.
“When you respond to my statements with a rhetorical question, you do not expect an answer or to succeed.”
“When did you learn how to use rhetoric? Did that come in a firmware upgrade or something?”
Stillness was the closest Kurt got to looking frustrated.
“Hostility as well, without a human female in the area to warrant this show of threatening bravado. Interesting.”
“The tin-man learned sarcasm as well. I pine for the days when they just silently obeyed orders, I really do.”
“Finally, we are at the dejected but inevitable realization that what I said was true. This is not smart.”
Kurt had this bad habit, or coded routine, of pronouncing the punctuation that most people skipped over. When he uses a comma in speech, he actually pauses. Periods at the ends of sentences take a moment all their own in Kurt’s voice box. I did my best impression.
“It’s this simple: we need credits and they have credits. They want certain outlaws brought back for justice; we have weapons just like everyone else.” I patted the revolver holstered on my thigh. “They don’t want to leave the security of their climate controlled settlements; our home is a space worthy hunk of junk and relocates easily. All these good reasons just stack up.”
Kurt continued to give me the unblinking gaze, possibly unconvinced.
“Let me put it this way. If we bring back the outlaw, we’ll receive enough credits to really stretch out the fuel, food, and juice so we won’t have to come across another settlement that is as,” I paused for emphasis that I hoped wasn’t lost, “disapproving, let’s say, of other Second Men like yourself.”
Sometimes, when I really give Kurt something to think about, the diodes in his eyes dim just the fraction of a lumen. I take it to mean he’s rerouting power from something unnecessary as appearance and switching it towards crunching numbers with his conscience.
“Ok. We will apprehend the outlaw. This bounty hunter mission can not be a regular occurrence. Humans get nervous enough seeing me walking around free. I hypothesize their reactions to seeing me with a gun will also be less than pleasant.”
“If only they knew what a pleasure it was to live with you, Kurt, they wouldn’t worry about you with a gun.”
“Ah. Your Contented chortling because you successfully over ruled my initial objections.”
“No, Kurt, just confidence in knowing a person would be much more dangerous to their own self if given a loaded weapon after living with you for so long.”
I smiled as his eyes flickered for the second time today.

One of the often-cited concerns with leveraging reusable software is design complexity. This is indeed a legitimate concern and as designers, we ought to ensure that it is managed appropriately. In this post, I want to provide some strategies for tackling integration complexity:

1. Build Iteratively: this is undoubtedly an effective way to avoid over-engineered assets. Building assets iteratively means realizing functionality in small bites, over multiple releases even. Instead of trying to implement a perfect reusable asset, prefer building in increments. This has several benefits: reduced risk, increased relevance for your applications, early feedback on whether the asset has captured domain relationships appropriately, and opportunities to remove code or refactor behavior on a continuous basis.
2. Capture natural variations in the domain:  reusable assets that don’t reflect the natural variations in the problem domain run into lots of issues. If you keep scratching your head trying to infer what the asset is trying to accomplish – examine the consumer-facing interfaces and ask yourself, does the interface reflect domain variations or is it providing needless variations or worse, ignoring must-have ones?
3. Prefer convention over configuration: This is one of the foundational principles behind why frameworks such as Ruby on Rails are so popular. You can use this idea and simplify assets in many ways! For example, instead of forcing configuration for files, maybe a standard location would suffice. This idea can be leveraged with scripts that setup developer environments, automated regression tests, and reading/saving program output etc.  There might also be cases where input data is used to determine class instantiation or stylesheet selection. Again, if you come up with a simple convention, many lines of configuration can be eliminated.
4. Loosely Couple Capabilities: Loosely coupled capabilities are easier to change and integrate. By creating reusable assets in a loosely coupled manner, you will also make it beneficial for consumers. Loose coupling provides another important benefit – making it easy to isolate assets and test them as individual components. If you are building service capabilities, explore the use of asynchronous message publications for real-time notifications to data/status updates.
5. Strive for consistent naming and behavior: consistent naming reduces learning curve for developers as well as makes it easy for the asset provider to debug, integrate, and test reusable assets. Consistent behavior should go beyond simple method calls – you can extend this to services and business processes as well.
6. Make Assumptions Explicit: A lot of design complexity can arise due to incorrect assumptions – for instance, there may be operating assumptions about security, data integration, tracking, and error handling.  There are a lot of design assumptions that get made as a natural part of the development process (e.g. every customer will always have a address, or that every customer needs to get authenticated prior to instantiating a business process). Make sure these assumptions are put in the open and for everyone to validate. It often turns out that an asset doesn’t have to implement a feature or that it may be implement an existing feature incorrectly.
7. Provide consumer-friendly interfaces: Start designing from the consumer’s standpoint and strive for simple yet functionally rich interfaces. This has several benefits: you won’t expose needless internal complexity associated with the asset to the consumer (i.e. achieve right level of encapsulation) and also make it simple for consumers to integrate with the asset. If you have 10 options for a reusable asset but most customers use 2 frequently, why not set the other parameters with sensible defaults? Consumer friendly interfaces also ensure that you build assets that have tangible business value.
8. Avoid abstractions for the sake of technical elegance: not every abstraction is meaningful, especially with respect to your problem domain. I wrote earlier about the domain-specific nature of variations and why one set of abstractions isn’t always appropriate for your problem. Experiment and iterate to get the right abstractions – they will help establish a shared language within the team and reduce needless complexity because of overly generic interfaces.
9. Minimize compile-time and runtime dependencies: Reducing the number of moving parts – both in terms of compile time libraries and runtime libraries, services, and systems will make it easier to manage design complexity. Always, ask yourself – is this dependency absolutely essential? Does it introduce a single point of failure in the overall architecture? Is there a way to cache frequently accessed data or return that isn’t 100% up to date?
10. Provide Mock Interfaces: When possible provide mock data/objects that can help consumers integrate and test assets quickly. This is related to the earlier point about minimizing dependencies but is also useful for customers to get a flavor for the kind of data or business rules that get executed as part of the asset’s functionality. Mocking also helps with another key benefit: asset co-creation. If you are developing in parallel with a consumer, mocking is a great way to agree on interfaces and develop in parallel.

What is your view on these strategies? Can you share some of the ideas/approaches that you have pursued to tackle integration complexity?

Like this post? Subscribe to RSS feed or get blog updates via email.

#4 Separate Message Construction from Message Delivery

There are a variety of scenarios where you will build a message and deliver it to a destination. The message itself could be free-form text, delimited/fixed-length text, XML, or some other format. The destination itself could be a system, service, application, a server, or a human user or group of users (in the case of email). If you decouple message construction from its destination, that will drive in reuse of both of these assets. For example, you can take a message and send it via email or send to a message queue. In the same vein, you can potentially use the same code that sends email to send a newsletter message and a reminder message.

To illustrate this idea, take a look at this code fragment:

MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress(from));
message.addRecipient(Message.RecipientType.TO,
new InternetAddress("someone@xyz.com"));
message.setSubject("Hello there...");

FileReader fr = new FileReader("some-template.html");
StringBuffer sb = new StringBuffer();
BufferedReader reader = new BufferedReader(fr);
String line = reader.readLine();
while (line != null) {
     sb.append(line);
     line = reader.readLine();
}
reader.close();

message.setText(sb.toString());
// Send message
Transport tr = session.getTransport("smtp");
tr.connect("host-name", "user", "some-password");
message.saveChanges();
tr.sendMessage(message, message.getAllRecipients());
tr.close();

There is a file that is read from the file system and a data buffer is being constructed. The data is then used to send an email. However, this class isn’t very reusable because of the tight coupling between message construction and delivery logic.

Now examine, a newer version that has modularized this code – Publisher sends the message using an EmailConfiguration and TemplateBuilder constructs the message using an instance of Template.

Publisher publisher = new Publisher();
EmailConfiguration eConfig = new EmailConfiguration();
publisher.setConfiguration(eConfig);
TemplateBuilder builder = new TemplateBuilder();
Template template = builder.build();
publisher.publishMessage(template);

Now, Publisher, EmailConfiguration, Template, and TemplateBuilder are all candidate assets that are available for other classes to reuse. If you have other types of configurations, they can be included as well and bound polymorphically. This concept can be further extended based on the quantity and quality of variations. For instance, the message construction can be realized using a common interface with multiple implementations. The message itself might have standard and personalized content.

You may move to a more modular version iteratively. Which version do you think facilitates reuse, faster integration, and higher productivity? This new design will make it easier to test message construction independently from publisher.
Like this post? Subscribe to RSS feed or get blog updates via email.

In what fresh magazine can you read the following stories?

• Agile coaches Rachel Davies and Liz Sedley share advice on coaching your Agile team.
• Bill Dudney walks you through building a rudimentary multiplayer game for the iPhone.
• Frederic Daoud shows you how to create Stripes extension classes to customize the framework to your needs.
• Brian Tarbox tells you simple strategies for avoiding dumping your mental stack.
• Staffan Nöteberg (that’s me) explains the pompatus of Pomodoro.

Of course it’s PragPub issue #5. It was released today. You better check it out; right away if you want your friends to rate you as an early adopter:

• http://www.pragprog.com/magazines

(BTW: Pomodoro Technique Illustrated went straight to the top of the league in its first month. The book is right now #1 on direct sales from Pragmatic Bookshelf’s online store. The full list is of course in the PragPub magazine—at page 2)

PragPub #5

Making the right decisions in the middle of an iteration or release cycle is risky and needs good judgment. Investing in a reusable asset is no exception.

What can help you take decisions on whether it is worth investing the time and effort for making a software capability reusable? The single most important factor is business relevance. Is the capability a priority for your business? Even if it is not a priority, is it one for the medium or long term? If the answer to these questions is no, you shouldn’t invest valuable resources into making your capability reusable. Yes, if it isn’t relevant, it needn’t be reusable. Assuming a capability is business relevant, there are several considerations you can think about:

Design Considerations:

1. Do you have user stories that either directly or indirectly requires this capability? For instance, if you have a login customer user story, and you don’t have a customer component, this is an opportunity to create one. In the same vein, the login customer story itself might have variations. What are the different kinds of login that you need to support? Username/password, username/password/special verification text, email/password, username/random set of questions, username/defined set of questions etc.
2. Do you understand the extent of variability that is required for the asset? Consider the ratio of the features that vary a lot vs. the overall functionality.  Even if you end up with a gross, high-level percentage it will help you during design.
3. Consider specifically the aspects that vary and the number of variations you need to support. This is very critical to plan for the reusable asset. Remember, you are pursuing iteration not perfection! Draw a distinction between the variations that are an absolute must vs. ones that can be built over time. If you look back at the first point, maybe your business only needs the simple login using username and password. In that case don’t rush into building in variation support. On the other hand, if they come back and ask for multiple kinds of login you can always refactor to support variability.

Process Considerations

1. Will the capability add significant schedule or technical risks? If so, you need to make this transparent and get clarity from your sponsors. You can explain the rationale for investing in a reusable capability if there is business relevance. Similarly, if schedule risk is unacceptable or you have other higher priority assets to build, refactor, etc. then add this asset to the refactoring list and revisit later.
2. Will the capability introduce deployment changes? Does it need an additional resource such as a database, a configuration file, or is dependent on an external service provider? In that case you will want to run it by your production support and operations partners and get their buy-in.

Like this post? Subscribe to RSS feed or get blog updates via email.

Here is a free e-book on tips when pursuing agile software reuse. It introduces the rationale for software reuse, the need for agility, and lists twenty quick tips to help you succeed with your initiatives. Enjoy!

Tips When Pursuing Agile Software Reuse

Like the ebook? Subscribe to RSS feed or get blog updates via email.

Scrum and Extreme Programming currently dominate named Agile processes. Less well known, but equally important, Agile processes include Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD)

Today’s typical Agile process, no matter what name you call it, takes the best from the buffet of Agile practices to create a typical process where:

1. Project needs or requirements are expressed in user stories placed in a backlog, and ideally written by Product owners (in Scrum), or customers (in XP) in collaboration with the development team. (Sometimes they magically appear.)
2. Developers give high-level estimates saying how long user stories will take to complete.
3. Product owners arrange user stories into incremental releases that take typically 6 weeks to 6 months.
4. Product owners choose the next stories, highest value first, for each development time-box. The stories chosen need to “fit” into the time-box based on how quickly the team can produce software.
5. At the end of each development time-box the team should have incrementally built some of the product. The team (proudly) demonstrates the finished product to product owners and other stakeholders.
6. The team adds up the development estimates for the user stories completed during the time-box. This is the velocity (from XP) that’ll be used to estimate the amount that can be completed in the next time-box.
7. The team holds a retrospective to evaluate how well they’ve done and what changes could be made to the process to allow things to go better, then the next time-boxed development cycle is planned.
8. Time-boxed development continues through to release — which is a short way of saying “rinse and repeat.”

There’s more common practices, such as daily standup meetings to synchronize the team, and burn-down charts to show development progress

Many links are laced through the essay — but here are a bunch in no particular order:

• Toyota production system
• The Poppendieks on Lean Software Development
• Software by Numbers
• David Anderson on Kanban
• Corey Ladas on Scrumban
• Arlo Belshee’s Naked Planning
• Aaron Sanders Kanban ground rules
• InfoQ article from Kenji Hiranabe on Kanban
• My simple Powerpoint presentation on Kanban

via Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit.

Another week, another customer that is either adopting Jazz, or very seriously thinking about it.  I ran into an interesting situation in the past month, and I ran into it twice.  It made me think a little bit about Agile development, Waterfall development, and how Jazz and Rational Team Concert can help an organization begin to get the troops marching in the same direction.

While working with a customer this week, we got wrapped around the thorny fact that while the organization would like to have all of their teams begin using Agile development methods, many of their teams would resist, and some efforts were probably better off being left with their current methodology (Waterfall, Iterative, Spiral, and so on).  The reality of the situation is that in any medium to large sized organization, there will be a period of time where Agile teams and Waterfall teams will need to coexist.  There may be projects and areas of the architecture where Agile is not the methodology of choice.  So after agreeing to this point, my customer asked, “So how do you support this?”.  We also spent some time talking about the differences between Agile, Waterfall, and Iterative methodologies.  Luckily, it was late in the day, so I was able to leave without really answering the question.

Still, the whole concept kept rattling around in my head.  Then it came to me.  What is the BASIC difference between all of these methodologies?  Speed and scope.  (I know, that this is over simplifying things a bit, so all of you methodology zealots keep your flames to yourselves.  I still believe that the core concept holds true.)

Think about it.  In a Waterfall project, we scope the entire project, and then we do the whole requirements -> design -> code -> test thing.  Because the scope is so big, this single iteration ends up taking about 12 months (which just happens to be the budget cycle).  In an Iterative project (RUP or not), we lay out maybe 6 iterations of about 8 weeks in length, and break the work into smaller more manageable chunks, and then do the whole requirements -> design -> code -> test cycle on those smaller pieces.  In an Agile project, we have some sort of vision, and then we make up a bunch of stories that we attack in quick, 2 week bursts.  In each burst, we go through the same requirements -> design -> code -> test cycle, only on pieces that are really small, and we tailor the workload to the velocity of the team.

So what does this mean for a Jazz/Rational Team Concert deployment?  Maybe I don’t need to have a bunch of different processes and work items for each different methodology.  Maybe all that I need to do is provide a framework for a common iteration, and then let the project determine the length of time for each iteration.  This will mean that teams will determine their “agile-ness” in how they interact with their stakeholders, and in how quickly they schedule their iterations.  So now an organization can have a consistent process, consistent work product types (kind of), and collect consistent software development metrics.  Bonus points: A common process, with tailored iteration lengths, is a lot more simple and cost effective to design, implement, support and improve.

The implications of this could be profound for an organization.  Management will be able to look at teams, and determine the optimal iteration length for their teams/projects/applications.  By measuring performance over time, it should be easy to compare the productivity of a team, and the quality of it’s work, based on the length of the team’s iterations.  Do my mainframe projects do better with a 2 week, 1 month, or 6 month long iteration?  Do my web applications do better with 2 week, 3 week or 4 week iterations?  As an organization, are maintenance activities better done with longer iterations or shorter iterations?  Does my Killer Bee team do better with longer or shorter iterations?  How does risk factor into this?

It’s an interesting thought.  So I guess ALL software teams are Agile, they just have different iteration durations.  I would love to see someone try this out.  Is your organization struggling with this issue?  How do you look at the adoption of Agile practices in software development?  Let me know, I am interested in seeing what Jazz (and non-Jazz!) users are seeing out there in the trenches.

Managing Iterative Software Development Projects

By Kurt Bittner, Ian Spence

Publisher           : Addison Wesley Professional
Pub Date            : June 27, 2006
Print ISBN-10 : 0-321-26889-X
Print ISBN-13 : 978-0-321-26889-1
Pages                   : 672

Last Friday’s class was mostly about Project Management, a term which has always meant almost nothing to me and has even struck mild dread into my soul – till now!

Since then i’ve been reading the suggested parts of the 37signals e-book and some other links. This evening i’ll start on the GTD and Lifehacker links provided in the tutorial handout. I’ve been looking around at other web-sites, both those suggested in the tutorial handout and others i’ve found, such as these:

http://www.dhsspsni.gov.uk/guidance_on_register.pdf
I got the idea because the NHS is all over the news at the moment. Page 15’s spider diagram is particularly interesting because i hadn’t thought about doing it like that, though i’m not sure how relevant it is to our project – yet!

http://www.brighthub.com/office/project-management/articles/50212.aspx
Questioning the budget-scope-time triangle. I do think there are no absolutes and there will be changes throughout the duration of the project.

Traditionally bound books:

I’m part way through the Steve Krug book which is easy to read. I also got a book out of the library i used to work in which actually turned out to be of no use in this case as it turned out to relate to a different kind of project. Never mind. I’ve got Kelly Goto’s ‘Web Redesign’ from Brighton university’s library and i’ll start on that later when internet-blindness sets in.

Wish i lived here

Some of the things that didn’t surprise me at all about good project management include:

• Excellent communication is required
• Prioritising tasks is essential
• Contingency planning is essential
• Different things motivate different people
• Chasing ‘assets’ (images, text) from the client is a major source of delay – sigh.

Some things that didn’t occur to me but on reflection are obvious, actually, include:

• The client is part of the team which manages and completes the project
• ‘Resources’ mostly means people (though of course includes money, technology etc)
• Some tasks might have to be de-prioritised to the point where they fall off the bottom of the list and never actually get done
• Drawing up a risk register

Completely new to me:

• Waterfall, iterative and spiral approaches
• ‘Critical paths’
• Drawing up a list of assumptions
• Project management tools, such as Basecamp and Microsoft Project

from hiphopsideproject.com

What i found really interesting was the iterative approach, where you smash the project up like cinder toffee into what is basically a list of tiny pieces, each one with its own ranking: none may have equal importance.

That means major overlap between team members’ tasks, so each one really needs to be a good team player, not precious about their own area, unafraid of criticism and protentially having their work trampled. There is no room for control freaks!

I’m both delighted and fascinated by this – although i’m not at all competitive and could handle this quite happily, i’m not sure i know anyone else like this. I really want to seek out ’good’ teams which take this approach to see if they actually work like this.

I was very interested to hear about Googlewave (which was also mentioned as a possibility for a future project management tool) although i didn’t manage to watch the entire 1 hour 20 minute video on their site! From what i can gather, it’ll be a combination of Googledocs and real-time chat – to the extent that users may also be able to see each other type (and delete) pretty much character-by-character. Some people’s comments indicated they weren’t happy with this! I imagine there’s considerably more to it but i’m hoping to get a proper look at it at some point.

You can practice minimal design to be effective with systematic reuse. The design needs to continuously look for opportunities to align iteration goals with your systematic reuse roadmap. Too many developers mistakenly think that adopting agile means abandoning design. This couldn’t be farther from the truth. You design whether you explicitly allocate time for it or not. Your code will reflect the design and you will impact the technical debt for your codebase in one way, shape, or form. Implementing user stories and paying down technical debt should be your end goal and not avoiding design altogether.

The first priority is to design for meeting your iteration goals. Avoid designing for several weeks or months and surely avoid putting technical perfection ahead of delivering real user needs. You should design minimally. Just enough to take advantage of existing reusable components, identify new ones, and plan refactoring to existing code. Specifically this means:

1. Keeping a list of short term and medium term business goals in mind when designing
2. Always looking for ways to make domain relevant software assets more reusable
3. You are aware of what distribution channels your business is looking to grow
4. Design reflects the domain as close as possible and that your reusable assets map to commonly occurring entities in your business domain
5. Value is placed on identifying the product lines that your business wants to invest in and evolving your reusable assets to mirror product line needs.
6. Design isn’t a pursuit of perfection but an iterative exercise in alignment with your domain.

What you decide to encapsulate, abstract, and scale are all natural byproducts of this design approach. Rather than spend a lot of effort with big upfront design you can do just enough design.

Like this post? Subscribe to RSS feed or get blog updates via email.

Three Pomodoro sessions this autumn

I’ve been invited to present Pomodoro Technique on three occasions in November-December:

• Devoxx09 November 16th – 20th, Antwerp, Belgium
• Ciber 35 years anniversary November 26th, Stockholm, Sweden
• Dansk-IT Agile’09 December 2nd – 3rd, Copenhagen, Denmark

Pomodoro Technique Illustrated – at Amazon and almost anywhere

My book Pomodoro Technique Illustrated can now be pre ordered from any online book store, e.g.

• Amazon (US)
• Amazon (Europe)
• Barnes & Noble
• Whatever

Very soon it will also be available at Pragmatic Bookshelf. Right now we’re having a tech (peer) review. It will hopefully be finished in next week. After that, the book is in the shop-window.

(This is an excerpt from the book Pomodoro Technique Illustrated)

In 1933 Hedwig von Restorff performed a set of memory experiments. Her conclusion was that an isolated item, in a list of otherwise similar items, would be better remembered. If I read a shopping list with one
item highlighted in azure blue, it’s more likely that I remember the highlighted item than any of the others. This is now identified as The
Von Restorff effect.

The Now List is not another artifact in Pomodoro Technique. It’s my name for a concept: what I give my attention to right now. The cardinality of my Now List is binary. Either I focus on 1 activity or 0 activities. It can
never be 2, 3, 4 or any other number of activities. Before I wind up the clock, I choose one single activity. My challenge during a 25 minute Pomodoro is to not give another activity attention for a minute or two.

The Von Restorff effect tells me that I can provoke my memory to store things that I highlight. I may use a highlighter felt-tip pen to mark the current activity on the To Do Today sheet. Or I can explicitly write the
activity title on a slip of paper and put it in front of me.

The Now List

Pragmatic Bookshelf

Since February, 6000 people have downloaded the draft of my book Pomodoro Technique Illustrated. To have 6000 readers in the first six months was above all reasonable expectations. Many of you have sent me e-mails with comments, corrections and other kinds of feedback. I have read, analyzed, modified, and above all learned an awful lot.

Rumors have spread, and recently it became clear that the book – or a version of it – will be published by Pragmatic Bookshelf. It is as paperback, PDF, mobi (Amazon’s Kindle) and epub (eg Apple’s iPhone and iPod Touch) – perhaps even as podcasts. Right now it looks like it will be released in February 2010.

Thanks to everyone who has helped me so far! I hope you will enjoy the new book.

Pomodoro Technique Illustrated book cover

This article on Wired talks about the increasing trend for tech companies to produce new products quickly and with fewer features. They say this is due to a demand from consumers to get access to new technology early and they’re willing to relinquish features in order to achieve that.

While the article is about tangible tech products this applies equally to the online world of web design and development. Too often I see companies striving to release the perfect, polished web site, app or piece of functionality and by the time it’s released into the wild it’s either no longer groundbreaking or it’s been done by someone else already. Being agile is important, iterating quickly and releasing early versions as soon as they offer value to users is the way to go particularly for e-commerce businesses. Amazon does this well, through a combination of an agile mindset and the great set of multivariate testing tools it has at its disposal. Get features to market quickly, test their effectiveness (really important) and iterate their development. Good enough really is ‘Good Enough’ if it’s adding value for your audience and making you more money. I can think of a few industries who could really do with adopting this mindset…