agile

Theory X and Theory Y by Ivar Jacobson

Management styles have a huge effect on software development teams.  A significant shift required in  the movement toward a more agile approach is a change in the way that teams are managed and measured.Management styles can be described in  a number of ways - Theory X and Theory Y are popular approaches dating back to the 1960's but still applicable today.   Basically, Theory X assumes that people are basically untrustworthy slackers who need to be constantly monitored and told what to do and are only working because they need the money.  Theory Y assumes that people want to do a good job and are motivated by more than money, and that people produce their best results when they are working in a supportive environment that frees them to be creative and productive.It should come as no surprise that a necessary condition for a movement toward agile teaming is a "Theory Y" management culture - a team trying to adopt an agile approach in an organization with a "Theory X" management culture is doomed to failure and frustration; it will constantly be fighting the management system and the surrounding culture. In these organizations, the management culture (and its supporting measurement system) must change along with the team approach in order for both to be successful. Before you can change it, however, you need to understand it.

Agile or not Agile – that is the question ? Or is it ? by Ivar Jacobson

I often get called into companies who are thinking of going "Agile".  They have invested many thousands of dollars on a very complex SDLC taking the best ideas from the industry, but that process is not being followed and their teams are effectively not working together, and now think that Agile will solve those problems.  They come to IJC with a simple question "how do I adopt agile ?".  But when you dig, you find that this question is not as easy as it would appear.  When you question their motivation and their constraints, you find a whole list of issues and problems that Agile by itself can not solve.  Issues can range from off-shoring, to quality and performance.  Issues that no one approach can solve.

Agile software development seems to be a way of describing everything that is good in software process today.  It combines techniques and team practices with ways of changing organizations.  Thus, when people talk about agile they are talking about so many different things it is really hard to get a handle on them all - it is like saying I like European food and everyone knows what that means.  Do I mean Spanish, Swedish, French...?  Of course I can not mean English.  There is a lot of great stuff that has the label Agile, but the area that I will discuss today are the team techniques that Agile has brought to the table.  In particular SCRUM. 

First let's define a structure that SCRUM fits into.  SCRUM provides a fantastic set of very simple project management processes that help teams better function, but it does not provide great guidance in the areas of actually building software or making sure that project fits into something much larger.  Thus, I always position SCRUM in the context of three other processes.  Firstly, on top is an organizational process.  These are typically described in SDLC milestones, gates or phases.  They represent the key stages a project MUST go through from a funding and control point of view.  The second view of process is the team.  How does the team function to deliver software in support of this lifecycle?  This I label as team.  The third is the techniques that an individual must employ to actually build software.  Techniques such as OOAD or Test Driven Development - Also this is where techniques such as Use Case Driven development fit. SCRUM fits nicely into the middle layer - It is a set of team techniques that really help the team become a team.  But without the top and bottom views of process being in place SCRUM by itself would not work. 

Firstly SCRUM provides a very simple set of roles.  Product Owner (the go to person who owns the problem you are solving), the SCRUM Master (the person who runs the SCRUM meetings and protects the team) and the Development Team (the people that do the work).  I also often add a fourth role that of the Technical Owner, the person who owns the system from a technical point of view and is the go to person about all things about the architecture.  Secondly it provides three meetings.  A kick off meeting at the start of a sprint.  Oh, I had better introduce the idea of a sprint - A sprint is like an iteration.  A small chunk of time when stuff happens - has a clear set of goals and delivers stuff.  In terms of what it delivers they are classically stories, but can also be features or other units of stuff.  What is important about a sprint is that real work is done, that means working software is produced, tested and deployed (maybe to a pseudo production environment).  The second type of meeting, and the one that gets all the press is the daily Scrum - this meeting is short, say 15 minutes, and focused on three questions.  How did you do, what are you doing and what is stopping you?  These three questions enable the project to move along at a rapid, focused rate.  The third meeting is all about retrospective and proving you did what you were promising in your sprint.   So, SCRUM provides a great way of organizing the team, but without the lifecycle the team can not decide on what sprints they will do and the management can not appreciate the value of this sprint in the context of something bigger.  Without some techniques for building software individuals do not know what to do. 

So SCRUM must always be part of something bigger to really make an impact.  I would therefore argue that agile on its own is like a single food item; really to enjoy it, it needs to be put into the context of a meal.

Future of Process by Ivar Jacobson

August 15, 2003

I am currently in Lima, Peru where I have participated in an international conference and given a series of workshops.

This week started in New Orleans, where I gave a keynote at the XP Agile conference. I arrived late Sunday night but my XP friends were kindly waiting for me. Ward Cunningham, Bob Martin and Ron Jeffries were there. I had a great time with these people whom I respect very much. I have known Ward since 1987 and he is one of the few people who has moved technology into the masses with ideas such as CRC Cards, XP and also Wiki. Ron Jeffrey and I have been on a panel discussing light versus rich processes and we will be on another panel in October. We were missing Kent Beck (who arrived later) and my old personal friend Dave Thomas (who is on the advisory board of Jaczone).

I sympathize a lot with XP and agile methods. I have different opinions on some XP ideas, but in general I think XP is a good approach when exploring a new product. However, I think that XP doesn’t help you grow an organization. Therefore I want a process that can be as light as XP when you start a new initiative, but a process that can grow with the organization as you become successful. Well, I could talk a lot about that but not in this short postcard. My keynote was about the "Future of Process". The core message is that we talk too much about process instead of focusing on getting the job done. Instead we should rely on best practices of many kinds: technical, human, project, organizational etc. These best practices need to be well-defined, they need to be kept separate, but composable, and need to change as time goes by. Ideally the end-result should come across as an "Invisible Process". Here techniques like Waypointer developed by Jaczone will play a very important role.

Peru was very friendly, but the conference could have been better organized. I gave three presentations, I had about 200-400 people each time despite my talks being announced just 4 hours in advance of the actual talks. One challenge in Lima is that people in general don't speak English that well. Luckily, they found an excellent translator for me -- Elizabeth Ramirez Perasso, who has been studying my work for many years. I found that I have many fans in Peru. Thus I need to go back!

Page 4 of 41234