Pragmatic Agile Weblog

Agile software development in real life

The use of SO THAT in user stories

recently, I found a good example of why (or how) to use the SO THAT clause in a user story. The use case is simple: a web site where the visitor should not be required to sign-up or sign-in.

The US would look like:

AS A visitor I WANT to access the site without any sign in or sign up SO THAT …

What to put in the SO THAT clause? try not to read the below and stop a bit thinking about it. What would you put?
I am pretty sure most of you is thinking “it depends by the reason why this is needed”…. EXACTLY! the SO THAT clause tells something about why we want that US; it tells something about the value to the user. It is important, because differently than use cases or formal specifications, it does not give the exact intended behavior, but just the goal from a user perspective. This tells us a lot in terms of what we can think of and what we should not if, for example, we want to provide the functionality in increments.

Back to the US, one version could be:

AS A visitor I WANT to access the site without any sign in or sign up SO THAT I do not give any personal data to the site

Or:

AS A visitor I WANT to access the site without any sign in or sign up SO THAT I can easily and quickly access all functionality of the site

As you see these two USs provide very different perspectives on what’s the real value to the user: in one case is privacy, in another case is easy of use. This can bring to very different strategies to split the story if necessary.

Advertisements

August 18, 2011 Posted by | Agile, Software development | Leave a comment

Declaring war to branches

What do branches have to do with agile? They have a role under many aspects. I will not cover the most basic ones like why a version control system is necessary (which is true regardless you do agile or not), but I want to cover a bit some implications we are facing in an environment with many teams working in parallel.

I believe the role of a VCS is fundamentally twofold: it’s the central repository of code from which you deliver a new release; and it is a communication tool, so that all developers can see what each other does and keep themselves updated with each other work.

In this post, I want to go in more details about the second aspect, accordingly to some real work (and world) experience I notice in my teams.

The concept that a scrum team uses the repository as a communication tool, is quite widely accepted. I would say it is well metabolized by each team member, so that everyone does not feel comfortable in keeping the code on his/her laptop only. It is the way code is exchanged, which is very good indeed. It is also well received and assimilated as a communication tool between different teams, so that we can all relay on nightly builds built from the trunk. The code repository is therefore a tool every one in the team relay upon to have the most stable code.

What’s wrong then? well, nothing in itself. However, there is a dynamic I am still trying to understand better, but that is showing some very bad effects. I start to identify a broken pattern, which is like this:

  1. One dev team needs to implement a new feature for a customer that we want to include in the product;
  2. Because as usual customers are in hurry, you need to deliver as quick as you can, and all that you know better than me, the team decides to make branch for that customer and develop the new feature on the branch
  3. Since everybody understands that 2 must be a temporarily solution because we want at the end the feature in the product, the team promises itself after releasing to the customer the branch will be merged
  4. The merge does never happen

And here is where the process breaks. At the end, you have different customers with radically different versions, all live with something that it is not the product. And because they are live, the forces against update them with a new release of the product are so strong that very hardly they will ever be all aligned to the same version. I am sure all readers understand this is quite bad, and who hosts for their customers, understands how bad it is even more.

The reasons why the merge does not happen are many and all good: firstly and most fundamentally everybody is scared to do the merge because at the point when it will be done, the code has so diverged from the trunk that the merge will be boring, very hard, long and will surely result in breaking the product, requiring a lot of regression and so on. Secondly, if the project is successfully, very likely you have a phase II, still urgent, still important. Do you want to risk you break everything? of course not, let’s keep working on the branch… this is even more true in agile development where it is us before all that tries to make the customer accept to do things incrementally and in phases.

So, should we ban the branches at all? Shall we just all work on the trunk? Honestly I do not know, at least yet. But I want to see if there is another way… what I’ve been doing since a few iterations is trying to understand why the teams feel so badly the need to work on branches. I am realizing something interesting that I want to report below:

  1. Usually branches start from a genuine good intention of a team, not wanting to interfere with the work of other teams: if I work on my own branch, I will not break the code for you, so that you can keep working like I wasn’t doing anything.
  2. Β The above is a practice also in place during the iterations, even at the level of a single iteration. The assumption is that the code will be merged before accepting the user story. The good news is that at this level (differently from branches for a project) the teams do it diligently. However what’s the direct result? it is that the other teams will just see the code changing suddenly at the end of the iteration, without time to remedy. The good intention of not breaking the code for other teams turns into delaying the time when issues can be encountered to a time where usually there is not more time to fix things within the iteration.

