AgileHolland

Johanna Rothman: Webinar for Geographically Distributed Agile Teams on Feb 15, Noon Eastern

Tue, 07 Feb 2012 14:50 GMT

Please join Shane Hastie and me for a webinar about our Geographically Distributed Teams workshop on Feb 15, at noon Eastern.

Want to make your geographically distributed agile projects more effective? Join Johanna Rothman and Shane Hastie for this webinar where they will discuss their workshop, Working Effectively In Geographically Distributed Agile Project Teams. We’ll address a few of the common problems of geographically distributed agile teams, and then open it up for your questions.

Even if you can’t make the webinar, please sign up so I can tell you about the recording.

Failure IS an Option

Tue, 07 Feb 2012 13:24 GMT

This is an article asking you to fail. More precisely: Fail now for greater success later. One of the five Scrum values is courage. Courage to point out problems, ask for help, receive help, and most important take risks even thou...

Article: 10 tips on how to prevent business value risk

Tue, 07 Feb 2012 07:01 GMT

One category of risk that project teams need to ensure they address is business value failure ? delivering a product that fails to provide value for the business investor. The authors provide insight into the underlying causes of business value risk and provide ten tips on how to avoid them. By Chris Matts and Olav Maassen

Article: Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

Tue, 07 Feb 2012 04:34 GMT

Nick Rozanski and Eoin Woods have continued their journey of building a comprehensive handbook on Systems Software architecture with the publication of the second edition of Software Systems Architecture. InfoQ spoke to the authors on a couple of new topics, the System Context viewpoint and Agile, that are covered in the latest edition. By Jeevak Kasarkod

Johanna Rothman: Geographically Distributed Agile Teams Have Choices for Their Lifecycles

Mon, 06 Feb 2012 10:56 GMT

I hope that by now you see that you have any number of choices for your lifecycle if you are geographically distributed team and you are transitioning to agile. I do recommend a servant leader agile project manager, for coordination and risk management. With people all over the world, it’s difficult to coordinate the project, which leads to more risk.

Scrum is often not the best approach to geographically distributed agile. That does not mean the distributed team should not go agile. It just means they should not use Scrum. If the distributed team can all travel to one place so they can get trained by the same Scrum trainer together, and if they can take the opportunity to talk together to discuss what they need from the Scrum Master then maybe they can use Scrum, especially if they use their retrospectives well. It’s a lot of responsibility for the team new to agile and new to Scrum. If you’re a team new to agile and new to Scrum, and you try this, do yourself a favor and use a coach.

Electronic tools do not always make seeing and managing the risk easier when you first start–tools can prevent transparency until you understand what you are doing. I like starting with stickies or cards on a wall or board, and as the team members learn how to work, and what they, as a team need, then choosing a tool. I don’t see how to choose a tool before you know what tool you need. One tip: do not allow your management to select a tool for you. You, as a team, can select a tool for yourself. You might start with digital pictures of your task board on a project wiki before you decide which tool to use.

Let me recap:

Agile Lifecycles for Geographically Distributed Teams, Part 1 discussed iterations and silo’d teams.

Agile Lifecycles for Geographically Distributed Teams, Part 2 discussed kanban and silo’d teams.

I got all hot under the collar and discussed Why an Agile Project Manager is Not a Scrum Master.

Agile Lifecycles for Geographically Distributed Teams, Part 3 discussed iterations and kanban and silo’d teams.

You should also read What Lifecycle? Selecting the Right Model for Your Project.

If you have several teams all working towards one business goal, you have a program, and that is a different problem. Look for more blog posts on that, later.

These are precisely the problems no one teaches you in project management certification courses. If you have read Manage It! Your Guide to Modern, Pragmatic Project Management, you know I consider knowledge of different lifecycles necessary for project managers.

Project managers who try to control their teams better have a darn good reason–these people are adults. They manage the rest of their lives. Are you trying to tell me they can’t manage their work? And, these are the problems that can cause geographically distributed projects to fail, splat.

If you want to learn to work more effectively on your geographically distributed team, please join Shane Hastie and me in a workshop April 17-18, 2012. We would love to have you.

Interview: The Seven Deadly Sins of Enterprise Agile Adoption

Sat, 04 Feb 2012 07:41 GMT

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Does success at the team level always result in success at the organization level? Sanjiv Augustine and Arlen Bankston discuss the Seven Deadly Sins that organizations repeatedly make so you can steer clear of them and benefit from a successful Enterprise Agile Adoption. By Sanjiv Augustine and Arlen Bankston

Stoos Network - Catherine Louis and Deborah Hartmann Preuss Discuss their Expectations

Fri, 03 Feb 2012 21:33 GMT

Continuing the series of interviews with Stoos Network Event participants, Shane Hastie spoke to Catherine Louis and Deborah Hartmann Preuss about their experiences at the event and their hopes and expectations for the future of the Stoos Network. The Stoos Network aims to encourage shift in organisational management from traditional hierarchical leadership toward more collaborative approaches. By Shane Hastie

Johanna Rothman: Agile Lifecycles for Geographically Distributed Teams, Part 3

Fri, 03 Feb 2012 09:37 GMT

Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Coaching Agile Teams

Thu, 02 Feb 2012 13:21 GMT

Two words, Agile and coaching, seem to be the most-used buzzwords (after brain and neuro) of the last five years or so. The way things are progressing, I see them staying at the top of the list for decades.

Johanna Rothman: Why an Agile Project Manager is Not a Scrum Master

Wed, 01 Feb 2012 11:01 GMT

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

Explain that velocity is not a productivity metric
Say No and explain why
Play the Double Your Velocity schedule game
Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Why Application Release Automation needs a Release and an Operations view

Tue, 31 Jan 2012 19:30 GMT

As the interface between Development and Operations, Application Release Management¹ handles information that is highly relevant to your Release and Operations teams. Selecting an Application Release Automation solution that provides insight and analytics from both perspectives is thus a key component of an effective DevOps strategy.

Here, we explain how Deployit‘s Infrastructure and new Release Overview features help you achieve this goal.

Continuous Delivery & the Release Perspective

In today's highly competitive economic environment, the need to bring new features to market quickly, flexibly and reliably is paramount – a goal that is ultimately the aim of the main IT trends Cloud, Agile and DevOps.

Continuous Delivery – extending Continuous Integration to automatically transition applications down the Dev-Test-Acc-Prod delivery pipeline – is a key component of this strategy. In order to be able to effectively implement this, your ARA solution needs to allow your developers – or, in larger organisations, release or DevOps teams, to quickly and efficiently answer questions such as:

How far is MyApplication down the road to Production?
When will MyApplication take the next step down the road?
What do I still need to do before that next step can be taken²?

Ideally, this dashboard would also allow you to plan MyApplication‘s next step and calculate the estimated go-live data, perhaps even based on an analysis of previews versions of MyApplication.

(Virtual) Environment Management & the Operations Perspective

From an Operations point of view, an individual application is only a small part of the picture. Across your Dev-Test-Acc-Prod landscape, you will need to track all applications vying for these environments, to manage potentially conflicting resource requests, plan environment maintenance activities and the like.

Since these environments are often owned and managed by different teams and certainly have varying service levels, you will also want to limit your view to one or a subset of these environments at a time.

Your Operations or DevOps teams need to know:

Which application versions are currently deployed to my environment(s), or were deployed at a certain point in time?
Which components do these applications consist of? On which middleware and infrastructure systems are these components deployed?
What are the current values of any properties or settings for these components? Which environment-specific customizations have been applied?

Cloud and the on-demand environments it enables will eventually replace the rigid Dev-Test-Acc-Prod distinction³. Nevertheless, the ability to present an environment-centric view will still be required, since virtual environments will still be owned by different groups or teams. Indeed, such a perspective will be even more important if you want to effectively combat “virtual sprawl”.

While the coming generations of “true” cloud architectures will hopefully reduce the shared resource conflicts that greatly complicate much of today's Dev-Test-Acc-Prod management, databases, legacy systems and external payment providers are not likely to disappear anytime soon.

In fact, Facebook, Twitter and other social elements of your future business services may even increase the number of shared resources you need to manage!

Incorporating ARA Data in the Service Delivery Picture

Whilst your ARA solution should be your “go-to” platform for answers about how your applications and environments relate, it is equally important to consider when this data might be more effectively embedded in a broader service delivery picture.

For example, your ARA platform is not a good candidate for providing a release calendar, since it is not aware of much of the information that is relevant in this context, such as CAB⁴ meeting schedules, business sign-off dates or operational maintenance windows.

It is thus important to ensure that your ARA solution can make its data accessible via APIs such as RSS feeds, iCal calendars and other APIs, to enable effective integrations with the rest of your service delivery tooling.

Conclusion

The right Application Release Automation platform gives your Delivery and Operations teams fast, accurate insight into your application environments and delivery pipeline.

Choosing a solution like Deployit with focused Operations and Delivery overviews as well as open APIs for easy integration into your overall Service Delivery dashboards and reports greatly enhances the accessibility and effectiveness of your application release management.

Footnotes

a.k.a. Deployment Automation – choose your favourite
For instance, certain blocking release conditions, such as test sign-off, may still need to be met.
and have long done so in many forward-looking organisations
Change Advisory Board

Budgeting a Scrum Project in a Fluid Environment

Mon, 30 Jan 2012 15:48 GMT

Agile, and Scrum in particular, are buzzwords. Everyone wants to try out Scrum and reap its benefits. Clients (especially business clients) see a big advantage in not having to wait till all the requirements are carved in stone before starting a p...

Agile Testing: Key Points for Unlearning

Fri, 27 Jan 2012 11:15 GMT

When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them.

Agile is niet te vermijden

Fri, 27 Jan 2012 08:08 GMT

Net�als�in 2010 heeft�Xebia�in 2011�het�jaarlijks onderzoek naar de de status van Agile in Nederland�uitgevoerd.�Met ook dit jaar weer opvallende�resultaten. Zo zegt bijna 90 procent van de bedrijven die met Agile werken sterk verbeterde resultaten te realiseren bij hun (ICT) projecten. De vraagt die direct bij mij opkomt bij dit soort hoge percentages is waarom niet iedereen met Agile aan de slag gaat.

Daarnaast ervaart 83 procent van de Nederlandse bedrijven die Agile werken hebben geadopteerd, meer werkplezier en 85 procent meer teammotivatie. Dit percentage is aanzienlijk hoger dan vorig jaar, toen gaf driekwart van de respondenten aan meer werkplezier en teammotivatie te ervaren.�Dus de mensen die Agile werken�varen er wel bij, naar mijn mening een van de belangrijkste redenen voor het succes van Agile. Dit komt ook veelal tot uiting in een lager ziekteverzuim en grotere loyaliteit naar de werkgever toe.

Andere belangrijke effecten zijn een verkorte time-to-market volgens 79 procent van de ondervraagden en toename van de productiviteit (66 procent). Het onderzoek laat ook zien dat kostenverlaging een belangrijker effect van Agile werken is dan vorig jaar (38 procent in 2011 tegen 21 procent in 2010). Niet zo vreemd�natuurlijk�in deze economisch zware tijden.�Maar dit betekent wel dat Agile steeds meer wordt ingezet als onderdeel van een�kostenverlagingstraject.�Dan is het wel heel belangrijk ervoor te waken,�dat met het (meer) sturen op deze doelen de Agile gedachte niet ten onder gaat�in�de zoektocht naar kostenverlaging. Indien kostenverlaging wordt neergezet als primair doel met Agile als middel, is de kans groot weer te verzanden in ‘ouderwets' contract en KPI management waarvan we in het verleden nou juist geleerd hebben dat dat niet effectief is.

