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.

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 Agile@Scale” – 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

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.

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 engaging 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

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

We’ve probably all been there at one time or another in our careers. We knew that change within our organisation had to happen. We were careful and we sought input before creating our plan. With careful consideration we built a plan that encompassed all our critical stakeholders; our budget was approved by management and our first critical new changes were implemented successfully.
Great first signs – right? But wait…our plan begins to die before it even takes off. Key stakeholders who appeared to be onboard are now complacent. And perhaps even worse, they are becoming large barriers to the success of the project.

Can it be turned around?

Implementing corporate change can be one of the toughest challenges for large organisations. Software development departments that want to scale their agile projects often run into this obstacle. The agile project that may have been extremely successful within a small team or department begins to crack and fall apart as the organisation attempts to scale Agile.  Read More

It is that time of year again, when organizations are putting the final touches on their project funding plans for tomorrow.  Over the past several months, a strange tale has played out across the globe, a farcical tale that if you tried to tell anyone outside IT about they would scarcely believe you.  It plays out like this:

Someone in the business gets something resembling an idea - not something fully formed, but at least an inkling that suggests that there might be some benefit achieved in developing something.  A few sentences are written about it and here is where the silliness begins.  All these little fragments of ideas are gathered together and then IT is asked to estimate the cost and schedule - based on little more than the few sentences of description.  If they are lucky they might get to ask some questions.

Everyone knows this is ludicrous, they will say, but they say they have no choice.  They put all manner of disclaimers on the estimates but these are forgotten over time.  What is recorded and remembered is a time and dollar cost estimate for each project - based on, remember, a few sentences of description.  This sounds so absurd that I know you would be laughing if you did not see it every year in your own organization.  But wait, it gets worse. Read More

The agile ideal is for a team to be composed of equals, peers who neither direct each other nor oversee each other, but who work collectively toward a common goal. Team members are self-directing in the sense that they, seeing the goals of the team, choose to work on things for which they are most capable. Since many teams start from a traditionally managed, externally directed world, the journey toward this idea takes time and adjustment for everyone involved. A team typically cannot become instantaneously self-directing.

Typically the journey is assisted and facilitated by a coach who helps the team learn new techniques and overcome barriers. The very existence of the coach suggests that the team is not wholly self-directing, at least not yet; the coach will naturally provide some direction to team members during the learning process. The degree to which the coach will "direct" depends on the progress the team has made toward becoming truly agile.

A typical problem is reflected in a recent question raised by a client. We recommended use of a particular newer framework (SOAJ) in place of the Hibernate/Spring framework familiar to the team, based on our understanding of the goals of the project and the skills of the team; in short, the new framework would reduce coding and increase code quality while improving performance. Some team members felt more comfortable with their familiar framework, however, and the team was divided on the use of the new framework. If the team is self-directing and self-organizing, who makes the decision in the event of a split decision?

It often falls to the agile coach to make these decisions. The coach generally has greater experience and is better equipped to make the choice when the team lacks experience. Coaches must be careful not to become dictators, however benevolent, and teams must take care not to become over-reliant on the coach. Over time, the incidence of coach intervention should decrease as the team gains experience and confidence.

Coaching is more than mere facilitating new practices: there is always an element of leadership in successful coaching engagements. Teams learn best by doing, and the coach must lead by doing as well. Over time, team members step forward and the coach steps back until, one day, the team is leading and directing itself. At first, however, the coach takes more of a directing role.

On the evening of November 14th, Ivar Jacobson International hosted an evening of camaraderie for our friends: staff, former colleagues, customers and partners at our office in Kista, Sweden.

It was an evening to share our experiences and update our guests on IJI’s recent activities and developments.

Ivar Jacobson, Svante Lidman, Graham Marsh and I presented IJI at the event and presented topics ranging from Scaling Agile to our new Use-Case 2.0 that our customers are currently using.

Svante Lidman presented an engaging and interesting presentation called “Learning’s from Large Scale Agile Transformation”. Svante discussed how a large client with thousands of developers and a large legacy system who was following a waterfall approach to software development is now making a successful transformation to becoming more agile.

Ivar updated attendees on Use-Case 2.0 (read Ivar’s previous posts for more info on this topic) and also presented Semat and Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking.

If you would like to be on our mailing list to be invited to one of our future events, drop me an email.