What I am finding is that branches are created mainly for the fear of breaking the code for other teams. Again, the intention is good, but is it the best way to make sure we do not break the code for other teams? Are we sure we can not work differently so that we do not break the code, and if we do is not a big deal?

In working directly with the teams I started to question the need of a branch and I expressly asked a team to discuss a bit before creating one. I am finding particularly interesting that most of the times, the need of a branch comes from the fear that only potentially a developer interferes with the work of another developer. And even more interestingly, they may be working on the same code. This seems common sense at a first glance. But when asking something like: have you checked with the other team if this is a problem? have you talked to them to see if touching that area of the code would be a problem for them? have you briefly discussed the changes together so that everybody will not have big surprises? …
You know what? most of the times that communication did not happen. Thus, the communication tool subversion, is turning into an obstacle to a more effective and efficient way to communicate: talking. This is the aspect I consider more important and that I want to attack. I want to attack the fear of breaking the code for others. And I believe the best way is not to isolate more the teams, but more integration between them. The best strategy is not to avoid to interfere each other, but to interfere more, on a daily basis, working all the time on the same trunk of code. I am sure this will break things more often and we will have a less stable trunk for a while. But I also think the incidents that will happen will make the teams generate the anti-corps to pay more attention to the code they release, to make sure code is tested at build time, to be able to change code more quickly and to talk more each other to save time and effort.

Therefore, from now on, I declared war to branches!

August 15, 2011 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment

Stabilization sprints

One of the most advertised advantages of agile development is that at the end of each iteration the product is always releasable. The idea is that each piece of functionality is either done or not done and everything done should be shippable.

Ok, we are not that good yet πŸ™‚ Or maybe this is not even a realistic goal in some organizations or under certain conditions. Under the cover, the subject is not that obvious and if you are interested in knowing more these are few interesting links:

http://blog.mountaingoatsoftware.com/correct-use-of-a-release-sprint

http://www.infoq.com/news/2009/12/stabilization-sprints
http://www.infoq.com/news/2008/02/done-shippable-quality

We adopt stabilization sprints before declaring a release GA. Indeed, the stabilization process is a work-in-progress that we try to improve at every release. For the upcoming release we structured the stabilization process in two main phases: integration and final stabilization. The integration period will take two iterations and is focused on putting all components together and performing integration and other high level testing. Then we will have one iteration of final stabilization. In this last period we will focus on real usage to make sure we do not encounter major issues that will get in the face of the user on real deployments. In the following, the process is described in little more details.

Integration

Length: 2 2week iterations
Focus: integration, regression and performance testing; general testing by selected users (dogfoodding)
Entrance criteria:

  • snapshots of all components ready
  • user documentation ready
  • no bugs targeted to the release
  • no development planned for the release
  • device list of the devices we condider blocker for the release ready

Output: all packages become release candidate

Final stabilization

Length: 1 2week iteration
Focus: stability and general testing by selected users
Entrance criteria:

  • all components are release candidates
  • network environment for testing machines verified and locked
  • performance are ok

Output: all packages become GA

During integration testing any bug found is triaged to determined if it must be fixed in the current release or can be postponed. Of course the bar is pretty high assuming most of the bugs should have been captured during development iterations.
The final stabilization iteration is intended to make sure a live system works smoothly for a period of time without major flaws. In our experience, it is a very good way to capture things that are difficult to foresee in advance and that likely (as per Murphy’s law) a customer would run into pretty soon. Only really sever bugs should block the release at this stage.

I keep asking myself if stabilization sprints are necessary in real cases or instead are just a sign of sub optimal development practices during normal iterations. For now, my experience tells me stabilization gives still a lot of value to the quality of the product shipping and allows to focus the team on tasks that would be not very efficient to do upfront in each iteration. But as usual, we will see how it goes and try to improve next time πŸ˜‰