In de overgang naar het Agile werken is de bedrijfscultuur net als vorig jaar de belangrijkste bottleneck voor veel organisaties (49 procent). En ook dat is geen nieuw inzicht.�Maar het is wel iets�dat te�vaak onderschat wordt, zeker door belangrijke personen die juist onderdeel zijn van die bestaande bedrijfscultuur.�De adoptie van Agile vereist veel focus en energie voor langere tijd en de daadwerkelijke borging vindt plaats juist via een inbedding in die bedrijfscultuur.

Door het verbeteren van kennis, kunde en bovenal mindset van Agile zal de uitrol een grotere kans van slagen hebben. De ondervraagde organisaties erkennen dit gegeven zelf�overigens�ook, want volgens 36 procent is een gebrek aan kennis en kunde de belangrijkste beperkende factor in de (verdere) implementatie en uitrol van Agile. Door juist in deze economisch�uitdagende�tijden�in kennis, kunde en mindset van Agile�te investeren zullen organisaties meer rendement kunnen behalen. Het verbeteren van bedrijfsresultaat is nu bijvoorbeeld voor veel financi�le instellingen in Nederland een belangrijke reden om Agile te gaan werken: zo kunnen zij namelijk effectief hun te hoge kostenstructuur aanpakken.

Agile belooft dus veel, maar�maakt�dit�ook waar. Zeker gezien de huidige generaties Y en Z die nu opgroeien en de toekomstige werkbevolking van Nederland gaan vormen, is er geen ontkomen meer aan (iets als) Agile. Regelmatig spreek ik diverse (jongere) sollicitanten die Agile, en de manier van werken en omgaan met elkaar die daarbij hoort, heel normaal en gewoon vinden en die gruwelen bij een beschrijving van het traditionele waterval model en bijbehorende werkaanpak. Het aantrekken van jong talent en een werkwijze die niets met Agile of elementen daarvan te maken heeft, staat bijna haaks op elkaar. Blijvende continiuteit en succes op langere termijn voor ieder bedrijf bestaat voor een belangrijk deel uit het aan kunnen blijven trekken en behouden van jong talent. Agile worden of zijn, lijkt hier een belangrijke voorwaarde voor te zijn.

Ik ben benieuwd wanneer�u op de succesvolle trein stapt die Agile heet!

One practice a day…

Wed, 25 Jan 2012 16:22 GMT

Suppose one day, after a particularly bad hangover, you decide to change your life.� You long for a trim body, a balanced spirit, lots of energy and no more headaches. In short, a happy mind in a healthy, good looking body. But how do you get there?

Well, we all know that there are many practices that will help you achieve those goals.� Exercise three times a week, stop smoking, reduce your alcohol intake, and change your eating patterns. Oh, also, get more sleep, less stress, no more pills, and drink herbal tea instead of espressos.

