I’m coming out as not-Agile and not post-Agile

Big A vs. Little a

Huh? What? I’ve written a fair bit on this blog about agile topics, but I always try to write about agility with a small “a”. I’m not really into Agile with a big “A” though – I’m not into doing things according to a set of rules and having arguments about whether I’m doing it right or not. I’m not anti-agile, but I’m increasingly anti-Agile.

To me, the ideological arguments, definitions of everything, frameworks, money-spinning certifications and money-spinning tooling are what’s wrong with doing “Agile”. Being empirical, reflecting and adapting, honestly communicating and putting people first as an approach is being “agile”.

I don’t really like the term “post-Agile” either though as it comes with a bunch of baggage and is easily misinterpreted – and I still see benefits in adopting agile practices. I don’t want to see another specific set of rules or a statement or beliefs with elitist signatures. For me what’s next after agile is about dropping the ideology in software process, destroying the ivory tower of trademarks, formal definitions, money spinning tools and money-spinning certification programmes.

We need to get rid of the League of Agile Methodology Experts and if anyone says “Ah, but this is different” when showing a website of process content then you have my permission to hit them with a stick.

So what does the future look like?

Software development is a complex social activity involving teams of people forming and self-organising to work together, sometimes in teams of teams which is even harder. As technology is increasingly abstracting up and raising in maturity so is the way that developers, managers and organisations think about software and doing software. I think the problem is getting increasingly social, and the solutions will start looking increasingly social using more “soft practices”.

Software process improvement agents/consultants/coaches/mentors (including myself) need to take a long hard look at themselves. Are they telling people how to do it right when they can’t even write HelloWorld in a modern language? I’ve said that to some acquaintances in the industry, generously qualifying “modern language” as something significantly commercially used in the last 10 years and seen them look quite offended at my insulting affront to their professional integrity. I’ll go out on a limb and say you can’t coach a software development team if you don’t know how to write software.

So… software process improvement?

The world runs on software, it’s everywhere and it’s critical. Getting better at doing software, improving the software value chain, is a noble aim and will continue to be as it means getting better at doing our businesses and our lives.

For me process improvement (dislike that phrase as well) is going to be more about combining psychology based business change practices with the best bits of a wide variety of ways of working (agile, lean, Scrum, what you currently do, RUP, Kanban, various workflow patters etc.) with technical software development practices like continuous integration, continuous delivery.

We need to work together, not as “leaders and followers” or “consultants and clients” but as collaborative peers working together to apply specialist skills and experience so that we can all improve. Smart people should be treated as smart people, we have much to learn from them and should be thinking in terms of fellowship rather than leadership.

I’m calling this overlap “soft practices”* because the term is evocative of:

• The practice of doing software
• The practices involved in doing software
• Being able to deal with people is sometimes called  having “soft skills“
• Soft power

What do you think about “post-Agile”?

 

* I’ve even set up a company called Soft Practice to do this stuff, that’s why I’ve not been blogging much recently, who knew there’d be so many forms to fill in!

Get your point across using positive statements

This is a simple one but amazingly important: use positive statements.

A positive statement is something like “to sprint you must run fast”. Conversely a negative statement is something like “to sprint you must not run slowly”. The problem with using negative statements is that for them to be processed by the listener the concept being negated (in this case running slowly) has to be represented first by the listener before being negated. Here’s two examples, one about software and the other about addiction. Then I’ll cover the more devious application of the technique before finishing with the positive application.

If you tell someone not to do something first they have to think about doing it, a bit like my purple penguin example in the introduction to this blog series.

Software

Here’s an example from software process training I used to hear regarding RUP phases: “The RUP phases Inception, Elaboration, Construction and Transition are not requirements, design, implementation and deployment…” This was a well intentioned phrase aiming to dispel a common misconception when risk-value lifecycles were first being introduced to classic waterfall minded managers. Unfortunately this sentence actually reinforces the misconception one and maybe two reasons, firstly it’s a negative statement meaning the listener has to make that link in their mind between these phases and the waterfall stages and then negate it. The second reason is that it’s too easy for a tired person on a training course to miss that key “not” word and totally misunderstand the trainer’s intention.

This happened to a colleague of mine who used this sentence and the client’s training manager sitting on the course mis-heard (swore they didn’t when challenged) and never used my colleague’s training services again.

Addiction