se dico che vado a correre

March 4, 2010 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment

Cost of unit testing

I found an interesting article about the topic of how much unit testing cost: http://misko.hevery.com/2009/10/01/cost-of-testing

October 2, 2009 Posted by | Software development | Leave a comment

As a … I want …

One of the key aspect of agile development is expressing requirements in user stories. It is one of the things that I like more, because it encourages developers to think always like a user.

However, in our switch to agile I’ve seen US using the most disparate roles between “As a” and “I want”. The most common mistake is when a technical task is expressed as a US using expressions like “As a developer I want to merge the tag into the trunk” or “As a product owner I want to know the size of a the MEA feature”.

For this reason I decided to identify which roles we use and introduce them to the team at the last demo meeting. Using a role not in the set below should be a big smell that there is something wrong.

The first role we use is the user:

The user role

The user role

The user is who is using the user interface of our software. This is primarily client oriented, but not in all cases.

As some of you is wondering, yes, the command line is a user interface as well. But it is a particular one, used mainly not from the final users, but most likely by system administrators. The system administrator is one the roles we selected from our us:

The system administrator role

The system administrator role

With our software there are also users whose duty is to help other users. These person are the portal administrators, who administers the portal users and other portal functionality. The portal administrator is therefore one of our selected roles:

The portal administrator role

The portal administrator role

Finally, an important aspect of our software is that it provides APIs and SDKs other developers can use to build application on top of our framework. These are definitely a special case of users, for which we want to build features. The developer is therefore the last one of the roles we use in our backlog.

The developer role

The developer role

Note that “this” developer is not the development team, which therefore has visibility to all Funambol code. This is a developer that wants to access a limited set of the source code, or maybe not even the source code, but libraries or APIs delivered in binary form. It is who uses our software to build something else, not who develops the software itself.

Many thanks to Francesco Mapelli, the author of the nice “omini” that represent our user stories roles.

September 13, 2009 Posted by | Agile, Funambol, Software engineering | Leave a comment

The risk of nano-management

One of the things agile practitioners and advocates fight, at least in principle, is project micro-management that is often associated with waterfall software development. Agile methodologies replace the need of having a so hated project manager that controls and then commands any aspect of the team and project with an informative work place and process that encourages sharing also the status of the project. Having a release split in iterations and then user stories in each iteration makes it easier to everybody to figure out how things are going.

This is fairly true, at least looking at our experience, where the new process has been accepted with favour at all levels in the company. In fact, some interpret agile processes like chaos reigns and where any sort of planning is banned. At the contrary, because agile software development embraces changes, an agile process asks the team to diligently and regularly check where the actual plan is compared to the original plan. To do so, inefficient and always-out-dated gantt are replaced with attitude and “tools”.

The attitude of an agile team is to make a plan at the beginning of an iteration or release and adjust it over time. This must not mean that the team is not in any way committed to the plan. The team should do all it can to follow the plan, but the goal is not to adhere to the plan, but to deliver value. Even the concept of “plan” may vary from team to team or amongst different agile processes. The plan could be a sequence of tasks, an high level gantt or even just a prioritized backlog. The goal of the team is to deliver what they promised, the way they achieve it is team responsibility only.

There are also great tools agile practices introduce or make use of to help teams to better perform. One of the best one, in my opinion, is at the basis of iterative and incremental development: user stories. I believe user stories are a powerful tool in the hands of all stakeholders and teams because they represent the atomic (at least at a certain level) piece of work around which a number of other concepts are attached. The first one, for who, like us, estimates in story points, is the size. And when you have a size, and an iteration, you have how many story points the teams make in a certain amount of time, which is their velocity. With user stories and size you can track the amount of work done or to be done over time with burn down or burn up charts. With user stories teams can commit on definite amounts of work and make very clear what’s get done and what not.
In addition to what more related to the process, often agile processes bring a number of other techniques to develop better software or increase productivity. All this is completely under the light of the stakeholders and managers, and in my opinion this is a very positive aspect of agile principles.

