Succeeding with Agile @ Scale, 8th March, London


130 Delegates
70 Organisations
13 Industry sectors
11 Speakers
5 Customer success stories

Succeeding with Agile @ Scale, 8th March, London

After many months of planning & preparation, the conference day finally arrived. The event exceed my own expectations and those of most of the people who came along. In total, 13 industry sectors were represented, with 130 delegates from 70 different organisations, demonstrating to me that succeeding with agile at scale is a common challenge across the breadth of our industry.

Even more interestingly, this event was not attended solely by software developers, architects and testers, but also by business change managers, project & programme managers, and various heads of IT functions, including many VPs and Directors – indicative of the fact that agile is now being taken very seriously at all levels within organisations.

It is no longer just about software development – it’s about achieving a lean, agile enterprise with technology as a key enabler; and that requires a truly joined-up IT supply chain, encompassing business change, large IT programmes, and both internal and external resources, across an increasingly distributed landscape.

Presentations from this event can be downloaded from: http://www.ivarjacobson.com/agile_at_scale/.

Shop Floor Agility Resistance

Agile software development can be an answer to over-prescriptive, over-documented and command & control style development. Agility is by no means anti-methodology, anti-documentation or anti-control. The idea is to restore balance and put people first.

In my experience most people think that, foremost, customers and management have to be convinced that adopting agile practices will lead to better, faster, cheaper and/or happier software development. And they also assume that transitioning to agile practices on the shop floor is a piece of cake. It is about more freedom, craftsmanship and collaboration, so who will object to that?

Well, in reality there are lots of reasons why analysts, developers, testers and people in roles alike object against agile. For example, there are people that object against teamwork because it threatens their knowledge based status.  Or what about team members that consistently refuse to update their tasks preventing them from having an up-to-date sprint burn chart. Another example is team members that just cannot focus on one of two user stories, always do work outside the scope of the sprint and never finish their tasks. Normal project or people management you say? What about team members that tell you that they do not have the required discipline nor are willing to try. Or what about staff who get violent when they are asked to move to another office space in order to create a co-located environment? Read More

Giving Empowerment or Taking Autonomy – Part 2

Read Part One here.

Let’s explore another aspect. Imagine an individual or team where the desire for autonomy or empowerment does not exist. This may sound unlikely but there are more examples of this out there than you can imagine.

In a traditional command and control organisation, dependent behaviour for long standing employees is often ingrained into each employee’s behaviours. In fact, if you are an individual who craves independence and self-determination then you are unlikely to become a long standing employee at this traditional command and control organisation.

This behaviour manifests itself as more individuals, who want to be told what they need to do, when they need to do it, are brought into the organisation. These individuals do not want to be responsible for making decisions about how they should work, when they should work and what tasks they should be performing.  By no means am I condemning this kind of behaviour. The “mechanics” of a team can be very important and as long as they participate to a certain extent in the team “independence” then their ability to complete the tasks they are given can be extremely beneficial. Read More

MoSCoW Anxiety

According to Wikipedia MoSCoW is a prioritization technique and a core aspect of agile software development. Its purpose is to focus a team on the most important requirements, for example to meet a deadline.

I know of many project teams that struggle using this technique because their stakeholders are unwilling to do the prioritization or accept the technique itself. If you have participated on a project where all requirements were classified as must have, I am sure you know what I mean.

What can you do when this happens to you? Well, valid options that might come to mind are run and hide and performing a coup for a decent Product Owner. However, before you go to extremes you might want to try another option first.

Basically what we have here is a kind of anxiety, MoSCoW anxiety if you will.  Anxiety? Yes!  In my experience many stakeholders simply become afraid they will not get what they have asked for when they are asked to classify requirements below the must have level. This makes perfect sense when you reckon that many projects deliver only a (small) part of the promised functionality and a lot of stakeholders have felt let down by IT at least a number of times. Read More

Giving Empowerment or Taking Autonomy

Part One

I’ve been working as an agile mentor for a few years now. (This is a mentor of agile software development teams, not a mentor of all things bendy – just so we’re clear.) In this role, I’ve built up a fair amount of experience in helping teams overcome technical /process problems and I’ve recently become interested in the softer side of agile software development teams – the psychology behind agility.

