Agile Development

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.

TUP Event – An IJI Day in Beijing

Dr. Ivar Jacobson was invited to present the keynote at this year’s TUP conference held on December 10, 2011, in Beijing, China. TUP (Technology/User Experience/Product) includes a series of events hosted by CSDN, the biggest IT community in China. The speakers invited for these events are famous IT experts; and attendees are IT and management people who are interested in IT product development.  I was very pleased to present lean and agile development sessions along with Dr. PanWei Ng at the conference. With three IJI members presenting it became an IJI day at TUP 2011.

Dr. Jacobson presented “Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking”. Ivar’s lively and TUP Event   An IJI Day in Beijingengaging session clearly demonstrated to attendees the new reasoning around lean and that to stay lean you need to stay lean from the beginning of a project rather than trying to eliminate waste later.  By presenting three case studies representing business, software product and process method, Ivar demonstrated the concept of a “kernel” --representing the essence of something as a good starting point for most things you build.  You start lean and you stay lean throughout the life of what you build.

Read More

How to Fund Software Maintenance Efforts

Part of the problem with funding projects is that, from a funding perspective, we treat software development as a one-time event.  When we create a new application I think we all expect that maintenance will need to be made over time, but this is not reflected in the funding model.  Each round of maintenance usually requires a project charter and funding approval.  In obtaining funding approval the maintenance project now has to compete with all other projects for funding approval.  This sounds sensible until you think of the implications.

If we have a building with a leaky roof, we know that we have to fix it or more damage will occur.  In software it is just the same: if the existing application supports the wrong business process, damage to the business occurs as long as the problem goes unaddressed. Forcing application maintenance into the project approval process can delay, sometimes indefinitely, the funding of needed maintenance, resulting in higher costs later on. Read More

Page 3 of 71234567