Imagine someone who’s going to give up smoking. Friends with decent intentions may say “Just don’t think about smoking” and yet the end result is that the listener has to think about smoking (linking in all of their anchored states).  In fact there’s a whole industry of negative statements around giving up smoking that are designed to make people think it isn’t an easy thing to do.

My first sentence might sound a little odd. Normally the phrase is “trying to give up smoking” but that’s because the word “try” presupposes failure which is why marketing folks have done their best to ensure it’s the normal way of talking about giving up. Just think of all of those adverts for giving up aids that tell smokers how hard it is. Sneaky.

The Sneaky Side

The problem is that a negative statement sneaks in a sliver of representation that counters the stated meaning. There’s a really insidious side to this when considering negative questions. Negative questions are any question including the word “not” (even in the form of a contraction when it’s even more sneaky) and they are a clever way of embedding pre-suppositions. Here’s an example:

“Don’t you think using positive statements is a good idea?”

Expand it out and it becomes:

“Do not you think using positive statements is a good idea?”

The second form of the question sounds very odd and unnatural. In fact it’ll confuse many people for a moment (excellent pattern interrupt) and yet the first form doesn’t sound so strange, and yet rather oddly people will almost always agree to a statement using a negative contraction. Magicians and mentalists use this trick a lot “Couldn’t you have changed your mind at any point?”, “Haven’t I been reasonably honest about …?”. And of course if the entertainers are doing it you can be sure the sneaky salespeople, callous cold-readers and other such charlatans are doing the same. In fact this particular construct is used especially heavily by cold readers, the effect is multiplied based on the level of rapport at one far end of the see-saw even slight nudge is enough to direct a listener.

If you consider the basic form of the question “Do you think using positive statements is a good idea?” you’ll notice that’s it’s neutral, it doesn’t presuppose an answer in any direction. That’s the difference.

The Positive Side

I’ve written a lot on the ethics of using somewhat sneaky linguistics before so I’ll leave out that discussion again. But there are some great positive ways to use this knowledge. Here’s an example from this very post (+10 internet points if you noticed it earlier)

In the section about addiction I wrote: ” there’s a whole industry of negative statements around giving up smoking that are designed to make people think it isn’t an easy thing to do”. I deliberately used a contracted negative statement that presupposes that it is an easy thing to do. I used a negative statement to cause a positive representation.

Another simple way to use this knowledge is to simply use positive statements. Tell people what you want them to do and think. Avoid telling people what not to think. (er.. two negatives in one sentence what the…?)

This works especially well with children, instead of telling them not do something (such as “stop being noisy”) tell them what to do positively (such as “be quiet”). The first makes the kid think about being noisy, the second makes them think about being quiet. However it must be said that even the most carefully crafted sentence isn’t going to get a little kid to be quiet, but that’s ok they’re meant to be noisy.

Finally

So, aren’t you glad you read this?

---

This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.

Definition of done

Teams are sometimes split into smaller sub-teams. Almost always they are part of a bigger team, which in turn is part of a bigger team and so on and so forth until we reach the organisational entity. Don’t get me started on B2B teams.  Imagine an onion, with lots of layers. A weird mutated onion with multiple cores and overlapping onions. One that has tendrils sticking out into other similarly mutated onions like a big brain… Ok metaphor taken too far. Back to the topic…

The point is that everything team is connected to everything else. At every boundary it’s necessary to have a “Definition of Done” so that teams and their stakeholders understand what they’re getting.  Any good or otherwise set of software development practices (like Scrum, RUP, waterfall  or whatever you’re using) should help the team define the levels of their Definition of Done. I’m not using a specific example so I’ll just make some up off the top of my head to illustrate the point:

• Fully documented, discs printed, shrink wrapped and online distribution site fully functional, support systems in place ready for users.
• Beta test program
• Acceptance Tested
• Integration Tested
• System Tested
• Unit Tested
• Code Built
• Code written
• Code designed
• Idea thought of
• Requirement captured

Given some levels like this we need to ask the question where do we draw the line? As an R&D team, as a component team, as an integration team or business team I’d expect different answers. And for those answers to vary according to points in the lifecycle and relationships between teams and stakeholders.

The point is that these different levels of done take different amounts of work and are intended to differentiate different levels of quality (although I’ve used a fair few public release versions of software that don’t appear to have even been unit tested!). Without working out what the definition of done is between teams or parts of a team no one can estimate, plan or deliver any work.