It all started when I watched a video on YouTube “The Surprising Truth of What Motivates Us” http://www.youtube.com/watch?v=u6XAPnuFjJc which is a summary of the book of the same name by Dan Pink.  By pure coincidence, on the same day I watched the Youtube video, I read  some review comments on a paper that debated whether the term “empowerment” or “autonomy” should be used when talking about the goals for true agility. It was an interesting discussion and it made me question some of my previous assumptions.

The first question is – what is the difference between autonomy and empowerment? A colleague said that in the simplest terms empowerment is given whereas autonomy is taken. If you look at definitions of the two words in the simplest form, they are:

Autonomy - the power or right of self-government

Empowerment - the giving or delegation of power or authority; authorization

Read More

Less is more

The motto "less is more" is often used in art and architecture circles to refer to a philosophy of minimalism ( http://en.wikipedia.org/wiki/Minimalism). Minimalism is related to a concept often referred to as Occam's Razor (http://en.wikipedia.org/wiki/Occam%27s_razor), or the idea that the simplest possible explanation should be chosen when considering alternatives.

These concepts came back to me as I considered the situation on a team with which we had been working.  The team was making reasonable progress, but it was clear that a couple of team members were struggling a bit.  The dilemma was this: does the team join together to help bring the team members along or do they, to use the vernacular from a well-known television program, "vote them off the island".

Conventional wisdom says that more people can get more work done than fewer people, but as Fred Brooks observed long ago in "The Mythical  Man Month", more people frequently do not get as much done, and adding people to a project can actually slow down velocity.  To apply Occam's Razor, we should have exactly as many people as we need on a project to get the work done, not a person more.  To apply the principle of minimalism, we actually ought to be a little understaffed.

People tend to perform better when there is a little stress.  As hunter-gatherers long ago, we probably hunted better with a little hunger driving us on; a full stomach leads to a kind of sleepy complacency.  We need goals that are just a little beyond our reach, as observed Robert Browning when he said that "a man's reach should exceed his grasp".

All this is a nice theory, but what about our team?  In true self-organizing fashion, the team decided that it would make more progress with fewer people.  The result?  The velocity of the team actually went up, proving that, at least for this team, less was indeed more.

The Product Owner from Hell

On at least two occasions we've run into a Product Owner that was, to be honest, an agile team's worst nightmare.The Product Owner is supposed to represent the interests of the business, providing information on needs, requirements, priorities, and the like.  This one, however, was a former IT guy, steeped in the traditional approach.  Instead of merely establishing priorities and representing the needs of the business, he also wanted the team to have a detailed task plan that he felt he needed to approve.  He didn't understand or accept the idea of a self-organizing team.  In short, the guy was a control freak who felt that being the product owner put him in charge of everything.

While we want the Product Owner to be engaged and feel a sense of commitment, this guy needed to be committed, or at least get some therapy!  The twin ideas that there is no detailed iteration plan, and by this I mean a plan with formal tasks and dependencies, and that the team is self-directing, flew in the face of everything this former IT manager held dear. 

The agile team needs to act as a team, based on bonds of professionalism and mutual accountability.  There is no room for micromanagement, and being appointed the Product Owner does not come with the right or responsibility to tell the team how to do their jobs.  The Product Owner has clear responsibility for the what and the why, but not the how or when.

When you find yourself faced with such a Product Owner, the only suitable reaction is to stage a coup; you need a different Product Owner.  If that won't work, you need to accept that your project is not going to be agile.  You might even want to think about finding a new project.

Holiday Greetings from Sion Roberts, CEO

2011 has without doubt been a busy year for economic and political observers across the world.  Almost every developed country has felt the impact of national and continental reaction to overspending and borrowing in previous years, and individuals, companies and governments have to look for newer and better ways to save money and be efficient while improving effectiveness.
While the general outlook for the immediate future for most in the Western world is one of austerity and prudence, it is easy (and sometimes wrong !) to interpret this as arbitrary “cost cutting” wherever we can…a broader analysis of the problem is invariably needed to determine the right way to achieve desired goals of efficiency and effectiveness, and in IJI’s experience use of software, and specifically GOOD software is a key enabler to these goals.

I’m delighted to say that despite a tough year for corporate and public sector budgets, our clients have taken that broader perspective in 2011 and engaged with our consultants at IJI on many initiatives to improve their businesses though greater software effectiveness, from development of new business-critical applications using Agile principles; to implementing better measures across their software organisations, to introducing new communities of Agile Change Agents and breaking down other barriers to effective software delivery.  I’m proud to say that we’ve helped you achieve success and all of us at IJI thank you for the opportunity and look forward to further successes in 2012.  We have some very exciting developments scheduled for release in the next twelve months to support these challenges including our key event of the year in March entitled “Succeeding with [email protected]” – a subject in which we have significant experience, and one in which we are extremely passionate.  I hope that you can join us to hear the perspectives from your peers in the industry on this important topic.

To all of our clients, past, present and future; to our colleagues in the industry and others who know us as a company, I would like to extend the warmest of wishes for the Holiday Period.  I hope it brings time for us to pause for a while, and to reflect both personally and professionally on this year and the next one, and on that note I wish you a prosperous and successful New Year.

Sion Roberts

Holiday Greetings from Ivar Jacobson by Ivar Jacobson

Season's Greetings

Year after year I feel fortunate that we as a company can report so many new technology advances – advances which help our customers build better software, faster and with happier users and clients.  A number of new practices have been developed to help our customers scale agile beyond small teams to whole organizations.  Our practices for scaling agile and for setting up coaching communities have, with our experienced mentors, helped many organizations to not just become successful with small projects but changed organizations in their entirety.  Several case studies confirm these successes.

Most important in 2011 is our release of Use-Case 2.0.  After having refined the way we work with agile use cases over many years, we have now put together all our experience in an ebook.  Our customers have already used this around the world, China, UK, Sweden, US; but now we have streamlined it close to perfection.  Use-Case 2.0 supports backlog-driven development with Scrum or Kanban making it as lean as it can be.  Many of our colleagues and friends are awaiting this new release ready to start using it.

Lean development has been a long term goal for our company.  Our approach, starting lean with a kernel of the most essential elements in software engineering and staying lean as more detailed practices are added on top of the kernel, is getting wide acceptance in the world.  During 2012, we will see standards being adopted, the academic world embracing it, new tools being available, the industry getting some governance of their ways of working, and developers systematically growing their competence in software development.  Most importantly, success stories will speak for themselves: agile and lean will be achievable targets for every organization developing software.

Welcome to the future, but don't forget to enjoy the holidays.
--Ivar Jacobson

Funding New Projects

In a prior blog entry I noted the traditional approach to funding new development efforts:

  1. the business gets an idea and writes a few sentences of description,
  2. IT tries to figure out what the business really meant and comes up with an estimate based on their best guess, and
  3. this amount gets locked in as a "committed" estimate to which IT is held accountable. 

The only thing that should be committed is the people who think this is a sane approach to funding projects.

A better model works like this:

  • The business identifies a set of desired business outcomes that they would like to achieve, along with the net present value of achieving those desired outcomes.
  • Based on this value, the business decides how much it is willing to spend to achieve those desired outcomes.  Usually this is based on the required rate of return of investments in the business.  This amount establishes an upper limit on the project that could deliver those outcomes.
  • The IT planning process then focuses on determining whether the desired outcomes can be achieved within the constraints established by the business planning process.  If they cannot, further funding for the project is stopped and more worthy projects are funded.  Several alternative approaches may be tried and rejected, and deciding project feasibility may require some prototyping and evaluation to determine viability.

This is how research and development funding works and, let's face it, software development has a lot in common with R&D: both deal with a lot of unknowns at the start of a project, so much so that it is usually not possible to precisely define the exact work that will be needed to achieve a particular end.  Both R&D and software are essentially exploratory: at the beginning of the effort the exact result is not known with a high degree of assurance so we have to evolve toward a solution.  The current funding model's assumptions that the solution is easily definable and therefore should be easy to estimate just doesn't work for most new software development efforts.

Page 3 of 1612345678910...Last »