However (you knew this was going to come… πŸ™‚ ), stakeholders and managers must be trained or socialized on the real goal and meaning of this tools. Some of these tools are so easy to pick up and give so great visibility that I am sure all managers love them. But if the meaning of the tools is misinterpreted or distorted, than it becomes an issue, because something that you think is useful for your team turns against the team at managers’ eyes.

A good example of what I mean is velocity. It is so easy to associate velocity with productivity or team ability to deliver on time. It is a simple number that may go up, and you are happy, or down and you are unhappy. But if you take just that number, ignoring where it comes from or what’s behind it, than you can easily go off-road. For instance, let’s assume the team is going through a tough period, some features revealed to be harder than expected, more legacy code than expected required refactoring, and maybe the team changed its composition. The sum of these factors will certainly take down the team velocity. If you do not trust your team, you will probably start to think that the team is not able to deliver, so you trust them even less. When managers see (or perceive) bad results they have to react. It is their job and role. This can lead to a situation where managers, given the number of tools that provide so good knowledge of what’s happening in the team, can be tempted not only to start to micro-manage the team, but to even nano-manage it (“why this user story is so big?”, “are you sure it is 10 s.p. and not 9?”, “why are you working on this u.s. now instead of later?”, “can you send me an email with all task you have done at the end of each day?”, “the burn down is not going down, we need to work more…”, “shall we put more resources?”, “c’mon a normal developer would take half of the time to do this…”, etc, etc…)

I am in that category too and so I am the first one tempted to go on that path. Instead, I think we should resist that temptation and keep trusting the team. This does not mean of course to trust the team blindly. We must make sure the team understands there is a problem and therefore acts to fix it. The team must know very clearly what are the areas of concern and what the factors of unhappiness, but still they deserve respect for their work and trust their willing to deliver the promised value. They may need help, and here is what managers are for: to listen the teams needs and help them to see how to overcome the difficulties. Help is also challenging the teams and their decision, to help them cross-check their assumptions and decisions. But the worst thing we could do is stick an ideal burn down chart on the wall and teach the teams that that is what they have to do πŸ˜‰

(or perceive)

August 14, 2009 Posted by | Agile, Software engineering | Leave a comment

Facing reality

I’ve been asking myself what’s the biggest and hardest challenge in embracing agile development. There are a lot of factors in play and it is not easy to clearly see what gives us the biggest pain. There have been also different phases in our way of adopting scrum, each with its challenges.

The human factor is surely one of the most interesting challenge because there is no way to foresee how people will react to the introduction of a development process that asks them to self-organize and make the team’s goals their own goals.

The practices their-self are challenging as well. You get lost very easily when you do a lot of changes at the same time. This is particularly true when you are experimenting yourself all those changes, because maybe you do not have the luxury of a budget for someone that can help you. In any way, I strongly believe there are things you have to learn in the hard way, no help other than your experience can show you the way.

Legacy code is another big obstacle in the way of being more agile. You would like to do more, be able to confidently change things; instead, you often fall in the chicken-and-egg problem that becoming able to do so means to spend time to refactor a big chunk of code. Since it is expensive, you do not start, piling technical debts over technical debts.

But the most challenging experience of embracing scrum is facing the reality. The essence of scrum is very simple: you have a check point of all your work, assumptions, plans, in a very short time-frame. This is terrific, because you know almost immediately how you are doing. But the reality can be something you and your stakeholders are not ready or willing to know.
When you do a long term plan, you keep the hope your plan is good until very close to the end. Since the deadline is far away, you keep the feeling that somehow you can catch up. There is usually not any real and concrete reason for that to happen, but you still believe it. The scope won’t be significantly reduced until the end, the resources will be the same for duration of the project, customers will keep bugging you with bugs and requests, you will keep read tons of emails per day. But still, you believe you can make it. There is something in the back of your brain that tells you “we cannot make it, we cannot make it…”. But you don’t hear it, and you keep believing something magic will happen.

Do not get me wrong, this is done all in good faith. The best product owners are the ones that see possible what everyone else considers impossible. This makes them more reluctant to consider that a plan is not achievable. They want the teams to have a “yes, we can!” attitude and they do not want to hear “sorry, this plan is not doable”. On the other side, the teams want to make their product owner happy, therefore tend to say “let’s try and see”.