If you have problems with multiple teams working together in your organisation, a lack of understanding of the Definition of Done is one of the common causes and is relatively easy to fix.

Use Case vs. User Story

Use Cases are too big to fit into a sprint/iteration! User Stories are so fine grained there’s too many too keep track of! Where’s the big picture? How to we define releases? Argh!!! I don’t know which to use!

Personally I tend to use both. I don’t think there’s any conflict between Use Cases and User Stories, in fact they’re rather complementary. Here’s how and why….

A few years ago I delivered a presentation at an agile software development conference entitled “Do requirements still matter?”. The short answer was “yes”. Most descriptions of agile iteration start with having a backlog, prioritising etc. etc. But where does the backlog come from? My answer: the Backlog Fairy; obviously.

Of course requirements still matter, they’re how we get a common understanding between customers and development teams of what we need to do. They’re the units by which we can incrementally build systems. In the rush to adopt agile processes a lot of teams have forgotten that they still need to start up with some lightweight analysis of scope and risk.

One of the things Use Cases are great at is capturing the big picture, showing a simple diagram of stick people and blobs that people who’ve never heard of UML can happily discuss in terms of what big bits of functionality are in and out of the system and who’s going to do them. The humble Use Case diagram. Not so easy to do that with a massive list of small stories.

However Use Cases can often be a bit too big to fit into a single development cycle but since they’re made up of a lot of different scenarios they’re easy to slice up into smaller bits. This is where I often use stories.

The advantage of Use Cases defining the scope is they’re nice chunky things to estimate and prioritise in a first pass. Of course as we get going we’ll estimate and prioritise stories for sprints/iterations but Use Cases help us prioritise requirements into Releases.

So I use a Use Case diagram to describe the high level scope of the thing to be developed. This normally takes about 5minutes to sketch. Then I use the Use Cases identified by the diagram (not documents, just the ovals on the diagram) to focus discussion on deriving stories (or use case slices) for development and testing within a sprint/iteration.

Sometimes stories turn up that don’t really fit into the early Use Case model, this is a rather good thing as it lets us challenge the understanding of scope. Does the story not fit in because it’s not really in line with the customers priorities and needs, it’s a cross-cutting or architectural concern or because we’ve missed some important part of the scope? All are important things to understand.

The Kung Fu of Software Engineering

I’ve been studying both kung fu and software engineering for many years. I’ve come to realise that they are very similar and that kung fu is a pretty good metaphor for software engineering.

Done right it looks easy, but it’s not

When you watch kung fu in movies, or martial arts in general it makes sense logically, it looks sensible. Attackers punch in one direction and defenders block in another. Sometimes there’s tricks and special moves but they’re just a matter of learning them. However when you actually try and do these moves you find it’s not so simple. It’s not easy to react the right way under pressure when you’ve not done it before. You need to learn muscle memory, improve your fitness, work on your reactions and internalise sometimes counter-intuitive techniques. When you really do it well you use very little energy to do something that looks easy and it becomes easy but other people can’t get it just by watching you.

Both software engineering and kung fu are deceptively difficult, with hidden complexities and complex emergent behaviour. I think it was Grady Booch who said (although I couldn’t find the quote so any mistake is mine) “Software development has, is and always will be, inherently complex”.

Complexity built from simple small techniques

In many kung fu styles you learn basic small movements in repetition, often called “form” in martial arts, Sil Nim Tao (generally referred to as Siu Nim Tao in Wing Chun kung fu, the RUP of kung fu) is translated as “little idea form”. Learning this form we learn all of the basic movements and stances that set up the body positions required to get the mechanical advantage in a given situation. Each individual movement tends to be very, very simple.

This kind of information and learning is analogous to the basic software engineering knowledge that we give people. We teach them how to write in a language, idioms, patterns, standard architectures, frameworks, build technologies, iterative patterns etc.

However knowing which techniques apply in which situations, which play well with others and how to put them all together is another level of expertise based on experience. Teaching someone the basics does not make them a master. Software engineering, like kung fu is something you should never stop practising and learning.

It gets more complex when you add more people

Defending yourself from one attacker is a whole different ball game than defending yourself from two attackers. Defending yourself from a group of attackers breaks down the whole mixed metaphor of ballgames, sports and anything else in the vicinity. The complexity of the action increases significantly as you add more people, it’s not just a linear relationship. As more and more people are involved there are emergent behaviours that can’t be predicted from the beginning.

