Pragmatic Agile Weblog

Agile software development in real life

Agile Jedi Initiative

Ok… in the agile mythology it is enough you explain agile to your team and everybody in the team will be excitedย  about it and can’t wait to start to release something every week and do pair programming. If this does not happen… just fire who is not convinced enough and hire somebody else…

I do not want to argue if this is a dogmatic or pragmatic position, I would just say it is not the way I like to face the issue. If there is something that agile tells you is that hiding the problems under the carpet of time does not make you do better. From agile you learn to highlight the problems and find the solutions.

In introducing agile in a team of about 30 engineers, we experienced people reacting in different ways: somebody was excited (at least in principle), somebody doubtful, some were completely against (and maybe still are), the most close to neutral. What to do in such situation? Fire who is not fully convinced and hire a new team? Give up? Or firmly keep trying to change things and fix problems convinced that the results will come? We have taken the former approach, but I have to admit we had to push some changes from top to the teams. This is not ideal indeed and only the time will tell if it was a good thing or not. For sure, it is not something you can keep doing for too long. How then encourage people to free-up their energy also in making the way they work better, easier, more efficient, more knowledgeable… in a word more enjoyable?

One initiative we introduced and I hope will bring the benefits above is the Agile Jedi Initiative. Aim of this initiative is to combine ideas, sensitivities, skills and energy of who is more sensitive to agile practices so to build a working group open to anyone that sees a problem in the current practices and wants to contribute to solve it. This is something that shall come from the teams and that is for the teams. I really hope it will virally spread to all members of the engineering team.

But what’s the mission of an Agile Jedi? A simple question with a non trivial (or no) answer, so let’s get some principles come to help us. An Agile Jedi:

  1. Constantly inspects and improves
  2. Does what makes sense, never more, never less
  3. Takes ownership
  4. Grows leadership
  5. Turns problems in opportunities
  6. Is not afraid to make mistakes
  7. Searches for the next right answer
  8. Breaks the patterns, sees things under different perspectives
  9. Exercises agile techniques
  10. Helps anyone in all the above

May the Force be with you!

Advertisements

May 1, 2010 Posted by | Agile, Funambol, Uncategorized | Leave a comment

nice Edo’s post: Foster collaboration in forming teams

A nice post from Edo: http://edschepis.wordpress.com/2010/04/27/foster-collaboration-in-forming-teams/

April 28, 2010 Posted by | Uncategorized | Leave a comment

Certified Scrum Professional

After CSM certification… my next step… http://edschepis.wordpress.com/2010/04/15/certified-scrum-professional/

Thanks to Funambol Engineering Team that gave me this opportunity: challenging every day my skills and our practices.

April 15, 2010 Posted by | Uncategorized | Leave a comment

Scrum?… a formality…

When somebody in the team says that Scrum is like the 12 tasks of Asterix in the following video….

What do you do? What is the best approach to manage the situation?

I’ve just posted the question to the scrumdevelopment Yahoo group and I’ll report here some feedback.

Stay tuned!

March 29, 2010 Posted by | Uncategorized | Leave a comment

Funambol Mobile Open Source: The Book

Funambol Book Cover The new Funambol Mobile Open Source book is out!!!

Really awesome… by Stefano Fornari and reviewers in Funambol.

Here is an introduction to the book:

The book is composed of two parts. The first part will take you through the steps required to fully understand and deploy Funambol to provide PIM synchronization and push email solution to your mobile users. This is done step-by-step, starting from a simple personal usage scenario to a more complex environment that must serve thousands of users. All components of the platform are smoothly introduced and explained, starting from the functionality they provide. The second part of the book is more informative and will assist you in building Funambol extensions. In particular, it contains an easy-to-follow tutorial that will allow you to write a Funambol connector in a few easy steps. If you are looking forward to install and get started with Funambol, this book is for you. You need to have a technical background and be confident with a bit of code tweaking, but not a developer. General server administration skills are assumed and familiarity with Java will be a benefit in places.

Buy your copy from many online stores (Amazon included) and enjoy the Mobile Open Source world.

January 7, 2010 Posted by | Uncategorized | Leave a comment

Brown bag agile lectures

Recently I’ve introduced the concept of Agile Lectures in Funambol (see here)… aka Brown Bag Lectures.

Below you can find the list of the lectures done until now…. a successful initiative in my opinion: 30 minutes every week, informal, cookies, coffee and beverages… not a meeting, more a coffee break (a little brown bag meeting).

Agile Lectures:

01 Sep 2009

  • “The Art of Agile Development” Book- Chapter 6: “Collaborating – Trust”Links:

22 Sep 2009

29 Sep 2009

06 Oct 2009

  • “Agile Estimating and Planning” Book – Chapter 4: “Estimating in Story Points”

… continue…

… maybe we could even do it live online also for external people ๐Ÿ˜‰

October 7, 2009 Posted by | Uncategorized | 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

Release planning started

It is time to plan the new release! Countach is the codename of the next Funambol release. We will make an entire iteration (2 weeks) of release planning with the goal of coming out with the release backlog for Countach and the iteration planning for the first iteration of the release.
Good luck to all the team! I am very excited and look forward to seeing the fruits.

For who curious about how we do it, we grouped the teams in different areas of the office. In the center (ideally) we put the product owner so that when teams need to discuss a US they go to the PO’s desk. The first task is to roughly estimate the USs in the backlog so that the PO can start putting them in the release backlog. This will drive additional investigations when needed or the process of splitting epics into USs. The fact that the release planning is time-boxed should make emerge what’s is more important from a business standpoint. In fact, if something cannot be evaluated in time, it won’t very likely go in the release (ok, we can make exceptions, but thoses will have to wait the iteration planning anyway and at that time, the planning will be time-boxed in one day only!).

I’ll keep you updated ๐Ÿ˜‰

February 16, 2009 Posted by | Uncategorized | Leave a comment

Our feedbacks for the Results Day

In November we have been part of a great event here in Italy: the Italian Agile Day.

One of the interesting thing the community has proposed is the “Results Day”: a way to share the experience of practicing the learned lessons from the conference – good and bad news to report.

In our experience we have some good news and I’ll focus on these in this post.

First of all we have learned that shorter iterations could help us a lot. Until now we have worked in 4 weeks iterations and the teams haven’t been so reliable in their commitments as you can see in the following burndown chart (an example from the previous release).

So, also convinced by something heard at the conference we have switched to 2 weeks long iterations… and very soon we have seen the following great results:

  1. user stories are now really small (we didn’t find yet a user story that cannot be split in smaller ones and therefore allow us to include in an iteration so short)
  2. teams are more in control of what they commit and therefore more reliable
  3. due to both the above results, we are starting now to work applying the right iterative development approach

And the burndown chart of one of the iterations of the new release is….

From 50% of completed story points we have now the 90% (I think we’ll always have a 10-20% of uncertainty in commitments but it can be acceptable in my opinion).

That’s all for the good news… in the next post we’ll tell you about what still concern us in our approach to agility…

February 4, 2009 Posted by | Uncategorized | Leave a comment

Funambol at the Master Open Source, University of Bologna

For who may be around, we are presenting our open source development story at the University of Bologna in their master course Open Source for student and professional.

Here are the slides.

January 23, 2009 Posted by | Uncategorized | Leave a comment