I observed a very interesting phenomenon when we switched to two week iterations. Most teams over-committed so that after one week most of the stories were still not done. Asking the teams if the commitment were still confirmed, they were still confident they could complete all the stories. I was becoming every day most worried and the teams kept being confident they could do all the USs until the very last day. There was not any real reason to this to happen… but still the teams were confident. Do not get me wrong, I appreciated a lot the teams attitude of trying to keep the commitments to what they promised to deliver, but the result was that their goals have been constantly not met and the stakeholders have been seeing the teams constantly fail on their commitments. This resulted in unpredictable velocity and in the teams and stakeholders constantly frustrated by the missed goals.

But scrum asks you to do something different: to look at your self, at your teams, at your stakeholders and do not lie. Scrums allows you to achieve your goals because you first of all have to face the reality. The reality of your team, of your resources, of your possibilities, of your knowledge. Only if you accept this challenge and you accept you have to make a plan that works given your real conditions you will be able to see your progress iteration after iteration. Only in this way you can see your weaknesses and work around them in the meantime you work to fix them.
However, sometimes this is not easy to accept. You may be frustrated and wish you have a different team, different deadlines and a different budget. You will be tempted to point your finger to scrum just because it opens your eyes.
But if you resist to that temptation and start to accept reality, you will have the great opportunity to fix what’s wrong and therefore to constantly improve. End eventually, you will be surprised to meet unhoped results.

I believe there are two factors that allow a development team to face reality:

1. Trust each other. The development team shall always keep in mind that what the PO is asking is what will make the product a successful product. POs shall always keep in mind that the development team wants to build a successful product and put all its best efforts to make it happen.

2. The development team needs to gain the confidence of saying, without illusions, what’s achievable. The team needs to learn to say ‘NO’. Plus, the development team must learn to provide alternatives. Firm ‘NO’ must be exceptional. Most of the times a ‘NO’ should be accompanied but alternative options.

What I often tell my team is that we can accept we do mistakes because nobody is perfect. What we cannot afford and to not improve. Facing reality is a precondition to improve a team.

July 5, 2009 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment

Shouldn’t engineers just be engineers?

During release planning we do two things: estimate user stories and write and refine user stories…

One of the question I asked myself when I knew for the first time about USs and how an agile team works with the product owner to get and refine user stories was… developers are developers, they are trained and paid to find and implement solutions. Why should we ask them to be a bit of business analyst too and define the user stories?

The other day, one of my best engineer came with the same doubt. Do not get me wrong, it was not a critique or a way to quit what we were doing, but a perfectly legal doubt in the back of his mind.

The answer I gave myself at first was that not necessarily developers will have to write user stories. In a perfect scrum world, the product owner(s) has(have) the bandwidth to fully write and refine the user stories. Engineers should just focus on making sure they discuss the stories with the product owner(s) so that they understand them fully and then estimate and implement the stories. In many real cases, where the customer is not an internal product manager, this can be much more difficult, because as anyone, the customer will have many other priorities than writing stories. But in this case, an agile team can just incorporate a business analyst that proxies the customer and acts as the product owner toward the development team.

There are however some good reasons (i.e. reasons I consider good) to have engineers more involved in writing the stories. First, if the project is of any not trivial size, the number of user stories grows easily big, so big that you would need to add many business analysts or product owners (in addition to big walls on to which stick the cards πŸ™‚ ). In such case, you probably go back to involve the development team in helping out. The other reason, which is the most important, is that writing the user stories engineers are forced to see things with the eyes of the users, more than with the eyes of a technician. To make fun of ourselfs we coined the following acronym: MFMU… Maximu Flexibility Minimum Usability. It was because as engineers, we tend to thinks about how a feature should be done and how the code can be changed easily. This usually despite the usability of the final solution (users will do what we tell them to do…). This is particularly unpleasant in software product development, because when you develop a software product, you can achieve the best result when developers think like users. This fits well with the agile principle of releasing workable software. Most users can live with few features but working, much less with the promise that they will have one day a perfect feature set (which we know already will take a couple of releases to get stable πŸ™‚ ).