This is true of any activity that multiple people take part in, especially complex activities. In kung fu it means you have multiple attacks, more energy in your attackers which means once you’re tired you’re in trouble. In software it means you have multiple people doing things at the same time with subtly or radically different ideas on what should be done and the best way to do it.

The only ways to reduce this complexity in software engineering are to go up or down. We can either abstract away from the complexity moving to higher level technologies where possible (sacrificing fine control typically) although such abstraction tends to bring it’s own complexities or we can dive down and educate the team (in the broadest sends) on the complexities to try and reach a common understanding.

No plan survives contact with the enemy

Trying to plan in detail all of the details of a kung fu fight, even against a known assailant is about as pointless as trying to plan all of the details of a software project. There is too much uncertainty, too much complexity and too much emergent behaviour. Above all there is too much change. In both kung fu and software engineering we need to remain agile and responsive to change, in the environment, the different things being thrown at us and our own actions.

There’s no magical solution

We’re not in the Matrix, we can’t download kung fu skills into our heads in seconds. Or software engineering skills. These things take years to learn, will be slightly different for every individual as they tailor the standard wisdom to their particular individual skills and style.

There’s a lot to learn. Personally I work as a software development coach helping people structure and plan their work from architecture and design mentoring, SCM & Build techniques and tooling, requirements management, agile and iterative project management, portfolio and business management. In many ways these kind of things, and others similar to them, can be thought of as different styles of martial art. Just because you’re good at one of them doesn’t mean that you’re good at another, or the next new one that comes along. Of course a certain aptitude helps, and knowledge of one certainly makes others easier to learn but beware of “experts in everything”.

We can’t all be Bruce Lee, Jackie Chan or Jet Li but we get a choice about where we are on the spectrum between being a master and an armchair expert sitting on the sofa watching others do it.

Finally

I believe that there’s an exact art and subtle science to both martial arts and software engineering. We need to practice these skills, we need to be continually learning and improving. We need to learn from other styles and experienced practitioners.

“Kung Fu” is actually translated to “achievement through great effort”

If you’re in the Cheltenham, UK area come and do some kung fu with me at Chi Wai Black Belt Academy.

I’ll leave you to make your own Chuck Norris software jokes…

Ngrams for nerds

Pictures that are worth 500 billion words!

Google Ngram Viewer shows graphs of how many times words or phrases have occurred in a set of 5 million books over the years. They’re a really interesting way of seeing trends in information and relative importance between words. It’s free and easy so check it out.

Here’s some I recently ran that I found interesting. I ran most of them from 1950 onwards and  the info only goes up to 2008.

Comparison of programming languages

Programming Languages

Ngram link – When looking at this you’ve got to mentally remove the baseline Java and Pascal references from the 1950 as they’re about coffee, islands and mathematicians. Interesting to see Java so dominant.

Programming paradigms

Programming Paradigms

Ngram link – I found this one really interesting. Compared to the others in my query “structured programming” had a lot more books written about it. I wonder how much this is a reflection of the rise of the internet… these days although there are lots of programming books the primary source for learning a language is online material?

Methodologies

Methodologies

Ngram link – I was a little surprised to see RUP so much more prevalent than agile but then I did have to add “software development” to the term to avoid including the bendy and stretchy. Also as with the previous one I suspect that there’s a difference here between a vendor driven process with supporting books and a more open source philosophy on agile as a generic umbrella for methodologies, and therefore more online sources. As Ivar Jacobson says: “No one reads process books“

Shareware, Freeware and OSS

Shareware, Freeware and Open Source

Ngram link – This one speaks for itself I wish I could have worked out how to add “expensive vendor products” to the query!

User Stories vs. Use Cases

User Story vs. Use Case

Ngram link – Ah yes, this argument again. Interestingly this dominance of use case over user story in written books correlates with query stats between user stories and use cases on by blog and the ivarjacobson.com site. Personally I think they’re both great and complimentary, I often use them together on software projects.

Windows vs. Linux

Windows vs. Linux

Ngram link – Yep, Linux beats Windows at every turn.

More Ngrams!

For more fun with Ngrams watch this very funny video explaining this stuff

How to avoid Fragile Agile, Flexibility in Context

A presentation I gave at the UK RUG Annual Meeting on what can make agile development fragile and how to avoid that fragility.