But you hate sports, you love chocolate and smoking is your way to reduce your stress. �So what do you do? (And what does this have to do with Agile? Read on and you'll find out….)

The daily fruit practice

In order to get healthy,�you decide that from now on, every day, you will eat a piece of fruit at lunch. ��It?s pretty easy to do, even though you don?t like fruit very much. �So now you are satisfied, you do a healthy thing every day, and you expect to reach your goals (more energy! greater happiness! better looks!) anytime soon.

Will you? Of course not! While the daily piece of fruit is a step in the right direction, you will never fully get the benefits you are seeking�if you keep up your old habits of smoking, drinking and eating greasy food,. And after a while you might even get disappointed and frustrated, and you will decide to stop eating fruit, claiming that ?a healthy lifestyle simply doesn?t work for you?.

Doing just one healthy practice, or even a couple of them, isn?t enough. What you really need is to change your mindset. You want to be a healthy person, not do some healthy stuff. Once the healthy mindset becomes your way of life, the practices will simply be the natural way to go. And they will be a lot easier to start with and maintain for a long time.

The daily Agile practice

The same applies to Agile. We see many companies and teams that ? do? Agile. They take a couple of practices from an Agile framework such as Scrum, and they figure that that will be enough to give them all the Agile benefits. Some teams even think that if they just do a daily stand-up, they do ? Agile?.� While daily stand-ups, just like that daily piece of fruit, are definitely a good practice, your are still far removed from true agility if the rest of your behaviour consists of old, non-Agile practices.

A company or team only gets the most out of being Agile, when its mindset is based on the Agile principles stated in the Agile manifesto, such as continuous learning at all levels in the organization, business and IT working closely together, delivering the highest business value first, welcoming change, and creating an environment where motivated individuals can be creative and self-directing.

So if you are doing ?some? Agile, expand your practices. But more importantly, change your mindset. Don?t do Agile, be Agile. And remember:

One practice a day does not keep the old habits away…

Johanna Rothman: Agile Lifecycles for Geographically Distributed Teams, Part 2

Wed, 25 Jan 2012 11:06 GMT

Example 2: Using a Project Manager with Kanban, Silo’d Teams

This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.

This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.

The New York developers had a problem biting off more than they could chew. So nothing moved across their board. The Italy developers had a board where the work did move across the board. The teams took pictures of their boards every day and shared the work across a project-based wiki. That allowed the New York-based developers to see the work move across the Italy board. And, that encouraged the New Yorkers to call the Italians and ask some questions. That helped the New Yorkers to change the size of their work by working with the product owners.

Now, why did the New Yorkers have such trouble originally? Because the developers “knew better” than the product owners, so they changed the stories into architectural features when they had originally received them. (Now they don’t. They leave the stories as real stories.)

Release planning: Management in California plan with agile roadmaps. They have features planned specifically week-by-week for the next 6 weeks, and have more of a quarter-by-quarter approach after that.

Iteration planning: No iteration planning because they are using kanban.

Daily commitment: No daily commitment needed because they use kanban. They do have a checkin a few times a week with each other as a technical team to make sure they don’t create bottlenecks and that they respect the WIP (work in progress) limits.

At one point, both the New York and Italy developer teams created automated tests so that the testers could catch up and stay caught up with regression tests. They add a story like that every couple of weeks, and they are paying down their automated testing debt.

The Project manager keeps an eye on the WIP, work in progress. Project manager also shepherds the product owner into keeping the queue of incoming work full and properly ranked. The product owner is notorious for changing the incoming work queue all the time. Project manager makes sure the team does retrospectives and is a little unclear how to do them in such a distributed team. The project manager is not so sure their retrospectives are working, and has started an obstacle list, to make sure the team has transparency for their obstacles.

Measurements: cumulative flow, average time to release a feature into the product.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Is Documentation Really Wasted Effort?

Tue, 24 Jan 2012 17:23 GMT

A widespread myth I've noticed in Agile software development is, No documentation in Agile or Documentation is wasted effort. Particularly during a transition from Waterfall to Agile, we appreciate the benefits of adopting typical Scrum practices, such as short iterations, timeboxing, daily scrums, retrospective, and so on. We also try to get away from the tasks and activities that we found monotonous before Agile adoption documentation, writing proper code comments, etc. But is it really correct to completely stop documentation and code comments?

Waterfall to Scrum: Transitions and Crossroads

Tue, 24 Jan 2012 17:06 GMT

I was at home a couple of Sundays ago, watching a Chelsea vs. Liverpool football match (soccer, for those Americans reading) a match Liverpool ultimately won. It was during the post-match analysis that I was struck by some parallels between what Chelsea is going through and my own current client engagement to move from Waterfall to Scrum.

Scrum For All: Deja Vu?

Tue, 24 Jan 2012 16:49 GMT

I've always wondered -- not just as a developer but as a human being -- why I needed to follow the orthodox methods of typical hierarchical reporting. There was always some middle man confusing the conversation. You can define many roles in a typical hierarchical organization, and

Tracking Individual Performances in Scrum

Mon, 23 Jan 2012 08:17 GMT

A question I've heard often is: Is it correct, in Scrum methodology, to track an individual's performance? This question has only one answer: No. Tracking and measuring the productivity of a single member of an Agile team is against the spirit of Scrum. The real question should be...

Scrum for Services

Fri, 13 Jan 2012 13:47 GMT

Product Owner Scaling Problems

Fri, 13 Jan 2012 05:45 GMT

Scaling the productowner (PO) role is tricky business. When you scale up too much within the same context, things become cumbersome. We don?t want to bring back the same centralized fear ridden ineffective decision making climate, we tried to kill off in the first place. When people spend so much time and effort to bring back entrepreneurship, they don?t want to create layer over layer of hierarchical PO/CPO relationships.
So if there is this perceived risk of fallback involved, why do we actually want to scale the PO role at all?

Here are some reasons I came up with when thinking of a project context(*)

The perceived need for scaling could follow as a reaction to the scope of the project at hand. It is quite common within projects to try and do as much as possible parallel development of different semi-detached functional areas of the product. This comes quite close to how I used to manage projects in the past. Whatever in the same timebox could be done in parallel, should. I was very efficiency driven back then, but also taught and stimulated to think this way.
Within this paradigm it would be preferable, that the PO has some sort of party around him helping to create the user stories he would be in charge of. Creating big teams gives us more capacity to do more work in our timebox. Larger teams and more work create the need for more coordination, because of limited span of control, thus creating the need to scale.

Also, I think we are still very much driven by the paradigm of the chain of command. It is simply comfortable when there is someone who can make the tough decisions for us and mediate between us whenever conflicting interests arise. The need for extra coordination between and over PO?s in the same context thus fits very naturally with our needs in a growing project context.
Come to think of it, maybe it is no coincidence that the person designated CPO is more times than not the first PO that was on the project. If we look deep within ourselves wouldn?t every PO actually want their first project steps to be so successful, that the extra means are granted to grow the team and consequently rise above to lead the way as CPO? And should we be that CPO, would we ever fully trust another colleague with the work we carefully prepared and poured our blood sweat and tears into? It would be great if we could somehow keep some sort of supervision on the others. Make sure the projects success and our hard work isn?t killed off in the next sprint or two. Scaling with a CPO construction would provide means to fulfill these needs.

Of course the above reasons to scale could be valid, but there are also downsides to them.

Although doing parallel work may sound efficient, maybe validation with your customers shows that the product increment doesn?t fulfill their needs as thought up in the first place. Since you have done a lot of parallel work, the risk of waste is also greater. Should you need to radically pivot your product in another direction, it will be much harder due to the already large scale of your operation.
I thus think that scaling towards having different teams work on the same backlog potentially inhibits us from maximizing validated business value, as you are pulling forward less important features from the backlog, before actually validating and thereby knowing whether you have actually delivered value with your top items. From this angle, it would be wise considering not to scale.

When scaling from success, we run the risk of slipping into a power monger mode and form a team beneath us to gain status and control instead of branching out sideways.
When this happens we are not working towards joint company stakeholdership any more, but we trying to build our own ivory towers. When the CPO leading the PO?s claims decisive power in certain areas, I believe you would not be creating the right entrepreneurial environment in which decisions are based on arguments and value for the customer and company. Maybe, as a PO, if you already know you need a decision from the CPO, you are inclined to use other influencing methods rather than comparable and less subjective measures than for example business cases, jeopardizing the quality of decision making and therefore the success of the product.

During my study, I was taught ?there is no one best way to organize?. I think of this line as a universal truth, that in my opinion also applies to scaling the PO role. I therefor think that form is less important than the route taking you there. Knowing that there are risks involved in scaling and consciously dealing with them helps you along this route to find a form that works for you.

(*)Scaling is also common in productline contexts (for instance a CPO over a group of PO?s managing a product family) or within business units where you would have various strategic themes that the CPO would like to have implemented over the same time period.

Scrum Alliance Newsletter: January, 2012

Wed, 11 Jan 2012 10:54 GMT

Scrum Alliance Newsletter: December, 2011

Wed, 11 Jan 2012 10:53 GMT

Scrum Alliance Newsletter: November, 2011

Wed, 11 Jan 2012 10:51 GMT

Innovative Agile

Fri, 23 Dec 2011 10:01 GMT

My motto regarding innovation is: being a first mover is a strategic choice, moving fast isn?t. Agile and scrum can help you move fast, so how can it accommodate innovation?

Getting a view on innovation
When a company fills in a portfolio tool like a Boston Consulting Group (BCG) matrix, it gets a view on its product market combination (PMC) portfolio. You can tell a lot about the company and its business from how a BCG matrix (*) develops over time. One of the most fun things in my eyes is the amount of question marks turning into stars. A question mark being a PMC in a high growth, low share section (e.g.; doing something relatively new), a star being a PMC in a high growth, high share section (e.g.; being successful in doing new stuff).

The amount of question marks in the portfolio illustrates the amount of newly launched PMC?s on to target markets. When you also consider the amount of ideas not becoming question marks, and turn this into a ratio, you could get some idea on how innovative the company is. Add to his the amount of question marks turned into stars and you really get a sense of outward successful innovation. I distinguish outward and inward innovation, because I believe that experiencing a commercial hypothesis to be proved wrong is at least just as valuable as seeing it proved right.
This doesn?t mean that innovation can?t be applied in other quadrants, just that it might not be the smartest thing to do when for instance handling dogs. In many cases adding features to cash cow products can be a brilliant strategy. Take for example razors, where adding more razorblades, self-adjusting blades and other sleight handling improvements constantly extends the product lifecycle.

Innovation flavours
To get an idea of how scrum could accommodate for innovation, first we have to get an idea on the various sorts of innovation like ?additive innovation? out there. In general there are four forms of innovation a company can venture into:

Incremental innovation: small improvements leading to slightly better results

Additive Innovation: adding product features, customization, new products in existing business lines

Complementary innovation: creating new offerings new in current business, but adjacent to current product lines

Radical innovation: doing completely new things, unknown to business and/or target markets.

Using agile to suit innovation
In the following section I will highlight a couple of alternative ways in which you could use agile and scrum mechanics to shape and facilitate these forms of innovation:

Incremental innovation:
1. Spend a retrospective or a section on this product improvement; try to get in one small improvement each sprint. Maybe this will ease the team into providing more input for the backlog.
2. Agree with the team that every sprint every individual team member comes up with at least one idea to improve the product in some way.

Additive innovation:
1. Create spikes in sprints to prototype new features, validate these with customers;
2. Hold demo like meetings with your target audience; ask them what they think about the product.

Complementary innovation
1. Keep key options open, have stories worked out in two variations and do validate these paths in spikes and demo meetings;
2. Invest time in finding the appropriate product owner for the job. Market and customer knowledge is important here as the company is going to serve adjacent and different markets than before;
3. Take care that the entire DMU is taken into account in the story map. Also look at internal impact of providing new services and products, for instance customer service needs.

Radical innovation
1. Make sure the innovation team is freed from all organizational gravity. Pull them away from status quo and peer paradigms;
2. Reserve time for existing teams to work on a free format project. This could be a once every month time box of a day for example. It can be whatever they would like, as log as results are made transparent. Let them the same social objects as in scrum (boards, graphs, backlogs);
3. Take care that you have means to measure relevant metrics early on. Every addition should increase sales, market share and other relevant metrics. Use retrospectives to find root causes and steer through story map;
4. Keep all options open, incorporate A/B tests, multi-variant tests, prototypes, feature polls and so on. Sprint goals are hypotheses you would like to see validated.

What I love about scrum, is that it so lightweight and adaptable. On the incremental- to radical innovation scale, there is no step in which scrum can?t be adapted to accommodate for innovation while remaining to move fast.

The above list is just a brain dump of what I quickly came up with. I am convinced that there are many more creative ways in which we could adapt agile and scrum practices towards innovation. Please view this blog as an open invite to share your thoughts on this subject.

PS: Merry Christmas and a very Happy New Year!

(*)A BCG matrix says nothing about profitability of the PMC, so market share in a growth market could be labeled as a vanity metric. The matrix also builds on the premise that you know a market to put question marks in. Sometimes however you don?t know what your market is going to be. Furthermore, the BCG matrix can be filled in numerous ways depending on how you define for example the market scope.

Scrum Gathering Atlanta 2012 Sponsorship Package

Tue, 06 Dec 2011 16:09 GMT

Scrum board. What's the best taskboard and information radiator?

Wed, 11 May 2011 14:00 GMT

About the last 10 years of my Agile experience I have been using various tools to monitor progress and keep an overview and radiate information. Some were more successful than others of course.Some of the "best" products were not always helping. Now at Backbase we use a set of JIRA tools. Before that I used mainly Super Sticky Notes and a whiteboard. To keep track of the numbers and print a

Perfect Feedback

Thu, 27 Jan 2011 14:41 GMT

One of my favourite tools for giving and receiving feedback is the Perfection Game. It is a powerful tool to give constructive feedback in a non-threatening way. It transforms feedback from an attack or personal�judgement�into a constructive act of jointly improving software, articles, conference sessions, blog entries…

The Perfection Game lowers the barrier for giving feedback. It makes it much easier for me to give feedback faster and earlier, and to ask for feedback.�It is useful for any situation where you want to ask or give feedback in a constructive way.

The Perfection Game is simple, but not necessarily easy and not always well understood. So how does it work?

Someone presents their work, like a session proposal, a text, or code, and asks for feedback.
You (the reviewer) rate the work on a scale from 1 to 10, based on how much value you can add. 10 means that the work is perfect for you. In other words, 10 means you don't see any way in which it can be improved.
You explain why you rated the work like you did. What makes up this number? What did you like about it? What should be kept?
You give concrete suggestions for improvement, i.e. actions that would make the work perfect.

An example of a perfection game applied to a session proposal is:

I would give this session proposal an 8 out of 10.

What I like about it:

catchy title, the abstract makes me want to attend

well thought out process, seems realistic for 90 minutes

To make it perfect, I would:

explicitly describe benefits for managers, because it would be good for the discussions to have the manager's perspective in the room

make the link with agile development explicit, so that it appeals to a wider audience

Some remarks:

The rating is not a�judgement, it is an indicator of how much possible improvement you see in the work.
The Perfection Game focuses on the work instead of the person; feedback is in the eye of the beholder.
Your improvement suggestions should be concrete and actionable; what would you do to improve the work?

It's also great for perfectionists like me, to see the positive things and accomplishments as well

I'm co-organizer of�Mini XP Days (1 April, to be announced) and XP Days Benelux (early December). We apply agile principles to organizing it, to make it an agile agile conference. We are feedback addicted and use the perfection game both during the conference, to get feedback about sessions, and in the iterative session review and improvement process, to help presenters develop quality sessions.

The Perfection Game is useful for any work product, code, text, design ideas, documents, blog entries, anything you are creating and you want to improve – it can help you get into a habit of constructive feedback and joint improvement, so that you'll deliver better results faster.

So please do try this at home! (and work!)

Background information

The Perfection Game is part of the Core Protocols by Jim and Michele McCarthy;�I also recommend their entertaining & informative podcasts.
The Perfection Game is similar to the scaling question from the solution focused approach.
Perfection Game summary
Yves Hanoulle has written an article on the Perfection Game and other Core Protocols.
Perfection Games remove noise from developer feedback

The fuzzy thing called lean

Wed, 19 Jan 2011 15:22 GMT

I've been asked to do some presentations and workshops around lean and software development, which gives rise to some reflections on what's currently going on around ‘lean' (thanks to Willem for the good conversations on this topic and for pushing me to publish this blog entry )

Lean is becoming more and more of a hype, see people talking about lean methodology, lean certification, religiously implementing practices and tools like Value Stream Mapping, A3, Removing Waste (hey, I don't like you you don't add value, you're waste!)

Lean is however not about practices & tools. It is primarily a philosophy, a way of looking at your organisation. Lean is about continuous improvement and developing the capability of the organisation and the people capability for improvement (see the Toyota Kata for more about this system that underlies lean).

Lean is inherently empirical, focusing on learning to see things as they are, not as they ought to be. Lean manifests itself in different contexts with different sets of principles and associated practices and tools. Lean works out differently for production processes, for services, for startups, for product development, even for software development there are different interpretations (listen e.g. to the Devnology interview with Mary and Tom Poppendieck)

I notice that a lot of conversations take place at the level of practices and tools, which are the most concrete manifestations. It is much easier to talk about tools, lean ‘methodology' or even having a check list of observable lean practices. There is no general lean methodology, although different organizations can have a situated, continuously evolving methodology of their own, guided by lean principles.

Practices and tools are manifestations of principles and philosophy in a specific context – they're specific solutions to specific problems in a specific context. They might or might not work in another context, even if that context is similar. But you won't know if something works until you've applied it and got actual feedback from practice. This is related to what Dave Snowden writes about innovation diffusion:

Context is everything and often neglected. Something that works in one context may not work in another even if they are very similar. Ideas and practices need to have enough flexibility to adapt and ideally to combine with existing practice and other ideas. It means that pilot approaches have an inherent problem in that the initial success results in a specific context with a lot of effort. It won't necessarily scale.

…and even when things worked out when you applied a practice or tool in your context, then you should be wary of confusing correlation with causation (doing the practice and having success does not imply a causal relation, it could be just correlation or even coincidence) and the retrospective coherence trap (everything looks logical and explainable in retrospect, but this does not help in predicting how things are going to work out).

Practices and tools are most concrete and easier to talk about, but they are the least important part of lean. They are highly situational,� almost random in a sense. To quote Dave Snowden again:

There is a paradox in that highly codified, highly abstracted material diffuses best (…), but is the least likely to be innovative or novel.

So people get stuck in tools, practices, methodologies, instead of focusing on philosophy and principles. The philosophy and principles are generative, setting up conditions that let a lean system emerge. Kanban for Software Development as presented by David Anderson and others is a good example of this.

Agile Tenet #9 ? Attention to Excellence

Mon, 11 Jan 2010 08:54 GMT

�Ninth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Continuous attention to technical excellence and good design enhances agility.

I met Abby Fichtner at the Nashua Scrum Club. Her card included the address of her blog, the Hacker Chick, and since like the elephant?s child I have an insatiable curiosity, when I got home I surfed on over to check out what she writes about. She?s got some great posts over there. I particularly like this one about Craftsmanship where she states that one of the most important lessons of Agile is ?the only way to go fast is to go well.?

“How many times have you been significantly�slowed down by bad code? Martin asks and we can be�sure all programmer hands went up. ?Then why did you write it?? he asks. There is laughter because of the truth in his question. We have all been slowed by bad code and yet, we continue to allow bad code to be written on our projects. And why? Because we didn?t have time to write it well?”

“We must not write bad code. Period. This is a fundamental issue of professional behavior.?
- Bob Martin

As I?ve been learning about Agile, there seems to be�quite a bit of emphasis on not just delivering software, but delivering better software. When we started our move to Agile at my company, there was a lot of emphasis on testing, with added unit tests, test harnesses, test plans, etc. I?m not sure if we meet all the requirements for test driven development, but we?re probably pretty close. Which means that our next release is going to be�of significantly higher quality than our last one. This is good news for our customers, and will hopefully translate into better word of mouth and better sales. I appreciate that the Agile emphasis on speed does not mean that we?re producing sloppy work, but also focusing on quality product.

Abby?s post on Craftsmanship led me to this one where she writes:

“And I just keep thinking back to Clean Code's preface: if we're to call ourselves professionals, we have a responsibility to act as such. And maybe that means we really do need a 5th element for our Agile Manifesto: We value Craftsmanship over Crap.“

So, how do you adopt this tenet to Agile technical writing? As Agile TWs we need to figure out how to not only write faster, but how to write better. And I?ve been lucky enough to have been exposed to automated tools that can help you be a better writer.

At a previous job we were implementing a pilot program with acrolix�acrocheck�(which seems to have been replaced by acrolinx IQ) a style and grammar tool that was designed�to reduce�translation costs. The tool had a number of different�features: it checked spelling and grammar, checked a variety of common style rules (as defined in the more popular style guides), and could be programmed�to check for in-house terminology and style. You could also use it with Microsoft Word, Adobe FrameMaker, and RoboHelp. Part of our pilot program was figuring which rules we wanted to keep and which we were going to disable. For example, our product had a Users application, so we had to decide if we were going to keep the rule “don't use the word user in your documentation.”

I?d always thought I was a pretty good writer, but the first time I ran the tool against one of my projects, I was absolutely horrified by how many errors were flagged�in my document. It's a good thing that my attitude towards editing is that is necessary for improvement, or I'd probably have been curled up under my desk. My three most common errors were sentence length, future tense, and passive voice, but there were plenty of other problems. Most of them easily fixed.

I used acrocheck for at least three months as part of our pilot. And one of the things that I noticed was that it was starting to improve my writing, in much the same way that using spell check consistently finally teaches my fingers the correct spellings of words that I initially misspell. I was starting to catch myself using passive voice during my writing process, before I ran the tool against my draft. I also started noticing when my sentences were creeping towards run-on (although, as you may have noticed, it?s still a problem I struggle with!).

The acrolix�product is enterprise level, and priced accordingly. Not something that I?m likely to be�able to access in my new role as Lone Writer. But if you?re a FrameMaker user, I?ll point you towards the download for SDL Author Assist�a FREE grammar and style checking tool. I?ve played with it, and it is worth the upgrade if you?re not yet on FrameMaker 9.

If we?re going to call ourselves professionals, we have a responsibility to act as such. We value craftsmanship over crap.

I love this. This resonates so profoundly with me. This just may be my new motto.

*****

Here is another post on the fifth element for the Agile Manifesto ? Craftsmanship over Execution. Read through the comments, they?re great.

The Friction of Agile

Thu, 07 Jan 2010 06:30 GMT

Everything is very simple in War, but the simplest thing is difficult. These difficulties accumulate and produce a friction which no man can imagine exactly who has not seen War… This enormous friction, which is not concentrated, as in mechanics, at a few points, is therefore everywhere brought into contact with chance, and thus incidents take place upon which it was impossible to calculate…

IMHO, this excerpt from On War applies exceptionally well to Agile roll-outs these days:

Simplicity: The four principles of the Agile Manifesto are intuitively compelling. You could (and probably should) use them as the core definition of what Agile is all about. Likewise, you do not need more than a single hand-drawn matrix to illustrate how WIP limits in Kanban work. In contrast to various other terms used in development and IT – e.g. SOA – the conceptual power of Agile methods is easy to grasp.

Friction: Assume you were building a company from scratch without any pre-conceived notions of the organizational constructs you would put in place. Assume as well that you were developing your organization with end-to-end Agile effectiveness in mind. You would probably devise a holistically integrated organization. For example, you might opt for an organizational design in which each level of the organization will include all functions relevant to Agile – R&D, IT, Marketing, Support, Sales etc. In other words, ideally you will not go for the traditional organizational design: a vertical R&D stove pipe, a vertical Marketing stove pipe, a vertical Sales stove pipe, etc.��As in reality you are unlikely to get the charter to start with a clean sheet of paper, the friction arises in each and every point in which your end-to-end organizational design for Agile deviates from the traditional organizational constructs your company uses.

Not concentrated: As Clausewitz points out, the friction of war is not mechanical friction – you can't address it by pouring in a ‘organizational lubricant' in just a few places. Flooding the whole organization with the lubricant is likely to create a morass in which all agility will be lost.

I recommend four principles to minimize the organizational friction of Agile, as follows:

Acknowledge you accrued organizational debt: It is conceptually quite similar to accruing technical debt – various organizational decisions and compromises taken along the way were rushed to the extent that they leave much to be desired. The organizational constructs and practices that sprang out of these decisions need to be refactored.

Carry out the organizational refactoring work from the outside to the inside: �A truly holistic Agile design will incorporate customers and partners. Start with the way you will integrate them, thence apply this very same way to the integration of �the organizational entities within your company.

Build on the strengths of your core corporate culture: As pointed out by Drucker:

… culture is singularly persistent… changing [organizational] behavior works only if it can be based on the existing ‘culture'… [Drucker, 1991]

Use modern corporate for the fundamental organizing principles. See�Relational Networks, Strategic Advantage: New Challenges for Collaborative Control by Hagel, Brown and Jelinek for a good recent article on the subject.

Since the end of the Cold War, a fair amount of debate has taken place around the applicability of the friction of war principles to armed conflicts in the information age. The conclusion is of interest to both military personnel, Agile practitioners and IT professionals:

… while technological advances might�temporarily mitigate general friction, they could neither eliminate�it nor substantially reduce its potential magnitude.

Agile Tenet #8 - Sustainable Pace

Wed, 06 Jan 2010 23:09 GMT

Eighth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. [emphasis mine]

Ah, a constant pace. Technical writers aren?t used to that. At least not in a Waterfall development environment. Waterfall technical writers are used to a significant amount of slack time at the beginning of the production cycle, then a stretch of regular work while coding continues, followed by a frantic scramble, often involving overtime, at the end of the production cycle.

One of the big disadvantages I can see to adopting Agile Sprints is that TWs lose the slack time at the beginning of the development cycle. I don?t know a single writer that has enough time to accomplish everything that they?re expected to do. Writers often use that beginning-of-the-cycle down time to catch up on projects that are important but not urgent, like researching writing tools, evaluating documentation processes, designing templates or style sheets, developing style guides, or just plain catching up on everything they didn?t finish in the rush to release. And heaven forbid you need to convert a large legacy documentation set to either a new tool or a new process. How on earth do Agile writers find time for big projects like adopting DITA? The short Sprint timeline makes taking time away from writing for things like conferences, training, and a well-earned vacation a little harder to plan.

Or maybe I?m still making the mental adjustment from being a member of a documentation team to being a sole writer. Even though it?s been a few years, it still feels weird to realize that I am the entire team now. And that if something needs to be done, there isn?t anyone but me make sure that happens.

One of the clear benefits I can see to adopting Agile Sprints is they eliminate that last-minute documentation rush at the end of the release cycle. Or if the scramble isn?t completely eliminated, at least the stress is spread around a bit more evenly so it doesn?t feel so bad. I can really embrace the idea of working at a steady pace.

But I keep bumping up against my fears about who gets to define what a ?steady pace? is and whether or not my own personal, idiosyncratic writing style can be made to fit into the Agile mode. What about when I have writer?s block? (Yes, even technical writers get writer?s block.) There are days when the words just don?t flow. This is one of the reasons why I usually have a couple of side projects going at any time. If I can?t get my writing mojo to work, I can switch over and do some training, work on my glossary of product terminology, do some indexing, or spend time trawling the network/wiki for other useful documents that no one thought to forward to the writer. But those side projects, while productive, are not usually the sort of things that would fit neatly into a user story. Thus my anxiety about keeping up a steady pace of work.

Thinking and writing about this tenet reveals my anxiety that Agile is about forcing me to become more productive, ever increasingly more productive. I?m not a slacker by any means. At least not when I compared my production to the other writers when I worked in a doc group. And when I compare my page count from one year?s work to my estimates for what I should have been able to produce (based on the Dependency Calculator), I?m cruising right along. So why do I always feel like business is never happy with a productive employee and always wants more work (and for less pay)? And that no matter how hard I work, it will never be good enough?

Or maybe I?m just feeling uncomfortable about admitting to non-technical writers that the majority of my time is not spent writing, but on other activities? There is this misconception that all writers do is write. Judging from the number of writers blogs I read (both literary and technical writers) most writers spend less than half their time actually writing. Most non-writers don?t understand that all that non-writing contributes to the writing. And that ?doing research? is not code for ?farting around on the internet.? At least, not usually.

Or maybe I?m dealing with my own attempts at sustaining a constant pace of posting to this blog. And I?m finding that despite my huge list of ideas for possible posts, some weeks it is easier to generate three posts and other weeks it is a bit of a struggle. Of course, the only person requiring me to post three times a week is me. And perhaps the whole point of this post was to get me to realize that the person who has the highest expectations for my work is not my employer, but me. And that I need to give myself permission to find my own sustainable pace.

Definition: Agile Development

Tue, 05 Jan 2010 06:30 GMT

The difficulty to concisely define the term Agile Development stems from the very nature of the Agile Manifesto:

The manifesto is a statement of values. By the very nature of values, people share them in a loose manner. Both definition and adherence (“But do they really practice Agile development?”) are qualitative and open to interpretation.
The manifesto values are relative. The manifesto is quite explicit in stating “… while there is value in the items on the right, we value the items on the left more:”

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiations

Responding to change over following a plan

Agile development is often described in terms of the software method in use. For example, in his foreword to�Agile Software Development with Scrum, Bob Martin summarizes Agile methods as “… people oriented software processes that work without getting in the way,” Martin Fowler emphasizes another aspect of Agile methods in his own foreword to the very same book:

… a new breed of software processes which are based on an empirical approach to controlling a project.

A more detailed definition is given by authors Rico, Sayani and Sone in their October 2009 book The Business Value of Agile Software Methods: Maximizing ROI with Just-in-time Processes and Documentation:

Agile methods are contemporary approaches for creating new software based on customer collaboration, teamwork, iterative development, and response to change. Combining communication and interpersonal trust with a flexible management and development framework, they contain just enough process to capture customer needs in the form of user stories and to rapidly create working software. However, the key to Agile methods are rich, high-context communications with customers along with cohesive teamwork.

On the other hand, such an authority (and signatory to the Manifesto) as Jim Highsmith does not seem to define the term Agile Development per se in the second edition of�Agile Project Management: Creating Innovative Products. Instead, Jim defines�Agility through two statements:

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

Agility is the ability to balance flexibility and stability.

Likewise, in Agile Software Development, Alistair Cockburn focuses on discussing what is core to Agile, emphasizing the properties of Agility through the following citation:

Agility is dynamic, context specific, aggressively change-embracing and growth-oriented. It is not about improving efficiency, cutting costs or battening down the business hatches to ride out fearsome competitive ‘storms.' It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share and customers in the very center of the competitive storms many companies now fear.

Rather than trying to reconcile all these worthy definitions, I would suggest five context-dependent approaches to the definition, as follows:

For the reader who tries to understand what Agile is all about: It is the mindset that really matters.�Read the Agile Manifesto and the corresponding History.

For the reader who is anxious to put his/her hands around an Agile implementation: Pick a specific Agile method – any method -�and study it with special emphasis on the roles, process and artifacts of the method. It could be Crystal, Extreme Programming (XP), Scrum, Dynamic Systems Development Method (DSDM), Kanban or any other method�that shows promise as a good fit �for your specific environment. Consult 10 Steps for Starting an Agile Start-up for a down-to-earth blueprint for implementation.

For the reader who tries to assess whether a project team is really Agile: It is a maturity curve issue that manifests itself in quite a few disciplines. For example, see the various kinds of maturity models surveyed in the BSM Review blog. You will probably need to determine the maturity model that suits your environment and apply it to the method you are practicing.

For the reader who needs to explore Agile in a business context: You need not worry about the technical aspects of Agile. See the category Benefits of Agile in this blog.

For the reader interested in applying Agile beyond development: Extending Agile changes its definition. See the various posts on the subject by Eric Ries in Lessons Learned.

Please remember: when it comes to defining Agile Development, you have a problem of choosing, not of choice. It is the use to which you put the definition that determines the choosing.

Agile Tenet #7 ? Usable Doc as a Measure of Progress

Mon, 04 Jan 2010 20:35 GMT

Seventh in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Working software is the primary measure of progress.

Technical writers write documentation rather than�software, so this is one of the tenets that needs to be�slightly modified to apply to TWs. The question is, how do you define ?working documentation? and whether or not the Agile technical writer is making progress?

We don?t want to use page count as a measure of progress. Lengthy docs often lack focus. Mark Twain said, ?I didn't have time to write a short letter, so I wrote a long one instead.? And Cicero, T.S. Eliot, Ernest Hemingway, Samuel Johnson, Blaise Pascal, George Bernard Shaw, and Voltaire have similar quotations about lengthy writing being an indication that they did not have time to do their best. Page counts are not a metric of good writing, in fact, if you localize, a low page count (and lower cost) is the goal.

Tightening up your writing can be�as simple as changing ?Click on the Save button? to ?Click Save? which says essentially the same thing but takes less time to read (and if you?re localizing, saves you three words). But I?ve also seen people take brevity to extremes in an effort to�reduce�localizations costs. At one point during a cost cutting effort one of our executives found a company that promised to cut our word count by 40%. We sent them samples, but what came back was so spare as to be almost useless. If you?re only focused on word count or page count, you?ve lost sight of your users and meeting their needs.

Since tenet #9 is attention to Excellence, I believe that the measure of progress for a technical writer should be useful�documentation. A couple of years ago I encountered the book Developing Quality Technical Information: A Handbook for Writers and Editors. I was so impressed with their definition of quality technical writing that I typed it up and posted it on the wall of my cube. Slightly paraphrased, their criteria are as follows:

Easy to use
Task Orientation	Focused on helping users perform tasks related to their jobs.
Accuracy	Free of mistakes and errors.
Completeness	Includes all the necessary information, and only necessary information.
Easy to understand
Clarity	Presents the information so that users understand it the first time.
Concreteness	Includes appropriate examples, scenarios, specific language and graphics.
Style	Appropriate writing conventions, words, and phrases.
Easy to find
Organization	Arranging the parts in a way that makes sense to the user.
Retrievability	Presentation that allows users to find information quickly and easily.
Visual Effectiveness	Appropriate use of layout, illustrations, color, typography, etc.

I believe that one of the most important things you can do to make software documentation useful is to focus on the user?s task. Several years ago I took a community college course to learn how to use Photoshop. Our instructor chose the Photoshop Visual Quickstart Guide�from PeachPit�Press as our text. Both the course and the text were feature oriented rather than task oriented. As we worked our way through the many features of Photoshop I remember constantly wondering ?But what would I use this for?? At the end of the semester we hadn?t covered what I suspect are the two most common corrections to photographs: removing red-eye and ?correcting? skin blemishes. I could probably figure out which features to use, but it would have been helpful if the course and text had focused on common tasks.

Journalists seek to answer the Five Ws: Who? What? When? Where? Why? And How? I believe that useful documentation should seek to answer the same questions.

Useful documentation is the primary measure of progress for a technical writer.

Agile Tenet #6? Face-to-face Communication

Mon, 28 Dec 2009 08:22 GMT

Sixth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

There have been many times when I?ve sent an e-mail to a Subject Matter Expert and asked, ?Does it work like this, or like that?? And have received back a terse answer of ?Yes.? Argh! Which usually leads to me tracking down the SME in his lair and asking, in person, does that answer mean ?Yes it works like this? or ?Yes it works like that.?

The short trek to Developer Land is often worth the effort, as most of the developers I know would rather talk about what they?re doing than write about it. (Or occasionally draw about it, my VP loves to scribble on his white board.) So I get much more information out of a conversation that I would from an e-mail or a specification. The conversations often lead to me gaining information that I wouldn?t have thought to ask about in the first place. And I also get the opportunity to ask questions, instantly clarifying points that I don?t understand.

Despite how useful face-to-face communication can be, it is not the first thing that I rely on when I?m doing research. I am a reader, and a fast reader at that. So I try to do my homework before I go to a product manager or developer with questions. If I can answer a question by myself, I don?t want to bother someone else. And I?ve found that doing as much advance research as I can, be that reading or experimenting with the software, helps me to focus my questions, and results in better answers. It saves time for both me and the person I?m interviewing.

Tenet 6 is one that has a huge impact on how technical writers do their work. With an emphasis on more face-to-face communication and less written communication, the writer has reduced access to specifications or even e-mail threads when they?re doing their research. If the writer is in the same physical location as the development team and the quality assurance team, that lack of project documentation can be made up with more face-to-face communication. But these days, off-shoring means that a lot of us don?t even work on the same continent as some of our team members. My first tech writing job had team members in Canada, Brazil, and India. My second had development in New Zealand and quality assurance in India. My current position has developers and QA in both India and China. I?m sure that there are those that would say that if team members aren?t all co-located that means we?re ?not doing Agile.? But I suspect that most companies are in a similar position, with team members scattered all over the globe.

Which means the team needs to develop new skills for building and maintaining teams. At my previous job I used Skype to chat with my New Zealand developers on a regular basis. My current job has also experimented with using Skype and instant messaging with team members in China to bring them into the Scrum meetings one or two days a week. We have an internal Wiki, and there is a team page with everyone?s picture, and all of our contact information (e-mail, phone numbers, Skype and instant messaging IDs). Being able to put a face to a name helps you feel more connected to someone who you've never met.

I'm still making the transition from my old work habits to more Agile ones. As I work through the backlog of doc bugs and undocumented legacy features and start working on the new features, I know that my research will be quite a bit less reading and a lot more interviewing. I?ll be back to the journalism model where the writer is interviewing the SME. I?ll need to be proactive and get out of my office and talk to my team more than I?m used to. I?m pretty sure that I?m going to be handicapped by my six month absence from Scrum. I?ve missed a lot of design discussions, and without project documentation it?s going to be hard to catch up on what I?ve missed. It's going to be a challenge. But this is one of the few areas where I've heard positive things from other Agile technical writers, so I know it is a challenge I can meet.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. It is essential that the technical writer be considered a full team member and be included in these conversations.

Agile Tenet #5 ? Motivated Individuals

Thu, 24 Dec 2009 09:43 GMT

Fifth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The part of this tenet that really resonates with me is trust them to get the job done. Abby Fichtner recently posted a link to Scott Berkun?s open letter to micromanagers, and I can?t stop thinking about it. I think that Scott?s opening lines are absolutely brilliant:

Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind the horse and jockey how to run, where the finish line is, or that it?d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this.

I once worked for a micromanager who wanted me to track a dozen different milestones for every single topic that I wrote, and send her a daily report on my progress. After working for several years for managers who wanted a simple weekly ?my project status is green/yellow/red.? status update, I found this new system to be highly demotivating. I felt like my new manager didn?t trust me to do my job, and the constant status updates had a definite negative impact on my productivity.

I?ve usually been lucky enough to work for managers who checked in on me every so often to ask ?Is there anything I can do to help? Need anything? No? OK then, carry on.? I am a trained professional, perfectly capable of planning and executing my work by myself. I understand my manager needs to report to upper management, and as long as they let me know what they need from me, I?m happy to provide it. But I don?t come to work to write status reports, I come to write user documentation.

The other, more difficult part of this tenet is Give them the environment and support they need? The physical environment is relatively easy to provide: powerful computers, comfortable chairs, a variety of caffeine sources in the break room, etc. What is harder to quantify is the cultural environment of an office and team dynamics. Over time I?ve come to recognize that there are three types of employees that can severely negatively impact a team:

Incompetent employees who create problems for their coworkers

Lazy employees who cause more work for their coworkers

Toxic employees who cause morale problems for their coworkers

When I say incompetent workers, I?m not talking about people who are lacking in skills. Skills can be learned. I?m talking about people who present themselves as being experienced, senior-level employees, but they?re fooling either themselves or their employers, because they are incapable of working at the level that they claim.

I once had a project updating documentation that included examples of SQL for querying and modifying the database. I knew enough about recent database schema changes to know that the examples would no longer work, but didn?t know enough SQL to be able to correct them myself. I asked the product manager for help. Over the next several weeks he put me off, sent me the existing examples that I had told him were wrong, sent me old examples that worked against the old schema, and generally did not answer my questions. It finally became clear to me that while I didn?t know very much SQL, he knew even less. And wasn?t about to admit it. Finally his incompetence became so obvious that the company had to replace him with someone else. And I was able to get more accomplished in two weeks with the new product manager than I had been able to accomplish in several months working with the old PM.

I read a quotation that has stuck with me ?Meetings move at the pace of the slowest person in the room.? I think that you can also say the same thing about teams. Incompetent employees slow down the team because their coworkers have to spent time cleaning up the problem worker?s messes and solving the problems they create rather than doing their own work.

The best example of the lazy employee can be found in the comic strip Dilbert: Wally walks around drinking coffee all day, but never seems to do any work. I suspect that we all have at least one Wally in our offices. I?ve worked with several over the years. Team members notice when someone shows up late every day, takes an hour and a half for lunch, then disappears for 45 minutes every afternoon to go pick up coffee at Dunkin Donuts. (And we also notice when managers continue to tolerate this behavior.)

If you?re a slacker, there is nowhere to hide in an Agile environment. You have to stand up every day and tell the team what work you accomplished the day before.

The third type of employee that can negatively impact a team is the toxic employee. And these are the hardest to deal with, as being toxic is less a matter of behavior and more a function of personality. A toxic employee may be a pessimist, constantly complaining about things. They may be combative, constantly arguing with people. They may spread malicious gossip. And sometimes the most brilliant people in an organization can be the most toxic, because of their arrogance.

I once worked with a writer who made enemies faster than anyone I?ve ever met before. She had usability training, and came into the company with lots of good ideas for how to improve our product, but she had no idea how to present her ideas effectively. It wasn?t so much what she said that caused her problems, but that she presented her ideas as criticisms, and often in a very insulting manner. For example, she invited herself to the UI team meeting and proceeded to give a presentation about what was wrong with their design. She wasn?t a member of that team, and hadn?t told the team leader that she would be attending, or that she wanted to provide the team with input. She just showed up, took over the meeting, and effectively told the team that they weren?t doing their jobs correctly. She was the sort of person that sends you running to the self-help section of the bookstore searching for books about how to deal with toxic coworkers. (I found strategies that saved my sanity in the book The Sociopath Next Door by Martha Stout.)

I know this is a deeply heretical statement (especially when so many people are out of work through no fault of their own), but some people need to be fired. It is the only thing that will make any change in their behavior. Poor workers need to be taught that their behavior is not acceptable. Managers need to coach problem employees. Give them a short probationary period to correct the problem, but if there isn?t drastic improvement, fire them. Some people cannot hear the message that they need to change until it costs them their job.

Sometimes firing someone is the best thing for both the team and the problem employee. The bad team member will get the wakeup call that they must make changes in order to remain employable. And the team will be more productive without the problem employee dragging them down.

Build teams of motivated individuals. Then give them the environment and support they need, and trust them to get the job done.

Agile Tenet #4 ? Work Together Daily

Wed, 23 Dec 2009 07:39 GMT

Fourth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Business people and developers must work together daily throughout the project.

When I was studying for my technical writing certificate, one of the things that my writing instructor emphasized was to know your audience. I want as much information as possible about my customers and their tasks so that I can write documentation that meets their needs. At my first technical writing job that was a bit of a challenge. The company made a highly configurable product for managing assets and work orders that was marketed to a wide variety of different industries. Our customers fell into four main categories:

Manufacturing and utilities production

Hotels, universities, and other facilities

Buses, trains, aircraft, and other fleet vehicles

Information technology (IT) assets

As you can imagine, this created a bit of a challenge for the writing team. Our customers could be virtually anyone.

In the years that I was employed there I worked hard to gather information about our customers. The company sponsored an annual User Group conference that was well attended. Unfortunately, when they were picking the employees who would attend, the Powers That Be favored product managers, support, and quality assurance engineers, and not technical writers. One year we managed to send both doc managers, who conducted a customer survey and hosted a documentation discussion that they taped and played for the team at one of our department meetings.

Since I couldn?t attend the user group, I decided to find other avenues for face-to-face contact with our customers. I started working closely with our training department. I made friends with some of our trainers and course developers over lunches in the company cafeteria. As a result, they started inviting me to sit in on beta training for new courses, since I could provide feedback to the course developers. I also made an effort to attend our customer training courses at least once or twice a year. I always paid close attention to the scenarios that the trainers were using to present our product, and listened to the questions that our customers asked. And our customers often asked a lot of detailed questions, trying to squeeze some free consulting out of our trainers.

In my final year at that company I worked on a specialized part of the product, and my manager was finally able to get me on the list for our User Group conference. I spent four days on the floor, demonstrating the product in our Demo area and answering customer questions about new features. I also was able to attend a few of the customer presentations, and was fascinated by the different and creative ways that our customers were using the product. As a result of meeting the moderator at the conference, I was also able to join the heavily moderated, customers-only Yahoo group for our product, which gave me even more insight into our customers.

I left that job for another one, working for a smaller company whose product was in the same space. I had much more customer contact at my second TW job, attending a User Group conference in my third week on the job. At that job I was a Lone Writer, and as a result I wore many more hats. During the year and a half that I worked for that company, I attended three different User Groups, assisted one of our consultants with an implementation at a customer site, and taught one session of user training.

At my current job I?m back to having limited information about our customers, and the product owner for our teams is the VP of Engineering. I?m back to brainstorming ways to learn about our customers. I?ve been getting to know our support team. And we just hired a trainer, someone who I know from a previous job and with whom I already have a good working relationship.

Just as I was getting ready to write this post, one of Mike Cottmeyer?s Interesting Links posts let me to a post about how Agile isn?t designed to meet the needs of customers. This makes me wonder, despite the stated goal of involving customers in the development process, how much actual customer contact I can expect in an Agile environment?

I think we should make a slight revision to the wording of this tenet, from “developers” to “teams” so that it includes technical writers, testers and other team members.

Business people and teams must work together daily throughout the project.

Agile Tenet #3 - Deliver Frequently

Tue, 22 Dec 2009 08:09 GMT

Third in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

When I was working in a Waterfall development environment my writing process was long and drawn out, similar to writing a novel. I once worked a solid 18 months on a single release. The User?s Guide was almost completely revised, and weighed in at 450 pages by the time I was done. For that particular release I did nothing for three solid months but read through the hundreds of pages of specifications for the release, taking notes along the way of new applications being added to our application suite and new features. Then I struggled with my outline for several weeks, trying to figure out a structure that would accommodate the new material. I was writing notes and draft topics the whole time, but the new release had so many different applications, that it was hard to find a structure that would fit the wide range of new features. Once I settled on a structure, I spent almost a year playing with the software builds, exploring the new features, interviewing a dozen different product managers, writing and revising before the software and doc was actually released.

In Write to Learn Donald Murray describes techniques used by all writers (Collect, Focus, Order, Draft, and Clarify), and urges his students to adapt them to their needs. And that list describes my writing process pretty well. My technical writing textbook, How to Communicate Technical Information, breaks the writing process down to just Planning, Writing, and Revising. However you define your writing process, in an Agile environment it is severely compressed.

I?ve heard TWs estimate that they only spend between 25% to 40% of their time actually writing, with the rest of their time taken up with e-mail, meetings, planning, research, and other non-writing tasks. When you?re writing documentation in an Agile environment, your process is no longer the long slow march towards a major release. In an Agile environment, you?ve got to be much more efficient. You have much less time to think about what you?re going to write, because if you are going to deliver content by the end of the Sprint, you need to stay focused on tasks that support the writing.

I?ve already written about how I use modular writing, and some of the techniques I use for being ready to publish at all times. Making the switch from the long cycles of Waterfall to shorter Agile Sprints has not been as big a shift for me as it might be for writers who were not used to delivering information in small chunks. But even so, I?ve had to learn to let go of my own expectations for the documentation. There has always been a gap between the documentation that I want to deliver and the documentation that I can deliver in a given timeframe. With a shorter timeframe, that gap widens considerably. (Thank goodness tenet #9 is Attention to Excellence!)

It seems to me that one of the tricks of being an Agile technical writer is to be less like the novelist and more like a journalist on deadline, trying to scoop the competition with a big story. Journalists are continuously writing because they have to deliver content, be it a daily newspaper, news weekly, or monthly magazine. But unlike a journalist, the Agile TW can always go back and revise what they?ve written in a later iteration.

Deliver documentation frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale and delivery of smaller chunks of information.

Agile Tenet #2 ? Welcome Changing Requirements

Fri, 18 Dec 2009 11:12 GMT

Second in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can?t) be applied or adapted to technical writing.

*****

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Early in my TW career a product manager changed a toolbar icon a week before a release. I updated the User?s Guide to reflect the new icon. A day before the release he changed his mind, and reverted back to the original icon, but didn?t tell the doc group. Luckily it was a beta release, so the incorrect docs only impacted a single customer.

While technical writers may not actually welcome change, most of us have had to adapt to the reality that developers often make changes the software and forget to tell us. Getting TWs to welcome change? Well, that may require a major attitude adjustment for some of us, as whingeing about how we get no respect is as much a part our perception of our jobs as it was part of Rodney Dangerfield?s comic persona. Many of us spend our days trying to earn that respect by subtly reminding our coworkers that we provide customer value too.

I think that part of the value of a technical writer is often found in the types of questions that they ask about the products that they document. When I was first investigating technical writing as a career change I attended an information session for a TW certificate course. The speaker was a graduate of the program whose previous career had been as a journalist. I remember that he said that his new career was much like his old career; he still spent his days interviewing people, then going back to his desk and writing. Ever since then I?ve looked at my work as a form of investigative reporting.

For example, if the new feature is to allow the user to create or change a password, I might ask the following questions:

Can the password match the user name?

Are there any length requirements or restrictions for the password?

Is the password case-sensitive?

Are there any requirements for the first character in the password?

What special characters are allowed in the password?

Does the password expire?

Can you reuse passwords or partial passwords?

When would it be more helpful to the project to have the technical writer ask these questions? Would you rather have them ask the developer after the code is complete, or ask the customer or product owner during the Sprint planning process, while you?re writing the acceptance criteria for the User Stories?

Agile processes harness change for the customer's competitive advantage.

So not only do TWs need to welcome change, we need to figure out how to harness it for our customers. I think one of the ways that we can do this is to keep up with the changes in technology and how information is shared in the Internet age. There are many new options for delivering content to our users. Yesterday my former manager sent me a link to the documentation Wiki that he?s working on. And there has been a brief discussion on the TECHWR-L mailing list recently about using WordPress as a documentation platform. I?m still waiting for my copy of Anne Gentle?s Conversation and Community: The Social Web for Documentation to arrive. I?m looking forward to finding more good tips for harnessing Web 2.0 for my customers in her book.

This tenet ties into one of the core TW goals, to understand users and their tasks so that we can write useful documentation. I think the trick for the Agile team is finding the right balance between understanding the user?s requirements and reducing project documentation so that you can get down to the business of creating the product. Technical writers, with our user focus, can help our teams remember that the goal is to meet our users? needs, not just deliver working software.

Agile Tenet #1 - Satisfy the Customer

Wed, 16 Dec 2009 08:56 GMT

The Agile Manifesto includes Twelve Principles of Agile Software. Over the next dozen entries I?ll look at how each of these tenets can (or can?t) be applied or adapted to technical writing. And then, as a wrap up, I?ll propose my own list of Agile Principles for technical writers.

*******

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Companies deliver two things to customers, software and documentation that explains how best to use it. Developers deliver software. Technical writers deliver user documentation. And technical writers, like developers, aim to ?satisfy the customer? when we create our deliverables.

It?s hard to satisfy your customers if you don?t know who they are, so one of the first things good technical writers do is perform an audience analysis. What industries do your users represent? Who are the people using your product? Are they students, office workers, managers, the general public? What level of computer experience do they have? Are they novices, experienced users, system administrators? What environments are they working in? Are they outdoors, in an office, in a clean room? Sometimes this information is easy to come by, and other times we have to take our best guess.

?Early and continuous delivery? of the most up-to-date information is a constant challenge for TWs. In the not so distant past, when TWs were mostly producing hard copy manuals, they were restricted by the lead time required for printing. Often the documentation was out-of-date by the time the product was released. Now that most of us are delivering our documentation as PDFs or online Help, we can release updated deliverables much more quickly. However, TWs may still be restricted to releasing documentation once a quarter or less. At a previous company we localized into a dozen languages, and often were not allowed to release updates if there wasn?t the budget to translate the content. The reason for this was never fully explained to me, but it was intensely frustrating to have corrections and new content and not be allowed to release them to our customers. Currently, I?m working as a lone writer for a company that doesn?t yet localize. So I can update the documentation as often as I like. Since we have a patch release cycle of 6-8 weeks, I update the docs whenever we release a patch.

Developers deliver ?valuable software?, but what makes documentation valuable? I think that Developing Quality Technical Information sums it up quite nicely, when they say that quality technical information is
? Easy to use
? Easy to understand
? Easy to find

Valuable documentation helps customers do their jobs. Customers don?t search the documentation for headings like ?Using the Widget Dialog Box.? They look for ?How to Order Widgets? because they don?t know which feature they need to use, but they do know the task that they need to perform. At every technical writing job that I?ve had in my career, I?ve spent my time turning feature based documentation into task based documentation. I focus on breaking the documentation down into small chunks, organizing it effectively with meaningful headings, and indexing it as thoroughly as possible. And whenever I can, I also include best practices for how to use the software and tips for how to be more efficient.

The technical writer?s highest priority is to satisfy the customer by providing useful documentation.

Agile Development : An Overview

Tue, 15 Dec 2009 10:18 GMT

Agile Development : An Overview

Its a topic where you can write as much as you can and lot of experienced work has been transformed into written form in different books, articles and blogs. I'm here to share what I have understood and observed reading some of the useful resources only to help others in having a better understanding of what an Agile development is? “)

Agile Software Development, a framework which interprets iterational development, open collaboration and is adaptive to the life-cycle of the project. This development process contains a family of processes instead of single approach to the development which is based on some core principles listed below, also named as “Agile Manifesto“. The Agile Manifesto was drafted by 17^[1] well known developers in 2001 in order to define the Agile development.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals.� Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity ? the art of maximizing the amount of work not done ? is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

There has been a good explanation of the question whether agility is a process or not. If you read article by agility is an ability by Kirk Knoernschild (one of the team members who drafted Agile manifesto).He tried to define agility as to actively adopt changes in even late development and resulting increased feedback by delivering working software possible incomplete at early stage. This ability can be achieved through being more specific and understanding agile practices i.e. why and how a practice helps in accepting a change,� resulting faster speed, increased feedback. This is not all about practicing agility its about understanding it.

Agile Development Emphasis on…

Customer satisfaction as highest priority
Welcome changes even late in development
Frequent delivery of the software
Business value
Face to face communication( Co-location)
Continuous attention to design and technical excellence can be achieved by self-organizing teams

Okay “), lets try to answer a simple question why should we go Agile? and how should one take a start? To any new technology we need to scale it by our own and check if it fits in our working environment keeping in mind that some practice/technology may or may not be a good fit to the environment despite the fact that they are getting hype in the market. So the key point is we should start gathering suitable ingredients i.e. a project worth trying out agile methodology. Agile methodology is quite successful where developer's team is intensively collaborative and top of all they are more than willing to work with agile methodology. I'd refer you to go for reading Martin Fowler's article for much better understanding.

Agile Methods are…

Below listed are the agile methods being practiced whose real source is Wikipedia, suggest me if any thing is missing.

Scrum
Agile Modeling
Agile Unified Process (AUP)
Agile Data Method
Daily kickoff and review of goals
short release cycles
Responsive Development
Generalism – Use of generic skill sets that are common across the team, not reliance on specific skill sets that are scarce
Test Driven Development (TDD)
Feature Driven Development (FDD)
Behavior Driven Development (BDD)
Essential Unified Process (EssUP)

I'll definitely try to touch the base on few of em in a short review soon….Alot more for me to learn.

Reference:
[1]�� 17 signatories of the Agile manifesto were Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,� ��Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,Steve Mellor,
Ken Schwaber,�Jeff Sutherland, Dave Thomas

http://www.martinfowler.com/articles/newMethodology.html#ShouldYouGoAgile

http://www.agilemodeling.com/principles.htm

http://agilemanifesto.org/principles.html

http://www.agilejournal.com/content/view/122/114/

Requirements and specifications -- your needs or theirs?

Mon, 14 Dec 2009 17:54 GMT

I've just finished reading a great post from world renowned Information Architect Eric Reiss on website projects and things CEOs should know. Something in particular, though, caught my eye that reminded me of requirements gathering in agile environments:

“Don?t confuse your needs with those of your visitors
You may want … to communicate your company?s values, service offerings, products, or something else entirely. But [users] will have their own agendas … the simple truth is, unless a site fulfills the needs of its visitors, it will never fulfill the needs of the site owner.“

If you're doing agile, real agile, not just doing iterations or stand-up meetings, you're focussing on the needs of your users and ranking them in relation to what adds value to them, not to you. This is one of the basic tenets of the Agile Manifesto and, in this way, has a lot in common with lean process practices:

work from the customer's perspective
expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus should be eliminated
create more value with less work

This requires a different way of working to elicit requirements for some of us. Rather than a focuss on the business, we need instead to shift our thinking to engaging end-users. This is why, specifically the following artefacts are of vital importance in requirements elicitation and documentation:

Personas — who are your actual end-users? Document their needs, wants, capabilities, expectations and attitudes?
Storyboards — what is their context of use? Document their thoughts and behaviours in the context of the product or service you're creating. I generally create both “as-is” and “to-be” storyboards rather than jumping straight into process diagrams. Most importantly, I've found that storyboards ultimately have greater appeal as a communications and change management tool than swimlane diagrams and are infinitely easier to create. Their value, therefore, to the project� in relation to “create more value with less work” is far greater than other artefacts you might deliver.
Epics — how do personas and storyboards fit into the wider picture of the project, particularly system widgets that need building? Multifaceted tools like epic diagrams help to communicate a complete feature set without the need to manually create use cases. It also emphasises that traceability of features through to pain-points and benefits is important to demonstrate in relation, again, to value.

Armed with these simple tools you can begin on the right path to ensure your focus is where it needs to be — on users in order to fulfil the needs of the business.

Meditations on Job Titles (Or, it's about the work, not the title)

Mon, 30 Nov 2009 16:37 GMT

Not long ago, �the layoff dragnet caught up several of us at my ex-place of employment. My LinkedIn profile �says “looking for new opportunities” �and I am truly in full-tilt-work-search mode.

While there are great strategies for finding work, ala “Ask The Headhunter*” style where the seeker targets attractive companies instead of the other way around, I thought that looking at the �job boards in my area seemed like a way to get a feel for who was hiring right now too.�Interestingly for my qualifications, the job titles are all over the place. While this is usually true for someone in the technical communication field like me, the differences are even more extreme than usual.

It was thought-provoking to see different titles and work descriptions from different vendors for what is obviously the same position.�That got me thinking about what is considered a heretical subject in some circles: does the title really matter? Or is it really about the work? So I put the question in an Agile context.

The�Agile Manifesto says:�”Build projects around motivated individuals. Give them the environment and support that they need, and trust them to get the job done.”

In times like these, when unemployment is high and jobs are scarcer than they have been in years, it is doubly important to be motivated and focus on competency, not title.

Experience�gained �from working on Agile teams has broadened my skills. Working with Agile has provided me with the extra capabilities to build software, �hands-on testing experience, and honed�communication�skills with a wider range of people,�including�stakeholders, users, marketing, product management, technical support, and product developers. This has made me a more flexible team player and expanded my effectiveness as well.

The more flexible–or agile–a worker you are, the easier it will be to find that “other position” that fills the need to do good work and get compensated for it. �Not only that, but Agile workers have an advantage: they demonstrate superior teamwork, good self-management and�organizational�skills, and the ability to flow with a changing environment.

The takeaway for me is to focus more on being a motivated individual and what I can contribute to a company that I want to work for, and less on �the job title. �This approach is more work than just answering a job posting on a board. It does require research and matching �skills to the company's needs. �However, the rewards can be great when you can provide value to a company that you choose.

It's always better to ask someone to dance than to wait to be asked, right? The people who wait are called “wallflowers.”

Agile-ly yours,

Diana

* Ask the Headhunter is Nick Corcodilos, whose blog is here: http://corcodilos.com/blog/ and main website is http://www.asktheheadhunter.com. If you are looking for a new position, I recommend his approach and counsel very highly, as well as his books.

XP Days Germany, Day 1

Thu, 26 Nov 2009 18:13 GMT

Well, first day of German XP Days is over. For all of you who couldn't come, I'll try to give you some insight:
I personally started today just after lunch, since the tutorials in the morning had been sold out. But doesn't matter, it's just the warm-up day and a good warm-up day doesn't start before lunch!

The first session I attended was “Am Ende entscheidet das Naturell” – together with title comes the first hint that XP Days Germany are really quite… ehm, German. Almost every talk seems to be in German – which is on the one hand ok for a national convention. It gives German people the chance to join the agile community, even though they don't understand English. On the other hand, it excludes the few people from other countries, who are here. And keeps potential visitors away. I think it's sad to miss the chance to let them participate. Actually I'm of two minds about this question. Maybe it's not a general question, but a question of personal taste. I tend to the international variant. Or as a compromise, at least one track in English, the others in German.

Ok, back to the talks: “Am Ende entscheidet das Naturell” means something like “Finally, the temper (disposition) tips the balance”. Dierk Koenig from Canoo talked on citeria how to categorize people at work.
He mentioned several models for characterizing people, like well-known Myers-Briggs model and “big five”, but the difference between these models and the approach they use at Canoo is the fact that one doesn't need to know everything about his employees' personality, but just about a few criteria, e.g. “What is your approach to collecting infomation?”. “Focussed” and “Holistic-associative” were the left and the right end of a scale. In the model they use, just 4 of these criteria had been filtered out. The second criterium was extra- vs. introversion (communicating with others), the third was self-organization (structured vs. flexible) and I have to admit that I've forgotten the last one (I think it was sth. about innovation…).

Depending on your personal likes and dislikes, you can draw a scheme of which roles and responsibilities you'll probably take over in a team. Because the four dimensions with its two extremes in each case relate to eight steps in a working process or to eight roles in a team.

Well, I like the pragmatical aspect of this approach. Dierk Koenig pointed out that they use it sometimes in team retrospectives. As an example, he showed a photo of a map with eight fields, one for each role. Each team member had put a big stone on a field for his key strength and smaller stones for supporting roles. Some fields had many stones, some of them just one. So it became very clear to all who looked at the photo, which roles could turn out as risks.
But in my eyes the most valuable sentence Dierk said, was in the beginning of his talk, when he reminded us of the Agile Manifesto: “Despite we are talking about Agile, most people are still talking about processes and tools. But we should stop talking about processes and tools, we should start talking about people.”

The next session was a Pecha Kucha session. I had heard about this special form of presentation before, but it was the first time I saw it. It's some kind of lightning talk. A speaker has a topic and 20 slides for that. Each slide has exactly 20 seconds to stay. That means: 400 seconds left for a talk, 6 min. 40 sec.!
Things I like: You try to tell people a story. Everything which is unimportant will be left out. The slides don't have any bullet points and don't have much text. Mostly, they're just pictures. And they only support the speaker's message. Of course, everything I mentioned can also be valid for a regular talk, but to be honest: Most talks are different, people don't care about these rules. In Pecha Kucha, people are forced to do so.
We had three talks in this session. “Stop the Line in Software development” by Stefan Roock, a very useful talk on really stopping the production process in case of failure (like Toyota does). “Our Journey to the Land of Agile”, an experiential report by Markus Adrezak and “I am packing my Agile Suitcase” (I have no clue if this game, well-known in Germany, is also known in other countries!?) by Holger Koschek, a talk on the most important values, principles and tools in Agile. Each talk was very good. But form impressed me even more than content (maybe this is the disadvantage of Pecha Kucha).

I missed the TDD session but I heard from others that it had been very good – and totally overcrowded. :-)

The last talk for today was “Wissensinseln – Schadbild, Bek�mpfung und Vorbeugung” (a very typical German title! Can maybe translated with “Islands of Knowledge – Symptoms, fighting and preventing them”). Though it was the last session, Jens Coldewey managed it to get my full attention to his talk. He talked in a very engaged manner on this topic. The main part: How to realize that your team has a problem with sharing knowledge. He showed some indicators which I've been knowing very well: Some remarks during the sprint plannings, “This task can only do XY” or “I have nothing to do”. Or the fact that stories are not done the order they were prioritized, but in different order (“that's because the first story is XYZ' story and we carry on with the second (third, fourth, …) story”). Another indicator is a chart with story points a team achieves per sprint. If story points hit rock bottom every time when a particular team member is ill or in holidays, then you know that something goes wrong.
Afterwards we had a lively discussion about how to prevent it. I think it's even the easiest part to prevent it amongst developers: You can do pair programming, code reviews etc. But nobody had a good answer to the question of knowledge transfer within a *cross*-functional team itself. How to handle knowledge transfer between developers, sysops and designers? How not to overburden the team's only sysop? And how much knowledge transfer from a sysop to a programmer and vice versa is necessary? And how much is useful?
That's a topic I'd like to see being placed on the Open Space agenda on Saturday. I'll put it into the discussion once again.

The Changing Nature of Innovation: Part I -- New Forms of Experimentation

Mon, 23 Nov 2009 05:45 GMT

Colleague Christian Sarkar�drew my attention to two recent Harvard Business Review (HBR) articles that shed light on the way(s) innovation�is being approached nowadays. To the best of my knowledge, none of the two articles�has been�written by an author who is associated with the Agile movement. Both, if you ask me, would have resonated big time�with the authors of the Agile Manifesto.

The February 2009 HBR article How to Design Smart Business Experiments focuses on data-driven decisions as distinct from decisions taken based on “intuition”:

Every day, managers in your organization take steps to implement new ideas without having any real evidence to back them up. They fiddle with offerings, try out distribution approaches, and alter how work gets done, usually acting on little more than gut feel or seeming common sense?”I'll bet this” or “I think that.” Even more disturbing, some wrap their decisions in the language of science, creating an illusion of evidence. Their so-called experiments aren't worthy of the name, because they lack investigative rigor. It's likely that the resulting guesses will be wrong and, worst of all, that very little will have been learned in the process.

It doesn?t have to be this way. Thanks to new, broadly available software and given some straightforward investments to build capabilities, managers can now base consequential decisions on scientifically valid experiments. Of course, the scientific method is not new, nor is its application in business. The R&D centers of firms ranging from biscuit bakers to drug makers have always relied on it, as have direct-mail marketers tracking response rates to different permutations of their pitches. To apply it outside such settings, however, has until recently been a major undertaking. Any foray into the randomized testing of management ideas?that is, the random assignment of subjects to test and control groups?meant employing or engaging a PhD in statistics or perhaps a ?design of experiments? expert (sometimes seen in advanced TQM programs). Now, a quantitatively trained MBA can oversee the process, assisted by software that will help determine what kind of samples are necessary, which sites to use for testing and controls, and whether any changes resulting from experiments are statistically significant.

On the heels of this essay on how one could attain and utilize experimentally validated data, the October 2009 HBR article How GE is Disrupting Itself discusses what is already happening in the form of Reverse Innovation:

The model that GE and other industrial manufacturers have followed for decades – developing high-end products at home and adapting them for other markets around the world – won't suffice as growth slows in rich nations.
To tap opportunities in emerging markets and pioneer value segments in wealthy countries, companies must learn reverse innovation: developing products in countries like China and India and then distributing them globally.
While multinationals need both approaches, there are deep conflicts between the two. But those conflicts can be overcome.
If GE doesn't master reverse innovation, the emerging giants could destroy the company.

It does not really matter whether you are a “shoe string and prayer” start-up spending $500�on A/B testing�through Web 2.0 technology or a�Fortune 500 company investing�$1B in the development and introduction of a new car�in rural India in order to “pioneer value segments in wealthy countries.” Either way, your experimentation is affordable in the context of the end-result you have in mind.

Fast forward to Agile methods. The chunking�of work to two-week segments�makes experimentation affordable – you cancel an unsuccessful iteration as needed and move on to work on the next one. Furthermore, you can make the go/no-go decision with respect to�an iteration based on statistically significant “real time” user response. This closed-loop operational nimbleness and affordability , in conjunction with a�mindset that considers�a “failure”�of an iteration as a valuable lesson to learn from, facilitates experimentation. Innovation simply follows.

Approaching Agile

Sat, 21 Nov 2009 08:31 GMT

Sneaking up on it

I think I was destined to become an Agile technical writer.� In the summer of 2008 I was working for a small software company that produced two different products.� After finishing up a stretch of concentrating on the documentation for product A, I checked in with the product B developers in New Zealand.� I discovered that they?d decided to adopt Agile development without telling me.�

I responded the way I always do when faced with a new idea.� I did some research.

I started out by checked the Techwr-l archives for threads that mentioned Agile.� I?ve been a member of Techwr-l since 2005, and since I use G-mail to manage my list subscriptions, it was fairly easy to find the few discussions of Agile from the past couple of years.� Unfortunately, what little I found didn?t sound too encouraging from a tech writer's point of view.

I also looked through my collection of back issues of the Intercom, the journal of the Society for Technical Communications.� I found two articles about Agile documentation:

Adapting to SCRUM: Challenges and Strategies (July/August 2007)
Extreme Documentation (February 2003)

Wikipedia and Google turned up plenty of articles, and also led me to the Agile Manifesto and Scott Ambler?s Web Site.�� I had to do quite a bit of reading before I finally realized that when Agile proponents were writing things like ?Documentation should be just barely good enough.? and ?The benefit of having documentation must be greater than the cost of creating and maintaining it.? They were talking about project documentation (design documents, functional specs, etc), not product documentation like User Guides and Help. And with the exception of the STC articles, none of the resources I was reading were talking about what a technical writer would produce, or how they fit into Agile (other than being part of the Scrum team).

I had just started reading Agile Software Development with Scrum when a friend forwarded a job opening to me.� The job description sounded like a very good fit with my skills and interests.� The company was looking for someone with experience working in an Agile software development environment.

By this point I?d learned enough about Agile to know that the way we were implementing it at my company (developers in two different cities, the tech writer and project manager on a completely different continent) was not going to be conducive to my success as an Agile Technical Writer.� �And I was intrigued by Agile. I now knew enough to be able to ?talk the talk? during my interviews.� During my interview I quizzed the VP of Engineering.� They were still using the Waterfall Model, but were planning to switch to Agile development at the beginning of 2009.��

I liked the idea of getting in at the beginning and being able to shape the way the technical writer fit into the Agile team.�� They made me an offer, I accepted, and I started work there in October 2008.

Fast forward to May 2009 and the end of Sprint 4.� The last day of the sprint our company had a layoff, and I was one of the casualties.� Six weeks later they called me back to work part time (two days a week).� So while I?m still working in an Agile environment, I?m no longer embedded with the team working to document the current sprint.� Hopefully that will change as the economy starts to recover.

The Developer Ignite 2 Experience

Thu, 12 Nov 2009 08:00 GMT

Last night I presented at Developer Ignite 2.� What a great experience!� The friendly energy from the audience was powerfully supportive.� The organizers had everything smooth and rolling, with excellent after event food.

The True Measure of Agile

I'm passionate about Agile and the power it brings to the people who apply it as intended.� I'm also frustrated by strong evidence that many who speak the words of Agile development are only wrapping the same old practices in buzz.� This is very bad for Agile and developers everywhere.� So many times I've talked to engineers who “did Agile” or “did Scrum” and then proceed to describe a broken and painful experience of micro-management or loosely controlled chaos to failure.� Coaching someone back from such a false agile implementation is often harder than pulling them out of waterfall.

The goal of my presentation was to point people back to the Agile Manifesto, to consider that there are meanings and values behind those words.� Pick a framework, like Scrum or XP.� Combine with practices like TDD and continuous integration.� Do your “stand-up” meeting sitting down if you want.� But make sure you check against the Agile Manifesto to keep driving to what Agile really means.� That if those values are promoted by what you are doing, whatever it is, you are on the “true Agile” path.

My slides are available below for download and reuse.� Because the Ignite format allows only 15 seconds per non-stop slide, there are few words, if any, on most of them.� Perhaps you will find better words than mine to fill in!� Let me know what you think of the message you get from them.� The video will be posted soon at the event web page.� Then you can compare what you thought to what I said.

Download presentation as an ODP. (Open Document Presentation format, as with OpenOffice.org Impress)
Download presentation as a PDF.

What I Learned

All of the presentations were great! A few points that stood out for me were:

Tomasz Stechly (@tstechly) introduced me to the concept and benefits of immutable code.� I'm now sorry to say it's not a technique I have looked into very much.
Derek Neighbors (@dneighbors) highlighted that we have too much information to slog through every day and that geo-location is one of the ways we can filter the flood to get at what is relevant where we are standing right now.
Leo Godin (@leogodin217) re-enforced many of the things I read about getting to done and giving what the customer wants, a solution.
Clayton Lengel-Zigich (@claytonlz) told 10 fables from Aesop and applied each of them to software development, including pair programming and TDD!

All of the presentations were great! I said that already and I'll say it again, if anyone asks.� Such talent in the Phoenix area!

Thank You

I give thanks to everyone who sponsored, organized, promoted and spoke.� Especially I thank the audience for an awesome experience!

Remembering the Principles Behind the Agile Manifesto

Wed, 04 Nov 2009 10:43 GMT

In discussing the merits of an agile approach to design and development, I went back to the source and read through the Agile Manifesto. For all the rhetoric that flies around about what agile is, what is or isn?t agile, who knows agile best, etc., it?s great to get back to the guiding principles, which I totally agree with. In fact, it?s hard to disagree with any of these principles.

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Software Moulding Methods

Sun, 01 Nov 2009 16:31 GMT

Christian Sarkar and I started an e-dialog�on�Agile Business Service Management in�BSMReview. Both of us are keenly interested in exploring the broad application of Agile BSM in the context of Gartner's�Top Ten Technologies for 2010. To quote Christian:

Israel, where do�agile practices�fit into this? Just about everywhere as well?

The short answer to Christian's good question is as follows:

I consider the principles articulated in the Manifesto For Agile Software Development �http://agilemanifesto.org universal and timeless. They certainly apply just about everywhere. As a matter of fact, we are seeing the Manifesto principles applied more and more to the development of hardware and content.

The fascinating thing in what we are witnessing (see, for example:�Scale in London �- Part II,�An Omen in Chicago,�Depth in Seattle, and�Richness and Vibrancy in Boston) is�the evolution of the classical problem of managing multiple�Software Development Life Cycles. Instead of dealing with one ‘material' (software), we handle multiple ‘materials' (software, hardware, content, business initiative, etc.) of dissimilar characteristics. The net effect is as follows:

The challenge then becomes the simultaneous and synchronized management of two or more ‘substances' (e.g. software and content; software, content and business initiative; or, software, hardware, content and business initiative) of different characteristics under a unified process. It is conceptually fairly similar to the techniques used in engineering composite materials.

Ten years have passed since�Evans and�Wurster demonstrated the effects of separating the virtual from the physical. As�software becomes pervasive, we are now starting to explore putting the virtual back together with the physical through a new generation of software�moulding methods.