Writing user stories helps engineers to switch for a moment from the how to the what and this brings the benefit of understanding much better the requirements, the why things should be done in a certain way, what is really important for the user and what less, what the user will do to accept a story and so on.

This is why I am more than happy we need to help our POs in writing and refining the USs. We are not super good yet, but we will get there!

Some additional comments. Interestingly, another engineer came few days after the first with almost the same argument. Easily the discussion slipped to asking ourself if the focus of a software engineer should not be more on producing quality code than writing user stories. Or, in a way, if we should not focus on making sure we can change our code easily before trying to develop with an iterative (possibly incrementally) development process.

First of all let me say that of course it is fundamental that developers write quality code. This is a good part of a developer professionality and it must beΒ  a field of constant improvement. Still, I like my developers put their hands in the user stories because I believe it is equally important they streer their ability to write code toward the final and ultimate goal of software development, which is delivering value for the users. As a manager I am in the middle between the development team and the product team and in many cases I feel the two teams think about value of software development in two very different ways. Developers tend to see value in writing good quality code, the product owner tends to see the value in features delivered to the user. Scrum gives the great opportunity to get these two views closer and see a common goal: deliver value to the user in the most efficient way. As this sentence shows, there is a sequence that makes sense: first deliver value to the user, then constantly improve your efficiency.

February 22, 2009 Posted by | Agile, SCRUM, Software development, Software engineering, Uncategorized | Leave a comment

Iteration length

Finding the right iteration length is quite an interesting challenge. Or most probably it is a challenge when you you are a beginner in iterative and evolutive software development processes. It is true that the literature mentions that an iteration should last between one and four weeks, but still one or four weeks is a bit different :). Plus, different agile teams use different lengths and some go veerryyyy extreeeeemmmm! I know of teams with iterations of 2.5 days (yes! 2 days and an half!). Quite amazing, isn’t it?

Recently we decide to shorten the length of our iterations. We originally started with 4 week and at the beginning it looked a good compromise between keeping a constant and predictable pace and the overhead that the iterations seemed to add (iteration planning, design presentation, product presentations and retrospective meeting).

I must say that from the point of view of establishing an heart beat for all teams, it worked pretty well… but after three iterations we realized the iteration was too long. The first signal that shown us that something was wrong was highlighted by the iteration burn-down chart of the completed user stories. Take a look at the following chart, which is the average of the three scrum teams:

The Y axis is the number of story points to be completed and the X axis are the days of the iteration. There are a number of things I do not like of this graph: first, the accomplished story points is about 65% of the commitment. This is one of the biggest challenges we are facing: we are not predictable enough yet. Note that the result above is not due to big surprises we encountered during the iteration. What’s particularly interesting is that the line did not go down for half of the iteration, then it started to decrease. This behavior is more evident in the burn down below which regards of one of the teams (but the same pattern was similar for all teams):

Let’s ignore for now the peak, again, no stories were declared done until mid iteration, than finally things started to get better and at the end the team almost hit the target. In general, I believe this trend is due to two main factors:

  1. teams tend to commit optimistically
  2. our definition of done strongly depends on QA people acceptance, and nothing can be accepted until at least has been developed and is ready to test πŸ˜‰

Both issues share a common root cause: we are not good enough yet in breaking down user stories in something that can be developed and tested quickly so that work can be declared done earlier. What can we do to fix this situation? We will indeed keep learning how to split user stories before we start the iteration, but one thing we thought is thatΒ  four weeks is still a quite long period of time for people to realize that a story is not of the right size and cannot be completed in one iteration. What we noticed is that teams are often optimistic about commitments and like to try to commit more work more than less work. I must admit I like it, it would be a much bigger problem dealing with teams afraid of committing work. But I think predictability and reliability is important too, therefore I would like we try to achieve better trends in our burn down charts.

After thinking about it, we thought that reducing the length of the iteration to two weeks should help the teams in being more realistic in their commitments (they have now to plan for two weeks only!) and in seeing more clearly when a user story must be broken in smaller pieces.