Unfortunately animations don’t work and slideshare’s screwed up the agenda slides but you can still follow it

Why do people still waterfall their development process?

Generally the software development industry has caught on to the fact that iterative development is a good thing. Only people that don’t believe in common sense think it’s a great idea to leave all of your testing to the end and hope for the best. With that in mind then why do people still have a waterfall mentality to their software development processes?

At the beginning of a project you can’t possibly know everything about it, that’s one of the many reasons it makes sense to iterate, so you can do some work and then refine your plans based on your work. For some odd reason though a lot of projects, even though they might develop iteratively, seem to think they should define their process at the beginning of a project in great detail and then stick to it regardless of the facts due to some misguided need for process alignment or similar.

That attitude just doesn’t make sense. A view of what practices will be followed is necessary at the beginning so that everyone’s on the same page and now what they’re meant to be doing, but even the formally defined iterative processes like RUP say that the process should be examined and refined each iteration.

In my experience an extremely detailed formal process is difficult to change. If you’ve got a 50 page development case. huge stack of xml files in your favourite process authoring tool or similar it’s very hard to make useful changes to a process. Of course you can change the review requirements of the Use Case Specifications from Formal-Internal to Formal-External, but it’s not so easy to scale down the formality of business modelling while adding a practice to address user experience issues.

Software development process can (and should) be thought of as a collection of practices. Each practice should address a particular aspect of software development in a complete fashion. Every small technique is not a practice (in coding terms every idiom is not a pattern). Using Use Cases, being Iterative,  using Component Based Development are all good examples of practices. They can be added or removed to your project’s way of working and the level of formality can be scaled up or down on each practice. Practices are the natural unit of adoption for processes.

It’s always best to start small and simple. At the beginning of a project just do what you can see. It might initially make sense to think about using Use Cases as a common way of managing requirements for your project and it clearly makes sense to iterate in most cases. Then as the project progresses and more understanding is reached more practices can be added as necessary. This is an iterative approach to software development process, it’s just common sense.

At IJI we’ve been doing this sort of practice based way or working for ages – in fact it’s what the company was created around as the fine brains we have created this approach and brought it to life in EssWork and EssUP which is a kernel and a collection of practices.

Anyway, enough of the company blurb, more about practices. I think everyone can agree that this is a sensible approach to software development as it applies the lessons the industry has learnt about software development back onto the problem. It doesn’t matter which vendors tools are used, or what process frameworks are used this is just a sensible approach, and the best thing is it is compatible with whatever you’re already doing that is successful or necessary in your organisation. I work with organisations helping them to change and adopt their processes and in every organisation I’ve been to is doing at least one thing well. Using practices to work with process improvement means that we can just add to what’s already working, incorporate the necessary governance or operational activities in an organisation, add SCRUM if that’s what’s wanted and have it all work together in a cohesive way of working.

To achieve this adding together of practices in a way that works you need to have a foundation that provides a common understanding of the basic concepts of software development so that practices can fit together neatly. This is intellectually quite tricky to achieve but necessary. It should also be practically invisible to the people doing projects – they don’t want to think about process geeky things like the process architecture that can support practice composition in a seamless way. At IJI we call this the kernel – which I think is a suitably geeky term. We have also built it both conceptually and in software (that’s what EssWork is) along with what we think are the “essential practices” (that’s what EssUP is) and now the big vendors are following suit and packaging their processes this way.

Maybe one day we can get away from branded processes by vendors and just have a software development community using, sharing and collaborating on practices.

Oh yeah, and they should be in tools not websites, and free!

RSDC UK 2008 Review

So RSDC UK is over and I’m finally getting a chance to blog about it. It was cool to meet so many old friends and new make new connections. There were even some blog readers that were able to recognise me IRL by mentally adding 6 years and a beard on to my blog picture Very impressive!

I think it was the best UK Rational event for a long time, and there were some great speakers. Unfortunately the chairs were uncomfortable, some of the rooms too small and the venue would do well to invest in some air conditioning. I suspect that going to an event at the Royal College of Phyicians in the height of summer (assuming we ever have one in this country again) would be enough cause to need a doctor. Regardless of that, and the amount of walking up and down stairs I did, I think it was a great event. The buzz was mainly about the Jazz platform and associated tools (RTC, RQM, RRC).

Day 1

