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

Growing a Coaching Community

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

Fixed Scope + Fixed Schedule + Fixed Budget = Certain Failure

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 Journey Toward Self – Organizing, Self-Directing Agile Teams: The Role of the Agile Coach

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.

An Evening for Sharing Ideas with Friends

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 .

“Is code engineering an art or a science”? by Ivar Jacobson

I received this question in an interview with SDTimes.  Although answering this question is like walking through a mine-field, I was so intrigued by the question that I accepted the challenge.

Code engineering is an interesting term that I so far have not come across.  It instantly has a built in conflict because it implies that coding is an engineering activity and if it is, then it can't be an art or a science.    Neither of these would be an engineering activity. Thus, the question is broken.

It would be easier to answer the question "is coding an art or a science".  I think it is neither.  It is more like a craft.  However, when do you really need craftsmanship when writing code?

When you implement interesting new algorithms,  you really need excellent coding skills.  However, the total amount of code of this nature is small.  I dare say that more than 80% - 90 % of code written for applications in banking, telecom, defense, etc. are just plain implementations of relatively simple features.  The coding job is quite straightforward, most of it doesn’t require great craftsmenship. Understanding the business processes (or how you can change them), the user's needs, the architectural principles and values, the available solutions as prefabricated packages or frameworks etc. are then as critical as having good coding skills.

Now, is there a case when someone could motivate talking about code engineering.  Yes, if everything you do would be about coding.  When you think about new business processes, you express them as code.  When you think about what the software should do (requirements) you express it as code.  When you think about the architecture and design, you express it as code.  Then of course code engineering would make perfect sense.  On the contrary if you think about code engineering as a discipline besides other engineering activities (requirements, architecture, design, etc.), then you would sub-optimize the work you have to do while coding, and that would be a serious mistake – not smart!

Follow the conversation with me on Twitter.

Agile Grows Up: Agile Business Conference 2011, London

Another week, another event! This time it was the turn of the Agile Business Conference in London. It was encouraging to see an excellent turn out for this 3 day event, and an overwhelmingly positive attitude from delegates, speakers & sponsors. The thing that most struck me about the whole experience was that agile software development really is breaking out and growing up. This was a conference not just for people wanting to know what it’s all about and how to get started, but for people that want to improve and grow, and use agile in ever more complex and challenging environments. But in the words of the famous american baseball player, Casey Stengel: “The trick is growing up without growing old”....let's hope the agile movement is not just another fad in the development of the software engineering profession.

Quotation source: www.brainyquote.com.

Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking by Ivar Jacobson

"In every block of marble I see a statue as plain as though it stood before me, shaped and perfect in attitude and action. I have only to hew away the rough walls that imprison the lovely apparition to reveal it to the other eyes as mine see it."—Michelangelo.

So how can a 500 year old quotation be relevant to business today? Well, you’ll be surprised.

The concept of a “kernel” representing the essence of something is a good starting point for most things you build.  You start lean and you stay lean throughout the life of what you build.  The idea of a kernel has many practical applications in today’s business:

1) designing an agile business,

2) building products using agile techniques,

3)  re-engineering your method or way of working.

Proven in many practical situations, the kernel concept provides the ability to scale up the use of agile approaches whilst maintaining control and visibility. It is now being considered for adoption by standards bodies such as the Object Management Group to enable light weight, usable, agile approaches to knowledge management.

The justification for the title is that adopting a kernel approach focuses on the essentials and naturally leads to lean processes and systems. The renaissance is that instead of removing waste to get lean we start lean and stay lean.

I presented a keynote with the same title as this blog at the Agile Business Conference in London Oct 5.  You can download the presentation here.

Follow the conversation with me on Twitter.

Use-Case 2.0: Scaling Up, Scaling Out, Scaling In for Agile Projects by Ivar Jacobson

Use-cases continue to be a popular way of working for both business and system requirements.  Googling "use-case" yields a search volume six times greater than Googling "user story", but software development should not be driven by popularity. Instead we should use the most practical way of working, one that allows us to continuously improve.  Over the years we have learnt how to be truly successful with use cases, and of course we have learnt something from other techniques, such as user stories and aspect-orientation, which have inspired us to make use-cases even better while maintaining their core values.

Distinctive features of the new use cases are:

  • As agile and light as you want it to be
  • Scaling up, scaling out and scaling in - to meet your needs
  • It’s not just about requirements - it's for the whole lifecycle
  • It's also for non-functional requirements
  • It’s not just for software development - it's for business as well

The presenation at IIBA was received very well by the around 400 participants.  Afterwards IJI staff were busy explaining the new use-cases and how to find slices of use cases to populate the backlog to support Scrum or Kanban like projects. Participants signed up for the new eBook on use-case 2.0, to be released shortly.

You can register to receive the powerpoint presentation here.

Follow the conversation with me on Twitter.

Page 4 of 1612345678910...Last »