Another signal that suggested us to shorten the iteration length was when we had a couple of customer related issues that required some attention by the teams. One of the principle of scrum is that teams must be protected as much as possible from external impediments and interruptions. Therefore we need to tell customers to wait the next iteration in as many cases as possible (indeed, critical issues are a different thing). Telling customers they have to wait one max two weeks is much more well accepted than 1 month πŸ˜‰

Another need that would benefit from a shorter iteration is product related. We deliver monthly product updates called “phone packs” that contain for example support for new phone models or carriers or small updates to the database and so on. Customers are starting to ask us to deliver more quickly such packages, potentially as soon as a new phone hit the market. The result of a shorter iteration is here pretty evident. It would allow us to schedule a new phone pack feature twice a month instead of once.

Well… It is enough to at least give it a try, isn’t it? πŸ™‚

From the next release we will use two week iterations for all teams. Let’s see what happens πŸ˜‰ Stay tuned, I will keep you updated.

December 29, 2008 Posted by | Agile, Funambol, SCRUM, Software development, Software engineering | Leave a comment

The decline of agile or need of a pragmatic approach to agile?

Recently, a number of interesting posts has shaken the tranquil days of the agile movement. Two remarkable ones are:

Of the two the most interesting is the first one by James Shore co-author of “The art of agile development” and agile trainer and consultant.

I would summarize the post with this paragraph:

“Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long. So they hire me to help them with one of these things. When I go visit, I see a team that is nominally agile, but is suffering huge numbers of problems and is anything but the joyful, settled, smooth-running workplace I expect from an agile organization.”

I think the most interesting information in the article is that he is experiencing that many teams in the real world are failing in applying agile principles and practices. I find it interesting because I believe it is related with the essence of this blog. The author presents his frustration in seeing teams defining themself “agile” and then failing in applying the most basic practices. I must say I am not surprised. I am not surprised because I know what turning a team from a more traditional software development model to a more evolutive and incremental development model means.

But this is not the most important point, for what my opinion counts. I believe that what is happening is not the decline of agile, but that it is entering his maturity. More and more organizations are adopting or are willing to adopt agile practices and therefore those practices are now challenged by the variety of real world environments. Many thinks and tell you that once you learn the agile manifest you can go back to your office and change everything in a blink. In too many occasions I heard people telling me that in order for agile practices to work, you first need A+B+C… in other words, it is too easy to assume that you can start always from the optimal conditions (you have the best and skilled team, very agile-motivated, all co-located, all willing to develop in pair, etc, etc)… what does it happen then if some of these conditions are not met? Shouldn’t agile techniques be pragmatic by definition and therefore allowing to face changes? I believe they should! Why then this is not happening?

My explanation is that there is the tendency to make of the agile methodology an ideal model, that guarantees brilliant results, once all the preconditions are met. But it is very difficult to find such preconditions all met in real world teams. The risk I see is that we replace an ideal model, the waterfall, with another ideal model, the agile. The waterfall is not applicable as it is in real environments because in the majority of the cases you cannot snapshot at time 0 the requirements, the design, the code, and so on and then hope that nothing changes. What happens if we build a methodology that requires so many things to happen at the same time all depending by each other and then one or some of the prerequisites are not met. All the methodology falls apart exactly like waterfall.

This is why it is fundamental that agile keeps its pragmatic nature. And I believe agile does so if accepts to face the issues of real world teams, without necessarily asking them to change everything and in once. I believe agile does so if accepts to face the business aspects that real world teams face every day (a co-located team can be simply not an option from a business perspective!). I believe agile does so if accepts the challenge to scale in size and in time. But most of all, I believe agile does so if instead of being considered a goal to achieve, it becomes a tool to improve quality and efficiency.

There is a risk, though, that we should avoid as much as possible. Pragmatism can sometimes hide the forces that resist to changes. Be pragmatic must be a way to improve things in a controlled way, taking calculated risks and being honest with yourself about your team. It cannot be the escuse to always find a reason why things should not change.

November 23, 2008 Posted by | Funambol, SCRUM, Software engineering | 1 Comment