The conference was opened by Graham Spittle (IBM SWG UKISA VP) and Danny Sabbah (IBM Rational Worldwide VP) who set the scene well for Erich Gamma (in real life) and Grady Booch (in Second Life). Unfortunately the Second Life link went belly up and we did’t get all of Grady’s keynote. Which must have been extremely annoying for Grady since it was 3:30am for him! Erich then took over and gave an excellent Rational Team Concert demo (RTC). When he started his demo I was a bit worried he was going to cover all of my planned demo too, but fortunately it didn’t overlap completely. Since he did the Monday keynote and I did the last slot on Tuesday there was enough time and quantity of information for the delegates so a little overlap didn’t hurt. Erich also did a panel discussion on Agile development in the context of Geographically Distributed Development along with Scott Ambler and Julian Holmes moderated by Anthony Kesterton.

The great TQ (Terry Quatrani) was also present speaking on Agile Modelling, I had a meeting to attend so unfortunately didn’t get to see her speak which is a shame because she’s always great. I did speak to people that did go who just confirmed that I’d have rather gone than have a meeting!

Following the break it was then time for me to speak along with Linda Weedon of PwC and Matt Archer (also of IJI) on “CUPID – Implementing the IBM Rational Unified Process at PricewaterhouseCoopers” which is all about our experiences in deploying UP using a practice based approach. I think the session went really well, we had some pertinent questions which is always a good sign of people staying awake and listening To close the day Ian Spence gave an excellent (as usual) talk on “Conversations in Context: Using Use Cases on Agile Projects”. Following an excellent dinner and a few glasses of wine kindly provided by a competitor it was time to commute home and eventually get to sleep at around 1am. It’s much easier at conferences when you’re staying at or really close to the venue! During the dinner there was a caricature artist or two wondering around who came to our table. Naturally we volunteered Ian to be caricatured and I managed to take a quick pic with my phone of him with his Mad Scientist caricature.

Ian Spence - the Mad Scientist

It’s a little known fact that Ian is also a Kung Fu master which is why his hand appears blurred in this pic. Fractions of a second later my phone was whisked from my hand at the speed of lightening.

Day 2

Day 2 was for some peculiar reason started 30mins earlier than day 1. This didn’t impress me, especially since like most people I hadn’t noticed until I was texted while on the train on the way in. Fortunately I was early enough anyway to get there on time. Mike O’Rourke opened the day with some description of the Rational 2.0 Roadmap (Jazz and future products). Rumours were confirmed about Rational Project Management and Rational Enterprise Reporting being released Q1 next year.

Ivar Jacobson then gave an excellent keynote on “Back to basics: Getting Good Software Quickly and at Low Cost” which focussed on using practices in a smart way, not following processes. I’ve seen Ivar speak many times, and many times on practice based development, which isn’t that surprising since I work for him but it’s always entertaining to hear the man speak.

I also had some meetings on Day 2 but the sessions that really stood out for me were Peter Eeles talking on “The Rise of the Development Environment Architect” which was based on his paper on DevelopWorks. This is an excellent formalisation of something that has been part of my job for some time. I also enjoyed Derek Holt’s talk on “RTC and the Agile Development Strategy”.

Finally to wrap up Day 2 I presented on own this time on “Live Jazz: Process Execution in IBM Rational Team Concert”. This started off with a demo of EssWork in Eclipse, shell sharing with RTC and creating a new process by composing practices as described in Ivar’s slideware at morning keynote. I then started executing my new process in RTC. It was the end of a long two days in a really hot room so I kept it quite light and I think it went well – and hopefully the audience got something different and new from the talk. If you are now kicking yourself that you missed this talk, fear not I’ll be repeating most of it as part of a webinar I’m doing in October – more details here.

Thanks to all those who attended my talks and came and said hello, especially those that read the Mac Daddy! I’ll post the slides in a few days

Ivar Jacobson International at the RSDC 2008

This year Ivar Jacobson International will be at the Rational Software Development Conference 2008 (RSDC). We’ll have a stand in the exhibition center and 7 presentations throughout the conference. So if you’re coming to the conference then come along and see us and our presentations. These are listed in chronological order but obviously the ones at the end are the ones to look out for

Monday – June 2nd

Conversations in Context: Using Use Cases on Agile Projects RA04 3:00 pm – 4:00 pm, presented by Ian Spence (Chief Scientist, IJI)

Abstract: One of the major challenges facing any team hoping to become more agile is how to manage its requirements. This presentation shows how, with a little care and the correct emphasis, use cases and IBM(R) Rational(R) RequisitePro(R) can provide the perfect solution for Agile teams – one that isn’t just Agile but is also robust and scalable; allowing teams to benefit from Agile techniques on even the largest, most safety critical, out-sourced, and distributed projects.

Practical Visual Modeling AC05 4:15 pm – 5:45 pm, Presented by Robert Maksimchuk (VP of Services Delivery, IJI)

Abstract: Project teams beginning to adopt visual modeling and the Unified Modeling Language often suffer from the “white paper syndrome” – they’ve been trained, but struggle with where to begin, how deep to go, and so on. This presentation approaches visual modeling pragmatically. Basic visual modeling is discussed, augmented with practical experiential advice, lessons learned from real-world projects, and heuristics for the beginning visual modeler.

Tuesday – June 3rd

Case Study at Nordea Bank: Survival Kits for Successful Process Adoption PPM25 3:30 pm – 5:00 pm, Presented by Ivar Jacobson (IJI Founder and CEO) and Anna Gustafsson (Manager, Nordea Bank)

Abstract: You can have the best process in the world but if people don’t adopt it, it is not very useful. Process adoption is a challenge in all methodology camps. The bigger the change is the harder it is. The agile movement has been very successful primarily because they didn’t take bigger pieces than people can adopt naturally. On the other hand agile methods are harder to scale. In this talk we will combine the two approaches. We will show how process adoption can be made in small digestible steps but also how it can scale. The change will be driven by the development team itself. We get highly motivated teams that focus on project delivery and on customer success. Good examples and success stories will be presented.

Wednesday – June 4th

What’s the Problem? How to Make Sure Your Solution Delivers the Right Thing RA10 10:00 am – 11:00 am, Presented by Kurt Bittner (CTO-Americas, IJI)

Abstract: Many teams jump straight to defining requirements without really understanding the context for the solution and the business problems that need to be solved. This presentation uses a consistent example throughout to clearly explain techniques that can be used by any team to improve their understanding of the real needs of their stakeholders. The result is fewer false starts and improved quality of delivered

Back to Basics. Getting Good Software Quickly and at Low Cost PPM11 11:15 am – 12:45 pm, Presented by Ivar Jacobson (IJI Founder and CEO)

Abstract: Getting good software quickly at low cost is what companies have been striving for to make this a better software world. The approaches to achieve this goal change over time. Some ideas have become mainstream and pushing them is like throwing in open doors. Use cases, architecture, components, iterations, user stories, features, and sprints are great. Companies have become agile – promoting services, product lines, aspects, and other ideas. How do companies integrate all these ideas into something useful that can help them deliver good software quickly and at low cost?

Case Study: Large-Scale Portfolio Management Experiences at PricewaterhouseCoopers PPM27 11:15 am – 12:45 pm, Presented by Mike MacDonagh, (Me! Principal Consultant, IJI) and Linda Weedon (Methods & Tools Manager, PwC)

Abstract: This session describes IBM(R) Rational(R) Portfolio Manager (RPM) enabling the ongoing journey towardsmaturity of the IBM(R) Rational Unified Process(R) aligned PricewaterhouseCoopers LLP UK IT organization. Attendees benefit from this session by learning from the real-world experience derived from the company’s success and challenges. This session demystifies RPM deployment by providing an example of a large-scale RPM implementation from a globally recognized firm.

Case Study: CUPID – Implementing the IBM(R) Rational Unified Process(R) at PricewaterhouseCoopers PPM14 4:15 pm – 5:45 pm, Presented by Mike MacDonagh, (Me! Principal Consultant, IJI) and Linda Weedon (Methods & Tools Manager, PwC) and Matt Archer (Principal Consultant, IJI)

Abstract: PricewaterhouseCoopers UK IT chose to adopt the IBM(R) Rational Unified Process(R) (RUP(R)) as part of a Capability Uplift and Process Improvement Deployment (CUPID) program. This presentation focuses on the use of RUP to manage a large-scale deployment of RUP and the effective adoption of the IBM Rational tools when facing challenges such as geographically distributed development, the requirement for process governance, and the tailoring of RUP to an organizational change management process.

Oh yeah, and here’s a sneak preview of what’s going to happen and be announced at the RSDC